SiliconBench:统一内存桌面上的 LLM 服务速度、内存与保真度

TL;DR SiliconBench 以速度、内存、保真度三视角评估 Apple Silicon 统一内存桌面上的 LLM 服务引擎，揭示速度排名掩盖的内存余量不足与输出质量退化，并筛出少数通过全部门槛的栈。

问题

问题背景

当前 AI 行业关注在本地 / 边缘设备上高效部署大语言模型（LLM），尤其 Apple Silicon 这类 统一内存架构 桌面设备，因其高带宽共享内存和能效优势，成为个人与小型团队运行 agent 推理的候选平台。

现有方法局限

传统 LLM 推理基准（如仅测吞吐量 / 延迟）忽略两个关键维度：内存纪律 和 输出保真度。在统一内存系统中，系统内存与 GPU / NPU 共享物理内存，不合理的 KV cache 分配、padding 浪费、以及后端对内存 headroom 的粗放管理，会导致并发服务时内存逼近物理上限，吞吐量显著下降甚至请求失败。速度优先的排名还掩盖了模型输出质量回归：不同推理引擎的量化、注意力实现或 batching 策略可能引入数值偏差，缺少与 NVIDIA 参考实现对齐的保真度检查。

为什么这个问题难 / 重要

本地 LLM 服务（尤其 agent 场景）正从实验走向生产，需要支持并发请求、低 TTFT、稳定输出。Apple Silicon 的统一内存特性既带来机会（高容量共享内存适合大模型），也带来挑战（内存竞争直接影响服务可靠性）。业界缺少系统性评估框架，难以同时考察速度、内存纪律与保真度，开发者选型时容易选择“快但不稳”或“节省内存但精度受损”的引擎。此外，新模型架构（如 MLA、稀疏注意力）对引擎支持要求更高，进一步加剧选型困难。

行业类比

这类似在自动驾驶或实时推荐系统中，仅以推理吞吐量作为选型标准，却忽略端到端延迟抖动和模型精度漂移，最终导致线上服务可用性下降。

核心洞察

• SiliconBench 将内存纪律作为独立评估维度，揭示了速度基准中无法反映的内存余量问题。与以往仅关注吞吐和延迟的 LLM 服务基准不同，该工作测量并发负载下内存使用接近物理容量时吞吐的下降趋势，并发现显式内存预算并不能保证实际余量，两个被测堆栈在所有请求完成时内存已逼近极限。这一视角对统一内存桌面上的本地部署具有直接工程指导价值，因为内存耗尽会导致系统交换或服务质量骤降，而单纯的速度排名会掩盖这一风险。
• SiliconBench 引入输出保真度检查，通过分类任务与 NVIDIA 参考实现对比，以捕获量化、内核优化或新架构支持不足导致的质量回归。现有 LLM 服务基准通常只验证输出 token 匹配或基本格式，而该工作用任务准确率检测语义层面的漂移，对面向生产环境的本地推理尤其重要。此外，它发现较新的模型架构（Qwen3.5、Gemma 4）引擎支持较窄，但已评估的实现与参考保真度一致，这为选择引擎提供了除速度和内存之外的第三道门槛，推动更全面的工程决策。

方法

输入

SiliconBench 以 九款 Apple Silicon 推理引擎、三组模型（Qwen3、Qwen3.5、Gemma 4）以及 chat / agent 两类工作负载为评估对象。速度基准使用统一服务协议与并发请求；保真度评估采用分类任务数据集，比对 NVIDIA 参考输出；内存纪律则通过显式内存预算与运行时追踪观测。

关键模块

1. 速度评估：测量并发 1–16 下的吞吐与延迟，重点记录 first-token latency (TTFT) 和 decode throughput。引入 DGX Spark 上的 CUDA vLLM / SGLang 作为参考轨道，对比 Apple Silicon 栈的并发扩展能力。
2. 内存纪律评估：为每个引擎设置显式内存预算，跟踪内存占用接近物理容量时的 headroom 变化，记录请求完成后的内存保留与浪费（如 padded query、KV cache 超额分配）。
3. 保真度评估：在分类任务上将 Apple Silicon 引擎输出与 NVIDIA 参考逐项比对，检测量化、内核实现或调度策略导致的输出漂移。
4. 多节点扩展：测试两机配置下 Thunderbolt RDMA 上的张量并行与 TCP 上的流水线并行，量化 decode 吞吐的 scaling 行为。
5. 维护工作流：结合 bounded agent fixes 与人工审查，处理共享依赖引发的关联故障，保证基准的可复现性与持续更新。

输出

每个引擎在三个维度上的量化结果，以及通过完成、保真、模型覆盖三个门控的栈列表。同时发布基准代码、逐次运行结果和维护日志。

