模型部署
14 篇文章
- 上手篇：把 V4.1-Flash 跑起来从零到发出第一个请求的完整清单：镜像只能选 nightly、环境变量照抄哪几行、启动参数逐条拆解、验证为什么必须发两条请求（正确答案 323）、thinking 默认开着会把小 max_tokens 的请求变成空回复、四个性能旋钮、内核生态速查（FlashInfer/CuTeDSL/DeepGEMM/AITER/MFMA/gfx942/gfx950/CUDA graph/torch.compile）、硬件选型与 KV cache offloading。
- PD 分离、NIXL 与 vllm-router：prefill 和 decode 为什么分居prefill 吃算力、decode 吃带宽，混跑会互相踩脚。官方唯一验证过的进阶布局就是把它们物理隔离：GB200 NVL4 上每角色一台 tray、池内 TP4、KV 经 NIXL 交接、前面由 vllm-router 分发，并把并发限制在 32。还包括为什么这台模型的 KV 小到可以搬，以及开投机解码必须两个池子一起开的原因。
- 并行三兄弟：TP / DP / EP(DEP)一张卡装不下 511 GB 时必须切，但切法有三种：TP 切层内权重（每层都要通信）、DP 复制模型切数据（不省显存）、EP 把专家分卡（all-to-all）。对比 H200 / MI355X / MI325X / Blackwell 的默认配置，看同一份模型为什么在不同卡上得出完全不同的答案，以及 DEP 一次性打开了哪四样东西。
- 猜 5 个再验一遍：投机解码与 DSpark 草稿头decode 是带宽瓶颈，搬一次权重只写一个字太浪费。投机解码让草稿器先猜 5 个 token，再由主模型一次验证——DSpark 是三阶段（每阶段 128 专家取 3）、读取第 37–39 层注意力输入的小模型。还包括 AMD 上必须关掉自适应验证的两个具体检查，以及 --max-cudagraph-capture-size 里 128×(1+5) 的由来。
- BF16/FP8/MXFP4/MXFP8/UE8M0：数字格式与 511GB 显存账本"MXFP4 量化"翻译成人话就是一个参数半个字节。把官方 511 GB 的账本逐项算一遍：专家 259.5 GiB、Engram 183.1 GiB，而光"块 scale"就要占 21.9 GiB。顺带说明数字格式如何决定硬件能不能跑（MI325X 没有 FP4 MFMA，MXFP4 专家只能走 Triton），以及 GB 与 GiB 之间那 7% 的差异。
- 1M 上下文怎么来的：RoPE、YaRN 与 theta这台模型只在 65,536 token 的训练窗口里见过世界，却提供 1,048,576 的上下文：65,536 × 16 = 1,048,576，那个 16 就是 YaRN 的 factor。从 RoPE 的旋转直觉讲到"模型内部有两套位置刻度"——压缩 KV 为什么要用自己的 theta 160,000，以及你能调的其实只有 --max-model-len。
- 超连接与 Sinkhorn：残差流为什么要开四条副本残差连接从"系数恒为 1 的一条线"变成"4 份并行副本 + 每层自算 pre/post/combine 系数"，再用 20 次 Sinkhorn 迭代把混合矩阵压成双随机矩阵。顺带解释官方 Prerequisites 里那句看起来毫不相干的 mHC + AITER 说明，以及为什么 AMD 镜像必须够新。
- Engram：给模型配一本 384M 行的词组小抄这台模型里唯一不参与"思考"的大块参数：第 1、14 层各有一张 384M 行 × 256 维的哈希表，用 2/3/4-gram 哈希查表，通过学习的门写进残差流。196.6B 参数、183 GiB 显存，也是唯一适合 offload 到 CPU 内存的部分——但"输出不变"不等于"速度不变"。
- 附录：vLLM DeepSeek-V4.1-Flash 部署说明中文全译vLLM Recipes 官方页面 deepseek-ai/DeepSeek-V4.1-Flash 的逐节中文翻译：从 Overview、Context length、Images，到 Prerequisites、Verifying、Performance tuning，以及 MI355X / MI325X / H200 / Blackwell 的并行配置与 KV cache offloading。命令、参数、链接保持原样，是整个系列的事实底稿。
- 两级稀疏注意力：滑窗、压缩 KV latent 与 indexer1M 上下文凭什么可行：每层 128 token 滑窗看近处，压缩 KV latent 看远处，indexer 用 2048 块粗筛 + 512 精筛决定"该看哪里"。还有两个关键细节——只有第 2、8、14、20 层真正写摘要、其余 36 层共享，以及压缩 KV 为什么要用自己的一套 RoPE theta。
- 注意力与 KV cache：为什么「长上下文」本质是显存问题prefill 吃算力、decode 吃带宽：从 TTFT 讲到 KV cache 为什么随长度和并发线性增长。以及这个模型的反直觉之处——890 字节/token 让上下文几乎不再是显存问题，真正吃显存的是权重和批大小；顺带说清 --max-model-len、--max-num-seqs、--max-num-batched-tokens 该怎么排优先级，KV offloading 为什么是"用延迟换容量"。
- 模型也会看图：ViT、aligner、图像 token 与 Encoder parallel一张图片如何从像素变成向量、再插进文本序列：32 层 ViT、patch 14、3× 下采样 aligner、每图 1024 token 上限。顺带讲清两个互斥的部署开关（--language-model-only 与 Encoder parallel），以及为什么验证服务时必须发一条图片请求。
- 384 个专家里只叫醒 6 个：MoE 与路由入门从"一家公司有 384 位专家、每来一个问题只准叫 6 个"讲起：MoE 为什么要切开 FFN，路由器这个"前台"到底在做什么，sqrtsoftplus 与 noaux_tc 偏置各自解决什么问题，为什么图像 token 要单独排一队，以及那句最该带走的话——MoE 省的是电费，不是房租。
- 它到底有多大：552B、196B、8B/16B 三个数字分别是什么拆开 DeepSeek-V4.1-Flash 的三个核心数字：552B 主干、196B Engram 记忆、每 prompt token 激活 8B / 每 output token 激活 16B。为什么容量按总量付费、速度按激活量算账，为什么 511 GB 权重只能用 Docker 跑，以及"1M 上下文"到底要不要 1M 显存。