千问3.8 27B实测：一张显卡跑长程编程Agent

一张显卡跑起前沿Agent能力

8月14日下午，阿里正式开源了千问3.8的27B模型权重，UP主在当晚第一时间完成了本地部署并进行了系统实测。这次发布之所以引发HuggingFace社区的高度关注，核心原因只有一个：这是第一次，一张消费级显卡就能跑起具备长程编程能力的开源模型。

从架构上看，这一代模型并没有推倒重来。它仍然基于千问3.5的整套架构体系——27.8B的稠密模型，支持多模态（图像、视频原生输入），原生262K上下文，4bit量化后可以塞进24GB显存的显卡。这里的"稠密模型"值得展开说明：与当前流行的MoE（Mixture of Experts，混合专家）架构不同，稠密模型意味着每次推理时所有27.8B参数都参与计算。MoE架构（如DeepSeek-V3的671B参数）虽然总参数量巨大，但每次推理只激活其中一部分专家网络（如37B），因此实际计算成本远低于总参数量暗示的水平。稠密模型的优势在于推理逻辑简单、部署门槛低、不存在专家路由的负载均衡问题，缺点是扩展性受限——要提升能力就必须增加全部参数，计算成本线性增长。千问选择在27B稠密架构上深耕而非转向MoE，核心考量正是消费级硬件的部署友好性。

官方明确表示，本次只做了两件事：继续预训练（Continue Pre-Training）和后训练（Post-Training，含SFT与RL强化），架构层面与3.5完全一致，模型权重直接沿用过来。具体而言，继续预训练是在已有预训练模型的基础上，使用新的或更高质量的语料继续进行无监督学习，目的是补充知识、强化特定领域能力，同时尽量避免灾难性遗忘。后训练则包括两个阶段：SFT（Supervised Fine-Tuning，监督微调）使用人工标注的指令-回答对让模型学会遵循指令；RL强化学习（通常采用RLHF或GRPO等算法）则通过奖励信号进一步优化模型的输出质量，尤其在推理链路的连贯性、工具调用的准确性等方面效果显著。这套"不改架构、只优化训练"的范式说明，在模型架构趋于成熟的当下，数据配方和训练策略已经成为能力提升的关键杠杆。

换句话说，千问团队这次不是靠堆参数，而是靠训练策略的优化，把一个27B级别的小模型的Agent能力和长程链路能力拉到了前所未有的高度。

跑分：多项接近甚至超越Claude Opus

相比上一代3.6 27B，官方给出的评测数据显示几乎所有项目分数都在上涨——不仅是单一数据点，SWE-Deep、千问自家的SWE-bench、Terminal-bench等多项基准全面提升。

这里有必要解释SWE-bench系列基准的含义。SWE-bench（Software Engineering Benchmark）是普林斯顿大学于2023年发布的代码能力评测基准，它从真实的GitHub仓库中抽取issue和对应的pull request，要求模型在给定issue描述的情况下自动生成代码补丁来修复问题。这不是简单的代码补全，而是需要理解项目结构、定位问题文件、生成跨文件修改——是目前衡量模型"软件工程能力"最权威的基准之一。SWE-bench Pro是其进阶版本，难度更高，涉及更复杂的多步推理和代码修改。

最引人注目的一点是，在SWE-bench Pro这一项上，27B模型的分数超过了Claude Opus。要知道Claude Opus的参数量估计在1T以上，而这里对比的是一个27B的模型，这个成绩本身已经相当了不起——意味着在特定软件工程任务上，精巧的训练策略可以弥补巨大的参数量差距。

当然也要理性看待：超越只是个别数据点，差距并非天壤之别。在GPQA问答、协作类评测上，27B与Opus 4.6非常接近；在Humor类项目上提升明显（从此前版本涨到30.8）；LiveCode类甚至超过了3.7 plus。但受限于模型容量，部分项目仍不如3.7。

真正的意义不在于超越了谁，而在于"一张卡能跑这一档"——这意味着普通人第一次拥有了一个可以长程辅助编程的本地模型。

部署实测：显存占用与推理框架避坑

