万亿级开源 MoE 模型自托管 —— 以 Kimi K3 为例

0030 秒速览

先给全貌,再看细节。读完这一节,你就知道这份文档在讲什么、和你有什么关系。

Moonshot AI 的 Kimi K3 是第一个达到 3T 级(2.8 万亿总参数)的开放权重模型,7 月 16 日上线 API,官方承诺 7 月 27 日(今天)在 Hugging Face 放出全部权重,许可证预计是与 K2 家族一致的 Modified MIT。这意味着「前沿水平的模型能不能自己架起来跑」第一次有了真实样本。

但自托管一个 2.8T 的 MoE 模型,和跑一个 7B 小模型完全是两回事。核心矛盾一句话:MoE 每次只「用」一小部分参数计算,但所有参数都必须常驻显存——K3 每个 token 只激活 896 个专家里的 16 个(约 50B 激活参数),可 2.8T 的全部专家权重都得放在 GPU 里待命。即便用官方的 MXFP4 4-bit 格式,光权重就约 1.4 TB,官方推荐 64 卡以上的超节点部署。

权重开放后的两条路。本文档重点讲路线 B 需要哪些知识,以及怎么判断自己该走哪条。

2.8T

总参数,首个开放 3T 级模型

16 / 896

每 token 激活的专家数(约 50B 激活参数)

~1.4 TB

MXFP4 权重体积(BF16 则约 5.2–5.6 TB)

上下文窗口(KDA 线性注意力支撑)

📌 即使你永远不会亲手部署 K3,这套「显存法则 + 量化 + 并行策略」的知识也适用于所有开源 MoE 模型(DeepSeek、GLM、Qwen、Llama 4 等)——它们是 2026 年开源模型的绝对主流形态。

01背景:开源权重是怎么走到 3T 级的

为什么「开放一个 2.8T 模型的权重」是个大事?先看它之前的世界。

两年前,「开源模型」的天花板还在几百亿参数;想要前沿能力,只能调用闭源 API,数据要出域、成本不可控、模型说下线就下线。此后开源阵营用 MoE(Mixture of Experts,专家混合)架构一路把总参数堆了上去——因为 MoE 允许「参数很多、每次只算一小撮」,让超大模型的推理成本不至于失控。

开放权重模型总参数规模的爬升(据 wan27.org 汇总的公开数据;各家均为 MoE 架构)。K3 把上限推到 2.8T。

Moonshot 是这条路线最激进的玩家:据 wan27.org 统计,过去 12 个月里有 9 个月「最大开源模型」的纪录由 Kimi 系列保持,K2 家族(1T 级)全部以 Modified MIT 开放权重,支撑 K3 长上下文的 KDA 注意力机制也早已通过 Kimi-Linear 项目(48B,MIT 协议)完整开源。所以社区普遍相信这次 K3 权重会如期兑现。

🔑 先分清两个词:「开放权重」≠「开源」

K3 是 open-weight(开放权重):训练好的参数可以下载、部署、微调、商用。但严格 OSI 意义上的 open-source 要求训练数据、训练代码也公开——Moonshot 从未公开过任何模型的训练数据和完整训练管线。如果你的合规团队要求「OSI 开源」,K3 不满足;如果只是要「可自托管、可商用」,开放权重就够了。(来源:wan27.org 分析文章)

另一个背景是时机的微妙:就在权重开放前一周,Artificial Analysis 测得 K3 在长时程知识工作评测中 Elo 1547、仅次于 Claude Fable 5,但幻觉率约 51%(前代 K2.6 为 39%)也被同时曝出——「下载它的人到底拿到的是什么水平的模型」,需要社区用自己的评测来回答。这正是开放权重的意义之一。

02MoE 显存法则:激活参数是算力账,总参数是显存账

这是整个主题里最容易算错、也最贵的一笔账。几乎所有部署翻车都从这里开始。

先把 MoE 本身说明白。普通的「稠密」模型,每个 token 过一遍网络,所有参数都参与计算。MoE 模型把每层的前馈网络拆成很多个「专家」,再放一个「路由器」:每个 token 进来,路由器给所有专家打分,只把 token 发给得分最高的少数几个专家处理。K3 就是 896 个专家里每次挑 16 个。

