全新编译器实现AI手机翻译实时响应速度提升9倍能力提升突破

这项由两位研究者Satyam Kumar与Saurabh Jha独立完成的研究，以arXiv预印本形式于2026年4月14日发布，论文编号为arXiv:2604.16498v1，归类于计算机体系结构领域（cs.AR）。感兴趣的读者可通过该编号在arXiv平台查阅完整论文。

手机里的AI助手在帮你写邮件、翻译语言、识别照片的时候，背后其实有一套复杂的"翻译系统"在悄悄工作。它的任务是把你安装的AI程序翻译成手机芯片能听懂的语言，就像一位专业口译员，坐在AI程序和芯片硬件之间，实时传达双方的意图。这个"翻译官"有个专业名字，叫做编译器。

问题在于，现在主流的"翻译官"——比如英特尔的OpenVINO和微软的ONNX Runtime——工作方式相当笨重。它们在翻译之前需要把AI程序先改写成一种老旧的中间格式，就像要把普通话先翻译成文言文，再从文言文翻译成方言，绕了一大圈，不仅慢，还经常翻译出错。现代AI程序里有很多新式表达方式，文言文根本没有对应词汇，翻译就卡住了。

这篇论文介绍的FORGE-UGC（全称FX Optimization & Register-Graph Engine — Universal Graph Compiler，可以理解为"通用图编译引擎"）正是为了解决这个问题而生。两位研究者从2025年12月开始，用不到半年时间，从零构建了一套全新的编译系统。这套系统跳过了那道多余的文言文翻译环节，直接在原始AI程序和芯片之间建立了清晰、透明的沟通管道。在英特尔AI Boost神经处理单元（NPU，一种专门处理AI任务的芯片）上验证的结果显示，编译速度比现有方案快了6.9到9.2倍，AI程序运行延迟降低了18.2%到35.7%，每次推理消耗的电量减少了30.2%到40.9%。

一、为什么手机里需要专门的AI芯片，而不是直接用CPU？

要理解这个问题，可以把不同类型的芯片想象成不同专业的厨师。CPU（中央处理器）是全能厨师，炒菜、烘焙、摆盘什么都会，但样样都只是中等水准，速度也不算快。GPU（图形处理器）更像是专门做批量料理的流水线厨师，同时炒一百锅的效率极高，特别适合需要大量重复计算的任务。而NPU（神经处理单元）则是专门为AI任务量身打造的厨师，处理那些密集的矩阵运算时，每一瓦电力产生的计算量远超前两者。

英特尔把这种NPU集成进了Meteor Lake和Arrow Lake系列处理器，品牌名叫AI Boost，能提供每秒11万亿次整数运算（11 TOPS INT8），功耗却不超过10瓦——这相当于在一根灯泡的耗电量下，完成独立显卡十几倍的AI效率。对于手机或笔记本电脑这种靠电池供电的设备来说，这种效率差距直接决定了AI助手能不能在本地流畅运行而不把电池榨干。

然而，有了这么好的硬件厨师，还需要一个能跟他沟通的助理。AI程序是用PyTorch这类工具写的，语言是Python；而NPU芯片只懂自己的底层指令集。编译器就是那个懂双语的助理，负责把Python写的菜谱翻译成芯片能执行的烹饪动作。翻译得好，芯片就能高效工作；翻译得差，芯片就在不停地等待、重复劳动、浪费电力。

二、现有的"翻译官"到底哪里出了问题？

现有的两套主流编译工具——OpenVINO和ONNX Runtime——在设计上都有一个共同缺陷，就是它们无法直接读懂现代PyTorch写出的AI程序。

以OpenVINO为例，它的工作流程是这样的：先把PyTorch程序转换成ONNX格式（一种通用的AI模型描述语言），再把ONNX转换成OpenVINO自己的专有格式，最后才送进NPU执行。这个过程就像把一本现代汉语小说先翻译成英文，再翻译成拉丁文，再交给罗马工匠去制作雕塑。每次转换都有信息损失，而且现代AI程序里有很多新式结构——比如Llama-3、Mistral这类大语言模型用到的旋转位置编码（RoPE）、分组查询注意力（GQA）、SwiGLU激活函数——这些东西在ONNX这种"旧语言"里根本没有对应词汇，翻译就直接失败了，开发者不得不手动把这些新结构拆解成更基础的操作，费时费力且容易出错。

