Token在燃烧？尝试本地部署？

如果把个人可以买到的设备限制在最多 128GB 统一内存，什么开源模型最适合 AI Coding？买 Mac Studio、AMD 大内存小主机、DGX Spark 或多显卡工作站，和直接调用在线 API 相比，哪一种更快、更便宜？

这篇文章只讨论 AI Coding Agent：模型需要读取代码仓库、调用终端、修改多个文件、执行测试，并根据报错继续迭代。普通聊天、知识问答和只补全下一行代码的 FIM 模型不在本文范围内。

为了让比较有实际采购意义，本文增加两个约束：

1. 本地设备的统一内存或可用于推理的总高速内存不超过 128GB；
2. 所有本地方案运行同一个开源模型，在线方案也尽量调用同名模型，避免把模型能力差异误算成硬件差异。

资料和价格更新至 2026 年 7 月 19 日。硬件价格按市场数量级估算，API 价格来自官方页面，实际采购价、汇率和服务价格可能变化。

一、先说结论

在 128GB 上限内，我选择 Qwen3-Coder-Next 作为本地 AI Coding 的比较样本。它不是所有维度都绝对最强，但在“开源许可、Coding Agent 能力、模型尺寸和本地推理效率”这几个条件同时成立时，是目前最有代表性的高端本地模型之一。

我的结论是：

1. 只为降低 Token 费用，不值得专门购买本地硬件。 同名模型的 Qwen Cloud API 在短上下文下，重度个人使用约 ¥216/月；一台 ¥2万～¥5万元的本地设备通常需要很多年才能靠 API 费差价回本。
2. 已有 64GB 以上 Mac 或 48GB 显存工作站时，本地部署很有价值。 Qwen3-Coder-Next 4bit 约需 46GB，模型完整装入后可以达到可交互的 Agent 速度。
3. 64GB 是能用，96GB～128GB 才是舒服。 64GB 在加载 4bit 权重后，留给操作系统、运行时和 KV Cache 的空间有限；96GB～128GB 更适合长上下文和并行工具任务。
4. 128GB 容量不等于高性能。 Ryzen AI Max+ 395 和 DGX Spark 都能装入模型，但生成速度会受到约 256～273GB/s 内存带宽限制；专业显卡带宽更高，但价格也高得多。
5. 个人最合理的模式仍然是混合使用。 敏感代码、离线任务和高频小修改走本地；长上下文、紧急任务和复杂重构走 API。

二、为什么选择 Qwen3-Coder-Next

Qwen3-Coder-Next 是专门面向 Coding Agent 和本地开发的 MoE 模型，采用 Apache-2.0 许可证。官方模型卡给出的核心参数如下：

• 总参数量 80B，每个 Token 激活约 3B；
• 原生上下文 262,144 Token；
• 只支持非思考模式；
• 支持函数调用和 OpenAI 兼容服务；
• 可接入 Qwen Code、Claude Code、Codex、Cline、Kilo 等 Coding 工具；
• 支持 llama.cpp、MLX-LM、Ollama、SGLang 和 vLLM 等后端。

公开 Coding 基准如下：

这些成绩会受到 Agent 框架、提示词、工具集和推理参数影响，不能理解为在任何 IDE 中都有固定成功率。不过它们至少说明，这个模型的目标不是生成几个函数，而是完成仓库级软件工程任务。

为什么不选择更大的模型

总参数更大的模型不一定适合本次硬件约束。例如 GLM-5.2 的最低实用量化也需要约 223GB～245GB 总内存，128GB 设备只能依赖大量 SSD 或远程卸载。它虽然能“启动”，但权重会频繁跨层级搬运，无法获得正常的 AI Coding 交互体验。

Qwen3-Coder-Next 的优势正好相反：总参数 80B，但每 Token 只激活约 3B。根据 Unsloth 的本地运行说明：

本文默认选择 4bit。它能在 64GB 设备上运行，又比 3bit 更稳；8bit 虽然更接近原始模型，但在 96GB 设备上只剩很少空间给 KV Cache，综合体验未必更好。

三、AI Coding 性能不能只看 Token/s

Coding Agent 的完整链路通常是：

1
2

