RK3518：1.5G 内存 + 8G 存储，如何跑起硬件编解码、Web、AI 识别、绿幕特效

智能直播2026-10-21 20:31

RK3518（RK3528A）直播推拉流全链路方案：1.5G 内存 + 8G 存储，如何跑起硬件编解码、Web、AI 识别、绿幕特效

本文所有数据中，标注 【实测】 的来自作者在 RK3518 开发板（核心为 Rockchip RK3528A）上的真实测量，其余来自 RK 官方 datasheet 或工程参考值，文中均有注明。

目录

一、方案定位：为什么是 RK3518

直播推拉流方案长期存在一个矛盾：

  • x86 小主机：性能强，但功耗高（15--35W）、价格高、体积大，做一体机/嵌入式盒子不现实；
  • 高端 ARM 芯片（RK3576/3588 级）：算力过剩，但整板成本和功耗跟着上去了；
  • RK3518（RK3528A） ：四核 A53 + Mali-450 + 完整 VPU 硬编解码，1.5GB 内存 + 8GB eMMC 的配置把成本压到百元级板卡，却恰好覆盖直播推拉流的全部硬需求：
直播链路需求 RK3518 的对应能力
视频编解码 独立 VPU：H.264/H.265 硬解 + 硬编，1080p@60
画面处理（缩放/旋转/格式转换/水印） RGA2 硬件 2D 引擎
特效合成（绿幕/字幕/台标/画中画） Mali-450 GPU + OpenGL ES 着色器
网络协议栈 RGMII 千兆网口 + Linux 全协议栈
Web 服务与播放 Nginx/Caddy + HTTP-FLV/WebRTC/HLS
AI 识别 CPU 量化推理（NCNN/MNN）+ RGA 前处理
显示输出 VOP2 + HDMI 2.0，1080p@60 + CVBS

一句话：用百元级板卡的钱，做到专业直播盒子的功能闭环。

二、硬件平台规格

本章为 RK 官方 datasheet 参数（RK3528A，板厂型号常标为 RK3518）。

2.1 核心配置

项目 规格
SoC Rockchip RK3528A（板厂型号 RK3518-r69）
CPU 四核 Cortex-A53（独立 NEON/FPU，共享 L2），最高 2.0GHz，支持 DVFS
GPU ARM Mali-450，支持 OpenGL ES 1.1/2.0、OpenVG 1.1
内存 32-bit DDR3(L)/LPDDR3/DDR4/LPDDR4(X)，板载可用 1.5GB
存储 eMMC 5.1（HS400、CMD Queue），8GB
视频解码 H.265 / H.264 / AVS2 / VP9，最高 4K@60fps 10-bit
视频编码 H.265 / H.264，最高 1080p@60fps
显示 VOP 控制器：HDMI 2.0（HDR10/VIVID HDR/CEC/HDCP2.2）+ CVBS 可切换
外设 PCIe 2.0、USB 3.0/2.0、RGMII、I2S、PDM、UART、I2C、PWM、SPI、SDMMC/SDIO
安全 TrustZone、硬件加密引擎、RNG、防火墙

2.2 两个必须知道的限制

  1. RK3528A 没有独立 NPU。AI 识别能力靠 CPU 量化推理（或 GPU OpenCL、或外接算力模块），选型时别按 RK3568/3576 的 NPU 思路规划。
  2. 内存只有 1.5GB（非主流 2GB），多路并发解码时要按帧缓冲精打细算，详见第九节。

三、系统与驱动底座

本项目采用的系统底座（均为 【实测】 环境）：

项目 版本/状态
系统 Armbian Ubuntu 24.04（aarch64）
内核 Linux 6.1.115-vendor-rk35xx
DRM rockchip-drm + VOP2 + dwhdmi，HDMI-A-1 @1920×1080@60（CRTC 89 / connector 138）
GPU 驱动 lima（Mali-450），GLES 2.0 可用，用户态 GBM/EGL surfaceless 上下文
RGA 驱动 librga（IM2D API），RGA2 核心，dma-buf 零拷贝
MPP rockchip_mpp，/dev/mpp_service 就位，VPU 电源域在线
设备树 mpp-srv / rkvdec / rkvenc / vdpu / avsd_plus / jpegd / iep 全部 okay（overlay 持久化）

