이미지: Qwen 공식 발표 갈무리
摘要
- 阿里巴巴通义千问于8月14日在Hugging Face上以Apache 2.0协议开放了Qwen3.8-27B的权重。
- 该模型为27B稠密结构并搭载视觉编码器,基础上下文为262,144个token,通过YaRN设置可扩展至100万。
- 4比特GGUF文件为17.9GB,一张24GB级显卡即可装下,在官方对比表中多个项目上超过了Claude Opus 4.6 Max。
阿里巴巴通义千问(Qwen)于8月14日在Hugging Face上传了Qwen3.8-27B的权重。仓库中附上许可证文件是在同一天下午(韩国时间),内容为Apache 2.0——商业使用没有用户数量限制,也无需支付许可费,是最宽松的一类协议。
通义千问官方账号表示:"仅凭27B参数,就在整体上超越了Qwen3.7-Plus,尤其在实际编码和办公任务上表现突出。"上下文基础为262,144个token,调整设置后可扩展至100万。
比起分数,更值得关注的是体积。压缩为4比特后为17.9GB——一张RTX 4090或5090,或24GB统一内存的Mac即可直接装下。想想两周前抢占头条的Qwen3.8-Max,以2.4万亿参数要求多张H100运行,这次才是真正能上手摸到的那一款。
只有27B,为何能达到这样的分数
其架构颇为特殊。64层由重复16次的4层区块构成,每个区块由「3个门控DeltaNet(Gated DeltaNet)+1个门控注意力(Gated Attention)」组成。前三者属于线性注意力系列,只有第四个才是我们熟知的全量注意力。
用会议来打比方会更好理解。三位与会者把会议记录总结后记在脑中随身携带,只有第四位在需要时才会翻遍原始档案柜。因为只有四人中的一人在翻档案柜,即便输入26万token,内存也不会爆炸。
隐藏维度为5,120,FFN中间维度为17,408,token嵌入数为248,320个。门控注意力仅有24个Q头和4个KV头,因此缓存较轻。此外还搭载了视觉编码器,可同时读取图像和视频。
官方对比表中与Opus 4.6 Max正面较量
通义千问在模型卡片中直接公布的对比表里,前代Qwen3.6-27B、更高阶的API模型Qwen3.7-Plus,以及Claude Opus 4.6 Max并列其中。一款27B模型能与前沿闭源模型同列一表,这本身就是此次发布传递的信息。下面是通义千问随发布公开的原始对比表。
| 项目 | Qwen3.8-27B | Qwen3.6-27B | Qwen3.7-Plus | Opus 4.6 Max |
|---|---|---|---|---|
| 智能体编码 (SWE-bench Pro) | 61.7 | 53.5 | 57.6 | 53.4 |
| 智能体编码 (DeepSWE 1.1) | 42.2 | 13.3 | 14.2 | — |
| 终端编码 (Terminal Bench 2.1) | 73.0 | 63.4 | 64.0 | 78.2 |
| 长期办公任务 (CoWorkBench) | 70.7 | 61.0 | 65.1 | 68.2 |
| 指令遵循 (IFBench) | 79.5 | 69.1 | 79.1 | 62.5 |
| 科学推理 (GPQA Diamond) | 89.2 | 87.8 | 90.3 | 91.3 |
| 综合难题推理 (HLE) | 30.8 | 24.0 | 34.7 | 40.0 |
多模态方面的差距更大。计算机操作(OSWorld-Verified)为84.3比72.7,移动设备操作(AndroidWorld)为81.9比62.0。
不过这张表是卖方自制的表。表中一同列出的QwenSWEBench(79.0)是通义千问自行制作的基准测试,而作为对比对象的Opus 4.6 Max,是Anthropic在7月24日推出Opus 5之后的上一代模型。视觉项目的差距也更接近于将搭载视觉编码器的模型与以文本为主的模型放在同一把尺子上衡量的结果。
即便如此,仍有一些结论站得住脚。虽然在最高难度的推理和终端编码方面依然落后,但在实际编码和办公自动化领域,27B模型已站上了与前沿模型同一刻度线的位置。
部署为服务器——命令与百万级上下文
模型卡片推荐的技术栈是vLLM、SGLang、TokenSpeed。命令如下,就这么简单。
# vLLM(最通用的默认选择)
pip install vllm
vllm serve Qwen/Qwen3.8-27B
# SGLang——在系统提示词固定的工作负载中更快
python3 -m sglang.launch_server \
--model-path Qwen/Qwen3.8-27B --host 0.0.0.0 --port 30000
# 若VRAM紧张，使用官方FP8变体(块128精细量化)
vllm serve "Qwen/Qwen3.8-27B-FP8"
# Docker一行搞定
docker model run hf.co/Qwen/Qwen3.8-27B
若要超过262,144个token使用,需在config.json中加入YaRN缩放设置。以下是模型卡片中记载的完整配置。
{
"rope_parameters": {
"mrope_interleaved": true,
"mrope_section": [11, 11, 10],
"rope_type": "yarn",
"rope_theta": 10000000,
"partial_rotary_factor": 0.25,
"factor": 4.0,
"original_max_position_embeddings": 262144
}
}
VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 vllm serve Qwen/Qwen3.8-27B --max-model-len 1000000
SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN=1 python3 -m sglang.launch_server \
--model-path Qwen/Qwen3.8-27B --context-length 1000000
在笔记本电脑上运行——21种GGUF实测容量
Unsloth的GGUF仓库中上传了21个文件。以下是全部实际文件大小。这就像把照片保存为JPEG时调低画质滑块——越往下调越轻,但到某个临界点画质会明显劣化。
| 文件 | 大小 | 文件 | 大小 |
|---|---|---|---|
| UD-IQ2_XXS | 9.01 GB | Q4_K_M | 17.1 GB |
| UD-IQ2_M | 10.3 GB | Q4_1 | 17.5 GB |
| UD-Q2_K_XL | 10.7 GB | UD-Q4_K_XL | 17.9 GB |
| UD-IQ3_XXS | 11.9 GB | Q5_K_S | 19.3 GB |
| Q3_K_S | 12.6 GB | Q5_K_M | 19.8 GB |
| UD-Q3_K_XL | 13.4 GB | UD-Q5_K_XL | 20.2 GB |
| Q3_K_M | 13.8 GB | Q6_K | 22.9 GB |
| IQ4_XS | 15.7 GB | UD-Q6_K_XL | 25.9 GB |
| Q4_0 | 16.1 GB | Q8_0 | 29 GB |
| Q4_K_S | 16.1 GB | UD-Q8_K_XL | 31.5 GB |
| IQ4_NL | 16.3 GB | BF16(原始) | 56 GB |
./llama.cpp/llama-cli \
--model unsloth/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_XL.gguf \
--temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0
有一个坑需要注意。**即使压缩了权重,KV缓存也不会随之缩小。**即便压到4比特降至15GB,若把上下文设得很长,缓存仍会额外占用超过10GB。这就像把文件对折收起来,但摊开的桌面大小并不会因此改变。大多数技术栈都支持KV缓存FP8量化,应优先开启这项选项。
思考模式开关与推荐采样参数
默认为思考(thinking)模式。模型会先输出推理过程再作答,可按请求单独关闭。通过reasoning_effort(xhigh/medium/low)调节推理深度,通过preserve_thinking在多轮对话中保留推理块。
completion = client.chat.completions.create(
model="Qwen/Qwen3.8-27B", messages=messages,
extra_body={"chat_template_kwargs": {
"enable_thinking": True, "preserve_thinking": True}},
reasoning_effort="xhigh",
)
# 关闭思考模式，只获取即答结果
chat_response = client.chat.completions.create(
model="Qwen/Qwen3.8-27B", messages=messages,
temperature=0.7, top_p=0.8, presence_penalty=1.5,
extra_body={"top_k": 20,
"chat_template_kwargs": {"enable_thinking": False}},
)
推荐的采样值因模式而异。若直接使用默认值,在思考模式下回答会变得散乱。
| 参数 | 思考模式 | 即答(instruct)模式 |
|---|---|---|
| temperature | 1.0 | 0.7 |
| top_p | 0.95 | 0.80 |
| top_k | 20 | 20 |
| min_p | 0.0 | 0.0 |
| presence_penalty | 0.0 | 1.5 |
图像和视频也通过同一个端点输入。只需在content中加入{"type": "image_url", ...}或{"type": "video_url", ...}即可,模型卡片中写明,即使是小时级长度的视频,也能通过帧采样进行处理。
一表总结
| 项目 | 值 |
|---|---|
| 仓库 | Qwen/Qwen3.8-27B · FP8版 Qwen/Qwen3.8-27B-FP8 |
| 许可证 | Apache 2.0(无用户数量限制、无许可费) |
| 结构 | 27B稠密模型+视觉编码器 · 64层 · 隐藏维度5,120 |
| 注意力机制 | 门控DeltaNet 3 : 门控注意力 1 循环 |
| 上下文 | 基础262,144 / 通过YaRN可达100万 |
| 最低运行要求 | 4比特GGUF 17.9GB——24GB级GPU或Mac |
| 默认模式 | 思考模式开启(可通过enable_thinking切换) |
编辑视角
去年这个时候,把27B级别的开源模型接入实际业务,结论总是一样的。摘要、分类、抽取还算能用,但一旦进入需要多次调用工具、自主判断的任务,通常在第三步左右就会偏离轨道。因此"本地模型做预处理,判断交给API"的分工是很自然的选择。
这次表格中让人驻足的不是SWE-bench Pro或GPQA,而是CoWorkBench的70.7分。这是一项需要持续锁定目标、使用工具并保持任务轨迹的长时任务,而在这一项上,27B模型超过了Opus 4.6 Max(68.2)。这意味着差距缩小的不是单次问答的得分,而是长时间坚持完成任务的能力,性质完全不同。
但这并不意味着可以停用API。面对最难的问题时,前沿模型依然占优。只是企业中大多数实际工作根本达不到那个难度。整理内部文档、反复修改代码、看屏幕点击完成的自动化——这一整块任务已经整体转移到了"可以在自己的服务器内完成"的范畴。
对国内团队而言,这带来三点启示。第一,对于因数据外流限制而卡在AI引进环节的组织,如今有了真正的选择。由于采用Apache 2.0协议,既无用户数量限制,也无需单独协商,意味着无需法务审查。
第二,预算测算方式随之改变。如果一张24GB显卡就是基准线,那么团队级别的实验就降到了一张申请单就能通过的价格区间。此前本地模型的评估屡屡卡在"那到底要买几台服务器"这个问题上。
第三,即便如此,不建议直接用4比特版本执行智能体任务。量化带来的损失在单次回答中不易察觉,但会在二十步的长任务中不断累积,最终爆发。参照上表,Q8_0为29GB,若打算认真运行智能体任务,现实的基准线应设在32GB以上。
最后再说一点。虽然Qwen3.8-Max凭借2.4万亿参数抢占了头条,但真正撬动生态系统的,一直都是触手可及的体积。过去两年间,微调和衍生模型爆发式增长的区间,清一色都落在这个体量段。本周末国内社区讨论最多的文件名,恐怕不是那个2.4万亿参数的模型,而是那个17.9GB的GGUF文件。