MoE 路由:每个 token 只有 16 个专家干活(算力便宜),但路由器随时可能点名任何专家,所以 896 个专家的权重必须全部常驻显存(显存昂贵)。

🏥 类比:MoE 像一家大医院

医院有 896 位各科专家,每个病人(token)挂号后由分诊台(路由器)转给最合适的 16 位。虽然每个病人只见 16 位医生——出诊成本低——但全部 896 位医生都必须在医院里坐班,因为下一个病人可能挂任何科。「养医生」的成本(显存)是按 896 人算的,「看病」的成本(算力)才是按 16 人算的。

显存怎么算:一条公式

Spheron 的 MoE 部署指南给出的实用公式(经验值,含约 15% 框架与路由开销):

所需显存 ≈ 总参数 × 每参数字节数 × 1.15 + KV cache 预算

每参数字节数:BF16 = 2 │ FP8/INT8 = 1 │ INT4/MXFP4 = 0.5

套到 K3 上,各精度的权重体积大致是(综合 kimi.com 官方博客、HF 社区博客与 wan27.org 估算):

格式	权重体积(估)	依据
BF16 全精度	~5.2–5.6 TB	2.8T × 2 字节
MXFP4(官方原生)	~1.4 TB	2.8T × 0.5 字节;官方 QAT 训练格式
社区 2-bit 动态量化	~950 GB – 1 TB	社区按 K2 缩放的估算,质量未知
社区 1.8-bit 激进量化	~650–700 GB	2.8T 规模下无先例,质量高度存疑

还有两个省心的点:第一,KV cache 按「激活架构」计费,不按 2.8T 总参数——这是 MoE 在显存上唯一占便宜的地方;第二,K3 的 KDA 线性注意力大幅压缩长上下文的 KV cache(Kimi-Linear 论文称最多省 75%),1M 上下文才因此可行。

硬件分层:什么设备能跑

配置	能跑 K3 吗	说明(来自 wan27.org 评估)
消费级 GPU(RTX 4090 24GB)	❌ 不行	差几个数量级
Mac Studio 512GB 统一内存	❌ 不行	够不到最小可用量化的门槛
4× RTX PRO 6000(384GB)	⚠️ 勉强	需 2-bit 激进量化,个位数 tok/s
8× A100 80GB(640GB)	⚠️ 可能	极限量化格式或可装下,预计 5–15 tok/s
8 节点 × 8× H100/B200(5+ TB)	✅ 可以	HF 社区博客估的「实际最低」多节点配置
64+ 加速卡超节点	✅ 官方推荐	kimi.com 官方博客:生产级吞吐需要大高带宽通信域

⚠️ 一句话的诚实评估

K3 不是本地模型。个人玩家、绝大多数创业公司都不该考虑自托管它。判断标准(wan27.org 的经验法则):如果你现在跑不动 K2.6(594 GB 下载、约 700 GB 总内存),就跑不动 K3;能跑 K2.6 的,把内存需求乘以约 2.8 倍再对照自己的硬件。

03K3 架构与 MXFP4 量化:为什么它「生来就是 4-bit」

K3 有一批新架构组件。对部署者来说,重点不是论文细节,而是「哪些组件影响我能不能跑起来」。

KDA(Kimi Delta Attention): 混合线性注意力:在一部分层里用「线性注意力」替代标准的平方复杂度注意力。通俗说,标准注意力像「每个新字都要回头看一遍全文」,越长越慢;线性注意力像「一边读一边维护一份摘要」,代价不随长度爆炸。这是 1M 上下文的基础,也是部署的最大拦路虎——llama.cpp、Ollama、主线 vLLM 截至 7 月中都还不支持 KDA。
AttnRes(Attention Residuals): 替代标准残差连接:每一层可以有选择地「回看」任意更早层的表示,而不是把所有层输出无差别地累加。影响训练质量,对部署影响小。
Stable LatentMoE: 管理 896 个专家的 MoE 框架,含潜空间路由和 Quantile Balancing(按路由分数分位数分配专家负载,防止「个别专家过劳、其他专家躺平」)。它的自定义路由内核也是现有推理引擎需要适配的部分。

MXFP4:不是「事后压缩」,是「从训练就 4-bit」

常见的量化是「训练完再压」(PTQ),模型没机会适应精度损失,压得越狠掉分越多。K3 走的是 QAT(量化感知训练):从 SFT 阶段起就用 MXFP4 权重 + MXFP8 激活训练——模型在训练中就学会了在 4-bit 精度下工作,所以 1.4 TB 的 MXFP4 就是它的「原生形态」,不是降级版。