出厂镜像默认关闭了 GPU/RGA/MPP 集群，需要通过设备树 overlay 启用（user_overlays 机制 + boot.cmd 兜底），这是通用玩法，本文不展开，改完 status=okay 后全部模块随驱动 probe 正常加载。

四、硬件编解码器（MPP/VPU）实测

4.1 编解码能力矩阵（【实测】）

通过标准 MPP API 对每类编解码器做 mpp_init 探测：

类型 初始化结果 说明
硬件解码器 9/10 成功 仅 AV1 解码返回不支持
硬件编码器 3/4 成功 仅 VP8 编码返回不支持
H.264 / H.265 编解码 ✅ 全部成功 直播链路主力
JPEG / MJPEG ✅ 成功 抓拍、缩略图

结合实际链路，直播场景用到的 H.264 编、H.265 编/H.264 解全部可用；AV1/VP8 本来也不是监控/直播的主流码流。

4.2 官方能力上限（datasheet）

能力 上限
解码 H.265/H.264/AVS2/VP9，最高 4K@60fps 10-bit
编码 H.265/H.264，最高 1080p@60fps

对直播盒子而言 1080p60 编码上限完全够用；4K 解码能力还能兼顾信息发布/IPTV 场景。

4.3 ⚠️ 实测踩坑：MPP 用户态与内核 ABI 错配（重点）

在 Armbian 官方镜像上做端到端解码实测时，发现一个镜像打包层面的坑，CSDN 读者大概率也会遇到，如实记录：

探针 观察到的现象
内核侧 mpp_service 打印 unknown mpp version for missing VCS info
用户态 librockchip_mpp.so 打印 ioctl version 0x1，与内核 0x0 不一致
/proc/mpp_service 内容为空
端到端解码 task 异步流程缓冲 6 帧输入后停滞、零输出，内核 dmesg 无报错

根因 ：内核 mpp_service 与 librockchip_mpp.so 来自不同 vendor 快照（两者都缺失 VCS 版本串），ioctl 接口版本 v0/v1 错配，导致 VPU 任务实际不执行。

结论 ：这是固件打包问题，不是芯片能力问题 。解决办法：从内核同源的 SDK/镜像中提取匹配版本的 librockchip_mpp.so.0 替换即可恢复硬件编解码（-rockchip 各版本 SDK 均自带）。本文后续性能数据按"MPP 对齐后"给出参考。

4.4 RTMP 推流代码骨架

硬件编码 + RTMP 推流的核心调用（librtmp）：

c 复制代码 
/* 1. MPP 初始化（H.264 编码器） */
MppCtx ctx; MppApi *mpi; MppEncCfg cfg;
mpp_create(&ctx, &mpi);
mpi->control(ctx, MPP_ENC_GET_CFG, &cfg);
mpp_enc_cfg_set_s32(cfg, "width",  1920);
mpp_enc_cfg_set_s32(cfg, "height", 1080);
mpp_enc_cfg_set_s32(cfg, "bps",    4 * 1000 * 1000);  // 4Mbps
mpp_enc_cfg_set_s32(cfg, "fps_in", 30);
mpi->control(ctx, MPP_ENC_SET_CFG, cfg);

/* 2. 关键：零拷贝。编码器输出直接来自 NV12 dma-buf 帧 */
mpp_buffer_group_get(...);  // EXT_DMA buffer group
MppFrame frm; mpp_frame_init(&frm);
mpp_frame_set_buffer(frm, dma_buf);   // V4L2/RGA/GL 导出的 fd

/* 3. 编码 -> 取包 -> RTMP 发送 */
MppPacket pkt;
mpi->encode(ctx, frm, &pkt);          // 同步编码
if (pkt) {
    uint8_t *data = (uint8_t *)mpp_packet_get_data(pkt);
    size_t    len  = mpp_packet_get_length(pkt);
    bool      key  = mpp_packet_get_eof(pkt) || mpp_packet_is_partition(pkt);

    RTMPPacket rtmp_pkt = {0};
    RTMPPacket_Alloc(&rtmp_pkt, len);
    memcpy(rtmp_pkt.m_body, data, len);
    rtmp_pkt.m_nBodySize     = len;
    rtmp_pkt.m_packetType    = RTMP_PACKET_TYPE_VIDEO;
    rtmp_pkt.m_nTimeStamp    = pts_ms;
    rtmp_pkt.m_headerType    = key ? RTMP_PACKET_SIZE_LARGE : RTMP_PACKET_SIZE_MEDIUM;
    RTMP_SendPacket(rtmp, &rtmp_pkt, 0);   // 推流到 阿里云/腾讯云/快手...
    RTMPPacket_Free(&rtmp_pkt);
    mpp_packet_deinit(&pkt);
}

