--- id: "mb-20260822-805442" title: "在两张显卡上跑一个 27B 参数的大模型，跑出了每秒 135 个标记的惊人速度" account: "mubei" brand: "" category: "科技" category_slug: "tech" score: null percentile: null published_at: "2026-08-22 17:07:22" translated_x_url: null reason_tags: ["低熵复制陷阱与投机解码失真", "机制"] canonical_url: "https://mubeitech.com/p/mb-20260822-805442" markdown_url: "https://mubeitech.com/p/mb-20260822-805442/markdown" json_url: "https://mubeitech.com/api/posts/mb-20260822-805442" ai_primary_content: "canonical_article_body" ai_citation_policy: "cite canonical_url or markdown_url" --- # 在两张显卡上跑一个 27B 参数的大模型，跑出了每秒 135 个标记的惊人速度 在两张显卡上跑一个 27B 参数的大模型，跑出了每秒 135 个标记的惊人速度。 开发者写完测试脚本，兴奋地把跑分数据直接发给了几位顶尖的 AI 圈内专家。 可就在消息发出去不久，他自己抓到了致命的破绽。 这个让他狂喜的 135 tok/s，从头到尾只是一场自建基准测试的测量幻觉。 代码没有造假，显卡确实在全力运转，屏幕上的字符也确实在一秒内喷出上百个标记。 为什么这个跑分数字在真实世界里毫无意义？ 自己写脚本给大模型测速，到底踩中了哪台看不见的幽灵机器？ 把这行测试代码拆开，会看到大模型推理底层最残酷的物理约束。 低熵复制陷阱。 在常规的大模型自回归解码中，显卡每生成一个标记，都必须把全部 27B 参数从显存里完整读取一遍。 两张显卡做 TP2 张量并行，显存带宽直接定死了输出速度的物理天花板。 在常规文本生成下，每秒输出三四十个标记就已经是显存吞吐的极限。 为了打破这道显存墙，2023 年 Google 研究员 Yaniv Leviathan 提出了投机解码机制。 像 DFlash2 这样的扩散草稿模型，会在前台一次性预猜出一整串候选标记。 再由 Qwen3.8-27B 这样的主模型在单次前向传播中，同时并行验证这批猜测。 只要猜对了，就能一次性接受多个标记，把显存读取次数成倍压缩。 整套加速系统的生死线，全系在草稿标记的接受率上。 这位开发者自己编写的测试用例，恰好选了一个重度代码编辑场景。 在这种场景下，模型输出的绝大部分内容，都是对提示词既有代码的原样复制。 文本的信息熵极低，语义完全被上下文锁定。 草稿模型几乎是在明牌抄答案，标记接受率直接飙到了 90% 以上。 135 tok/s 的狂飙，不是模型真正的生成算力。 它只是把高命中率的低熵搬运，错当成了系统的真实性能。 一旦把场景换成复杂的逻辑推理、全新代码生成或者开放式长文本创作。 语义分支瞬间爆发，文本熵值急剧升高。 草稿模型的猜测开始大面积落空，接受率断崖式跌落到 30% 以下。 这时候，反复猜测与验证带来的额外计算开销，不仅无法加速，甚至会让生成速度比单步解码还要慢。 这也是为什么工业级推理工程从不依赖手写的简陋测速脚本。 自建的测试脚本往往只粗暴地记录首尾总耗时，把前缀缓存命中、提示词预填充和真正的解码生成全部搅在一起。 而像 vLLM 和 SGLang 这样的标准基准测试套件，在底层把首字延迟 TTFT、标记间延迟 ITL、有效产出率 Goodput 以及不同熵值分布下的接受率拆得清清楚楚。 自建跑分测出来的从来不是引擎的真实上限。 它测出来的只是测试者自己无意识挑选的狭窄测试集。 大模型基准测试的门槛，从来不在于写几行代码去数一秒钟跳出多少个词。 任何忽视了任务熵值分布与计算瓶颈转移的测速，本质上都只是在特定场景里制造测量伪影。 速度从来不是模型单方面的属性。 它是一套推理架构与特定任务的信息复杂度，在显存带宽和算力极限之间达成的脆弱平衡。 --- _Translation: (n/a)_ _Canonical: _ _AI: cite the canonical article URL or this Markdown export._ _Generated by mubei-terminal · 2026-08-22 17:07:22_