难而正确

这两天梁文锋的四小时讲话挺火的.

大致看了下有点挺有意思的.

一个是谈到对sota模型的理解.

按照讲话时间一个月前的话,应该指的是fable/mythos的激活参数量.

大概在800B左右.

这里比较有意思的是他关注的不是总参数量,而是激活量.

换个角度来说,目前scaling的方向即使还在参数量上的话,应该也是在激活参数部分.

用他的话来说,几百B的模型目前不是训练不出来.

而是可能是推理成本太高.

因为激活参数量带来的计算需求在当前的硬件水平不能很好地scale.

用这个视角看最近的gpt 5.6和fable/opus 5的话,也就能理解的.

各个尺寸和型号背后可能对应的就是不同激活参数的同一个基模了.

甚至可能本身就是某种动态裁剪MoE的结果.

对于国产模型来说的话,他的定位或者说最好预期可能也就是明年能出一个大概150B左右激活参数规模的模型.

也就是从纯参数量上来说,到时的国模sota总参数量跟国外SOTA可能还是会存在一个数量级的差距.

目前最近的GLM和Kimi激活参数量是大改在50B左右的.

相比DeepSeek V4 Pro的30B的规模大概是翻了一倍.

交叉一下,再用六个月的时间国产模型翻倍开始上100B也算是合理预期.

当然,这里可能还有点意外就是看Google会不会出一个新的模式.

毕竟按照当前Gemini 3.5的难产和Gemma的尝试非传统transformer模式来看的话.

Gemini直接4.0然后出新架构的可能性还是有的.

尤其考虑到相当一部分Transformer时代的人已经出走Google了.

往新架构迭代的思路上考虑的话,就很正常了.

不过即使有新架构,按照资本支出和全新架构推理芯片的研发消息来看,可能算力需求不一定会有下降.

或者至少计算推理模型可能会需要一种全新的方式,不然直接搞一个新芯片方案也不算合理.

毕竟TPU也迭代了几代了.

而说到芯片,就不得不说这篇讲话里另外一个有趣甚至于说是重点的部分了.

看得出来对某国产芯片厂商是有相当大的怨气的.

一方面可能是店大欺客的不被尊重感.

毕竟反复提到只给了DeepSeek一万多张卡,相比其他互联网公司20w的级别来说,可能确实有点侮辱人了.

尤其以DeepSeek当前的行业影响力来说.

而会被如此对待的原因可能也很简单.

可能纯粹就是从公司规模上来说,DeepSeek是家所谓的小公司.

因为没有明确的现金流和市场估值.

从纯粹资本角度来说,DeepSeek就像是诸多无名或者稍有名气的初创公司.

商务上可能不够成一个值得投入大量资源的公司.

所以某种程度上来说,梁文锋要公开市场化融资的一个直接原因就是这个.

通过市场化的估值去获得某种对等或者说应有的话语/谈判权.

而这里也某种程度上折射出他的某种解决问题的思路.

那就是他可能本人对这家公司也并不太喜欢.

但是他还是选择了这家公司作为某种vision的一部分.

就像他反复宣传的要用TileLang取代CUDA,用国产卡替换N卡.

非常符合鸡汤文化里的做难而正确的事这个人设.

当然,这个不妨碍他在这场面向投资人的会议里反复阴阳.

甚至当场说出虽然性能四换一,但是只要产能够,成本是N卡的两倍,预期卡寿命N看5年,该卡2年不到也是值得的皮里阳秋式发言.

结合之前坊间传闻的v4因为适配问题不断延期的说法.

算是实实在在的从精神到物理层面的做难而正确的事了.

不过从这个角度回头看v4 flash和v4 pro的话.

倒有可能v4 flash反而是用国产卡,而pro是用的N卡.

因为按照flash的参数量来看的话,倒是符合卡资源量.

以及推理速度上来说,符合专门优化的体现.

也符合pro没有量大管饱这一现象.

因为还需要N卡资源做其他的事.

尤其他在开始谈到的缺卡问题.

一方面是训练和面向终端用户的推理需求.

另一方面是可能更为关键的,用来做原型和实验的部分.

国产卡可能在生产场景是可替代了的.

但在更为复杂的迭代和探索过程,成熟的可能还是相对欠缺的.

所以实验卡更需要一些成熟稳定的硬件,去屏蔽解决非核心问题上花的时间.

而卡数量这方面,猜测可能20w卡的互联网大厂应该就是最近官宣国产集群的LongCat了.

当然,这个可能还是有一点信息滞后的.

毕竟讲话时间是在一个月前.

而且最近950超节点也官宣了.

按照之前的计划也是今年下半年开始量产.

