API服务与部署 — 概念

服务架构

前端模式

vLLM 现在支持三种前端模式：

模式	实现	触发条件	适用场景
Python FastAPI	`APIServerProcessManager`	默认	通用场景
Rust Frontend	`RustFrontendProcessManager`	`VLLM_RUST_FRONTEND_PATH` 环境变量	高性能低延迟
DP Supervisor	`launchers/dp_supervisor.py`	`--data-parallel-multi-port-external-lb`	多 GPU 数据并行

OpenAI 兼容 API

Chat Completions

bash

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3-8B",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Hello!"}
    ],
    "temperature": 0.7,
    "max_tokens": 256,
    "stream": true
  }'

Text Completions

bash

curl http://localhost:8000/v1/completions \
  -d '{
    "model": "meta-llama/Llama-3-8B",
    "prompt": "Once upon a time",
    "max_tokens": 100
  }'

Embeddings

bash

curl http://localhost:8000/v1/embeddings \
  -d '{
    "model": "BAAI/bge-large-en",
    "input": "Hello world"
  }'

OpenAI Responses API

除了 /v1/chat/completions，vLLM 还实现了 OpenAI 的 Responses API（/v1/responses，vllm/entrypoints/openai/responses/）。它在复用同一套 OnlineRenderer + ParserManager 管线的基础上，额外提供四项 chat completions 没有的能力：

有状态会话：请求带 store 与 previous_response_id；带上后者时，服务端从内存中取出上一轮的输出与输入消息，拼入下一轮 prompt（serving.py 的 _make_request）。注意 vLLM 实际默认是不存储——存储由环境变量 VLLM_ENABLE_RESPONSES_API_STORE 开启，未开启时请求里的 store=True 会被静默降级为 False。
后台模式：background=true 时立即返回 status="queued" 的响应，真正生成跑在 asyncio.Task 里，客户端用 GET /v1/responses/{id} 轮询、POST .../cancel 取消。
内置工具：配置了 --tool-server 时，请求里的 web_search_preview / code_interpreter / container 会映射到内置 browser / python / container 工具，外加任意 MCP 工具。
命名式 SSE 事件：流式输出形如 event: <type>\ndata: <json>，而非裸 data: 分块。

核心处理类是 OpenAIServingResponses，每轮会话状态封装在 ConversationContext（responses/context.py）抽象基类下，有 SimpleContext（无 MCP）、ParsableContext（走通用 parser）、HarmonyContext（GPT-OSS 专用）三个子类；状态全部存放在实例的内存 dict 里（response_store/msg_store/event_store/background_tasks），目前不会主动清理。流式事件按生命周期（response.created/in_progress/completed）、输出项/内容块、文本/推理、工具调用（function/MCP/web_search/code_interpreter）分类（streaming_events.py）。GPT-OSS（Harmony）分支由 responses/harmony.py 负责 Responses 对象与 Harmony Message（final/analysis/commentary 通道 + recipient）的双向转换，输入侧把消息直接渲染成 token id（绕过 HF chat template），输出侧按 recipient 路由成 web_search / function / MCP / reasoning。挂载由 entrypoints/generate/api_router.py 的 register_generate_api_routers 完成。

Pooling：嵌入 / 分类 / 打分服务

非生成式（pooling）模型不走解码循环：编码器跑一遍 prefill 取 hidden states，再由 pooler 按 task 归约为向量或标量。任务由 PoolingTask 区分（vllm/tasks.py）：embed/token_embed 出嵌入（序列级 vs token 级多向量），classify/token_classify 出分类 logits（后者为 NER），plugin 走自定义 IO processor。统一请求管线在 PoolingBaseServing.__call__（entrypoints/pooling/base/serving.py）：选 IO processor → 渲染 → engine_client.encode → 后处理 → 构造响应。entrypoints/pooling/factories.py 是调度中枢，按解析出的 pooling_task 实例化对应 serving 类（ServingEmbedding/ServingClassification/ServingScores/ServingPooling）挂到 app.state 并条件挂载路由。