理解需求 -> 搜索仓库 -> 阅读文件 -> 规划修改 -> 编辑代码
        -> 执行命令 -> 分析报错 -> 再次修改 -> 运行测试

因此需要同时比较四种性能：

• 任务成功率：能否最终通过测试，而不是只输出看起来正确的代码；
• 首 Token 延迟：提交任务后多久开始响应；
• 生成速度：模型持续输出时的 Token/s；
• 总完成时间：包括读取上下文、工具调用、失败重试和人工纠错。

本地部署最容易只关注生成速度，但 AI Coding 中经常更慢的是长提示词的 Prefill。一次输入 50K Token 的仓库上下文，即使后续输出很快，也可能在开始生成前等待很久。

另一个常见误区是把“支持 256K 上下文”理解成“应该默认开启 256K”。上下文越长，KV Cache、Prefill 时间和内存碎片越大。个人使用建议从 16K 或 32K 开始，让 Agent 通过代码搜索按需读取文件，再根据项目逐步提高。

四、本地部署方案对比

下面所有方案都以 Qwen3-Coder-Next 4bit、单用户 AI Coding 为基础。速度等级是综合容量、内存带宽、推理后端和是否发生卸载后的相对判断，不是厂商保证值。

Unsloth 给出的经验是：量化模型完整放入计算设备后，可期待 20+ Token/s；一旦模型不能完整装入而需要分层卸载，速度会明显下降。这个数字是模型级经验，不是对每一种硬件的实测承诺。

1. 64GB Mac Studio：能用，但要控制上下文

Mac 的 CPU 和 GPU 共用统一内存，不存在传统 PC 上“系统有 64GB，但显卡只能用 24GB”的硬边界。Qwen3-Coder-Next 4bit 约 46GB，64GB Mac 可以完整加载，并通过 llama.cpp、MLX-LM、Ollama 或 LM Studio 提供本地 API。

它的主要瓶颈不是计算单元数量，而是 剩余内存和内存带宽：

• 权重加载后只剩约 18GB，操作系统、运行时和 KV Cache 都要使用这部分空间；
• 上下文开得过大时容易触发内存压力和 Swap；
• 发生 SSD Swap 后，速度会从可交互迅速下降；
• Metal 对桌面推理很成熟，但新模型的高级优化通常晚于 CUDA 后端。

因此 64GB 更适合 4bit + 16K～32K 上下文，不适合追求 256K 满上下文。

2. 96GB Mac Studio M3 Ultra：Mac 路线的性能型选择

Apple 的技术规格显示，M3 Ultra 的统一内存带宽为 819GB/s。96GB 配置运行 46GB 的 4bit 模型时，可以给 KV Cache 和其他应用留下较大空间，比 64GB 配置更适合作为长期运行的本地 Coding 服务。

8bit 约需 85GB，看起来也能加载，但只剩约 11GB，容易被系统和长上下文吃完。实际使用更建议继续选择高质量 4bit，把容量留给上下文。

主要瓶颈是：

• 没有 CUDA，无法使用只提供 CUDA Kernel 的最新优化；
• 单用户速度不错，但多人并发能力不如专业 GPU 服务；
• 长上下文仍受 KV Cache 和 Prefill 时间限制；
• 设备价格远高于调用同名 API 的费用。

3. Ryzen AI Max+ 395 128GB：容量优先的 PC 小主机

Framework Desktop 等设备可配置 128GB LPDDR5x-8000 统一内存，官方称最多可提供 96GB 图形可寻址内存，采用 256-bit 内存总线。Qwen3-Coder-Next 4bit 可以宽裕运行，8bit 也有机会完整装入。

这条路线的优点是容量大、体积小、功耗低，并且保留 Linux/Windows 环境。主要瓶颈是：

• 统一内存带宽明显低于 M3 Ultra 和高端独立显卡；
• ROCm、Vulkan、llama.cpp 对新架构的优化程度不完全一致；
• “模型能装入”不代表 GPU 能以独显级速度完成推理；
• Windows、Linux 和不同驱动版本的实际表现可能差异较大。

它适合把“运行更大模型和更长上下文”放在第一位的人，不适合单纯追求最快 Token/s。

4. DGX Spark：128GB + CUDA，但不是大显存显卡的速度

