推理提速近3倍！Agent下场调引擎，两周反超人工精调

新智元报道 Coding 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共同完成计算。各张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路张量并行、单