★ FEATURED ARTICLE GitHub: https://github.com/geekchow/deepseek-v41-flash-inference-guide你在哪里已知问题与定义现在一次性铺开整片领域。读完本文你将知道8 个核心概念按依赖顺序、7 个关键组件各自“负责什么 / 知道什么 / 刻意不做什么”以及它们如何协同把一个请求变成一个回答。此处不讲内部实现。3.1 领域映射从问题到概念#现实问题系统概念一句话定义为什么是这个抽象C1prefill 和 decode 脾气相反EPD 分离视觉编码VEVision Encoder、预填充P、解码D部署在不同机器池各自扩缩容TTFT 与 TBT 可以分别优化各阶段选各自最优并行度和硬件C2MoE 权重太大、decode 访存瓶颈Attention DP MoE EPWide-EP注意力按数据并行#DP #EP专家按专家并行切到多卡decode 用 EP64–128EP 越宽每卡要读的专家权重越少批越大矩阵乘效率越高C3缓存要省、要大、要可靠分层 KV 缓存三类在途 KV显存、SWA KV本机内存单副本、Block KV3FS 集群分页不同 KV 体积与复用价值差异巨大分层存放成本最低C4多轮请求大量重复前缀前缀命中与命中策略用哈希链对前缀做元数据匹配命中长度由 Block KV 决定最后一块是否重算由 SWA KV 决定任意 prefill 机器可命中任意前缀路由不必考虑亲和C5SWA 缓存缺失时重算代价随层数和长度增长SWA Bounded Replay只重放最近 128 个 token、并把注意力窗口截断在重放段内得到近似 SWA KV重算代价变为常数持久化 KV 降到 V4-Flash 的约 1/8C6请求长短悬殊按“请求数”均衡不准计算配额compute quota用拟合的二次代价模型cost(q, c)把请求换算成纳秒级时间预算按预算调度和均衡均衡的是“算力时间”而不是“请求个数”C7固定长度投机解码浪费验证算力DSpark 变长验证草稿模型一次出 5 个 token置信度头Confidence Head预测每个的接受率只验证边际收益最高的前缀验证 token 数减少约 30%接受长度几乎不变C8三种 API 协议、控制 token 注入风险统一 Conversation 特殊 token 区间所有协议先转成同一个 Conversation再渲染出 prompt 和“哪些字节是真正的特殊 token”一套模板服务三种协议用户文本中的同名字符串只能是普通文本依赖关系C1 → C2分离后才能各选并行度→ C3/C4有了分离和多副本缓存必须共享→ C5共享缓存只存 Block KVSWA 缺失时怎么办→ C6请求换算成算力才能均衡→ C7decode 侧再提速C8 横跨入口和出口。3.2 关键组件从概念到组件下图回答系统的物理分层长什么样官方架构图。黑色箭头为请求流蓝色粗箭头为 KV 缓存流。#组件负责Owns知道Knows刻意不做Does not doK1deepseek-recipe协议 JSON ↔ token 序列 采样参数输出 token 流 ↔ 协议流式事件各协议字段语义、V4/V4.1 模板、特殊 token 表、tokenizer不推理、不发 HTTP、不执行工具、不算 logprobsK2Entrypoint请求入口前缀命中长度计算选择 prefill 路由回收 decode 结果本地 kvcache-storeCHECK 角色的哈希链元数据SWA KV 位置目录按 key 分片不搬运 KV 数据本身只看元数据K3KVCache Storagekvcache-store 3FS持久化 Block KV按 LRU 回收过期缓存~100 PiB SSD 上每个块的位置102 纠删码分组应用层不做副本、不做 TTL 判断全交给 3FS GCK4负载均衡器族Prefill LB / Decode LB / VE LB / EPLB把请求分配到 DP 副本把专家分配到 GPU各引擎剩余计算配额、并发数、KV 总长度、专家近期负载不考虑前缀亲和缓存是全局共享的K5Vision Encoder Service把图片编码成 embedding 交给 prefill每卡正在处理的 patch 数不参与文本 prefill单卡即可用便宜卡K6Prefill ServiceDeepInfer 实例EP2–8计算未命中后缀的 KV执行 SWA Bounded Replay把 KV 写入 3FS 并传给 decode本批请求的命中长度、换入的 KV 块、时间预算不做长时间生成不用 TPTensor Parallelism张量并行/ CPContext Parallelism上下文并行K7Decode ServiceDeepInfer 实例Wide-EP 64–128逐步生成 tokenDSpark 投机解码结构化输出掩码把 decode 产生的 KV 也落盘在途 KV、每请求每草稿 token 的接受率、语法自动机状态不做 KV offloaddecode 不受缓存容量约束这 7 个组件就是第 5 章深潜的目录K5–K7 同属 DeepInfer合并为一个子文件夹。3.3 协同一览快乐路径下图回答一个请求从 JSON 进来到 JSON 出去依次经过谁、带着什么数据。Decode(DeepInfer)Decode LB3FS KV StorePrefill(DeepInfer)Prefill LBEntrypointRecipeClientDecode(DeepInfer)Decode LB3FS KV StorePrefill(DeepInfer)Prefill LBEntrypointRecipeClientloop[每一步]API JSON 请求1token 列表 采样参数2哈希链前缀匹配算出命中长度3请求 命中长度4按计算配额分配5异步取回命中的 KV 块6算未命中后缀 SWA 有界重放7新 KV 块落盘8交给 decode9按并发与 KV 长度均衡10KV 传输P→D11DSpark 草稿 验证12新 token13token 列表14流式协议事件15decode 产生的 KV 落盘16两条最重要的非快乐路径机制留到深潜SWA KV 缺失Block KV 命中了但 SWA KV 所在机器不可达 → 命中长度回退一个块128 token并重放 → 见 05.2 Entrypoint 与 KV 存储。Decode 实例下线 / GPU 故障1 分钟宽限期后把未完成请求连同 KV 一次性转给其他实例EP 规模按健康 GPU 数重新确定 → 见 05.5 弹性与容错。3.4 质量检验现在你应该能在白板上画出入口recipe Entrypoint→ 三类均衡器 → 三类服务池 → 共享存储并说出每个组件为什么必须存在——即使还不知道任何一个组件的内部细节。下一篇04-running-example.md — 贯穿示例 返回00 总览 返回专栏目录
阅读完成 · 觉得有帮助？
