MoE 大模型自建还是 API？2026 年显存与成本平衡点
一篇公开分析文章给出的 Kimi K3 口径是总参数约 2.8T、896 个专家、每个 token 激活 16 个专家，并带有 1M token 上下文；这些数字已经足以说明：激活参数不能直接替代完整权重驻留需求。(huggingface.co)
获胜者取决于条件：低利用率、需求波动大，或模型仍未完成验证的团队，应继续使用 API，或先租用算力做短周期压测；只有负载稳定、数据控制需求明确，并且团队能承担分布式推理与故障恢复时，长期自建才可能成立。
这篇文章适合三类读者：
AI 创业团队和 Agent 产品组，需要保留更换模型的空间；MLOps 工程师，需要确认权重、运行时余量和集群拓扑；预算负责人，需要用同一业务负载比较 API、租用算力和自建的总成本。
先看完整驻留容量，而不是激活参数
MoE 模型的激活参数描述的是一次计算中参与路由的部分专家，不代表部署时只需要把这部分权重放进显存。大多数推理服务仍需要处理完整专家权重、路由结构、共享层、量化元数据和运行时缓存。
显存至少应拆成四个口径：
- 权重与量化元数据：模型文件、缩放因子、索引和加载后的布局。
- 运行时工作区：算子临时张量、通信缓冲区、框架预留空间。
- KV Cache：输入长度、输出长度、并发和会话保持时间共同决定。
- 安全余量：模型切换、批处理波动、碎片和异常请求需要的缓冲。
因此，必须区分三种状态：
- 能加载：进程可以把权重放入设备或统一内存。
- 能生成：单个请求可以完成推理。
- 能承载业务：在目标并发、延迟、上下文长度和失败重试条件下持续服务。
公开分析对 Kimi K3 的 1.4 TB 权重存储估算，只能作为量级参考，不能直接当作生产显存需求。该数字没有覆盖具体运行时、KV Cache、并行通信和故障余量。(huggingface.co)
激活参数能不能直接换算部署显存？
不能。可以使用下面的估算式建立第一版容量模型：
最低设备容量
≈ 权重驻留 + 量化元数据 + 运行时工作区
+ KV Cache + 通信缓冲 + 安全余量
激活参数可以帮助估算计算量和带宽压力，但不能删除未激活专家的权重驻留责任。除非官方部署方案明确支持专家按需加载、卸载或分层存储，否则“每次只激活一小部分”不能成为减少设备数量的采购依据。
配置文件能下载，不等于当前运行时能加载
容量通过后，第二道门是兼容性。模型仓库文件完整，只能证明文件可以获取，不能证明当前推理框架、量化格式、驱动和硬件组合能够正确启动。
部署前至少要核对：
- 模型卡是否明确支持目标推理框架。
- 权重格式是否被当前版本正确识别。
- 量化类型是否有对应内核和硬件支持。
- 张量并行、流水线并行、专家并行的组合是否匹配。
- 节点之间的通信带宽和拓扑是否满足启动条件。
- 启动日志中是否出现权重回退、CPU offload、显存溢出或专家路由异常。
对于 MoE，专家并行和张量并行并不是同一件事。官方文档说明，部分 MoE 服务可以让注意力层采用数据并行，而专家层采用专家并行或张量并行；这会改变设备数量、通信路径和故障域。(docs.vllm.ai)
注意： “文件大小接近设备总显存”通常不是安全配置。只要 KV Cache、通信缓冲或框架工作区没有被计入，单次启动成功也不能证明方案可以进入生产验收。
两张表先把三条路线放到同一口径
第一张表用于判断方案是否具备容量和运行条件。它不比较名义单价，而是比较能否完成同一个业务目标。
| 指标 | API | 短期租用算力 | 长期自建 |
|---|---|---|---|
| 权重驻留 | 由服务方承担 | 由租用方确认 | 由团队长期承担 |
| 模型切换 | ✅ 快速 | ✅ 可调整 | ❌ 迁移成本高 |
| 显存与拓扑验证 | 低 | 中，可通过压测确认 | 高，需要长期维护 |
| 闲置容量 | 通常按调用发生 | 可按周期控制 | 设备长期占用 |
| 数据控制 | 取决于服务条款 | 取决于环境与网络 | ✅ 控制范围最大 |
| 故障恢复 | 由服务方承担 | 需要双方约定 | ❌ 团队自行建设 |
| 适合负载 | 波动、试验、低利用率 | 压测、短期项目、模型验证 | 稳定且持续的生产流量 |
第二张表用于判断应当把哪些成本放入公式。遗漏一项，平衡点就会向自建方向产生虚假偏移。
| 成本项 | API 侧口径 | 自建或租用侧口径 |
|---|---|---|
| 推理消耗 | 实际输入 token、输出 token | 有效完成请求消耗的设备时间 |
| 推理模式 | 普通、思考、工具调用等模式 | 不同模式对应的吞吐和缓存占用 |
| 重试成本 | 失败请求再次计费 | 失败请求占用的设备时间 |
| 容量成本 | 通常包含在调用价格中 | 预留设备、空闲节点和扩容余量 |
| 工程投入 | 接口接入和监控 | 部署、升级、监控、恢复和值班 |
| 数据与网络 | 调用链路和传输 | 存储、跨节点通信、出口带宽 |
| 风险准备 | 服务商可用性和供应商替换 | 硬件故障、版本回退和备份环境 |
用有效请求成本，而不是空跑吞吐做比较
很多自建方案只拿基准测试中的 token 每秒和 API 单价比较。这种做法忽略了最贵的部分：设备并不总在满载运行。
业务侧至少要从真实日志提取：
- 每日和每小时请求量。
- 输入、输出和上下文长度。
- 峰值并发与平均并发。
- 峰谷分布和空闲时段。
- 目标首 token 延迟与完整响应延迟。
- 工具调用、思考模式和失败重试比例。
- 需要保留的最大会话数。
自建总成本可以写成：
自建总成本
= 算力占用或折旧
+ 存储与传输
+ 工程工时
+ 监控与恢复
+ 闲置容量
+ 风险准备
API 总成本则应写成：
API 总成本
= 输入消耗
+ 输出消耗
+ 推理模式费用
+ 工具调用费用
+ 失败重试费用
真正的平衡点是：
在相同请求量、上下文、延迟和可用性目标下：
API 总成本 = 自建总成本
不是“单卡价格等于 API 标价”，也不是“每天调用多少次就一定值得部署”。如果请求集中在短时间窗口，租用算力的闲置成本可能低于长期自建；如果请求全年稳定，且数据控制与延迟要求很高，自建才有继续计算的价值。
每天调用多少才值得自己部署？
没有脱离业务条件的固定次数。更可靠的判断方法是先计算一个周期内的有效请求量，再把自建侧的固定成本、闲置成本和运维投入摊到这些请求上。
若当前团队还没有明确租用周期，应先结合实际预算核对 ProxyMac 的算力租赁价格页面，把设备占用、释放时机和验证周期单独列出，而不是直接拿长期月度成本与 API 单次调用价格比较。
如果请求集中在少数时段，或每周流量变化很大，API 通常更容易控制预算。若流量长期稳定、模型版本不频繁更换，并且团队能够持续维护分布式推理环境，才值得进一步做租用压测和自建回收期测算。
Kimi K3、DeepSeek V4 与 Qwen3.8 Max 应该怎样比较
Kimi K3 可以作为“完整权重极大、激活部分较小”的校准案例。公开资料提到它采用 896 个专家、每 token 激活 16 个专家，并使用 MXFP4 权重；但这些信息仍不能替代真实运行时的启动日志和显存峰值。(huggingface.co)
DeepSeek V4 则应优先核对官方模型卡、技术报告、权重文件和部署说明。其官方透明度页面已经列出 DeepSeek-V4，并提供模型卡与技术报告入口；官方 API 文档也给出了 V4 的预览接入说明。(deepseek.com)
Qwen3.8 Max 与 Qwen3.8-2.4T-A95B 在没有完成官方模型仓库、模型卡和文件清单核验前，只能保留为待填实例。社区帖子、发布时间预测和未被官方页面支持的硬件需求，不应进入采购结论。
三者可以使用同一公式比较，但不能把三者的参数、文件大小或推理性能直接横向排名：
| 校准项目 | Kimi K3 | DeepSeek V4 | Qwen3.8 Max |
|---|---|---|---|
| 权威输入 | 模型资料与权重文件 | 官方模型卡与技术报告 | 待完成官方资料核验 |
| 可用于公式的内容 | 权重格式、运行时要求、实际日志 | 权重格式、运行时要求、实际日志 | 核验后再填写 |
| 禁止直接采用 | 社区推测的生产显存 | 未验证的硬件数量 | 社区发布时间与配置传闻 |
| 结论用途 | 校准容量与并行策略 | 校准容量与服务条件 | 暂不作采购判断 |
第一步：先完成一周业务日志采集
不要先买设备。先记录真实请求，至少覆盖高峰、低谷、失败重试和工具调用。日志字段应包含时间、输入输出长度、并发、模型版本、响应延迟和错误原因。
如果当前模型仍在频繁变化，日志还应记录每次模型切换后的质量与延迟变化。否则，自建成本可能是在为一个很快被替换的权重版本做长期投资。
第二步：建立权重和运行时容量表
从官方仓库读取权重索引、配置文件和量化说明。分别记录文件大小、加载后显存、工作区峰值、KV Cache 增长和通信缓冲，不能把仓库文件大小直接填入生产显存栏。
第三步：确认并行策略与拓扑
使用目标推理框架的当前文档核对张量并行、流水线并行、专家并行和数据并行。官方文档显示，大型 MoE 部署可能需要把不同层采用不同并行策略；这意味着“设备数量足够”仍不代表通信拓扑合格。(docs.vllm.ai)
第四步：用目标请求压测
压测不能只发固定短问题。应按真实输入输出长度、目标并发、上下文增长、工具调用和失败重试重放请求。记录首 token 延迟、完整响应延迟、有效吞吐、峰值显存和错误率。
第五步：把空闲和恢复成本加入总账
租用算力要记录实际租用周期、交付等待、启动时间和释放条件。长期自建要记录设备折旧、备件、监控、升级、值班和故障恢复。API 则要记录限流、供应商切换和重复调用成本。
第六步：用清单决定是否进入长期自建
- [ ] 已取得目标模型的官方模型卡、配置文件和权重索引。
- [ ] 已分别测出权重驻留、运行时工作区和 KV Cache 峰值。
- [ ] 已确认量化格式、驱动和推理框架版本可以正常加载。
- [ ] 已验证张量并行、专家并行和跨节点通信拓扑。
- [ ] 已用真实请求日志，而不是空跑基准计算有效吞吐。
- [ ] 已将闲置容量、失败重试、监控、恢复和值班计入成本。
- [ ] 已证明模型版本不会在验证周期内频繁替换。
- [ ] 已明确发生容量溢出、延迟不达标或故障时的回退方案。
- [ ] 已确认团队可以承担持续升级和生产故障恢复。
只要容量或运行时不成立，就应停止采购讨论。业务负载不足时，不应进入长期自建。无法承担故障恢复时，不能按生产方案验收。
API、短期租用和自建的放弃线
✅ 继续使用 API：请求量波动明显，模型版本变化快，团队更重视交付速度，或暂时没有稳定的容量数据。
✅ 先租用算力：模型已确定，但权重驻留、并行策略、有效吞吐和高峰稳定性尚未验证。短周期租用的价值是消除未知变量，而不是简单追求低单价。需要临时环境时，可先查看 ProxyMac 的算力租用与帮助说明，再按实际周期核对交付与释放条件。
✅ 考虑长期自建：负载稳定，数据控制和延迟目标明确，模型版本变化可控，并且团队拥有分布式推理、监控、升级和故障恢复能力。
❌ 放弃自建：只能证明“模型可以启动”，却无法证明目标并发下能稳定生成；或者成本模型没有包含闲置容量、工程工时和恢复风险。
相比 API，当前方案的主要缺点是调用链路和供应商策略会限制控制范围；相比长期自建，短期租用和 API 又可能在持续高负载下缺少规模优势。长期自建则要承担设备闲置、模型迁移、驱动兼容和夜间故障恢复。对于仍在比较 Kimi K3、DeepSeek V4 与 Qwen3.8 Max 的团队，直接采购往往把未验证的变量变成固定成本。更稳妥的做法，是先整理一周真实请求日志，再通过 ProxyMac 租用可调整周期的 Mac 算力完成容量与利用率验证；验证结果不足以支撑长期自建时，保留 API 作为回退，通常比提前锁定一套生产集群更合理。
