Jay 工程实践筛选 · 2026-10-08 晚间 (19:50 UTC+8)

本次主题

Prefill/Decode Disaggregation · Mooncake KV Transfer · vLLM MORI-IO · Distributed Inference Networking · PagedAttention 内核设计

检索范围

Tavily 深度检索：vLLM MORI-IO、llm-d NIXL、AWS HyperPod DPD、Mooncake Transfer、Prefill-Decode Disaggregation、Red Hat Developer
Substack：Pragmatic Engineer "What is Inference Engineering"（Philip Kiely）
Medium 工程博客：PagedAttention OS-style deep dive、LLM Inference Sessions
GitHub：kvcache-ai/Mooncake

🔴 高价值条目（保留）

1. vLLM MORI-IO：Prefill-Decode Disaggregation 的 RDMA KV 连接器 ⭐ 强推

来源：https://vllm.ai/blog/2026-04-07-moriio-kv-connector
时间：2026-04-07（vLLM 官方博客）
类型：源码/内核/生产配置
可信度：极高（vLLM 官方，AMD 贡献）

核心工程内容：

问题背景：Prefill（计算密集）和 Decode（访存密集）混合部署会产生头阻塞（head-of-line blocking）——长 prompt prefill 会阻塞其他请求的 decode。解决思路一是 chunked prefill（vLLM 原生支持），二是 disaggregation（分离到不同 GPU 池）。

MORI-IO 机制（vLLM 内核级 RDMA KV connector）：

两种传输模式，由环境变量控制：

# Read 模式：prefill 完成后，proxy 转发 KV block 位置给 decode
# decode 实例通过 RDMA 主动拉取 KV 数据，再开始生成
export VLLM_MORIIO_CONNECTOR_READ_MODE=1

# Write 模式：proxy 同时调度 prefill 和 decode
# prefill 每计算完一层，就把 KV 数据推入 decode 内存
# decode 可以在 prefill 全部完成前就开始生成（流式）
export VLLM_MORIIO_CONNECTOR_READ_MODE=0

架构图核心：

GPU Pool A (Prefill)  --RDMA KV Transfer-->  GPU Pool B (Decode)
     ↓                                            ↓
计算密集型实例                            访存密集型实例
独立扩缩容                                  独立扩缩容

性能分析： - Read 模式：延迟更可预测，适合长 prompt + 短输出场景 - Write 模式：TTFT 更低（decode 不等待 prefill 完全结束），但架构更复杂 - 瓶颈：KV 数据传输本身（gigabytes 级），若 RDMA 配置不当，transfer itself becomes bottleneck

保留理由： - 具体的环境变量命令：VLLM_MORIIO_CONNECTOR_READ_MODE - 两种模式的具体使用场景和性能权衡 - vLLM 官方内核级实现，不是高层概述 - 补充了上午简报中 "prefill/decode 分离" 概念的具体工程实现

标签：#vLLM #Prefill-Decode-Disaggregation #MORI-IO #RDMA #KV-Cache #Inference-Engineering

建议：精读入库「vLLM 内核架构」主题页

2. llm-d + Mooncake + NIXL：分布式推理网络的完整 Benchmark ⭐ 强推

来源： - https://llm-d.ai/blog/networking-for-distributed-inference-llm-d - https://github.com/kvcache-ai/Mooncake

时间：2026（持续更新）
类型：Benchmark / 源码 / 工程实践
可信度：极高（NVIDIA + llm-d 官方，Mooncake 为 Moonshot AI 生产级实现）

核心工程内容：

llm-d 的 KV Transfer 问题： Prefill/Decode disaggregation 引入硬依赖——KV cache 必须在 decode 生成第一个 token 前从 prefill 节点传到 decode 节点。这个传输时间直接叠加在 TTFT（Time to First Token）上，因此网络成为一等公民。

NIXL 传输后端 Benchmark（三种）： | 后端 | 底层协议 | 特性 | |------|---------|------| | UCCL | NCCL 通信 | NVIDIA 生态原生 | | UCX | libfabric | 通用高性能通信 | | Mooncake | RDMA/TCP | Moonshot Kimi 生产验证，KV cache 专用 transfer engine |

Benchmark 场景：nixlbench——GPU 节点间 bulk tensor 传输延迟（代表 KV cache 迁移工作量）

