推理提速近3倍

新智元报道 Coding Agent正在让大模型推理面临新的性能挑战。 近日，至知创新研究院发布并开源了面向IQuest-Q1的专用推理运行优化引擎 IQuestRT。 根据官方公布的技术报告，在8卡高性能GPU、单请求条件下，IQuestRT实现了 910.70 tokens/s的实测解码吞吐量，达到vLLM参考配置的2.94倍。 这一性能来自多项底层优化：GPU自主控制解码循环，动态决定投机预测深度，提前加载可能用到的专家权重，并减少跨GPU通信中的同步等待。

还有一个值得关注的细节：AI Agent也参与了IQuestRT的底层研发。 多个Agent并行开展代码实现、性能实验和调试，相关优化成果仅用两周就超过了团队此前经过人工精细调优的计算流水线。 IQuestRT所服务的IQuest-Q1，是至知创新研究院开源的基础模型。 它采用稀疏混合专家（MoE）架构，总参数约320B，每个Token激活约15B参数，主要面向代码生成、软件工程、推理及多步工具调用等任务。 在推理过程中，IQuest-Q1采用递归多Token预测（MTP）机制。

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在连续解码过程中拥有更完整的执行控制能力。 继续压缩等待 除了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时，系统就可以继续处理已经就绪的数据。 这一设计将数据就绪判断与结果归约结合在一起，减少了额外的同步操作。 这些优化覆盖了推理过程中反复出现的计算调度、数据加载与通信环节。 单项改进可能只节省数十微秒，但随着执行轮次和模型层数不断增加，累积收益就会影响整体生成速度。

当然，改变计算路径也可能影响浮点数值结果。 技术报告明确指出，部分路由融合操作采用了与原有实现不同的数值计算方式； 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毫秒。