当GPU与CPU焊死在一起，边缘智能的算力范式正在被重新定义

当一台重量不到2公斤的笔记本能够流畅运行120B参数的大模型，我们是否还需要将每一次推理请求都发送到云端？RTX Spark在Bilibili World上的真机亮相，直接把这个问号拉直了——它不再是纸上谈兵的概念，而是一块焊死了CPU与GPU的“超级芯片”，正在撬动整个AI边缘计算的底层逻辑。

[!tip] 核心观点
RTX Spark的核心突破不在于算力数字的堆砌，而在于通过物理集成彻底消除了CPU与GPU之间的数据搬运瓶颈，使得大模型推理的真正瓶颈从“算力不够”转向了“内存带宽与延迟”。

从技术架构上看，NVIDIA这次的做法远不止是“把两块芯片封装在一起”那么简单。传统的CPU+GPU分立方案，即使通过PCIe 5.0或NVLink桥接，跨芯片数据传输的延迟依然在微秒级，且带宽受限于接口协议。而RTX Spark采用了统一的共享内存池设计，CPU与GPU之间通过高速的片上互联实现数据一致性——这意味着模型参数、中间激活值、甚至推理过程中的KV cache都可以在两者之间无缝迁移，无需经过显存与系统内存之间的拷贝。

[!success] 关键数据
120B参数模型在笔记本上的推理，如果采用传统方案，仅模型权重就需要约60GB显存（FP16），而RTX Spark通过统一内存架构，将系统内存与显存合并视为一个逻辑池，让模型参数常驻于大容量系统内存，推理时按需调度到GPU计算单元，有效避免了大模型对显存容量的刚性需求。

这种设计思路，透露出NVIDIA对“物理AI”部署场景的深刻理解。人形机器人、自动驾驶、工业检测等场景，对推理延迟的要求是毫秒级甚至亚毫秒级，且必须本地完成，无法容忍云端的网络抖动。但传统边缘设备往往受限于功耗和散热，难以承载大模型。RTX Spark的“焊死”方案，本质上是在功耗约束下做了一次极致的内存带宽优化——通过将CPU与GPU的物理距离缩短到芯片级，降低数据搬运的能耗和延迟，从而在40W左右的功耗下实现了此前需要服务器级GPU才能完成的推理任务。

[!example] 具体场景
想象一个在物流仓库中运行的人形机器人，需要实时理解自然语言指令并规划抓取路径。如果使用RTX Spark，机器人本体即可运行一个70B的视觉-语言模型，无需通过无线网络向云端请求推理，响应时间从秒级降到毫秒级，且不会因为网络丢包或延迟波动而“死机”。

当然，这种“焊死”方案也带来了明显的trade-off。CPU和GPU的集成度越高，意味着用户无法单独升级其中任何一个部件，且整个模组的散热设计必须同时兼顾两种芯片的热特性。对于发烧友级别的DIY玩家来说，这可能是一个坏消息——他们失去了自由搭配的权利。但对于企业级部署和消费级产品而言，这种集成恰恰降低了系统工程的复杂度，让OEM厂商可以像设计游戏机一样设计AI笔记本，无需担心PCIe走线、内存兼容性等问题。

从产业生态的角度看，RTX Spark的出现可能加速“边缘大模型”的普及。目前，开发者在大模型应用部署时，往往需要权衡模型精度与设备算力，不得不使用量化、蒸馏等压缩技术。而有了RTX Spark，开发者可以直接在笔记本上运行120B的原始模型，调试和测试流程将大幅简化，进而推动更多基于本地大模型的创新应用落地。尤其对于物理AI领域，机器人开发者可以在真实环境中实时调试视觉-语言模型，无需频繁上传数据到云端，这既保护了数据隐私，也提升了迭代效率。

[!note] 背景信息
在ComputeX上，老黄曾强调Project Digits（即RTX Spark的开发代号）面向的是“AI研究者和开发者社区”，而非普通消费者。Bilibili World上的真机演示进一步印证了这一点：现场展示的120B模型推理，使用的是Llama 3.1 120B，这恰是当前开源社区最主流的大模型之一，开发者可以立即上手，无需专门适配。

但我们需要警惕一个潜在误区：RTX Spark并非“万能钥匙”。120B模型在本地运行，推理速度是否达到可用水平？从公开信息看，演示中的吞吐量大约在每秒几到十几个token，远不如云端H100集群的数百token。对于对话式应用，这个速度基本可用，但对于实时视频分析、高帧率机器人控制，可能仍然不够。所以，RTX Spark更适合的是“需要理解能力但不需要极致吞吐”的场景——比如智能助手、文档分析、代码生成、以及中等复杂度的机器人规划。

原文链接：老黄RTX Spark真机现身Bilibili World！CPU和GPU直接焊在一起，笔记本跑120B大模型 – 量子位