SiliconBench：本地大模型服务不能只看速度

导语

在 Apple Silicon 桌面上运行本地大模型，速度往往是最容易被展示的指标：每秒生成多少 token、并发数提高后吞吐增加多少。但对聊天机器人或智能体服务而言，系统是否会因 KV cache 和并发请求挤占统一内存、输出质量是否发生回退，同样决定了它能否真正投入使用。论文《SiliconBench》试图把这些容易被速度排行榜忽略的问题放到同一张成绩单上。

核心要点

• 三维评测而非单一测速。 SiliconBench 从速度、内存和保真度三个维度考察 Apple Silicon 上的 9 款服务引擎，包括 vllm-metal、omlx、llama.cpp、Ollama、mlx_lm、vllm-mlx、SGLang、Transformers 和 mistral.rs；同时以 DGX Spark 上的 vLLM、SGLang 与 llama.cpp 提供补充参考。
• 并发能力取决于服务架构。 在 Qwen3-0.6B 测试中，vllm-metal 在并发从 1 提升到 16 时，聊天和智能体工作负载的吞吐均增长超过一倍。不过，在相同提示下，CUDA 版 vLLM 与 SGLang 展现出更强的并发扩展能力，说明硬件平台与调度实现仍然会显著影响结果。
• 内存预算不等于安全余量。 有两套系统虽然完成了全部请求，但内存占用已经逼近物理容量，随后吞吐出现下降。对统一内存设备来说，标注一个上限并不能自动解决模型权重、缓存和并发请求之间的竞争。
• 兼容性也是生产力指标。 较新的 Qwen3.5 和 Gemma 4 架构获得的引擎支持更窄。经过评测的实现与 NVIDIA 参考结果保持一致，但只有 3 套栈同时满足请求完成、输出保真度和模型覆盖这三个门槛。
• 首 token 延迟不能被平均吞吐掩盖。 在更大的稠密模型和 MoE 模型上，vllm-metal 的打包式 prefill-decode 路径在并发负载下保持了比 omlx 更低的首 token 延迟，凸显了将提示处理与持续生成协调调度的重要性。
• 多机扩展依赖通信方式。 在论文测试的双机配置中，经 Thunderbolt RDMA 的张量并行能够扩展；而经 TCP 的流水线并行则出现性能回退。

意义与影响

这项工作并没有给出一个脱离场景的“最佳引擎”，而是提醒使用者重新定义本地推理的比较方法。若只是单请求测速，某个后端的优势可能很明显；但当设备需要同时处理聊天、工具调用或智能体任务时，内存余量、首 token 延迟、模型覆盖范围和质量一致性都必须纳入决策。

对引擎开发者而言，重点也不只是继续压低单流延迟，还包括更成熟的 prefill-decode 调度、可观测的内存管理以及跨节点通信支持。对用户而言，SiliconBench 更适合作为选型清单：先确认模型能否运行，再检查并发时是否留有内存余量，最后用任务级质量测试验证输出是否可靠。

Hugging Face Daily Papers