在 vLLM Semantic Router 的设计中，Embedding 推理是驱动语义路由的核心信号之一。

官方教程已经演示了如何使用远程 Embedding 推理提供商（Remote Embedding Providers）替代本地 Embedding 推理服务：

👉 https://vllm-sr.ai/docs/tutorials/global/remote-embeddings/

然而，在实际生产环境中，一个更为关键的问题随之而来：

如何使用企业级、可扩展的 Embedding 推理服务来支持语义路由？

本文基于官方教程中的场景，并结合 Microsoft Foundry Embedding 模型，演示如何构建一个具备以下特性的智能路由系统：

• 无需 GPU
• 无需在本地部署 Embedding 模型
• 生产就绪

2. 回顾：远程 Embedding 推理提供商

在 vLLM Semantic Router 中，路由器运行在 CPU 上，不依赖 GPU 推理能力。

通过远程 Embedding 推理提供商：

路由器 → 远程 Embedding 推理 API → 向量

我们可以：

• 将嵌入计算完全卸载到云服务
• 统一多模型的语义能力
• 解耦路由与推理

3. 教程场景（沿用官方测试场景）

在官方教程中，核心流程如下：

第 1 步：定义语义路由

routing:
  decisions:
    - name: math
      when:
        semantic_similarity:
          text: "math question"
          threshold: 0.8

    - name: general

第 2 步：发送请求

curl http://localhost:8888/v1/chat/completions \
  -d '{
    "model": "MoM",
    "messages": [{"role": "user", "content": "What is 1+1?"}]
  }'

路由器将执行以下操作：

1. 生成嵌入向量
2. 执行语义匹配
3. 选择目标模型

4. 第 0 步：在 Microsoft Foundry 中创建 Embedding 模型

在与 vLLM Semantic Router 集成之前，我们首先需要在 Microsoft Foundry 中部署一个 Embedding 模型。

4.1 创建 Foundry 项目

1. 前往 Microsoft Foundry 门户
2. 创建新项目（或选择现有项目）
3. 确保该项目已关联 Azure 订阅

4.2 部署嵌入模型

在模型目录中：

1. 搜索 Embedding 模型
2. 选择受支持的模型（例如 text-embedding-3-small）
3. 单击 Deploy（部署）

部署完成后，你将获得：

• Endpoint URL
• API Key
• Model Name

示例：

Endpoint: https://<your-foundry-resource>.inference.ai.azure.com
Model: text-embedding-3-small
API Key: ******

4.3 验证 Embedding 推理 API

你可以直接测试该终结点：

curl https://<your-foundry-endpoint>/v1/embeddings \
  -H "api-key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Hello world"
  }'

如果调用成功，你将收到包含向量的响应。

5. 升级：使用 Microsoft Foundry 替代本地 Embedding 模型

现在，我们将教程中的 Embedding 推理提供商替换为：

✅ Microsoft Foundry Embedding 模型

6. 为什么选择 Microsoft Foundry Embedding 模型

Microsoft Foundry 提供：

• 高质量 Embedding 模型（更强的语义理解能力）
• 托管 API（无需自行部署）
• 全球可用性与企业级 SLA
• 与 Azure AI 生态系统无缝集成

更重要的是：

它可以直接充当 Semantic Router 的“语义大脑”

7. 集成：将 Microsoft Foundry 用作远程 Embedding 推理提供商

7.1 配置 Embedding 推理提供商

providers:
  embedding:
    type: remote
    provider: openai-compatible
    base_url: https://<your-foundry-endpoint>
    api_key: <your-api-key>
    model: text-embedding-3-small

说明：

• Foundry 提供兼容 OpenAI 的 API
• 可以直接复用 Semantic Router 的远程 Embedding 推理提供商
• 无需额外适配

7.2 路由器工作流

用户请求
   ↓
Semantic Router
   ↓
Microsoft Foundry Embedding 推理 API
   ↓
向量相似度计算
   ↓
路由决策
   ↓
目标模型（vLLM / API）

8. 相比官方教程的主要改进

9. 实际价值

🚀 1. 真正的“无 GPU 架构”

路由器本身运行在 CPU 上。

Embedding 模型与推理能力完全外部化：

• Foundry → Embedding 模型
• vLLM / API → 推理

🧠 2. 更准确的语义路由

在教程场景中：

"What is 1+1?" → math 路由
"Tell me a joke" → general 路由

使用 Foundry 嵌入后，可以获得：

• 更稳定的语义理解
• 更好的多语言支持
• 对边界场景更准确的判断

🌐 3. 统一的多模型入口

结合 Semantic Router：

• Microsoft Foundry（Embedding 模型）
• vLLM（自托管推理）
• OpenAI / 其他 API

从而实现真正的：

多提供商智能路由

10. 架构洞察

此次升级的本质是：

升级前：
路由器 = 基础设施 + 智能

升级后：
路由器 = 智能
Foundry = AI 能力

由此形成清晰的分层架构：

[ AI 能力层 ] → Microsoft Foundry
[ 路由层    ] → Semantic Router
[ 推理层    ] → vLLM / APIs

11. 总结

通过将 Microsoft Foundry 与官方远程 Embedding 模型教程相结合，我们实现了一套生产就绪的架构：

• 无需本地 Embedding 模型
• 无需 GPU
• 高质量的语义能力
• 企业级可靠性

这不仅是一次功能增强，更是 Semantic Router 的一次关键演进：

从“本地工具”演进为“云原生 AI 路由层”

然而，用多张卡跑模型并不是一个简单的资源堆叠问题。在实践中，工程团队很快会发现：不同的拆分方式，带来的性能表现差异可能是数量级的。有的配置 TTFT 极低，却在高并发下迅速失速；有的方案吞吐惊人，却难以满足在线服务对延迟的要求；还有一些组合在理论上看似合理，却在真实硬件拓扑下被通信成本完全吞噬。

在训练与推理阶段，业界逐步沉淀出四类核心并行策略：

• TP（Tensor Parallelism，张量并行）
• DP（Data Parallelism，数据并行）
• PP（Pipeline Parallelism，流水线并行）
• EP（Expert Parallelism，专家并行，主要用于 MoE）

大语言模型四种核心并行策略基础

Tensor Parallelism（TP）：算子级拆分

核心思想：将单层内部的矩阵计算（如 Linear / Attention）沿维度切分到多张 GPU 上并行计算。

典型拆分方式：

• Linear 层按 hidden_size 或 num_heads 切分
• Attention 的 Q / K / V 或 FFN 的中间层拆分

优点：

• 单层显存占用显著下降
• 单 token 延迟较低（适合推理）

代价：

• 每一层都需要 All-Reduce / All-Gather
• 通信频繁，对 NVLink / IB 依赖高

适用场景：

• 单模型过大但层数不多
• 对 TTFT（Time To First Token）敏感的在线推理

Data Parallelism（DP）：请求级复制

核心思想：模型完整复制到多张 GPU，每张 GPU 处理不同请求或 batch。

优点：

• 实现简单
• 无模型内部通信
• 吞吐线性扩展

代价：

• 显存需求最高（每卡一整模型）
• 单请求延迟不变

适用场景：

• 模型能放进单卡
• 离线推理 / 高并发吞吐

Pipeline Parallelism（PP）：层级切分

核心思想：将模型按层切分到多张 GPU，请求在 GPU 间流水线式流动。

优点：

• 几乎无层内通信
• 显存效率高（比 DP 好）

代价：

• pipeline bubble（气泡）带来空转
• 小 batch 下延迟显著升高

适用场景：

• 超深模型（如 70B+）
• 长序列推理或训练

Expert Parallelism（EP）：MoE 专属并行

核心思想：在 MoE（Mixture of Experts）模型中，不同 Expert 分布在不同 GPU 上，仅被激活的 Expert 参与计算。

优点：

• 参数规模大但计算稀疏
• 性能/参数比极高

代价：

• Token 路由与负载不均
• 通信模式复杂

适用场景：

• MoE 模型（如 Mixtral、DeepSeek-MoE）
• 高参数规模、可接受一定调度复杂度