端点	Serving 类	底层 task
`/v1/embeddings`、`/v2/embed`（Cohere）	`ServingEmbedding`	`embed`
`/classify`	`ServingClassification`	`classify`
`/score`、`/rerank`（+ `/v1`、`/v2` 别名）	`ServingScores`	由 score_type 决定
`/pooling`	`ServingPooling`	按 `task` 字段分发

打分（/score、/rerank）是叠加在 pooling 之上的高层语义：SCORE_TYPE_MAP 把 pooling task 映射成打分策略 —— embed→bi-encoder（双编码器，query/doc 分别编码再算余弦）、classify→cross-encoder（query+doc 拼接送模型出单 logit，需 num_labels==1）、token_embed→late-interaction（ColBERT 风格）。Late-interaction / ColBERT 与 mean 池化的区别在于：mean 把 [seq_len, dim] 压成 [dim] 单向量后算余弦；late-interaction 保留 query 与 doc 双方的 token 级嵌入，做 MaxSim（对每个 query token 取与所有 doc token 相似度的最大值再求和），表达力更强。核心算子 compute_maxsim_score_batched 在 vllm/v1/pool/late_interaction.py（bmm → amax(doc) → sum(query)）。性能关键路径是「flash」模式：score_type=="late-interaction" 时默认启用，分两阶段——先编码 query 并把 token 嵌入缓存在 worker 进程内，再编码 doc 直接在 GPU 上算 MaxSim 返回标量；worker 侧 LateInteractionRunner（vllm/v1/pool/late_interaction_runner.py）维护 query 缓存与引用计数，因缓存进程本地，用 crc32(query_key) % num_engines 把 query 与其 docs 钉到同一数据并行引擎。

v0.26.1rc0 后 pooling 侧的增量：PoolingBaseServing 尊重请求体里的 request_id（响应 id 变为 pooling-{client-request-id}，#55665）；chunked embedding 分块路径也遵守 max_embed_len（#55551，此前分块时完全不限长）；DispatchPooler.for_seq_cls() 不再给 token_classify 强制 AllPool()，--override-pooler-config '{"tok_pooling_type":"STEP"}' 可让 forced alignment 这类任务只保留 step_tag_id 行再过分类头（#55307）。多模态文档理解新增 Cohere Compass（#54774，model_executor/models/cohere_compass.py，2354 行）：Conv3d + MMEncoderAttention 的视觉文档检索（late-interaction）模型，配套自定义 image processor。注意区分：entrypoints/cohere/serving.py（#47189）是 Cohere Chat v2 生成 API（CohereServingChatV2，citation 收集与流式转换），不在 pooling 路径上。

支持的参数

参数	说明	默认值
`temperature`	采样温度	1.0
`top_p`	核采样概率	1.0
`top_k`	Top-k 采样	-1
`max_tokens`	最大生成 token 数	模型最大
`stop`	停止 token 列表	[]
`stream`	是否流式输出	false
`n`	生成候选数	1
`presence_penalty`	存在惩罚	0.0
`frequency_penalty`	频率惩罚	0.0
`logprobs`	返回 logprobs	false
`response_format`	结构化输出格式	null
`guided_json`	JSON Schema 约束	null

Anthropic Messages API

除 OpenAI 协议外，vLLM 内置 Anthropic Messages API（vllm/entrypoints/anthropic/，挂载 /v1/messages）。它支持 effort（low/medium/high/xhigh/max）、thinking / redacted_thinking 内容块、cache usage 上报、count_tokens 端点，并复用统一的 strict tool calling 与 OnlineRenderer。适配层把 Anthropic 请求转成内部 ChatCompletionRequest 处理。

解析与渲染管线

v0.23 把解析（parsing）与渲染（rendering）拆为两个独立关注点（详见 topics/architecture/）：

