当开源小模型已经够日常工作用了，模型接下来靠什么拉开差距？

PingCAP 联合创始人兼 CTO、TiDB 发起人黄东旭认为，是速度。他做了十多年数据库和分布式系统，也是本地模型与 Agent 的重度用户，过去几个月里消耗了上百亿 Token。他在最近写的文章里提到，自己开始为了更快的速度，主动换掉更聪明的模型。

当每一次判断、调用和试错都快上十倍，原本需要扔到后台等待的任务，可能会变成实时交互。Agent 也不必先想出一套完整方案，可以快速尝试、拿到反馈，一步步逼近答案。App 交互、机器人控制，甚至产品形态，都可能跟着改变。

对创业者来说，值得提前想一想：如果模型再快十倍，你的产品会变成什么？

以下为原文内容，Founder Park 经授权转载自「我世界的源代码」。

好久没写文章了，最近实属多事之秋，一是比较忙，二是现在的 AI 行业进展快的有点科幻了，去年差不多这个时间我开始写公众号的时候，是万万没想到一年后的今天的世界是如此这般，但是情况就是这么个情况，我们能做的只能是奋力追赶。

我感觉大概从 2026 年 7 月开始，开源模型，尤其是小尺寸模型的智商已经跨越过日常 Agent 工作完全够用的水平，这个分水岭大概是在 8 月份 Qwen3.8_27b 开始的，去年的我是万万想不到一个 27b 的模型，在 Agent 和编程上能和有接近 Opus 这样水平的能力，之后的 DeepSeek_4.1_Flash_Next_1017 更是接近最前沿模型的能力（现在我能跑在一台 Mac Studio 上，大概还能有 40t/s 的吞吐）。

但是对我来说，真正震撼的事情是大概两个月前，我开始用 Strata（一个开源推理引擎）跑 Qwen3.8-Flash-Next。最开始用的是一张 RTX 3090，在我的配置上，每秒能达到 120t/s 左右。我当时已经觉得挺快了，后来换了 5090，用 Infernix（一个针对 5090 和 Qwen3.8-Flash-Next 定制的推理引擎）日常推理和 Agent 任务能跑到两百多的吞吐。这时候对我来说，一切都变了。

我自己的机器上本地跑 Qwen3.8-Flash-Next 的速度

还有个前提是，这一年本地模型确实进步了很多。以前在自己机器上跑起来，我会觉得这事很好玩，真要做点工作，还是会下意识去开云上的模型。现在整理一段材料，或者写个短脚本，本地模型给的结果很多时候已经能用。到了这个程度，我会真的为了速度换一个模型。这件事让我想起那句老话，天下武功，唯快不破。模型智商带来的体验提升的边际效应在收窄，未来影响用户体验的几乎唯一关键指标就是推理速度。

有这个感受的不仅仅是我，头部的推理服务厂商基本都发现了这个点。

Baseten 今年做 GLM-5.2 的快速版 API，有一个很具体的选择。他们把最大 batch size 调小了，这样同一批里争抢 GPU 资源的请求少一些，单条请求也就回得更快。代价是整套服务的吞吐会受影响，快速版的输入和输出 token 都贵了 50%，Baseten 赌的是重度用户可以专门为速度支付更多溢价（至少我是愿意掏这个钱的）。

Fireworks 最近公布的一组数字也可以放在这里看。他们的 Ultra-fast 预览版在 DeepSeek V4.1 Flash 上展示了最高每秒 1500 token。更容易理解的数字是他们自己测的一个 30 轮 Agent 任务，完成时间从大约一分钟降到了八秒。Agent 得先看到工具执行的结果，才知道下一步该怎么办，这些调用有不少是串行的。每轮少等一点，到了最后就差出一截。

我自己会拿一个很简单的标准来判断这种提速有没有用。假如我还愿意坐在原地看结果，出来以后接着做，那它就是个交互工具。等到我觉得应该先去干点别的，它在我这里就成了一个后台任务。而交互工具，速度就是最重要的指标，而且在我的使用中越来越明显的趋势是，如果交互工具的速度足够快，我是愿意把越来越多的原来定位为后台项目的任务放在交互工具中。，而且这个玩意就像吃辣能力一样，一旦你习惯了更快的速度，就再也回不去了。

顺着这个思路往前展望一下。

02

瓶颈不是智商，

是不够快

最近很多做 Robotics Lab 都有点焦虑，原因是 GPT-6 Astra 的发布，大家发现，好像似乎也不需要什么特别的给机器人训练的世界模型或者特别的 VLA 路线了，直接给机器人接个 GPT-6 Astra 就已经在很多任务上吊打专用模型了，例如 ROBOTIS 这个创业团队最近做了个实验，用 GPT-6 Astra 看摄像头画面和机器人的当前状态，然后让它通过工具调用给机械臂发指令。模型可以指定手要到哪个位置、摆成什么姿态，程序校验指令之后交给机器人执行。动作结束，新的画面和状态回到模型，它再决定下一步。团队用的是通用多模态模型，没有为这项任务单独训练控制策略。