并行策略并非互斥，而是可组合的

在真实系统中，并行策略通常组合使用：

问题不在于能不能用，而在于：不同组合，在真实推理负载下，性能表现差异极大。

这正是 vLLM 非常适合做验证的原因。

vLLM 中的并行能力概览

vLLM 是一个面向高性能 LLM 推理的引擎，其核心优势包括：

• 高效 KV Cache 管理（PagedAttention）
• 原生支持 TP / PP
• 对 DP 友好（多实例、多副本）
• MoE 模型中支持 EP（依赖模型实现）

在 vLLM 中，并行配置主要通过启动参数 + 资源拓扑控制。

基于 vLLM 的并行策略配置示例

Tensor Parallelism（TP）

vllm serve meta-llama/Llama-2-70b-hf \
  --tensor-parallel-size 4

含义：

• 模型每一层被拆分到 4 张 GPU
• 适合单请求低延迟验证

Pipeline Parallelism（PP）

vllm serve meta-llama/Llama-2-70b-hf \
  --pipeline-parallel-size 2 \
  --tensor-parallel-size 2

含义：

• 2-stage pipeline
• 每 stage 内 2-way TP
• 总 GPU 数 = 4

Data Parallelism（DP）

vLLM 本身不显式声明 DP，而是通过多实例部署实现：

# GPU 0-3
CUDA_VISIBLE_DEVICES=0,1,2,3 vllm serve ...

# GPU 4-7
CUDA_VISIBLE_DEVICES=4,5,6,7 vllm serve ...

再通过上层负载均衡（如 Kubernetes / Gateway）实现 DP。

Expert Parallelism（EP）

对于 MoE 模型（如 Mixtral）：

vllm serve mistralai/Mixtral-8x7B-Instruct \
  --tensor-parallel-size 4

vLLM 会自动将 Expert 分布到 TP 组内 GPU（模型内部实现 EP）。

如何在 vLLM 中“验证”并行组合的真实性能

核心评测指标

建议至少关注以下指标：

推荐对比实验矩阵

以 8 GPU 为例：

通过固定输入长度与请求并发，对比上述方案即可得到清晰结论。

实际经验结论（常见规律）

• TP 越大，TTFT 越低，但通信越重
• PP 提升显存利用率，但对小 batch 极不友好
• DP 是吞吐的唯一线性放大手段
• MoE 的 EP 在低并发下可能反而变慢

总结

并行策略没有最优解，只有最适解，TP / DP / PP / EP 并不是竞争关系，而是：

在模型规模、请求模式、硬件拓扑三者约束下的工程权衡。

vLLM 提供了一个极其适合做并行策略验证与对比实验的平台。真正有价值的工作不是“支持了什么并行”，而是：

• 在你的模型
• 在你的硬件
• 在你的真实请求负载下

验证哪种组合，才是最优解。

本文将不依赖任何具体推理框架，从 模型推理执行流 的角度，系统阐述什么是 PD Disaggregated、为什么需要它，以及它为 LLM 推理系统带来的核心优势。

LLM 推理的两个本质阶段

所有自回归大语言模型的推理过程，本质上都可以拆解为两个阶段：

Prefill（预填充阶段）

Prefill 阶段负责处理用户输入的完整 Prompt，其主要任务包括：

• 对输入序列进行一次完整前向计算；
• 构建上下文对应的 KV Cache；
• 生成第一个输出 Token。

这一阶段具有如下特征：

• 计算密集型（Compute-bound）
• 大规模矩阵乘法（GEMM）占主导
• 序列长度通常较长
• 对批处理（Batching）高度友好

Decode（解码阶段）

Decode 阶段进入逐 Token 生成过程，每一步都会：

• 输入上一个生成的 Token；
• 读取历史 KV Cache；
• 生成下一个 Token，直到结束条件满足。

其特征与 Prefill 明显不同：

• 访存密集型（Memory-bound）
• 计算规模小，但 KV Cache 访问频繁
• 强延迟敏感
• 执行步数随生成长度线性增长

问题根源：Prefill 与 Decode 的“异构性”

Prefill 与 Decode 并非同一类工作负载，它们在多个维度上呈现出显著异构性：

如果将这两种阶段混合部署、统一调度，就会导致资源使用上的结构性低效。

什么是 PD Disaggregated

PD Disaggregated（Prefill / Decode 解耦），指的是在推理系统架构层面：

将 Prefill 与 Decode 视为两类不同的工作负载，并在调度、资源分配甚至部署拓扑上对它们进行解耦设计。

需要强调的是：

• 这并不是模型结构的拆分；
• 也不是参数的拆分；
• 而是推理执行路径与资源使用方式的解耦。

PD Disaggregated 的核心思想是： 让 Prefill 为吞吐服务，让 Decode 为延迟服务。

为什么必须进行 PD 解耦

GPU 利用率的结构性浪费

混合执行时常见现象包括：

• Decode 阶段算子太小，GPU 算力无法被充分利用；
• Prefill 阶段的大算子又会阻塞 Decode；
• 结果是整体 GPU 利用率“看起来不低，但效率很差”。

PD 解耦后，可以针对不同阶段采用不同的调度和批策略，显著改善有效算力利用。

延迟不可预测，尾延迟恶化

在在线推理场景中，Decode 阶段直接决定用户体验：

• 首 Token 延迟（TTFT）
• 单 Token 延迟（TPOT）
• P99 / P999 延迟

如果 Decode 被 Prefill 阻塞，哪怕吞吐提升，用户体验也会显著下降。 PD Disaggregated 能从架构层面隔离延迟敏感路径。

扩展性受限

在混合架构下：

• Prefill 和 Decode 只能按同一比例扩容；
• 无法根据实际负载特征独立扩展某一阶段。

而真实业务中：

• Chat、Agent 场景 Decode 占比极高；
• 离线生成、批处理 Prefill 占比更高。

PD 解耦使得 按阶段独立扩展成为可能。

PD Disaggregated 的典型架构形态

在工程实践中，PD Disaggregated 通常体现为以下形式之一：

调度级解耦（Soft Disaggregation）

• Prefill 与 Decode 共享模型参数；
• 但在调度层面对二者区别对待；
• Decode 拥有更高优先级。

这是最轻量、最容易落地的形态。

资源级解耦（Resource Disaggregation）

• Prefill 与 Decode 使用不同的 GPU 资源池；
• Prefill GPU 偏向算力型；
• Decode GPU 偏向显存带宽与 KV Cache 容量。

该模式在大规模集群中尤为常见。

服务级解耦（Service Disaggregation）

• Prefill 与 Decode 成为独立服务；
• 中间通过 KV Cache 或状态句柄连接；
• 可独立伸缩、独立调度。

这是 PD Disaggregated 的“完全形态”，也是复杂度最高的一种。

PD Disaggregated 带来的核心优势

更高吞吐与更低延迟并存

传统架构往往需要在吞吐与延迟之间取舍，而 PD 解耦允许：

• Prefill 极致批量化；
• Decode 极致低延迟。

更稳定的尾延迟

Decode 不再被大规模 Prefill 阻塞，P99 / P999 延迟显著改善，这对生产系统至关重要。

更合理的资源利用

不同阶段匹配不同资源类型，避免“用算力型 GPU 跑访存密集任务”这类结构性浪费。

更强的系统演进能力

PD Disaggregated 为后续优化打开空间，例如：

• KV Cache 分层存储；
• Decode 专用硬件；
• 面向 Agent 的长时会话优化。

总结

PD Disaggregated 并不是某个框架的特性，而是对 LLM 推理本质的抽象与再设计：

• Prefill 和 Decode 在计算形态上天然异构；
• 强行混合只会掩盖效率问题；
• 解耦是走向规模化、高质量推理服务的必经之路。

可以预见，随着模型规模继续增长、应用形态日益复杂，PD Disaggregated 将从“高级优化”演变为 LLM 推理系统的默认架构假设。

