AI INFRA 全景分析与展望 #

深度调研日期：2026-06-24 | 来源：多源 Web 搜索 + 对抗验证（24 个搜索代理，15+ 源站，70+ 可验证 claims）

📐 全景架构定位图 #

graph TB
    subgraph "应用层 / Gateway"
        User[用户请求]
        GAIE[K8s Gateway API<br/>Inference Extension]
    end

    subgraph "编排层 / Orchestration"
        LLMD[llm-d<br/>CNCF Sandbox<br/>路由 + PD 分离 + 自缩容]
        Dynamo[NVIDIA Dynamo<br/>数据中心级推理栈<br/>路由 + PD 分离 + KV 管理]
        VolcanoKthena[Volcano Kthena<br/>K8s-native LLM<br/>路由与编排]
    end

    subgraph "调度层 / Scheduling"
        Volcano[Volcano<br/>CNCF Incubating<br/>批调度 + Gang + DRA]
        LWS[LeaderWorkerSet<br/>k8s-sigs<br/>多节点 Pod 组]
        DS[DisaggregatedSet<br/>基于 LWS<br/>PD 分离部署]
        HAMi[HAMi<br/>CNCF Sandbox<br/>GPU 切分 + 多厂商]
    end

    subgraph "推理引擎层 / Inference Engine"
        vLLM[vLLM<br/>PagedAttention<br/>400+ 模型 / 多硬件]
        SGLang[SGLang<br/>RadixAttention<br/>150+ 模型]
        TRTLLM[TensorRT-LLM<br/>编译优化<br/>NVIDIA 专属]
    end

    subgraph "KV Cache 层 / State Management"
        LMCache[LMCache<br/>PyTorch Foundation<br/>分层 KV 管理]
        Mooncake[Mooncake<br/>PyTorch Ecosystem<br/>解耦 KV 池 + Conductor]
        NIXL[NVIDIA NIXL<br/>高速 KV 传输<br/>GPU→GPU]
    end

    User --> GAIE
    GAIE --> LLMD
    GAIE --> Dynamo
    LLMD --> vLLM
    LLMD --> SGLang
    Dynamo --> SGLang
    Dynamo --> TRTLLM
    Dynamo --> vLLM
    VolcanoKthena --> vLLM

    LLMD --> LWS
    LLMD --> DS
    Dynamo --> LWS
    Dynamo --> Grove

    HAMi --> Volcano
    Volcano --> LWS

    vLLM --> LMCache
    vLLM --> Mooncake
    SGLang --> Mooncake
    Dynamo --> LMCache
    Dynamo --> NIXL
    LLMD --> NIXL
    LLMD --> LMCache

    style LLMD fill:#e1f5fe
    style Dynamo fill:#fff3e0
    style vLLM fill:#e8f5e9
    style SGLang fill:#f3e5f5
    style TRTLLM fill:#ffebee
    style HAMi fill:#fce4ec
    style Volcano fill:#e0f2f1
    style Mooncake fill:#f1f8e9
    style LMCache fill:#e8eaf6

🔥 推理引擎三巨头 #

vLLM — 通用默认起点 #

⚠️ 注意：vLLM 上游无法提供 day-0 ROCm 支持，因缺少足够的 AMD GPU 机器资源。AMD 在开源分布式推理上落后 NVIDIA 6+ 个月。

SGLang — 前缀缓存专家 #

TensorRT-LLM — NVIDIA 极致吞吐 #

⚠️ NVIDIA 将大部分推理工程资源投入 TRT-LLM，vLLM/SGLang 的 NVIDIA 后端支持相对较少。

三引擎横向对比 #

graph LR
    subgraph "Feature Convergence ✅"
        CB[Continuous Batching]
        PKV[Paged KV Caching]
        FP8[FP8 Quantization]
    end

    subgraph "Differentiation 🔥"
        PA[vLLM<br/>PagedAttention<br/>最广覆盖]
        RA[SGLang<br/>RadixAttention<br/>前缀复用]
        CE[TRT-LLM<br/>Compiled Engine<br/>极致吞吐]
    end

    vLLM --- CB & PKV & FP8
    SGLang --- CB & PKV & FP8
    TRTLLM --- CB & PKV & FP8

