阿里巴巴千问团队正式开源 Qwen3.8-27B。这是一款 270 亿参数的原生多模态稠密模型，原生支持 262K tokens 上下文，通过 YaRN 技术可外推至 1M tokens。它在 SWE-bench Pro 测试中拿下 61.7 分，Agentic terminal coding 达到 73.0 分。在 LiveCodeBench v6 上得分 90.3，GPQA Diamond 得分 89.2。多项基准测试追平甚至反超了半年前的闭源旗舰。
但最炸裂的不是这些数字。最炸裂的是——有人在两块 2020 年发布的 RTX 3090 上，跑出了 105 tok/s 的吞吐量！
105 tok/s 是什么概念？ 相当于每秒生成 105 个 token，读一篇 1000 字的短文只需要 10 秒出头。而做到这一切的硬件，是五年前的老显卡。没有 H100，没有云服务，没有 API 密钥。这事的荒谬程度，相当于你用一台 2015 年的笔记本电脑玩转了 2025 年的 3A 大作！
这不可能吧？但数据就摆在面前——来自 Qwen3.8-27B 发布后 48 小时内的真实社区实测。
270 亿个参数，塞进 24GB 显存——这本身就是个魔术
先算一笔账。Qwen3.8-27B 的 BF16 权重完整检查点是 51.7GB。一张 RTX 3090 只有 24GB 显存。51.7 大于 24，而且是两倍多。数学不会骗人——全精度模型在一张 3090 上根本装不下。
那 105 tok/s 是怎么来的？答案只有一个：量化。
量化就是把模型的精度砍一刀，用更少的比特数来表示每个参数。BF16 每个参数占 16 个比特，换成 INT4 就只需要 4 个比特——体积直接缩到四分之一。27B 的模型用 4-bit 量化后大概 17GB 左右，刚好塞进 24GB 的显存，还能给 KV 缓存留点空间。
但问题来了——量化是有代价的。砍精度必然损失智力。那损失了多少？
社区里有人做了 GGUF 量化版本的完整对比测试。从 Q8_0 一路砍到 2-bit，七个量化等级横跨 2.9 个百分点的性能差距。注意——是 2.9 个百分点，不是 29 个。Q6_K 和 Q8_0 的性能差距小到小数点后第二位才体现出来。UD-IQ3_XXS 这个档位，居然保留了 Q8 版本 92.7% 的能力。
换句话说，砍掉一半以上的精度，只损失了不到 8% 的智商。而且最让人意外的是，整个量化阶梯上没有出现任何“断崖”——没有一个量化等级突然崩掉。这就怪了！
同一个模型，同一块显卡，差一倍的速度——问题出在哪
105 tok/s 是两块 3090 的成绩。但单卡的表现更值得琢磨。
有人用 llama.cpp 在单张 RTX 3090 上跑 Q4_K_M 量化版，测出来是 31 tok/s。但加了一个叫 --spec-type draft-mtp 的启动参数之后，速度直接飙到 41.3 tok/s——提升了 33%，而且不需要下载任何新文件，不需要转换格式，不需要重新编译。
MTP 是什么？ Multi-Token Prediction，多头预测。Qwen3.8 在训练的时候就内置了 MTP 的“草稿头”。它可以在主模型正式生成下一个 token 之前，先“猜”几个候选 token。主模型只需要验证这些候选对不对，而不是从零开始重新算。验证的成本远低于生成的成本。所以有了 MTP，速度就能往上蹿一截。
但这还没完。有人用 vLLM 在单张 3090 上跑出了更夸张的数字：批处理模式下 417 tok/s。单用户单次请求也有 82 tok/s。同一个模型，同一块显卡，llama.cpp 是 41 tok/s，vLLM 是 82 tok/s——差了一倍。
差在哪？ 差在 continuous batching（连续批处理）。vLLM 的调度机制可以把多个用户的请求拼在一起同时处理，GPU 的算力被压榨到了极致。llama.cpp 是单用户模式，一次只处理一个请求。两种场景，两种优化方向，结果差了一倍。
所以当你看到一个“XXX tok/s”的数字，第一个问题必须是——什么场景？什么配置？什么量化？有没有开 MTP？批处理还是单用户？ 脱离上下文谈速度，没有任何意义。
量化的流派之争——Intel 的配方真比别人的香吗
社区里的技术讨论已经深入到量化方案的颗粒度了。
有人在两块 3090 上用 vLLM 跑 Qwen3.8-27B，发现 INT8 量化模式下 KV 缓存的空间不够。于是换成了 W4A16 的 AutoRound 量化。AutoRound 是 Intel 开发的量化算法，它可以在 4-bit 权重、16-bit 激活值的配置下，尽量保住模型的精度。
但马上有人跳出来说——dbirks 的 AutoRound 版本不行，我换了 avuja 的版本。理由是 avuja 的版本“更接近过去经过实践检验的 Intel 配方”。
同一个量化算法，不同人打包出来的效果不一样。这事本身就挺耐人寻味的。量化不是简单地“把 16 比特砍成 4 比特”就完事了——它涉及到权重分组策略、缩放因子的计算方式、异常值处理等等一系列选择。不同的选择会直接影响最终模型的智力保留程度。有人在 4 张 Intel Arc Pro B70 上用 AutoRound 的 INT4 量化跑出了 47.8 tok/s，而且号称“质量与 BF16 持平”。“质量持平”这个说法本身就值得打个问号——持平是相对什么任务？代码生成持平，还是数学推理也持平？
更值得注意的是，官方直接放出了 FP8 量化权重。FP8 比 INT4 精度更高，体积也更大——24.6 GiB。一张 3090 刚好塞得下，但 KV 缓存的余量就非常紧张了。有人在社区里喊话——“请对 FP8 量化做调优，Q4 量化的智力流失太严重了”。但作者回了一句：“FP8 量化请检查双最大值 slug”。
这句话什么意思？外行看不懂，内行也不用多说。这就是量化调优的日常——每个人都有自己的配方，每个配方都有自己的脾气。
一个模型，两种命运——代码场景和散文场景差出 30%
同一个模型，同一个量化版本，同一块显卡——跑代码和跑散文，速度能差多少？
有人在测试 MTP 的时候做了一个有意思的对比。在 RTX 5090 mobile 上，n-max=2 的配置下，代码提示词跑出了 56.4 tok/s，散文只有 42.5 tok/s。差出 14 个 tok/s，接近 30% 的差距。
为什么？ 因为代码的结构性更强——函数、括号、关键字这些 token 的分布模式更规律，MTP 的草稿头猜中的概率更高。散文的自由度更大，草稿头猜错的概率更高，一旦猜错就要回退重算，速度就掉下来了。
这引出了一个更深层的问题：MTP 的 n-max 设成多少最合适？
有人在 5090 mobile 上做了扫参测试：
- n-max=2：整体中位数 50.9 tok/s，代码 56.4，散文 42.5
- n-max=3：整体 48.3 tok/s，代码 59.4，散文 37.9
- n-max=4：整体 47.3 tok/s，代码 60.2，散文 33.4
草稿越深，代码越快，散文越慢。 因为草稿越深，代码场景下连续命中的概率越高，收益越大；但散文场景下只要中间错一个，整条草稿链就废了。所以作者的推荐是：日常用 n-max=2，纯代码会话可以开到 3。
同一个模型，同一个硬件，同一个加速技术，换了一个任务类型——结果完全不同。所以“105 tok/s”这个数字到底代表什么？ 代表的是代码场景还是散文场景？代表的是 MTP 开启还是关闭？代表的是批处理还是单用户？
262K 上下文——一个让人又爱又恨的数字
Qwen3.8-27B 原生支持 262K tokens 的上下文。通过 YaRN 可以推到 1M。这是一个极其夸张的数字——相当于一次性把三本《三体》的内容塞进模型的“记忆”里。
但代价是什么？
262K 上下文意味着 KV 缓存会吃掉海量显存。有人在 llama.cpp 上做了测试：在 24GB 的 3090 上，Q4_K_M 的权重约 17GB，剩下的 7GB 要装 KV 缓存。如果不开 KV 缓存量化，上下文超过 90K 就会 OOM。开了 q4_0 的 KV 缓存之后，262K 的完整上下文才能塞进 24GB。
但 KV 缓存量化本身又会引入新的精度损失。这就形成了一个死循环：要长上下文就得量化 KV 缓存，量化 KV 缓存又会牺牲质量。到底牺牲了多少？ 没人给出确切答案。有人在 vLLM 上用 FP8 KV 缓存配合 MTP n=3，跑出了 108 tok/s 的成绩。但这是 20,319 个输入 token、生成 8,890 个 token 的特定场景。换了另一个场景，数字可能完全不同。
更麻烦的是——模型默认开启了“过度思考”模式。Qwen 官方文档自己承认，模型默认的 reasoning_effort 设置成了“xhigh”。有人抱怨：“Qwen3.8 27B 想太多了——36K+ tokens 了还一行代码都没写出来”。36K 个 token 的思考量——相当于一篇中篇小说长度的内部独白——然后一行代码都没生成。这到底是智能还是智障？
还好 Qwen3.8 加入了 reasoning_effort 参数，可以根据任务难度动态调节思考深度。但这意味着用户必须自己去调这个参数。调对了是效率，调错了是灾难。
5090 能跑，那 5070 呢——硬件门槛的真相
有人问：“我能在 RTX 5070 上跑吗？”
作者的回答干脆利落：“不行，你至少需要 24GB 显存。”
RTX 5070 的显存是多少？目前消费级 5070 的显存配置是 12GB。差了整整一倍。270 亿个参数，哪怕用 4-bit 量化压缩到 17GB，12GB 还是装不下。如果强行跑，系统就会把一部分参数放到系统内存里，然后速度就会从“tok/s”变成“秒/tok”——直接退回拨号上网时代。
那 16GB 的显卡呢？ 有人给出了建议：16GB 显卡可以跑 IQ4_XS，15.7GB。或者 IQ3_XXS，13.8GB，能多留点空间给上下文。但 IQ3 的智力损失比 IQ4 大——具体大多少？前面说了，UD-IQ3_XXS 保留了 Q8 版本 92.7% 的能力。也就是说，从 24GB 降到 16GB 的显卡，你要付出大约 7-8% 的智力代价。
8% 的智力换一张便宜一半的显卡——值吗？ 这取决于你要干什么。写代码可能感觉不出来，做数学推理可能就明显了。
更狠的是，有人用 8 张 RTX 3090 跑 119B 的模型。8 张 3090 的总显存是 192GB。这种配置的成本已经超过了一台二手 H100 服务器的价格，但好处是——完全本地、完全离线、没有 API 计费。
所以“本地跑大模型”到底是为了省钱还是为了隐私？ 如果是为了省钱，买 8 张 3090 的花费可能比你用三年 API 还贵。如果是为了隐私，那 8 张 3090 的资本投入就是合理的——数据不出机房，物理隔离。
开源协议 Apache 2.0——这句话值多少钱
Qwen3.8-27B 采用的是 Apache 2.0 协议。这意味着什么？意味着你可以免费下载、免费部署、免费商用，而且可以修改、可以再分发。
这句话值多少钱？对比一下就知道了。
闭源模型的 API 调用是按 token 计费的。输出速度大约 25.9 tok/s。如果你每天生成 10 万 token，一个月下来就是一笔不小的开销。而 Qwen3.8-27B 本地部署之后，生成多少 token 都不再产生 API 费用。
但“免费”不等于“零成本”。硬件是一次性投入，电费是持续性支出。两块 3090 的满载功耗是 700W（350W×2），一天跑 10 个小时就是 7 度电。按中国平均电价算，一天大概 5-7 块钱。一个月 150-200 块。比 API 便宜，但也不是零。
更关键的是——Apache 2.0 让“模型所有权”这个概念变得模糊了。你下载的是一堆权重文件，它们驻留在你的硬盘上，运行在你的显卡上。没有人能远程收回它们，没有人能突然涨价，没有人能因为政策变化而切断你的访问。这才是开源模型真正的价值——不是便宜，是不可剥夺。
48 小时，86 万次下载——社区的速度有多快
Qwen3.8-27B 发布后 48 小时内，Unsloth 上 GGUF 量化包的下载量达到了 86.8 万次。官方 FP8 权重的下载量是 12.3 万次。HackerNews 上的讨论帖拿到了 1387 分和 760+ 条评论。两天时间，近百万次下载。
这不是一个普通的模型发布。这是一个社区等了很久的“那个模型”——270 亿参数、消费级显卡能跑、性能接近旗舰闭源模型。
有人在发布当晚就用 llama.cpp 跑了起来。有人在第二天就发布了专门的推理引擎 NInfer-3090。有人在第三天就完成了昇腾平台的适配。有人在第四天就拿它做了一个可玩的二战飞机游戏。
社区的速度比官方文档更新还快。 官方说“推荐用 vLLM 0.17.0”，社区已经把 MTP 的扫参数据贴出来了。官方说“FP8 量化可用”，社区已经发现 INT8 的 KV 缓存空间不够了。官方说“模型支持 262K 上下文”，社区已经在测 100K 输入下 prefill 要花多长时间——约 2 分钟。
这正是开源生态最可怕的地方：官方发布一个“能用”的东西，社区能在 48 小时内把它变成“好用”的东西。86 万次下载背后是 86 万个测试样本、86 万份反馈、86 万个优化思路。闭源模型永远不可能获得这种规模的实时测试。
但有一个数据，到现在还没人解释清楚
回顾一下开头那个 105 tok/s 的数字。
两块 RTX 3090，Qwen3.8-27B，105 tok/s。但仔细看社区里的其他数据：单张 3090 在 llama.cpp 上开 MTP 是 41 tok/s；单张 3090 在 vLLM 单用户模式下是 82 tok/s；单张 3090 在 vLLM 批处理模式下是 417 tok/s。
105 处在 82 和 417 之间。两块卡的理论峰值应该是单卡的两倍——164 tok/s（单用户）或 834 tok/s（批处理）。105 远低于 164。为什么两块卡加起来反而比单卡的理论值还低？
可能是 tensor parallelism 的通信开销抵消了部分收益。可能是 KV 缓存需要在两张卡之间同步，产生了额外延迟。可能是测试场景不同——105 是针对特定代码任务的实测值，而 82 和 417 是 benchmark 的峰值。
但有一点是确定的：多卡不一定比单卡快。在某些场景下，两张卡协同工作的通信开销，可能超过第二张卡带来的算力增益。两张 3090 跑 105 tok/s，单张 3090 跑 82 tok/s——多花了一倍的钱，只多拿了 28% 的速度。
这合理吗？ 如果是为了跑更大的模型（比如 FP8 版本需要更多显存），那两张卡是刚需。但如果只是为了更快的速度，两张卡的投资回报率可能并不好看。
更诡异的是——有人在单张 RTX 3090 上用 vLLM 批处理模式跑出了 417 tok/s。如果 105 是批处理模式下的双卡成绩，那单卡批处理 417 反而比双卡 105 快了 4 倍。这说明 105 很可能不是批处理模式，而是单用户模式下的实测值。单用户双卡 105 对比单用户单卡 82——提升 28%，还算合理。
但问题依然存在：为什么没有人同时公布测试场景、量化方案、MTP 配置、并发数、输入输出长度这些完整信息？ 因为一个孤立的“105 tok/s”数字，在缺少上下文的情况下，什么也说明不了。
这或许就是开源社区最真实的样子——数据到处都是，但能串成完整故事的数据，永远不够。