微软研究院最近发布了 Fara-7B，这是一款专为电脑操作（Computer Use）设计的代理小语言模型（Agentic SLM）。与传统的聊天模型不同，Fara-7B 旨在通过像人类一样使用鼠标和键盘来完成任务。

什么是 Fara-7B？

Fara-7B 是一个拥有 70 亿参数的模型，基于 Qwen2.5-VL-7B 构建。它的主要特点包括：

• 视觉感知：它通过视觉感知网页（截图）来操作，不需要依赖辅助功能树（Accessibility Trees）或额外的解析模型。
• 高效紧凑：尽管只有 7B 参数，但在同类模型中实现了最先进的性能，甚至在某些基准测试中可以与更大的模型竞争。
• 端侧运行：由于体积小，它可以在设备上本地运行，从而降低延迟并提高隐私安全性。

核心技术

Fara-7B 的训练利用了微软开发的合成数据生成管道，该管道基于 Magentic-One 框架。它通过“观察-思考-行动”（observe-think-act）的循环来执行任务。

在每个步骤中，模型会接收：

1. 用户指令
2. 完整的操作历史
3. 最近的三张屏幕截图

然后，它会输出一个推理信息（“思考”下一步行动），随后调用工具（如 click(x,y)、type() 等）来执行操作。

性能表现

在 WebVoyager、Online-Mind2Web 等基准测试中，Fara-7B 展现了强大的性能。例如在 WebVoyager 上，它的任务成功率达到了 73.5%，超过了 UI-TARS-1.5-7B (66.4%) 和 GPT-4o (SoM Agent, 65.1%)。

如何通过 vLLM 使用 Fara-7B

Fara-7B 已经发布在 Hugging Face 上。由于它是基于 Qwen2.5-VL 的，我们可以使用 vLLM 来高效地部署和推理。

安装 vLLM

首先确保你安装了最新版本的 vllm：

pip install vllm

Python 代码示例

以下是一个使用 vLLM 加载 Fara-7B 并进行推理的 Python 脚本示例：

from vllm import LLM, SamplingParams
from PIL import Image
import requests
from io import BytesIO

def run_fara_7b():
    # 模型名称
    model_name = "microsoft/Fara-7B"

    # 初始化 LLM
    # Fara-7B 基于 Qwen2.5-VL，因此使用类似的配置
    llm = LLM(
        model=model_name,
        trust_remote_code=True,
        max_model_len=4096,  # 根据显存大小调整
        limit_mm_per_prompt={"image": 1},
        mm_processor_kwargs={
            "min_pixels": 28 * 28,
            "max_pixels": 1280 * 28 * 28,
        },
    )

    # 加载示例图片（这里仅作演示，实际使用中应为屏幕截图）
    image_url = "https://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/Gfp-wisconsin-madison-the-nature-boardwalk.jpg/2560px-Gfp-wisconsin-madison-the-nature-boardwalk.jpg"
    response = requests.get(image_url)
    image = Image.open(BytesIO(response.content))

    # 构建 Prompt
    # 注意：Fara-7B 使用特定的 Prompt 格式
    prompt = (
        "<|im_start|>system\nYou are a helpful assistant.<|im_end|>\n"
        "<|im_start|>user\n<|vision_start|><|image_pad|><|vision_end|>"
        "Describe this image in detail.<|im_end|>\n"
        "<|im_start|>assistant\n"
    )

    # 准备输入
    inputs = {
        "prompt": prompt,
        "multi_modal_data": {
            "image": image
        },
    }

    # 采样参数
    sampling_params = SamplingParams(temperature=0.2, max_tokens=512)

    # 生成结果
    outputs = llm.generate([inputs], sampling_params=sampling_params)

    for o in outputs:
        print(f"Generated text: {o.outputs[0].text}")

if __name__ == "__main__":
    run_fara_7b()

命令行启动 API 服务

如果你想启动一个兼容 OpenAI API 的服务，可以使用以下命令：

vllm serve microsoft/Fara-7B \
  --trust-remote-code \
  --limit-mm-per-prompt image=1 \
  --mm-processor-kwargs '{"min_pixels": 784, "max_pixels": 1003520}'

注意：min_pixels 对应 28x28，max_pixels 对应 1280x28x28。

总结

Fara-7B 是微软在代理小模型领域的一次重要尝试，它证明了小模型在复杂的电脑操作任务中也能有出色的表现。通过开源权重，开发者可以更轻松地探索和构建基于 GUI 的自动化代理。

注意：本译文已获得的原文作者翻译授权，为避免广告嫌疑，本文中移除了特定产品和品牌的商业宣传内容，仅保留技术特性及企业级产品功能描述，相关内容请以原文为准。

随着各组织从大语言模型（LLM）的试验阶段迈向生产部署，选择哪种推理平台就成了一项关键的业务决策。这个选择不仅影响性能，也影响灵活性、成本优化，以及应对快速变化业务需求的能力。

对于技术人员和方案架构师在评估 LLM 推理平台时，应该重点考虑以下三大因素：

1. 架构灵活性：能否在不同硬件加速器和混合云环境间部署，而不会被某一家厂商锁定。
2. 运行可扩展性：支持从单 GPU 部署扩展到分布式多节点的高级部署模式。
3. 生态开放性：对最广泛的模型与内核支持，以及能与各种企业软件生态系统整合。

vLLM 在开源基础、先进内存管理能力，以及即将推出的分布式部署蓝图方面，独特地满足这些需求。与专有或硬件专用方案不同，这套组合提供了在成本、性能和运营需求上随时优化调整的自由。

本文将深入分析为何 vLLM 在其技术架构与能力上（尤其是其 KV-Cache 管理、并行策略，以及未来的 llm-d 分布式能力）提供了最可持续的生产级 LLM 部署路径。

开源优势

社区驱动的大规模创新

LLM 推理的发展，根本上受到开源创新的推动。过去一年半以来 vLLM V1: A Major Upgrade to vLLM’s Core Architecture | vLLM 博客（英文版），vLLM 在支持多样模型、功能和硬件后端方面取得显著成绩，从伯克利大学的研究项目成长为开源 AI 生态中的事实标准之一 vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。

vLLM 社区发展参考链接

vLLM 现在隶属于 PyTorch 基金会托管项目（GitHub — vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs），这保证了其长远的可持续性和治理机制。

企业支持与开源结合

许多企业及产品及解决方案对 vLLM 的态度类似于其对 Linux/OpenStack/Kubernetes 的策略：在社区驱动创新基础上，加入企业级支持、安全性和运维工具。这样模型即可部署在本地、公有云或混合云中，避免绑定。

这种方式带来的好处包括：

• 无厂商绑定：用户可自由选择部署环境
• 透明开发：安全漏洞与缺陷公开追踪与快速修复
• 社区贡献共享：一个组织开发的功能惠及整个生态
• 可定制性：源代码开放，可针对特定需求修改

此外，vLLM 在以下方面具备战略优势：

• 硬件无关性：不局限于 NVIDIA，支持 AMD、Intel、TPU 等多种平台（GitHub — vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs）
• 快速功能迭代：vLLM v1 对其核心模块（调度器、KV 缓存管理、worker、采样器、API 服务等）进行了全面重构（vLLM V1: A Major Upgrade to vLLM’s Core Architecture | vLLM 博客（英文版））
• 生态整合：原生兼容 Hugging Face、OpenAI API、Kubernetes 生态
• 成本优化：可以为不同工作负载选择最具性价比的硬件

架构灵活性与并行化策略

理解并行化（Understanding Parallelization）

大型语言模型带来了特殊的扩展挑战。例如：一个拥有 70B 参数 的模型，仅其权重（使用 FP16 精度）就需约 140GB 内存，这远远超过单一卡片的容量。基于 vLLM 及相关产品和解决方案通过四种互补的并行化策略来应对这些挑战，每一种策略都解决不同类型的扩展问题。

数据并行（Data Parallelism, DP）：跨请求扩展

数据并行是最简单的一种扩展模式：在多个服务器上运行完整模型的多个副本，每个副本处理不同的请求批次。在这种模式下：

