今年七月快手旗下AI研发团队Kwaipilot推出了闭源版本的KAT-Coder-V2.5在开发者圈子里引发了不少讨论。没过多久团队再次放出一个重磅消息——开放权重版本KAT-Coder-V2.5-Dev正式亮相。这款模型采用了当前大模型领域热门的MoEMixture of Experts混合专家架构总参数量达到350亿但推理时实际激活的参数仅有30亿。换句话说它用轻量级的计算开销换来了接近甚至超越同级竞品的代码理解与生成能力。对于国内AI编程赛道而言Kwaipilot这一步走得相当务实。KAT系列自诞生以来就专注于Agentic Coding方向强调模型不仅能写代码还能像真正的软件工程师一样自主规划、调用工具、在多轮交互中迭代优化。此前KAT-Coder-Pro V1在SWE-Bench Verified上拿下73.4%的成绩已经证明了这条技术路线的可行性。此次开源的V2.5-Dev版本更像是把这套成熟方法论降维到一个更亲民的参数量级让中小团队和个人开发者也能低成本体验顶尖代码智能。模型架构稀疏激活的MoE设计效率与性能兼顾KAT-Coder-V2.5-Dev的核心底座选用了Qwen3.6-35B-A3B这是阿里通义千问家族中一款经过充分验证的MoE基座。MoE架构的本质在于按需调用——面对不同类型的输入门控网络会动态选择最合适的专家子网络参与计算其余专家处于休眠状态。这种稀疏激活机制使得模型在保持庞大知识容量的同时推理成本被压缩到与密集模型中30亿参数相当的水平。从工程角度看这种设计对代码生成任务尤为友好。编程场景中的需求往往呈现出明显的领域分化前端界面构建、后端API开发、算法实现、测试用例编写……每种任务对模型的知识调用路径差异很大。MoE架构天然适合这种分而治之的范式不同专家可以分别深耕特定领域门控网络则负责精准路由。Kwaipilot团队在此基础上进行了完整的后训练流程包括监督微调SFT和强化学习RL两个阶段数据集规模约12.7万条高质量样本。实测成绩多项基准领跑异常行为大幅收敛在代码大模型的竞技场里SWE-Bench系列是公认的硬骨头。它不像HumanEval那样只考单函数补全而是直接拿真实的GitHub Issue让模型去修Bug测的是端到端的软件工程能力。KAT-Coder-V2.5-Dev在这个战场上表现相当亮眼——SWE-bench Verified拿到69.40%SWE-bench多语言版本63.00%就连难度更高的SWE-bench Pro也冲到了45.96%。横向对比来看它压过了Qwen3.5-27B、Qwen3.6-35BA3B、Gemma4-31B等同级别对手。除了基准分数模型在行为健康度上的改进更值得细品。通过强化学习训练一些困扰代码模型的典型毛病被显著修正异常工具标签的出现频率从9.34%暴跌到0.28%单回合连续重复输出直接被清零。这些数字背后反映的是训练策略的精细化——模型不再胡乱的调用不存在的工具也不会陷入无意义的自我重复这对于实际落地到IDE插件或CI/CD流水线来说意味着更稳定的用户体验。Terminal Bench 2.1的测试结果也很有意思。KAT-Coder-V2.5-Dev在两个代理框架下的平均分达到41.02其中Terminus-2路线拿到32.60Claude Code路线更是冲到49.44。PinchBench上93.43%的通过率、SciCode上44.20%的得分以及KAT-Code-Bench上46.21%的成绩共同勾勒出一个能力均衡的代码助手形象——它既能处理日常开发琐事也能在需要深度推理的科学计算场景中给出靠谱答案。这里需要提一下评估的严谨性。Kwaipilot团队没有直接引用各模型的官方报告而是统一下载公开权重用vLLM或SGLang部署后在完全一致的流水线里跑测试。每个模型在每个评估集上只测一次除非发现明显错误才会复测。这种统一考场的做法让横向对比的可信度提升了不少。当然他们也坦诚指出了部分竞品在测试中暴露的问题Qwen3.6-35BA3B在某些测试集上与官方结果存在约10个百分点的偏差可能跟评测工具版本有关Qwen3.5-35BA3B和Gemma4-26BA4B则出现了对MultiEdit工具的幻觉调用影响了最终得分——这些问题本质上属于工具偏好与评测环境的不匹配而非模型能力缺陷。后训练揭秘从SFT到RL的完整链路奖励设计是门手艺活KAT-Coder-V2.5-Dev的训练后流程基本延续了KAT-V2.5的成熟配方数据构建、训练流水线和优化策略大体保持一致。整个流程可以拆解为两个大阶段先用12.7万条样本做监督微调让模型学会遵循指令、理解代码语义再对SFT后的模型进行强化学习用环境反馈来进一步打磨决策质量。强化学习阶段保留了KAT-V2.5验证过的四大技术支柱TITOToken-In-Token-Out一致性。推广阶段和训练阶段的token序列必须严格对齐聊天模板、序列化方式、分词器行为哪怕有一点差异都可能在RL训练中放大成灾难。TITO就是用来堵住这个漏洞的。TISTruncated Importance Sampling。异步rollout带来的策略陈旧和off-policy问题在分布式RL训练里几乎是通病。TIS通过截断重要性采样权重把过大的权重波动压下去减少方差和不稳定性。可靠的沙盒与验证器。基础设施层面的故障——执行超时、环境配置错误、验证器误判——如果一股脑儿当成模型错误来惩罚奖励信号就被污染了。团队系统性地检查了沙盒和验证器的稳定性确保只有真正的逻辑错误才会触发负向反馈。基于约束执行反馈的层级奖励。工具返回的执行反馈被细粒度地拆解成多层奖励信号。模型即使没一次性跑通也能在失败轨迹里获得有意义的进展奖励这让训练样本的利用率大幅提升奖励密度也更合理。不过把这套流程搬到Qwen3.6底座上时团队遇到了一个棘手的水土不服问题。初步实验里简单的二元0-1奖励在第二个epoch就让模型直接崩溃。分析训练轨迹后发现模型开始疯狂地在单回合内发起大量并行工具调用——有时候一次能飙到70次以上。这种病态行为导致上下文长度爆炸无效轨迹和执行错误堆积如山整个RL训练陷入震荡。为了把训练拉回正轨团队在原有层级奖励的基础上针对Qwen3.6的行为特点追加了几项专门惩罚单回合内过多的并行工具调用、工具调用失败、空的工具调用块以及大量重复内容。这些纠偏措施效果立竿见影RL训练得以稳定推进到10个epoch。从奖励曲线上看通过单元测试的样本比例随训练稳步上升验证了整体流程和针对性奖励设计的有效性。快速上手四大推理框架全覆盖API兼容OpenAI格式开源模型能不能真正用起来部署门槛是关键。Kwaipilot这次给出了相当完善的基建支持SGLang、vLLM、KTransformers、Hugging Face Transformers四种主流方案全部覆盖而且都提供了开箱即用的启动命令。SGLang是推荐方案之一建议版本不低于0.5.10。8卡GPU张量并行下可以轻松拉起支持262,144 token上下文长度的API服务。如果需要用工具调用功能只需在启动命令里追加--tool-call-parser qwen3_coder参数即可。需要留意的是这个开放权重版本只包含语言模型权重没有视觉塔。如果SGLang版本较老、启动时尝试构建多模态组件可能会因为缺少视觉权重而报错这时需要显式指定纯文本模式。vLLM作为高吞吐量推理引擎的代表推荐0.19.0以上版本。启动时必须带上--language-model-only标志告诉vLLM跳过视觉编码器和多模态解析否则会因为尝试加载不存在的视觉塔权重而失败。工具调用支持通过--enable-auto-tool-choice和--tool-call-parser qwen3_coder两个参数开启。KTransformers适合想在CPU-GPU异构环境下跑推理的用户具体配置可以参考官方部署指南。Hugging Face Transformers则是最轻量的方案适合快速测试和中小负载场景。安装transformers[serving]和accelerate后一条transformers serve命令就能在本地8000端口起服务有加速器的话会自动把模型放上去。API调用层面KAT-Coder-V2.5-Dev完全兼容OpenAI的Chat Completion格式。用Python SDK接入非常直观plainfrom openai import OpenAI client OpenAI() messages [{role: user, content: Type I love KAT-Coder-V2.5-Dev backwards}] chat_response client.chat.completions.create( modelKwaipilot/KAT-Coder-V2.5-Dev, messagesmessages, max_tokens81920, temperature1.0, top_p0.95, presence_penalty1.5, extra_body{top_k: 20}, )模型默认会进入先思考再回答的模式。如果希望跳过思考过程、直接拿到结果可以在extra_body里传入{chat_template_kwargs: {enable_thinking: False}}。另外KAT-Coder-V2.5-Dev还支持一个挺有意思的功能——保留历史思维链。通过设置preserve_thinkingTrue模型在处理新消息时会参考之前轮次留下的推理痕迹而不是每次都从零开始想。这在Agent场景里特别实用完整的推理上下文能提升决策一致性减少重复思考带来的token浪费还能优化KV缓存的利用率。超长上下文26万token原生支持YaRN可扩展至百万级上下文长度是代码大模型的另一块硬指标。KAT-Coder-V2.5-Dev原生支持262,144 token的上下文窗口对于绝大多数代码库分析、多文件重构任务来说已经绰绰有余。如果碰到更极端的长文本场景团队建议用YaRNYet another RoPE extension method做RoPE缩放。YaRN目前已经被Transformers、vLLM、KTransformers和SGLang等多个框架支持。启用方式有两种要么直接修改模型配置文件里的rope_parameters字段把rope_type改成yarn并设置factor: 4.0和original_max_position_embeddings: 262144要么在启动推理服务时通过命令行参数注入覆盖。vLLM用户可以用--hf-overrides传JSON配置SGLang和KTransformers用户则通过--json-model-override-args指定同时记得设置对应的环境变量来允许覆盖超长上下文限制。按这套配置上下文长度可以扩展到百万token级别足以应对超大规模代码仓库的全局分析。写在最后从KAT-Coder-Pro V1的73.4% SWE-Bench成绩到V2.5闭源版本的持续进化再到如今V2.5-Dev的开源开放Kwaipilot在AI编程这条赛道上走得越来越扎实。这次开源的35B MoE模型既是对社区的一次技术回馈也为国内代码大模型的生态添了一块重要拼图。对于开发者来说KAT-Coder-V2.5-Dev的价值在于可落地——它不是实验室里仅供观赏的分数而是配套了完整部署方案、API接口和超长上下文支持的工程化产物。3B激活参数意味着单卡或双卡就能跑起来中小企业和个人开发者完全负担得起。而在SWE-Bench、Terminal Bench、PinchBench等硬核基准上的全面领先又证明了它绝非缩水版而是真正具备顶尖竞争力的代码智能体。如果你正在寻找一款兼顾性能与成本、支持工具调用与多轮交互、且能无缝接入现有开发流程的开源代码大模型KAT-Coder-V2.5-Dev值得放进候选清单的前列。