SiliconBench: Speed, Memory, and Fidelity for LLM Serving on Unified-Memory Desktops
Ranran Haoran Zhang, Aysa Xuemo Fan, David Munhá Correia, Alex Cheema, Rui Zhang
cs.AR, cs.DC, eess.SY
2026-09-13
在64GB M5 Pro上对九个Apple Silicon推理栈做chat与agent并发审计,vllm-metal从并发1到16吞吐翻倍以上,只有llama.cpp、vllm-metal、omlx同时通过完成率、保真和覆盖三道门。
Mac 上跑本地 LLM 已经是日常:Ollama、llama.cpp、LM Studio 每年几十万次安装,mlxlm 每月 145 万次 PyPI 下载。统一内存把权重、KV cache、浏览器和 IDE 塞进同一池 RAM。只看单请求吞吐的排行榜会漏两件事:并发 4 到 16 路时代理请求会不会拖死调度,内存顶满以后前台应用还剩多少余量。同一套权重,不同引擎的任务分还可能对不齐 NVIDIA 参考实现。
现有消费级评测多半测一两个栈的速度。SiliconBench 把九个 Apple Silicon 引擎放进同一套 chat / agent 负载,再加内存轨迹和分类保真,DGX Spark 上的 CUDA 同胞当对照。
三道解读标准:架构是否跟得上新模型和并发(D1),统一内存上有没有纪律(D2),跨机扩展是否划算(D3)。
九个栈覆盖打包 vs 填充 batch、paged vs 连续 KV、prefill 与 decode 是否同一次前向、内存是硬帽还是 Metal 建议值:llama.cpp、ollama、mlxlm、vllm-metal、vllm-mlx、omlx、sglang、hftransformers、mistral.rs。
主测在一台 64GB M5 Pro、macOS 26.6 上跑 Qwen3-0.6B BF16,并发 1/8/16。Chat 来自 OpenOrca 和 CNN/DailyMail,agent 来自 BFCL v3、Hermes、ClawsBench,各 100 条;agent 上下文大约 0.3K–8.9K token。新架构用 Qwen3.5-0.8B 和 Gemma-4-E4B-it 探覆盖。保真是 GMRID 供应链事件八分类(N=1146)的加权 F1,对照 A100 上的 vLLM。大模型补测 4-bit 的 Qwen3.8-27B 和 Qwen3.6-35B-A3B。双机测 Qwen3.5-35B-A3B 8-bit,两台 64GB M4 Pro mini,Thunderbolt 5 RDMA。
维护节奏按两周一次快照设计:Claude Code 代理改适配器,人审再出正式数。早期一次 MLX 小版本升级同时打坏三个栈;ollama 用裸 GGUF 导入丢掉 ChatML 分隔符,分类解析失败约 92%。
Qwen3-0.6B 上,vllm-metal 与 hftransformers 都声称打包 query、paged KV、混合 step,chat 吞吐从 c=1 到 c=16 分别放大 3.65× 和 1.23×。vllm-metal 的 agent 放大 2.71×,也是唯一在两条负载上都超过 2× 的栈。填充或串行 prefill 的路径在 chat 的 c=16 要么增益不到 30%,要么回退或失败。Chat 的 c=16,vllm-metal 与 ollama 相差不到 1%;agent 上 vllm-metal 领先 32%,中位 TTFT 219ms。sglang 入队快(655ms),agent 吞吐从 80.6 掉到 45.3 tok/s。
九栈里六个在每个并发档、两条负载上都至少完成 90/100。mistral.rs 在 c=8 退化、c=16 崩溃;mlxlm 在 agent c=16 只剩 2/100;hftransformers 的 agent 跑不完 1 小时帽。新模型只有五栈能同时伺候 Qwen3.5 和 Gemma 4。
内存上,vllm-metal 的 agent 峰值大约 34.7–34.9GB 且几乎不随并发涨;llama.cpp 也平。ollama 从 c=1 起就占住 Metal 建议工作集的 94–97%。mistral.rs 在 agent c=8 摸到 59.3GB,只完成 13/100。sglang 和 vllm-mlx 声明了预算,600 个请求全完成,系统内存仍逼近物理容量,吞吐往下走。mlxlm 的 chat 占用几乎乘 3,吞吐只多 7%。填充示范更狠:30K+5K+10 token 三条并发,query/KV 有 61% 是 padding;32GB M1 Pro 触发页压缩,墙钟变 2.5 倍,64GB 上几乎无罚。
保真方面,八个 Qwen3-0.6B 栈里六个 0-shot/5-shot 都落在参考附近 1.5 个百分点内。ollama 的 0-shot F1 是 0.4173,贴近参考 0.4094,5-shot 只有 0.4462,别人到 0.73 一带,落后约 30 个百分点。vllm-mlx 的 0-shot 低 5.0 个百分点。新模型上测到的五栈都在 1.4 个百分点内。
双机 decode:单机 EXO 66.8 tok/s,mlxlm 49.3,llama.cpp 40.0。张量并行加 RDMA 后 EXO 到 87.0(1.30–1.37×),mlxlm 到 63.3(1.28–1.32×);llama.cpp 的 TCP 流水线并行掉到 32.4(0.80–0.84×)。
三道门(每档 ≥90/100 完成、保真落在参考带、三个模型都能跑)只有 llama.cpp、vllm-metal、omlx 全过。CUDA 上的 vLLM 和 SGLang 在同一 prompt 上放大 4.3–7.7×,TTFT 几乎不涨,说明 Metal 侧还有调度余量。
在 Mac 上选本地 serving,单看 tok/s 会把 ollama 和 vllm-metal 看成 chat 并列第一。加上 agent 并发、内存余量和 5-shot 模板,名单只剩三个能用的栈。声明了「显式内存预算」不等于系统内存受控;packed+paged+混合 step 也不等于并发能缩放,hftransformers 就是反例。
对做本地 agent 的人,这条更硬:prefill 必须和正在 decode 的请求挤在同一次前向里,否则长 prompt 的首 token 会在并发下炸掉。跨机不要默认流水线加 TCP,至少在这两台 mini 上它比单机慢。
主审计只有一台 M5 Pro,小模型扛覆盖。大模型和双机是后来的构建和不同量化,不能直接跟 0.6B 主表横比。保真只靠一个分类任务,没有给出多次运行方差。双机用的 35B MoE 单机就放得下,测的是互连效率,不是「单卡装不下才拆」。agent 负载最长大约 9K,没有测 10K+ 上下文或 1K+ 生成。mlxlm 的 70/100「失败」里有一部分是合法 tool call 被记成零 content,完成率口径会偏。
快照会过期。论文自己用维护代理扛这个,读者仍应按日期读,不要把 2026 年 8 月的门当成永久排名。