阿里开源 Qwen3.8-27B 本地实测：性能很强，但 Agent 适配仍待补课

从部署到实测：覆盖标准部署、量化部署、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 底座。它让社区开发者和科研院所有机会用本地设备获得接近顶级闭源模型的能力，也把一个新的问题摆到台前：开源免费之后，我们还要不要为时间买单？

01

不看榜单，直接实践：

部署、量化、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 则证明高精度也可能在输出长度上失控。

• ← 返回资讯流