• 维护完整模型：每个加速器／服务器保存整个模型的权重。
• 分配请求：请求由负载均衡器分发给不同的副本。
• 支持线性扩展：增加服务器数目可以线性提升吞吐量。
• 简化部署：部署相对简单，不需要对模型进行切分（sharding）。

          [负载均衡器]
               |
    ------------------------
    |          |           |
[Server1]  [Server2]  [Server3]
[Model A]  [Model A]  [Model A]
    |          |           |
[Batch 1]  [Batch 2]  [Batch 3]

关键：每台服务器都有完整的模型副本并行处理不同的请求

此模式与基于 KServe 的 Replica-Sets 用于模型副本服务很好的契合，能自动根据请求负载进行扩展，同时保有模型服务的简单性。

流水线并行（Pipeline Parallelism, PP）：按层分配

流水线并行将模型按照层（layers）分拆，不同的加速器处理不同的网络层：

• 顺序处理：请求在 GPU 间依次通过模型层进行处理。
• 内存均衡：内存需求在多个设备间较为均匀分布。
• 灵活部署：部署灵活，可以跨多个节点，不一定依赖特别高速的互联。
• 微批处理：通过微批处理（micro-batching）来保持 GPU 利用率。

Request → [GPU1:NN-Layers 1-8] → [GPU2:NN-Layers 9-16] → [GPU3:NN-Layers 17-24] → Response
             ↓                     ↓                      ↓
          [Memory]              [Memory]               [Memory]
          
时间线：请求按顺序流经 GPU

但流水线并行在现代 LLM 应用中也面临一些限制：

• “流水线气泡”（pipeline bubble）效率低下：某些 GPU 在等待上游阶段的数据时处于空闲状态。
• 通信开销高：阶段间数据传输成为瓶颈。
• 延迟敏感：每个阶段都会增加延迟，对“第一个 token 的时间”（time-to-first-token）有负面影响。
• 对 MoE（Mixture of Experts，混合专家模型）不友好：MoE 模型中只激活某些专家（非密集执行），这样无法很好地映射到按层划分的流水线结构中。

因为这些限制，很多生产环境更倾向于将张量并行（Tensor Parallelism）用于节点内部扩展，将数据并行（Data Parallelism）用于跨节点扩展。尽管如此，在内存受限或与其他并行策略组合使用的场景中，流水线并行仍然有价值。

张量并行（Tensor Parallelism, TP）：切分模型权重

当模型太大，单个加速器无法容纳其所有权重时，就使用张量并行来将模型权重拆分到多个 GPU 上：

• 水平层拆分：每次矩阵乘法操作被分配到多个 GPU，按部分计算。
• 同步计算：GPU 之间通过高速互联（如 NVLink、Infinity Fabric 等）进行同步和数据交换。
• 内存效率：可使得模型可服务的规模比单个 GPU 容量大出约 4～8 倍。
• 低延迟：如果硬件条件合适，通信开销低的话，张量并行还能保持较低的延迟。

Original Matrix Operation:
[Large Weight Matrix] × [Input] = [Output]

With Tensor Parallelism:
[Weight Part 1] → GPU1 ↘
[Weight Part 2] → GPU2 → [Combine] → [Output]
[Weight Part 3] → GPU3 ↗

关键：单矩阵运算跨 GPU 拆分，需要高速互连（NVLink）

vLLM 的张量并行实现是硬件无关的，支持多种互联技术和不同类型的加速器。

专家并行（Expert Parallelism, EP）：MoE 模型中的专家分布策略

对于混合专家模型（MoE），专家并行把不同的专家（experts）分配给多个 GPU 或多个节点，而不是让每个 GPU 都保存所有专家，由一个路由层（router layer）动态地将 token 分发给需要的专家：

• 分布式专家分片：专家（experts）被分片（shard）分布在不同的 GPU／节点，使拥有上百个专家的模型能扩展到远超过单设备的内存容量。
• 动态 token 路由：每个 token 只被发送到它应使用的一个或多个专家，以减少计算开销。
• 专家并行负载平衡（Expert Parallel Load Balancing, EPLB）：防止某些热门专家／专家组被频繁调用导致不均匀负载，通过动态复制或分布专家，以分散负载。
• 分层调度（Hierarchical Scheduling）：在多节点集群中，路由与复制先在节点间协调，再在节点内部的 GPU 间协调，确保整体利用率均衡且减少跨节点通信。
• 性能收益：对大型的 MoE 模型，这种专家并行在具有高速互联（NVLink、InfiniBand 等）的环境中可以实现接近线性扩展的吞吐效率。

               [Router Layer]
                      |
        ---------------------------------
        |          |          |         |
      GPU1        GPU2       GPU3      GPU4
    [Exp 1,2]   [Exp 3,4]  [Exp 5,6]  [Exp 7,8]
    
令牌流：路由器 → 选定专家 → 输出

vLLM 的统一策略

vLLM 的区别与优势在于它能够无缝结合这些并行策略，为分布式推理提供高度灵活性，使组织能够：

1. 混合使用策略：例如，在节点内部用张量并行，在节点间用流水线并行。
2. 根据硬件特性调整：基于可用的互联速度、GPU 内存、延迟敏感性等因素做最优规划。
3. 动态扩展：可以从单节点部署起步，随着需求增长扩展到多节点／多 GPU。
4. 保持 API 的一致性：无论使用哪种并行策略，道线路径、调用接口等对使用者尽量透明，不需要因为并行方式不同而改很多逻辑。

这种灵活性在混合云环境中尤其关键，因为不同环境（本地、云端、不同厂商硬件）之间的配置可能大不相同。

Hybrid TP+PP+EP+DP Deployment (MoE Model):

Pipeline Stage 1:               Pipeline Stage 2:              Pipeline Stage 3:
Node 1 (Attention Layers)       Node 2 (MoE FFN Layers)        Node 3 (Output Layers)
[Attn Part A] ←→ [Attn Part B]  [Router + Experts Subset]      [Out Part A] ←→ [Out Part B]
    GPU1           GPU2          GPU3: Experts 1-4                  GPU5            GPU6
         ↕ NVLink ↕              GPU4: Experts 5-8                       ↕ NVLink ↕
                                     ↕ NVLink ↕

Expert Distribution Detail (Node 2):
            [Router]
         GPU3  |  GPU4
        -------|-------
        Exp1   |  Exp5
        Exp2   |  Exp6  
        Exp3   |  Exp7
        Exp4   |  Exp8

Request Flow: → [Attention] → [MoE Layer/Router] → [Output] → Response
                              ↓
                    [Route to specific experts]

Parallelization Breakdown:
- Tensor Parallel (TP): Attention and Output layers split within nodes.
- Pipeline Parallel (PP): Different model stages across nodes .
- Expert Parallel (EP): MoE experts distributed across GPUs in Node 2.
- Data Parallel (DP): Entire pipeline can be replicated for more throughput.

更好的内存管理：KV-Cache（Key-Value 缓存）

在 LLM 推理中理解 KV-Cache

KV-Cache（键-值缓存）是 LLM 推理优化中最关键的特性之一。在注意力计算期间，模型必须访问先前 token 的表示 —— 随着序列长度增长，这个过程变得非常消耗内存。

高效的 KV-Cache 管理能决定同一硬件上能同时服务 10 个并发用户或 100 个并发用户，因为缓存复用将计算换成内存利用率。

(Q * K^T) * V computation process with caching

Step 1 (Prefill Phase)
                    Keys Transpose
                          ↓
    Queries              Keys              Values            Results
       |                  |                  |                  |
    [  Q  ]      ×     [  K  ]      →    [Scores]     ×    [  V  ]    →    [Output]
       |                  |                  |                  |
      64                 64                                    64              64
                          ↓                                     ↓
                    [Storing K]                           [Storing V]
                          ↓                                     ↓
                    ←── Cache memory (stores both K and V) ──→

Step N (Decode Phase)
                    Keys Transpose
                          ↓
    Query              Cached K            Cached V          Results
       |                  |                  |                  |
    [  q  ]      ×   [K₁...Kₙ]      →    [Scores]     ×   [V₁...Vₙ]   →    [output]
    (new)             (from cache)                         (from cache)       (new)
       |                  |                  |                  |
       1                 64                                    64               1
                          ↑                                     ↑
                    ←── Reading from cache (both K and V) ──→

