三个模型，三类硬件压力

建议阅读路径

先记住这四个判断

架构参数对照

来源：官方模型卡、官方 config.json、Kimi K3 Technical Report；仓库载荷通过 Hugging Face Models API 的 blob size 汇总，快照日期见页顶。

不要用一个 “TOPS” 比较三者

权重能否装入一组卡：第一轮筛选

论文地图：只沿推理主线阅读

CED 原理：Prompt 不再走完整 Decoder

40 层 causal Transformer 被重写为 20 层 causal encoder 与 20 层 autoregressive decoder。关键不是普通 encoder-decoder cross attention，而是 decoder 各层的 global KV 都从 encoder 最终状态 H20 直接产生；decoder 自身仍保留逐层 SWA，所以 decode 的表达深度没有被简单砍半。

对架构的直接含义

CSA2 原理：同时压缩 Token 维与 Layer 维

普通稀疏注意力只减少被读出的 token；CSA2 还让多层共享 main KV、indexer K 和 Top-K 结果。每层仍生成自己的 query 与 128-token SWA KV，因此“共享”只发生在 global branch，不破坏局部细粒度路径。

论文给出的实际层编排

Global attention 使用 64 个 query heads、head dimension 512；indexer 为 32 heads × 128 dimension，最终选择 Top-512。首个 decoder Full 层还按 block 内最大 score 选 2,048 个 block，每块 8 个 position，形成最多 16,384 position 的共享候选池。后续 Reindex 层只在这 16K 项上评分，因此 1M context 下深层 indexer 的计算量不再随上下文长度增长。

FP4 Main KV：重点是解码路径，不是 FP4 GEMM

论文选择 E2M1 数据配每 16 channel 一个 E4M3 scale，省去二级 global scale；main KV 在 RoPE 之后量化，attention 之前反量化。也就是说，硬件无需用这种格式直接做矩阵乘，但必须能以极低代价完成 load → unpack → scale → sparse attention。SWA KV 因精度更敏感仍保留 FP8。

Bounded Replay：用固定重算换掉海量持久化 SWA

SWA 状态跨层传播，数学上精确恢复 40 层 SWA 需要回放 L × nwin token。V4.1 接受训练感知的近似：只回放命中点前最近 128 token，并截断到 replay segment。这样 persistent cache 只需保存 global KV。

Engram：196B 参数变成随机查表系统

两处 Engram 位于第 1、14 层，每处使用 n-gram 阶数 {2,3,4}、8 个 hash heads，每 head 约 16M entries，每个阶数总 embedding dimension 为 2048；table 与 KV projection 都是 FP8。地址只由输入 token 决定，因此可以在 backbone 计算前预取，但其性能取决于地址分布而非 GEMM 峰值。

Single-Pass mHC：Residual 也必须按字节优化

mHC 维护 n=4 条 residual streams。原 V4 的多 pass 实现需要 residual update、系数预测和 input mixing 三次 kernel；V4.1 将 input mixing 系数错后一层，使所有输出可在一次遍历中产生。

DSpark：验证长度是一个在线调度问题

DSpark 用 3 个带 128-token sliding window 的 Transformer block，一次并行给出 5 个 draft position 的 base logits；轻量 Markov head 补回块内依赖，confidence head 估计每个位置的条件接受率。调度器把 prefix survival probability 与实测 engine throughput curve 结合，为每条请求选择不同 verification length。

最终形成的算力卡需求

论文地图与单 token 执行图

mHC：为什么 Residual 从加法变成受约束路由

标准 residual 只有一条宽度 d 的状态；mHC 将其扩为 nhc × d，在进入 block 前用 A 混成一条输入，block 输出再由 C 写回多条流，同时 B 在流之间搬运旧信息。V4 Pro 中 nhc=4。

稳定性的关键是把 B 投影到双随机矩阵的 Birkhoff polytope：所有元素非负，且每行、每列和为 1。这样谱范数不超过 1，多层相乘也保持在同一集合内；A 用 sigmoid 约束在 [0,1]，C 用 2·sigmoid 约束在 [0,2]。B 通过 exp 后执行 20 次 Sinkhorn 行/列归一化得到。

CSA：先把 1M Token 压成 250K，再只读 1024

CSA 不是简单 block pooling。每个压缩条目由当前 4-token block 的 A 分支与前一 block 的 B 分支共同贡献，两个分支各自产生 KV 与逐 channel compression weights，经 softmax 后加权形成共享的 compressed KV。相邻输出存在重叠，最终序列长度仍是原来的 1/4。

