刚刚，320B中国开源黑马杀出！模型自己抓Bug，凶手是一个空格

新智元报道

就在昨天凌晨，一个320B的开源大模型横空出世，权重连同blog，一口气全丢了出来。

这匹「黑马」叫IQuest-Q1。

九月这个赛道有多卷，你看看就知道了：月初GPT-6 Astra、Fable 5.1、Gemini 3.8 Flash连着三天扎堆发布，国产阵营Qwen3.8、GLM-5.3轮番上阵。

在这帮「卷王」里，一个名叫「至知」的团队突然交出了一张320B的开源答卷，而且一上来就在写代码库、挖安全漏洞和跑长程复杂任务这几类硬核评测上，跟不少头部模型同台过了招。

光看跑分不过瘾。

我们直接把它拉下场，干了几件实打实的活。

IQuest-Q1指挥下的早高峰全城俯瞰，6个路口的信号灯按节奏切换，车流沿东西干道成串通过

幽灵空格卡死训练

竟是模型自己「抓的虫」

先说一个印象最深的故事。

在研发团队的一次强化学习训练上，训练跑到一半，模型的得分曲线突然走平，再怎么练也不涨了。

诡异的是，系统既没报错，也没崩溃。屏幕上一切正常，但分数就是纹丝不动。

这种「哑巴bug」最让人头疼。它不哭不闹不摔碗，你甚至不知道它哪儿出了问题。

过去碰上这种事，只能靠工程师对着成堆的日志一行一行排查，通常要熬上好几个通宵。

这一次，排查没交给人，而是交给了IQuest-Q1自己。

它一头扎进训练日志、保存下来的对话记录和相关代码，从上到下翻了个遍。最后揪出的元凶小得让人想摔键盘——

只是一个多出来的空格。

怎么回事呢？这次训练用的是多轮对话，模型每答完一轮，系统要把回答原样拼回历史记录，然后再问下一轮。

问题出在中间环节：负责运行模型的推理服务在把输出转回文字时，悄悄多塞了一个空格进去。

就这么一个看不见摸不着的空格，把一场正常的训练搅得天翻地覆。

训练系统是逐字比对的。它发现拼回去的历史和模型原本写的差了一个字符，就把一段连贯的对话硬生生切成了好几截。

前几轮回答虽然还在对话里，却不再被算进训练。模型实际上只能从最后一轮学东西。

所以分数就这么不声不响地卡住了。整个训练框架看起来在跑，实际上大部分数据都是「摆设」。

找到病根之后，它关掉了那个多塞空格的设置，重新跑训练。平均得分从0.704涨到了0.769，后段进一步升到0.799——提升肉眼可见。

而这套原本要工程师熬夜几个通宵才能干完的活儿，从头到尾是模型自己完成的。

IQuest-Q1查完问题后自己做的分析页，第二页标出了那个多出来的空格，最后一页是修好后的得分曲线

顺着名字来查，IQuest-Q1背后，是一支名为至知创新研究院（IQuest Research）的中国团队。

在他们那儿，模型给自己查bug已是日常操作。

320B，稀疏MoE的魔法：干活高效

IQuest-Q1 干活很高效，模型架构和训练策略值得说说。

训练上，团队用了一招叫多教师在线策略蒸馏（MOPD）的技术。

简单说就是请来四位各有所长的「老师」模型，不是出一张标准答案让学生抄，而是盯着「学生」IQuest-Q1自己答题，直接在它的作业上批改。

这有什么好处？学生被按在自己的错题上反复练习，改掉的全是它真正会犯的错，而不是在一堆它已经会的题目上刷存在感。

最后再把几个阶段、几条训练路径上跑出来的模型合并到一起。

IQuest-Q1的训练流程，依次是预训练、中期训练、监督微调、强化学习加MOPD，最后把几个模型合并成一个

这样练出来的IQuest-Q1，在NL2Repo（只给一份白话需求，从零写出完整代码库）和CyberGym（在真实开源代码库里挖安全漏洞并复现）上成绩优异。

同时，在Terminal-Bench 2.1、DeepSWE v1.1以及面向专业办公场景的JobBench等复杂任务评测中，它也拿出了相当能打的表现。

