文档(金鹏): 2026-08-06 章节 48 篇文章摘要归档

- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇）
- 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/
- 章节重组为 9 个主题分组并挂接摘要引用

知识/llm-d/2026-08-06_llm-d_K8s原生分布式推理栈架构.md

@@ -0,0 +1,72 @@
+# llm-d：K8s 原生的分布式推理栈架构文档
+
+> **来源**：llm-d  
+> **作者**：llm-d 项目团队（CNCF Sandbox 项目）  
+> **发布日期**：2026-08-06  
+> **原文链接**：https://llm-d.ai/docs/architecture
+
+---
+
+# Architecture
+
+llm-d 架构高级指南。从这里开始，然后深入阅读具体指南。
+
+## Core Components（核心组件）
+
+llm-d 架构围绕三个主要概念构建：**Router（路由器）**、**InferencePool（推理池）** 和 **Model Server（模型服务器）**。
+
+- **llm-d Router** —— 推理请求的智能入口点。它提供 LLM 感知的负载均衡、请求排队和策略执行。由两个功能部分组成：
+  - **Proxy**：一个高性能 L7 代理（通常是 Envoy），接受用户请求，并通过 `ext-proc` 协议咨询 EPP 以确定最佳目标。
+  - **Endpoint Picker (EPP)**：路由引擎，基于实时指标、KV-cache 亲和性和配置的策略，对模型服务器 Pod 进行评分和选择。
+- **InferencePool** —— 通过标签选择器对服务同一基础模型的 Model Server Pod 进行分组的 API。被概念化为"面向 LLM 优化的 Service"，是 Router 的发现目标。此外：
+  - **Variant**：InferencePool 内 Model Server Pod 的逻辑子分组，通过 Pod 标签而非专用资源来表达。Variant 根据共享特征（如服务角色（例如 prefill 或 decode）、成本概况、性能概况（吞吐量、延迟）或其他运营属性）来区分模型服务器。
+- **Model Server** —— 在硬件加速器（GPU、TPU、HPU）上执行模型的推理引擎（如 vLLM 或 SGLang）。
+
+![Basic llm-d Arch](https://llm-d.ai/img/versioned/0.8/assets/basic-architecture.svg)
+
+## Advanced Patterns（高级模式）
+
+llm-d 的核心设计可以扩展出可选的高级模式：
+
+### KV Cache Management（KV Cache 管理）
+
+llm-d 提供了一个全面的生态系统，用于跨推理池管理和复用 KV cache，包括：
+
+- **Prefix-Cache Aware Routing（前缀缓存感知路由）**：启发式和精确的技术以最大化缓存命中。
+- **KV-Cache Indexing（KV Cache 索引）**：跨所有模型服务器对缓存状态进行事件驱动的跟踪。
+- **KV Offloading（KV 卸载）**：分层存储体系（CPU、SSD）以扩展缓存容量。
+
+参见 KV Cache Management 了解这些组件如何组合的概述。
+
+### Disaggregated Serving（分离式服务）
+
+在分离式服务中，单个推理请求被拆分为多个阶段（例如 Prefill 和 Decode），由专门的 worker 处理。llm-d Router 通过同时选择 prefill 和 decode 端点并协调它们之间的 KV-cache 传输来编排这一流程。
+
+参见 Disaggregation 了解完整细节。
+
+### Predicted Latency-Based Routing（基于预测延迟的路由）
+
+llm-d Router 可以通过"consultant"边车扩展，以提供用于路由决策的高级信号。主要实现是 **Latency Predictor**，它支持基于预测的 ITL 和 TTFT 的路由。
+
+- **Latency Predictor**：在线训练 XGBoost 模型以预测请求延迟，用于更好的端点评分和 SLO 执行。
+
+### Batch Inference（批推理）
+
+批处理和离线推理工作负载由两个模块处理，可以独立或一起部署。**Batch Gateway** 提供 OpenAI 兼容的 Batch API 用于作业管理，而 **Async Processor** 通过流控门控分发排队的请求。组合使用时，Batch Gateway 将分发委托给 Async Processor。
+
+参见 Batch Inference 了解批推理设计的细节。
+
+### Autoscaling（自动扩缩容）
+
+llm-d 通过两种互补的方法支持主动的、SLO 感知的自动扩缩容：
+
+- **HPA/KEDA**：标准 Kubernetes 原生扩缩容，使用 EPP 导出的指标（如队列深度）。
+- **Workload Variant Autoscaler (WVA)**：全局优化的扩缩容，通过在不同 variant 之间或跨推理池放置副本，在满足延迟目标的同时最小化成本。
+
+参见 Autoscaling 了解完整细节。
+
+![Advanced llm-d Arch](https://llm-d.ai/img/versioned/0.8/assets/images/llm-d-arch.svg)
+
+---
+
+> 文档版本：llm-d 0.8（Docusaurus 文档站，CNCF 托管项目）。llm-d 是 Kubernetes 原生的分布式推理服务栈，使用 vLLM 作为模型服务引擎，Inference Gateway 作为请求调度器与负载均衡器，Kubernetes 作为基础设施编排与控制平面，面向大规模生产环境的 P/D 分离、分布式 KV Cache 与 SLO 感知调度。

知识/llm-d/2026-08-06_llm-d_K8s原生分布式推理栈架构_摘要.md

@@ -0,0 +1,85 @@
+# 📊 文章摘要：llm-d：K8s 原生分布式推理栈架构
+
+> **原文**：[2026-08-06_llm-d_K8s原生分布式推理栈架构.md](./2026-08-06_llm-d_K8s原生分布式推理栈架构.md)
+> **原文链接**：https://llm-d.ai/docs/architecture
+> **来源**：llm-d 官方文档（CNCF Sandbox 项目）
+> **作者**：llm-d 项目团队（CNCF Sandbox）
+> **发布日期**：2026-08-06
+> **摘要日期**：2026-08-06
+> **价值评级**：⭐⭐⭐ 高
+
+---
+
+## 核心命题
+
+> **K8s 原生推理栈** — 用 Router（Proxy + EPP）、InferencePool（含 Variant 子分组）、Model Server 三个抽象，把 LLM 推理的调度、缓存、扩缩容全部收敛为 Kubernetes 原生的声明式模式。
+
+---
+
+## 文章概要
+
+本文是 CNCF Sandbox 项目 llm-d 的架构指南，系统阐述其三层核心组件：llm-d Router（Envoy L7 代理 + Endpoint Picker 路由引擎，基于实时指标、KV-cache 亲和性与策略打分选端）、InferencePool（按模型分组的"LLM 优化的 Service"，Variant 通过 Pod 标签表达 prefill/decode 等服务角色）、Model Server（vLLM/SGLang 等推理引擎）。高级模式覆盖 KV Cache 管理（前缀缓存感知路由、事件驱动索引、CPU/SSD 分层卸载）、PD 分离编排（同时选择 prefill/decode 端点并协调 KV 传输）、基于 XGBoost 在线训练的延迟预测路由、批推理（Batch Gateway + Async Processor）与双通道扩缩容（HPA/KEDA + 全局优化的 Workload Variant Autoscaler）。价值在于提供了一套结构完整、可借鉴的 K8s 原生推理平台设计范式。局限在于全文为纯架构描述，无任何性能数据、对比实验或生产验证，且未讨论各模式之间的依赖关系与适用边界。
+
+---
+
+## 关键要点
+
+1. **三层抽象解耦清晰** — Router（路由决策）/ InferencePool（服务发现与分组）/ Model Server（算力执行）各司其职，将"面向 LLM 的调度逻辑"从基础设施中显式分离，是对传统 K8s Service 模式的 LLM 化扩展。 `[分类: 范式突破]`
+
+2. **Variant 用标签表达服务角色** — prefill/decode、成本档位、性能档位等差异通过 Pod 标签而非专用资源表达，使同一 InferencePool 内可运行异构实例且无需新建 CRD 类型，设计轻巧。 `[分类: 共识]`
+
+3. **KV cache 成为一等调度信号** — 前缀缓存感知路由 + 事件驱动 KV 索引 + 分层卸载（CPU/SSD），把"缓存命中率"纳入路由打分，这是 2025 年以来推理网关的公认演进方向。 `[分类: 共识]`
+
+4. **SLO 感知的主动扩缩容** — WVA 在满足延迟目标的前提下跨 variant/跨池全局放置副本以最小化成本，与 HPA/KEDA 的反应式扩缩互补，代表了"成本最优 + SLO 驱动"的编排思路。 `[分类: 未探索]`
+
+5. **无验证数据是硬伤** — 全文档零基准测试、零生产案例，XGBoost 延迟预测的在线训练稳定性、EPP 打分开销、PD 分离下的传输瓶颈等关键工程问题均未触及，方案成熟度无从判断。 `[分类: 未探索]`
+
+---
+
+## 批判性分析
+
+### 假设前提
+
+- 假设集群以 Kubernetes 为唯一控制平面，且团队具备 K8s 运维能力（Envoy、HPA/KEDA、CRD 生态）；
+- 假设以 vLLM 为默认引擎（其 EPP 协议、KV connector 机制是设计底座），其他引擎支持依赖社区生态；
+- 假设"LLM 感知的集中式路由"在超大规模集群上的扩展性成立——文档未讨论 EPP 作为单点路由引擎的性能边界。
+
+### 论据与逻辑
+
+- 架构叙述内部自洽、模式描述符合业界主流实践（与 vLLM 的 KV connector、IGW 的 EPP 协议等既有机制对应），可视为对社区方案的整合与提炼，论据质量在于"结构可信"而非"数据可信"——没有任何性能数字或对比实验支撑其宣称的"最快落地速度""大规模生产环境"等表述，这些属于项目宣传口径。
+
+### 边界与局限
+
+- 适用场景：中型以上团队自建 LLM 推理平台时的架构蓝图参考；对 K8s 熟悉度高、愿意接受 CRD/Operator 生态的团队。
+- 不适用于：单机/小集群简单部署（复杂度不划算）、对延迟极度敏感且需绕过 K8s 调度开销的场景、非 K8s 基础设施环境。
+- 高级模式（延迟预测、WVA）均标注为可选扩展，但其交互关系（如延迟预测与 KV 亲和路由的优先级冲突）未说明。
+
+---
+
+## 可引用金句
+
+> "llm-d 是 Kubernetes 原生的分布式推理服务栈，使用 vLLM 作为模型服务引擎，Inference Gateway 作为请求调度器与负载均衡器，Kubernetes 作为基础设施编排与控制平面。"
+
+---
+
+## 总体评价
+
+**亮点**：
+- 三层抽象 + Variant 设计结构清晰，是 K8s 原生推理平台的可直接借鉴的架构范式
+- 将 KV cache、SLO、成本三个维度显式纳入调度决策，覆盖了业界最新关注点
+- CNCF Sandbox 托管 + 0.8 版本迭代，项目活跃度可信
+
+**不足**：
+- 零性能数据、零对比实验、零生产案例，无法评估方案真实收益
+- 未讨论 EPP 单点扩展性、延迟预测在线学习稳定性等关键工程边界
+- "可选高级模式"之间的依赖与取舍缺乏说明
+
+**适用场景**：K8s 工程团队设计 LLM 推理平台时的架构参考；对比 AIBrix、Dynamo 等同类方案时的横向认知材料；技术选型评审的输入之一。
+
+**关联建议**：对照阅读 AIBrix（字节跳动，K8s 原生）、NVIDIA Dynamo（Planner/路由/KV 管理四组件）与 vLLM 官方 KV Connector 文档，横向比较三者对"路由、缓存、扩缩容"三大问题的解决路径；关注 llm-d 后续版本是否补充基准数据。
+
+---
+
+## 配图
+
+![-](../../金鹏/20260806/20260806-005.png)