Mountain Divider

从部署到实测：覆盖标准部署、量化部署、Agent场景三大维度。

作者丨吴海明何宇轩

编辑丨李娜岑峰

8月14日，阿里 Qwen 团队开源了 Qwen3.8-27B 模型，紧接着社区里的声音从“能不能跑”变成了“是不是新的模型斩杀线”，有人把它叫作本地 Opus，也有人直接给出更刺激的判断：一个 27B 开源模型，已经能在部分代码和 Agent 任务上达到顶级闭源模型的水平。那么，一个 27B 开源模型，体验到底怎么样呢?

根据官方数据，27B dense、Apache 2.0、262K 原生上下文、可扩展到 100 万 token、支持视觉理解、思考默认开启，低比特量化后还能压到十几 GB 级 GGUF 文件，这说明 Qwen3.8-27B 是一个试图把代码、长上下文、多模态和 Agent 工作流一起拉到本地的开源底座。

因此，我们从适配 Agent 出发，先后测试标准化部署、量化部署和接入 Agent 框架。其中，标准部署看 vLLM、SGLang 和 Llama.cpp 谁更能榨干 GPU，将推理速度提到最快；量化部署从 2bit 测到 16bit，看文件体积、速度和质量怎么取舍；Agent 测试则把本地 Qwen3.8-27B 接入 DeepSeek Harness，并用同样本地部署的 DeepSeek-V4-Flash-0731 做对照。测试任务从组合推理、事实校验、新闻写作，一直压到论文综述和 3D 网站生成。

实测结果有点像给这波热度泼了一杯很浓的咖啡：确实醒脑，但也很苦。在 Agent 质量评分里，Qwen3.8-27B 最终拿到任务完成度的满分，复杂任务完成度明显更稳；标准部署下，vLLM 和 SGLang 平均吞吐都超过 40 token/s；量化部署里，3bit 到 6bit 在本轮文本任务中保持了完成度满分的质量。

可另一面也同样扎眼：Qwen 最终跑通 9 个 Agent 任务消耗了 13,995,350 token、197 次请求和 22,564.37 秒，约 6 小时 17 分钟；其中，生成 3D 网站单题就烧掉 11,533,959 token，分析日志发现，核心问题出现在复杂任务拆分归于复杂、单步目标过重、上下文反复回灌，导致大量时间消耗在和空转上。它确实能干活，而且能把复杂任务做得更完整，但是它烧的不仅是 token，更是用户的时间。

所以，这篇文章回答了：性能比肩 Claude Opus 4.6 Max 的开源 dense 模型，放到本地工作流里到底怎么用？在哪些部署框架下跑得快，量化到几 bit 还可靠，接入 Agent 后质量优势值不值得、等待时间和本地计算成本？简单说，Qwen3.8-27B 是一个能做事、愿意深想、但必须被严格约束 token、步骤和输出边界的开源 Agent 底座。它让社区开发者和科研院所有机会用本地设备获得接近顶级闭源模型的能力，也把一个新的问题摆到台前：开源免费之后，我们还要不要为时间买单？

不看榜单，直接实践：

部署、量化、Agent 三组硬测

我们在一台搭载 A100 GPU 的服务器上对 Qwen3.8-27B 进行部署和测试，同时，我们设计了三类任务题目：第一类是模型能直接完成的推理题，第二类是指令跟随和事实校验题，第三类是接入 Agent 后才有意义的长上下文、文件读写和前端生成任务。

具体题目如下：

这三类题目被用来考验模型的多种能力，推理题考察模型能不能在没有工具辅助的情况下稳定完成多条件推导，尤其是能否区分不同统计口径、避免只给一个看似合理但不完整的答案。指令跟随和事实校验题更接近日常内容生产场景，重点考察模型是否能遵守字数、格式、禁词、语气和事实边界，避免在任务中把话说满、说偏或说过头。Agent 测试题则进一步把模型放进文件系统和代码生成流程里，观察模型能不能读材料、写文件、组织长上下文、生成可运行代码，并在复杂任务中持续推进到一个可交付结果。

