翻译：Transwan

校对：Carl Cui

引言：对于想构建本地 AI 环境的人来说，如何选择硬件一直是个难题。毕竟现在跟 AI 有关的硬件，价格一路水涨船高，即便是玩硬件的富哥，“我都懂”也肯定比“我都有”来得地道。这篇文章从应用场景出发，讨论该如何选择本地 AI 硬件。作者压根没有考虑那些入门级或者中等程度的选项，直接在 M5 MBP、DGX Spark 和 RTX PRO 6000 之间比较，主打一个退烧。不知道你看完会不会有收获，反正我决定老老实实先用 API 套餐吧。以下是翻译正文：

在决定购买 M5 MBP、DGX Spark 还是 RTX PRO 6000 之前，让我们先思考这个问题：

你的硬件究竟应该加速代理循环（agent loop）的哪个部分？

聊天会话和本地 AI 代理系统对硬件的要求不同。AI 编程代理任务侧重于长上下文的重复读取、工具调用、缓存频繁失效（churn）、后台并行工作的子代理、检索、子进程、执行测试、容器这些方面，并且经常会出现多个代理同时使用同一个 LLM 服务的情况。

相比在 Mac 和 NVIDIA 或者统一内存 和 VRAM 之间权衡，我们更应该关注工作负载拆解问题。

在开始讨论硬件之前，我想纠正一种常见的误区：通过比较 token/sec 指标来决定要购买的硬件。我们应该试着将本地代理工作流映射到以下四个瓶颈上：

  1. 模型匹配度
  2. 预填充延迟
  3. 解码吞吐量
  4. 并发服务表现

这样尝试以后，你就不太容易做出"冲动"的购买决定，也更能把好钢用在刀刃上。

基准测试引发的争议

最近 M5 对比 DGX Spark 对比 Strix Halo 对比 RTX PRO 6000 讨论中最有用的部分是如何设计基准测试。MMBT fleet study 考虑了其他许多硬件对比测试经常会忽略的事情：它尽量保持模型大小和运行时引擎不变。

主流的 fleet 基准测试了四个主机类别：

Pasted image 20260527213423

该测试使用了两个 Q8 GGUF 模型：

1*SCl6i2n3xdOYsqxXIP4HVA

主要的测试场景是：

Pasted image 20260527213438

这非常重要，因为当基准测试混杂了量化格式、运行时引擎和后端成熟度时，测试结果就会产生误导。

  • 在 vLLM 下的 4-bit AWQ 模型与在 llama.cpp 下的 Q8 GGUF 模型不是同一个基准。
  • 在 Apple Silicon 上运行的 MLX 与基于 Metal 后端的 llama.cpp 也不是一码事。
  • 双 RTX 卡工作站与单卡节点不在同一个层级。

MMBT 明确区分了这些情况，它的 aggregate/canonical-headline.csv 表是典型的基于同一份源代码跨主机比较，与默认测试环境差异较大的特殊配置（包括 vLLM/FP8 和双卡行）单独放在附录中，以便读者不会意外地混淆不同类别的事物。这正是硬件讨论所需的那种严谨性。

首要原则

编码代理会将大部分时间花在感知上下文上，而不是生成最终文本。它会反复读取代码片段、仓库文件树、diff 信息、编译器输出、测试失败、linter 消息、依赖清单、问题描述以及先前的工具调用状态。每一轮看上去可能是下面这样：

1. 读取 repo 上下文。
2. 决定哪些文件重要。
3. 调用工具。
4. 接收工具输出。
5. 重新读取扩展的上下文。
6. 发起另一次工具调用。
7. 运行测试。
8. 解析失败。
9. 修补代码。
10. 重新运行测试。

这个循环导致了三个不同的延迟面。

  • 预填充（prefill）是模型读取提示词的速度。在代理工作流中，提示词通常是代理循环的全部工作记忆（the entire working memory）。长提示词使预填充成为首要瓶颈。

  • 解码（Decode）是模型写入新 token 的速度。这对于长答案、代码生成和代码补丁很重要。

  • TTFT，即首 token 时间，是任何内容开始流式传输之前对于用户的延迟。在长上下文环境中，TTFT 通常由预填充主导。

一个简单的心智模型是：