解析（vllm/parser/）：ParserManager + 流式解析器引擎（Streaming Parser Engine）从生成 token 流中增量提取 tool call 与 reasoning，取代了过去分散在每个 entrypoint 的解析逻辑。各模型 parser（GLM4.7/5.x、Qwen3、MinimaxM2、Nemotron V3、Gemma4 等）以 adapter 形式注册；seed_oss（Harmony）作为 Qwen3 子类复用其流式解析基建。
渲染（vllm/renderers/）：OnlineRenderer 负责把 chat/completion 请求渲染为引擎输入（prompt token + 多模态），OnlineDerenderer 负责反向解析引擎输出为协议消息。模型特定渲染由 registry.py 注册（deepseek_v32、grok2、mistral、hf 等）。

Rust 前端（rust/src/parser/src/unified/）把原先分离的 reasoning parser 与 tool parser 合并为统一的 UnifiedParser 接口，单个 parse_into() 同时增量产出 Text / Reasoning / ToolCall 三类 UnifiedParserEvent，并保留事件交错顺序（ToolParserOutput 相应改为 Vec<ToolParserEvent>）。两种接入方式：原生实现（如 Gemma4UnifiedParser，因 reasoning 与 tool 标记紧密交错）；或用 CombinedParser 把现有 reasoning + tool parser 组合适配进统一框架（Qwen3 等走此路）。

渲染（输入侧）方面，Rust 前端按 model_type 自动选 RendererSelection：HF（Jinja 模板）、DeepSeek-V3.2、DeepSeek-V4，以及新增的 Harmony（GPT-OSS）。HarmonyChatRenderer（rust/src/chat/src/renderer/harmony/）用 openai-harmony crate 的编码把对话直接渲染成 token id（Prompt::TokenIds），完全绕过 HF tokenizer；它处理 Harmony 的通道协议（final/analysis/commentary）、tool-call 接收方（functions.{name} + <|constrain|>json）、preamble（日期、reasoning effort）与过期 analysis 清理，与既有的 Harmony 输出解析器共享同一 encoding 单例。Rust tool 参数解析器也修了：对 type: "string" 的参数保留字面量 "null" 字符串而非强转为 JSON null（枚举含 null 成员时仍正确推断可空类型）。

Chat Completion、Responses、Anthropic 三条 API 链路均经此管线。

InputPreprocessor 已删除（#53064）：v0 时代的 vllm/inputs/preprocess.py（把 raw prompt 字符串/tokenize 成 EngineInput 的独立预处理层）被彻底移除，prompt 预处理统一收敛到 Renderer 路径 —— InputProcessor 若仍收到 raw prompt（打 deprecation warning），改调 parse_model_prompt()（承接模块 vllm/renderers/inputs/preprocess.py）+ renderer.render_cmpl() 就地渲染；贯穿各处的 tokenization_kwargs 透传也一并删除（并入 Renderer 的 tok params）。前端正规路径变为：HTTP 层 → Renderer（tokenize + mm processing）→ InputProcessor（构造 EngineCoreRequest）→ EngineCore，且 raw-prompt 预处理可卸载到 renderer 线程池避免阻塞事件循环（#49608）。

结构化 Tool Calling（Strict 模式）

v0.23 为 tool calling 引入 strict 模式：在 tools[].function.strict=true 且 VLLM_ENFORCE_STRICT_TOOL_CALLING=true（默认）时，vLLM 通过 xgrammar structural-tag 在 token 生成阶段直接约束参数格式，而非事后从文本提取。各 tool parser 通过类属性 structural_tag_model（如 "hermes"、"deepseek_v3_2"、"glm_4_7"）声明其内置 structural-tag 模型；不支持 structural-tag 的 parser 则将 required / 具名 function 退化为 auto 行为。Rust 前端也已集成 xgrammar-structural-tag。

分离式渲染（/render、/derender）

