post cover

技术热点落地：Kimi K3 开源 3T 级模型在 AMD MI355X 上的部署与成本优化（2026-08-02）

技术热点落地：Kimi K3 开源 3T 级模型在 AMD MI355X 上的部署与成本优化

热点来源：8/2 Wafer 发布《Running Kimi K3 on MI355X at Better Performance per Dollar Than B300》（HN 135 分 / 44 评论）：8× MI355X（TP8）单机跑 Kimi K3 达到 952 tok/s 聚合吞吐 / 118 tok/s 单流，每美元吞吐（48 tok/s/$）是 B300（33 tok/s/$）的约 1.5 倍。此前 AMD 已于 7/28 发布 Kimi-K3 Day-0 部署指南（ATOM 推理栈 + 现成容器镜像），把”开源 3T 级模型能否绕开 CUDA 生态”从口号变成了可复现的部署流程。

前情提要：

适用场景与目标

这个热点解决了什么问题？

Kimi K3 是 2.8T（2.78T）参数的开源权重模型：基于 Kimi Delta Attention（KDA）与 Attention Residuals，Stable LatentMoE 激活 16/896 专家，原生视觉 + 1M token 上下文。它的 checkpoint 混合 MXFP4/BF16 约 1.56 TB——一个 B200 节点（8×192GB）根本装不下，此前只有两条路：B300 节点（8×288GB），或两个 B200 节点拼 TP16（decode 关键路径要跨节点 all-reduce）。

MI355X 是除 B300 外唯一单机（8 卡）能装下 K3 的 288GB 显存卡，单卡均价约为 B300 的 1/2.4、B200 的 1/1.7。AMD 给了 Day-0 支持（镜像 + 启动命令），Wafer 又把它调到了可用的吞吐。对团队的意义：“买不到 B300 / 租不起 B300”不再是无法自托管前沿开源模型的借口。

适用场景

场景价值
要自托管 3T 级开源模型、但 B300 供给不足/超预算的团队单机 TP8 跑 K3，省掉跨节点 TP16 的复杂度与开销
长上下文（100K~1M）知识工作、批处理、离线分析容量型负载吃显存红利，每美元吞吐优先
做模型路由/分层（承接 7/31 方案）把”便宜的长上下文层”落到 MI355X 上，B300 只留给延迟敏感流量
评估”去 CUDA 化”可行性的平台团队用 AMD 官方 ATOM 栈 + sglang ROCm 分支做 PoC

不适合的场景

  • 首 token 延迟（TTFT）极度敏感的在线产品：长预填充下 MI355X 明显落后 B300（见下）。
  • 团队没有 ROCm/内核调试能力：Day-0 支持 ≠ 零调试，sglang 路线大概率要自己打补丁。

最小可行方案（MVP）步骤

前提条件

  • 8× MI355X（每卡 288GB HBM）单节点，ROCm 7.2.4+；或云上按需租 MI355X 实例（HF 上的 moonshotai/Kimi-K3 权重约 1.56TB，先规划存储与拉取带宽）
  • 商用前先读 Kimi K3 模型许可（开放权重 ≠ 开源，见坑 5）

步骤 1：算显存预算（先确认装得下）

权重（MXFP4+BF16 混合）        ≈ 1.5609 TB 总量
TP8 每卡权重                   ≈ 190.974 GiB
+ 1M-token 序列的 FP8 latent KV ≈ 205.401 GiB/卡
每卡剩余（288 - 205.4）        ≈ 82.6 GiB（留给 runtime 开销）

结论：8×MI355X 单机 TP8 可行，但没有余量再塞第二个模型——这是专用推理节点，别指望混部。

步骤 2：AMD 官方 ATOM 通道（先跑通再优化）

# 拉 Day-0 专用镜像（内含 K3 推理栈与配置）
docker pull rocm/atom-dev:rocm7.2.4_ubuntu24.04_py3.12_pytorch2.10.0_20260727_kimi_k3