def estimate_latency(prompt_tokens, output_tokens, prefill_tps, decode_tps):
    prefill_seconds = prompt_tokens / prefill_tps
    decode_seconds = output_tokens / decode_tps
    return prefill_seconds + decode_seconds

这个函数显然是不完整的，它没有考虑调度、缓存命中、工具执行、网络开销、运行时批处理、推测解码、前缀重用和排队延迟等等这些因素，但它很有用，因为它让你意识到“token/sec”不是单一的数字。对于一个 AI 编码代理：

  • 解码速度快但读取长提示词缓慢的机器，其实际体验可能比预期的要差
  • 解码速度慢但首个 token 延迟可预测的机器，可能适合批量摘要任务。
  • 如果服务引擎的批处理能力不佳，单用户性能出色的机器在面对多个并行代理时可能会崩溃。

选择什么样的硬件取决于本地代理循环的瓶颈在哪里。

一张表看清硬件真相

MMBT 标准的 27B Q8 单用户表提供了一个清晰的参考。

Pasted image 20260527215556

这张表比类似 “M5 击败 Spark” 或 “CUDA 获胜” 的表述更有价值。

单用户情况下，RTX PRO 6000 系统在峰值预填充速度和峰值解码速度这两个指标上胜出，这并不意外。 NVIDIA 官方给出了工作站版 RTX PRO 6000 Blackwell 参数：96 GB GDDR7 ECC 内存，1792 GB/s 内存带宽和 600 W 最大功耗。这跟笔记本电脑或迷你 PC 的统一内存处在完全不同的级别。

M5 Max 在其自身定位上表现强劲。 Apple M5 Max MacBook Pro 配备 40 核 GPU、128 GB 统一内存和 614 GB/s 内存带宽。在 MMBT 的 27B Q8 表格中，它在短上下文环境下的峰值解码速度远快于 Spark 和 Strix Halo，而在 16K 上下文环境下，它的解码速度出乎意料地接近 llama.cpp + RTX PRO 6000 组合的表现。

在这个基准测试中，DGX Spark 并非单纯的单节点解码怪兽。 NVIDIA 的 DGX Spark 硬件指南显示其拥有 128 GB LPDDR5x 统一内存、256 位接口、273 GB/s 内存带宽、20 核 Arm CPU、ConnectX-7 网络以及 FP4 支持。Spark 的定位是桌面 AI 系统，用于原型设计、微调、推理，便于向 NVIDIA 基础设施迁移，这与“本地最快聊天框”是不同的价值主张。

Strix Halo 讲述的是性价比与大容量兼顾的故事。 AMD 的 Ryzen AI Max+ 395 官方规格列出了最大 128 GB 内存、256 位 LPDDR5x 内存子系统，以及配备 40 个图形核心的 Radeon 8060S 显卡。在 MMBT 中，被测试的 EVO X2 以更低的价格水平提供了大型统一内存，但测试结果表明它的预填充速度较慢，并且小巧的机箱不可避免的受温度墙影响。

因此，最核心的结论是：没有永远的赢家，只有不同的运行方式。

Pasted image 20260527222212

为什么到处都在讲内存带宽

单流 LLM 解码通常受限于内存带宽。对于每个新的 token，系统会将模型权重反复流式传输并在 KV 状态上进行注意力计算。如果内存无法足够快地传递数据，计算单元就会处于空闲状态。

官方和基准测试相关的带宽数据如下所示：

Pasted image 20260527222238

对于 Q8 量化版本的稠密模型，你可以据此预估单用户解码速度，但 AI 代理系统会让情况变得复杂。

在短上下文情况下，RTX PRO 6000 解码速度遥遥领先。在 16K 上下文时，其他硬件相比 RTX PRO 6000 的解码速度缩小了差距：RTX PRO 6000 约为 19.84 token/sec，而 M5 Max 约为 16.11 token/sec。在 32K 上下文情况下，M5 保持在 16 token/sec 左右，而 RTX PRO 6000 在 llama.cpp CUDA 设置下的表现进一步下降。

这并不意味着 M5 拥有比 RTX PRO 6000 更快的 GPU。这意味长上下文表现会非常明显地受运行时影响。MMBT 的结果表明：多用户和某些长上下文比较受限于 llama.cpp 引擎，需要考虑单独的 vLLM、TensorRT-LLM 或 MLX 的后续改善。硬件规格解释了很多问题，但运行时决定了剩余的部分。