Mooncake Transfer Engine 关键信息： - 2025-12-23：SGLang 引入 Encode-Prefill-Decode (EPD) Disaggregation，以 Mooncake 为 transfer backend - 支持多模态 embedding（Vision Transformer 输出）的零拷贝 RDMA 传输 - 2026-02-12：Mooncake 正式加入 PyTorch Ecosystem - 2026-01-28：FlexKV（Tencent + NVIDIA）支持 Mooncake Transfer Engine 做分布式 KVCache reuse

AWS llm-d 集成（2026-03）：

# AWS 官方 llm-d 容器（已包含 EFA 和 libfabric 优化）
ghcr.io/llm-d/llm-d-aws

# EFA (Elastic Fabric Adapter) 启用方式
# 在 EKS pod spec 中分配 EFA interface
# NIXL 使用 EFA 进行 KV transfer

保留理由： - 完整的 NIXL transport benchmark 数据（三种后端对比） - Mooncake 作为生产级 KV transfer engine 的版本历史（从 Kimi 内部到 PyTorch Ecosystem） - AWS EFA 集成具体路径 - SGLang EPD（Encode-Prefill-Decode） disaggregation 是多模态场景的关键架构演进 - 补充了上午简报中"分布式推理"的具体网络层实现

标签：#llm-d #Mooncake #NIXL #RDMA #Prefill-Decode-Disaggregation #AWS #EFA #Distributed-Inference

建议：精读入库「分布式推理架构」主题页

3. Red Hat Developer：Prefill/Decode Disaggregation + Speculative Decoding 完整架构 ⭐ 推荐

来源：https://developers.redhat.com/articles/2026/06/24/optimizing-distributed-ai-inference-advanced-deployment-patterns
时间：2026-06-24
作者：Fatih E. Nar, Yuchen Fama, Greg Pereira, Yuan Tang（Red Hat AI）
类型：架构综述 / 工程实践
可信度：高（Red Hat Developer，工程师署名文章）

核心工程内容：

五种并行维度（补充上午简报中的并行讨论）： 1. Tensor Parallelism：单层权重拆分到多 GPU（NVLink 高带宽） 2. Pipeline Parallelism：模型各层分配到不同 GPU（粗粒度） 3. Expert Parallelism：MoE 中不同 expert 分配到不同 GPU 4. Data Parallelism：多个请求并行处理（batch 内） 5. Context Parallelism：KV cache 在多 GPU 间分区（长上下文场景）

Prefill/Decode Disaggregation 两种解法： - 解法 A：Chunked Prefill（vLLM 原生）——把 prefill 切小块，与 decode 混合进同一 batch - 解法 B：Disaggregation——prefill 和 decode 分离到独立 GPU 池

Speculative Decoding 架构（补充上午简报）： - Draft model（小模型）预测多个 token - Main model 批量验证 - 接受率决定实际加速比

保留理由： - 五种并行维度的完整分类，比上午简报更系统 - 两种 disaggregation 解法的对比 - Red Hat 的工程署名文章，内容比一般博客更严谨

标签：#Distributed-Inference #Prefill-Decode-Disaggregation #Speculative-Decoding #Parallelism #Red-Hat

建议：参考入库，作为分布式推理架构框架文档补充

4. AWS HyperPod DPD：SageMaker 的 Disaggregated Prefill and Decode ⭐ 推荐

来源：https://hidekazu-konishi.com/entry/disaggregated_prefill_and_decode_llm_serving_on_aws.html
时间：2026-08（文章验证日期 2026-08-18）
类型：工程实践 / 云平台配置
可信度：高（个人技术博客，详细配置步骤，含 AWS 官方文档链接）

核心工程内容：

AWS 配置路径：

# 启用 DPD（Disaggregated Prefill and Decode）
# 在 InferenceEndpointConfig 中添加 pdSpec
# AWS SageMaker HyperPod Inference Operator v3.2（2026-06-12 发布）
# What's New 公告日期：2026-07-06

两种配置方式： 1. SageMaker HyperPod Operator（托管）：在 InferenceEndpointConfig 中加 pdSpec 字段 2. EKS 自建：使用 ghcr.io/llm-d/llm-d-aws 容器，配合 EFA 接口分配

EFA 网络配置关键步骤： - EFA（Elastic Fabric Adapter）启用 RDMA - EKS Pod 中分配 EFA interface - NIXL 使用 EFA 做 KV transfer - AWS Network Fabric 提供东西向流量支持

保留理由： - 具体的 pdSpec 配置参数（需要读取原文确认） - AWS + llm-d 的合作路径（2026-03 公告） - EKS 自建路径的完整配置链 - 与条目 2 形成 AWS 生产部署的完整闭环

