是什么：320B稀疏MoE开源黑马
IQuest-Q1是由至知创新研究院（IQuest Research）推出的一款开源大模型，参数量为320B。它采用稀疏MoE（Mixture of Experts，混合专家）架构，这意味着模型虽然总参数量大，但每次推理只会激活其中一部分专家网络，从而兼顾大规模知识容量与较高的运行效率。模型权重、博客和技术说明同步发布，属于真正意义上的开源而非仅开放API。
关键能力与原理：从训练策略到任务执行
多教师在线策略蒸馏
IQuest-Q1的核心训练方法被命名为多教师在线策略蒸馏（Multi-teacher Online Policy Distillation，简称MOPD）。其思路不是让多个教师模型给出标准答案让学生模仿，而是让多个教师同时监督学生模型自身的输出，直接在学生的答题结果上批改。这种做法的逻辑是：学生被反复按在自己的错题上练习，改掉的全是真正会犯的错误，避免在已经掌握的题目上空转。训练完成后再将多个阶段的模型合并，最终输出一个统一的模型。
完整训练流程为：预训练 → 中期训练 → 监督微调 → 强化学习 + MOPD → 多模型合并。这套流水线让模型在NL2Repo（从自然语言需求生成完整代码库）、CyberGym（在真实开源代码库中挖掘并复现安全漏洞）、Terminal-Bench 2.1、DeepSWE v1.1以及面向专业办公场景的JobBench等多项复杂任务评测中均拿出了较强的成绩。
自己抓Bug的能力
IQuest-Q1最令人印象深刻的能力之一是能够反向排查自己的训练故障。在一次强化学习训练中，模型得分曲线突然走平且系统不报错，工程师没有熬夜排查，而是把日志和对话记录交给IQuest-Q1自己分析。它从训练记录中揪出了一个不起眼的元凶：推理服务在将模型输出转回文本时多塞了一个空格，导致多轮对话历史被逐字比对时切碎，前几轮回答实际上并未被纳入训练。找到病根后，关闭多余空格设置，平均得分从0.704升至0.769，后段进一步升至0.799。从查问题到给出修改方案，整个过程由模型独立完成。
复杂任务的执行路数
在多项实测任务中，IQuest-Q1展现出稳定的工作模式：先把病根找出来，再动手改；改坏了就退回，换个方向重来。这种看似朴素的方法论，被它稳定地执行在交通调度、仓库调度、电梯调度和前端生成等差异极大的任务上。
实测表现：从路口绿波到浏览器里的水乡
早高峰6路口交通调度
给定一座小城6个十字路口的早高峰场景，要求在7:00到9:00之间疏导进城车流，并在8:05放行一辆横穿全城的救护车。作为对照的固定配时方案在早高峰将进城主干道堵成长龙。IQuest-Q1测出相邻路口车流耗时约18秒后，先排出东西向绿波带，再将两排路口整体错开18秒实现南北向绿波。救护车经过某一排路口时，该排全切绿灯，过后再切回绿波。最终每辆车平均等待时间从6分钟压到22秒，救护车穿城时间从近4分钟缩短到1分钟出头，复测全程零事故。
双11仓库机器人调度
在一座拥有8台搬运机器人的电商仓库中，平日220单，双11爆单420单，且会中途封掉一条通道。朴素调度方案在通道里频繁撞车并在打包台堵死。IQuest-Q1先逐台翻看运行记录发现问题：双向两格通道迎面相遇导致互不相让；空车停在打包台不走挡住后面车辆；空车让开后停在打包台入口仍挡路。它逐一设规则解决撞车与堵死问题。复测时8台车全程零撞车，平日与封路局订单全部送达，双11爆单局送达率达87%。
24层写字楼电梯调度
在一栋24层、4部电梯的写字楼里，晚高峰准点率从对照方案的26%提升至61%，平峰从70%提升至88%。它的核心判断是硬件运力已达上限，因此转向软件策略：早高峰让空梯在大堂等到满员再走，晚高峰让电梯先到最高有下行需求的楼层再一路往下顺路接人，并给低楼层预留位置以避免被高楼层挤占。
前端生成
在前端任务中，IQuest-Q1被要求用单个HTML文件、纯代码（不允许使用图片或模型文件）完成设计题。它交出的作品多在两三千行代码规模，包括一幅随二十四节气变化而流转的江南水乡画卷（白墙黛瓦马头墙、大雪积落、夜晚红灯笼皆由代码绘制），以及一款名为《山海经》的水墨弹幕射击游戏（仙鹤射杀毕方/九尾狐/鲲等异兽、烛龙Boss睁眼放弹幕闭眼受击、背景音乐由代码现场合成五声音阶）。
和上一代的差异
材料中并未直接给出与同团队上一代模型的横向对比数据，但可以从两个维度观察其代际变化：一是模型规模跃升至320B且采用稀疏MoE架构，相比稠密小模型在容量和推理效率之间取得更优折衷；二是训练方法从常见的单一监督微调或离线蒸馏，转向MOPD在线策略蒸馏，强调让学生在自己错题上反复练习，避免在已掌握数据上空转；三是任务能力从单纯的对话与问答，向长程复杂任务（代码库生成、漏洞挖掘、城市调度）以及自调试能力扩展。
适用场景
根据实测表现，IQuest-Q1相对适合以下几类任务：
- 长程复杂任务：需要拆解、试错、回退的多步骤问题，例如代码库生成、自动化调试、跨工具调度。
- 真实环境决策：在规则清晰、有可量化目标的小规模仿真场景中（交通、仓储、电梯等），能够基于运行记录自行诊断瓶颈。
- 安全与漏洞研究：在CyberGym类评测中能针对真实开源代码库挖掘并复现漏洞。
- 前端可视化：单文件HTML纯代码生成复杂视觉与交互内容。
如何用起来
IQuest-Q1的权重、技术博客已全面开源。可在Hugging Face上获取模型权重并加载推理，在GitHub仓库获取示例代码与文档，团队博客上查阅技术说明。对于显存充足（建议多卡高带宽环境，如多张80GB级别GPU）的部署者，可按照Hugging Face官方文档使用标准推理框架加载；对于资源受限的研究者，可关注社区后续发布的量化版本。由于模型总参数量大且为稀疏MoE，部署与微调都需要相应的工程投入，普通开发者更适合通过API或托管服务进行调用，材料中暂未披露统一的公共推理API。
局限与边界
需要客观地指出以下几点边界，避免过度外推：
- 评测与实测多在受控仿真场景中完成，如6路口小城交通、双11仓库仿真、24层电梯仿真等，迁移到真实城市级别的复杂路网、真实仓库硬件与真实电梯群仍需额外验证。
- 实测中设置的对照方案是较朴素的固定配时或最简单调度，并不代表与业界成熟的最优运筹学算法（如强化学习调度器、工业级交通信号控制系统）做过严格对比。
- 双11爆单局虽送达率达87%，但同时被指出420单已超出8台车在规定时间内能送完的物理极限，意味着模型无法突破任务给出的硬件与时间硬上限，只能在规则内最大化效率。
- 自我抓Bug的能力目前是在团队自有的训练日志与对话记录上验证的，对于未见过的、跨系统的复杂故障，其泛化能力尚需更多案例支持。
- 在材料展示的任务中，模型均给出了详尽的可解释工作记录，但对于决策黑箱风险、误操作后果承担等现实问题，仍需要人来兜底。
材料中明确表示，IQuest-Q1的飞轮刚刚开始转动，对其下一代产品形态与能力演进下结论为时尚早，但可以确定的是，当AI能够真正落地解决任务，价值便开始具象化。