🏗️ K8s 调度与编排层 #

HAMi — 多厂商 GPU 切分中间件 #

HAMi 四大核心组件 #

1. MutatingWebhook — 拦截 Pod 提交，注入调度配置
2. Scheduler Extender — 实现 filter/score/bind，维护全局 GPU 视图，支持 binpack/spread 策略
3. Device Plugin（DaemonSet）— 每节点注册虚拟 GPU 资源；Allocate 时挂载 libvgpu.so 和注入环境变量
4. HAMi-Core (libvgpu.so) — 容器内 CUDA API 层拦截

GPU 切分与隔离机制 #

• GPU Slicing：GPU → 1/2 → 1/4 → 1/N，fractional GPU allocation
• 硬隔离：内存和算力在运行时精确硬隔离
• 标准声明：nvidia.com/gpu:1 + nvidia.com/gpumem:3000（3 GiB on one GPU） + nvidia.com/gpucores:50（50% compute）
• 生产收益：GPU 数 4→2（减 50%），利用率 50%→100%，每 GPU 工作负载 1→2+

HAMi-Core (libvgpu.so) 工作原理 #

CUDA Runtime (libcudart.so)
       ↕ API calls intercepted
   libvgpu.so (HAMi-Core)
       ↕ 
CUDA Driver (libcuda.so)

• 内存拦截：cuMemAlloc → OOM 检查，若 Pod request + 当前分配 > CUDA_DEVICE_MEMORY_LIMIT_ 则拒绝
• 算力拦截：cuLaunchKernel/cuLaunchKernelEx → rate_limiter，消耗全局计数器 g_cur_cuda_cores；耗尽时 spin-wait
• 计数器补充：后台 utilization watcher 线程周期采样实际 GPU 利用率，动态计算补充量，收敛至 CUDA_DEVICE_SM_LIMIT 百分比
• dlsym 覆写：劫持所有 cu/nvml 前缀的 NVIDIA 动态库符号

HAMi 与 Volcano 集成用于批处理 AI 工作负载；支持 vLLM、DeepSeek、Xinference 等 LLM 推理工作负载。

Volcano — K8s 批调度系统 #

Volcano 在 LLM 场景的关键能力 #

• Gang Scheduling：分布式 LLM 工作负载的所有 Pod 必须同时启动（all-or-nothing）
• Gang-Aware Preemption：v1.15 引入，以 gang 为单位抢占，避免部分 Pod 被抢占导致整个分布式推理崩溃
• DRA 支持：动态资源分配，支持 GPU/vGPU 更灵活调度
• 与 HAMi 集成：HAMi 使用 Volcano 的 scheduler extender 路径
• 与 LWS 集成：LWS PodGroup 可通过 scheduling.volcano.sh/queue-name annotation 指定 Volcano queue

LeaderWorkerSet (LWS) — 多节点 Pod 组 #

LWS 核心特性 #

1. Topology-aware Placement：同组 Pod 可选同拓扑域共置
2. Gang Scheduling：每个 replica 组 all-or-nothing 启动
3. Dual Template：Leader 和 Worker 分别使用不同 Pod template
4. Group-level Rolling Update：组级别滚动更新
5. StartupPolicy：
   • LeaderCreated（默认）— minMember = 全 replica 大小（1 leader + 所有 workers），全 gang 启动
   • LeaderReady — minMember = 1，仅 leader 就绪即可开始

DisaggregatedSet (DS) — 基于 LWS 的 PD 分离 API #

• 核心能力：支持 Prefill 和 Decode 运行在不同基础设施
• 协调机制：跨组 Pod 间的网络身份与生命周期管理
• 独立缩容：Prefill 和 Decode 组可独立弹性伸缩

🎼 分布式推理编排层 #

llm-d — CNCF 分布式推理框架 #

llm-d 三层架构 #

1. Router（智能入口）

   • Proxy：高性能 L7 代理（Envoy），接受用户请求
   • Endpoint Picker (EPP)：路由引擎 — 基于实时指标、KV-cache 亲和性、策略评分选择最优 Pod
   • 实现 GAIE（K8s Gateway API Inference Extension）的 Endpoint Picker Protocol

