开权重模型自部署：从 checkpoint、量化、TP/EP 到 P/D，不把参考命令当生产拓扑

1. 先判断能否自部署，再谈怎样部署

提供 API 不等于发布了可自部署 checkpoint。下表只收录已有官方权重或实现入口的模型，并把可验证的 engine 配置和未披露的内部服务拓扑分开。

Qwen3.7、闭源 GPT 和闭源 Grok 只能讨论托管 API；Qwen3.5、gpt-oss 与 Grok-2 才有可执行的权重和 engine 路径，所以不能放在同一张自部署表里比较。

2. 自部署的四本账：参数、状态、通信、控制

模型跑通只是第一步。若只报 B200/H100 数量或参数量，KV 峰值、热门 experts、P/D 传输尾延迟和工具暂停后的恢复都没有进入容量计划。

3. 精度、分片与 MTP：为什么显存计算不能只乘参数量

以 BF16 粗算，静态权重约为 2 bytes × total parameters，再加量化 metadata、加载冗余和 runtime buffer；FP8/FP4/INT4 会降低这部分，但对应 kernel、量化方式和精度边界不同。KV 另按层数、KV heads、head dim、token、精度和并发累加。对于 MLA/DSA/CSA/MSA 等模型，还可能出现 compressed KV 或 index cache，不能直接照普通 MHA 的字节公式套用。

MTP 或 speculative decoding 也不等同于‘开关后更快’。它增加 drafter、验证 batch 和短期 KV；只有 accepted prefix 减少的目标模型 decode 数足以覆盖这些代价时，端到端 latency 才改善。

4. 各家公开部署配方如何读

GLM

GLM-5/5.2 模型卡列出 vLLM、SGLang、xLLM、KTransformers、MTP/EAGLE 和版本要求。这些资料说明 index-aware long-context 依赖哪些 engine feature，不代表 Z.ai 的线上布置。

Kimi

K2/K2.5 guide 给出了相当具体的 MoE 配置：FP8、TP/DP+EP、DeepEP/DeepGEMM、P/D disaggregation 和 IB 都有公开示例。这只是特定硬件假设下的一种 mesh，不能概括成“所有 1T MoE 都要 4P12D”。

Qwen / Hy3 / DeepSeek

Qwen3.5/3.6 recipes 包含 MTP、prefix cache、tool/reasoning parser；Hy3 preview 标出 TP8 和 MTP；DeepSeek 各版 README 又会随 MLA、DSA、V4 CSA/HCA 或 OCR 输入变化。tokenizer、config 和 supported engine 必须按 checkpoint 锁定，不能串用 flags。

MiniMax / Gemma / gpt-oss / Grok-2

这些资料覆盖 MTP、QAT、MSA、多模态 processor 和开权重 API 兼容。相同品牌下的闭源产品仍属于托管 API。Gemma 的官方权重显存表明确不含 KV，正好提醒部署者不要把权重容量当成总显存。

5. P/D 分离何时有用，何时只是增加一个网络故障点

Prefill 以大矩阵与长 prompt 为主，decode 以每 sequence 的小 batch、频繁读 KV 为主；两者可能需要不同 GPU、batch 和调度策略。P/D 分离在负载相差大、KV 可高效转移、路由能命中已有状态时有机会提高利用率。但是它引入状态序列化、带宽、传输 tail、目录一致性与恢复协议。

1. 用不可分离基线测 TTFT / TPOT / p99 和 GPU 利用率。
2. 定义可迁移的 KV identity：模型、revision、tokenizer、rope/context 规则、精度、prompt hash、block layout。
3. 测传输的 p50/p95/p99，包含拥塞、abort、retry 和 cache miss。
4. 只在端到端 SLO、成本与故障恢复都改善时保留 P/D。

这是链接到 数据中心 KV 与 P/D 的原因：模型命令行里的 P/D flag 不能代替全局 state directory。

6. 上线前的验证清单

1. 固定 checkpoint SHA、engine version、CUDA/driver、tokenizer、chat template 和 quantization。
2. 短 prompt 先做输出/工具格式 smoke test，再梯度扩到 32K、128K、目标上限与并发。
3. 分开记录 weights、KV、index/visual state、workspace 和 fragmentation 的峰值。
4. MoE 记录 expert routing histogram、dispatch/combine 时间与跨节点字节；TP 记录 collective 时间。
5. 投机记录 draft/accept/reject/verify 及端到端 TPOT。
6. 故障演练包括 worker loss、KV miss、P/D transfer abort、网络退化和 engine restart。
7. 将基线、版本、输入分布和完整指标写入可重放报告。

7. 基准设计：不能用一条启动命令替代容量曲线

每个 self-host 模型都应有至少三条曲线：固定并发下 context 增长的 TTFT/KV；固定 context 下并发增长的 TPOT/p99；固定质量约束下 MTP/quantization/EP 的 cost-latency Pareto。测量还要保留 cache warm/cold、media input、tool rounds 和 failure injection。否则一个短 prompt 的 tokens/s 会掩盖生产中最昂贵的状态与网络条件。

8. 从 notebook 到服务：一份可审计运行手册

1. 将模型 revision、engine/container digest、driver、NIC firmware、mesh、量化和参数记录为不可变 manifest。
2. 为 tokenizer/template/processor/adapter 计算兼容性签名，并将其写入 prefix/KV identity。
3. 为每个模型保存 baseline workload、容量阈值、overflow/eviction policy、SLO 和 rollback revision。
4. 把 benchmark、profile、日志和失败演练作为 release artifact；出现回归时先比对 manifest 而不是猜模型变了。

9. 一手来源