MXFP4(Microscaling FP4)是什么?

每个权重只用 4 个 bit 存,但每一小块权重共享一个「缩放因子」来保住数值范围——相当于用「大概数字 × 块级倍率」来还原真实值。显存占用是 BF16 的 1/4。

硬件支持是关键:NVIDIA Blackwell(B200/B300 等)和 AMD MI400 原生支持 MXFP4 运算;更老的 Hopper(H100/H200)没有原生 FP4 张量核,跑起来吃亏。这直接决定「买什么卡」。(来源:kimi.com 官方博客、HF 社区博客)

官方自己的推理还有一层参考价值:Moonshot 用 Mooncake 分离式推理架构(prefill 和 decode 分属不同节点池)服务 K3,配合 KDA 的 prefix cache(官方称已向 vLLM 社区贡献实现),在编码负载上做到 90% 以上缓存命中率——这是它敢定 $0.30/MTok 缓存输入价的底气,也是自托管者迟早要抄的作业。

04部署实操:推理引擎、并行策略与真实命令

先学会部署今天就能跑的万亿级 MoE(如 K2.6、DeepSeek),等 K3 工具链就位后原样迁移——这也是 wan27.org 给出的务实路径。

三种并行策略,MoE 该选哪种

单卡装不下就要切分模型,切法有三种。理解它们的最快方式是看「按什么维度切」:

三种模型切分方式。万亿级 MoE 的常见组合是 TP + EP(单节点)或 TP + PP(跨节点)。(整理自 Spheron MoE 部署指南)

引擎选型:vLLM 还是 SGLang

	vLLM	SGLang
强项	模型兼容面广、prefix caching 成熟、运维生态好	MoE 高并发短序列吞吐常更高;社区评测称在 DeepSeek V3 级 MoE 上快约 3.1 倍(单一来源,需自测)
MoE 关键旗标	`--enable-expert-parallel`	`--enable-moe-ep`(不开则退化为纯 TP,专家权重每卡一份拷贝)
适合	生产 API、聊天类负载	超高并发、批量推理

一个可以照抄的真实例子——DeepSeek V3.2(685B MoE)在 8× H200 上的 vLLM 启动命令(来自 Spheron 指南,原文即为可运行配置):

vllm serve deepseek-ai/DeepSeek-V3.2-Speciale \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --dtype fp8 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --kv-cache-dtype fp8 \
  --max-num-seqs 16 --port 8000

要点:--kv-cache-dtype fp8 把 KV cache 也减半(仅 Hopper 及以上);--gpu-memory-utilization 不要贪 0.95+,给路由开销留头寸;上线前用 nvidia-smi dmon 确认各卡利用率均衡——一张卡 95% 其他卡 30%,就是专家路由失衡。

K3 首日部署检查清单

查许可证。去 github.com/MoonshotAI 找 Kimi-K3 仓库,读实际的 LICENSE 文件(重点:合成数据条款、有无 MAU 上限),别拿 K2 的许可证当依据。

确认格式再下载。看官方放的是 MXFP4、BF16+INT4 还是多种;确认磁盘和总内存装得下(BF16 是 5+ TB)再点下载。

查推理后端支持。先看 K3 仓库 README 列的受支持后端。KDA 内核大概率先出现在 Moonshot 自己的仓库和 FLA(Flash Linear Attention)库,主线 vLLM/llama.cpp 的整合预计要数周到数月。

小规模质量评测。跑一组自己业务的 prompt 评测(哪怕只有 10 条),确认量化质量,再考虑接生产流量。社区 GGUF/AWQ 量化会在数小时内出现,但 2.8T 规模的极限量化没有先例。

harness 兼容性。官方明确警告:K3 按「保留完整思考历史」模式训练,agent 框架若截断思考内容,生成质量会剧烈不稳定;也不要在会话中途从别的模型切到 K3。

05选型决策:什么情况才值得自托管

工程判断题,答案主要由钱和合规决定,不由情怀决定。