早高峰6个路口交给它

救护车一路绿灯

榜单上的分数再好看，最后都得落到真活儿上验一验。

我们给它派的第一份差事，是管好一座小城的早高峰。

6个十字路口，早7点到9点车流往商务区涌，8点05分还有一辆救护车要横穿全城——这是一道有标准答案、有评分、没法糊弄的考试题。

作为对照，我们先让一套最常见的「傻瓜式」红绿灯方案跑了一遍：6个路口同时切灯，东西、南北方向各给30秒绿灯，不管哪边车多车少，一视同仁。

结果？早高峰一来，进城的主干道一路堵到了城外，跟节假日高速收费站似的。

同一批车、同一时刻，拉近到最繁忙的B3路口。上为固定配时（画面里标为「基线」），下为IQuest-Q1

IQuest-Q1给出的解法一点都不花哨，但聪明得很，它排了一条「绿波」。

它先测出车从一个路口开到下一个路口大约要18秒，于是让下一个路口的绿灯晚18秒再亮。这样车队刚好在绿灯亮起时开到下一个路口，一旦启动，就能一路绿灯开过去。

东西向打通了，南北向的车还在走走停停。怎么办？

6个路口排成上下两排，它又把下面一排路口的信号整体再推后18秒，从北往南开的车过完上一排，到下一排时也正好赶上绿灯。这一步让分数一下子好了一大截。

IQuest-Q1做交通题的工作记录，先做出东西向绿波，再把两排路口错开18秒

救护车那边更干脆。救护车开进哪一排，这一排路口就全切绿灯。等它过去，再切回绿波。简单粗暴，但有效。

镜头跟着救护车，同一时刻出发。上为固定配时，救护车还堵在红灯路口；下为IQuest-Q1，整排放绿，救护车一路开到终点

整道题它自己边跑分边改，做了54分钟。换上它从没见过的车流复测，全程零事故。

效果多明显？每辆车因为红灯和排队平均多等的时间，从6分钟压到了22秒。救护车更夸张——原来穿城得将近4分钟，现在1分钟出头。

双11仓库、下班电梯

死局被它一个个盘活

第二份活儿，我们把它扔进了一座电商仓库。

8台搬运机器人要把货从货架送到最左边的打包台。平日220单，双11爆单420单，还有一局会中途临时封掉一条通道。妥妥的地狱难度。

照例，我们先用一套最朴素的调度跑了一遍：哪台车空了就去接最早的那张订单，不管远近，只走最短路，也不看别的车。

开局没几分钟，8台车就在通道和打包台附近堵成了一坨，就像一群人挤地铁，谁也动不了。

IQuest-Q1接手之后，没有上来就写一套花里胡哨的算法，而是先搭起一版能跑的调度，然后逐台翻看运行记录，找车为什么会堵。

它把某一秒8台车的位置全打印出来一看，发现了第一个问题：两台车在两格宽的通道里迎面碰上时，谁也不让谁，直接撞了。

于是它定下规矩：迎面相遇时，必须有一台绕开。

撞车的问题解决了，可送出去的订单还是不多。它接着往下查，发现有车在打包台那一列卡了很久。原因是放完货的车就停在打包台上不走，后面排队送货的车全被堵死了。

于是它让空车主动离开，给后面的车腾地方。可让开的空车一开始又停在了打包台入口，还是挡路。它又改了一轮，才把这条路彻底理顺。

回头看，它在记录里写下了自己的判断：这道题丢分主要丢在堵死上，撞车反倒是次要的。这个判断，跟老仓管的直觉一模一样。

IQuest-Q1做仓管题的工作记录，它打印出8台车的位置，一步步找到堵死打包台的原因

换上它没见过的订单复测，8台车全程零撞车。平日局和封路局，订单全部送达。通道一被封，它就立刻调度车辆绕开封闭路段，继续送货。

中途临时封掉一条通道，红色是封闭路段，左边是朴素调度，右边是IQuest-Q1

双11那一局订单最多。420单已经超出了8台车在规定时间里能送完的极限，但它还是送出了87%。同样的订单，朴素调度只送出了几十单。一个天上一个地下。