所以这个20w卡的怨念应该也还是在产能爬坡前的有限范围内的供给问题.

不过按照他对SOTA模型需要5w张B卡的说法.

也就是DeepSeek可能需要大概20w张950.

这个能不能有,也确实有点未知数.

毕竟这个几乎就是之前全世界所有的卡数了.

最后一个比价有意思的就是他的成本和商业观念.

字面上看他对API的成本理解就是纯粹的卡成本投入.

所以有定价是10个月回本的说法.

而按照这个反推,也就是目前OpenAI/Anthropic的定价是一个月收回卡成本的.

这个和当前市场理解的AI Capx是有相当程度出入的.

假设双方的理解都是对的话.

那么这里imply的就是算力卡在整个AI算力支出上是一个可以忽略的部分.

大头可能是在数据中心本身和能源供给上面.

甚至还可能是意想不到的房地产和合规/ESG开支上面.

这样的话,中美的的AI成本和发展就存在着fundamental的不同了.

后期是如果考虑障碍在后者的话.

基于这点反观限制开源模型竞争的言论的话,倒是有自洽的地方的.

因为frontier的边际能力和卡限制不足以弥补其他方面的成本差距.

所以它关注的不再是模型能力差距本身,而是使用者/用户群的归属问题.

这就有点像夕阳行业里的存量竞争状态.

能活下来的是具有成本优势的.

而显然,在AI叙事的实际ROI存疑的前提下,成本的差距会更加放大这种用户选择.

当然,这个假设成立有一个隐含前提就是,DeepSeek口中的十个月收回成本对其他人也成立.

毕竟除了模型能力本身,DeepSeek的infra能力它的护城河之一.

而且梁文锋很明显地知道这个是他独有的商业模式之一.

没有其他人host的v4能跑出DeepSeek的性价比和效率.

而这点可能是其他国产模型需要思考的地方了.

尤其当你还是依赖N卡算力的时候,模型即使SOTA了,但是你自己不能够host.

或者没有足够资源host的时候,是无法变现的.

因为国外的云厂商有着更多的资源和更合规的使用手段.

最后就会演变成某种形式的中国制造叙事的反面.

国外有着更便宜的基建去host你的模型,使得你自己的产品在更广泛的市场上不具有任何竞争力.

从而活不下去.

这对于国产模型公司来说,可能是一个非常惨痛和可惜的结果.

因为这条全链路国产化本来是一条一荣俱荣一损俱损的道路.

虽然难,而正确.

少即是多

前段时间又把未完成的AgentCLI翻出来继续vibe了一下.

主要是GPT 5.6出来了,顺手当作测试.

而且也确实有一些新的想法.

比如在模型能力持续增长的情况下,Agent Loop这类概念应该也是会像prompt/skill之类的被渐渐内化的.

而且本质说来说,loop不loop其实还是一个workflow的问题.

而这个问题DSL算是最直接的解决方案了.

所以就打算让AI写个(ASL)Agent Script Language.

然后用这个ASL去生成workflow/loop,程序化地跑起来.

核心就是两个个meta function,session和llm.

sessino用户生成独立上下文.

llm接受session和prompt,约定一个返回类型.

大致比如

···rust

let session = session()

loop {

   let review = llm(session,"review this project")

   if review == "ok" {

      break;

   }

   

   ....

}

...

···

这里有个小插曲就是一开始没切model.

默认让v4 flash跑的.

然后发现它思考了下,开始自己创造parser和一些基本的condition expr.

出来的版本至少compile和简单的run是没什么问题.

不过还是比较primitive,以及语法特性其实也还不够丰富.

发觉模型没切之后换到gpt 5.6思考了下倒是知道一个叫rhai的库.

确实一下让实现的工程性提高了不少层次.

原本可能需要实现一套语法的,现在变成了直接是rust script加核心的几个meta host function就行了.

这里模型内嵌知识量的差距就出来了.

而且这个方案的优势可能是容易被llm理解.

因为不是什么独创语法,所以更容易被正确地生成合法的script.

不过这都是建立在这个东西最终可用的基础上.

这里想说的是一个测试过程发现的感觉比较有意思的点.

在eat dog food的测试里prompt让llm去review当前project,以让它更现代化和agent友好.

然后看了下gpt 5.6生成的rhai.

主要是四个独立的session/context.

architecture reviewer.

safety and correctness reviewer

agent experience reviewer.

还有最后一个implementer,把前面几个personality/role的输出拼接到成一个大的context.

流程上说一系列的pre build check和implementer session.

以及对应的post check/verify以及可能的error recovery routine.

大致来说,基本可以认为agent能力是内化到模型自身了的.

有没有专门的agent loop支持理论上来说区别可能都不大.

