本地跑 Llama 3.1 405B：显存预算、双 Mac Studio 方案与替代路线

很多人第一次看到 Llama 3.1 405B 的参数量，会本能地想知道：家里那台顶配机器能不能跑？讨论区里给出的答案是一套苹果集群——两台 192G 统一内存的 Mac Studio 加上 exo 做分布式推理。这个答案本身没错，但它只是整条决策链的最后一环。真正需要先搞清楚的是：参数量怎么换算成内存、为什么一台不够、跑起来有多快、以及这件事到底值不值得做。

下面按“算账 → 选硬件 → 估速度 → 挑软件 → 看语言能力 → 定方案”的顺序拆开讲。

第一步：把参数量换算成内存

权重的裸占用可以用一个粗略公式估算：参数量 × 每个参数的字节数。405B 意味着 4050 亿参数，代入不同精度：

除了权重，还要留出三块空间：

• KV Cache：随上下文线性增长。日常几 K 上下文时通常只有几 GB 到十几 GB，但开到 128K 这种长上下文，量级会爬到几十 GB。
• 激活与临时缓冲：推理框架、编译图、批处理都会额外占用。
• 系统与运行时：几十 GB 起步，别忽略。

工程上的经验法则是：权重占用 × 1.2 到 1.3，再加上 KV Cache，才是你真正需要的内存下限。按这个算法，405B 想跑起来，4bit 量化是唯一现实路径，起点就在 220–260 GB 这个量级。

为什么是两台 192G 的 Mac Studio

单台 192G 统一内存的 Mac Studio 看起来离 230 GB 只差一点，但实际差得不少。macOS 对 GPU 可用的 wired memory 有默认上限，虽然可以通过系统参数调高，但调高之后留给系统本身、文件缓存和 KV Cache 的余量就所剩无几。模型加载到一半被系统杀掉，是很常见的翻车方式。

两台串联之后总内存到 384 GB，扣除系统开销和上下文缓存，才算是“舒服地装下 4bit 权重”。这就是“为什么要两台”的实质答案：不是算力不够，是单机内存装不下。

代价在互联上。这类集群通常走 Thunderbolt 或万兆以太网组成环形/流水线并行，实际可用带宽比机内统一内存总线低一到两个数量级。每一层计算完要把激活值传给下一台，token 生成被通信延迟拖着走，机器越多，边际收益越差。

多卡 GPU 服务器路线

如果目标是稳定服务而不是折腾，标准做法是租或买多卡节点：

• FP8 推理：8 张 80G 卡，张量并行切分，权重刚好放下，上下文长度要保守设置。
• BF16 推理：显存需求翻倍，需要 8 张 141G 级别的卡，或跨节点部署。

以 vLLM 为例，启动参数大致是：

vllm serve meta-llama/Llama-3.1-405B-Instruct \
  --tensor-parallel-size 8 \
  --quantization fp8 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92

先把 --max-model-len 设小，跑通再逐步加，比一上来开满上下文然后 OOM 要省时间。具体参数名和支持的量化格式随版本变化，以所装版本的官方文档为准。

速度大概是什么水平

这是讨论里被追问最多、也最容易被含糊带过的点。可以这样估：生成一个 token，需要把参与计算的权重完整读一遍。405B 在 4bit 下约 200 GB，单机内存带宽如果是 800 GB/s 量级，理论上极限也就是每秒几个 token；两台分摊后每台读一半，但中间多了跨机传输，实际往往还要再打折扣。

结论是：双机 Mac 集群跑 405B，交互体验大概率是个位数 token/s，首次加载模型要等很久，长提示词的首 token 延迟也会很明显。 具体数字受量化方式、上下文长度、互联方式影响很大，务必自己实测，不要信任何单一 benchmark 截图。

测的时候至少记录四个指标：首 token 延迟、生成速度（token/s）、显存/内存峰值、以及跑满 30 分钟后的稳定性。

软件栈怎么选

• 苹果集群：exo 是目前把多台 Mac 拼成推理集群比较省事的方案，支持 MLX 后端，各节点启动后在 Web 面板里选择模型与设备即可。安装方式和可用模型列表变动较快，按仓库 README 操作。
• 跨机 llama.cpp：用 RPC 模式把多台机器拼起来，适合已有 GGUF 量化文件的场景，命令形态类似 llama-server -m model.gguf --rpc host1:50052,host2:50052 -c 8192 -ngl 999，对端要先起 rpc-server。这种方式通用性好，但跨机带宽利用率一般。
• 单机多卡：直接上 vLLM 或 TensorRT-LLM，成熟度和吞吐都更好。

几个容易踩的坑：上下文长度别照抄默认值；能开 KV Cache 量化就开；-ngl 要设成全部卸载，否则一部分层跑在 CPU 上会慢得离谱；磁盘至少留出权重大小的 1.5 倍做下载和转换。

另外，Llama 3.1 的权重在 Hugging Face 上是需要申请授权的 gated 仓库，下载前要先拿到访问权限。

中文能力：这一点要有心理准备

Llama 3.1 官方列出的支持语言里并不包含中文，它的中文能力主要靠预训练语料迁移，实际表现明显弱于同量级的中文优化模型——指令遵循、成语与术语、标点习惯都容易出问题。如果你的场景以中文为主，用 405B 去对比 70B 级的中文模型，结果很可能不占优势，甚至更差。

因此评估时不要只看参数量，一定要用自己的真实任务做 A/B：同一批中文提示词，分别跑 405B 和中文优化模型，人工看前十条的可用率。

更务实的几条替代路线

1. 先验证需求再上硬件。把 405B 托管推理服务和本地能跑的中等模型放在一起盲测，如果中等模型在你的任务上已经够用，就没必要为一个 405B 的执念投硬件。
2. 降级到 70B 级 + 高精度量化。一台大内存工作站就能承载，速度提升一个数量级，调试成本也低得多。
3. 小模型 + 工具调用/检索。很多“必须大模型”的需求，其实是缺上下文管理，靠检索和流程拆分能补掉大半。
4. 本地只做开发，重活放远端。如果真正的目标是让 AI 编码助手长期在线跑，而不是自建 405B，那么租一台整机放在机房的 Mac mini、通过远程连接使用，是比自己攒集群更省心的选择——这类机器按月租用、网络环境稳定，适合 Claude Code 之类需要常驻运行的工具；但要说清楚，它的内存规格装不下 405B，定位是替代本地设备的常驻运行环境，不是跑超大模型的方案。

落地前检查清单

• 明确目标：研究探索、替代 API、还是单纯想跑通一次？目标不同，硬件结论完全不同。
• 算出自己的内存预算：权重 × 1.2 + KV Cache + 系统余量。
• 确认量化精度与最低可用上下文长度。
• 评估互联方式与带宽，判断通信是否成为瓶颈。
• 磁盘至少预留权重的 1.5 倍。
• 算上电费、散热和噪音——多台高配机器长期开机的成本不只是购机价。
• 检查模型许可证条款，商用场景尤其要看清楚，以官方许可文本为准。
• 先做小规模基准测试再决定是否扩容。

小结

405B 的本地部署不是“买台顶配电脑”的问题，而是一道内存算术题：4bit 量化下权重就吃掉 200 GB 以上，单机装不下，才需要两台 192G 的 Mac Studio 撑起总容量，代价是跨机互联拖慢生成速度。多卡 GPU 方案更稳更快，但成本和门槛更高；托管 API 则是最便宜的效果验证手段。

在做决定之前，先花一天时间用托管服务跑一遍你的真实任务，再回头看看那台机器到底需不需要买。绝大多数情况下，答案会比想象中简单。