返回研究报告列表

开源组织深度分析

llm-d 开源组织深度研究报告

Kubernetes 分布式 LLM 推理服务编排平台的全方位技术解析

项目概览

llm-d 是 Kubernetes 原生的分布式 LLM 推理服务平台

仓库数量

3068

主仓库 Stars

v0.5

核心仓库

3068 ★

llm-d

主项目，提供 Kubernetes 分布式推理的完整架构、部署指南和最佳实践。

174 ★

llm-d-inference-scheduler

智能路由调度器，基于 Gateway API 的 EPP 实现，支持 P/D 分解协调。

136 ★

llm-d-kv-cache

分布式 KV-Cache 索引和事件处理库，支持多后端索引和精确评分。

119 ★

llm-d-inference-sim

轻量级 vLLM 模拟器，用于测试推理基础设施，无需 GPU。

技术架构

五层架构实现高性能分布式推理

llm-d 架构层次

应用层 (Guides)

↓

优化基线 · P/D分解 · Wide EP · KV缓存 · Autoscaling

↓

调度层 (Inference Scheduler + EPP)

↓

路由层 (Gateway API + Envoy ext-proc)

↓

引擎层 (vLLM / PyTorch / JAX)

↓

资源层 (Kubernetes + GPU/TPU/XPU)

核心设计原则

多工作负载共享模型池
调度器驱动的 RPC
强分离缓存策略
NIXL 传输抽象
适配现有部署模式
模块化 API 设计

支持硬件

NVIDIA A100/H100/B200
AMD MI250/MI300
Google TPU v5e+
Intel GPU Max 系列

核心能力详解

五大能力构建生产级分布式推理

1 优化基线 (Optimized Baseline)

vLLM + Gateway API 负载均衡的组合优化。前缀缓存感知路由利用率负载均衡，配合多租户公平性保证和优先级调度。客户端请求通过 Gateway API 进入，由 Envoy ext-proc 回调 EPP 进行智能路由决策。

2 P/D 分解 (Prefill/Decode Disaggregation)

将 LLM 推理分为预填充(Prefill)和解码(Decode)两阶段，在独立实例执行。Prefill 处理输入 prompt 生成首个 token (计算密集型)，Decode 逐个生成输出 token (内存带宽密集型)。优势包括 TTFT 降低、TPOT 更稳定、支持异构并行度配置。

典型部署配置:
Prefill Workers: TP=1, 多副本
Decode Worker:  TP=5, 单副本
传输: NIXL RDMA (dynamic lazy 连接)
          

3 广域专家并行 (Wide Expert-Parallelism)

针对 MoE (Mixture-of-Experts) 模型的优化部署策略。支持 DeepSeek-R1、Mixtral、Qwen-MoE 等模型。结合数据并行和专家并行，通过快速互联网络 (InfiniBand/RoCE) 连接。在 RL 和延迟不敏感工作负载场景下可显著提升吞吐量。

4 分层 KV 缓存

GPU HBM → CPU Memory → Local SSD → Remote Storage 的多级缓存层次。事件驱动索引通过 ZMQ 消费 vLLM 发出的 KVEvents，近实时更新块位置。LongestPrefixMatch 评分算法综合考虑介质权重和前缀长度。

5 工作负载自动扩缩容

SLO 感知的成本优化自动扩缩容。支持异构硬件和流量感知的变体自动扩缩容。核心指标包括延迟 SLO 保障、吞吐量优化和成本效率平衡。可与 HPA (Horizontal Pod Autoscaler) 集成。

P/D 分解部署架构

Gateway API

↓

Prefill Router

Decode Router

↓

Prefill Worker 1 (TP=1)

Prefill Worker 2 (TP=1)

Prefill Worker N (TP=1)

↓ KV Cache Transfer (RDMA/NIXL)

Decode Worker 1 (TP=4)

...

Decode Worker M (TP=4)

EPP 调度框架

基于插件扩展的智能请求调度

调度流程

Inference Request

↓

ProfilePicker.Pick()

↓ 选择配置文件

Filter → Scorer → Picker

