标签: #실측

← 全部文章

• 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

• 结构化输出：为每个 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