你的情况	建议	为什么
今天就要 K3 的能力进生产	用 API	官方 API $3.00/$15.00 每百万 token(缓存输入 $0.30);工具链空窗期没有别的生产级选项
推理月预算 < $500	永远用 API	自托管硬件月成本以万美元计
已有 8× A100/H100 以上集群	等权重、先跑分	先验证格式与后端支持,再决定迁移
需要领域微调	等权重	微调必须有权重;2.8T 全参微调不现实,LoRA 类方法为主,且「4-bit 底座 + LoRA」是社区待验证的新课题
合规要求数据不出域	等权重 + 预留工具链时间	自托管是唯一解;按 Q4 才生产可用来排计划

💰 盈亏平衡点(wan27.org 估算,按云租硬件口径)

最小可用 K3 集群(8× A100 80GB 级)云租金约 $15K–20K/月;要摊平这笔钱,日输出量需要稳定达到 100–150 万 output token/天以上。经验法则:月 API 账单持续超过 $15K 之前,别动自托管的念头——低于这个量级,自托管在硬件、人力、维护上全都更贵。

还有一条「中间路线」容易被忽略:如果你要的是「开源 + 自托管」而不是「非 K3 不可」,今天就能部署 K2.6(594 GB)或 K2.7 Code——同一个架构家族、同类许可证、vLLM 支持成熟。先用它们把管线跑通,K3 工具链稳定后(社区预期 Q3 末–Q4)再换权重,是风险最低的迁移路径。

06常见坑:首日翻车榜与许可证细节

wan27.org 根据 K2.6 发布时的社区翻车记录,预测了 7 月 27 日会重演的错误。别当分母。

三个最常见的首日错误

在不够格的硬件上开下 BF16 权重。5+ TB 的下载,磁盘、带宽、时间全浪费。先算账再下载。
默认 vLLM / llama.cpp 开箱即用。KDA 需要自定义内核,首批可用的推理脚本大概率来自 Moonshot 官方仓库和 FLA 库,不是主线框架。别急着给 vLLM 提 issue。
不验质量就上社区量化。1.8-bit 的 2.8T MoE 是无人区,质量退化可能远比小模型严重。任何社区 quant 先过自己的评测。

许可证的三个细节

📜 「Modified MIT」不是标准 MIT,别这样跟法务说

基于 K2 家族先例(K3 正式文本尚未发布,以下为预期):① 合成数据条款——用 K 系模型的输出去训练你自己的新模型,新模型不能继承这份许可证的条款;② MAU 条款(K2.7 Code 引入的先例)——月活超过一定门槛的大规模商用部署可能需要单独商业协议,如果你的应用 MAU 超过 10 万,现在就该让法务盯着;③ 微调衍生模型是否继承同一许可证,待正式文本确认。常规商用 + 署名是允许的。

其它已知限制(官方自己写在博客里的)

过度主动:遇到模糊指令时 K3 倾向于「替你做决定」而不是问你。需要边界感的应用要在 system prompt / AGENTS.md 里加显式约束。
体验差距:官方承认综合用户体验仍落后 Claude Fable 5 和 GPT-5.6 Sol。
幻觉率争议:Artificial Analysis 测得约 51%(第三方口径,官方未回应)。自托管后建议纳入自己的幻觉评测。

07学习资源清单

Kimi K3 官方技术博客(架构、基准、部署建议的一手来源):kimi.com/blog/kimi-k3
Moonshot GitHub(查 K3 仓库是否上线、读 LICENSE):github.com/MoonshotAI
Kimi-Linear(KDA 的完整开源实现,MIT):github.com/MoonshotAI/Kimi-Linear —— 想搞懂 K3 长上下文机制,从这里入手
K3 模型概览(HF 社区):huggingface.co/blog/ResterChed/kimi-k3-model-overview…
MoE 推理部署指南(显存公式、EP/TP、vLLM 配置):spheron.network/blog/moe-inference-optimization-gpu-cloud
K3 开源状态与自托管评估:wan27.org/blog/kimi-k3-open-source
FLA(Flash Linear Attention)库:KDA 内核最先落地的地方,盯它的 changelog 判断工具链进度

五个维度覆盖情况:「是什么 / 怎么算 / 怎么部署 / 怎么选型 / 有什么坑」均有多来源支撑;相对薄弱的是实战案例——权重今天才放出,尚无第三方成功自托管 K3 的公开记录,文中部署命令均来自同架构家族模型(DeepSeek/K2 系)的已验证配置。