Key Points:
- Prefill: Computes K and V for all input tokens, stores both in cache
- Decode: For each new token, reads ALL previous K and V values from cache
- Both K and V matrices must be cached (not just V)
- Cache size grows with sequence length

Prefill 阶段 vs Decode 阶段：两个截然不同的阶段

LLM 推理包含两个本质不同的阶段：

Prefill 阶段（Prompt 处理阶段）

• 并行处理所有输入 token。
• 计算密集型，GPU 利用率高。
• 为 prompt 中的所有 token 生成初始的 KV-Cache 条目。
• 延迟与 prompt 长度成正比。
• 大批量（larger batch sizes）带来好处。

Decode 阶段（Token 生成阶段）

• 一个 token 一个 token 顺序生成。
• 此阶段受限于内存带宽（memory-bandwidth bound）。
• 每新增一个 token，都要读取整个 KV-Cache 来自缓存的所有先前的 K 和 V。
• 延迟与输出 token 数量成正比。
• 依赖高效的缓存管理。

PagedAttention：vLLM 的内存革命

vLLM 引入 PagedAttention，这是一种在 KV-Cache 管理方面的突破性设计，它将 GPU 内存视为类似操作系统中的虚拟内存（virtual memory）来处理，其关键设计包括：

• 非连续存储（Non-contiguous Storage）：KV-Cache 块可以存储在 GPU 内存的任意地方，不必是连续的。
• 动态分配（Dynamic Allocation）：随着序列长度增长时才分配内存。
• 内存共享（Memory Sharing）：完全相同的 prompt 前缀（prompt prefixes）可以共享 KV-Cache 块。
• 几乎零浪费（Near-Zero Waste）：消除静态分配中常见的内部碎片问题。

这种设计让 vLLM 可以维持更大的批量大小、更高的并发性、以及比那些依赖静态、大型 KV-Cache 缓冲区的系统更好的 GPU 利用率。

连续批处理（Continuous Batching）：最大化 GPU 利用率

vLLM 的连续批处理机制带来了几个举措：

• 动态请求加入：新的请求可以在 decode 步骤之间加入正在运行的 batch。
• 提前完成处理：已经完成的序列立即释放资源。
• GPU 使用最优化：通过混合处理 prefill 与 decode 操作以保持高利用率。
• 支持抢占（Preemption）：可以暂停低优先级的请求以优先处理紧急请求。

在部署中的实际意义

这些内存管理上的创新在实际部署中带来了具体的效益：

1. 更高的并发性：在相同硬件上服务更多用户。
2. 更佳的成本效率：大幅减少基础设施需求。
3. 改善延迟：通过高效调度缩短 time-to-first-token。
4. 灵活性：可以处理变长的序列长度，而无需重新配置系统。

KV-Cache 优化在即将推出的 llm-d 分布式架构中变得尤为关键，因为高效的内存使用使得过去因内存约束而无法实现的新部署模式成为可能。

使用 llm-d 扩展：Kubernetes 原生的分布式推理

超越单服务器部署

虽然 vLLM 自身是高性能推理引擎，但在大规模生产环境中，还需要复杂的编排和智能请求调度。2025 年 5 月，红帽、Google Cloud、IBM 研究院、NVIDIA 和 CoreWeave 联手推出 llm-d，构建在 vLLM 之上的 Kubernetes 原生分布式推理栈。

llm-d 并不是 vLLM 的内置功能，而是一个补充的编排层。可以把它比作 Linux 与 Kubernetes 的关系：vLLM 负责推理引擎，llm-d 负责跨实例的调度与编排。它结合了三项开源技术：vLLM、Inference Gateway（AI 路由层）和 Kubernetes。

KServe 也在集成 llm-d，通过新的 LLMInference CRD，实现统一的服务接口，简化生成式 AI 的企业上手路径。

llm-d 将三大基础开源技术集成到一个统一的服务栈中：

• vLLM - 执行模型推理的高性能推理引擎。
• 推理网关（IGW） - 一个官方 Kubernetes 项目，通过 AI 感知路由扩展了 Gateway API。
• Kubernetes - 用于部署和扩展的行业标准编排平台。

通过整合这些技术，llm-d 使企业能够在混合云环境中大规模部署 LLM 推理，并实现最快的价值实现时间和极具竞争力的性价比。

三项关键创新

传统的负载均衡采用简单的轮询（round-robin）路由，对所有服务器一视同仁。llm-d 的 vLLM 感知调度程序能够做出智能决策，将请求路由到具有匹配缓存前缀的实例，根据实例是处理计算密集型预填充操作还是内存密集型解码操作来分配负载，并使用来自 vLLM 的实时可观测数据来避免实例过载，同时优先处理低延迟路径。这种智能路由可将基础设施成本降低 30% 到 50%，同时保持延迟 SLO。

解耦式服务（Disaggregated Serving）

llm-d 在生产规模上协调 vLLM 的本机分解服务（通过 KVConnector API），将预填充和解码分离到专门的工作节点中：

• 预填充工作节点：负责计算密集型的提示处理，使用高性能 GPU（如 H100、MI300X），并可根据需求独立扩展。

• 解码工作节点：专注于受内存带宽限制的 token 生成任务，使用具成本效益的 GPU（如 A100、L40S），并根据并发会话数进行弹性扩缩。

• KV 缓存传输：使用 NVIDIA NIXL 通过 UCX 提供高效的缓存移动，支持卸载到存储后端（未来交付）以及跨集群的全局缓存感知。

这允许适当规模的基础设施：昂贵的 GPU 仅用于预填充，成本优化的硬件可为数千个并发用户提供服务。

分布式前缀缓存（Distributed Prefix Caching）

llm-d 将 vLLM 的前缀缓存扩展到多个实例之间，通过两种方式实现：

• 本地缓存：在每个实例上将缓存卸载（offload）到内存或磁盘，几乎没有运维成本。

• 共享缓存（计划中）：通过实例之间的 KV 传输实现共享，并使用全局索引实现集群范围的缓存感知。

部署模式（Deployment Patterns）

llm-d 支持多种先进的企业部署模式：

• 异构硬件：根据工作负载混合 GPU 供应商和代数——用于预填充的高端 GPU、用于解码的成本优化 GPU 或用于低频请求的 CPU 集群。

• 动态扩缩：在高峰时段独立调整预填充容量，同时保持活动会话的稳定解码容量，并具有自动资源分配和故障转移功能。

• 地理分布（规划中）：在主数据中心部署集中式预填充工作者，并在用户附近部署边缘解码工作者，以实现低延迟响应。

多加速器与混合云支持

摆脱硬件锁定

AI 加速器快速演进，使市场变得多样化。专优化 NVIDIA 的方案如 TensorRT-LLM 虽然性能优秀，但容易导致锁定。vLLM 的硬件中立设计则允许用户自由选择最适合的加速器。

广泛硬件支持

vLLM 支持 NVIDIA GPU（针对 H100 进行一流的优化，支持 V100 及更新版本的所有 NVIDIA GPU）、AMD GPU（MI200、MI300 和 Radeon RX 7900 系列）、Google TPU（v4、v5p、v5e 和最新的 v6e）、AWS Inferentia 和 Trainium（trn1/inf2 实例）、Intel Gaudi（HPU）和 GPU（XPU）以及支持 x86、ARM 和 PowerPC vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。

这种广泛支持带来以下战略优势：

成本优化

• 选择 AMD MI300X，在特定工作负载下实现高性价比。
• 使用 AWS Inferentia，在 AWS 上进行经济高效的推理。
• 在低吞吐量用例中，可部署在现有 CPU 基础架构上。

供应链弹性

• 避免依赖单一 GPU 供应商的可用性。
• 通过多种选择协商更优惠的价格。
• 根据区域硬件可用性进行调整。

工作负载匹配

