320B MoE 开源：IQuest-Q1 重构智能体编码

320B MoE 开源：IQuest-Q1 重构智能体编码

2026 年 9 月，IQuest Research 开源了 IQuest-Q1------一个 3200 亿参数（每 token 仅激活 150 亿）的稀疏 MoE 模型，上下文窗口拉到 52.4 万 token，专门面向代码、软件工程和长链路智能体任务。它不是又一个聊天模型，而是一套「能在命令行里自己读代码、跑工具、看结果、从报错里爬出来」的编码智能体基座。下面把它的架构、训练、真实表现和落地门槛一次说清。

目录

• 一、概念澄清：它是编码智能体基座，不是聊天框
• [二、它解决的真问题：让编码 Agent 跑得动、跑得久](#二、它解决的真问题：让编码 Agent 跑得动、跑得久)
• 三、架构与训练机制拆解
• [四、事实 / 推断 / 未知：把三层分开看](#四、事实 / 推断 / 未知：把三层分开看)
• 五、怎么用：开源权重与本地复现两条路
• 六、冷静视角：边界与保留意见
• 总结

一、概念澄清：它是编码智能体基座，不是聊天框

先划清几个容易混的概念，免得把它当成「又一个大模型」一掠而过。

IQuest-Q1 是一个稀疏 MoE 基座模型：总参数约 320B，每处理一个 token 只激活 15B，专家总数 256、每次激活 8 个。上下文窗口 52.4 万 token。它的设计目标是 CLI 智能体场景------在命令行里完成「读代码库、调工具、看反馈、从错误里恢复」这类多步任务，而不是陪你聊天或写营销文案。

它和三类东西都不同。第一，和通用聊天模型（Claude、GPT 这类）不同，Q1 的数据和训练明显向代码、STEM 与智能体轨迹倾斜，通用对话不是它的主战场。第二，和「自主智能体产品」（比如一些厂商推出的「会自己写代码的交付型 Agent」）不同，Q1 是底座模型，不是成品 Agent------它提供能力，怎么编排工具、怎么管上下文，交给上层的 harness（如 Claude Code、Codex）或你自己的系统。第三，和前代 IQuest-Coder-V1（2026 年 1 月开源的 7B~40B 代码模型）不同，Q1 把参数规模、上下文长度和训练范式都抬到了「智能体基座」的层级。

把 IQuest 这九个月的研究线连起来看，路线相当连续：年初开源代码模型，九月开源 320B 智能体基座，训练从 Code-Flow 转向多 harness 强化学习。

（图三：IQuest 从代码模型到智能体基座的两次开源脉络）

一句话记住它的位置：如果说聊天模型是「会说话的百科全书」，那 Q1 更像「一个能自己操作终端的初级工程师」，专长在代码与长链路任务。

谁该盯它？如果你是维护内部 Agent 平台、做代码助手、跑长链路重构或终端自动化的工程师，Q1 直接和你相关；如果你是做纯对话、内容生成或视觉多模态的，它的提升对你几乎无感。开源权重还意味着你可以私有化部署，把代码和训练数据留在自己机房，这对有合规要求的金融、政企场景是硬需求，不是锦上添花。

二、它解决的真问题：让编码 Agent 跑得动、跑得久

为什么要把一个编码模型做到 320B 还只激活 15B、还塞进 52.4 万上下文？这背后是长链路编码 Agent 的三个硬约束。

第一，装得下整个工程。 真实重构任务往往要同时理解几十个文件的依赖关系，128K 上下文装一个中大型仓库都吃力，更别说带历史对话和工具输出。524K 上下文让模型可以一口气吃进大段代码库或长文档做 RAG，不必频繁切块。

第二，每一步都便宜。 编码 Agent 一轮对话要跑几十上百步工具调用，每步都过一遍模型。稠密 320B 模型每步成本太高，根本跑不起长任务；稀疏激活把每步计算压到 15B 量级，等于「用 15B 的算力花销，换 320B 的知识容量」。

第三，多步不断链。 智能体最难的不是单步答对，而是「调用工具 → 读反馈 → 纠错 → 再调用」的循环里不跑偏。Q1 在合成环境里用多 harness 强化学习专门练这个，而不是只在静态代码快照上做补全。

这也是为什么评估它要看 DeepSWE、Terminal-Bench、NL2Repo 这类「仓库级、长链路、要真跑」的基准，而不是单轮代码补全------它的价值恰好落在「又长又乱、跨文件、要反复调工具」的那类活。

举个具体场景：把一个 20 万行、跨三十个模块的旧服务从某框架迁移到新版本，需要读全仓依赖、改一批接口、跑测试、根据报错回修。稠密小模型往往读到后半段就忘了前半段的约束，而 524K 上下文加长链路训练让 Q1 更可能把整条链路攥在手里一次跑完。当然，这是「更可能」，不是「保证」------具体体感仍要拿你自己的仓库测。

三、架构与训练机制拆解

这一节把技术细节拆开，方便做选型的人判断它到底「新」在哪。

MoE 结构。 320B 总参数、15B 激活，256 个专家里每次选 8 个。稀疏激活是它「大容量 + 低成本」的根本来源，也是和稠密模型拉开性价比的关键。

注意力混合设计。 Q1 用了「3 个滑动窗口 + 1 个全量」的混合注意力，共 88 层，但只有 25 层会随上下文变长而增长 KV cache。这是个很务实的工程取舍：长上下文最烧显存的就是 KV cache，让大部分层用滑动窗口、只让少数层保留全局视野，既控住了显存，又没丢掉长程依赖。配套的还有 attention 后端的 sink 路径（sink attention），进一步稳住长序列。

加速生成。 它带一个递归的多 token 预测（MTP）头，配合 EAGLE 投机解码、用概率化草稿采样来 draft，能在不牺牲质量的前提下把生成速度拉起来。推理侧这些设计，是它在 vLLM 上能做到「发布当天就能跑」的前提。

这里有个工程常识值得点破：很多大模型「开源」但推理框架要等几周才跟上，等于发布即不可用。Q1 把混合 KV 协调器、sink attention、EAGLE 草稿头都做成了 vLLM 既有组件的组合，而不是新算子，意味着社区不用改内核就能接住------这比参数漂亮更能决定它能不能真的被用起来。

训练：多 harness 强化学习。 Q1 不是在一个固定环境里做 RL，而是让同一个策略跨多个 harness 训练，每个 harness 保留自己的工具和上下文管理方式------等于把「在真实智能体系统里干活」本身当成学习任务。一个细节值得记：训练时失败的归因放在优化之前，只有策略自身的错误才成为学习信号，避免把环境噪声误当成模型问题。

MOPD 四专家蒸馏。 RL 阶段产出四个专家（智能体用户体验、多 harness 协作、长链路任务、通用智能体工作），再用多教师同策略蒸馏（MOPD）合并成一个学生模型，从 SFT 检查点初始化，在自身轨迹上学习、由匹配专家给每个 token 打分。最后用跨阶段与跨专家分支的模型合并把各路检查点折回 Q1。

为什么不直接训一个大模型、而要先出四个专家再蒸馏？原因是不同智能体能力（用户体验、多 harness、长链路、通用）在 RL 阶段容易互相拖累，分开训能让每个能力充分收敛，再用 MOPD 把优点汇到一个模型里。这相当于把「一个模型学所有」拆成「几个专家各学一样、最后合体」，工程上更可控，也方便定位哪块能力没训好。

自改进研发闭环。 这是 Q1 最特别的卖点：模型在研发阶段就参与了自身的迭代------它提出的方案经人类研究者拍板后，验证过的更新、训练资产和研究流程会回流进下一轮，被后续版本接着用；每一轮攒下的数据流、训练配置、评估方法和工具，也沉淀成可复用的研发资产。换句话说，它的「训练工艺」本身也在被模型辅助打磨。

这种闭环的直观好处是研发资产可复用：每一轮训练沉淀下来的数据流程、配置、评估脚本都变成下一版的起点，团队不用每次从零搭实验台。代价是它对工程纪律要求极高------一旦某轮把错误的「自我改进」结论写进了资产库，错误会被后续版本继承，所以人类拍板环节不能省。

（图二：从 2026 年 1 月的 Coder-V1 到 9 月的 Q1，IQuest 用九个月把代码模型升级为 320B 智能体基座）

四、事实 / 推断 / 未知：把三层分开看

资讯里最怕把厂商说法、自己推测、没搞清的事搅成一锅。这一节分层列。

已确认的事实（来自 IQuest Lab 技术报告）

• 模型规格：320B 总参数 / 15B 激活 / 256 专家 / 8 激活，上下文 524,288 token，开源权重、技术报告、HuggingFace 与 GitHub 均已放出。
• 推理基建：vLLM 发布当天即支持，靠既有组件实现混合 KV 协调器、sink attention 路径与 EAGLE 投机解码，无需等社区补丁。
• 官方基准（同批对比里 Q1 均居首）：DeepSWE v1.1 74.2 （次席 DeepSeek-V4.1-Flash 73.7）、NL2Repo 75.3 （次席 Claude Opus 5 63.0）、CyberGym 88.1 （次席 DeepSeek-V4.1-Flash / GLM-5.3 84.5）、Terminal-Bench 2.1 89.1 （次席 Claude Opus 5 85.4）、JobBench 65.7（次席 Claude Opus 5 61.4）。
• 更通用的智能体基准：Agents' Last Exam 32.2、Humanity's Last Exam 43.4、自家的 IQuest-CLIBench（CLI 用户体验）58.5（次席 GPT-5.6 Sol 58.2）。
• 复现口径：温度 1.0、top-p 0.95、top-k 20，harness 用 Claude Code 2.1.140 或 Codex 0.142；CyberGym 限 6 小时、Terminal-Bench 2.1 限 8 小时；因暂无多模态，评测时把多模态输入替换为占位符。

（图一：Q1 在四项编码 / 智能体基准上的厂商自测得分，均为同批对比第一）

我的推断

• 它的优势集中在「仓库级、长链路、要真跑」的任务，而不是单轮问答。524K 上下文 + 稀疏激活 + 偏 Agent 的训练数据，三者叠加刚好打在长链路编码的痛点上；单轮聊天或纯文本推理不是它的主秀场。
• 「自改进研发闭环」大概率让它的迭代速度比传统「人写训练脚本、模型只当产物」的团队更快------这是组织层面的杠杆，比单次跑分更值得长期关注。
• 在长上下文下只有 25 层增长 KV，说明它的显存曲线比「全层全量注意力」的同类长上下文模型更平缓，同等硬件能撑更长的会话。

再补一句关于定位的判断：Q1 和同档的 DeepSeek-V4 系列、GLM-5.3、Claude Opus 5 不是零和关系。开源加可私有化是它的差异化，闭源旗舰在通用推理与多模态上仍有阵地；对多数企业，更现实的用法是「闭源旗舰做难推理、开源 Q1 做高频编码 Agent」，而不是二选一。

还有一点关于成本的判断：稀疏激活的省钱效应在「高频、长链路」场景才会充分显现。一个每天跑几千次、每次几十步工具调用的编码 Agent，15B 激活相比稠密 70B+ 模型，单月推理账单可能差出一个数量级------这正是 Q1 对企业最实在的吸引力，比单次跑分更该被算进总拥有成本。

目前未知

• 上述基准都是厂商自测，且对比对象用的是各家公开或官方分数，口径不完全一致；独立机构重跑后的绝对水位待验证。
• 暂无多模态能力，涉及图像 / 视觉输入的场景要先做占位或外接视觉模型。
• 320B 权重的部署显存门槛仍高，单机友好版本（量化 / 小激活变体）是否后续放出未知。
• 精确的开源协议以仓库 LICENSE 为准（IQuest 系列此前采用带署名条款的修改版 MIT），商用前需确认。

五、怎么用：开源权重与本地复现两条路

Q1 既然权重已放出，就有「现在就能跑」的入口，不用等候补。

路径一：vLLM 直接拉起推理

官方已合入混合 KV 协调器、sink attention 与 EAGLE 草稿头，发布当天即可服务。最小可运行示例（仓库名以 HuggingFace 实际为准）：

# 需要 vLLM 已支持 IQuest-Q1 的混合 KV 协调器与 EAGLE 草稿头
vllm serve IQuestLab/IQuest-Q1 \
  --tensor-parallel-size 8 \
  --max-model-len 524288 \
  --enable-prefix-caching

注意 524K 上下文加上 320B 权重，单卡远远不够，生产部署按 8 卡起步规划；个人开发者建议等社区量化版（如 FP8 / 低比特）再在单机上试。

路径二：接 harness 复现官方基准

想验证它在编码智能体上的真实水平，最干净的做法是把它接到 Claude Code 或 Codex 这类 harness 上，按官方口径跑 Terminal-Bench 2.1 等任务：

# 复现官方基准的简化示意（以 Claude Code 作为 harness）
claude --model IQuestLab/IQuest-Q1 \
  --terminal-bench-2.1 \
  --temperature 1.0 --top-p 0.95 --top-k 20 \
  --max-steps 500 --timeout 8h

这套「开源基座 + 现成 harness」的组合，对已经在用 Agent 框架的团队最友好：你不用自己造运行时，只要把模型名换掉就能横向对比。

怎么判断要不要上 Q1？给你一条简单标准：如果你的编码任务平均单轮就要上万 token 上下文、且每天跑成百上千次工具调用，它的长上下文与稀疏激活能实打实省钱省时；如果你的任务多是单文件小改、偶尔跑一次，7B~40B 级的小模型反而更划算，不必为 320B 的权重买单。

六、冷静视角：边界与保留意见

这是资讯和公关稿的分水岭，至少四点要摊开讲。

第一，跑分是厂商自测。Q1 在四项编码基准上都是同批第一，但对手分数多半取自公开或官方发布值，评测 harness 和采样设置未必统一。把它当成「显著领先」的方向性信号可以，当成「代际领先」的证据则还早，等独立重跑。尤其 JobBench（办公场景）Q1 是 65.7，和 Claude Opus 5 的 61.4 差距并不大，说明它在「非代码」的通用 Agent 任务上优势收窄，别被编码榜的领先误判成全面领先。

第二，部署门槛不低。每 token 只激活 15B 不等于「小显存就能跑」------320B 的权重本身就要多卡加载，长上下文还会放大 KV 占用。它的省，省在每一步的计算，不省在落盘的权重体积。单机玩家先别急着上，等量化版。另外，524K 上下文是「能设」不是「该设」------把上下文开满会显著拉高 KV 占用和首 token 延迟，实际部署时按任务长度动态收缩往往更稳。

第三，协议要自己看。IQuest 系列此前用带署名条款的修改版 MIT（商用产品界面需标注 IQuest Coder），Q1 大概率沿用类似宽松但有署名要求的协议。准备商用的，先把仓库 LICENSE 读一遍，别默认等同 Apache 2.0。

第四，自改进闭环是双刃剑。模型参与自身研发能加速迭代，但「模型参与自身迭代」的长期可控性、评估偏差会不会被自我强化，目前没有足够长时间的外部观察。把它当效率工具欢迎，把它当无需审查的研发主体则言之尚早。

总结

IQuest-Q1 的价值不在「又大了一点」，而在它把开源编码模型从「代码补全」推到了「智能体基座」：320B 容量、15B 激活、524K 上下文，加上长上下文下仅 25 层增长 KV 的务实注意力设计，以及让模型参与自身迭代的研发闭环。对做编码 Agent、长链路重构、终端自动化的团队，它是 2026 年下半年最值得接入对比的开源选项之一。

落地建议只有一条：先用 vLLM 或现成 harness 拉起来，拿你自己的真实仓库级任务跑一遍，盯着 DeepSWE / Terminal-Bench 这类「要真跑」的基准看绝对水位，而不是只看厂商榜首。最后提醒，部署前先确认显存规划与开源协议------这两件事，比追分更重要。