与同类方法的差异点：SiliconBench 将内存 headroom 与输出保真度提升为与速度并列的一等公民，并纳入多节点 scaling 与可持续维护流程，而非仅报告吞吐排名。

实验

实验设计

基准覆盖 Qwen3、Qwen3.5、Gemma 4 三个模型家族，在 Apple Silicon 统一内存桌面 上评测 9 个推理引擎，同时以 DGX Spark 作为互补性能基准。工作负载分 chat 与 agent 两类，分别记录吞吐、延迟、内存占用与输出保真度。保真度通过与 NVIDIA 参考实现做分类任务对比来衡量。

关键发现

• Qwen3-0.6B 上， vllm-metal 在并发 1→16 时吞吐提升超过 100%；CUDA vLLM 与 SGLang 扩展更强。
• 显式内存预算不能保证余量：两个引擎栈在逼近物理内存上限时仍能完成请求，但吞吐已下降。
• 仅有 3/9 引擎栈通过完成率、保真度、模型覆盖三重门槛。
• vllm-metal 的 packed prefill-decode 路径在并发负载下首 token 延迟低于 omlx。
• 双机配置中， Thunderbolt RDMA 张量并行 扩展，而 TCP 流水线并行 退化。

与基线对比

速度单项排名掩盖内存与保真度风险。本工作把 memory discipline 和 fidelity 纳入硬性门槛后，合格栈从速度榜单上的多数缩至 3 个。 vllm-metal 在 Apple Silicon 上通过打包 prefill/decode 避免了 omlx 的调度空泡，证明本地桌面 LLM serving 需要针对统一内存架构重排批处理，而非照搬 CUDA 路径。

行业影响

落地场景

SiliconBench 面向在 Apple Silicon 桌面或工作站上部署本地 LLM 服务的团队，典型场景包括：

• 离线 AI 助手：个人开发者或小型团队在 Mac 上运行聊天、代码生成模型，如 Qwen3 系列。
• 边缘内容处理：内容平台在本地设备上执行实时文本分类、摘要或敏感信息过滤，避免上传数据。
• 私有化知识库问答：企业使用统一内存工作站运行 RAG 服务，要求低延迟和高吞吐。

这些场景中，内存余量与输出保真度直接影响服务稳定性，仅看速度排名会忽略关键风险。

商业价值

通过基准筛选出的高效引擎（如 vllm-metal 在 Qwen3-0.6B 上并发吞吐翻倍），企业可减少云 GPU 租用成本，将推理迁移到本地硬件。同时，fidelity 检查确保输出与 NVIDIA 参考一致，避免因引擎实现差异导致质量回归，从而提升用户信任和产品可靠性。Memory discipline 分析揭示显式内存预算并不保证余量，帮助规避内存耗尽引发的吞吐骤降，保障服务 SLA。

跟现有产品/工作流的接口

可将 SiliconBench 集成到 CI/CD 流程中，作为新硬件或模型发布前的引擎选型验证工具。基准代码已开源（GitHub），其测试负载、度量方法及维护日志可直接复用。对于使用 vLLM / SGLang / MLX 的技术栈，可对照基准结果调整调度策略（如 packed prefill-decode）或并行方案（如 Thunderbolt RDMA vs TCP）。DGX Spark 参考轨道提供跨平台对比基线，便于团队统一推理基础设施。

局限

• **实验范围与引擎覆盖有限**：论文评估了九个 Apple Silicon 推理引擎，但并未涵盖所有常见选择（如 `llama.cpp`、`TensorRT-LLM`、`MLX` 等），且模型局限于 **Qwen3**、**Qwen3.5**、**Gemma 4** 系列。这可能导致结论对特定引擎或模型架构存在偏差，无法完全推广到其他模型家族或量化配置。此外，工作负载仅包含 chat 和 agent 场景，未覆盖批处理、流式或长文本生成等实际部署中常见的负载类型，因此基准的全面性有待加强。
• **保真度评估指标单一**：论文使用分类任务来检测质量回归，但该任务可能无法捕捉生成模型在指令跟随、推理连贯性、多轮对话等方面的保真度退化。**分类任务** 对某些模型架构（如 MoE）可能不敏感，且仅与 NVIDIA 参考进行比较，缺乏对绝对质量退化程度的量化。这限制了结论在更广泛生成任务上的适用性，未来需要引入更多样化的保真度基准（如 `AlpacaEval` 或 `MT-Bench`）来完善评估。
• **多节点实验的局限性**：论文在双机配置上测试了 tensor parallelism over Thunderbolt RDMA 和 pipeline parallelism over TCP，发现前者扩展而后者回归。但仅有两台机器的实验无法充分揭示更大规模集群下的扩展行为，且 Thunderbolt RDMA 是特定硬件特性，其结论可能不适用于标准以太网或 InfiniBand 环境。此外，未分析内存瓶颈在多节点场景下的交互，限制了多节点推理的工程指导价值。