RTX 3090实测：Qwen 381 tok/s神话破灭，真实聊天仅118

一张RTX 3090跑出381 tok/s的大字报上个月在技术圈流传。一位拥有同款显卡的用户亲自动手复现了这个名为HyperQwen的推理栈，结果发现：真实聊天场景下吞吐量只有118 tok/s，而那个诱人的381数字不仅依赖非默认设置，还会在长上下文请求中直接把引擎打崩。

这个栈到底是什么

HyperQwen由GitHub用户syv-ai发布，是一个Apache-2.0协议的vLLM定制构建，专门针对Qwen3.8-27B模型在W4A16量化格式下做了调优，权重约占19.5GB，并搭载了DFlash2投机解码。对比基线是同一个27B模型的Q4_K_M GGUF版本，跑在llama.cpp上，同卡约42 tok/s。

原帖宣称的82到381 tok/s提升，经过实际检验后发现：82是原版vLLM的起始基线，而381仅在引用复述类工作负载下才出现。这个数字需要设置DFLASH_TOKENS=15——一个非默认的更长草稿块参数。作者尝试后，聊天性能没变，但引用请求在20k上下文时引擎直接崩溃，报EngineDeadError和marlin_gemm分配失败。此后每个请求都返回500，容器重启后依然可能继续500，无法自愈。

W4A16量化指权重以4-bit存储、激活值保持16-bit的混合精度方案。相比GGUF常用的Q4_K_M（同样是4-bit权重），W4A16保留了更高精度的激活路径，配合marlin等专用CUDA kernel可在NVIDIA显卡上获得更高吞吐，但代价是显存占用更刚性、对kernel的支持要求更苛刻——文中出现的marlin_gemm分配失败正是该路径特有的故障形态。

**投机解码（speculative decoding）**用一个小的草稿模型或草稿块预测后续若干token，再由主模型批量验证并接受匹配部分。它在贪婪解码等确定性场景收益最大，在采样或思考密集场景收益会明显缩水。草稿块长度（如DFLASH_TOKENS）越长，理论加速越大，但验证失败率与显存开销也随之上升。

**Draft-flash类方案（如DFlash2）**的核心是让草稿阶段也复用主模型的部分计算，而非完全依赖独立小模型，因此在长上下文下对KV cache和显存的挤占更敏感——这正是文中20k上下文崩溃的诱因。

真实聊天性能实测

在思考密集型prompt上做贪婪解码（投机解码的最差场景），四个prompt平均118.1 tok/s，范围111到131。温度0.7采样下为123.3 tok/s。项目方自己给出的单用户聊天数字约127 tok/s，实测落在合理区间内。

上下文引用场景——一个29k token的prompt让模型逐字复现某段文字——解码达到237.6 tok/s，逐字校验通过。Prefill约1,210 tok/s，该prompt约24秒完成，大约是llama.cpp（~250 tok/s）的五倍。从启动到健康约3分钟（含首次JIT编译），预热后约1分钟。

对比GGUF基线的42 tok/s：真实聊天快三倍，引用场景快六倍。测试条件为420W功耗上限，驱动610.57，CUDA 13.3。

Prefill与Decode是推理的两个阶段。Prefill一次性并行处理整个prompt，算力受限，吞吐以tok/s计通常远高于decode；decode逐token自回归生成，受显存带宽限制。文中Prefill约1,210 tok/s而decode仅百级tok/s，是消费级单卡上典型的不对称表现，也因此长prompt的“首token延迟”往往比总吞吐更影响体感。

贪婪解码每步只取概率最高的token，是确定性输出，也是衡量投机解码上限的标准场景；温度采样引入随机性后，草稿被接受的概率下降，加速比随之变小，这解释了文中0.7采样下123.3 tok/s与贪婪118 tok/s的接近关系。

两个容易踩的测量陷阱

第一轮测试时，作者通过计数流式chunk得出43 tok/s——几乎是实际118 tok/s的三分之一，会让这个栈看起来比它替换掉的GGUF还慢。原因在于投机解码改变了流式输出的形态：vLLM不按每个SSE chunk一个token发送，而是发送整个被接受的批次，7个草稿下约2.5 token每chunk。正确做法是读取最终chunk的usage.completion_tokens，请求中加上stream_options: {"include_usage": true}。

第二个陷阱：模型把思考过程放在delta.reasoning而非reasoning_content下，且每个prompt都会思考。max_tokens必须留足余量，否则思考预算会吃掉答案。

SSE流式协议中，服务端通常每个token发一个data: chunk，因此按chunk计数即可近似token数。但vLLM在批量接受草稿后会把整批合并成单个chunk，chunk数与token数不再一一对应。文中约2.5 token/chunk即源于此。更稳健的做法是解析最终chunk里的usage.completion_tokens，它由服务端权威统计，不受流式打包方式影响，需在请求体中显式开启stream_options.include_usage。

思考模型的双字段问题：不同框架对思维链的字段命名并不统一（reasoning、reasoning_content、thinking等），且思考内容同样计入max_tokens预算。若客户端只读取答案字段而忽略思考字段，或在预算不足时让思考截断，会出现“答案为空”或“答非所问”的假故障，容易被误判为推理栈性能问题。

24GB显卡的物理法则

作者总结了三条运营规则，每条都是用一个下午的调试换来的。

服务器必须先预热。compose入口默认WARMUP=0，首批请求触发服务路径内核编译，冷启动数字毫无参考价值。每次启动后跑bench/warmup.sh。

频繁的agent cron任务必须暂停。llama-swap对已死成员每次请求要烧420秒健康检查超时，cron agent会在运行中途报错。

最关键的一条：systemctl stop strata会连带停掉llama-swap，因为llama-swap携带Requires=strata.service。而llama-swap无法在Strata运行时加载GGUF成员，因为Strata始终占着显存。HyperQwen窗口只能绕过代理，直连:18020，此时:8080下线。一张24GB卡同一时间只能跑一个大模型——这是物理规律，代理配置只是让它变得可见。

JIT编译与预热：vLLM在首次遇到某种shape或dtype组合时会即时编译CUDA kernel，因此冷启动首请求延迟极高、吞吐为0或极低。批量预热脚本的作用是提前触发这些编译路径，让稳态数字可复现。

llama-swap类代理通过按需启停成员模型来“共享”一块GPU，但它无法绕过VRAM互斥：只要常驻模型仍占用显存，候选模型就加载不进去。systemd的Requires=是强依赖，停止被依赖服务会连带停止依赖方，因此“只停一个服务”的直觉在链式依赖下并不成立。24GB卡上单一大模型 + 代理的可行组合，本质上是一道显存预算分配题，而非软件配置题。

现在跑什么

稳态下HyperQwen已关闭。Strata回归常驻服务，用真实补全验证后，七个cron全部恢复，第一次尝试时的Windows watcher cron正式退役。将HyperQwen变为llama-swap按需成员的接线已写好并暂存，等待路由决策后接入。

追逐381这个数字之前，建议带上自己实际运行的工作负载。引用路径确实飞快，聊天大约是GGUF路径的三倍，但支撑头条数字的那个设置，恰好在头条所需的长上下文尺寸上崩了作者的引擎。