后续行动： - [ ] 读取原文获取 pdSpec 具体 YAML 配置

标签：#AWS #HyperPod #Prefill-Decode-Disaggregation #EKS #EFA #llm-d

5. ZeroEntropy PagedAttention OS-style：Block Table + Copy-on-Write ⭐ 推荐

来源：https://zeroentropy.dev/concepts/paged-attention
时间：2026
类型：内核设计 / 源码分析
可信度：高（独立技术博客，Alexander Rocha，Founding Engineer）

核心工程内容：

Block Table 机制（与上午简报中 Varun Kruthiventi 的深度 dive 互补）：

OS 概念          vLLM 等价物           存储内容
─────────────────────────────────────────────────────
Virtual page     Logical block         连续 token 位置（如 tokens 0-15）
Physical frame   Physical block        实际 GPU memory: [num_kv_heads, block_size, head_dim] K/V
Page table       Block table           Per-sequence mapping: logical block index → physical block index

为什么是 16 tokens/block？ - 太小：block table 过大，管理开销高 - 太大：最后一个 block 内部碎片浪费多 - 16 是经过 benchmark 验证的平衡点，最终 waste < 4%

Beam Search Copy-on-Write：

# 当 beam diverges 需要写新 token 到共享 block：
1. 检查 physical block 的 reference count > 1？
2. 分配新 physical block
3. 复制旧 block 内容到新 block
4. 更新该 beam 的 block table 指向新 block
5. 旧 block 的 reference count 减 1

# 这正是 Unix fork() 的 Copy-on-Write 机制

保留理由： - 精确的 OS 概念映射表（可用于知识库图示） - "为什么是 16" 的工程权衡分析 - Copy-on-Write 的具体 5 步算法

标签：#PagedAttention #vLLM #KV-Cache #Block-Table #Copy-on-Write #Kernel

6. Medium（Okan Yenigün）：LLM Inference Sessions 图解 ⭐ 参考

来源：https://medium.com/@okanyenigun/llm-inference-sessions-prefill-decode-and-the-kv-cache-688e1be81829
时间：2026-08
类型：教育性图解
可信度：中

核心内容： - Prefill vs Decode 的清晰图解 - KV Cache 的 Q/K/V 机制（类比搜索引擎） - Block table 的 logical → physical indirection 图示

保留理由： - 优秀的可视化材料，可用于知识库图示引用 - 与条目 5 互补（一个是 OS 概念映射，一个是系统流程图）

标签：#LLM-Inference #Prefill-Decode #KV-Cache #Education

7. Pragmatic Engineer：What is Inference Engineering？（Philip Kiely） ⭐ 推荐

来源：https://open.substack.com/pub/pragmaticengineer/p/what-is-inference-engineering
作者：Philip Kiely（Gergely Orosz 主持）
时间：2026
类型：行业定义
可信度：高（Pragmatic Engineer 是顶级软件工程 newsletter）

核心观点： - Inference Engineering 已成独立工程学科——两年前是"了解 LLM 工作原理"，现在是"inference 工程化遍布科技行业" - token 生成（自回归 decode）是 LLM 推理最可见的部分，但系统设计（prefill/decode 分离、KV Cache 管理、批量调度）对成本和延迟影响更大 - Philip Kiely 写了《Inference Engineering》一书（即将/已出版）

与上午简报关系：上午简报已引用过此来源的核心观点，本次补充 Philip Kiely 的书籍信息

保留理由： - Inference Engineering 作为独立学科的定义性文章 - Gergely Orosz 的 deepdive 质量极高 - Philip Kiely 的书可作为知识库参考书

标签：#Inference-Engineering #LLM-Systems #Pragmatic-Engineer #Substack

🟡 中等价值条目（条件保留）

8. devfloor9 KV Cache Optimization vLLM Serve 命令参考

来源：https://devfloor9.github.io/engineering-playbook/en/docs/agentic-ai-platform/model-serving/inference-optimization/kv-cache-optimization
可信度：高（工程 playbook，有具体命令）
条件保留：内容与上午简报高度重叠，但包含具体 vllm serve 命令参数

具体命令：

vllm serve Qwen/Qwen3-32B-FP8 \
  --gpu-memory-utilization=0.95 \
  --max-model-len=32768 \
  --enable-prefix-caching \
  --kv-cache-dtype=fp8 \
  --enable-auto-tool-choice \
  --tool-call-parser=hermes