2. InferencePool（LLM 优化的 Service）

   • 通过 label selector 将同模型的服务 Pod 组合
   • Variant：InferencePool 内的逻辑子分组（prefill / decode / latency-tolerant 等）

3. Model Server（推理引擎）

   • vLLM 或 SGLang 在硬件加速器上执行模型

llm-d 核心优化 #

llm-d 分离拓扑 #

• EPD（无分离）— 单节点处理全流程
• P/D — Prefill 和 Decode 分离到不同 worker
• E/PD — Encode（多模态）独立 + Prefill+Decode 合并
• E/P/D — 全三阶段流水线

llm-d 的 Variant Autoscaler（与 AIBrix 协作开发）根据流量和硬件特征计算最优实例组合。

NVIDIA Dynamo — 数据中心级推理栈 #

Dynamo 三平面架构 #

1. Serving Plane（请求处理）

   • Frontend：接受请求，OpenAI-compatible API（端口 8000）
   • PrefillRouter：KV-aware routing 选择 prefill worker
   • Prefill Worker：计算 prompt KV state
   • Decode Worker：生成输出 tokens
   • KV Transfer：GPU-to-GPU 直传（NIXL）

2. Control Plane（编排）

   • Planner：SLA-driven autoscaler，从实时指标计算缩容目标
   • Dynamo Operator：reconcile DynamoGraphDeployment CRD
   • Grove：K8s operator，topology-aware gang scheduling（NVL72）
   • Discovery + Endpoints/CRD：liveness 与 discoverability

3. State Plane（KV Cache 管理）

   • KV Events：发布 cache lifecycle transitions
   • KV Block Manager (KVBM)：跨 GPU→CPU→SSD→remote 的 block reuse/eviction/offload/recall
   • NIXL：高速 KV/data 传输（NVLink / InfiniBand / PCIe）

Dynamo 四大核心创新 #

Dynamo 部署模式 #

• Standalone（默认）— Dynamo Frontend 是请求入口，集成 Router 做 KV-aware 评分
• Gateway (GAIE) — Dynamo 运行在 K8s Gateway API Inference Extension 之后；EPP 在 gateway 层做 KV-aware routing；Frontend 作为 sidecar

Dynamo vs llm-d 定位对比 #

🧠 KV Cache 状态管理层 #

LMCache — 分层 KV Cache 管理 #

LMCache 分层存储层级 #

GPU Memory → CPU Memory → Local Storage → Remote Backends

• 可插拔后端：Redis/Valkey / Mooncake / InfiniStore / S3-compatible
• 跨实例复用：KV Cache 跨请求、会话、引擎实例复用
• Multiprocess 架构（2026/04 引入）— MoE 推理性能 10x 提升
• 与 Dynamo 集成：2025/09 NVIDIA Dynamo 官方集成 LMCache
• 与 llm-d 集成：作为共享缓存后端，KV transfer + 全局索引

Mooncake — 解耦 KV Cache 池 + Conductor #

Mooncake 核心架构 #

1. 解耦 Prefill/Decode 集群 — 独立扩缩容
2. Disaggregated KVCache Pool — 利用 GPU 集群中闲置的 CPU / DRAM / SSD 资源
3. KVCache-centric Scheduler (Conductor) — 预测式早拒绝（prediction-based early rejection）
4. Chunked Pipeline Parallelism (CPP) — 长上下文 prefill 分块流水线

Mooncake 关键性能数据 #

Mooncake 集成生态 #

• vLLM：KV Connector for PD-disaggregation（vLLM v1, 自 2024/12）
• SGLang：PD-disaggregated serving + hierarchical KV caching（自 2025/04）
• TensorRT-LLM：PD-disaggregated serving
• LMCache：2025/05 合并合作，共建 KV Cache 共享生态
• AMD MoRI：作为 AMD 解耦 KV transfer 选项测试

🔗 生态关系与集成矩阵 #