NVIDIA DGX Spark 使用 GB10 Grace Blackwell Superchip，提供 128GB 一致性内存和 NVIDIA AI 软件栈。它的价值是小体积、CUDA 环境和大容量可以同时获得，部署容器、NIM、PyTorch、SGLang 和 vLLM 类工具更接近 NVIDIA 服务器工作流。

它的核心瓶颈是约 273GB/s 内存带宽。这远低于 RTX 5090 和 RTX PRO 6000，因此不能因为名字中有“DGX”就预期获得数据中心 GPU 的生成速度。其他限制还包括 ARM64 环境的软件兼容、部分 Python Wheel 和第三方工具需要重新验证。

DGX Spark 更适合学习和验证 CUDA 部署栈，未必是单用户桌面 AI Coding 的最高性价比方案。

5. 双 RTX 3090：最便宜的 48GB CUDA 路线

两张 RTX 3090 合计有 48GB 显存，接近 4bit 模型约 46GB 的大小。它的显存带宽高、CUDA 生态成熟，二手整机价格也低于新款大内存设备。

问题是两张显卡的显存不会自动变成一块无缝的 48GB：

• 推理框架必须支持 Tensor Split 或 Tensor Parallel；
• 4bit 权重几乎占满显存，KV Cache 余量很小；
• 跨卡通信受 PCIe 或 NVLink 限制；
• 两张卡的额定功耗合计可达约 700W；
• 二手显卡还存在显存稳定性和维修历史风险。

更现实的做法是使用 3bit，或者把少量层和 KV Cache 放到系统内存。代价是量化质量或速度下降。

6. RTX 5090 + 128GB 系统内存：显卡快，卸载慢

RTX 5090 有 32GB 显存，无法完整装下约 46GB 的 4bit 模型。llama.cpp 可以把一部分层留在系统内存，从而让模型运行起来。

这条路线的瓶颈非常明确：CPU 中的权重要经过系统内存和 PCIe，不能享受显卡本地 GDDR7 的完整带宽。模型越多层卸载到 CPU，生成速度越接近系统内存方案，而不是 5090 的理论性能。

如果已经拥有 5090，这是一条新增成本很低的尝试路线；如果准备新购设备专门运行 Qwen3-Coder-Next，则不如直接选择能完整容纳模型的硬件。

7. RTX PRO 6000 Blackwell：性能最好，成本最差

RTX PRO 6000 Blackwell 提供 96GB GDDR7 ECC 显存和约 1792GB/s 带宽。Qwen3-Coder-Next 4bit 可以完整装入，并为 KV Cache 和并发保留大量空间，是本文本地方案中性能最接近理想状态的一种。

它的主要瓶颈不是技术，而是价格：单卡价格已经超过大多数个人工作站。只有在多人共享、商业服务、模型微调、专业渲染等负载能够共同分摊成本时，才可能合理。

五、推理后端怎么选

个人桌面部署建议先使用 llama.cpp 或封装它的 Ollama/LM Studio。它们对 GGUF 量化和 CPU/GPU 混合卸载支持最好。团队共享、需要并发时，再考虑 SGLang 或 vLLM。

无论使用哪一个后端，都应向 Coding 客户端暴露 OpenAI 兼容接口。这样可以把模型接入 OpenCode、Cline、Continue、Aider、Codex 或其他 Agent，而不必把工作流锁定在单一推理程序中。

六、同名模型在线 API 方案

Qwen Cloud 的 Qwen3-Coder-Next 页面提供 OpenAI 兼容 API、函数调用、结构化输出和上下文缓存。官方公布的上下文上限约 262K，最大输入约 204.8K，最大输出约 65.5K。

API 按单次请求的输入长度分档计价：

在线 API 的优势：

• 无硬件投入，开通即可使用；
• 不需要下载模型、处理驱动和量化兼容；
• 由服务端承担扩容、故障恢复和推理优化；
• 不需要为了适配 64GB 设备亲自选择量化和分配 KV Cache；服务端具体精度并未公开；
• 长上下文不会挤占本机内存。

API 的性能瓶颈则是：