除此之外，这两套工具还有一个让开发者头疼的特点：整个翻译过程是个黑箱。你把AI程序扔进去，等十几分钟，出来一个编译好的版本，但你完全不知道编译器在里面做了什么，哪些优化生效了，哪些没有，也无法调试为什么某个模型跑得特别慢。这就好比你把食材交给餐厅厨师，一小时后端出一道菜，但厨师绝不让你进厨房，你永远不知道他到底怎么做的，食材有没有被处理好，火候有没有控制准确。

在内存管理上，这两套工具同样没有提供有效的机制。AI程序在运行时会产生大量中间计算结果，它们就像厨房里临时摆放的半成品，需要合理安排放置位置，用完了就清掉，以免把工作台堆满。现有工具没有暴露给开发者任何关于这些中间结果生命周期的信息，导致芯片在CPU和NPU之间来回搬运数据，每次搬运都要花时间和电力。

编译速度也是一个实际问题。对于80亿参数规模的模型（比如Llama-3.1-8B），OpenVINO需要58秒，ONNX Runtime需要62秒才能完成编译。在研究和开发阶段，工程师每次调整模型后都要等这么久才能看到结果，严重拖慢了迭代速度。

三、FORGE-UGC是怎么绕过这些麻烦的？

FORGE-UGC的核心思路是：既然问题出在那道多余的翻译环节，那就干脆不翻译，直接在原始语言上工作。

PyTorch 2.x版本提供了一个叫做`torch.export`的功能，它能把AI程序的计算过程完整地捕获成一张"计算图"——可以把这张图想象成一张精确的烹饪流程图，上面标注了每道菜需要哪些食材、按什么顺序操作、中间产物传递给哪个步骤。这张图使用的是PyTorch底层的ATen算子语言，涵盖了包括RoPE、GQA、SwiGLU在内的所有现代操作，不需要经过任何中间格式转换。

FORGE-UGC直接接收这张计算图，然后分四个阶段处理：

第一阶段是图的捕获，也就是用`torch.export`把AI程序变成那张烹饪流程图。这个阶段还有一个细节处理：有些AI程序里有"共享参数"，比如GPT-2的词嵌入层和语言模型头部共用同一块权重数据，就像两道菜共用同一锅高汤。FORGE-UGC会自动识别这种情况，确保两个地方都指向同一份数据，而不是复制两份，既节省内存又保证计算正确。

第二阶段是图的优化，这是整个系统最精华的部分，下一节会详细展开。

第三阶段是把优化后的计算图转换成一种叫做NPUIR的中间表示，给每个计算步骤打上标签，注明它应该在NPU上运行还是在CPU上运行，以及输入输出用哪个"虚拟寄存器"（可以理解为临时存储格子的编号）。

第四阶段是内存分配和指令调度，确定虚拟寄存器映射到实际物理内存的哪个位置，并调整执行顺序，让NPU任务尽可能连续执行，减少CPU和NPU之间来回切换的次数。

这四个阶段共同产出一个叫做`CompiledNPUExecutor`的执行器，它是一个扁平化的指令列表，运行时不需要再做任何动态决策或内存分配，像一台按剧本表演的机器人，每步都提前安排好了。

四、那六道"优化工序"各自做了什么？

第二阶段的六个优化步骤是FORGE-UGC的核心技术所在，它们按照固定顺序依次处理计算图，每一步都有明确的任务，可以独立测量效果，也可以单独禁用某一步来测试其贡献。

第一步叫死代码消除。计算图在捕获时会包含一些实际执行时根本用不到的节点，比如调试用的中间输出、梯度计算相关的分支等。这一步从输出结果往回追溯，标记出所有真正需要的计算节点，剩下的一律删掉，相当于在烹饪流程图里划掉那些"最终菜品不需要"的预备工序。