graph LR
    subgraph "Inference Engines"
        vLLM
        SGLang
        TRTLLM[TensorRT-LLM]
    end

    subgraph "KV Cache Layer"
        LMCache
        Mooncake
        NIXL[NIXL]
    end

    subgraph "Orchestration"
        LLMD[llm-d]
        Dynamo[NVIDIA Dynamo]
    end

    subgraph "K8s Scheduling"
        HAMi
        Volcano
        LWS[LeaderWorkerSet]
    end

    vLLM --> LMCache & Mooncake
    SGLang --> Mooncake
    TRTLLM --> Mooncake
    LLMD --> vLLM & SGLang & LMCache & NIXL & LWS
    Dynamo --> SGLang & TRTLLM & vLLM & LMCache & NIXL & LWS
    HAMi --> Volcano
    Volcano --> LWS

📊 关键趋势与展望 #

1. PD 分离成为标配 #

Prefill/Decode Disaggregation 已不再是实验特性——llm-d、Dynamo、Volcano Kthena、Mooncake 四个项目同时实现。核心逻辑：

• Prefill 是 compute-intensive（算力密集），Decode 是 memory-intensive（显存密集）
• 分离后各阶段独立缩容，GPU 利用率最大化
• KV Cache 通过 NIXL/Mooncake TE 高速跨节点传输

2. KV Cache 从"浪费"到"核心资产" #

• 传统推理引擎 61.8%-79.6% KV Cache 内存浪费（碎片化）
• PagedAttention / RadixAttention / LMCache 分层存储 / Mooncake 解耦池 — 四条路径解决同一问题
• KV-aware routing 成为路由层的核心竞争力（llm-d EPP / Dynamo Smart Router / Kthena）

3. K8s 原生推理工作负载标准化 #

• GAIE（Gateway API Inference Extension）— 标准化推理网关
• LWS + DisaggregatedSet — 标准化多节点部署和 PD 分离部署
• Volcano Gang-Aware Preemption — 标准化分布式推理抢占
• HAMi 多厂商 GPU 切分 — 标准化异构加速器共享

4. 编排层 vs 引擎层的清晰分层 #

• 引擎层（vLLM/SGLang/TRT-LLM）专注单节点/单 GPU 优化
• 编排层（llm-d/Dynamo）专注多节点路由、PD 分离、自缩容
• llm-d 走 CNCF 开放标准路线，Dynamo 走 NVIDIA 一体化路线 — 两条路线将长期共存

5. AMD 生态差距显著 #

• vLLM 上游需 20+ MI300/MI325/MI355X 机器才能追平 CUDA 可用性
• AMD 在分布式推理 + wide EP + FP4 组合性上落后 NVIDIA 6+ 个月
• MI355X FP4 解耦推理实际性能低于单节点（理论建模预测应更好）

6. 选型决策树 #

graph TD
    Start[开始选型] --> Q1{需要多厂商GPU?}
    Q1 -->|是| HAMiSelect[HAMi + Volcano]
    Q1 -->|否| Q2{仅 NVIDIA 硬件?}

    Q2 -->|是| Q3{追求极致吞吐?}
    Q3 -->|是| TRTSelect[TensorRT-LLM<br/>+ Dynamo]
    Q3 -->|否| Q4{共享前缀密集?}

    Q4 -->|是| SGLangSelect[SGLang<br/>+ llm-d / Dynamo]
    Q4 -->|否| vLLMSelect[vLLM<br/>+ llm-d / Dynamo]

    Q2 -->|否| vLLMSelect2[vLLM<br/>多硬件覆盖]

    HAMiSelect --> Q5{需要PD分离?}
    Q5 -->|是| LLMDSelect[llm-d<br/>CNCF开放标准]
    Q5 -->|否| VolcanoOnly[Volcano + LWS]

    TRTSelect --> DynamoOrLLMD{编排层选择}
    DynamoOrLLMD -->|NVIDIA一体化| DynamoOnly[Dynamo]
    DynamoOrLLMD -->|开放标准| LLMDOnly[llm-d]

    SGLangSelect --> KVQ{KV Cache管理?}
    vLLMSelect --> KVQ
    KVQ -->|简单| BuiltIn[引擎内置]
    KVQ -->|跨实例复用| LMCacheSelect[LMCache]
    KVQ -->|解耦池| MooncakeSelect[Mooncake]

📚 Sources #