评分上，我们采用 0 到 2 分制：完全满足题目要求记 2 分；主体方向正确但有明显瑕疵记 1 分；关键结论错误、任务失败或输出截断记 0 分。需要说明的是，质量分、吞吐、显存、耗时和 token 消耗是不同口径，本文会分开统计，同时评估模型在跑得快与答得好两方面的表现。

基于上述题目，我们同时构建了三组测试任务：标准部署、量化部署和 Agent 场景测试。标准部署组使用官方标准模型权重与题目，对比 vLLM、SGLang 和 Llama.cpp 三种部署框架，观察不同部署框架下的回答质量与吞吐差异；量化部署组采用 Llama.cpp 作为框架，横向测试 2bit 至 16bit 版本，考察模型权重文件大小、生成速度和回答质量之间的取舍；Agent 组则把部署好的模型接入热门的 DeepSeek Harness，在 A1~A7 之外加入论文综述（A8）和 3D 网站生成（A9），记录任务完成率、质量得分、token 消耗、请求次数和端到端耗时。

三组测试分别回答三个用户最关心的问题：什么框架更合适本地部署、压缩到什么程度仍然可靠，以及接入 Agent 后能否以可控成本完成任务。

标准部署：vLLM / SGLang 跑满 A100，Llama.cpp 胜在门槛低

三款主流模型部署框架：vLLM, SGLang 和 Llama.cpp

在这组实验中，我们分别用 vLLM、SGLang 和 Llama.cpp 部署标准 Qwen3.8-27B，并使用 A1-A7 的 7 道题测试回答质量和平均吞吐量，题目覆盖组合推理、时间线校验、表格推理、中文精确指令跟随、闲聊、新闻写作和实验结果归因。一起看看结果：

从结果看，vLLM 的表现最稳，7 道题拿到 14/14，SGLang 和 Llama.cpp 没有出现方向性错误，但都暴露出一些约束执行问题：SGLang 在 A3 表格推理里对不同口径的分析不够完整，A4 的第 5 句话也低于题目要求的 18 到 28 个汉字；Llama.cpp 的主要扣分点出现在 A6，新闻稿要求约 800 字，实际生成到 1400 多字，内容能用，但篇幅控制失守。

速度差异比质量差异更明显，vLLM 和 SGLang 的平均吞吐分别为 41.77 token/s 和 40.06 token/s，基本在同一档；Llama.cpp 为 23.50 token/s，只有前两者的六成左右。

进一步从三个框架在推理过程中的显存占用可以发现，vLLM 和 SGLang 都充分利用了 GPU 资源：vLLM 在两张 A100 上都接近 39.3GB 显存占用，GPU 利用率达到 100%；SGLang 的显存占用也在 38GB 到 40GB 附近，GPU 利用率约 98%。Llama.cpp 则只占用了 34GB 左右显存，推理时 GPU 利用率只有 46% 到 53%，这解释了它为什么质量还能跟上，吞吐却明显落后一档。因此，标准部署里真正拉开速度的核心是框架能否把 GPU 算力高效利用。

量化部署：3bit 到 16bit 质量持平，2bit 开始露出边界

这组实验用 Llama.cpp 测试 2/3/4/5/6/8/16bit 版本，量化本身不改变模型参数量，改变的是权重存储精度和文件体积，在一定程度上会影响模型结果的效果。Qwen3.8-27B 的权重参数量为 27.78 B，官方版本的权重大小约 55.59 GB，量化后的 GGUF 版本文件大小则从 7.27GB 到 54.7GB 不等。

具体测试结果如下：

这组量化结果要分三条线来看：

1.质量：3bit、4bit、5bit 和 6bit 在 7 道题上都拿到 14/14，说明在这批文本推理、指令跟随和短文写作任务里，中低比特量化没有带来明显质量塌陷。2bit 和 8bit 都是 13/14，扣分点集中在 A2 时间线校验：它们先识别出日期矛盾，却在修正版里又把“正式权重已在更早日期公开”写了回去，而 16bit 也是 13/14，但问题换成了 A6 篇幅控制，约 800 字的新闻稿实际写到 1200 多个汉字，内容可用，边界没守住。