不要忽略预填充这个指标

AI 代理用户应该比普通聊天用户更关心 prefill。一个编码代理可以发起数十轮对话，每一轮可能包含数千或数万个 token 的累积上下文。如果 LLM 系统的前缀缓存不佳或频繁发生缓存驱逐，相同的代码库上下文就会被一遍又一遍地重新读取。在这种情况下，“启动之后就能流畅运行”是保证不了的。

在 27B Q8 单用户测试结果中： 1*ILuaMa2QbqmdSIAgWk1OxQ

Spark 的表现很有意思，运行这个 Q8 量化后的稠密模型时，它的解码速度输给了 M5，但它有更好的 16K TTFT。对于重度使用工具的代理来说，这可能比生成第一个 token 之后的流式输出速度更重要。

  • 如果你的工作流是“给模型一个长提示 prompt，要求一个简短的决策，调用工具，重复”，那么 prefill 和 TTFT 占主导地位。例如 PR 分类、基于政策文档的 RAG、结构化提取、路由或代码库查阅这些任务。
  • 如果你的工作流是“给模型一个中等长度的提示 prompt，并要求它生成一个长文件”，那么解码就更重要。例如长代码生成、迁移脚本、文档或测试脚手架。
  • 如果你的工作流是“并行运行十个代理”，那么单用户的 prefill 和单用户的解码都不够。你需要一个验证批处理、排队和缓存行为的真实服务基准测试。

并发是陷阱

最危险的情况是将单用户数字直接套用到多用户代理服务场景中。MMBT 在这一点上也很谨慎，它运行了并发单元，但明确地对跨主机多用户场景保留了结论，因为在长上下文环境下，llama.cpp 的 --parallel N 行为会成为引擎级别的限制。这是正确的做法。

并发的代理工作负载绝不是简单地“单用户 token/sec 乘以 N”。它们取决于：

  • 连续批处理
  • KV 缓存分配
  • 前缀缓存
  • 工具调用解析器的正确性
  • 队列策略
  • 每个请求的上下文长度
  • 模型是稠密模型还是混合专家
  • 张量并行或流水线并行对模型是否高效
  • 运行时是否能让硬件保持饱和，而不会发生病态的缓存驱逐

这就是 vLLM 值得考虑的地方。vLLM 强调连续批处理、前缀缓存、分块 prefill、用于 KV 内存管理的 PagedAttention、优化的注意力机制内核、张量/流水线/数据/专家/上下文并行、工具调用、推理解析器以及兼容 OpenAI 的 API 服务器。这些功能集是专为生产级服务构建的。

llama.cpp 极其有用，因为它几乎可以在任何地方运行。它支持在各种硬件实现推理，包括通过 Apple Silicon 的 Metal、x86 加速、CUDA、Vulkan、SYCL 以及 CPU+GPU 混合推理。这使它成为一个合适的跨平台比较工具，但跨平台比较工具并不能成为适合高并发的最佳生产服务引擎。

对于开发团队来说，实用规则是：

使用 llama.cpp 来了解可移植性和基线硬件行为。使用 vLLM、TensorRT-LLM、SGLang、MLX 或其他优化的服务技术栈来评估生产级并发。

供单个开发者使用的本地编码助手可以在单用户引擎上顺畅运行，但面向团队的代理服务需要服务级引擎。

DGX Spark 适用的场景

从 Q8 量化模型的解码速度上看，DGX Spark 看起来很弱，但这是一个错误的视角。NVIDIA 强调 NVIDIA 软件栈、128 GB 统一系统内存、FP4 支持、对最高 70B 参数模型的微调、大型模型推理，以及可以连接两台 Spark 系统以支持更大模型的 ConnectX 网络。硬件指南列出了两个 QSFP 网络连接器和 ConnectX-7，这使得两台 DGX Spark 系统可以实现数据中心级别的 RDMA 网络连接，使得支持高达 405B 参数的 AI 模型成为可能。