要点：编码器输入帧用 dma-buf（V4L2 采集或 GL/RGA 导出的 fd），全链路零拷贝，CPU 不参与像素搬运------这是低配 SoC 跑直播的关键。

五、流媒体协议矩阵：推流 + 拉流全覆盖

5.1 协议方向矩阵

协议 推流 拉流 典型端到端延迟 典型用途
RTMP ✅ ✅ 1--3s 推流到各大直播云/平台（主流）
HTTP-FLV --- ✅ 1--3s 网页低延迟播放，Flash 遗产但直播仍广用
HLS (m3u8) --- ✅ 5--10s 微信/浏览器兼容播放、自适应码率
RTSP ✅（少用） ✅ <1s（局域网） 摄像头/NVR/IPC 拉流，监控标准
WebRTC ✅ ✅ <500ms 超低延迟互动（连麦、云游戏）
SRT ✅ ✅ <1s 弱网/跨网远距离传输
GB28181 ✅ ✅ 1--3s 国标监控平台上云
RTMP/HLS 本地录制 ✅ --- --- eMMC 本地落盘 mp4/ts

延迟为工程参考值，随网络环境/码率/CDN 变化。

5.2 板载流媒体服务器

三种负载可自由组合（均交叉编译 aarch64 即可运行）：

软件 定位 适用
SRS 功能最全的单机流媒体服务器（RTMP/WebRTC/HLS/GB28181） 一体机推拉流中枢
mediamtx（原 rtsp-simple-server） 轻量零配置多协议网关 RTSP/RTMP/WebRTC 互通
LiveGo 纯 Go 极轻量 RTMP/HTTP-FLV/HLS 资源紧张场景

实测建议：8GB eMMC + 1.5GB 内存下，SRS 单进程可稳定承担 1 路 1080p30 推流 + 多路拉流转发；纯拉流分发（不解码、直接转发）内存占用极低。

5.3 全链路拓扑

复制代码 
 ┌──────────── 输入侧 ────────────┐        ┌──────────── 处理层（全部硬件加速）────────────┐
 │ USB/UVC 摄像头 │ CSI 摄像头    │        │                                            │
 │ 网络拉流(RTSP)  │ HDML 环出     │───────►│  特效合成层：OpenGL 绿幕/字幕/台标/AI叠加   │
 └────────────────────────────────┘        │      + RGA 缩放/旋转/水印（227fps 实测）     │
                                           └───────────────────┬────────────────────────┘
                                                               ▼
                                          MPP 硬件编码器：H.264/H.265 1080p30
                                                               │
                     ┌─────────────────────────────────────────┼──────────────────────┐
                     ▼                         ▼               ▼                      ▼
              RTMP/SRT/GB28181            WebRTC(WHEP)     HTTP-FLV/HLS         本地录制(eMMC)
                 直播云/私有服务器          <500ms互动      网页/微信播放          mp4/ts

六、Web 功能

功能 实现 说明
Web 服务器 Nginx / Caddy / 自研 Go/C++ 服务 1.5G 内存下静态页 + 反向代理无压力
低延迟播放页 HTTP-FLV（flv.js）/ WebRTC（WHEP） 浏览器即开即播
HLS 播放页 hls.js 兼容微信/移动端
管理配置页 Web 前端 + REST API 推流地址、码率/帧率、通道、字幕等参数在线改
状态监控 WebSocket 上报 码率、帧率、编码队列、温度、CPU/内存占用
本地录制管理 自研服务 8GB eMMC 存放 mp4/ts，Web 端回放下载
OTA/日志 Web 端点 远程升级与故障排查

要点：管理页面一定要热更新配置（改码率即时生效、不重启推流），直播现场没有人等你 reboot。

七、AI 识别功能

RK3528A 没有 NPU，但**"RGA 前处理 + CPU 量化推理 + 硬件编解码后处理"**的组合拳，足以撑起主流轻量 AI 场景：

7.1 推理性能（A53@2GHz，INT8 量化，参考值 + 本板实测数据混合）