双11爆单，左边是朴素调度，右边是IQuest-Q1，顶部卡片实时显示送达的单数

拉近看IQuest-Q1的仓库，机器人顶着纸箱在通道里互相让行，去左侧的打包台放货

写字楼电梯：24层4部梯

第三份活儿，是调度一栋24层写字楼的4部电梯。

规则很简单：一个人从按下按钮到进电梯超过60秒，或者在电梯里待了超过180秒，都算没准点。

对照方案还是最简单的派梯方式：哪部电梯空了就去接等得最久的那个人，一次只送一个人，路上也不顺路捎人。

结果呢？一到高峰，大堂就排起长队，跟网红奶茶店似的。

IQuest-Q1接手后，先自己写了分析脚本跑了一遍数据，然后发现了一个扎心的事实：早高峰时每趟电梯都塞满了13个人，电梯本身已经不够用了。

既然运力就这么多，硬件改不了，那就在软件上做文章。

它让空梯在大堂多等一会儿，等人满了或者等够时间再走，每一趟都尽量装满——宁可等一等，也别空着跑。

晚高峰大家都要下楼，它换了个策略：让电梯先开到最高一个有人按下行的楼层，再一路往下，顺路把各层的人接上，一趟接满。

可这样一来，电梯到低楼层时往往已经满了，低楼层的人一直挤不上去。它又给低楼层预留了位置，把这个「高楼层吃独食」的问题也给解了。

晚高峰同一批下班的人，左边是最简单的派梯方式，右边是IQuest-Q1，楼顶卡片实时显示准点率

换上没见过的客流复测，晚高峰准点率从26%提到61%，平峰从70%升到了88%。

一个HTML文件几千行

它把江南水乡搬进了浏览器

最后看看前端能力。

毕竟现在大模型写前端，已经是大家最爱卷的赛道之一了。

我们给它出了几道设计题，每道都只许用一个HTML文件，画面、贴图和音效全靠代码生成，图片和模型文件一概不能用。

它交出的作品多数都有两三千行代码。

「二十四节气水乡」是一幅会动的江南画卷。白墙黛瓦的马头墙民居沿河排开，节气一换，天色、草木和天气都跟着慢慢变。

「二十四节气水乡」，一年24个节气在同一幅画里流转，左上角大字标出当前节气

到了大雪，屋顶和马头墙积上了雪，入夜后家家户户亮起红灯笼——全是代码画的，不是贴图。

大雪时节，屋顶和马头墙积了雪，深蓝夜空下亮起红灯笼

「山海·墨舞」是一款《山海经》题材的水墨弹幕射击游戏。

宣纸底色上叠着几层水墨远山，玩家操控一只仙鹤，把毕方、九尾狐、鲲这些异兽一只只打成飞溅的墨点——光听这描述就觉得很中二，但玩起来确实带劲。

「山海·墨舞」的宣纸底色、水墨远山和朱红落日，仙鹤射出的箭羽击中妖兽后溅开墨点，右侧竖排计分和连斩

最后登场的Boss是烛龙。睁眼时放弹幕，闭眼时才打得动。背景音乐也是它用代码现场合成的五声音阶。打通关后盖上一枚朱印「胜」，仪式感拉满。

「烛龙将至」，Boss登场放出朱砂弹幕，通关后盖上一枚朱印「胜」

进化飞轮，才刚刚转起来

从路口的绿波、仓库的让行规矩，到一个个浏览器里的世界。你会发现它的干活路数始终一样：先把病根找出来，再动手改；改坏了就退回去，换个方向重来。

这不是什么高深的方法论，但能稳定地执行这套流程，本身就是一种能力。

一个320B的开源模型，已经能帮着查训练里的bug、写下一轮的训练方案——飞轮转起来了。

它转得快不快，下一代IQuest长什么样，老实说现在下结论还早。

但有一件事可以确定：当AI能真正开始做事，解决任务，价值由此显现。

模型权重已全面开源，链接在下面。

• GitHub：https://github.com/IQuestLab/IQuest-Q1

• Hugging Face：https://huggingface.co/IQuestLab/IQuest-Q1

• Blog：https://iquestlab.github.io/

编辑：所罗门 摩西