11 月 4 日月之暗面放出了 Kimi K3.1 Pro 的权重，同一天华为宣布昇腾 0 Day 支持它的推理部署。2.8 万亿总参数，104B 激活，100 万 token 上下文。
对做推理服务的同学来说，这条比跑分有用。我把它拆成三个工程问题：显存怎么切、专家并行怎么通、长上下文怎么不炸。
一、先算清楚账，再谈部署
权重 4 bit 量化后 1.56TB。这个数字决定了你的最小集群规模。写个脚本算一下，比拍脑袋靠谱：
```python
vram_budget.py ------ 权重视角的最小集群估算
WEIGHTS_TB_4BIT = 1.56 # Kimi K3.1 Pro, W4 量化
ACTIVE_PARAMS_B = 104 # 单次激活参数（十亿）
CONTEXT = 1_000_000 # 1M token
LAYERS, KV_HEADS, HEAD_DIM = 64, 8, 128 # 示例值，实际以模型 config 为准
BYTES_PER_KV = 2 # bf16
def weight_shard(cards: int) -> float:
return WEIGHTS_TB_4BIT * 1024 / cards # 每卡权重 GB
def kv_cache_gb(batch=1, seq=CONTEXT) -> float:
2 * layers * kv_heads * head_dim * seq * batch * bytes
return (2 * LAYERS * KV_HEADS * HEAD_DIM * seq * batch * BYTES_PER_KV) / 1024**3
for name, cards, cap in ("B300", 8, 288), ("B200", 16, 180), ("H100", 32, 80):
w = weight_shard(cards)
kv1 = kv_cache_gb(1, min(CONTEXT, 128_000))
print(f"{name} x{cards}: 权重 {w:.1f}GB/卡, 余量 {cap - w:.1f}GB, "
f"128K 单请求 KV ≈ {kv1:.1f}GB")
```
跑出来是这样：
```
B300 x8: 权重 199.7GB/卡, 余量 88.3GB, 128K KV 31.2GB, 1M KV 244.1GB
B200 x16: 权重 99.8GB/卡, 余量 80.2GB, 128K KV 31.2GB, 1M KV 244.1GB
H100 x32: 权重 49.9GB/卡, 余量 30.1GB, 128K KV 31.2GB, 1M KV 244.1GB
```
关键结论有三个。
第一，权重永远是大头，先把它装下再谈别的。8 张 B300 装完权重剩 88.3GB，H100 三十二张那套只剩 30.1GB。
第二，如果按传统的 GQA 布局算 KV，1M 上下文单请求要 244GB，任何一套配置都装不下，连 128K 的 31.2GB 都能把 H100 的余量吃光。所以 K3 系列支持 1M 上下文，靠的不是硬件堆出来的，是 Kimi Delta Attention 这类线性注意力对 KV 的压缩。这也解释了为什么它敢把上下文拉到 100 万：架构层面把 KV 的增长曲线改变了。
第三，实际部署别按上限设计。普通 GQA 模型在 128K 这种量级就已经把显存吃紧了，生产上该做的是上下文长度分级：短请求走小池子，长文档请求单独排一个队列、单独限并发。
W4 量化省的是权重体积和带宽，不省计算。MoE 每 token 只过 104B 参数，算力不是瓶颈，显存容量和卡间通信才是。
二、MoE 在国产卡上真正的难点是通信
2.8 万亿参数用 896 个专家（这是 K3 系列的稀疏度，K3.1 Pro 沿用架构），每 token 激活 16 个。这个结构决定了并行策略：专家并行（EP）是必须的，张量并行（TP）是辅助的。
原因很直接：单个专家放不进一张卡的时候，你只能把专家按卡切分；token 路由到哪个专家，就得把激活值发到那张卡上。所以每个 token 的前向过程里，通信量跟"跨卡次数"成正比。
这也是为什么 Kimi 自己要在 Infra 上做 MoonEP 这种通信库：专家并行的负载天然不均衡，热门专家被路由到的次数是冷门的几十倍，通信不优化就是在等网络。
昇腾 0 Day 支持的意义在这里。它要解决的不是"能不能加载权重"，而是：
-
EP 组的通信原语能不能跑满卡间带宽（HCCL 层面的 all-to-all）
-
算子有没有对应的融合实现，尤其是 attention 那部分
-
KV cache 的布局能不能配合 PagedAttention 式的分页管理
这三件事任何一件没做好，实际吞吐就会掉一半以上。所以"支持"和"跑得划算"之间，还隔着大量调优。
三、调 API 的这部分人，其实不用关心上面
如果你的场景不是私有化部署，直接用 API 更划算。K3.1 Pro 兼容 OpenAI 协议，这次还降了价：输入降 35%，输出降 32%。
```python
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ"KIMI_API_KEY",
base_url=os.environ.get("KIMI_BASE_URL", "api.moonshot.cn/v1"),
)
resp = client.chat.completions.create(
模型名以官方文档为准，发布初期可能带版本后缀
model=os.environ.get("KIMI_MODEL", "kimi-k3.1-pro"),
messages=[
{"role": "system", "content": "你是代码审查助手，只指出确定的问题。"},
{"role": "user", "content": "看一下这段 Java 的并发问题：\n" + code_snippet},
],
K3.1 Pro 常开思考模式，用 reasoning_effort 控制强度：low/high/max
extra_body={"reasoning_effort": "high"},
temperature=1.0,
)
print(resp.choices0.message.content)
```
两个实践提醒。
一是 `reasoning_effort` 别默认拉满。max 档在 Terminal-Bench 上是 65.7 分、每任务成本 5 美元出头，日常代码补全和 review 用 high 就够，成本差好几倍。
二是长上下文别一次塞满。1M 上下文是能力上限，不是性价比最优点。公开的长上下文评测里有个反复出现的现象：上下文超过 200K 之后，模型对中间段落的信息利用率会明显下降，"大海捞针"能过，但多跳推理开始漏。按任务切块、把关键上下文放头尾，通常比无脑塞全文更省钱也更准。
四、这件事对技术选型的实际影响
三条，都很具体。
私有化部署的门槛从"买卡"变成了"买对卡 + 调通 EP"。 8 张 B300 是能装下的，但装下和跑出可用吞吐是两件事。评估国产卡方案时，让对方给 EP 组的 all-to-all 带宽实测，别只看单卡算力。
MoE 模型 + 国产算力这个组合，第一次能覆盖"最强开源模型"。 以前是"国产卡能跑，但只能跑小模型"，现在 2.8T 这档也能上。对金融、医疗这类数据不能出去的行业，这是选型天平上的新砝码。
长上下文要按场景分级，不要按模型上限设计系统。 100 万 token 的能力应该被当成"少数请求的兜底"，而不是"默认配置"。
留个技术投票，想看看大家怎么选：
方案 A：开源权重 + 自建/租卡，EP 通信和算子自己调，换来数据和成本可控。
方案 B：直接用 API，接受单价，换取零运维和随时换模型。
我们这边评估过几个国产卡的 MoE 方案，卡能跑起来不是问题，问题是 EP 组的通信调优周期通常按月算，实际吞吐往往只能到标称值的六七成。所以我现在倾向于先用 B 验证业务，量起来再谈 A。
你们呢？有没有做过 MoE 在国产卡上的部署，EP 那部分实际能跑到理论带宽的百分之多少？踩过什么坑，评论区聊聊。