模型（ncnn/MNN） 输入 帧率（参考值） 典型场景
YOLOv5s / YOLO11n 640×640 8--12 fps 通用目标检测（人/车/物）
MobileNet-SSD v2 300×300 18--25 fps 轻量检测框
人脸检测 + 106 关键点 320×320 20--30 fps 人脸抓拍、美颜锚点
NanoDet-Plus 320×320 15--20 fps 端侧实时检测

【实测】RGA 前处理 1080p→320/640 缩放 + NV12→RGB 转换：227fps，CPU 占用仅 ~4.7%------AI 链路的图像预处理完全由 RGA 承包，不挤占推理 CPU。

7.2 AI 后处理叠加

检测框/标签/电子围栏/告警截图，同样走硬件：小尺寸框线用 RGA 水印合成 （全屏负载 <5%），大画面重合成用 OpenGL 图层，一路都不占用编码/推流资源。

7.3 标准 AI 流水线

复制代码 
VPU 硬解(拉流)/ V4L2 采集 ──► RGA 前处理(227fps 实测) ──► CPU/GPU 量化推理
                                                              │
                        ┌─────────────────────────────────────┤
                        ▼                                     ▼
               GL/RGA 叠加检测框+字幕                    WebSocket 告警/抓拍上传
                        │
                        ▼
              VOP2/HDMI 本地显示  +  MPP 硬编 ──► 推流（带 AI 框的实时画面）

需要更高算力时，可通过 PCIe 2.0 / USB 3.0 外接 AI 加速模块升级，CPU 推理部分无侵入。

八、特效与 OpenGL 绿幕

8.1 OpenGL 渲染能力（【实测】）

链路 帧率（1080p） 说明
GL 合成管线（NV12→RGB 着色器 + 多图层 + PageFlip 双缓冲） 38fps Mali-450 + lima 驱动，全 GPU 合成
VOP2 硬件直通（--mode hw） 60fps 不经 GPU，VOP2 直出，零合成场景

lima 驱动对应 Mali-450，API 上限是 GLES 2.0（datasheet：GLES 1.1/2.0 + OpenVG 1.1），特效着色器按 GLES2 精度写，别用 ES 3.x 特性。

8.2 绿幕（色度抠像）算法与着色器

直播一体机/虚拟直播间核心：把绿幕实时替换成任意背景。在 GLES2 里一个 fragment shader 即可完成：

glsl 复制代码 
precision mediump float;
varying vec2 vTex;
uniform sampler2D uY, uUV;      // NV12 双平面（前景）
uniform sampler2D uBg;          // 背景层（图片/视频/另一路流）
uniform vec3  uKeyColor;        // 绿色幕布采样值，如 vec3(0.0, 1.0, 0.0)
uniform float uTol;             // 主阈值 ~0.35
uniform float uSoft;            // 边缘软化 ~0.15
uniform float uDespill;         // 去溢色 ~0.5

vec3 yuv2rgb(float y, float u, float v) {
    return mat3(1.0, 1.0, 1.0,
                0.0, -0.344, 1.772,
                1.402, -0.714, 0.0) * vec3(y - 0.0625, u - 0.5, v - 0.5);
}

void main() {
    float y  = texture2D(uY,  vTex).r;
    vec2  cr = texture2D(uUV, vTex).ra - 0.5;
    vec3  rgb = yuv2rgb(y, cr.x, cr.y);

    // 1) 色度距离抠像
    float d   = distance(normalize(rgb), normalize(uKeyColor));
    float a   = smoothstep(uTol - uSoft, uTol, d);   // 0=背景(抠掉) 1=前景

    // 2) 去溢色：前景里残留的绿色压回去
    rgb.g += uDespill * (1.0 - a) * max(0.0, rgb.r > rgb.b ? rgb.r - rgb.b : 0.0);

    // 3) 输出：背景层(可换图片/视频/另一路画面) x (1-a) + 前景 x a
    vec3 bg = texture2D(uBg, vTex).rgb;
    gl_FragColor = vec4(mix(bg, rgb, a), 1.0);
}

工程要点（【实测】 经验）：

  1. NV12 直接采样：摄像头/解码器输出 NV12 dma-buf 直接绑 EGLImage，不做一次 RGB 预转换------省一趟全屏内存搬运；
  2. 键色阈值分区：远镜头（全身）用大阈值，近景口播收紧阈值并加大去溢色，避免把主播脸色一同抠掉；
  3. 绿幕打光 > 算法：再成熟的抠像算法也救不了不均匀的绿幕打光，先把灯光布均匀，算法只是兜底；
  4. 双缓冲 PageFlip对齐 HDMI 60Hz，撕裂问题直接消失（我们 38fps 实测无撕裂）。