2.速度：吞吐并没有随着 bit 数升高而平滑下降，但大方向仍然清楚：2bit / IQ2_XXS 最高，为 47.89 token/s；3bit 为 44.68 token/s；4bit 为 39.45 token/s；5bit 和 6bit 继续降到 36.11 和 33.12 token/s。8bit 为 30.79 token/s，16bit 只有 23.50 token/s。低比特确实能换来更轻的存储和更高的平均生成速度，但 2bit 的质量边界已经在事实修正题里露出来。

3.显存: 截图显示，量化文件越大，推理时显存占用也基本同步上升：2bit 在两张 A100 上约占 13.8GB 和 14.1GB，3bit 约 15GB，4bit 约 17GB，5bit 接近 19GB，6bit 约 20GB，8bit 约 23GB；到 16bit 时已经升到约 34GB。相比标准 bf16 部署，低比特版本把本地运行门槛明显压低了。不过这些 Llama.cpp 量化测试里的 GPU 利用率大多在 46% 到 53% 之间，说明 Llama.cpp 和量化版模型的组合更加适合 PC 或边缘设备端部署推理。

因此，这组结果更适合支持一个克制结论：如果只看本轮 7 道文本任务，3bit 到 6bit 是比较稳的区间；2bit 最省、最快，但已经出现事实修正错误；8bit 并没有因为更高精度完全避免同类问题；16bit 则证明高精度也可能在输出长度上失控。

Agent 测试拉开差距：Qwen 质量拿满分，成本也冲到天花板

Agent 测试实验，是本文最关键的一组。我们在分别在 DeepSeek Harness 上分别接入 Qwen3.8-27B 和 DeepSeek-V4-Flash-0731-Q4 两个开源模型，两个模型都在本地部署后，完成上述 9 个任务。这些任务包括组合推理、时间线校验、表格推理、中文指令跟随、新闻写作、长上下文论文综述，以及一个复杂 3D 网页生成任务。

从回答质量来看，Qwen3.8-27B 表现更佳，最终拿到 18/18，质量通过率 100%；DeepSeek-V4-Flash-0731-Q4 得分为 14/18，质量通过率 77.78%。DeepSeek 的优势是执行快，但在若干需要严格校验的任务中不够稳，例如 A1 会保留错误中间表格，A2 的时间线修正版仍有不严谨之处，A7 对 Agent 增益的表述偏积极。Qwen 的答案更克制，尤其在表格口径、事实边界和实验归因这类题目上，更接近媒体评测需要的写法。

另外，A9 的差异更直观，两个模型都被要求生成“颐和园 · 昆明湖与万寿山”的 3D 网站，结果如下图所示。Qwen 生成的页面已经具备昆明湖、万寿山、佛香阁、桥、导览按钮和日景/暮色切换等核心元素，拖拽旋转、滚轮缩放、镜头切换也能工作，整体更接近一个可交付的 3D 数字沙盘。DeepSeek 的页面虽然保留了标题、景点按钮和交互提示，但主画面基本为空，颐和园主体元素没有真正渲染出来。这一题把两者的差别放大了：Qwen 更愿意把复杂场景一步步补齐，DeepSeek 更容易先把框架搭出来，但视觉内容没有跟上。

Qwen3.8-27B-Q16 和 DeepSeek-V4-Flash-0731-Q4 在 DeepSeek Harness 框架中一次性完成 “颐和园 · 昆明湖与万寿山” 3D 网站的页面结果

然而， Qwen 虽然具有质量优势，但代价也很高，完成上述 9 个任务共消耗 13,995,350 token，其中输入 token 达到 13,718,510，输出 token 为 276,840，总耗时 22,564.37 秒（约 6 小时 17 分钟），请求 197 次。DeepSeek 总 token 为 956,630，输入 token 927,401，输出 token 29,229，总耗时 1,343.75 秒（约 22 分钟），请求 87 次。换算下来，Qwen 的总 token 约为 DeepSeek 的 14.6 倍，总耗时约为 16.8 倍，输出 token 约为 9.5 倍。其中，A9 任务是两个模型成本差距最大的来源，Qwen 的单题就消耗 11,533,959 token、124 次 LLM 请求和 18,639.20 秒；DeepSeek 同题只用了 161,019 token、15 次请求和 540.95 秒。

