本地跑 Qwen3.8-27B 选哪个推理框架？四个引擎实测，长文本差出 20 倍

本文数据来自同一台机器（双 RTX 3090 24GB）上的真实测试，基座模型都是 Qwen3.8-27B，非转载、非厂商标称。
同一个两万 token 的提示词，丢给一个引擎，五分钟还没读完；丢给另一个，十五秒读完。差的不是显卡，是引擎。
很多人在本地跑大模型时，第一个难题不是”用哪个模型”，而是”用哪个引擎”。这里说的引擎，也叫推理框架，就是真正把模型跑起来、回答你问题的那套程序。同一个模型换一套引擎来跑，速度和能装下的文本长度可能差出一倍以上。尤其当你只有一张 24GB 的显卡，想跑 Qwen3.8-27B 这种 27B 稠密模型时，引擎的选择几乎决定了你到底是”能用”还是”不能用”。
我们把四个主流引擎分别跑在单独的 3090 上，全都用真实请求压测。它们是 llama.cpp、vLLM、SGLang 和 NInfer。下面这份横评，尽量把每个引擎的真实脾气讲清楚。

先认识这四个引擎

llama.cpp 是本地推理的老牌选手，靠 GGUF 格式和极致的可移植性出名，从 Mac 到 CPU 到显卡都能跑，是无数人上手本地模型的第一站。
vLLM 是工业界部署的事实标准，格式支持最广，社区活跃，几乎所有新量化格式它都跟进得最快。
SGLang 以高吞吐的调度和连续批处理见长，对新一代混合注意力架构的适配也走在前列。
NInfer 则是 2026 年下半年冒出来的新面孔，它是一个从零写起的 C++/CUDA 引擎，目标非常明确，就是”单张显卡跑好一个模型”，对 Qwen3.8-27B 做了深度定制。我们测的是它在 3090 上的社区分支（v0.12.0）。

同一个模型，四种活法

需要先说清楚一件事，同一个 Qwen3.8-27B，在四个引擎里其实”不是一个东西”。
因为每个引擎都有自己的原生权重格式。llama.cpp 吃 GGUF，vLLM 支持 safetensors、compressed-tensors 以及各种低比特格式，SGLang 走 compressed-tensors 和 AWQ，而 NInfer 用自有的专用格式。顺便解释一下，所谓权重格式，本质是模型被压缩打包的方式。为了把 27B 的模型塞进 24GB 显卡，几乎都要做”量化”，也就是用更少的位数（比如 4 位、3 位）来存原本 16 位的参数，压得越狠越省显存，通常也越损精度。
不同引擎只认自己擅长的打包格式，这才是它们”各自活法”的由来。所以下面所有的对比，本质上是”各自部署态”的对比，而不是把同一份权重塞进四个引擎。这既是现实，也是这个横评最有价值的地方，因为它反映的正是你真正会遇到的场景。
还有一点绕不开。Qwen3.8-27B 用的是混合架构，64 层里有 48 层是 Gated Delta Net 这种线性注意力，只有 16 层是标准注意力。你可以先把线性注意力理解成一种”记忆逐字往后传”的结构，它省显存、能撑更长的文本。这个结构特点，恰恰是后面拉开差距的关键。

单流速度：新引擎明显更快

先看最直观的单请求生成速度，也就是只有一个用户、一次问一个问题的场景。这里有几个术语先交代一下，模型处理文本的最小单位叫 token，大致可以理解为一个字或一个词；decode 是模型逐字往外写答案的阶段；t/s 就是每秒能写多少个 token。

引擎	单流 decode
llama.cpp	约 50 到 57 t/s
vLLM	约 39 到 46 t/s
SGLang	约 47 到 54 t/s
NInfer	96 到 134 t/s

llama.cpp 在短上下文下单流其实不慢，它靠 MTP 投机解码能跑到 50 到 57。所谓投机解码，是让一个小模型先草草猜出后面几个词，再交给大模型一次性批改，猜对了就省下时间。

vLLM 的区间看着比 SGLang 低，原因在后面会讲，是权重和 KV 缓存的搭配问题。真正在所有引擎里拉开差距的是 NInfer，单流能跑到 96 到 134，是其他几家的两倍上下，它对单张卡的针对性优化在这里体现得淋漓尽致。

不过单流快不代表一切。真实使用里，你往往不止一个请求。

并发：不是谁更快，而是谁更公平

并发就是多个请求同时进来。这里要提醒一句，四个引擎的测试并发档位并不一致，所以横向看数字时要留个心眼。

llama.cpp 默认以单通道运行，多个请求只能排队，三个请求的聚合吞吐还是 57 左右，几乎等于单流。

SGLang 的强项在这里，它用连续批处理让三个并发请求真正并行，聚合吞吐能到 130 到 143。

vLLM 同样支持批处理，但我们在 3090 上做过的唯一一次同权重对照里（两边都用 RedHatAI 的 INT4 权重），它比 SGLang 慢大约 14%。

NInfer 走的是另一条路，它默认开两条通道，两个并发请求的聚合吞吐能到 180 到 207，单看数字是最高的。