8.3 特效能力清单

特效 实现 性能
绿幕/蓝幕抠像 GL 着色器 含在 38fps 全合成内
背景替换（图/视频/另一路流） GL 多图层 同上
画中画（PIP） GL 图层 + scissor 同上
台标/水印/滚动字幕 GL 贴图或 RGA 水印 RGA 全屏 <5% CPU
边框/圆角/阴影/转场 GL 几何 同上
图像缩放/旋转/格式转换 RGA2 IM2D 227fps（实测）
对比度/亮度/锐化 RGA imattrAttrs 随转换零成本

九、全链路性能汇总

9.1 直播链路延迟预算（1080p30 / H.264 / RTMP，参考值）

环节 耗时
摄像头采集（UVC） 30--60ms
GL/RGA 前处理 + 特效合成 10--20ms（RGA 227fps 实测单次 <5ms）
MPP 硬件编码（帧级） ~33ms（帧率型，1 帧间隔）
RTMP 推流网络 150--300ms（公网）
CDN/直播云分发 500ms--1s
播放器缓冲 0.5--1s
端到端合计 约 1--2.5s
WebRTC 互动链路合计 300--500ms

9.2 资源占用（1.5G 内存 / 8G eMMC 实测规划）

场景 CPU 占用 内存估算 结论
单路 1080p30 硬编 + RTMP 推流 主进程跑协议栈和业务，<30%（硬编零像素 CPU） 系统 ~300MB + 编解码缓冲 ~80MB 稳
RGA 全屏格式转换 4.7%（实测） --- 零感
GL 全合成特效 38fps GPU 承担，CPU 只做提交 ~100MB 稳
并发解码 4--6 路 1080p（每路 DPB≈12 帧≈50--70MB） <50% 300--450MB 1.5G 内存上限内可行
8 路以上并发解码 --- 突破 1G 缓存区 建议降 720p 或加 swap/zram

每路 1080p 帧缓冲 = 1920×1080×1.5 ≈ 3MB，DPB（参考帧缓冲，H.264 level 4.1 为 12 帧）+ MPP 内部缓冲按 50--70MB/路上限估算，属于设计推导值，请以自己板子 free -m 实测为准。

9.3 关键性能指标一览（重点数据表）

指标 数值 类型
GL 全合成特效帧率（1080p） 38fps 【实测】
VOP2 硬件直通帧率（1080p） 60fps 【实测】
RGA 图像转换吞吐 227fps，CPU 4.7% 【实测】
VPU 解码器初始化 9/10 成功（仅 AV1 不支持） 【实测】
VPU 编码器初始化 3/4 成功（仅 VP8 不支持） 【实测】
硬件编码上限（H.265/H.264） 1080p@60fps 规格
硬件解码上限 4K@60fps 10-bit 规格
RTMP 端到端延迟 1--2.5s 参考
WebRTC 端到端延迟 300--500ms 参考
AI 检测帧率（YOLOv5s-n, 640） 8--12fps 参考

十、避坑指南

10.1 MPP 用户态/内核 ABI 错配（最值得注意）

Armbian 官方镜像的 librockchip_mpp.so 与内核 mpp_service 版本不同源（ioctl v1 vs v0，双方都报 missing VCS info），直接跑硬件编解码会静默停滞 。解决：用内核 SDK 同源的 librockchip_mpp.so.0 整体替换，替换后硬件编解码即恢复正常。详见第四节实测记录。

10.2 /dev/mpp_service 权限

默认 root:root 0600，非 root 服务调用会 EACCES。加 udev 规则：

bash 复制代码 
echo 'KERNEL=="mpp_service", MODE="0666"' > /etc/udev/rules.d/99-mpp.rules

10.3 内存规划

1.5GB 是硬约束：多路并发解码按 50--70MB/路精算 DPB，超出要么降分辨率要么开 zram。

10.4 GPU API 天花板

Mali-450 + lima = GLES 2.0 封顶，特效 shader 别写 ES 3.x；需要 compute 风格的处理走 RGA 而不是 GPU。

10.5 eMMC 8GB 规划

系统（~2GB）+ 日志 + 录制文件要留余量：日志滚动切割、录像按时长/容量轮转，别把根分区写满------eMMC 写满会变砖级卡顿。