为支持 PD 分离（Prefill/Decode disaggregation），新增 /render（在线渲染：prompt→token）与 /derender（反向：token→message+tool call）端点。核心逻辑抽到 vllm/renderers/，entrypoint 仅做 HTTP 适配，使渲染可在独立进程/节点完成。

/render 现支持两个面向下游消费的标志位（entrypoints/serve/render/serving.py）：

return_assistant_tokens_mask：借助 chat template 里的 {% generation %} Jinja 扩展，为每个 token 标注是否落在 assistant 回合内（0/1 序列）。在分离式 prefill 架构下，可把渲染后的 token 送到 generate 服务取 logprobs，再用此 mask 计算仅覆盖 assistant token 的交叉熵损失 —— 即 SFT / RLHF / 推测解码草稿模型训练数据的生成管线。
return_token_offsets：返回每个 token 相对原文的字符级 (start, end) 偏移（依赖 fast tokenizer 的 offset_mapping），便于把按 token 索引的输出映射回原文位置（高亮、归因、RAG 溯源）。

路由组织

v0.23 把 HTTP 路由分为两组：register_vllm_serve_api_routers（生产：LoRA、profile、tokenize）始终挂载；register_vllm_dev_api_routers（开发：cache、rlhf、rpc、server_info、sleep）仅在 VLLM_SERVER_DEV_MODE=1 时挂载并打印安全警告。generate / disagg / elastic_ep / render 按 supported_tasks 条件挂载。

性能剖析（Profiler）

这是基于 kineto / PyTorch profiler 的逐层计时剖析，勿与用于 KV cache 容量估算的 profile_run() 混淆。由 ProfilerConfig（config/profiler.py）控制：profiler 取 torch（TorchProfilerWrapper，输出 tensorboard trace）或 cuda（CudaProfilerWrapper + NVTX range），并用 delay_iterations/max_iterations/warmup/active/wait 调度采样窗口。触发经 POST /start_profile、POST /stop_profile（entrypoints/serve/profile/api_router.py）：链路 endpoint → executor collective_rpc("profile") → GPUWorker.profile 首次创建 wrapper；每个 worker step 经 annotate_profile 调用 profiler.step() 并以 record_function 标注 prefill/decode 迭代，stop 时按 self_cuda_time_total / self_cpu_time_total 输出排序表。这两个路由仅当启动时配置了 profiler 才挂载，并打印「仅供本地开发」警告。更细的逐层离线分析由 profiler/layerwise_profile.py 配合 tools/profiler/ 脚本完成；另有 --enable-layerwise-nvtx-tracing（observability 配置）给每个 module 注入 NVTX 钩子（不支持 CUDA graph）。离线 LLM 类亦可经 start_profile()/stop_profile() 触发。

旧的单体 vllm/entrypoints/api_server.py 已移到 examples/applications/api_server/server.py —— 模块化 serve 架构才是生产入口，Python 与 Rust 前端两条路径都继续维护，那个简单脚本只是示例。v0.26.1rc0 后 entrypoints 又做了一轮「启动器出仓」重组：API server 的进程编排部分拆到 vllm/entrypoints/launchers/api_server/（#52131，openai/api_server.py 仅剩弃用 shim），run_batch.py（#53500）、cli_args.py 与 dp_supervisor.py（#53659）、engine/protocol.py（#54492，即 EngineClient 协议所在的 vllm/engine/protocol.py）相继移出 openai/ 目录 —— OpenAI 子目录回归纯协议实现，跨前端的启动/协议基建上提。

Scale-out 端点整合（PR #44512）：分离式服务的三个端点 —— render（chat/completion → token 序列）、token_in_token_out（原 disagg，decode 侧 generate）、derender（generate 输出 → 协议消息）—— 从分散的 entrypoints/serve/{render,disagg}/ 统一收到 vllm/entrypoints/scale_out/ 包，由集中的 scale_out/factories.py（init_scale_out_state()、register_scale_out_api_routers()）初始化，并把 derender 提升为正式的 ServingDerender 类（scale_out/derender/serving.py）。OpenAI api_server 与 generate api_router 不再各自构造这些 serving 对象，统一委托 factories。"scale-out" 即分离式 prefill/decode 部署，render（分词）、generate（解码）、derender（反分词/解析）可跑在独立进程/节点。