通过这组结果可以知道 Qwen3.8-27B 更适合质量优先、需要长推理和复杂交付的任务，但必须被严格约束；DeepSeek-V4-Flash-0731 更适合快速执行和低成本尝试，但关键结论和复杂视觉交付需要人工复核。另外，在 Agent 场景下，模型可用性不只看能否完成，还要看完成一次任务要花多少 token、多少时间，以及失败时是否容易被发现和修正。

从官方榜单解读：Qwen3.8-27B

为什么能成为高端 Agent 的底座

为了回答这个问题，我们回到官方在 Hugging Face 的模型卡，Qwen3.8-27B 的定位是一个面向 coding、professional work、research 和 long-horizon agentic tasks 的本地开源模型，官方给出的基准榜单也基本围绕这几个方向展开：代码、Agent、长程办公、指令跟随、科学推理，以及多模态 computer use：(雷峰网)

在此，我们通过上表中与当前测试相关的评测榜单数据来进一步分析 Qwen3.8-27B 效果好的原因。

首先，对比 Qwen3.6-27B，Qwen3.8-27B 的提升主要集中在更接近真实工作流的任务上。Terminal Bench 2.1、SWE-bench Pro、NL2Repo-Bench、DeepSWE 和 QwenSWEBench 分别对应终端环境编码、软件工程修复、repo 级代码生成和自主工程执行，这些指标都有明显提升，说明模型不只是单轮代码能力变强，而是在读懂任务、规划步骤、调用工具和持续修正上更接近 Agent 工作流需要。

其次，CoWorkBench、JobBench 和 Agents' Last Exam 的提升，解释了 Qwen3.8-27B 为什么在 Agent 场景里更愿意把任务推进完整；IFBench 从 69.1 提到 79.5，则说明它在格式、边界和复杂约束跟随上有更强基础。与此同时，GPQA Diamond、HLE 以及 OSWorld-Verified、WebArena-Verified、AndroidWorld、MathVision、OmniDocBench、RealWorldQA 等指标也表明，Qwen3.8-27B 保留了较强的科学推理、知识处理、视觉理解和 computer use 能力。这些官方数据共同指向一个结论：Qwen3.8-27B 的优势来自更完整的 Agent 能力栈，而不只是某一项单点能力变强。

更准确地说，据官方披露 Qwen3.8-27B 的能力确实向代码、Agent、长程任务、指令跟随和多模态理解倾斜，这解释了它为什么在复杂任务里更容易做出高质量结果。

Qwen3.8-27B 虽然很强，

但在 Agent 场景的处理能力并不强

前面的结果说明 Qwen3.8-27B 的能力足够强，并不能说明它完全适合作为 Agent 底座，这需要深入分析接入 DeepSeek Harness 后的运行数据。我们从 DeepSeek Harness 的会话日志中拆分了 reasoning chunks、text chunks 和 step 时长，并分别统计 A1~A7 常规任务、加入 A8 长上下文论文综述后、再加入 A9 复杂 3D 网站生成后的平均思考占比。结果如下：

根据 A1~A7 常规任务，Qwen 的平均思考时间占比约为 55.6%，平均思考 token 占比约为 60.7%，这说明，Qwen 还没有真正进入输出和操作阶段，就已经把一半以上资源花在内部推理里。加入 A8 后，Qwen 的思考时间占比下降到 48.4%，主要是因为长上下文论文综述带来了更重的 prefill 和上下文处理成本，降低了思考的比例，到了 A9 复杂 3D 网站任务，平均思考时间占比又回到 51.3%，思考 token 占比也升到 58.3%。相比之下，DeepSeek 的思考时间占比从 A1~A7 的 29.6% 降到 A1~A9 的 24.2%，思考 token 占比也从 36.6% 降到 30.1%。