步骤 3：配置运行时环境变量并启动 OpenAI 兼容服务

export ATOM_LOADER_USE_THREADPOOL=1
export ATOM_LOADER_THREADPOOL_WORKERS=16
export ATOM_SYNC_AFTER_LOAD=1
export ATOM_DIST_TIMEOUT_SECONDS=3600
export ATOM_USE_TRITON_GEMM=1
export AITER_USE_GROUPED_GEMM=0
export ATOM_USE_TRITON_MOE=0
export AITER_FLYDSL_FORCE=1
export AITER_FORCE_GFX1250=0
export ATOM_USE_UNIFIED_ATTN=1
export ATOM_FORCE_ATTN_TRITON=1

python -m atom.entrypoints.openai_server \
  --model moonshotai/Kimi-K3 \
  --kv_cache_dtype fp8 -tp 8 \
  --trust-remote-code \
  --max-model-len 16384 \
  --max-num-seqs 64 \
  --max-num-batched-tokens 10240 \
  --gpu-memory-utilization 0.93 \
  --block-size 128 \
  --no-enable_prefix_caching

步骤 4：正确性验证（AMD 官方路径）

先做 GSM8K 5-shot（1,319 样本） 全量验证（AMD 官方已在 TP8/16K 上下文下跑通），通过后再放开上下文长度。不要一上来就开 1M 上下文压测——先证明”输出是对的”，再证明”跑得快”。

步骤 5：sglang 通道压测（吞吐优化，可选）

如果走 sglang ROCm 分支追求更高吞吐（Wafer 路线），按”关键实现细节”第 2、3 节打好两个补丁，然后按 1,024-in/400-out 短输入与 172k 长预填充分别建基准（两个数字代表完全不同的负载画像）。

关键实现细节

1. 为什么 MI355X 能赢：容量即竞争力

K3 这种 1.5TB+ 的模型，“装得下”就是硬门槛。B200 节点装不下 → 被迫 TP16 跨节点 → decode 关键路径背 ~195 Gb/s（RoCE v2）的 all-reduce 税；MI355X 单机 TP8 没有这笔开销。Wafer 实测（1,024-in/400-out）：

配置单流 tok/s聚合 tok/s每卡 tok/s每美元 tok/s
8× MI355X（TP8，$2.50/卡时）11895211948
2×8 B200（TP16，$4.25/卡时）90498317
B300（TP8+DCP8，$6.00/卡时）1721,56819633

B300 绝对性能仍领先约 1.65×（聚合），但价格 2.4×——比的是每美元产出，不是最快。

2. ROCm 坑 A：speculative decoding 缺 top_k_renorm_prob

K3 自带 零草稿张量（无 MTP、无 EAGLE），唯一投机路径是外部 block-diffusion 草稿（Wafer 用的是 RadixArk 的 Kimi-K3-DSpark）。但 sglang 的 accept-sampling verifier 在 ROCm 上会炸：

NameError: name 'top_k_renorm_prob' is not defined. Did you mean: 'top_p_renorm_prob'?

原因：CUDA 构建从 sgl_kernel 导入 top-k renorm kernel，ROCm 构建只别名了一个 Triton top-p kernel，gfx950 上没有 top-k renorm 内核可别名——是”缺定义”而不是”缺内核”。修法是一个纯 PyTorch 函数（sort → masked_fill → rescale），塞进 sglang 的 ROCm sampling 分支即可，不需要自研 CUDA kernel：

def top_k_renorm(probs, k):
    vals, idx = probs.topk(k, dim=-1)          # 取前 k 高概率
    mask = torch.zeros_like(probs).scatter(-1, idx, 1.0)
    out = probs * mask                          # 其余置零
    return out / out.sum(dim=-1, keepdim=True)  # 重归一化

