标签: #vLLM

← 全部文章

• 并行化、多模态与池化：单张 GPU 能测与不能测的内容

  本文整理了 vLLM 的其余几大功能集。将模型拆分到多个 GPU 上的张量、流水线、数据和专家并行因为只有一张 GPU 而未作实测，并已通过官方文档与论文整理了各自的拆分对象与适用场景。图像、视频和音频输入因为需要重新下载模型而未作实测，取而代之的是，我们记录了在实际运维中应优先处理的事项，例如防止 SSRF 的 --allowed-media-domains 以及分配 4GiB CPU 内存的处理缓存。嵌入和重排（Rerank）使用与

  2026-10-27 · 16 分钟阅读 #vLLM#텐서 병렬#파이프라인 병렬#데이터 병렬#전문가 병렬

• 运维功能：休眠模式、启动时间、/metrics 以及 --api-key 无法覆盖的路径

  在不关闭服务器的情况下释放 GPU 的休眠模式、缩短重新加载时间的编译缓存、用于查看状态的 /metrics，以及亲自测试的身份验证。休眠第 2 阶段在 42ms 内将 GPU 内存从 6,168MiB 释放至 606MiB，重新加载权重唤醒耗时 0.39 秒（相同配置重启需 32 秒）。第 1 阶段在将权重迁移至 CPU 的过程中导致限额分别为 4GiB 和 4.5GiB 的容器因内存不足（OOM）而被终止，使用 0.32.0 版本重

  2026-10-27 · 17 分钟阅读 #vLLM#sleep mode#잠자기 모드#기동 시간#torch.compile

• KV 卸载与分离式服务：从 CPU 重新加载被挤出的前缀

  如果 GPU 的前缀缓存空间不足，就会从最早的块开始清除。vLLM 默认的 CPU 卸载（--kv-offloading-size）会将用完的 KV 块复制到固定内存（pinned memory）中，当相同的前缀再次到来时，再将其恢复到 GPU 中。我们特意将 GPU KV 缩减至 2,336 个 token，挤出 1,600 个 token 的前缀后再次发送，结果显示：如果没有卸载，重新计算需要 77.3ms；如果有卸载，从 CPU

  2026-10-27 · 12 分钟阅读 #vLLM#KV 캐시#KV 오프로딩#OffloadingConnector#분리 서빙

• 量化：将权重缩减至 8 位为何能加快解码速度及其代价

  解码的一个步骤主要耗费在从内存中读取整个权重的时间上，因此减小权重可以缩短步骤耗时。vLLM 支持在线量化，即在加载 bf16 检查点的同时原地转换为 FP8。在 8GB 级 GPU 上用 0.6B 模型重新测试发现，权重内存从 1.12GiB 降至 0.71GiB，单用户吞吐量从 174.2 提升至 236.3 tok/s（1.36 倍），并发 16 时从 1,683 提升至 2,086 tok/s（1.24 倍），并发 64 时为

  2026-10-27 · 13 分钟阅读 #vLLM#양자화#FP8#AWQ#GPTQ

• 工具调用：解析器将文本转换为函数调用，strict 约束参数

  模型调用工具实际上是模型在编写特定格式的文本。vLLM 通过聊天模板将工具列表放入提示词中，解析器则将模型编写的文本转换为 OpenAI 格式的 toolcalls。如果 toolchoice 是 required 或特定的函数名，结构化输出就会强制规定调用的外观。然而，在 8GB 级 GPU 上用 0.6B 模型重新测试时，在未开启 strict 的情况下，5 次 required 调用中没有一次的参数遵守了架构（3 次空的 {}，1

  2026-10-27 · 15 分钟阅读 #vLLM#도구 호출#tool calling#function calling#구조화 출력

• 结构化输出：为每个 Token 屏蔽「非法字符」的代价

  结构化输出会在模型选择下一个 Token 之前，将语法上不可能出现的 Token 的概率置零。因此，对话能力几乎为零的 0.6B 模型在指定 JSON Schema 的情况下，48 次中有 46 次输出了正确的 JSON，而在未指定时则为 0 次。出错的两次均是因为触及了 maxtokens 而被截断。代价体现在两个方面：新 Schema 的首次请求因为生成语法在 xgrammar 中耗时 446ms、在 guidance 中耗时 97

  2026-10-27 · 17 分钟阅读 #vLLM#구조화 출력#structured outputs#JSON 스키마#xgrammar

• 推测解码：猜中赚四倍，猜错要吃亏

  推测解码是一种低成本地提前预测几个下一个 Token 的方法，由大模型一步到位地验证这些草案，并将正确的部分全部接受。在贪婪解码中，输出通常保持不变。在使用 8GB 级 GPU 和 0.6B 模型重新测试最轻量的 n-gram 方法时，在原样复制文本的任务中，单独使用时的每秒 176.4 个 Token 提升到了 704.1 个 Token（4.0 倍，4 个建议）和 1,117 个 Token（6.3 倍，8 个建议）。接受率在 96

  2026-10-27 · 17 分钟阅读 #vLLM#추측 디코딩#speculative decoding#n-gram#EAGLE

• 对连续批处理、chunked prefill、前缀缓存进行重复测量

  我们使用 0.6B 模型重新测量了 vLLM 的三大基本功能。这一次，每个条件重复了三到四次并取中位数，同时附带了完全关闭这些功能的基线。当强制一次只处理一个请求（--max-num-seqs 1）时，16 个并发请求的吞吐量停留在 174.6 tok/s，而默认设置为 1,683 tok/s，是前者的 9.6 倍。当插入 3,700 个 token 的输入时，解码暂停的最大时间在 512 token 的 chunk 大小下为 35.6

  2026-10-27 · 15 分钟阅读 #vLLM#연속 배칭#chunked prefill#접두사 캐시#cache_salt

• vLLM 功能地图：有哪些功能、什么时候划算、每个版本改了什么

  基于 vLLM 0.32.0 (2026-10-18) 官方文档与发布说明，我们将十六项核心功能汇总成一张表，梳理了每项功能节省的开销、开启所需的参数、划算与不划算的条件。在这其中，我们使用一张 8GB 级别的笔记本 GPU 和一个 0.6B 的模型，对其中的十二项（多模态与池化仅测了池化）进行了实际测量。连续批处理在并发为 16 时将吞吐量提升了 9.6 倍，前缀缓存使 3,200 个 Token 公共部分的首个 Token 速度提升

  2026-10-27 · 15 分钟阅读 #vLLM#LLM 서빙#기능 지도#PagedAttention#추측 디코딩