@RedHat_AI: 145 tokens每秒。加入推测解码。424 tokens每秒。同一模型。同一H100。输出质量零变化…
摘要
Red Hat 演示了使用推测解码可以将 LLM 推理速度从 145 tokens/秒提升至 424 tokens/秒,且使用相同 H100 硬件,质量无损失,凸显了面向生产服务的一项重要优化。
查看缓存全文
缓存时间: 2026/06/15 17:08
每秒145个token。加入推测解码。每秒424个token。同一个模型。同一块H100。输出质量零变化。
如果你在生产环境中部署LLM却没有使用推测解码,以下就是你正在错过的……
A:
两个模型协同工作:
一个小型草稿模型(0.5-2B参数)快速冲刺,提出3-5个token。大型验证器通过单个并行前向传播一次性检查所有token。
当草稿正确时(对于可预测的任务,概率为50-80%),你可以以一次前向传播的成本获得多个token。当草稿错误时,你损失的只是微秒。
适用场景:代码生成、JSON/SQL、结构化输出、基于模板的生成。任何具有可预测模式的任务。
不适用场景:大批次大小(32+),此时GPU已经饱和。创造性写作,因为草稿模型无法准确预测token。
接受率是你的信号。60-80%是最佳区间。
在@vllm_project中启用它只需要一个参数:
vllm serve RedHatAI/gemma-4-31B-it-FP8-Dynamic
–speculative-model RedHatAI/gemma-4-31B-it-speculator.eagle3
–num-speculative-tokens 5
Red Hat AI 已在 HuggingFace 上准备好了 Gemma、Qwen、Llama 和 Mistral 的预训练推测器:
成本计算:
标准:100 tokens/秒,5美元/小时 = 每1000个token 0.05美元
使用推测解码:250 tokens/秒,5美元/小时 = 每1000个token 0.02美元
成本降低60%。相同硬件。对于一个每天处理1000万token的部署,每年可节省109,500美元。
由@_soyr_撰写的完整指南:工作原理、使用时机、如何调整接受率,以及获取预训练推测器模型的途径:
Gemma 4 Diffusion 上周登陆 vLLM。Day 0 支持。
vLLM 原生支持的首个扩散LLM。它不是一次预测一个token,而是一次预测256个token,并迭代并行去噪。
结果:在单个H100上,批次大小为1时,每秒超过1000个token。
基于 Model Runner V2 构建。@googlegemma
相似文章
2倍 tok/s(在1块MI50上从19.4 tok/s提升到38.1 tok/s)尝试类似推测解码的假设……但不是用额外的侧模型,而是利用我可以同时运行多个计算,就好像内存里加载了两份Qwen3.6-27B一样——小量化不占用所有可用算力。
打包双推理(PTI)是一种通过单批解码中运行多个token序列来实现约2倍LLM吞吐量的技术,它利用了llama.cpp中的权重共享,无需草稿模型或额外VRAM。
@HotAisle: 太棒了。我想知道他们用的是谁的 MI300x... ;-)
Kog 宣布在标准数据中心 GPU 上实现每请求每秒 3000+ 输出令牌的实时大语言模型推理,将此前仅限于定制芯片的高速推理引入生产硬件。
@0xSero:终于搞定 GLM-5.1-505B-REAP-NVFP4,解码 45 tokens/s,预填充 1350 tokens/s,剪枝 32%,这是我跑通过最费劲的一次…
开发者 @0xSero 在优化版 GLM-5.1-505B 上通过 NVFP4 量化与 32% 剪枝实现高吞吐推理,解码速度 45 tokens/s,预填充速度 1350 tokens/s。
@_avichawla: Anthropic. Google. Meta. 每个人都在用来自1990年代的一个想法将LLM推理速度提升2-3倍。在1990年代,CPU设计者…
推测解码受1990年代CPU分支预测启发,现被Anthropic、Google和Meta用于将LLM推理速度提升2-3倍。它使用一个小模型来猜测未来的token,并用一个大模型并行验证它们,从而避免了解码期间GPU空闲时间。
为AMD MI300X构建LLM推理的单内核 - 每个请求最高3300输出tokens/秒 [P]
一种针对AMD MI300X GPU上LLM解码的单内核方法,每个请求可达3300输出tokens/秒,无需推测解码或量化,利用映射到芯片拓扑结构的内存访问模式。