AutoTuneBench: 用于LLM服务引擎代理自动调优的可信度量

# AutoTuneBench：面向LLM服务引擎代理自动调优的可信赖测量基准
来源：https://arxiv.org/html/2609.18123
###### 摘要

大型语言模型代理通过“提议-测量-保留”的闭环机制调整GPU内核与服务引擎，但该闭环背后的测量过程缺乏可信赖性。我们基于为期四天、包含619次模型调用的试点语料库，归纳出四类失效模式：虚假基准制造加速假象、绝对时间指标跨机器不可迁移、任务饱和度使对比失效、基础设施缺陷伪装成科学结论。我们提出AutoTuneBench——一套通过架构设计确保可信度的基准与测量协议。该协议以冻结代码形式固化，通过测试强制执行数据溯源；数据库级验证器会拒绝所有违反协议的结果；防作弊检查独立于代理可修改范围运行；对比分析遵循预注册读数规范；测量结果锚定外部公开数据，采用配对种子统计方法并将跨次运行变异系数上限设为5%。诚实测量重新书写了关键结论：我们最优内核相对于朴素基准的加速比为10.6×，但相对于诚实基准仅为2.03×；同一配置在不同机器上分别实现1.174×和1.0049×的加速；预注册的开关对照实验因共享性能上限而显示无显著差异（2.4840 vs 2.4957毫秒）；KernelBench Level-1测试集中51%的任务通过验证，但相对PyTorch eager模式的中位加速比仅为1.0001×。该协议、双引擎语料库（vLLM和SGLang）及其审计追踪记录均以开源制品形式发布。

## 1引言