这并不会让 Spark 在这个单节点 Q8 基准测试中的表现比 RTX PRO 6000 更好，但这确实让 Spark 作为一款开发者设备，适合那些处在 NVIDIA 生态、测试本地微调、验证部署工作流，以及未来可能将两台设备组成集群的团队。对于面向 AI 代理产品的团队来说，下面的条件成立时，建议选择 Spark：

  • 相比本地聊天峰值速度更看重 CUDA 兼容性
  • 关注 FP8/FP4 模型发展
  • 想要一台紧凑的 Linux 设备，而不是笔记本电脑
  • 可能会连接多个单元
  • 正在构建工作流原型，后续将迁移到 NVIDIA 云端或数据中心 GPU 上
  • 想在本地进行微调或实验，又不需要搭建完整的工作站

M5 Max 适用的场景

在 MMBT 基准测试中，128 GB M5 Max MacBook Pro 在单用户本地推理方面确实表现出色，它有足够的统一内存来运行大型 GGUF 模型，其解码速度良好，而且散热表现比许多人预期的要好。对于小团队来说，Mac 具有明显的优势：

  • 它是一台常规的开发者笔记本电脑
  • 它具有便携性
  • 它不需要服务器机房
  • 它可以运行常见 24 GB 显卡无法容纳的大型本地模型
  • 它避免了独立 GPU 工作站的复杂性
  • 它可以成为一个很好的单人开发者本地助手盒子

MLX 正在不断改进。llama.cpp Metal 运行良好，而且也有本地 AI 服务。但是，如果你的 AI 代理产品依赖于特定于 CUDA 的内核、vLLM 生产环境行为、TensorRT-LLM、NVIDIA 量化路径，或者假设有 NVIDIA GPU 的训练/微调工作流程，那么 Mac 并不是一个可直接替换的方案。

当你重视内存容量、便携性和单用户便利性时，M5 Max 是一台出色的本地推理机器；但当你要构建一个共享的多代理服务平台时，它就不太合适了。

RTX PRO 6000 依然重要

说 RTX PRO 6000 定价过高是一种流行观点，但这种说法也是不全面的。它拥有 96 GB GDDR7 ECC 内存和 1792 GB/s 的内存带宽。在 MMBT 单用户 27B Q8 测试结果中，Blackwell 6000 塔式主机在峰值预填充速度和峰值解码速度上表现最好。但 RTX 级别硬件对 AI 代理真正重要的原因在于以下几个方面的组合：

  • CUDA
  • vLLM 的成熟度
  • 张量并行服务选项
  • 更好的高批量吞吐量
  • 微调和训练支持
  • 扩散和多模态工作负载
  • 多 GPU 工作站扩展
  • 最先落地于 NVIDIA 生态系统的工具

如果你的 AI 代理产品是为某个团队提供本地服务，那么 RTX PRO 6000 更接近于“基础设施”，而不是“一个便捷的本地玩具”。一个运行着众多后台代理、评估任务、合成数据生成、PR 审查器、嵌入重排器和支持工具调用的代理的平台团队，才能充分利用起这块 GPU。这一点云计算团队体会最明显：GPU 空闲时很昂贵，但被有用的工作填满时就很划算。

所以这就是实际的采购逻辑：

Pasted image 20260527232307

第二个决策表对代理系统更为有用：

Pasted image 20260527232315

写在最后

对于面向开发者的 AI 代理产品，硬件选择如下：

  • 当你需要 CUDA、高预填充、高解码、高批量支持、微调以及未来工作负载的灵活性时，RTX PRO 6000 级别硬件是值得认真考虑的本地 AI 基础设施
  • M5 Max 是一台非常强大的单用户大内存推理机器，特别适合那些希望在便携机器中运行本地模型且不绑定 CUDA 工作流的开发者
  • DGX Spark 最好被理解为一台具有统一内存、FP4/FP8 方向、支持微调和集群特性的紧凑型 NVIDIA 开发设备，它不是最快的 Q8 llama.cpp 解码盒子
  • Strix Halo 是预算型的大内存实验箱。它很有用，但在本次基准测试中，其预填充和机箱热限制使其不适合作为低延迟代理服务的默认选择。

AI 代理将模型推理转变为系统性的工程。你需要考虑模型适配、预填充、解码、TTFT、批处理、工具调用解析器、KV 缓存行为、热稳定性、功耗以及可复现性。因此，最适合本地的 AI 硬件，其实是在回答一个问题：

我花钱是为了解决哪个瓶颈？

回答了这个问题，硬件购买决策就会明朗得多。

原文链接

M5 MacBook Pro or NVIDIA DGX Spark or RTX PRO 6000?