Lightning Indexer 将 query 先下投影到 1536，再升到 64×128 的 indexer heads。每个 head 做 Q·K，ReLU 后由 token-dependent head weight 加权求和，得到每个 compressed position 的 score，随后 Top-1024 进入主 attention。

为什么是 Shared KV MQA 与 grouped output

被选中的每个 compressed entry 同时作为 key 和 value，供 128 个 query heads 共享。直接把 128×512=65,536 维 attention output 投回 7,168 代价过高，所以先分 16 组、每组投到 1,024 维，再做最终 projection。算力阵列必须覆盖这类“宽输入、分组中间层”的非标准 GEMM。

HCA：压到 1/128 后做 Dense Attention

HCA 去掉 indexer 和稀疏选择，每 128 个 token 以逐 channel 权重合并成一个条目；1M context 只留下 8,192 个左右的 global summaries。它保留全局覆盖，弥补 CSA Top-K 可能漏掉的信息，但分辨率较低。

FP4 推理：专家权重与 Indexer QK 是两条不同路径

Post-training QAT 把 MXFP4 用在两处：占据绝大多数容量的 MoE expert weights，以及 CSA indexer 的 Q/K cache 与乘法；index score 随后从 FP32 压到 BF16。论文报告这一 score 优化使 Top-K selector 获得约 2× 加速，同时保持 99.7% KV recall。

MoE：通信应被计算完全覆盖，而不是单独排队

论文的 MegaMoE 将专家切成 waves：当前 wave 做 Linear-1/2 时，同时拉取下一 wave 的 token，并发送上一 wave 的结果。与只在两端重叠的做法相比，通信、GEMM、activation/combine 在稳态同时工作；论文在多平台上报告 1.50–1.73× 一般推理加速，延迟敏感场景最高 1.96×。

异构 KV：PagedAttention 的同构假设已经失效

每个 request 同时有固定大小的 state cache 与可增长的 classical KV cache。state cache 保存各层 SWA 最近 128 项，以及 CSA/HCA 尚不足一个 compression block 的 uncompressed tail；classical cache 保存已经压缩完成的 CSA/HCA 条目和 indexer KV。

持久化到 SSD 时，CSA/HCA 完整压缩块可以直接复用，尾部不完整块必须重算。SWA 有三种策略：全量存储、周期 checkpoint 或完全不存；它们分别交换写放大、尾部重算和恢复延迟。runtime 的 cache policy 必须按状态类型配置，不能用一个统一 LRU。

容量、并行与单 token 下界

V4 Pro 算力卡签核表

3 KDA + 1 Gated MLA：重复 23 次的基本节拍

93 层由 69 个 KDA 层和 24 个 Gated MLA 层构成。KDA 用固定大小 recurrent state 表达长历史，MLA 保留随序列增长的 KV cache，二者的分配、分页、prefix hit 和跨节点迁移语义完全不同。

Stable LatentMoE：通信维度下降，fan-out 上升

Hidden size 为 7168，LatentMoE routing/专家交换维度为 3584；896 routed experts 中每 token 激活 16 个，另有 2 个 shared experts。相比直接在 hidden 维度 dispatch，latent 表示降低单份 activation 大小，但 top-16 仍显著放大网络数据。

如果 92 个 MoE 层都发生同等级交换，collective engine、NoC injection rate 和拓扑拥塞将直接决定 tokens/s。Kimi K3 特别适合用来检验算力卡是否真的为 MoE 设计，而不只是有一个高峰值 Tensor Core。

MXFP4 是架构能力，不是文件格式复选框

容量现实

官方 vLLM recipe 将 B300 作为默认硬件，并提供 H200/B200/B300/GB200/GB300/MI355X 等配置。部署到自研卡时，应优先保证 8 卡域内权重与 runtime state 可完全驻留；如果必须跨节点，expert placement 和 all-to-all fabric 需要成为系统设计中心。

Serving runtime 还需要理解 thinking history

Kimi K3 始终启用 thinking，并要求多轮对话把先前 assistant message 的 reasoning_content 与 tool_calls 原样带回。这会增加上下文增长速度，改变 prefix cache 命中和 admission control；不能只按用户可见 content 估算 session token。

四层分析框架

参数路径计算下界

Prefill：算力、SRAM 复用与长序列调度

Prefill 的 GEMM M 维约等于 token 数，矩阵阵列容易获得高利用率；但 1M context 不会作为一个 GEMM 一次执行。runtime 使用 chunked prefill，把请求切成固定 token budget，与 decode batch 混排。

架构师需要收集的 trace

• 每个 chunk 的 token 数与 padding 比例；
• 每层 GEMM 的 M/N/K 分布，而不是平均 shape；
• CSA candidate 数、Top-K、实际 gather cache-line utilization；
• KDA chunk size、scan depth、state bytes 与 SRAM residency；
• prefill 与 decode 混排时的队列等待和抢占成本。