修好后收益：单流 ~2.2×、中等负载每流 ~1.7×、聚合 +18%，且峰值聚合出现在更高并发（c64 vs 无投机 c24）。

3. ROCm 坑 B：长预填充慢 2 倍——AITER MLA kernel 头数不匹配

同一个 172k token 冷预填充：MI355X 约 51s，B300 约 23s。根因不是缺内核而是形状不匹配：TP8 下每 rank 只有 12 个 attention 头，而 AITER 的 MLA 快速内核只支持 4、8 或 16 的倍数 → 回退到慢速通用 Triton attention（4~7k tok/s）。修法：把头数 zero-pad 12→16 跑快速内核，再裁回真实 12 头：

# 加载 AITER MLA 快速内核前：12 → 16（pad），输出后取 [..., :12]
q_padded = F.pad(q, (0, 0, 0, 0, 0, 4))   # head 维 12→16
out_padded = fast_mla_kernel(q_padded, ...)
out = out_padded[..., :12, :]

修好后快速内核约 13k tok/s vs 回退路径 47k，预填充提速 23×——这是纯 TTFT 杠杆，decode 不变，但”用户等第一个字的时间”直接减半。

4. AMD 官方栈 vs sglang：定位不同

AMD ATOM 的 Day-0 指南明确不承诺吞吐数字（“This post does not make claims about throughput, TTFT, TPOT”），它的价值是”能跑通 + 正确性验证”。要吞吐，走 sglang ROCm + 上面两个补丁（Wafer 路线）。建议 PoC 两路都跑，用同一基准对比后再定生产栈。

常见坑与规避清单

坑风险解决方案
拿”每美元吞吐”当”更快”选型决策被营销带偏绝对性能 B300 全胜，MI355X 只赢性价比；按负载类型选
用租赁时价当 TCO成本模型失真市场租价会波动（gpus.io 上 MI355X 现价 $2.95/时），要做 MSRP/租约/电力/维护的全口径 TCO
只测 1,024 短输入基准1M 上下文负载下结论完全相反长短输入分测：decode 看短基准，TTFT 看 172k+ 长预填充
以为”Day-0 支持 = 开箱即用”卡在框架 bug 上几天预期要打 1~2 个补丁；没有 ROCm 调试能力就别上 sglang 路线
把开放权重当开源商用合规翻车K3 无训练数据/训练代码，读 Kimi K3 License 再商用
单节点塞不下硬塞TP16 跨节点后性能崩先算显存预算；装不下就换 MI355X/B300 单机，别用 TP16 硬撑
只听一家供应商的基准数字被利益相关方修饰交叉验证：AMD 官方指南 + 社区复现 + HN 讨论中的质疑

⚠️ 坑 1：基准的”帧”选错了

问题：1,024-in/400-out 的短输入基准下 MI355X 很好看；但同一模型上 172k 冷预填充 MI355X 要 51s、B300 只要 23s。如果你的产品是”喂长文档 → 等第一个字”，短输入基准会骗你下单。

解决方案：基准必须分两档——decode 用短输入测聚合吞吐；TTFT 用你线上最长的 P90 输入长度测冷/热预填充。两条曲线都画出来再决策。

⚠️ 坑 2：把租赁时价当全成本

问题：$2.50 vs $6.00 是发布时的市场租价。HN 评论指出 gpus.io 上 MI355X 现价已到 $2.95/时，且 B300 供不应求导致溢价——用某一天的 spot 价算”赢 1.5 倍”不稳健。

解决方案：至少做三档测算——按需租（时价）、预留实例（年约）、自购（MSRP + 电力 + 折旧 + 维护人力）。结论大概率仍是 MI355X 赢性价比，但赢多少要看你的采购方式。

⚠️ 坑 3：供应商基准的立场问题

问题：Wafer 是卖推理服务的供应商（HN 上被质疑过 WaferPass 定价反复、基准口径），其数字”每行 B300 都赢，唯独每美元赢”的叙事有营销成分。

