今年七月，快手旗下AI研发团队Kwaipilot推出了闭源版本的KAT-Coder-V2.5，在开发者圈子里引发了不少讨论。没过多久，团队再次放出一个重磅消息——开放权重版本KAT-Coder-V2.5-Dev正式亮相。这款模型采用了当前大模型领域热门的MoE（Mixture 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.60，Claude 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验证过的四大技术支柱：
TITO（Token-In-Token-Out）一致性。推广阶段和训练阶段的token序列必须严格对齐，聊天模板、序列化方式、分词器行为哪怕有一点差异，都可能在RL训练中放大成灾难。TITO就是用来堵住这个漏洞的。
TIS（Truncated 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接入非常直观：
plain
from openai import OpenAI client = OpenAI() messages = [{"role": "user", "content": "Type 'I love KAT-Coder-V2.5-Dev' backwards"}] chat_response = client.chat.completions.create( model="Kwaipilot/KAT-Coder-V2.5-Dev", messages=messages, max_tokens=81920, temperature=1.0, top_p=0.95, presence_penalty=1.5, extra_body={"top_k": 20}, )模型默认会进入"先思考再回答"的模式。如果希望跳过思考过程、直接拿到结果，可以在extra_body里传入{"chat_template_kwargs": {"enable_thinking": False}}。另外，KAT-Coder-V2.5-Dev还支持一个挺有意思的功能——保留历史思维链。通过设置preserve_thinking=True，模型在处理新消息时会参考之前轮次留下的推理痕迹，而不是每次都从零开始想。这在Agent场景里特别实用：完整的推理上下文能提升决策一致性，减少重复思考带来的token浪费，还能优化KV缓存的利用率。
超长上下文：26万token原生支持，YaRN可扩展至百万级
上下文长度是代码大模型的另一块硬指标。KAT-Coder-V2.5-Dev原生支持262,144 token的上下文窗口，对于绝大多数代码库分析、多文件重构任务来说已经绰绰有余。如果碰到更极端的长文本场景，团队建议用YaRN（Yet 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值得放进候选清单的前列。
