新智元报道
(相关资料图)
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路张量并行、单请求条件下，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倍的性能结果，仍应放在相应的测试环境中理解。
从IQuestRT可以看到，随着Coding Agent等应用开始承担越来越复杂、连续的任务，推理优化正进一步深入具体模型结构与实际工作负载。
GPU执行调度、投机深度选择、MoE专家权重读取以及跨卡通信，这些底层环节的优化能够共同影响一次请求的生成效率。
与此同时，AI Agent参与底层性能优化的实践，也为高性能计算软件的研发提供了新的探索方向。
当专用推理引擎的性能优化与自动化研发流程结合起来，未来面向不同模型构建高效推理系统，可能拥有更多值得尝试的工程路径。
参考资料：
技术报告：https://iquestlab.github.io/IQuestRT/
开源代码：https://github.com/IQuestLab/IQuestRT
编辑：元宇
