至知创新研究院开源新方案：Agent调推理引擎两周反超人工

新智元报道

Agent 参与大模型推理，正在给推理系统带来新的性能压力。落到软件工程任务里，模型要反复读代码、写改动、调工具，再依据执行结果判断下一步怎么走。

这些环节大多有先后依赖，哪怕算力管够，每一轮 Token 生成时的等待也会一点点攒起来，拖慢整个任务。怎么让单条请求的生成过程一直跑得顺、跑得快，已经成了推理系统优化的一条重要赛道。

至知创新研究院（IQuest Research）近日发布并开源了 IQuest-Q1 的专用推理运行优化引擎 IQuestRT。官方技术报告给出的数据是：8 卡高性能 GPU、单请求条件下，IQuestRT 实测解码吞吐量 910.70 tokens/s，为 vLLM 参考配置的 2.94 倍。

支撑这一成绩的是几项底层改动：解码循环交给 GPU 自主控制，投机预测深度动态决定，可能用到的专家权重提前加载，跨 GPU 通信中的同步等待也做了削减。另一个细节是，AI Agent 同样参与了 IQuestRT 的底层研发——多个 Agent 并行做代码实现、性能实验和调试，相关优化成果只用了两周，就超过了团队此前人工精细调优过的计算流水线。

从模型生成速度到推理引擎的研发方式，IQuestRT 摆出了高性能推理系统正在摸索的两条技术路径。

IQuestRT 单请求解码吞吐量与 vLLM 参考配置对比

单请求推理

为什么要单独为它做优化？

过去衡量大模型推理性能，看的多是吞吐量、延迟这类指标。可碰上 Coding Agent 这样的应用，优化就得再往任务的执行方式上看一层。比如用户让模型改一个代码项目，模型可能先翻文件、弄明白问题，再写代码、调测试工具；测试没过，还得照着报错继续分析和修改。

整个过程中，模型生成的内容不断决定后面做什么。这种连续交互的任务里，每一轮生成快不快，直接关系到下一步操作什么时候能开始。

IQuestRT 服务的 IQuest-Q1 是至知创新研究院开源的基础模型，采用稀疏混合专家（MoE）架构，总参数约 320B，每个 Token 激活约 15B 参数，主要面向代码生成、软件工程、推理及多步工具调用等任务。推理时，IQuest-Q1 用递归多 Token 预测（MTP）机制：草稿网络反复运行，连续提出多个候选 Token，再由主模型统一验证，让一次计算产出更多有效 Token。

不过多 Token 预测也带来了新的工程麻烦。每轮生成都要做候选验证、采样、缓存更新和后续预测，还牵扯大量 GPU 计算任务的启动、模型权重读取与跨卡数据交换。这些操作单次可能只花几十微秒，却会在连续生成中一遍遍出现。

于是，在单请求、小批量场景下，怎么减少调度、同步和数据搬运带来的等待，就成了影响性能的关键。

IQuestRT 的做法，是盯着 IQuest-Q1 的具体计算结构，把整个投机解码过程系统性地优化一遍。

让 GPU 自己发起下一轮计算

IQuestRT 先动的是 GPU 与 CPU 之间的执行关系。在部分常规推理实现里，GPU 算完一轮，得由 CPU 读结果、更新状态，再发起下一轮任务，这期间 GPU 可能一直等着主机把活干完。

IQuestRT把更多控制逻辑搬到了GPU上。

候选Token验证、采样、缓存更新，以及下一轮计算的启动，这些环节都能在GPU内部跑完。CPU只负责发起第一轮任务，等整个生成过程收尾，再去读结果。

连续解码过程中反复出现的主机控制间隔，就这样被压短了。

技术报告里的配对重放实验显示，把主机端控制间隔去掉之后，每轮计算省下约22—25微秒；后来继续精简执行边界，又多出约3微秒的收益。

传统CPU控制循环与IQuestRT GPU自主解码循环的对比

GPU自主控制这套思路，也被用到了投机解码上。

提前多提一些候选Token，主模型就有机会一次验证并接受更多内容。可额外预测本身也要花计算。要是后续候选的预期收益不够，接着生成反倒可能拖长耗时。

于是IQuestRT设计了动态投机深度策略。

每轮计算先固定跑前三个预测深度，后面由GPU看着已生成的候选Token及其概率、熵等信息，判断继续预测值不值得多花计算成本。

