AI 有一种很微妙的使用体验：你知道它能做很多事情，但把任务交出去之后，常常只能盯着屏幕等。
等第一句话，等它把话说完，等它查资料，等它重新想一遍。有时答案还没出来，人已经顺手打开了另一个网页。等想起这件事，刚才的工作思路也断了。
所以，看到今年 GTC 上关于推理的讨论，我更关心的是那些看起来不够热闹的问题：一次请求要等多久？很多人同时使用时会怎样？让 AI 连续工作几步，这些等待会不会越攒越多？
3 月 16 日，NVIDIA 公布了 Vera Rubin 平台的新进展，其中包括 Groq 3 LPX 推理加速系统。官方把它放在面向交互式 AI、追求快速且可预测的 token 生成的场景里。这也提供了一个观察角度：AI 基础设施的竞争，正在越来越细致地讨论用户怎样等到结果。NVIDIA 平台公告。
先把训练和推理分开。训练负责调整模型参数，让模型获得能力；推理则是拿着训练好的模型，处理一次具体输入。用户每发出一个问题，背后都需要重新完成相应的计算，已经训练过并不意味着回答可以直接从某个抽屉里取出来。
对常见的自回归语言模型，一次回答可以粗略分成两个阶段。先处理提示词和已有上下文，通常叫 prefill；再逐步生成输出，通常叫 decode。前者需要消化输入，后者的后续生成依赖此前的结果。两部分对硬件和调度的要求并不完全一样。
这也解释了“慢”的几种不同感受。
第一种是发出问题后，很久没有任何回应。这里常用的指标是首 token 延迟，也就是从提交请求到收到第一个输出 token 的时间。网络、排队、输入长度和服务端处理都可能影响它。对于会先做内部推理的产品，第一个返回的 token 和第一段可见答案也可能不是一回事。
第二种是已经开始回答，却一个字一个字往外挤。这时，生成过程的速度更影响体验。第三种则是同样的任务，有时很快，有时莫名其妙卡住。平均速度看着不错，偶尔一次很长的等待，仍然足以让人失去耐心。
这些都和另一项常见指标有关：吞吐量。吞吐量看的是系统在单位时间里总共处理多少工作。用户通常更关心自己的请求多久完成。两者需要一起考虑，不能看见整个机房每秒生成更多 token，就认定每个人都能更快拿到答案。
拿餐馆打个比方。后厨一次做一大锅饭，很适合提高整晚的出餐总量；但刚进店、只点了一碗面的客人，还要看自己的那碗排在什么位置。系统把更多请求放在一起处理，可能提高设备利用率，也可能改变单个请求的等待情况。
这不是谁的指标有问题，而是工作目标不同。半夜批量整理十万份文档，可以更看重总成本和总耗时；正在和人对话的语音助手，则需要把每一轮等待控制好。一个服务同时承担这两类工作，调度就会变得复杂。
Agent 又把这个问题往前推了一步。假设一个助手要完成任务，需要先理解要求，再搜索资料，读完结果后决定下一步，最后整理答案。串行步骤存在依赖，后面往往要等前面结束，模型调用之外还夹着工具和外部服务的耗时。
做一个纯粹用于说明的算术例子：如果关键路径上有八次串行模型调用，每次固定多等两秒，单是这部分就会增加十六秒。这还没有算搜索、文件读取或重试。真实任务的调用次数和速度当然不同，但累积方式很直观。
于是，在普通聊天中只是稍微影响心情的延迟，到了连续工作的流程里，就可能改变任务是否值得交给 AI。让它生成一份东西，等一会儿可以接受；每做一个小动作都得停下来，协作就容易变成看进度条。
NVIDIA 对 Groq 3 LPX 的介绍，强调了片上 SRAM、编译器调度和可预测执行，并提出与 Rubin GPU 分工处理推理工作。按照其技术说明，GPU 仍承担输入处理、注意力等工作，LPX 加速部分对延迟敏感的生成计算。这是一种围绕不同瓶颈组织硬件的思路。Groq 3 LPX 技术介绍。
这些设计能在什么负载下达到怎样的效果，还需要结合实际部署评估。发布材料里的性能提升有具体的比较对象和条件，不能直接换算成手里某个 AI 应用马上快几倍。模型、软件、网络和产品流程都会参与最后那笔时间账。
软件端同样有不少事情可做。早在 2023 年，vLLM 就围绕注意力缓存的内存管理提出 PagedAttention，目的是更有效地使用显存并改善服务吞吐量。推理优化既涉及芯片，也涉及数据怎么放、请求怎么排。vLLM 技术介绍。
对应用开发者来说，还有更直接的办法：少传无关上下文，能用确定性程序完成的步骤就直接执行，独立任务可以并行，简单判断也未必每次都需要最复杂的模型。用户只是要一个文件名，没有必要让系统先写出一段长篇分析。
我期待下一阶段的 AI 产品更认真地回答一个问题：用户从交代任务到拿到可用结果，总共需要多久？这里既包括生成时间，也包括中途干预、失败重试和结果检查。
当一个助手能稳定地在思路还没断掉之前交回结果，我们才更容易把它放进日常工作。推理速度的进步，最后应该体现在这样的时刻。
评论
还没有评论，来说点什么吧。