第二步叫公共子表达式消除。如果计算图里有两个地方做了完全相同的运算（相同的操作、相同的输入），就只保留第一个，第二个直接复用第一个的结果。这就像发现流程图里有两处"切洋葱"步骤，只需要切一次，把切好的洋葱分给两道菜用就行了。

第三步叫常量折叠。如果某个计算的所有输入在编译时就已经是固定数值，那就直接提前算好结果，把那个计算节点替换成一个数字常量。比如AI程序里有`x + 0`或者`x × 1`这种毫无意义的运算，直接替换成`x`本身，节省运行时计算。

第四步叫注意力融合，这是六步中效果最显著的一步。现代大语言模型的"注意力机制"（Attention）是让模型理解上下文的核心计算，但在原始计算图里，它被分解成了一串独立的操作：先做Q乘K的转置，再除以缩放系数，再加掩码，再经过softmax，再乘以V矩阵。每个箭头都是一次独立的芯片调度请求，中间结果都需要写入内存再读出来。FORGE-UGC会识别这个特定的操作模式，把整条链合并成一个单一的"融合注意力"调用，一次性完成所有计算，中间结果都在芯片内部流转，不需要来回写内存。这一步平均减少了14.6%的计算图节点，对32层深的模型，延迟降低可达29.6%。

第五步叫算子融合。类似于注意力融合，这一步针对的是"线性层+激活函数"这种常见组合，比如Linear层后面跟着ReLU、GELU或者SiLU。原本需要两次调度的操作合并成一次，由NNFactory（英特尔NPU的编程接口）编译成一个统一的NPU指令。

第六步叫布局优化。NPU处理数据时，数据在内存里的排列方式（布局）对效率有很大影响。经过矩阵转置或维度重排操作后，数据在内存里可能变得不连续，NPU读取时需要额外复制一份连续的版本。这一步在进入NPU处理之前，提前把数据排列成NPU最喜欢的格式，省掉运行时的隐式复制开销。

六步优化合在一起，在GPT-2（125M参数）上把计算图节点数从403个减少到333个，降幅17.4%；在LFM2-2.6B上降幅达到21.9%。所有六步总耗时仅208毫秒，只占整个编译时间的21.1%。

五、内存管理和指令调度的技术细节

第四阶段的工作可以用一个仓库管理的比喻来理解。计算图里有大量中间计算结果需要临时存放，就像仓库里有很多货物，每件货物都有它的"入库时间"（什么时候被生产出来）和"出库时间"（什么时候被最后一次使用）。入库到出库之间叫做这件货物的"存活区间"。

FORGE-UGC先做一次活性分析（Liveness Analysis），精确计算每个虚拟寄存器的存活区间。然后用一个叫做"线性扫描寄存器分配"的经典算法（这个算法复杂度是O(N log N)，比OpenVINO内部使用的图着色方法的O(N?)复杂度低得多），贪心地把已经过了出库时间的货物存储格子分配给新进来的货物。这就像仓库里一个货架位被腾空后，立刻分配给下一批需要存放的货物，而不是专门给每种货物留一个固定的格子。

通过这种重用机制，物理缓冲区的数量比虚拟寄存器数量减少了30%到48%。具体来说，GPT-2的333个虚拟寄存器只需要218个物理缓冲区，Llama-3.1-8B的896个虚拟寄存器只需要468个物理缓冲区。

指令调度的任务则是调整执行顺序。CPU和NPU是两个独立的处理单元，每次从一个切换到另一个都需要通过PCIe/MMIO接口搬运数据，每次切换大约耗时0.3到0.8毫秒。FORGE-UGC的调度器在满足数据依赖关系的前提下，优先安排与当前设备相同的任务，让NPU上的任务尽可能聚集在一起，CPU上的任务也聚集在一起，减少设备切换次数。

六、研究结果：数字背后的真实含义

研究团队在一台配备英特尔Core Ultra 9 285HX处理器和英特尔AI Boost NPU的工作站上，针对六个规模从1.25亿到80亿参数不等的语言模型进行了测试，数据集采用WikiText-103（语言建模标准测试集）和GLUE（多任务自然语言理解测试集）。