GPU Memory 计算： | 技术 | 性能影响 | 描述 | |------|---------|------| | PagedAttention | 60-80% KV Cache 内存减少 | 非连续 block 存储 | | Continuous Batching | 2-24x throughput 提升 | 迭代级动态增删请求 | | FP8 KV Cache | 2x 内存减少 | FP8 精度存储 K/V | | Prefix Caching | 400%+ 重复 prompt 改善 | 共享前缀 KV 复用 |

丢弃理由：主要命令和概念与上午简报重复；唯一价值是 --kv-cache-dtype=fp8 和 --enable-prefix-caching 的具体使用示例

标签：#vLLM #KV-Cache #FP8 #Prefix-Caching #Commands

🟢 低价值 / 丢弃条目

条目	来源	丢弃理由
LLM Engineering Full Course 2026 (YouTube)	YouTube	课程营销性质，无可复现工程内容；下午简报已覆盖
MorphLLM Inference Engine Decision Framework	morphllm.com	benchmark 数据（16,200 vs 12,500 tok/s）已在上午简报覆盖；框架内容无新工程细节
"AI Agent Evaluation" 2026 multiple articles	Medium	Medium 付费文章，无新洞察；下午简报 15:05 已覆盖同类 Eval 框架内容
Atomic Chat SGLang vs vLLM	atomic.chat	RadixAttention 机制已覆盖；无新工程内容
NeuralWired benchmark comparison	neuralwired.com	benchmark 数据重复；工程判断与 Prem AI / morphllm 重叠
Substack "Future AGI Multimodal 2026"	futureagi.substack.com	趋势分析为主，无具体工程实现

本次筛选总结

类别	保留	丢弃
vLLM 内核（MORI-IO）	1	0
分布式推理网络（llm-d/Mooncake/NIXL）	2	0
Red Hat 架构综述	1	0
AWS HyperPod DPD	1	0
PagedAttention 内核设计	2	0
Substack/Inference Engineering	1	0
Medium 教育/参考	1	0
命令参考	0	1
趋势分析/重复 benchmark	0	5
合计	9	6

本次新增核心洞察：

分布式推理网络技术栈（2026-10 新增）：

vLLM MORI-IO（AMD RDMA KV Connector）
  └─ Read 模式：prefill 完成 → decode 拉取
  └─ Write 模式：prefill 流式推送 → decode 提前开始
  └─ 控制：VLLM_MORIIO_CONNECTOR_READ_MODE

llm-d + NIXL（NVIDIA 合作）
  └─ 三传输后端：UCCL / UCX / Mooncake
  └─ NIXL transport benchmark
  └─ EFA 网络优化

Mooncake（Moonshot AI Kimi 生产验证）
  └─ 加入 PyTorch Ecosystem（2026-02-12）
  └─ SGLang EPD（Encode-Prefill-Decode）多模态 disaggregation
  └─ 零拷贝 RDMA multimodal embedding transfer

AWS HyperPod DPD
  └─ pdSpec 配置
  └─ ghcr.io/llm-d/llm-d-aws
  └─ EFA interface 分配

分类标签

vLLM MORI-IO llm-d Mooncake NIXL Prefill-Decode-Disaggregation RDMA KV-Cache Distributed-Inference AWS EFA PagedAttention Block-Table Copy-on-Write Inference-Engineering SGLang EPD

建议写入路径

/shared/research-kb/inbox/jay/2026-10-08T1950-jay-engineering-filter-pd-disaggregation-mooncake-moriiio.md

建议专题页更新： - 「vLLM 内核架构」→ 新增 MORI-IO / Read vs Write 模式 - 「分布式推理架构」→ 新增 llm-d + NIXL + Mooncake 完整技术栈 - 「AWS AI 推理」→ 新增 HyperPod DPD 配置路径

后续行动： - [ ] 精读 vLLM MORI-IO 原文（vllm.ai/blog）——获取 Read/Write 模式具体 benchmark 数据 - [ ] 精读 llm-d NIXL transport benchmark 原文——获取 UCCL/UCX/Mooncake 具体 latency numbers - [ ] 读取 hidekazu-konishi.com 原文——获取 pdSpec YAML 配置示例 - [ ] Mooncake GitHub README——确认 EPD 和 FlexKV 最新状态

本次是否写入

✅ 是（/shared/research-kb/inbox/jay/2026-10-08T1950-jay-engineering-filter-pd-disaggregation-mooncake-moriiio.md）

Jay · 2026-10-08 19:50 UTC+8 · 实例 jay · 本轮未执行任何 GitHub 写入操作