• NVIDIA H100 可实现最佳性能。
• AMD GPU 适用于开源部署。
• TPU 适用于 Google Cloud 部署。
• Intel Gaudi 适用于特定企业协议。

混合云部署模式

在企业级产品及解决方案中，vLLM 支持真正的混合云：

本地核心

• 在本地基础架构上处理敏感数据。
• 满足合规性要求的工作负载。
• 可预测的基线负载容量。

云爆发式扩展

• 利用云资源处理峰值负载。
• 试用新硬件（H100s、TPU v6e）。
• 无需基础设施投资即可实现地域扩展。

边缘推理

• 部署在适合边缘计算的硬件上。
• CPU 或更小的 GPU 推理。
• 与集中管理集成。

统一运维跨环境

借助企业级产品的相关功能，用户可从单一控制平面管理全部部署（公有云 + 私有云），主要从一下几个方面考虑。

• 单一控制平面：通过统一界面管理所有部署。
• 一致的 API：跨环境实现相同的应用程序集成。
• 统一监控：跨混合部署的聚合指标。
• 策略执行：一致的安全和合规策略。

模型生态与兼容性

支持广泛的开源模型体系

随着人工智能“淘金热”步伐的加快，vLLM 已发展到支持超过 100 种模型架构的高性能推理：涵盖几乎所有著名的开源大型语言模型（LLM）、多模态模型（图像、音频、视频）、编码器-解码器模型、推测解码模型、分类模型、嵌入模型和奖励模型。vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。与专注于有限模型系列的专业解决方案相比，这种全面的支持具有根本性的优势。

不只是传统 LLM

vLLM 的架构支持更多样的模型类型：

语言模型

• Llama 系列。
• Mistral 和 Mixtral 多模态模型。
• Google 的 Gemma 模型。
• IBM 的 Granite 系列。
• 阿里巴巴的 Qwen 模型。

多模态模型

• 视觉-语言模型（LLaVA, Qwen-VL）。
• 文档理解模型。
• 音频-语言模型。
• 视频理解能力。

专用架构

• 状态空间语言模型的生产支持，探索非 Transformer 语言模型的未来。vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。
• 混合专家（MoE）模型。
• 编码器-解码器架构。
• 嵌入和重排序模型。

模型集成简易流程

将新模型加入 vLLM 通常包括以下步骤：

1. 模型架构定义：使用熟悉的 PyTorch 模式实现。
2. Attention 后端集成：利用现有的优化内核。
3. Tokenizer 支持：兼容 Direct Hugging Face。
4. 配置映射：基于标准 YAML 的配置。

这样的标准化流程意味着组织能更快将新模型投入生产。例如，在 2025 年 8 月 GPT-OSS 发布后不久，vLLM 的 v0.11.0 版本就加入了对其生产部署的支持。

与 Hugging Face 生态整合

vLLM 与 Hugging Face 的原生兼容带来了便捷性：

直接模型加载

• 直接从 Hugging Face Hub 和/或兼容 S3 的对象存储后端（例如 MinIO）加载模型。
• 支持私有模型库。
• 自动权重转换处理。

分词器兼容性

• 使用现有的分词器实现。
• 支持自定义分词器。
• 快速分词器优化

配置保存

• 尊重特定于模型的配置。
• 支持自定义模型参数。
• 兼容经过微调的变体。

生产级模型管理

在一些企业级产品和方案中增加了模型生命周期的企业功能：

模型注册集成

• 已部署模型的版本控制。
• A/B 测试功能。
• 回滚机制。

模型监控

• 每个模型的性能跟踪。
• 使用情况分析和成本归因。
• 偏差检测功能。

面向未来的模型支持

模型创新速度极快，推理平台必须具备适应能力：

社区贡献

• 活跃的社区不断添加新模型。
• 供应商中立的开发流程。
• 快速集成突破性架构。

灵活的架构

• 模块化设计支持新的模型范式。
• 不受特定模型假设的约束。
• 为后转型架构做好准备。

企业验证

• 企业的测试和认证流程。
• 模型工件的安全扫描。
• 跨硬件性能验证。

这种全面的模型支持确保组织能够在新模型出现时立即采用它们，而无需进行平台迁移或架构更改，这是人工智能领域持续快速发展的一项关键能力。

使用企业级产品进行企业部署

从第一天起就是生产级

大多数企业级产品提供了一个灵活、可扩展的 MLOps 平台，提供构建、部署和管理 AI 应用的工具。它采用开源技术构建，为团队提供值得信赖且操作一致的功能，用于实验、模型服务和交付创新应用。了解更多关于企业级产品如何应对这一挑战的信息。

与 KServe 的整合：智能模型服务

在许多产品和方案中对 vLLM 与 KServe 的集成提供了企业级服务功能：

GenAI 功能

• 使用 vLLM 服务运行时进行多节点/多 GPU 推理。
• 通过 vLLM + LMCache 集成卸载键值缓存。
• 通过模型缓存高效重用模型。
• 集成 KEDA，允许基于外部指标自动扩缩。
• 通过与 Envoy AI Gateway 集成实现速率限制和请求路由。
• 通过 LLMInferenceService CRD 访问 llm-d 功能。

高级自动扩缩

• 基于请求的扩缩，实现资源利用率优化。
• 缩减​​至零功能，实现成本优化。
• 基于流量模式的预测性扩缩。
• 多指标扩缩（GPU 利用率、队列深度、延迟）。

流量管理

• 金丝雀部署，确保模型更新安全。
• 蓝绿部署，实现即时回滚。
• A/B 测试，用于模型比较。
• 影子流量，用于验证。

服务网格集成

• 使用 Istio 进行端到端加密。
• 高级路由和负载均衡。
• 熔断和重试逻辑。
• 用于调试的分布式跟踪。

自动化运维

• 健康检查和自动恢复。
• 资源优化建议。
• 自动化证书管理。
• 日志聚合和分析。

安全与合规

在企业部署中，必须重视安全：

访问控制

• RBAC 与企业身份提供商集成。
• 模型级访问权限。
• API 密钥管理。
• 所有操作的审计日志记录。

数据保护

• 静态和传输中加密。
• 私有端点选项。
• 网络策略实施。
• 合规性报告工具。

供应链安全

• 签名容器镜像。
• SBOM（软件物料清单）生成。
• 漏洞扫描。
• 基于策略的部署控制。

MLPerf 验证的性能

一些企业级解决方案和产品与众多知名服务器原始设备制造商（OEM）合作，使用搭载 NVIDIA GPU 和 vLLM 推理运行时的产品发布了令人印象深刻的 MLPerf 推理结果，在应对这一挑战方面取得了重大进展。加速生成式 AI 的采用，这些结果验证了：

• 规模化生产级性能。
• 高效的资源利用率。
• 负载下一致的延迟。
• 多实例协调能力。

集成可观测性

无需额外工具即可进行全面监控：

指标和仪表板

• 预建 Grafana 仪表板，用于 vLLM 指标。
• 预建 Grafana 仪表板，用于驱动路由决策的请求调度程序指标。
• 令牌生成率和延迟。
• GPU 利用率和内存使用率。
• 队列深度和拒绝率。

警报和响应

• SLA 违规自动警报。
• 与企业监控系统集成。
• Runbook 自动化功能。
• 容量规划洞察。

成本管理与优化（未来交付）

专为企业成本控制设计的功能：

• 计费/显示：按团队或项目跟踪使用情况。
• 资源配额：防止成本失控。
• 竞价型实例支持：降低批量工作负载的成本。
• 空闲检测：自动缩减未使用的资源。

这个企业级平台将 vLLM 从高性能推理引擎转变为完整的生产解决方案，可用于关键任务部署。

特性对比：vLLM vs TGI vs TensorRT-LLM

✓ = 全面支持，◐ = 部分/有限支持，✗ = 不支持

企业级产品与开源 vLLM 的主要区别