• 首 Token 延迟包含公网往返、排队和长提示词 Prefill；
• 官方限制为 600 RPM、100 万 TPM，高并发时会触及配额；
• 请求超过 32K 和 128K 后，输入、输出单价都会提高；
• 速度和模型版本由服务商控制，无法固定推理 Kernel；
• 私有代码需要离开本机，必须评估数据协议、地区和合规要求。

七、API 月度成本

为了避免只看“每百万 Token”却不知道一个月花多少，下面设置三种个人 AI Coding 用量：

按 1 美元约 7.2 元人民币计算，暂不计上下文缓存可能带来的进一步优惠：

这里的上下文档位是单次请求长度，不是月度 Token 总量。一个设计合理的 Coding Agent 会通过代码搜索、摘要和缓存尽量让请求留在 32K 内；如果每轮都把整个仓库重复发送到 128K 以上，不仅费用增加，首 Token 延迟也会变长。

八、本地硬件的真实月成本

“本地 Token 免费”并不等于运行成本为零。把设备按 3 年折旧，并粗略加入每月 100 小时推理的电费，可以得到下面的数量级：

假设重度使用的 API 费用为 ¥216～¥576/月：

• ¥2万元设备的静态回本时间约为 2.9～7.7 年；
• ¥3万元设备约为 4.3～11.6 年；
• ¥5万元设备约为 7.2～19.3 年。

这还没有计算 SSD、设备残值、维护时间、硬件故障和本地 4bit 量化的能力损失。只为了省 API 费购买新机器，经济上基本不成立。

九、性能瓶颈总表

十、不同用户应该怎么选

十一、我的推荐配置

如果从零购买，我不会为了省 Token 费组建多卡服务器，而会在下面三种方案中选择：

方案 A：不买硬件，直接 API

适合大多数个人开发者。按实际用量付费，短上下文下即使重度使用也约 ¥216/月。省下的硬件预算可以购买很多年的 API，并且不需要维护模型和驱动。

方案 B：已有 64GB 设备，本地 4bit + API 兜底

这是性价比最高的本地路线。本地运行 Qwen3-Coder-Next 4bit，设置 16K～32K 上下文；同一个任务连续失败两次、上下文过长或需要更高成功率时，切换 Qwen Cloud API。

方案 C：隐私优先，新购 96GB～128GB 设备

Mac Studio 更安静省心，Ryzen AI Max 主机容量价格比更好，DGX Spark 的 CUDA 生态更完整。三者都应优先运行 4bit，而不是为了 8bit 把内存占满。额外容量应留给 KV Cache、IDE、编译和测试进程。

总结

在统一内存不超过 128GB 的条件下，Qwen3-Coder-Next 是一个很合适的高端本地 AI Coding 样本：80B 总参数、3B 激活参数、4bit 约 46GB，既有较强的公开 Coding 成绩，也能在个人可以买到的设备上完整运行。

不同本地方案的本质差异可以压缩成三句话：

• Mac Studio 用高带宽统一内存换取安静、简单，但受 Metal 生态和不可升级限制；
• Ryzen AI Max 与 DGX Spark 用 128GB 容量换取更大的模型空间，但性能瓶颈是内存带宽；
• NVIDIA 多卡或专业显卡 速度和生态最好，但瓶颈转向显存容量、跨卡通信和采购成本。

而 API 的瓶颈不是本地内存，而是网络延迟、限流、隐私和长上下文价格。以目前同名模型的价格看，个人新购硬件几乎不可能单靠节省 Token 费用回本。

所以最终建议仍然是：

没有现成硬件就先用 API；已有 64GB 以上设备就部署本地 4bit；有隐私或离线刚需再购买 96GB～128GB 设备。不要为了“本地免费”忽略折旧、速度和任务成功率。

参考资料

• Qwen3-Coder-Next 官方模型卡
• Qwen3-Coder-Next 本地运行、量化与内存要求
• Qwen3-Coder-Next 官方 API 能力与价格
• Qwen3-Coder GitHub
• llama.cpp
• vLLM
• SGLang
• Apple Mac Studio 技术规格
• Framework Desktop Ryzen AI Max
• NVIDIA DGX Spark
• NVIDIA RTX PRO 6000 Blackwell
• NVIDIA GeForce RTX 5090