Decode：先画 bandwidth roof，再画 compute roof

以 accepted token 为最终归一化单位

开启 DSpark/MTP 后，“模型 forward token”和“用户得到的 token”不再相等。所有计数器都应同时提供 per step、per drafted token、per accepted token 三种归一化。

完整容量方程

四级存储不是“自动分层”

每一级迁移都必须由 runtime 的可观测状态驱动。仅把 tensor 标成 “offload” 会把平均延迟问题变成 P99 抖动问题。

互联流量的三种来源

卡级接口建议

并行维度速查

拓扑优先的 rank 布局

• TP collective 不应无意跨越低带宽 NIC；
• EP expert placement 要结合真实路由共现矩阵，而不是轮询分配；
• shared expert、embedding、LM head 的复制成本要单独记账；
• 多 rail 网络需要 rank-to-NIC affinity，避免所有 all-to-all 落到同一 rail。

三个模型的起始映射

这不是通用最佳配置，而是用于建立第一个可工作的 baseline。最终布局必须由目标卡容量、scale-up 拓扑和生产请求 trace 驱动。

参考卡级框图

数值数据通路

片上存储应该缓存什么

专家权重总体不可能放入片上 SRAM，但 decode batch 内的 expert temporal locality 可以形成小型 victim cache。是否值得加入，要从 router trace 测量重复命中，而不是凭直觉。

按模型检查 primitive 覆盖

建议的分层 IR

Kernel 优先级

Runtime 与编译器的边界

一个实用实现是预编译 shape bucket 与 kernel family，runtime 根据当前 token 数、expert histogram、cache 状态选择 variant，而不是 JIT 整张模型。

自研卡接入现有 serving engine

1. Platform backend

   设备枚举、allocator、stream/event、P2P、collective 与 graph capture 能力声明。

2. Tensor / operator backend

   PyTorch device 或独立 runtime；实现 dtype、storage、view、copy 与必要 fallback。

3. Attention backend

   Paged KV、CSA2/KDA/MLA 自定义 backend；暴露 block size 与 metadata builder。

4. MoE backend

   router、token permutation、grouped GEMM、combine；与 EP communicator 对接。

5. Worker executor

   rank 启动、模型加载、健康检查、profile run 与 memory snapshot。

6. Model parser

   chat template、reasoning/tool parser、multimodal processor 不能被遗漏。

九阶段闭环

Artifact contract

model_bundle/
├── manifest.json          # revision, hashes, license, source URLs
├── config.json            # 原始配置，不在转换时“顺手修改”
├── tokenizer/             # vocab, merges, chat template
├── processor/             # vision / multimodal preprocessing
├── weights.index.json     # tensor → source shard
├── device_weights/        # layout + TP/EP placement + scales
├── graph_manifest.json    # layer types, custom ops, state schema
└── validation/
    ├── golden_inputs.npz
    ├── golden_intermediates.npz
    └── tolerances.yaml

converter 必须可重复、可版本化、可逆向追踪：设备 tensor 的每一段都能映射回原始 safetensors key 和量化 scale。

先建立 GPU baseline

逐层数值验证

完成定义

• 目标模型 revision 的完整权重可加载，不依赖未记录的 host fallback；
• 至少覆盖 greedy、thinking、tool call、多轮、长上下文和多模态（适用时）；
• 固定 workload 下 token 输出与 golden 满足定义的数值准则；
• 每个主要 kernel 有 roofline 与硬件计数器解释，性能差距可归因；
• OOM、collective timeout、坏页、设备 reset 有明确错误路径；
• 连续 24–72 小时 soak 无泄漏、无 page corruption、无 silent hang。

如何使用结果

1. 容量不通过：增加卡数/单卡 HBM、改变并行、offload Engram，或选择更小模型；不要先优化 kernel。
2. 容量刚通过：至少再留一个真实 workload 的 KV 峰值和 graph bucket；低于 10% 余量通常不是生产配置。
3. 带宽过高：增加 decode batch、低精度、expert locality 或 speculative decoding；同时检查 TPOT。
4. 计算过高：看 prefill/vision/KDA/attention 占比，再决定增加阵列还是特殊引擎。

建议的硬件计数器

性能分解模板

上图是格式示例，不是任何目标模型的实测值。实际报告应按 prefill、decode、vision、cache-hit/miss 分组，并同时给均值和 P99。

必须覆盖的异常路径

签核顺序

一级来源：模型发布方

二级来源：Runtime 实现

本站推导项

更新策略