2026-09-19

今天的三条消息来自完全不同的场景，却在回答同一个问题：系统怎样把“看起来会做事”变成可以交代、可以比较、可以承受真实约束的能力。 Vercel 将下一步选择从生成模型中拆出，NVIDIA 先清理压测器本身的噪声，Google 则把物流里的等车、转运和容量上限放回公开基准。它们共同说明，AI Infra 的进步往往不发生在模型回答得更漂亮时，而发生在控制、测量和问题定义终于不再被省略时。

头条｜Jev：把“下一步做什么”交给一个可检查的决策层

Vercel 在 9 月 18 日公布 Jev 上线 AI Gateway 后首 24 小时的数据：近 13% 的付费团队已经试用。更值得留意的不是这个采用比例，而是 Jev 刻意不承担生成任务——应用一次提交上下文和多个问题，它并行返回带概率的 choice、score 或布尔判断，用于选择工具或子代理、决定重试/终止、分流风险，以及把低置信度样本升级给人工。

这相当于把长链 Agent 最容易失控的岔路口从自然语言 prompt 中抽出来。内容模型继续写和推理；决策层则留下阈值、置信度和实际动作。于是“为什么没有继续调用工具”“为什么这一步转人工”可以成为观测事件，而不只是事后生成的一段解释。首日采用并不能证明决策质量或成本优势，更不能把结构化输出误当作风险判断正确；真正的生产门槛仍是错放行/错拦截率、校准误差和低置信度回退是否被持续记录。 Vercel：首日采用与使用场景 · Jev 接口与限制

量准了，优化才有意义｜AIPerf 不让压测客户端替服务端背锅

NVIDIA 同日发布的 AIPerf 是一个看似朴素却必要的补丁：在高并发下，Python 客户端、GIL 和流式事件采集本身就可能成为瓶颈。如果负载发生器先饱和，“模型 A 比模型 B 快”的结论其实是在测客户端。AIPerf 将负载、记录处理和协调拆成多进程服务，通过 ZMQ 协作；它既能固定输入/输出长度，也能回放真实 trace，并把到达过程控制为常数、Poisson 或 gamma。

这使一次基准测试有机会成为部署证据，而不是宣传中的单个 tokens/s：TTFT、ITL、请求延迟和吞吐可以按分位数给出，GPU 遥测和完整配置随 CSV/JSON 留下。使用它时，先固定端点语义、tokenizer 和 streaming 配置，再导入自己的长度分布和流量峰谷；若客户端 CPU、失败率与队列长度没有一起被记录，服务端吞吐的“提升”依旧无法解释。 NVIDIA：架构、负载模型与指标 · AIPerf 原仓库

公开基准也要有摩擦｜MilleMiglia 把现实约束带回问题本身

Google Research 开源 MilleMiglia 时，重点并不是一个新的求解器，而是一套更难被“简化掉”的中程物流实例。它以空间聚类和重力模型生成中心与需求，用结构化车辆轮转而不是随机边来模拟班次，并把节点表示为“某个中心在某个时间段”：车辆移动、仓内等待、分拣和合流都是同一张时空图里的边。

这种建模的意义在于，物流系统真正棘手的部分恰恰是经典 VRP 常会略过的东西——固定时刻表、转运容量、前序到达对后续发车的限制。把它们写进公开、可复现的实例，学习型启发式、运筹求解器和 Agent 工作流才可能比较成本、延误与不可行率，而不是各自在私有数据和被磨平的假设里取胜。生成器本身不证明任何调度器更优；接下来要看的是合成分布与真实网络之间的偏差，以及规模上升后评测协议是否仍可复现。 Google Research：问题建模与生成器 · 代码与实例格式