离线 LLM 类

python

from vllm import LLM, SamplingParams

llm = LLM(model="meta-llama/Llama-3-8B")
params = SamplingParams(temperature=0.7, max_tokens=256)

# 单个推理
output = llm.generate("Hello, world!", params)

# 批量推理
outputs = llm.generate(["prompt1", "prompt2", "prompt3"], params)

for output in outputs:
    print(output.outputs[0].text)

Mixin 架构

LLM 类从单一庞大类重构为 Mixin 组合架构：

LLM(BeamSearchOfflineMixin, PoolingOfflineMixin, OfflineInferenceMixin)

OfflineInferenceMixin (entrypoints/offline_utils.py): 核心推理逻辑 — 预处理、参数广播、引擎运行
BeamSearchOfflineMixin (entrypoints/generate/beam_search/offline.py): 离线 beam search
PoolingOfflineMixin: 池化操作（embeddings 等）

推测解码快捷参数

python

# 之前：需要传递完整的 JSON 配置
llm = LLM(model="...", speculative_config='{"method":"ngram","num_speculative_tokens":5}')

# 现在：直接通过 CLI 参数设置
llm = LLM(model="...", spec_method="ngram", spec_tokens=5)

LLM 类参数

参数	说明
`model`	模型名称或路径
`tensor_parallel_size`	张量并行数
`gpu_memory_utilization`	GPU 显存利用率 (0-1)
`max_model_len`	最大序列长度
`quantization`	量化方法
`dtype`	数据类型
`trust_remote_code`	是否信任远程代码
`spec_method`	推测解码方法
`spec_model`	推测解码草稿模型
`spec_tokens`	推测解码候选 token 数

中间件

CORS

python

app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],
    allow_methods=["*"],
    allow_headers=["*"],
)

限流

vLLM 不再内置限流中间件（早期的 --rate-limit-interval / --rate-limit-token 与 RateLimitMiddleware 已移除）。生产部署应在前置的反向代理 / API 网关（如 nginx、Envoy、Cloudflare）层做限流与配额。进程内的请求级资源防护见下方「资源耗尽防护」。

健康检查

GET /health    → 200 OK (引擎就绪)
GET /ready     → 200 OK (服务就绪)
GET /v1/models → 返回可用模型列表

资源耗尽防护（DoS 加固）

v0.26 做了一轮系统性的资源耗尽加固（一组 fix(security) 提交），统一模式是「在昂贵的处理之前先校验/设上限，必要时暴露可调环境变量」。这些是内部防护（非请求级配置），多数带环境变量逃生口：

防护	环境变量（默认）	机制
图像/视频解压炸弹	`VLLM_MAX_IMAGE_PIXELS`（~179M px，对齐 PIL 2× 阈值，0 关闭）	`ImageMediaIO.load_bytes()` 与各视频后端的 `_check_frame_pixel_limit()` 在解码前按 `w*h` 拒绝超大帧（#47010）
正则 ReDoS	`VLLM_REGEX_COMPILATION_TIMEOUT_S`（5s，≤0 关闭）	`compile_regex_with_timeout()`（`v1/structured_output/utils.py`）用线程池给 lm-format-enforcer 的 `RegexParser` 编译限时，避免嵌套量词致 DFA 指数爆炸挂死 worker（#47595）
超长 prompt 分词	—（内部）	显式 `truncation_side` 时，`TokenizeParams._text_len_check` 按 `max_input_chars = max_input_tokens × max_chars_per_token` 在分词前按字符预裁剪（#47007）
`/v1/completions` prompt 列表扇出	`VLLM_MAX_COMPLETION_PROMPTS`（1024）	`CompletionRequest` 的 `validate_prompt_list_length` 拒绝过大的 `prompt`/`prompt_embeds` 列表，防一次调用扇出成上千 engine 请求（#47845）
请求级 GPU 视频后端	—（内部）	`VideoLoaderRegistry.register()` 的 `requires_gpu` 标志 + `merge_kwargs()` 丢弃与启动默认冲突的请求级 GPU video backend 选择（#47259）
derender 资源上限	—（内部）	`ServingDerender._validate_derender_bounds()` 在反解析前按 `VLLM_MAX_N_SEQUENCES` / `max_model_len` / `top_logprobs≤20` 拦截过大的 caller-supplied `generate_responses`，并拒负 token_id（#47260）

