缓慢的开发体验将成为快速模型的瓶颈

2

目前开发者的体验以秒为单位。如果你的测试运行需要一秒钟,那很好;如果测试需要三十秒,那就不好了。超过一秒其实没什么影响,因为你大部分时间都在思考或等待AI代理的启动。

把开发服务器的加载时间缩短几毫秒毫秒之类的,没必要:那不是瓶颈。

会的。小模型越来越快,智能模型也越来越小。我认为大多数工程师仍会选择最智能的模型——软件工程很难——但我们会越来越多地看到更快的模型被用作子代理或被广泛理解的任务。

这在很大程度上是未知领域。很少有人对与以数千个令牌每秒运行的代理工作有直观的理解。

GPT-6-Astra 的运行速度大约是六十每秒代币数。这意味着你花了很多时间等待它思考。你像对待另一个人一样与它合作:委托一个任务,然后切换上下文直到任务完成。

如果你还没尝试过,可以试试吉米,Taalas 版本的 LLaMA-3.1-8B 运行于每秒一万七千个代币.无论回复多长,它都会在你按下发送的瞬间到达。

这个模型还不够好用于代理工作,但它让人一窥它的样子:你会立刻得到答案。

当然,这还假设代理的工具调用速度快。当生成令牌不是瓶颈时,它是否能在100毫秒内读取文件,或者能否在500毫秒内完成测试,或者在2秒内完成测试,这会变得非常重要。

快速的工具调用将决定你几乎是即时响应,还是需要等待几分钟。因此,在像Golang这样拥有快速编译器和测试的语言中进行代理编码,并且要严格优化代理代码库中的开发循环,压力会非常大。

专注于DevEx——开发者体验的团队——在很大程度上是2010年代的遗物,那时的公司激励为了让他们的工程师满意。大多数公司已经将他们削减到骨干团队,甚至完全撤销。

但我们可能会在2020年代末看到DevEx的回归,专注于加快AI代理的体验。


  1. 像大多数超高速推理一样,它依赖于将整个模型安装在一个专门设计用于推理的巨大GPU芯片上:对于Taalas来说,推理存储在硅片本身;对于Cerebras和Groq来说,它存在于巨大的内置内存单元中。
  2. AI提供商会不会只是训练模型让它们花更多时间推理,让用户得等差不多的时间?我怀疑。大多数普通工程问题不会因为多花一百万代币思考而解决得更好。只有当你在模型极限前方才需要这么做。
参与讨论