您的边缘设备仅在前向传递上进行基准测试，而您的智能体将运行循环

过去一年，关于边缘 AI 的硬件讨论变得更加诚实。本站的一篇近期文章指出，旧的设计层级——“先最大化吞吐量，再围绕它管理功耗和热量”——已经颠倒，对于工业部署而言，功耗现在位居首位，原始吞吐量居于最后。这呼应了本刊长期以来的论点：边缘设备是热受限，而非 MIPS/计算受限，而智能手机已经达到了这些极限。这两点都是实质性的纠正，且早该如此。

但它仍然保留了来自它所纠正的世界的一个假设。层级中的每一项都基于一个假设的工作负载进行预算，而几乎所有人仍在预算的工作负载是单次前向传递：模型接收输入，产生输出，硅片得到片刻冷却。

这并不是智能体的工作方式。智能体会做决定，调用工具，读取返回结果，然后再次决定。它循环多少次并不是硬件的属性，也并非模型的属性，而是某人那天早上交给它的问题的属性。我在边缘硬件上运行智能体，花了最长时间才接受的并不是它们慢，而是运行成本被设定在我在设计时看不见的地方。

The Loop Is Unbounded Until Someone Types a Number

这不是修辞式的表述；它正是框架实际构建的方式。在OpenAI 的 Agents SDK中，运行器“运行一个循环”，当模型产生工具调用时，运行时会“运行这些工具调用，追加结果，并重新运行循环”。唯一能阻止它的是回合限制——超出 max_turns 会抛出异常——文档中说明可以将 max_turns=None 以完全禁用该限制。

在服务器上，这个数字是计费决策。有人会注意到账单。

在设备上，这个数字是热决策，因为循环长度等同于占空比。而占空比是被动散热无法争辩的唯一变量。

Sustained Load Does Something Different to a Phone Than a Benchmark Does

一项2026 年 3 月的基准测试在完全相同的负载下对四个平台进行评估——一个量化的 15 亿参数模型，固定的 258 令牌提示，二十次连续运行，测量每次的吞吐量、功耗和温度。它是预印本，只在四个设备上对同一模型进行基准测试，因此应将具体数值视为这些平台的特性描述，而非自然法则。重要的是结果的形状。

iPhone 16 Pro 的峰值为每秒 40.35 令牌，但无法维持。两次推理后出现性能下降，最终稳定在每秒 22.56 令牌——下降了 44%，并在基准测试的 65% 时间内被限频。动态电压频率调节（DVFS）——温度升高时降低时钟频率的机制——正是它存在的目的。

Galaxy S24 Ultra 的表现则更糟且方式不同。与其出现降速，Android 的热调节器在第六次迭代时将 GPU 频率硬性限制在 78.3°C，导致推理停止。作者指出，这对智能体部署来说“比温和降速更具破坏性”，因为系统并未变慢，而是变得不可用。

现在注意一个让人震惊的细节。那二十次运行全部使用了 相同的提示。这是智能体硬件能看到的最友好工作负载，却有两款旗舰手机无法在二十次重复中维持。这并非新发现——MELTing 点在 2024 年 MobiCom 上提出，得出在能量和热量方面“持续执行 LLM 仍然难以实现”。两年、数代工艺节点后，结论仍是同一堵墙。

Two Curves Move Toward Each Other, and Your Product Breaks Where They Cross

智能体的循环在特定、机械的方式上比重复提示更糟糕。

解码受内存带宽限制——吞吐量取决于模型读取键值缓存的速度，而不是芯片理论上能执行的操作数。该缓存随上下文增长。每一次循环步骤都会追加工具结果、观察或部分计划——因此第十步相较于第一步要在一个实质更大的缓存上生成令牌。

与此同时，设备温度升高，调节器降低时钟频率。

于是每一步的成本正好在设备支付能力下降的时刻上升。两条曲线相交的地方，就是你的产品失效的地方。它永远不是第一步——第一步是你已经测试过的。

这背后还有规模问题。生成式工作本质上是与过去十年边缘硅片所做工作不同的支出顺序——对 88 种模型的测量显示，文本分类每千次推理约消耗 0.002 kWh，而文本生成约为 0.047 kWh——大约是前者的二十倍，且任何循环都会进一步放大。那些测量是在数据中心 GPU 上完成的，而非手机，所以应将其视为不同工作类型之间的比例，而非你设备的功耗数值。该研究还给出，一次完整的智能手机充电约为 0.022 kWh。

Buy on Joules per Finished Task, Not on Tokens per Second

那份 2026 年基准测试中最有用的结果恰恰是看起来最不显眼的。

Hailo-10H NPU 在低于 2 瓦的功耗下实现了每秒 6.9 令牌。慢——真的很慢，作者也这么说。但它的吞吐量变异系数只有 0.04%，比其他任何测试对象稳健两个数量级。同一研究中的笔记本 GPU 在 34.1 瓦下提供了每秒 131.7 令牌。

然后比较两者的能耗而非速度：每个令牌的能耗分别为 270.5 毫焦（小 NPU）和 297.3 毫焦（GPU）。尽管吞吐量相差十九倍，小部件每焦耳的计算略高——而且几乎没有波动。

如果你按每秒令牌数选硬件，你会买最快的那款。如果你按能够以可预测成本完成有界循环的能力来选，那就是智能体真正需要的，排名会改变。规格表上应出现的单位是每完成任务的焦耳数，并附上变异值。报告峰值吞吐量的基准只反映了当天的第一次推理。

The Honest Objection, and What It Does Not Solve

显而易见的反驳是这只是暂时性问题：硅片会改进，NPU 会成熟，任何关于 2026 年手机的描述都会显得古旧。或者更实际的做法是把昂贵的步骤卸载到服务器。

我本人会押注硬件本身。但卸载正是你搬到边缘是想避免的往返，而智能体并不是一次性付费——它在每一次循环步骤都要付费，而循环长度是你无法预测的。混合设计并没有消除变异，只是把它转移到网络上。

更深层次的不对称不会随工艺节点而改变。设备的预算在设计时就已固定。智能体的需求在运行时由用户的请求决定。更好的硅片只能提升上限，却无法告诉智能体上限在哪里。

因此请在产品规格中设定回合限制，而不是在代码审查时才发现，并从热预算中挑选数字：决定有多少步骤能容纳，然后让智能体在该约束下给出最佳可用答案，而不是在任意的理想答案上做实验。把它视为截止期限，而不是目标。

随后把预算作为输入提供给智能体。剩余余量、电池状态、平台是否已开始降频——这些都应放在上下文中，就像当前时间一样。一个知道自己处于第八步（共十步）的智能体可以进行总结并提交。一个不知道的智能体会一直探索，直至操作系统为其决定。

并且测试尾部，而非中位数——在实体设备上这意味着在仿真中测试。失败案例从不是干净的运行，而是因为第三步的工具返回了模糊结果而导致需要十四步才能完成的运行，你无法在需要在每次尝试间冷却的手机上手动枚举这些情况。我的系统正是因此主要在仿真中训练：有趣的行为出现在长时间运行中，而长时间运行正是硬件不让你手动采样的。

这些都不需要更快的芯片。需要的是承认工作负载的形状已改变。没有人会出货电池只能支撑一次拍照的设备。我们仍在出货热预算只能支撑一次推理的设备。