深度解读 · 约 4 分钟阅读
苹果解释MLX与RDMA如何把大模型推理分到多台Mac
10月15日工程文章区分内存容量、提示预填充与解码；四机结果不是普遍速度或功耗承诺。
- 原文发布
- 本站发布
- 核实时间
苹果10月15日技术文章展示MLX结合统一内存与雷雳RDMA，在多台Mac Studio上推理。代表结果是四台M5 Ultra、8192词元上下文下，Muse Spark Open每秒生成36.73词元。这是特定本地基准，不是示例模型新发布、云端订阅或所有代理工作负载的保证。
听读资讯
朗读当前文章，或连续收听资讯。
正在准备听读…
设备语音
朗读由浏览器或设备处理，AISubHub 不向音频 API 发送文本。可用语音及锁屏播放能力因设备而异。
继续播放时可能重复一小段。
一分钟速览
- Muse Spark Open总参数816B、激活42B，NVFP4将模型占用降至约493GB，但中间计算仍使它装不进单台512GB机器。
- 流水线并行按深度拆层，张量并行按宽度拆每一层，后者需要频繁低延迟通信。
- 最高4.6倍TTFT改善指Qwen和Mistral的单台M5对M3，不是Muse与不存在的单机基线相比。
装得下与跑得快是两道题
苹果用mlx_lm.benchmark，批量为1，在8192或65536词元上下文后生成128词元，分别测首词元时间、解码吞吐和峰值功耗。Muse使用NVFP4，Mistral Medium 3.5用FP8，Qwen 3.8用BF16。总参数与激活参数不能混为一谈：混合专家减少计算，不代表只需装载激活权重。Muse原生BF16仅权重就超过1.6TB，量化后约493GB加上中间计算也超过单机512GB可用空间。分布式首先解决容量，不自动等于生成更快。
流水线与张量拆分分别改变什么
双机流水线让一台算前半层、另一台算后半层。解码仍基本串行，对本来能装下的模型通常不会明显加速；长上下文预填充可以把分块在不同阶段重叠。张量并行则把每层分给多机同时算，但增加大量小广播与聚合。文章环境为macOS 26.2的雷雳5 RDMA、MLX 0.30.1及以上的jaccl后端，每对机器用两根线。示例快速CPU—GPU同步开关仍为实验功能，不是所有环境自动启用的默认能力。
必须带着正确基线读性能
可见8192词元表中，Muse双机流水线解码为15.74词元/秒，双机张量24.99，四机张量36.73；不能改写为对单机的提升。最高4.6倍首词元、约1.6倍解码改善属于Qwen和Mistral单M5与M3比较。张量也不总占优：65536词元时，Muse双机张量预填充因专家输出归一化的通信而落后双机流水线，四机才改善取舍。另一个明确的四机长上下文实验中，每链路双线将首词元时间从约50.5秒降至40.6秒，不能省掉上下文和拓扑条件。
本地代理仍要做系统层评估
文章给出启动和本地服务配置，可接代理编码客户端。这说明配置路径，不代表已测所有工具流程、并发和回答质量需求。约200W的M3与300W的M5峰值来自单机测试，不是四机集群总功耗。本站分析认为，部署应分开判断权重能否装载、提示处理延迟、输出速度与网络要求。多机可能解锁更大模型，但通信占主导时不会按机器数等比例加速。硬件成本、全系统能耗和并发服务可靠性仍需独立评估。
有什么影响
有用进展是提供从单机内存限制到多机本地推理的工程路线，并明确容量与延迟的取舍，便于规划私有实验。本站未运行基准、购买或配置集群、启动所给服务或测量生产代理性能。
限制与可用性
本站完整读苹果工程文章及其默认可见表格，不是独立复现。模型格式、上下文、生成长度、软件和线缆都影响结果；示例模型基准不应写成模型首发、质量排名、订阅权益或整个集群能耗结论。
来源与证据
原文发布: 2026年10月15日 · 核实时间: 2026年10月20日
AI 辅助采编，依据所列一手来源核实。厂商自报结论注明归属，收录不代表背书。