四台 Mac Studio 连在一起,跑一个 816B 参数的开源模型,速度 36.73 tok/s。这个数字放在本地推理的语境里,值得停下来看一眼。
![]()
苹果展示的这套系统,核心不是单机性能,而是把多台机器拼成一个统一的推理单元。参与测试的是四台 M5 Ultra Mac Studio,框架用的是 MLX,跑的模型叫 Muse Spark Open——参数总量 816B,活跃参数 42B,经 NVFP4 量化后权重约 493GB。
为什么非要四台?单台顶配 Mac Studio 的统一内存是 512GB,装不下完整模型加推理开销。这个缺口不是靠优化能补的,只能靠把模型拆到多台机器上。
拆法不同,结果差得不少。两台 Mac 走流水线并行,跑到 15.74 tps;两台 Mac 走张量并行,24.99 tps;四台 Mac 走张量并行,36.73 tps,首 token 延迟 4.8 秒。同样的硬件,并行策略一换,吞吐量几乎翻倍。
连接方式是这套方案里容易被忽略的一环。每对 Mac 之间用两根 Thunderbolt 数据线点对点直连,走的是 Thunderbolt 5 RDMA。没有交换机,没有专用互联硬件,靠的是消费级高带宽接口把多台机器粘成一个推理系统。
这里有个值得拆开看的对比。正方会说,这是本地运行前沿级模型的一次可行性验证——493GB 的量化权重、816B 的总参数量,过去这类模型基本只能在数据中心里跑,现在四台桌面级机器就能撑起来,首 token 4.8 秒也不是不能接受。
反方则会盯着另外几个数:36.73 tps 是四台顶配机器堆出来的,单台的成本摆在那里;活跃参数 42B 意味着每次推理实际调动的只是模型的一部分,总参数量大不等于计算量大;而 Thunderbolt 5 RDMA 的点对点拓扑,扩展到更多机器时会遇到什么,这套演示没有给出答案。
我的判断偏向前者,但限定条件要说清楚。这套方案证明的是「能跑」,不是「跑得划算」。它的价值在于把一条原本被内存容量卡死的路打通了——当单机内存成为硬约束时,用高带宽互联把多台机器的内存池化,是一条可走的路。
至于 36.73 tps 这个数字本身,它更像一个起点而非终点。并行策略从流水线换到张量、机器从两台加到四台,每一步都带来了实打实的吞吐提升,说明这套分布式推理的扩展曲线还没走平。
对关注本地部署的人来说,这次演示给出的信息很具体:模型规模、量化精度、权重体积、互联方式、不同并行策略下的吞吐和延迟,都是可复现的参数。剩下的问题是,这套配置在真实工作负载下能稳定跑多久。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.