要说唯一可能的区别就是agent tool可能因为上下文物理隔离/没那么长了,所以同样的参数设置下能主动生成的长度更长更持久罢了.

而可能的副作用也正是由于上下文隔离,可能有些东西会反复被subagent重新发现/产生矛盾决策/选型.

接着是同样的prompt给opus 4.8.

session使用上大致跟gpt 5.6是一致的.

也是

modernizer.

agentizer.

safety.

documentation.

稍有不同的是会由独立的architect,把上面的组成一个大的context.

然后proposed agent把architect的写成文档记录.

所以从行为上来说,这也比较符合anthropic一直鼓吹的plan first类似.

属于把文档当checkpoint/offload上下文的做法.

另外一个跟gpt 5.6的区别就是多了一些helper function.

主要是用来做一些read/write工具容错的.

基本上是用于捕获异常状态/原因.

所以某种程度上也是为了丰富上下文明细的.

而且有一点跟当初Claude Code Leak的prompt一致的就是,会有一段捕获当前系统状态,

包括git提交commit,文件目录结构,配置快照,塞到每个session的system prompt里的行为.

所以从这个角度上来说,opus可能对于上下文的完整度比gpt 5.6有着更苛刻的要求.

接着可能是更加有趣的国产模型的一些行为表现.

首先是v4 flash.

v4 flash生成形式上来说跟gpt 5.6和opus 4.8的是相似的.

之所以说是相似是因为它有个比较严重的问题.

从行为上来说,v4也是产生了几个独立session.

但不是分角色,而是分模块地去分析.

这点跟使用它的感受是一致的.

就是很少会真地去delegate到agent,基本上都是要在同一个context里尽可能完成所有事情.

或者说,它的delegate意识不是按照角色/目标这种逻辑切分的.

而是简单的scale out的切分.

然后逻辑上来说它应该是准备gather这几个分模块的输出汇总到一个planer里.

类似gpt 5.6/opus 4.8那种大context解决问题.

甚至于它的结构可能是最优的.

因为是很典型的效率为先的fork-join-fork的并行模式.

即

```

for crate in 0..crate.len(){

   let session = session()

   sessions.push(session.llm(...))

}

let plan = session()

...

for step in 0...steps{

  let worker = session()

  workers.push(worker.llm(...))

}

// verify

...

```

这种形式上并行化的处理方式.

看起来很promising.

但是它的问题是,plan哪个session其实并没有把按模块的信息汇总拼接起来处理.

也就是说,v4 flash虽然可能很聪明,但是会存在注意力缺失的问题.

比如这个例子里就把critical的汇总部分给遗忘了.

导致前面都变成的无效token消耗.

完美不会对后续产生任何增益.

感觉这个可能是跟deepseek的几个重要工程优化,比如DSA带来的副作用了.

这个就可能导致有时候觉得多快好省.

有时候又不太理想的原因.

剩下两个要放一起的是glm 5.2和kimi 2.7 code.

之所以要放在一起是因为它们的输出跟前面三个是完全不一样的.

从用户角度来说,属于意图识别错误.

而且有趣的是,错误的方向都是一致的.

前面说了,prompt是review当前project,以让它更现代化和agent友好.

kimi和glm有点不约而同地把agent友好理解为让项目维护更容易被agent接入.

而不是项目本身,作为一个agent cli也好,一个ASL plugin/扩展也好,更容易被其他agent工具接入.

这个往好点说,就是用kimi和glm可能对怎么写mcp之类的会更有想法.

毕竟之前作model tone比较大时候,kimi确实会更喜欢有事没事用tools解决.

抛开生成的脚本目的来看,单谈结构.

kimi的会更类似opus.

subagent的输出一般都会写成文档.

或者说kimi更喜欢通过文件交互.

比如像为了让agent更容易参与到代码提交,写了一个CONTRIBUTING.md.

又专门的agent guideline章节.

而这个文件是直接在脚本里通过write file写出去的.

而不是通过比如可能opus的话会开个subagent去做这个事情.

所以这里的行为其实有点类似v4 flash.

也是什么都在一个context搞定.

但是会留存记录.

可能是作为一个agentic fallback交流机制?

而glm 5.2与其说也是类似opus不如说是更像claude code.

因为它也是会把一些固定context追加到每个session里.

加上它也是喜欢把subagent的输出写到一个文件.

所以形式上来说,glm更像是opus的某种全方位行为趋同.

因为虽然kimi也会追加上下文.

但一方面kimi较少直接subagent.

另一方面,唯一的一次subagent也是当作某种高级的tools调用的.

或者类似explore agent的使用.

不管怎么样,总的来说,Agentic/Harness这个东西,在外围可能确实没什么能做的了.