整个流程最多生成七个候选Token。

按这个设计，系统能结合当前生成状态决定预测深度，收益不够就停下额外计算。

从削减CPU参与，到动态决定下一步算什么，IQuestRT想让GPU在连续解码时掌握更完整的执行控制权。

从MoE专家权重到跨卡通信

等待还能继续压

除了GPU调度，IQuestRT还对MoE模型的专家路由和参数读取做了深入优化。

MoE模型会依据输入动态挑选参与计算的专家。小批量推理时，等专家权重从显存加载到计算所需的位置，开销可能不小。

IQuestRT用的是一种提前预取策略：正式路由结果还没出来，先预测哪些专家可能被调用，把它们的权重加载进GPU的L2缓存。

等后面的计算真需要这些权重时，部分数据已经就位。

不过，提前预取也要占用计算资源。

团队实验发现，在滑动窗口注意力层中，有效验证位置为四至五个时，预取能带来收益；位置增加到六至八个时，预取的成本就超过了收益。

所以IQuestRT只在合适的计算路径里开启预取。

另外，预测结果只决定哪些权重被提前放进缓存，真正参与计算的专家仍由模型的正式路由结果说了算。

还有一个优化方向，是减少独立GPU Kernel的启动次数。

研究团队把原本单独执行的专家路由计算，融进了注意力相关的既有计算流程。初版路由融合方案在轨迹重放测试中，每轮计算省下88.5微秒。

跨GPU通信这块，同样有可挖的余量。IQuest-Q1跑在8路张量并行环境里，计算要靠多张GPU一起完成，各卡之间既得互换数据，也得确认别的设备有没有把结果写进去。

针对这一点，IQuestRT想出的是用NaN标记来做同步与归约。NaN是浮点运算里一个特殊的数值标记，系统的做法是先把输出缓冲区填满NaN，等各张GPU算完，再用真实数据把这些位置盖掉。

只要跨GPU归约的结果里还留着NaN，就说明至少有一部分数据没写进来；等到结果里再也找不到NaN，系统就能接着处理已经就绪的数据。数据就绪判断和结果归约合成了一件事，额外的同步操作因此少了一截。

IQuestRT这套基于NaN标记的跨GPU数据同步与归约机制，正落在上述思路上。

这些改进盯的都是推理过程中反复出现的环节：计算调度、数据加载、通信。单看一项，可能只省下几十微秒，可执行轮次一多、模型层数一叠，收益就会累积起来，最终影响整体生成速度。

当然，计算路径一变，浮点数值结果也可能跟着变。技术报告讲得很明白：部分路由融合操作采用的数值计算方式与原实现不同；FP8激活和归约顺序变化带来的影响，还得拿更高精度的参考实现单独验证。

这其实是推理系统底层优化绕不开的一道坎：算得快的同时，数值变化、Token接受行为和最终生成结果都得盯着。

910.70 tokens/s这个数字，是怎么测出来的？

按官方技术报告的说法，IQuestRT的主要性能测试跑了400条Claude Code运行轨迹，并在两个随机种子下完成800次解码测试。

采样参数用的是IQuest-Q1推荐的那套：temperature=1、top-k=20、top-p=0.95。

在8卡高性能GPU、8路张量并行、单请求的条件下，IQuestRT的解码吞吐量做到910.70 tokens/s。

再往下拆：平均每轮投机解码输出3.24个有效Token，一轮耗时约3.558毫秒，摊到每个输出Token上约1.098毫秒。

团队记录的vLLM参考配置吞吐量为309.83 tokens/s。两相比较，IQuestRT在这组测试里的解码吞吐量是它的2.94倍。

不过要说明，对照双方用的投机策略并不一样：vLLM参考配置固定五候选，IQuestRT则是在三到七个候选之间动态选。这个结果反映的是特定软硬件与推理策略组合下的整体性能差距。

技术报告还给了另一项长上下文单步计算测试。

在固定五候选、使用合成KV缓存的独立测试中，上下文长度从1K加到192K，中位单步延迟由3.23毫秒升到3.76毫秒，涨了约16%。

这项测试跟前面400条运行轨迹的测法不是一回事，它反映的是指定计算条件下单步延迟的变化。