这个实验里我最感兴趣的是 LLM 所在的位置，Astra 做的是看现场视频、推理，再通过 API 把决定交给机器。这个分工和一个 coding agent 挺像的。这就是为什么我说：也许我们不需要世界模型，只需要一个足够快的多模态语言模型。这个感悟就是来自这个实验。

ROBOITIS 团队提到，LLM API 响应延迟是他们遇到的问题之一。那我们不妨做个合理推论：保留今天这个模型的能力、摄像头和动作接口，只把每次看图到发出下一条指令的时间压到原来的十分之一，机械臂会变得多好用？

另外一个有趣的例子来自于模型，最近大家应该都听说过 Jev，它的出发点很简单，给模型一点上下文和几个现成的选项，让它只做选择题。比如一个 Agent 跑到一半，手上已经有几个候选方案，下一步应该先验证哪一个？最后返回一个选项就够了。这个判断可以是整个系统里很小的一步，做完马上接着执行。

这件事有意思的地方在于调用频率。一次选择要几秒钟，我可能只会在很重要的地方用它。假设一个任务有几十处类似的选择，每次都等几秒，整个程序都得围着这个开销来写。要是判断够快，我就可以在走到分支的时候做决定，用上刚刚拿到的信息。和传统的规则相比，它能理解一些很模糊的条件。

这样一来，做 Agent 的时候就有了一个我觉得挺自然的分工。碰到一个新问题，可以让强模型先看一遍，提出几个办法。执行过程里频繁出现的小判断，交给低延迟的选择模型。比如哪条路先跑一次，看到这个错误后值不值得重试。只要这些判断的质量过关，系统就可以用它们把反馈接回去，强模型也不用在每个小分支上重新想一遍。这个架构能不能成立，很大程度上取决于一次选择究竟有多快。

03

快是一种方法

最典型的例子是：试错。写程序的时候，如果一个测试几百毫秒就跑完，我通常会很快试一版，看看结果再说。如果每次改动之后要等一个小时才能知道对不对，动手之前我就会多想一会儿。同样一个人，面对不同的反馈速度，会用不同的办法解决问题。Agent 也可以这样。它如果能很快改出一个版本的行动，又能马上在环境中（例如 sandbox）里跑起来得到 test-time 的反馈，那么传统的长程的思维链是否还有必要？我在我自己的本地模型的使用场景中，经常有类似的体验：头部模型思考半天，写了个脚本 one shot 达成目标，但是可能花了 2 分钟；本地模型快速的尝试了 5 轮，可能前四种方法都有问题，但是一步步从错误中逼近正确答案，最后这个过程可能只花了几秒。

强化学习里有个类似的问题。训练需要先让模型在环境里跑出一批轨迹，拿到奖励，再用这些数据更新模型。假如时间大多花在生成轨迹上，推理提速以后，同样一小时能拿到更多轨迹。比如训练一个会修代码的 Agent，可以让它尝试修改代码，用测试结果做反馈。模型生成一轮改动和工具调用的时间短了，在测试设施还能接得住的情况下，下一批训练数据就来得更早。对我来说，这里的收益首先是训练跑得更快。

我觉得这件事可以和做机器人的例子放在一起想。在真实机械臂上，多做一次尝试有实际的时间和设备成本。在模拟器里，有些动作可以很快重来，也可以让很多个实例同时跑。一个 Agent 有没有机会从尝试里学到东西，跟它接入的环境有很大关系。过去我们会花很多时间让它先想清楚再行动。有些任务里，如果行动的结果很快能看见，而且容易恢复，那这部分时间就应该交给 AI 进行实际的尝试，在这种场景上，速度就变得很重要了。

04

快会改变产品形态

就举个最好理解的例子，过去做 App，页面和交互基本都是开发者提前写好的。天气会变，搜索结果也会变，但显示这些信息的页面是固定的。用户要做一件事，通常得在 App 已经提供的页面里找一个合适的入口。

如果有一个足够快的编程模型，界面就可以在用的时候生成。比如我在规划周末出游，聊着聊着想比较几个地方，App 可以当场生成一个能操作的比较界面。我改了主意，界面也能跟着调整。这一页是在我需要它的时候才出现的。

这里的速度得快到能跟上交互。要是每生成一个界面都得等半分钟，这更像是让模型临时给我写个小工具。要是界面能在我接着操作的时候就出来，实时生成 UI 就可以成为 App 平时的工作方式。

这种完全动态的应用交互体验一定会催生出新的产品形态和商业模式。但是这一切的起点是一个足够快的模型 :)

以前我会把想做的事攒一攒，一次交代清楚，省得来回等。现在有个念头就先试一下，看到结果再说，跑个两轮，发现效果不错，就接着做了。很多时候要我一开始就写需求，我大概压根儿想不到自己会需要这么个东西。

所以现在做 AI 产品时，不妨经常多问自己一句：今天的模型要是能快十倍，会改变什么？