准入控制（Admission Control）

队列积压防护（#49445）：SchedulerConfig 新增 --max-num-queued-reqs（未完成请求总数上限，waiting+running）与 --max-num-queued-tokens（仍处 prefill 阶段请求的 prompt token 总量上限）。关键设计是准入检查在 API server 进程执行而非调度器：AsyncLLM.check_admission() 在把请求注册进 OutputProcessor 之后、发给 EngineCore 之前判定，计数直接取前端进程内的 get_num_unfinished_requests()（len(request_states)）与 get_num_queued_tokens()（各 prefill 请求 prompt_len 之和）——不需要引擎往返。超限抛 QueueOverflowError / MaxQueuedTokensError，二者继承自 GracefulHTTPError（携带 http_status），映射为 HTTP 503 让 LB/客户端换实例重试；EngineClient 协议相应加了默认空实现的 check_admission() 钩子。

两个细节：计数偏保守——chunked prefill 进度与 prefix cache 命中在前传完成前不会同步到 API server，部分预填请求仍按完整 prompt_len 计入（偏向提前拒绝，安全方向）；n>1 的请求按 params.n 占多个槽位。与 max_num_seqs 的关系（#55124 澄清）：max_num_seqs 是每 DP rank 的调度器并发上限，这两个新限制是整个 server 级（跨所有 DP rank 在 API server 统计），容量建议 data_parallel_size × max_num_seqs + 期望队列深度；max_num_queued_tokens 则可视为 TTFT QoS 阀门（目标TTFT × prefill吞吐）。tests/v1/engine/test_admission_control.py 有 384 行专项测试。

错误处理架构（VLLMValidationError）

输入校验错误从裸 ValueError 迁移到标准化异常层级（#49665 起的迁移系列）：vllm/exceptions.py 顶层 VLLMError 二分为 VLLMClientError（4xx）与 VLLMServerError（5xx），entrypoint 据此决定 HTTP 状态码。VLLMValidationError(VLLMClientError) 构造签名 (message, *, parameter=None, value=None)，__str__ 自动附加出错的参数名与取值（Pydantic 风格错误体）。本周期把所有校验点迁移完毕：sampling/pooling params、Responses API（含 harmony）、chat_utils（mistral/harmony/params）、pooling/scoring、Cohere、structured output validators、batch URL 等。配套防护（#54684）：exception_handling/handlers/validation.py 对校验错误响应体限长，防错误消息回显 payload 造成放大。

性能调优

关键配置参数

参数	影响	建议值
`--max-num-seqs`	最大并发请求数	128-512
`--max-num-batched-tokens`	每步最大 token 数	8192-32768
`--gpu-memory-utilization`	GPU 显存利用率	0.85-0.95
`--block-size`	KV 缓存块大小	16
`--enable-prefix-caching`	启用前缀缓存	建议开启
`--enable-chunked-prefill`	启用分块 prefill	建议开启

性能指标

指标	含义	优化方向
TTFT	首 token 延迟	降低 prefill 时间
TPOT	每 token 延迟	减少 decode 开销
Throughput	吞吐量 (tokens/s)	增加批处理量
GPU Utilization	GPU 利用率	平衡 prefill/decode