为了更好分析模型在复杂任务中与 Agent 框架的适配性，我们进一步统计了两个模型在 A9 上的运行数据。A9 要求模型完成页面构思、结构拆分、前端实现、文件读写和结果交付，如果 Agent 能力足够强，模型应该先把任务拆成若干边界明确的小目标，再逐步完成。

从上表看，相比 Qwen 总耗时 21,543 秒（约 6 小时），DeepSeek 只用了 540 秒，约 9 分钟；同时，Qwen 的结果输出时间是 146 秒，DeepSeek 是 23 秒，差距约 6.3 倍。真正拉开距离的是思考时间、其它运行时间和多轮执行，Qwen 的思考时间达到 5,974 秒，是 DeepSeek 的 157 倍；而其它运行时间达到 12,632 秒，占总时间 59%，这部分往往对应上下文处理、工具调用、文件读写、等待和反复执行，即 Qwen 并不是一直在高效生成结果，而是在 Agent 流程里耗费了大量不可见时间。

任务拆解数据也能解释这种空转，Qwen 拆出了 75 个 step，分 3 轮 turn 执行，请求大模型 124 次，而 DeepSeek 只有 8 个 step、15 次请求。可以发现，Qwen 的步骤更多、更细，但结合耗时和 token 看，问题恰恰是“拆得多，不等于拆得好”。有效的任务拆分应该让每一步目标更窄、完成标准更清楚、上下文更轻，而 Qwen 的很多 step 仍然很重，单步内继续长时间思考，后续又反复带着庞大上下文进入下一轮，最终把输入 token 推到 11,315,587，是 DeepSeek 的 548 倍。

所以，Qwen3.8-27B 在 Agent 场景中的真实表现是不会经济地把任务做完，尽管模型能力很强，但很大程度上来自更长时间的深思、更多轮次的反复和更高 token 消耗，而不是来自高效的规划、拆解和执行控制。对于 Agent 产品的底座来说，一个模型如果不能把任务拆细、不能识别无效循环、不能及时停止空转，即使最后能做出结果，也会让用户付出过高的等待成本和算力成本。

从部署到 Agent：Qwen3.8-27B 值得用，但 Agent 场景必须被约束

回到最实际的问题：如果只是部署 Qwen3.8-27B，框架怎么选？追求服务化吞吐和 GPU 利用率，vLLM 和 SGLang 更合适，两者基本处在同一档；如果更看重上手门槛、量化版本支持和本地设备适配，Llama.cpp 仍然是更友好的选择。换句话说，vLLM / SGLang 更适合“把 A100 跑满”，Llama.cpp 更适合“先把模型跑起来”。此外，通过量化测试，3bit 到 6bit 在文件体积、速度和质量之间的平衡更好；2bit 最省、最快，但已经在事实修正题里露出边界；8bit 和 16bit 也没有因为精度更高就完全避免问题。因此，本地部署不一定要盲目追求最高精度，真正值得看的，是任务质量、吞吐、显存和文件体积之间的综合账。

从开源角度看，Qwen3.8-27B ，一个 Apache 2.0 许可的 dense 模型，能够被官方和社区放到与 Claude Opus 4.6 Max 同一档位讨论，甚至在部分测试中具备超过 Opus 4.6 Max 的表现，这对社区开发者、科研院所和需要私有化部署的团队都是利好，可部署、可复测、可量化、可改造。

官方报告：Qwen3.8-27B 在部分测试中超越 Claude Opus 4.6 Max

从应用角度看，通过本文的测试可以发现：模型能力强，不等于适配 Agent 的效果好。 在 DeepSeek Harness 测试中，Qwen 的质量得分更高，但它在复杂 Agent 任务中的适配能力非常一般，尤其表现为任务拆分不够细、单步目标过重、完成标准不清晰、上下文反复回灌，并由此带来大量空转。

因此，Qwen3.8-27B 更适合被看作一个“能力很强、但需要工程约束的开源底座”，其最适合的用法，不是替代一切模型，而是在需要质量、可控性和私有化的场景里，作为一个值得认真工程化约束的开源 Agent 底座。