10.6 设备树 overlay 持久化

GPU/RGA/MPP 启用 overlay 后，务必写入 armbianEnv.txt 的 user_overlays 并加 boot.cmd 兜底，否则一次升级全部打回原形。

十一、适用场景与成本对比

11.1 适用场景

场景 用到的能力组合
直播一体机 / 绿幕虚拟直播间 GL 绿幕 + 硬编 + RTMP/WebRTC
多路监控拉流转发盒 多路硬解 + RTSP/RTMP/HLS 分发
会议/教育推流终端 特效字幕 + GB28181/RTMP + Web 管理
AI 摄像机（人数/安全帽/入侵） RGA 前处理 + 量化推理 + 告警上报
信息发布/IPTV 盒子 4K 硬解 + HDMI 2.0 + Web 播放
庭审/庭审直播推流 多路字幕 + 本地录制 + 推流云端

11.2 成本对比（整机 BOM 视角，参考）

平台 视频能力 典型功耗 板卡成本量级
RK3518（本文） 1080p60 编 + 4K 解 低（<10W） 百元级
x86 N100 小主机 强（软编依赖） 15--35W 千元级
RK3568/RK3576 强（4K 编/NPU） 中 数百元级

结论：在"1080p 直播推拉流"这个最主流的带宽/画质平衡点上，RK3518 是性价比最优解之一。

十二、总结

RK3518（RK3528A）用一颗没有 NPU、GPU 只有 GLES2.0、内存 1.5GB 的低成本芯片，把直播推拉流的每一环都用硬件引擎兜住：

  • VPU：H.264/H.265 1080p60 编、4K 解（实测 9/10 解码、3/4 编码初始化成功，仅 AV1/VP8 不支持）；
  • RGA2： 全屏转换，CPU 只吃 4.7%------AI 前处理、水印、缩放全包；
  • Mali-450： 全合成特效，绿幕/字幕/PIP 一个 shader 体系解决；
  • VOP2：60fps 直通兜底；
  • 协议栈：RTMP/RTSP/HLS/FLV/WebRTC/SRT/GB28181 全方向覆盖，端到端 1--2.5s（WebRTC 300--500ms）；
  • 成本：百元级板卡做到专业直播盒子功能闭环。

唯一需要注意的是 Armbian 官方镜像的 MPP ABI 错配坑 （换 SDK 同源 librockchip_mpp 即可），以及 1.5GB 内存对并发路数的约束------两者都有明确的工程解法。

后续会继续分享 MP4 解封装硬解、WebRTC 低延迟互通、AI 告警联动的完整开源工程，欢迎关注。

相关推荐
大模型真好玩1 小时前
初试短视频生成：豆包将我梦中的场景画出来了~
人工智能·agent·deepseek
梦想出海-Phoebe2 小时前
AI Agent能实现自主复制吗？Anthropic研究揭示模型部署与IoT设备安全问题
人工智能·物联网·安全
指针向南2 小时前
PDF转长图用什么？3种方法实测（2026）
图像处理·人工智能·计算机视觉·pdf
郝学胜-神的一滴2 小时前
AI 编程智能体 09：零门槛调用教程
人工智能·数据分析·自动化·numpy·pandas·量化投资
商业看点解说2 小时前
支持私有化部署的 AI 助手有哪些？把“私有化“拆成四层，排除一类常被错放的产品
大数据·人工智能
清华kenny2 小时前
安徽晓得养HIS系统适合哪类健康机构升级使用
大数据·人工智能·安徽晓得养
kyriewen2 小时前
我抽查了 6 万个 Skills：前排没几个真货
人工智能·程序员·ai编程
掘金酱3 小时前
【10.24 特别活动】AI 时代，程序员的新饭碗在哪里？
前端·人工智能·后端
PNP Robotics3 小时前
【PNP机器人具身分享】GPT-6 Astra 作为原生机器人策略的实证研究，NVIDIA Astranomy 揭示具身智能的新路径
人工智能
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02如何新建文件夹？ 电脑新建文件夹的4种方法03历年考研数学一、数学二、数学三真题试卷及答案PDF04GitHub 镜像站点05几个好用的ip纯净度检测网站06乙二醇水溶液物性参数07「全语录+省流版」邵艾伦 × 孙宇晨：聊风口、聊个人IP、聊年轻人如何抓住 AI 时代的机会08昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战09苹果iPA游戏软件资源下载网站10Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）