但并发不只看吞吐，还要看公平。NInfer 读取长文档的 prefill 是单通道串行，它一边读，就一边把同一轮里的其它请求堵在后面，后来者只能干等。SGLang 的分块 prefill 让每个请求都能往前推进，谁都不会被谁饿死。对”多个应用或多个子代理同时在线”的场景，这种延迟可预测性比峰值吞吐更重要，这也是 SGLang 最扎实的底座价值。需要补充一句，NInfer 在随后发布的新版里，已经给读文档开了多条通道，这个堵塞问题基本解决（详见我们的后续实测）。

长上下文：真正的分水岭

如果只让我用一个维度来区分这四款引擎，我会选长上下文。这一项直接决定谁能拿来做真正的工程任务。

先解释一下 prefill，它是模型正式回答前”读完你整段问题”的阶段，问题越长这一步越吃时间。原因是那个 Gated Delta Net 结构。线性注意力的状态依赖前一个 token，好比一条流水线必须等上一个零件过完才能加工下一个，天生不利于并行 prefill。引擎能不能把这段”顺序扫描”改造成”分块并行”，就成了长文本场景的生死线。

llama.cpp 在这里栽了跟头。我们测的版本（b10454）对 Gated Delta Net 的 prefill 还是逐 token 顺序扫描，官方源码里也留着”尚未实现分块内核”的注释。结果是两万 token 的提示词跑超过 300 秒还没完成，而 SGLang 同样的任务只用 15.6 秒，差了将近 20 倍。这也是我们后来放弃用 llama.cpp 跑长上下文的原因。

vLLM 的问题不一样。它能预填，但长上下文下衰减明显。当 KV 缓存用 fp8 方案时，它只能走 flashinfer 后端，反量化开销会随上下文线性放大，30K 上下文就掉到 8 t/s 左右。换成 bf16 缓存能回到 16，但到 70K 时又只剩 3，因为注意力本身是 O(n) 的，上下文越长，每次生成要翻的历史就越多，这是物理限制。

SGLang 是前三者里长上下文最稳的。它用分块的 triton 实现解决了顺序扫描问题，9.8 万 token 的冷 prefill 大约 109 秒，速度约 897 t/s。

NInfer 则把这件事做到了另一个量级。同样规模的 9.8 万 token 冷 prefill 只要 69 秒，速度约 1422 t/s，比 SGLang 快了约六成，而且上下文能顶到约 19 万甚至 25 万 token，比 SGLang 的 15 万更宽。

引擎	长上下文 prefill	可用上下文
llama.cpp	2 万 token 超过 300 秒，不可用	128K（名义）
vLLM	30K 衰减到 8 到 16 t/s	随 KV 配置差异大
SGLang	9.8 万 token 约 109 秒	15 万
NInfer	9.8 万 token 约 69 秒	约 19 万到 25.6 万

结论：按场景选，不按名气选

跑完这一圈，我的感受是，这四个引擎没有绝对的优劣，只有和场景是否匹配。

如果你是个人开发者，单机单窗口，经常和模型进行长对话或者长文档分析，NInfer 是当下最值得试的选择。它的单流速度、上下文长度和长文本 prefill 全面领先。但它也有另一面，它是一个还很年轻、由社区维护的分支，选它意味着接受一定的不确定性；至于前面说的读取长上下文会阻塞同轮请求，它随后的新版已经修复（详见后续实测）。

如果你需要把本地模型共享给多个应用或多个 AI 智能体，追求”谁都不被谁堵住”，SGLang 依然是最稳的通用底座。它的连续批处理和高并发下的延迟稳定性，是这几款里最成熟的。

如果你手上是 SGLang 和 NInfer 都不支持的冷门量化格式，尤其是各种低比特压缩权重，vLLM 作为格式兜底的价值无可替代。只要别指望它在 3090 上跑长上下文。

至于 llama.cpp，它依旧是最好的入门与跨平台选择。只要你的任务不碰长文本，它在短上下文下的单流表现完全够用，而且它能在别人跑不动的地方跑起来。但一旦上下文变长，它对这类混合架构的短板就会暴露无遗。

一句话总结这四款引擎的性格：llama.cpp 赢在普及，vLLM 赢在兼容，SGLang 赢在并发与均衡，NInfer 赢在单卡的极致性能。

附：测试条件与说明

所有测试都在双 RTX 3090 24GB（Ampere 架构）上完成，每个引擎跑在单独一张卡上。基座模型统一为 Qwen3.8-27B，各引擎使用各自的部署格式：llama.cpp 用 IQ4_XS GGUF（b10454），vLLM 分别测了 GSQ 三比特和 RedHatAI INT4，SGLang 用压缩张量 W4A16（v0.5.20），NInfer 用其自有的 groupwise 量化格式（v0.12.0 社区分支）。

需要提醒的是，这些结果来自不同时间的实测，量化方式、上下文配置并不完全一致，绝对数字会随硬件、驱动和负载变化。本文更想传达的是四款引擎之间的相对形态，而非某个精确到小数点的排名。所有速度数字均为实测，不是厂商标称。