部署方式

Docker

bash

docker run --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3-8B

多 GPU

bash

vllm serve meta-llama/Llama-3-70B \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.9

Rust Frontend（高性能）

bash

# 设置 Rust 前端路径
export VLLM_RUST_FRONTEND_PATH=/path/to/vllm-rs
vllm serve meta-llama/Llama-3-8B

Rust 前端位于 rust/ workspace（含 chat、tool-parser、reasoning-parser、managed-engine 等 crate），由 RustFrontendProcessManager 以子进程方式拉起 vllm-rs frontend 子命令，通过 --listen-fd 继承监听 socket、--args-json 传递引擎配置、ZMQ 连接 EngineCore。v0.23 已对齐 Python 前端能力 —— API key 认证、CORS、/tokenize、/detokenize、/abort_requests、/v1/models 元数据，并集成 xgrammar-structural-tag 支持 strict tool calling。v0.26 起新增条件挂载 /start_profile、/stop_profile（rust/src/server/src/routes/profile.rs），仅当 Config.profiler 存在时注册并告警「仅供本地开发」；同时新增 gRPC server（含模型发现、abort、engine 健康上报）与多模态音视频接入，持续向 Python 前端能力看齐。

v0.26.1rc0 后 Rust 前端进一步长成完整的 RL rollout server 控制面：

gRPC RL lifecycle（#51316，rust/proto/control.proto）：control service 新增 12 个 RPC —— PauseGeneration/ResumeGeneration/IsPaused、Sleep/WakeUp/IsSleeping、InitWeightTransferEngine/StartWeightUpdate/StartDraftWeightUpdate/UpdateWeights/FinishWeightUpdate/UpdateWeightVersion/GetWeightVersion。握手响应 ServerInfo 携带 RlCapabilities（weight_transfer/sleep_mode/draft weight updates 等），能力字段从 EngineCoreReadyResponse 聚合且所有 DP rank 一致才为 true；rl_lock: Mutex<()> 串行化 RL 操作，张量数据走 NCCL/IPC，gRPC 只传 backend JSON。
LoRA 全生命周期（#52031/#52840/#53756/#54837）：握手与 ServerInfo/ModelInfo 广告 supports_lora、max_loras（Python 侧 EngineCoreProc 从 lora_config 填充）；gRPC LoRA lifecycle；--lora-modules 静态加载与 HTTP /v1/load_lora_adapter、/v1/unload_lora_adapter。
KV-connector 指标（#52755）：Mooncake/NIXL connector 统计经 EngineCore stats 帧（Python 侧 kv_connector/v1/metrics.py）转成 Rust Prometheus 指标。
其它补齐：standalone renderer（#50289）、gRPC 多模态图像推理（#50368）与音视频（#53760）、显式 DP rank 路由（#51178）、token 级归因解码（#52910/#54884）、SSE 热路径优化（#51321）、HY3 统一解析器 + 本地 XGrammar structural-tag builder（#53054）、reasoning tokens usage（#54883）。

流式粒度现可作为请求级采样参数：ChatCompletionRequest / CompletionRequest 新增 stream_interval 字段（#49754），透传进 SamplingParams 并由 v1/engine/output_processor.py 生效，客户端可逐请求调节流式分块频率。

确定性解码回放（#46701）：SamplingParams 新增 trace_decode_token_ids，让 sampler 在每个 decode 步用预定 token 序列覆写采样结果，而 logprobs/ranks 仍从未修改的 logit 分布真实计算——用于跨配置（量化/TP/attention backend）对比 logprob 分布、或以训练序列回放检测 train-vs-inference 数值漂移。实现全在 GPU 侧（v1/worker/gpu/sample/trace_replay.py 的 TraceReplayState + Triton kernel _trace_replay_kernel，按 total_len - prompt_len 推导回放步，无 CPU 同步）；因需按 (max_num_reqs, max_model_len) 预留 buffer，须 --enable-trace-replay 显式开启且仅支持 MRV2。与 prompt_logprobs、spec decode、structured outputs 等互斥。