UP主分享了非常实用的部署经验。4bit量化可放入24GB显卡；他自己使用FP8精度，部署在48GB显卡上，跑4个并发request，加上各种开销后占用约46GB，基本接近48GB上限。

关于量化精度的选择值得深入了解：原始模型通常以FP16（16位浮点）或BF16存储，每个参数占2字节，27.8B模型约需55.6GB显存。4bit量化将每个参数压缩到0.5字节，理论上只需约13.9GB，加上KV Cache和运行时开销，24GB显卡刚好能装下。FP8（8位浮点）是NVIDIA在Hopper架构（H100）和Ada Lovelace架构（RTX 4090/5090）中引入的原生支持格式，精度损失比4bit小得多，但显存占用约为FP16的一半（约27.8GB），因此需要48GB级别的显卡。UP主选择FP8而非4bit，是在精度和资源之间取了更偏向质量的平衡点。

对比之下，Kimi的全量权重占用1.56TB，即便是DeepSeek较低档的Flash版本也要200-300B参数量，27B的资源占用堪称"菩萨行为"。

在推理框架选择上有一个重要的坑需要注意。当前最主流的两个开源LLM推理服务框架是vLLM和SGLang。vLLM由加州大学伯克利分校团队开发，其核心创新是PagedAttention——借鉴操作系统虚拟内存分页的思想管理KV Cache，大幅减少显存碎片和浪费。SGLang同样出自伯克利，但侧重点不同：它引入了RadixAttention来实现更高效的前缀共享和缓存管理，并且在调度策略上更激进，对Agent类工作负载（频繁的工具调用、长上下文、多轮对话）优化更到位。

具体到本次部署：

• vLLM存在Bug：Prefix预填充与MTP（Multi-Token Prediction，UP主设为3）两者不能并存，同时开启会有调用tools的风险。这个issue开了很长时间但未完全解决。
• 改用SGLang：不存在上述冲突，同时开启Prefix Cache和MTP后，token生成速度提升到约40-50 tokens/s，Prefix Cache命中率约1.5-2，在48GB显卡上表现相当不错。

这里解释一下Prefix Cache和MTP这两项关键优化。Prefix Cache（前缀缓存）是指当多个请求共享相同的系统提示词或上下文前缀时，第一次计算的KV Cache可以被缓存并复用，避免重复计算，大幅降低首token延迟。这在Agent场景下尤为重要，因为Agent通常携带大量工具描述和系统指令作为固定前缀。Multi-Token Prediction（MTP，多token预测）则是一种投机解码的变体——模型一次性预测未来多个token，然后通过验证步骤确认预测是否正确，正确的token直接采纳，错误的回退重新生成。MTP设为3意味着每步尝试预测3个token，理想情况下可将生成速度提升2-3倍。

编程测试：能力可用但思考时间过长

车辆驾驶模拟器

第一个测试是让模型实现一个车辆驾驶模拟器。开启深度思考模式后，模型思考了将近29分钟，生成了约600多行代码。

这里的"深度思考模式"属于当前大模型领域的重要趋势——思维链推理（Chain-of-Thought Reasoning）的工程化实现。自OpenAI的o1模型以来，"让模型在生成最终答案前先进行长时间内部推理"已成为提升复杂任务表现的标准范式。模型会在输出答案前生成大量的中间推理token（思考过程），这些token消耗计算资源但不直接呈现给用户。29分钟的思考时间意味着模型可能生成了数万个推理token，在本地部署的40-50 tokens/s速度下，这个时长虽然在技术上可以解释，但在用户体验上确实难以接受。这也暴露了小模型做深度思考的根本矛盾：参数量不足导致每步推理的"信息密度"较低，模型需要更多步骤才能收敛到正确答案。

最终成品完成度不错：油门、刹车、拐弯、加速等界面元素都按照真实逻辑实现，整体表现可以接受。但思考时间实在太长，这是本次模型最大的槽点——太爱想了。

骑车动画

第二个测试是骑自行车的动画，思考了约12分钟。第一版代码漏掉了轮子，UP主提示后模型思考一分钟补齐。腿部旋转动效实现了，但轮子基本没有转起来，骑行位置也有偏差。整体属于"能用但不完美"的水平。