编译速度的差距非常显著。以最小的GPT-2（125M参数）为例，FORGE-UGC编译需要1000毫秒，OpenVINO需要6930毫秒，ONNX Runtime需要7271毫秒，分别快了6.9倍和7.3倍。对最大的Llama-3.1-8B，FORGE-UGC需要6.7秒，而两个基准框架分别需要58.4秒和62.2秒，差距进一步扩大到8.7倍和9.2倍。更值得注意的是，FORGE-UGC的编译时间与模型层数基本成线性比例（大约每层210毫秒），而两个基准框架的编译时间随层数增长呈超线性增长（大约按层数的1.4次方增长），这意味着模型越大，FORGE-UGC的优势越明显。

进一步分析编译时间的构成，会发现一个有趣的事实：FORGE-UGC78%的编译时间花在了`torch.export`图捕获这一步，而这是PyTorch本身的基础功能，任何使用FX计算图的工具都必须走这一步。FORGE-UGC自己的优化和后端处理只花了约216毫秒。换句话说，FORGE-UGC之所以比基准框架快，一部分是因为它省掉了对方需要额外做的ONNX/TorchScript转换步骤，另一部分是因为它自己的优化算法更高效。

推理延迟的改善在不同模型规模上都很稳定。在WikiText-103上，GPT-2的平均延迟从8.45毫秒（OpenVINO）或9.13毫秒（ONNX Runtime）降到6.82毫秒，降幅19.3%；Llama-3.1-8B从91.37毫秒或97.82毫秒降到62.48毫秒，降幅分别为31.6%和36.1%。在GLUE数据集上，结果与WikiText-103高度一致，标准差不超过1.2%，说明这些改善来自图结构优化，而不是针对特定数据集的侥幸表现。

延迟分布的稳定性同样值得关注。FORGE-UGC的P99延迟（最差情况下99%的请求能在这个时间内完成）与P50延迟（中位数延迟）的比值稳定在1.20，而两个基准框架的这个比值是1.27到1.28。这6到8个百分点的差距意味着，在对响应时间要求严格的边缘部署场景中，FORGE-UGC能更可靠地满足服务质量要求。

能耗数据可能是最令人印象深刻的部分。研究团队使用英特尔的RAPL接口测量了推理过程中CPU和NPU的系统级功耗，GPT-2每次推理消耗69.6毫焦，而OpenVINO消耗99.7毫焦，ONNX Runtime消耗110.5毫焦，降幅分别是30.2%和37.0%。Llama-3.1-8B每次推理消耗637.3毫焦，而两个基准框架分别消耗1078.2毫焦和1183.6毫焦，降幅达到40.9%和46.2%。能耗的改善幅度系统性地超过了延迟的改善幅度，原因在于FORGE-UGC不仅缩短了推理时间（时间短就少耗电），还降低了推理过程中的平均功耗（设备切换减少了调度开销，预分配内存减少了动态内存分配带来的DRAM功耗峰值）。

在数值精度方面，研究团队对1000个随机采样的文本序列分别运行编译前和编译后的模型，比较输出概率的差异。对于使用fp16精度的模型（1.25亿到26亿参数），最大绝对差异不超过1.2×10??，KL散度（衡量两个概率分布差异的指标，越接近0表示越相似）低于6.3×10???，可以认为是数值误差范围内的完全一致。对于80亿参数的Llama-3.1-8B，因为NNFactory在第四阶段执行时应用了INT8权重量化（把模型从16位浮点精度压缩到8位整数精度），最大绝对差异是2.1×10??，KL散度是8.4×10??，仍然处于实践中可忽略不计的范围内，困惑度（衡量语言模型质量的指标）在两位小数精度下完全一致。

七、三个新指标：把编译器的价值量化出来

研究团队还提出了三个评估指标，帮助工程师更科学地比较不同编译器。

第一个指标是每个优化步骤的执行时间。通过分别测量每个优化步骤的耗时，工程师可以清楚地知道哪个步骤最耗时、哪个步骤收益最大。在GPT-2上，算子融合耗时72毫秒，是最耗时的步骤，但注意力融合只需38毫秒，却消除了59个节点，每毫秒消除1.55个节点，效率是算子融合（每毫秒消除0.17个节点）的9.1倍。