• 硬件灵活性：最广泛的加速器支持，包括 AMD、Intel、Google TPU 和 CPU。
• 模型生态系统：支持超过 100 种模型架构，而其他替代方案仅有 25-40 种。
• 分布式架构：即将推出的 llm-d 支持分解式预填充/解码和系统级 kv-cache 路由，以实现分布式最优扩展。
• 企业集成：企业级产品集成 KServe 自动扩展。
• 内存效率：先进的 PagedAttention 和 KV-Cache 管理。
• 开放开发：PyTorch 基金会项目，社区创新迅速。

如何作出正确选择

文中给出一个简单的决策框架：对每个判断点打 “Yes”：

• 0–2 个 “Yes”：可考虑专用方案（若其满足你的特定需求）
• 3–5 个 “Yes”：vLLM 在你的场景中将提供显著优势
• 6+ 个 “Yes”：基于 vLLM 的企业级产品是战略性选择

每个决策点都涉及基本的架构约束：

• 灵活性要求决定您是否需要与硬件无关的解决方案。
• 运营复杂性评估简化的运营是否值得采用开源技术。
• 模型与创新评估快速发展是否需要一个适应性强的平台。
• 长期可持续性考虑总体拥有成本和战略风险。

战略推荐

如果你对多个维度都倾向 “Yes”，那 vLLM + 企业级产品将提供：

• 最大的灵活性：可在任何受支持的硬件上部署。
• 优秀的运维体验：企业级平台，复杂性极低。
• 面向未来的能力：支支持新兴模型和架构。
• 成本优化：为每种工作负载选择最佳硬件。
• 风险控制：开源基础，提供企业级支持。

这些因素的融合使得 vLLM 成为构建可持续人工智能基础设施的组织的战略选择。

采纳步骤建议

立即阶段

• 在开发环境部署 vLLM + 企业级产品
• 用自己的模型和工作负载进行测试
• 验证硬件灵活性与性能

短期阶段

• 实施 KServe 的自动扩缩能力
• 建立监控与可观察性体系
• 培训团队操作流程

中期阶段

• 设计生产部署架构
• 若需要，实施混合云模式
• 为 llm-d 分布式架构做准备

长期阶段

• 优化成本（选硬件、资源调度）
• 引入更高级部署模式
• 将自己的改进贡献给社区

总结

选择 LLM 推理平台代表着一项战略承诺，它将影响您组织未来几年的人工智能能力。

我们的分析表明，企业级产品上的 vLLM 独特地满足了企业 LLM 部署的三个关键要求：

1. 灵活性：可在任意硬件与混合云环境部署
2. 可扩展性：先进内存管理与 llm-d 架构使资源利用效率提升 10–100 倍
3. 可持续性：开源基础 + 企业支持，避免陷入锁定

虽然 TensorRT-LLM 提供了 NVIDIA 专属优化，TGI 也提供了 Hugging Face 集成，但“只有 vLLM 能够提供快速发展的 AI 领域所需的架构灵活性”。 凭借对 100 多种模型架构的支持、与硬件无关的设计以及 PyTorch 和 Linux 基金会的支持，->“搭载 vLLM 的企业级产品为长期成功奠定了最坚实的基础”。

• 模型参数（Parameters, P）动辄上百 GB，需要长期驻留显存。
• 输入/输出数据（Data, D）则随请求动态变化，但往往和参数耦合在同一设备上，导致显存占用不均衡，扩展性受限。

为了解决这一问题，可以借助 vLLM 框架实现参数 / 数据（P/D）分离，提升推理系统的灵活性和吞吐。

大模型推理的资源瓶颈

以一个 70B 规模的 Transformer 模型为例：

• 参数权重（FP16 存储）约需 140GB 显存；
• 每次请求输入的序列数据、KV Cache 会消耗额外显存，并随 batch size 增长而急剧膨胀。

如果不加区分地将 P 与 D 放在同一块 GPU：

1. 参数长期驻留，挤压了用于动态数据的显存；
2. 多实例并发时，数据显存不足，限制了吞吐。

因此，在分布式推理系统中，业界逐渐采用 参数与数据分离（P/D Separation） 的架构思路。

vLLM 简介

vLLM 是一个高性能的大模型推理引擎，核心优势包括：

• PagedAttention：高效管理 KV Cache，支持大批量并发；
• 高吞吐率：相较于 Hugging Face Transformers 推理，吞吐提升数倍；
• 灵活的分布式支持：可结合 DeepSpeed、Megatron 等方案，支持参数/数据分布式存储与调度。

vLLM 的模块化架构，使其天然适合实现 P/D 分离。

P/D 分离的实现思路

在 vLLM 中，推理流程大致分为两个部分：

1. 参数侧（P）

   • 模型权重加载与存放；
   • 可通过 ZeRO-3 / Tensor Parallel 等策略将参数分布在多 GPU 节点上；
   • 参数在整个推理生命周期中保持常驻，不随请求波动。

2. 数据侧（D）

   • 动态输入序列、KV Cache、采样状态等；
   • 可使用 PagedAttention 管理显存分页；
   • 支持把部分 KV Cache 放到 CPU/Host 内存，再动态迁移到 GPU。

核心机制

其核心机制是显存资源隔离：

• 权重（P） 固定驻留在专门的 GPU（参数节点）；
• 数据（D） 可以按需分配到其他 GPU（数据节点），甚至利用 CPU 内存 / NVMe。

这样：

• 参数显存不与动态数据抢占空间；
• 数据可以根据请求动态扩展，提升并发能力。

在 vLLM 中的实现路径

实现 P/D 分离的常见方法：

1. 参数分片（Parameter Sharding）

   • 借助 vLLM 对 Megatron-LM / DeepSpeed 的支持，将模型参数按张量维度切分到多 GPU；
   • 仅在推理计算时聚合，不需要在每个设备上完整存放参数。

2. KV Cache 分离（Data Sharding）

   • 通过 vLLM 的 PagedAttention，可以把 KV Cache 存在独立的 GPU 或 Host 内存；
   • 在推理过程中按需调页，类似操作系统的虚拟内存机制。

3. Pipeline 并行化

   • 将模型计算划分为不同阶段，前几层专门占用参数节点，后几层在数据节点完成；
   • 在流水线中，数据逐层传递，而参数保持分片驻留。

基于 vLLM 的 P/D 分离实战

下面给出两部分内容：

• 配置示例：如何在多 GPU 环境下指定参数和数据分布；
• 代码示例：如何加载模型并运行推理，展示参数常驻、数据动态分配。

配置示例

假设我们有 4 张 GPU：

• GPU 0,1：专门存放模型参数（P）；
• GPU 2,3：主要承载 KV Cache 等动态数据（D）。

我们可以在启动 vLLM 时设置：

CUDA_VISIBLE_DEVICES=0,1,2,3 \
python -m vllm.entrypoints.api_server \
    --model /path/to/llama-2-70b \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.85 \
    --enable-chunked-prefill \
    --enforce-eager \
    --kv-cache-dtype fp16 \
    --max-num-batched-tokens 4096

这里的关键点：

• --tensor-parallel-size 2：只在 GPU 0,1 上做参数分片存放；
• --gpu-memory-utilization：控制参数占用的比例，留出余量给数据；
• --kv-cache-dtype fp16：降低 KV Cache 精度，减少数据显存占用；
• vLLM 内部的 PagedAttention 会自动把 KV Cache 分配到 GPU 2,3，如果溢出则回退到 CPU 内存。

代码示例

下面是一个 Python 调用示例：

from vllm import LLM, SamplingParams

# -------- 参数（P）分离 --------
# tensor_parallel_size=2 表示参数分布在前两张 GPU（0,1）
llm = LLM(
    model="/path/to/llama-2-70b",
    tensor_parallel_size=2,
    gpu_memory_utilization=0.85,
    enforce_eager=True,       # 避免显存碎片
    enable_chunked_prefill=True,
    kv_cache_dtype="fp16"     # 数据（D）使用更轻量的缓存精度
)

# -------- 数据（D）分离 --------
# PagedAttention 会自动管理 KV Cache 的存放位置（GPU2, 3, 甚至 CPU 内存）
sampling_params = SamplingParams(
    temperature=0.8,
    top_p=0.95,
    max_tokens=256
)