剧本与小说拆解

UP主日常大量使用模型做剧本拆解和小说生成。在生成激烈打斗场景时，模型考虑更细致，但偶尔会冒出莫名其妙的英文单词（如凭空出现的"玻璃"英文词），有点出戏。相比3.6，剧本拆解能力有提升，但幅度没有想象中那么大——这与语料能力强相关，代码方向的进步明显大于文本创作。

长程任务：本次的核心突破

真正体现价值的是任务级别的长程链路能力。这是当前AI Agent研究的核心方向：传统的LLM交互是单轮或少量多轮对话，而Agent范式要求模型能够自主规划多步任务、调用外部工具（浏览器、终端、API等）、观察执行结果、在失败时自我纠错并重新尝试——整个过程可能涉及数十甚至上百轮的"思考-行动-观察"循环。这对模型的要求远超简单的问答：它需要在超长上下文中保持目标一致性，准确解析工具返回的结构化和非结构化信息，并在遇到意外情况时做出合理决策。

UP主让模型自动操作浏览器发布小红书宣传内容，模型跑得非常积极，不断刷新浏览器操作。虽然截断时尚未成功发布，但相比原来，这类Web操控任务的成功率明显提高，链路更长，中间失败后能自我纠正、重新尝试。

另一个例子更能说明问题：树莓派向服务器发送信息，但界面上看不到数据，UP主让模型排查后台问题。模型持续跑了近一个小时——分析架构、检查工厂注册等，虽然直到最后触及最大输出token也未完全跑完，但整个链路的推理连贯性和自主纠错能力已经相当出色。

UP主判断，这种长链路方式与Kimi非常相似，本次模型的核心改动很可能就在于借鉴了类似Kimi的长链路机制。具体来说，Moonshot AI在Kimi k1.5/k2中采用了大规模强化学习训练策略——在Agent环境中让模型反复尝试、接收环境反馈、学习纠错，从而习得在长任务中保持推理连贯性和自主纠错的能力。千问3.8的后训练阶段很可能采用了类似的RL策略，让小模型也能撑起长程任务。

阿里把开源叙事拉了回来

从行业角度看，这次发布的意义超出了模型本身。上半年阿里曾陷入质疑：3月核心训练负责人离职当天股价跌了5.3%，外界普遍判断阿里最强模型以后不再开源。

但这一次，Max级权重首次开放，27B同步开源。官方口径是要把"开放权重与闭源前沿的差距压缩到半年左右"——即把半年前水平相当的模型公开出来（训练数据配方等核心机密仍不公开，属正常商业保留）。

值得注意的是，"开放权重"（Open Weight）与"完全开源"（Open Source）有本质区别：前者只公开模型参数，训练数据、数据配方、训练代码等核心资产仍然保密。这种模式下，阿里通过开放权重建立生态壁垒——当全球大量企业基于千问基座做后训练和应用开发时，千问架构就成为事实上的行业标准，阿里的云计算服务（训练和推理基础设施）自然成为这些企业的首选。同时，社区的广泛使用会反馈大量真实场景的问题和优化方向，相当于免费获得了大规模测试。Meta的Llama系列也采用了类似策略。

更重要的是生态价值。从3.5 27B到3.6 27B再到3.8 27B，一大批海外厂家（日本、欧洲等）都在这个基座上做后训练，相当于千问一家公司把整个小模型生态给养了起来。在许多非英语市场，千问系列已经成为Llama之外最重要的开源基座选择。这是送给开源世界的一份重要礼物。

结语：当下最好的个人可用本地模型

客观地说，27B的模型容量决定了它必然有能力上限——思考冗长、文本创作提升有限、长任务偶有中断。但正如UP主所言："它确确实实是当下最好的、个人能用的、能部署在你家里的开源模型。"

对于希望拥有本地Agent能力、又不想承担云端API成本和隐私顾虑的开发者来说，千问3.8 27B第一次让"本地长程编程"从概念变成了现实。这或许才是这次开源真正值得认真对待的原因。