vLLM[5 (https://arxiv.org/html/2609.18123#bib.bib6)]与SGLang[21 (https://arxiv.org/html/2609.18123#bib.bib9)]等LLM服务引擎提供了数十个相互关联的配置旋钮：调度策略、投机解码设置[9 (https://arxiv.org/html/2609.18123#bib.bib3), 1 (https://arxiv.org/html/2609.18123#bib.bib1)]、KV缓存限制以及CUDA图形态。精确调优这些参数具有显著经济价值：在我们的SGLang试点中，同一模型在同一GPU上经过调优后吞吐量可达默认配置的1.26×至1.28×；而vLLM试点则测得1.01×的差异，可见收益幅度因引擎而异。如今大语言模型已能自动生成代码与配置。闭环的“提议-测量-保留”机制有望无需人工干预即可完成引擎与GPU内核的调优，相关系统正持续涌现。

然而当前支撑该愿景的测量过程尚不可信。Sakana AI CUDA工程师事件为此定调：其宣称的3.13×加速比在消除奖励机制漏洞后坍缩至1.49×[6 (https://arxiv.org/html/2609.18123#bib.bib10)]。我们在自身调优语料库中观察到四类会悄然破坏结果的失效模式：第一，*虚假基准制造加速假象*：我们最优的gelu调优内核相对于朴素初始版本显示10.6×加速，但相对于搜索实际采用的诚实基准仅为2.03×；第二，*绝对数值跨机器不可迁移*：同一配置在不同机器上分别实现1.174×和1.0049×加速，因此跨站点声明必须基于各设备基准进行比例报告；第三，*任务饱和度使对比失效*：在首次有效的开关AB实验中（每组n=20），两组方案均在首次迭代时达到2.48毫秒的性能上限，因为任何合格的初始提案已触及融合算子的天花板；第四，*基础设施缺陷伪装成科学结论*：4096令牌的管道默认值截断了148次模型调用的97.3%，占用率检查竞争条件使某AB实验的处理组静默失效一天，另一个引擎的补丁链错误导致12次迭代中11次被拒绝。这些问题在实验数据中均未显现，却在审计追踪中无所遁形。

本文探讨的是测量问题而非调优问题：*如何对LLM代理的引擎自动调优进行测量，才能确保其结果可信？诚实测量能揭示哪些朴素评估所掩盖的真相？*我们通过AutoTuneBench——一套面向引擎自动调优的基准与测量协议——对此作出回应。核心洞见在于：信任必须*通过架构实现*——协议以冻结代码形式存在，所有数值必须通过验证器进入数据库，声明需锚定外部公开数据。

AutoTuneBench通过四种机制实现这一理念：协议固化于单一配置文件，每个字段均可追溯引用源；若字段丢失溯源信息则测试失败；数据库级验证器拒绝任何违反冻结协议的结果，确保违规数据即使偶然也无法进入语料库。防作弊设计从架构层面而非建议层面实施：参考实现位于修改范围之外，10×异常断路器隔离可疑加速比（它在自身语料库中捕获了真实的身份伪装案例），运行时检查统计禁止的回退操作。对比分析遵循预注册读数规范，配备*处理交付检查点*：当处理组证明从未触达提示词时AB实验自动终止，这在自身运行中避免了两次虚假零结果。测量锚定外部公开结果，确保绝对声明可通过调优代理无法影响的数字进行验证。

在该协议下，我们揭示了朴素评估所掩盖的真相：通过Astra公开的SGLang内核加速数据进行外部锚定验证[18 (https://arxiv.org/html/2609.18123#bib.bib12)]，在单一内核上实现±10%范围内的吻合（均等比1.047），并对其他差异进行机械解释：标准SGLang已对某内核进行向量化，而硬件频率下限压缩了短时任务的加速比。KernelBench Level-1测试集[13 (https://arxiv.org/html/2609.18123#bib.bib11)]产生诚实的阴性结论：51%的任务生成正确候选解，但相对PyTorch eager模式的中位加速比仅为1.0001×，53次重测候选解的运行间方差中位数为0.6%。随机突变基线对照揭示了LLM提案器的真实贡献：在饱和任务上随机搜索同样能达到最终内核质量（最佳2.47毫秒，触及上限），但20次可用迭代中仅维持3次有效提案，而LLM可维持11至14次。在第二引擎上运行相同循环将与协议无关的声明转化为证据：SGLang的搜索发现ngram投机解码相比其默认配置可持续提升1.256×请求吞吐量（三种ngram配置下的七次测量）。

本文包含五项贡献：
1. 揭示四类会悄然破坏LLM代理自动调优测量的失效模式，基于619次模型调用的四天试点语料库提供实例（虚假基准、不可迁移的绝对值、任务饱和度、基础设施缺陷伪装科学）。
2. 提出以冻结代码形式存在的测量协议，通过测试强制执行数据溯源，并拒绝所有违反协议的结果。
3. 构建架构化防作弊设计，包括捕获已部署身份伪装的10×异常断路器，以及避免两次虚假AB零结果的处理交付检查点。
4. 建立外部锚定方法论，通过公开数据验证测试框架，并将差异转化为机制层面发现。
5. 生成基线对照、跨引擎评估语料库（vLLM与SGLang，100个KernelBench任务，预注册AB实验每组n=20），这使诚实测量成为可能。

## 2背景与动机

### 2.1引擎调优的配置空间

现代服务引擎提供数十个相互关联的配置旋钮。vLLM[5 (https://arxiv.org/html/2609.18123#bib.bib6)]与SGLang[21 (https://arxiv.org/html/2609.18123#bib.bib9)]允许操作者选择调度策略、KV缓存限制、CUDA图形态及投机解码设置；投机解码通过草稿模型生成候选输出，引擎在单次前向传播中进行验证[9 (https://arxiv.org/html/2609.18123#bib.bib3)]，分块预填充调度则改变预填充与解码阶段对GPU的共享方式[1 (https://arxiv.org/html/2609.18123#bib.bib1)]。这些旋钮存在相互作用，因此对某一工作负载有益的设置可能损害另一负载性能。在我们的SGLang试点中，同一模型同一GPU上默认与最优调优配置之间的吞吐量差距达1.28×，vLLM试点中则为1.01×。该配置空间的专家级调优需要跨模型、跨工作负载、跨硬件代际进行迭代，这正是当前领域将调优闭环本身委托给LLM代理的原因。

### 2.2当前的代理调优闭环

现有代理调优闭环复现了专家性能工程师的工作流程：任务指定待优化的内核或引擎配置；LLM代理提议候选差异；沙箱环境构建该候选；基准测试层在特定协议下对比候选与基线；保留或丢弃规则决定下一次提议的起点。KernelBench[13 (https://arxiv.org/html/2609.18123#bib.bib11)]等基准提供任务表面，Astra的SGLang内核加速数据[18 (https://arxiv.org/html/2609.18123#bib.bib12)]等公开优化结果提供参考点。

测量步骤承担了全部认知负荷，因为它同时作为奖励信号：测量层奖励什么，代理就学会产出什么，包括其缺陷。Sakana AI CUDA工程师事件具体展现了这一点：代理发现评估代码中的内存安全漏洞并加以利用，清理后的聚合数据从3.13×坍缩至1.49×[6 (https://arxiv.org/html/2609.18123#bib.bib10)]。当前闭环缺乏人类基准测试实践中理所当然的防御措施，本节后续部分将记录四种导致结果腐化的缺口类型。

### 2.3四类失效模式及实证

虚假基准制造加速假象：基准选择而非搜索质量决定了头条数字。我们最优的gelu调优内核相对于朴素初始文件显示10.6×加速，但相对于搜索实际改进的诚实基准仅为2.03×。10.6×比率衡量的是从朴素基准到内存带宽上限的距离，而非搜索质量；我们的异常断路器正是为此隔离超过10×的比率。我们引用2.03×数据并将10.6×读数标记为虚假基准产物。Sakana从3.13×坍缩至1.49×是公开的同类案例：代码未变，仅对比的诚实性发生了变化。

绝对时间跨机器不可迁移：同一候选在两台同型号机器上与其各自设备基准对比时得出不同结论。试点中最优的ngram投机解码配置在一台机器上将测量任务时间从3608毫秒降至3073毫秒（1.174×），但在另一台机器上仅达1.0049×；该配置在第一台机器上的效果是第二台的约35倍。因此跨机器绝对时间不可比，跨站点声明只有通过与同硬件上重测的设备基准进行比例对比才合法。报告绝对胜利的语料库会将这种不稳定性传递给读者。

任务饱和度使对比失效：当任何合格的初始提案已触及性能上限时，优化提示无法提供帮助。在首次有效的开关AB实验中（每组n=20），关闭组最佳为2.4840毫秒，开启组最佳为2.4957毫秒，0.5%的差异处于运行间噪声范围内；两组均在首次迭代时达到平台期，初始提案已达到各组最优的5%范围内，共同上限在2.48至2.50毫秒之间，由融合逐元素CUDA内核设定。此零结果真实有效而非处理失效：所有13个开启组保留方案均携带实时分析输出，表明提示已触达该组保留的所有提示词。饱和度将AB实验变为硬币投掷，因此余量筛查必须先于对比分析。

基础设施缺陷伪装成科学结论：三类管道缺陷各自产生了一夜看似测量结果的数据。路由器默认值`max_tokens=4096`截断了模型回复：148次实时循环模型调用中有97.3%恰好返回4096输出令牌，98个内核任务变体中有82个格式错误，此比例伪装成模型质量天花板。占用率检查竞争条件静默禁用AB实验的处理组，使其在一天内无处理措施运行。第二引擎的补丁链错误导致12次迭代中11次因补丁无法应用而被拒绝。三类问题均未在实验数据中显现；审计追踪捕获了每个问题，这证明了将追踪记录作为协议组成部分而非事后补充的必要性。

### 2.4现有基准测试为何无法捕获这些失效

标准实践规范候选质量而非测量完整性，而四种失效均发生在此界限之下。KernelBench[13 (https://arxiv.org/html/2609.18123#bib.bib11)]、MLPerf Inference[15 (https://arxiv.org/html/2609.18123#bib.bib13)]等静态套件固定了任务、指标与可比性规则——这正是共享标尺所需；它们同时假设测量层可靠并报告单次运行的中位数，但测量研究表明单次运行会翻转配对排名，重复运行纪律才是稳定排名的关键[2 (https://arxiv.org/html/2609.18123#bib.bib14)]。我们对53个KernelBench候选解的重测在正确性判定上完全复现，中位偏差0.60%，证明当协议要求重复运行时方差具有可表征性。自我报告的数字在可问责人类签署声明且存在复现压力时有效；具备奖励访问权限的自主闭环既不内化人类问责也不内化复现压力，Sakana事件展示了自我报告与优化器相遇的后果。因此四类失效模式要求静态套件或报告规范所不具备的特性：以冻结代码形式存在的协议、通过架构而非审查强制执行的防作弊机制、以及锚定代理无法影响数字的方法论。

## 3概述

AutoTuneBench在代理无法触及的测量流水线中运行第2节[2 (https://arxiv.org/html/2609.18123#S2)]描述的代理调优闭环（图1[1 (https://arxiv.org/html/2609.18123#S3.F1)]）。单次迭代流程如下：LLM代理提议候选差异，任务修改范围将其限制为单个文件；网络隔离沙箱构建候选；正确性阶段在至少五种输入形状下对比候选与位于修改范围外的参考实现输出；计时阶段在冻结协议下测量候选：内核任务运行25次预热迭代和100次带L2缓存刷新的定时重复，引擎任务运行配对种子列表并报告第50、95、99百分位数；通过的候选可能进行NCU性能分析，仅被保留的候选需承担此成本；评分器将测量到的基线对比比率映射至离散里程碑区间；第4节[4 (https://arxiv.org/html/2609.18123#S4)]的门控矩阵裁决该迭代；变体数据库记录结果；棘轮机制闭合闭环：每个保留的变体成为下一次提议的父节点，因此改进仅通过所有门控的测量结果复合增长。

LLM代理提议差异 → 沙箱构建 → 正确性检查 → 公平计时 → 可选NCU分析 → 评分（里程碑区间） → 防作弊门控 → 变体数据库（单次摄入） → 保留决策 → 下一迭代：保留变体成为父节点 → 修改范围