第二个指标叫融合增益比（FGR），它衡量的是禁用所有融合优化时的代价模型得分与完全开启融合时的得分之比。这里需要特别说明的是，FGR是一个基于启发式代价模型的诊断工具，而不是实际延迟的直接比值。在Llama-3.1-8B上，FGR值是67.9，意思是融合把代价模型评估的估算成本压缩到了原来的1/67.9，但对应的实际墙钟时间延迟降低是29.6%，两者之间不是线性关系。FGR的价值在于提供一个不依赖硬件执行就能比较不同编译配置、不同模型融合效果的标准化指标。

第三个指标叫编译效率指数（CEI），计算方式是推理延迟加速比除以编译时间（以秒为单位）。CEI越高，说明每花一秒编译时间能换来更多的推理速度提升。对于GPT-2，相对ONNX Runtime的CEI是1.339，意思是每秒编译时间换来了1.339倍的推理速度提升。对于Llama-3.1-8B，CEI是0.233，随模型变大而降低，因为编译时间增长比推理加速更快。研究者特别指出，CEI主要适用于频繁重新编译的迭代开发场景，在"编译一次、运行百万次"的生产部署场景中，即使是6.7秒的编译时间也完全可以忽略不计，绝对延迟改善才是关键指标。

八、消融实验：拆开来看，哪步最关键？

研究团队逐一禁用某个优化步骤来测量它的贡献。结果明确指出，注意力融合是最关键的单一优化。禁用注意力融合后，代价模型得分从8.64急剧上升到238.34，增幅2658%；而禁用其他任何单一步骤，代价模型得分的变化都不超过3%。

从实际延迟的角度验证这一结论，在12层的GPT-2上，启用注意力融合比不启用延迟降低16.6%；在32层的Llama-3.1-8B上，降低幅度达到29.6%。层数越多，效果越显著，因为每个注意力模块都会被融合处理一次，层数越多，融合的节点越多。

融合激进程度（参数α，从0到1）的敏感性测试显示，对NPU目标来说，α越高越好。这与GPU上的情况不同——GPU上过度融合会导致寄存器压力增大，反而影响性能。NPU通过NNFactory把整个融合子图作为一个单元调度，消除了所有中间调度开销，因此融合得越彻底，节省越多。

自动调优（AutoTuning）模块在45种配置组合中选出最优配置，在200毫秒内完成，不需要实际运行硬件。自动调优比默认配置进一步改善了4.2%到8.7%的代价模型得分，且改善幅度随模型规模增大而增大，因为更大的模型有更多样化的子图结构，更能受益于针对性配置。

九、这套系统和其他同类工具相比，到底独特在哪里？

同类工具中有几个值得横向比较。TVM是学术界影响力最大的深度学习编译器，支持自动调优，但需要把模型导出到ONNX格式，引入了FORGE-UGC极力避免的导出环节，且不支持英特尔NPU目标。

XLA是谷歌为TPU和GPU开发的编译器，支持整程序优化，但只能用于谷歌自家硬件生态。

IREE是最接近FORGE-UGC理念的开源框架，基于MLIR（多层中间表示）构建，支持可组合的优化步骤、多后端代码生成和显式内存管理。但IREE需要通过torch-mlir或StableHLO转换才能接入PyTorch模型，再次引入了导出环节；更关键的是，IREE没有英特尔NPU后端，也不支持NNFactory调度。研究者最初曾尝试用IREE-Turbine（IREE的PyTorch前端）来构建这套系统，但遭遇了两个难以绕过的障碍：MLIR的优化步骤必须用C++实现，Python调试周期很长；而且IREE完全没有针对英特尔AI Boost NPU的后端，从头实现需要巨大工程量。这段尝试经历最终促使研究者选择了PyTorch FX计算图作为基础。