↓

Scheduling Result

// SchedulerProfile 配置结构
type SchedulerProfile struct {
    filters []fwksched.Filter     // 过滤插件
    scorers []*WeightedScorer     // 评分插件 (带权重)
    picker  fwksched.Picker      // 选择插件
}

// 插件扩展点
const (
    ProfilePickerExt  = "ProfilePicker"   // 选择调度配置
    FilterExt         = "Filter"          // 过滤候选
    ScorerExt         = "Scorer"         // 评分
    PickerExt         = "Picker"         // 最终选择
)
      

插件类型

扩展点	类型	功能说明	典型实现
ProfilePicker	插件	选择要执行的调度配置文件	DefaultProfilePicker
Filter	插件	过滤不满足条件的端点	UtilizationFilter, LoadFilter
Scorer	插件	多维度评分候选端点	KVCacheScorer, LatencyScorer
Picker	插件	最终确定目标端点	WeightedPicker

Scorer 插件详细

插件	功能
queue-scorer	基于队列深度的负载均衡
kv-cache-utilization-scorer	KV-cache 利用率评分
prefix-cache-scorer	前缀缓存匹配评分
slo-scorer	SLO 感知评分

EPP 请求处理流程

Incoming Request

↓

Parser

↓

FlowControl

↓

Admit → Schedule → Endpoint

KV-Cache 感知路由

事件驱动的分布式缓存索引

KVCache Indexer 数据流

vLLM Pods

→

KVEvents (ZMQ)

↓

Subscriber Pool

↓ Index Update

KVBlock Index

↓ Lookup

Score Request

↓

Scores (LongestPrefixMatch)

// KVBlockScorer 评分策略
type KVScoringStrategy string

const (
    // LongestPrefixMatch - 从 block 0 开始的最长连续匹配
    LongestPrefixMatch KVScoringStrategy = "LongestPrefix"
)

type KVBlockScorer interface {
    Strategy() KVScoringStrategy
    Score(ctx context.Context,
          keys []kvblock.BlockHash,
          keyToPods map[kvblock.BlockHash][]kvblock.PodEntry) (map[string]float64, error)
}

// 多后端索引支持
type IndexConfig struct {
    InMemoryConfig         *InMemoryIndexConfig     // 内存索引
    RedisConfig           *RedisIndexConfig        // Redis 索引
    ValkeyConfig          *RedisIndexConfig        // Valkey 索引
    CostAwareMemoryConfig *CostAwareMemoryIndexConfig // 成本感知
}
      

评分算法原理

LongestPrefixMatch 策略

1. 将请求的 tokens 转换为 block keys
2. 查询每个 block 在哪些 pods 上有缓存
3. 计算从 block 0 开始的最长连续前缀长度
4. 考虑介质权重 (GPU:1.0, CPU:0.6, Storage:0.3)
5. 综合评分 = Σ(前缀长度 × 介质权重)

具体技术参数

参数	数值	说明
Block Size	64 tokens/block	每个 KV-cache block 包含的 token 数量
Max Prefix Blocks	256	最大前缀匹配 block 数
LRU Capacity	31,250 blocks/server	每个服务器的 LRU 缓存容量

plugins:
- type: prefix-cache-scorer
  parameters:
    blockSizeTokens: 64
    maxPrefixBlocksToMatch: 256
    lruCapacityPerServer: 31250
- type: kv-cache-utilization-scorer
- type: queue-depth-scorer
      

竞品深度对比

llm-d 与其他主流方案的定位和能力差异

产品	定位	核心特性	适用场景
llm-d	编排层	K8s原生、P/D分解、KV缓存感知	企业级、多租户
vLLM	引擎层	PagedAttention、200+模型、连续批处理	极致性能、单模型
SGLang	服务框架	RadixAttention、RL训练后端	高吞吐、多模态
TensorRT-LLM	推理引擎	NVIDIA深度优化、编译优化	NVIDIA硬件、极致延迟
Ray Serve	通用框架	分布式、多模型	多模型服务

能力矩阵对比