另外，910.70 tokens/s量的是Decode阶段性能，候选验证、采样、递归预测和缓存处理这些操作都算在里面，Prefill、模型加载及计算图捕获等开销则没有计入。

所以，单请求解码吞吐量还得跟完整任务耗时、多请求并发服务吞吐量分开来看。

不过，对要连续产出代码、工具指令和推理内容的智能体应用来说，把单请求生成阶段的等待时间压下来，依然有直接的技术意义。

AI Agent参与底层研发

两周超过人工调优流水线

IQuestRT还有一处值得看的地方：它的研发过程里有AI Agent参与。

GPU高性能计算的优化，往往要靠大量细碎的工程活。

工程师得反复分析计算瓶颈，改Kernel实现、数据布局、同步方式和任务调度策略，再跑测试确认改动有没有用。

有些优化即便单测能拿到收益，进了完整推理流程也可能因为多出来的调度或数据处理开销而丢掉优势。

于是研究团队搭了一套工程师与AI Agent共同参与的优化流程。

工程师负责定义工作负载、数值约束与验收标准，并拍板哪些修改最终能合入代码。AI Agent则参与读代码、提优化假设、实现方案、跑实验、调试和代码审查。

每项实验都留下对应的代码版本、测试环境和原始结果，方便后面做对比与复现。

这个过程里，实际运行轨迹也帮团队发现了合成测试容易盖住的问题。

比如一次性能分析中，KV缓存读取长度相同，实际请求的单轮解码还是比合成测试慢了约0.36毫秒。

问题主要出在MoE模型的专家访问上。

实际请求平均每层要访问37.7个不同专家，合成输入只有11.0个。不同专家越多，权重读取就越多，缓存复用效率也跟着下降。

这个发现让团队改了实验方法：凡是可能影响专家权重访问的优化，都得回到实际运行轨迹里验证性能收益。

自动化实验也会跑出失败的方案。

比如团队试过把专家权重再压到FP4，想减少参数读取开销。测试下来，额外的数据解包与计算调度成本把权重存储减少带来的收益抵消掉了，最终没有采用。

整个IQuestRT研发历程记录了32个优化检查点。

从工程师写的初始实现，到后面的计算融合、通信优化、动态投机解码及GPU自主循环等改进，记录里的单步延迟由6.449毫秒降至3.526毫秒，累计下降约45.3%。

这组数据呈现的是整个系统的优化历程，与前述vLLM参考配置的对照属于不同测试。

IQuestRT研发过程中的32个优化检查点及单步延迟变化

研发方法上，团队摸索了一个多月，逐步建立起由Agent参与的自动化优化与验证流程。

IQuest-Q1发布后，多个AI Agent在多台GPU服务器上并行做单请求推理优化。

这份技术报告提到，团队此前对Tile Pipeline（分块计算流水线）做过人工精细调优，而相关优化成果只花两周，性能就超过了它。

这次结果还说明，AI Agent确实能插手复杂底层系统的研发。目标怎么定、正确性怎么约束、最终谁来把关，还是工程师的事；Agent则能同时铺开更多代码探索和实验验证。

这些活儿一旦攒成可复用的工具和流程，针对某个具体模型做高性能推理引擎，工程成本也有望再降一截。

专用推理引擎

走向开源

IQuestRT目前已在GitHub公开代码，许可证为Apache-2.0，安装、运行和性能测试的说明都一并给出。不过它眼下有清楚的适用边界。

项目公开文档写明，IQuestRT是为IQuest-Q1以及特定GPU计算架构和互连环境设计的，要求8路张量并行、单个活动请求，其他模型、GPU架构和并行配置暂时都不支持。

换句话说，910.70 tokens/s和2.94倍这两个数，得放回对应的测试环境里看。

Coding Agent这类应用开始接手越来越复杂、连续的任务，推理优化也就往具体模型结构和真实工作负载里钻得更深。GPU执行调度、投机深度怎么选、MoE专家权重怎么读、跨卡通信，这些底层环节的优化会一起影响一次请求的生成效率。

AI Agent下场做底层性能优化，也给高性能计算软件的研发添了一条新的探索路子。

专用推理引擎的性能优化要是和自动化研发流程接上，以后给不同模型搭高效推理系统，能试的工程路径或许会更多。

参考资料：

技术报告：https://iquestlab.github.io/IQuestRT/

开源代码：https://github.com/IQuestLab/IQuestRT