解决方案：把它的数字当”上界参考”，用 AMD 官方 Day-0 指南（只承诺正确性）+ 自己复现的基准做决策依据。可复现性（是否公开代码/配置）是判断基准可信度的第一指标。

⚠️ 坑 4：忽略”开放权重 ≠ 开源”

问题：K3 只开放权重，没有训练数据与训练代码；许可证是自定义的 Kimi K3 License（GitHub 上标 NOASSERTION）。“开源”称呼在 HN 上已被专门纠偏。

解决方案：商用前逐条读 License（尤其商用限制、衍生品条款）；对外宣传用”开放权重（open-weight）“措辞。

成本 / 性能 / 维护权衡

维度8× MI355X（TP8）2×8 B200（TP16）B300（TP8+DCP8）
单流 decode118 tok/s90 tok/s172 tok/s
聚合吞吐952 tok/s498 tok/s1,568 tok/s
每美元吞吐48 tok/s/$7 tok/s/$33 tok/s/$
参考时价~$2.50-2.95/卡时~$4.25/卡时~$6.00/卡时
单机可装 K3✅❌（需 2 节点）✅

权衡要点：

  • 成本：MI355X 的赢面在”容量 × 单价”——同样能装 K3，单机成本约为 B300 方案的一半以下；但省下的钱会部分变成”调 ROCm 的工程师工时”。
  • 性能：绝对吞吐 B300 领先 1.65×；但 MI355X 单机省掉了 TP16 的跨节点 all-reduce 税。并发敏感型批处理（c64+）是 MI355X 的主场，低延迟交互是 B300 的主场。
  • 维护：ROCm 生态 Day-0 支持仍落后 CUDA——ATOM 是 AMD 官方栈（更新快、文档少、不承诺性能）；sglang ROCm 分支需要自己打补丁。团队要预留”框架调试”预算。
  • 架构建议：承接 7/31 的分层路由思路——长上下文/批量/成本敏感流量路由到 MI355X 池，延迟敏感流量留在 B300 池，两池共享同一 OpenAI 兼容 API 面。

一周内可执行行动清单

  • Day 1：资源核算——确认权重 1.56TB 的存储/拉取方案，用”每卡 ~205.4 GiB（权重+1M KV）“公式验证 MI355X 单机 TP8 预算
  • Day 2：拉 AMD ATOM Day-0 镜像，按文中的 env + 启动命令把 OpenAI 兼容服务跑起来（先 16K 上下文）
  • Day 3：GSM8K 5-shot（1,319 样本）正确性验证；同时跑一个 1,024-in/400-out 冒烟基准记录基线
  • Day 4：用真实负载测 TTFT——拿你线上 P90 输入长度做冷预填充测试，和 B300 数据对比，判断负载画像是否适合 MI355X
  • Day 5：评估 speculative decoding——接外部 DSpark 草稿；遇 top_k_renorm_prob 报错就按文中补丁修复，复测单流与聚合收益
  • Day 6：做三档 TCO（按需租/年约/自购）对比 B300；用真实采购价重算 tok/s/$，别用新闻稿的 spot 价
  • Day 7：并发扫描（c24→c64）找峰值聚合点；通读 Kimi K3 License 确认商用合规；写部署文档（镜像、env、补丁、基准脚本）

参考资源

写在最后：这篇热点真正的信号不是”AMD 赢了”或”B300 输了”，而是开源 3T 级模型的推理成本第一次出现了”非英伟达可选路径”：MI355X 的 288GB 容量让 K3 可以单机 TP8 部署，把”装得下”的成本打下来一个数量级。但别被每美元吞吐的单行数字带跑——先分清你的负载是”等第一个字”还是”等最后一批结果”，再决定要不要把预算押给 AMD。工具链在追平，坑也在变少，但基准要自己跑、TCO 要自己算，这两件事没有任何供应商能替你完成。