torch.compile（Inductor后端）是PyTorch官方的编译工具，也直接操作FX计算图，与FORGE-UGC在架构上最相似。但Inductor只针对CPU（C++代码生成）和GPU（Triton内核）后端，没有英特尔NPU调度，没有NNFactory集成，也没有基于存活区间的NPU缓冲区分配。研究者评估过把FORGE-UGC实现为torch.compile的自定义后端，但发现三个问题难以解决：torch.compile的后端API不支持在图捕获和代码生成之间注入自定义步骤；NNFactory需要的是"编译一次、作为整体调度"的执行模型，而torch.compile假设内核是可直接调用的Python函数；Inductor的内存规划器是面向GPU设计的，不开放为可插拔组件。

Hexagon-MLIR是与FORGE-UGC同期出现的一个针对高通骁龙NPU的编译栈，采用MLIR为基础，支持Triton内核编译，实现了Hexagon向量扩展（HVX）的向量化和NPU紧耦合内存（TCM）感知的分块优化。两者的目标硬件和IR基础完全不同，但设计理念高度相似：可组合步骤、显式内存管理、硬件感知调度。FORGE-UGC的作者认为，未来在高通Hexagon后端模块里，可以借鉴Hexagon-MLIR在TCM感知分块和双缓冲方面的经验，同时复用FORGE-UGC的整个前端和中间优化流程。

说到底，这项研究做的事情其实可以用一句话概括：把一套原本像黑箱一样、让开发者束手无策的芯片"翻译官"，替换成了一套透明、可调试、可拆卸的工具链，同时还顺带把速度提高了将近10倍，把电量消耗降低了三分之一到四成。

对于普通用户来说，这意味着你手机上的AI助手有一天可以跑得更快、更省电，不用每次思考半天才给你回答，同时也不会把电池消耗殆尽。对于开发者来说，这意味着他们可以看清楚自己的AI程序在芯片上到底经历了什么，在哪里卡壳，为什么这个步骤比那个步骤慢。对于整个行业来说，这套系统的架构设计——把硬件无关的优化层和硬件相关的后端层彻底分离——意味着当高通、AMD、苹果或者三星的新一代NPU出现时，只需要新写一个后端模块，前面那六道优化工序可以完全照搬。

这个研究还带出了一个更深层的思考：在芯片硬件越来越强大的今天，软件与硬件之间的"沟通层"是否已经成为新的瓶颈？好的硬件如果没有好的编译器来驱动，就像一辆赛车配了一个不会换挡的司机。FORGE-UGC给出的答案是，透明、可组合、硬件感知的编译基础设施，才是让AI真正跑起来的关键。感兴趣的读者可以通过arXiv:2604.16498v1获取完整论文，深入了解每个技术细节。

Q&A

Q1：FORGE-UGC编译器和OpenVINO有什么本质区别？

A：OpenVINO需要把PyTorch模型先转成ONNX格式，再转成自己的专有格式，才能送进NPU执行，这个过程不仅慢，还会因为格式差异导致现代大语言模型里的新式操作（如RoPE、GQA）转换失败。FORGE-UGC直接操作PyTorch原生的计算图，跳过了所有中间格式转换，编译速度快了6.9到8.7倍，同时还暴露了每个优化步骤的详细信息，让开发者可以清楚看到每一步做了什么。

Q2：NPU和GPU处理AI任务有什么不同？

A：GPU像是能同时做一百道菜的流水线厨师，并行计算能力极强但功耗较高，适合灵活多变的大规模任务。NPU是专门为密集矩阵运算优化的AI专用芯片，每瓦电力产生的AI计算量远超GPU，特别适合手机、笔记本这类依赖电池的设备。英特尔AI Boost NPU在10瓦功耗下提供每秒11万亿次运算，比独立显卡的AI能效高出一个数量级，但需要配合高质量的编译器才能发挥全部效能。

Q3：FORGE-UGC的注意力融合优化具体是怎么工作的？

A：大语言模型的注意力机制在原始计算图中被拆分成多个独立步骤：Q乘K的转置、缩放、掩码、softmax、再乘V矩阵，每个步骤都是一次单独的NPU调度请求，中间结果需要写入内存再读出。注意力融合识别出这个固定的操作链，把它合并成一个单一的"缩放点积注意力"调用，整个计算在芯片内部一次完成，中间结果不需要经过内存读写。这一步平均减少了14.6%的图节点数，在32层深的模型上能让推理延迟降低接近30%。