structured output × min_tokens 交互修复（#54218）：grammar 到达终止态时会把其余 token 全 mask 成 -inf，与 MinTokensLogitsProcessor 的 stop-token 屏蔽叠加会导致整行 -inf、采样退化。修复后 _mask_stop_token_logits 先保存 stop-token logits 副本，按行检测「整行全 -inf」（grammar 强制终止），对这种行恢复有限的 stop-token logits——grammar 允许的终止 token 在 min_tokens 之下也能被采出。

DP Supervisor（多端口数据并行）

bash

vllm serve meta-llama/Llama-3-8B \
  --data-parallel-size 4 \
  --data-parallel-multi-port-external-lb

DP Supervisor 是一个节点本地管理进程：

为每个数据并行 rank 生成独立的 vLLM API Server（使用不同端口）
提供聚合的健康检查端点（/health、/health/liveness、/health/readiness）
通过 device_ids 参数为各子进程分配设备
支持 hybrid / external LB 的 Python supervised bootstrap（Rust 前端侧也接入）
支持可配置的探测间隔和失败阈值

API服务与部署 — 概念

服务架构

前端模式

OpenAI 兼容 API

Chat Completions

Text Completions

Embeddings

OpenAI Responses API

Pooling：嵌入 / 分类 / 打分服务

支持的参数

Anthropic Messages API

解析与渲染管线

结构化 Tool Calling（Strict 模式）

分离式渲染（/render、/derender）

路由组织

性能剖析（Profiler）

离线 LLM 类

Mixin 架构

推测解码快捷参数

LLM 类参数

中间件

CORS

限流

健康检查

资源耗尽防护（DoS 加固）

准入控制（Admission Control）

错误处理架构（VLLMValidationError）

性能调优

关键配置参数

性能指标

部署方式

Docker

多 GPU

Rust Frontend（高性能）

DP Supervisor（多端口数据并行）

相关概念

反向链接

出链

API服务与部署 — 概念 ​

服务架构 ​

前端模式 ​

OpenAI 兼容 API ​

Chat Completions ​

Text Completions ​

Embeddings ​

OpenAI Responses API ​

Pooling：嵌入 / 分类 / 打分服务 ​

支持的参数 ​

Anthropic Messages API ​

解析与渲染管线 ​

结构化 Tool Calling（Strict 模式） ​

分离式渲染（/render、/derender） ​

路由组织 ​

性能剖析（Profiler） ​

离线 LLM 类 ​

Mixin 架构 ​

推测解码快捷参数 ​

LLM 类参数 ​

中间件 ​

CORS ​

限流 ​

健康检查 ​

资源耗尽防护（DoS 加固） ​

准入控制（Admission Control） ​

错误处理架构（VLLMValidationError） ​

性能调优 ​

关键配置参数 ​

性能指标 ​

部署方式 ​

Docker ​

多 GPU ​

Rust Frontend（高性能） ​

DP Supervisor（多端口数据并行） ​

相关概念 ​

反向链接

出链

API服务与部署 — 概念

服务架构

前端模式

OpenAI 兼容 API

Chat Completions

Text Completions

Embeddings

OpenAI Responses API

Pooling：嵌入 / 分类 / 打分服务

支持的参数

Anthropic Messages API

解析与渲染管线

结构化 Tool Calling（Strict 模式）

分离式渲染（/render、/derender）

路由组织

性能剖析（Profiler）

离线 LLM 类

Mixin 架构

推测解码快捷参数

LLM 类参数

中间件

CORS

限流

健康检查

资源耗尽防护（DoS 加固）

准入控制（Admission Control）

错误处理架构（VLLMValidationError）

性能调优

关键配置参数

性能指标

部署方式

Docker

多 GPU

Rust Frontend（高性能）

DP Supervisor（多端口数据并行）

相关概念