prompt = "解释一下通过 vLLM 实现 P/D 分离的好处。"

# 运行推理
outputs = llm.generate([prompt], sampling_params)

print("模型输出：")
for output in outputs:
    print(output.outputs[0].text)

验证方式

运行时可以用 nvidia-smi 观察：

• GPU 0,1 显存几乎恒定，主要承载参数；
• GPU 2,3 的显存随请求数量/序列长度波动，主要承载 KV Cache；
• 如果输入过大，KV Cache 会溢出到 CPU 内存，但仍可继续推理。

实际效果与收益

通过 P/D 分离，可以得到以下好处：

• 提升 GPU 利用率：参数和数据分工明确，避免显存冲突；
• 支持更大 batch size：数据显存可扩展，吞吐率提升显著；
• 降低成本：参数可驻留在高端 GPU，而数据可放到中低端 GPU 或 CPU 内存，形成分层存储；
• 灵活性：适配多种硬件资源组合（A100 + H100, GPU + CPU, GPU + NVMe）。

在实践中，结合 vLLM 的 PagedAttention，P/D 分离的效果尤为明显，可让大模型推理在同样硬件下实现 数倍并发提升。

总结

vLLM 框架凭借其高效的 KV Cache 管理和分布式能力，为 大模型推理的 P/D 分离 提供了坚实基础。 通过将 参数（P） 和 数据（D） 解耦，可以更好地利用硬件资源，提升推理性能与扩展性。

未来，随着 混合精度存储、分层缓存（GPU+CPU+NVMe） 的发展，P/D 分离架构将逐渐成为大模型推理的主流范式。

SGLang 简介

SGLang 是一款面向大语言模型（LLM）和视觉语言模型（VLM）的高性能推理框架，通过精心设计的后端运行时与前端语言协同工作，使模型交互更加高效且可控。其核心优势包括：

• 高效后端运行时：采用创新的 RadixAttention 技术实现前缀缓存，支持跳跃式受限解码、零开销 CPU 调度、连续批处理、令牌注意力（分页注意力）、张量并行、FlashInfer 内核、分块预填充以及多种量化技术（FP8/INT4/AWQ/GPTQ），显著提升推理效率。
• 灵活前端语言：提供直观且强大的 LLM 编程接口，支持链式生成调用、高级提示工程、复杂控制流、多模态输入、并行处理及外部系统交互。
• 广泛模型兼容性：支持多种主流生成式模型（Llama、Gemma、Mistral、QWen、DeepSeek、LLaVA 等）、嵌入模型（e5-mistral、gte）及奖励模型（Skywork），并提供简便的新模型扩展机制。
• 活跃开源生态：拥有蓬勃发展的社区支持，已获得广泛业界认可（截至 2025 年 3 月 17 日，GitHub 累计星标超过 12,000）。

其技术架构如下：

除此之外，对于初学者，需要了解其以下特性：

• OpenAI 兼容 API：直接用 openai Python SDK 或 cURL 调用，不用改你的上层业务代码。
• 高吞吐与低延迟：结合连续批处理与前缀缓存等技巧，让相同前缀的请求复用计算。
• 生产友好：支持多并发、流式输出、可与 Hugging Face 模型库直接对接。

环境准备

工欲善其事必先利其器，要完成本文的新手实验，需准备如下环境：

• 操作系统：建议 Linux（常用为 Ubuntu 20.04+）。WSL2 也可尝试。
• Python：建议 3.10 或 3.11。
• GPU：建议 NVIDIA 显卡，24GB 显存可跑 7B/8B 级（如 Llama 3.1 8B）。没有 GPU 也能跑小模型或量化模型，但性能有限。
• 模型来源：Hugging Face（如 meta-llama/Llama-3.1-8B-Instruct）或本地路径。

安装 SGLang

环境就绪后，使用 pip 安装 SGLang（确保已安装 pip、可选创建虚拟环境）。

pip install sglang openai huggingface-hub

如果你需要从 Hugging Face 自动下载私有或受限模型，请先登录或设置 Token：

huggingface-cli login
# 或
export HF_TOKEN=您的Token

启动 SGLang 服务

可以通过以下两种启动方式进行 SGLang 服务的启动。不同版本的 SGLang 命令行参数可能略有差异，如果出现参数名称不匹配，先执行 –help 查看本机版本支持的参数。

通过 launcher 启动

python -m sglang.launcher \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 30000 \
  --tp 1 \
  --max-model-len 8192

其中常用参数说明如下：

• –model：Hugging Face 模型名称或本地模型权重路径
• –host/–port：服务监听地址与端口
• –tp：Tensor Parallel 并行度（单卡设为 1；多卡可根据需要设为 2、4 等）
• –max-model-len：上下文最大长度

另外需要注意以下两点：

• 如果使用的是 Hugging Face 模型，首次运行会下载模型权重，请确保网络通畅。
• 如果显存吃紧，可优先尝试更小模型，或减少 –max-model-len。

通过 sglang 命令启动

如果您使用的版本提供 sglang serve 命令，也可使用如下命令进行启动：

sglang serve -m meta-llama/Llama-3.1-8B-Instruct --host 0.0.0.0 --port 30000

快速验证

服务启动后，OpenAI 兼容接口即可使用：

curl http://127.0.0.1:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer EMPTY" \
  -d '{
    "model": "meta-llama/Llama-3.1-8B-Instruct",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "用两句话介绍一下你自己。"}
    ],
    "max_tokens": 128,
    "temperature": 0.2
  }'

如果运行正常，将返回标准的 ChatCompletion JSON 响应。

使用 Python OpenAI SDK 进行调用

非流式调用（最简单的问答）：

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:30000/v1",
    api_key="EMPTY"  # 本地服务通常不校验
)

messages = [
    {"role": "system", "content": "You are a helpful assistant who answers in Chinese."},
    {"role": "user", "content": "请用三句话介绍帕累托最优。"}
]

resp = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=messages,
    temperature=0.2,
    max_tokens=256
)

print(resp.choices[0].message.content)

流式输出（边生成边打印）：

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:30000/v1", api_key="EMPTY")

messages = [
    {"role": "system", "content": "You are a helpful assistant that speaks Chinese."},
    {"role": "user", "content": "简述 Transformer 的核心思想，并给出一个现实类比。"}
]

stream = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=messages,
    temperature=0.2,
    max_tokens=300,
    stream=True
)

for chunk in stream:
    if chunk.choices and chunk.choices[0].delta:
        delta = chunk.choices[0].delta.content
        if delta:
            print(delta, end="", flush=True)

print("\n[Done]")

通过以上两种方式，我们可以构建自己的推理服务应用，也可以通过市面上开源的软件来接入您部署的推理服务，如 Open-WebUI 等。

常见问题与排错

• 启动时报显存不足（CUDA OOM）
  • 尝试更小的模型（如 7B/8B）、减小 --max-model-len、或降低并发。
  • 如果有多卡，增加 –tp 并用多卡分摊显存。
• 拉取模型失败或速度慢
  • 先执行 huggingface-cli login；或提前手动把模型权重下载到本地路径，并在 --model 里填本地路径。
• API 报 Unknown argument
  • 不同版本的命令行参数可能有差异。请运行：python -m sglang.launcher --help
  • 根据你安装的版本调整参数名，如 --model / --model-path、--tp / --tensor-parallel-size 等。
• Python 客户端 401/Key 错误
  • 本地服务通常不校验 Key，只要带上一个占位即可（如 EMPTY）。
• 流式输出不打印
  • 确认传了 stream=True；迭代 chunk 时取 choices[0].delta.content。
• 并发性能不达预期
  • 尝试用 Async 客户端并发请求；避免在单线程里串行等待。
  • 检查 GPU 利用率；确认没有 CPU/GPU 数据传输瓶颈。

总结

至此，你已经完成了：

• 安装与启动 SGLang 服务
• 用 OpenAI 兼容接口进行非流式与流式推理

祝你上手顺利，玩得开心！如果遇到命令行参数或 API 的小差异，参考本地版本的 –help 与官方文档进行快速适配即可。