功能	llm-d	vLLM	SGLang	TensorRT-LLM
P/D 分解	✓ 完整	△ 实验	✗	△ 有限
KV-Cache 感知调度	✓ 精确	△ 基础	✗	✗
Gateway API	✓ 原生	✗	✗	✗
Kubernetes 集成	✓ 原生	✗	✗	✗
多租户	✓ 完善	△ 基础	△ 基础	△ 基础
多加速器	✓ NVIDIA/AMD/TPU	△ 主要NVIDIA	△ 主要NVIDIA	✗ NVIDIA专用

选择 llm-d 的场景

企业级多租户部署
需要 P/D 分解优化
长上下文应用
MoE 模型部署
多云/混合部署
SLO 保障需求

选择 vLLM/SGLang 的场景

追求极限性能
简单快速原型
单模型部署
无复杂调度需求
团队技术栈单一

横纵交汇洞察

历史、技术与市场的综合分析

1 项目起源与定位

历史背景: llm-d 于 2024 年初启动，核心团队来自 Google 等云厂商，深刻理解企业级 Kubernetes 部署需求。项目定位明确：不是另一个模型服务器，而是建立在 vLLM、Kubernetes、Gateway API 现有生态之上的编排层。

2 版本演进时间线

v0.1-v0.2 (2024): 奠基阶段，建立多仓库架构和 Kubernetes 集成

v0.3 (2025): 智能推理调度器发布，前缀缓存感知路由

v0.4 (2025-12): 多加速器扩展，DeepSeek V3.1 on H200 40% 延迟降低

v0.5 (2026-02): 生产就绪，分层 KV 卸载、Active-Active HA、Scale-to-Zero

3 SIG 组织架构

llm-d 采用 SIG 模式组织开发：SIG Inference Scheduler (调度框架)、SIG KV-Cache (缓存索引)、SIG Accelerators (多硬件支持)、SIG Observability (监控追踪)

4 未来推演

最可能剧本: llm-d 在企业级市场站稳脚跟，特别是金融、医疗、政府等对安全和合规有严格要求的场景。

最危险剧本: llm-d 过度工程化，复杂性导致采用门槛过高；或者 vLLM 内置更完善的调度能力削弱差异化。

最乐观剧本: llm-d 的调度框架成为行业标准，Gateway API Inference Extension 全面采纳其设计。

5 社区用户反馈

性能数据 (真实生产环境):

• llm-d + vLLM 实现 3倍吞吐提升、2倍延迟降低

• KV缓存优化可实现 10倍成本降低、50倍速度提升

挑战与反馈:

• P/D 分离实施复杂度较高

• 与 SGLang 存在兼容性问题

• 文档有待进一步完善

仓库依赖关系

llm-d (3068★) 主项目

↓

llm-d-inference-scheduler (174★)

llm-d-kv-cache (136★)

llm-d-inference-sim (119★)

↓

EPP 调度器 · PD-Sidecar · 流量控制

KVCacheIndexer · KVEvents Pool · 多后端索引

vLLM 模拟器 · 延迟计算器 · 故障注入

综合结论

关键发现与决策建议

核心结论

1. llm-d 是生产级分布式推理编排平台，不是简单的模型服务器，提供从模型服务到路由调度再到自动扩缩容的完整解决方案。

2. 核心技术差异化包括 P/D 分解的完整工程实现、KV-Cache 精确感知路由(基于 LongestPrefixMatch)、Kubernetes Gateway API 原生集成。

3. 与 vLLM 互补而非竞争，llm-d 基于 vLLM 构建上层编排能力，增强其生产部署效果。

4. 企业友好，多租户、SLO 保障、多加速器支持等特性使其适合复杂生产环境。

决策框架

是否需要 llm-d?
│
├── 是否有 P/D 分解需求?     → YES → llm-d ✓
├── 是否需要 KV 缓存感知路由? → YES → llm-d ✓
├── 是否有多租户部署?        → YES → llm-d ✓
├── 是否追求极限性能?        → YES → vLLM 直接部署
└── 快速原型/简单场景?       → vLLM 即可
      