Why Static Evals Become Obsolete in Production — Ramin Hasani, Liquid A

Liquid AI 用线虫的 302 个神经元做模型灵感，把 600MB 的 AI 塞进奔驰车机，Shopify 每月跑过 10 亿次请求。

静态评测一进生产就会过期

Ramin Hasani 是 Liquid 的 CEO。他和现任 CTO 从维也纳工业大学的连续时间机器学习研究出发，2017 年受 Daniela Rus 邀请进入 MIT，把原本受神经系统启发的研究一路推进到可部署的基础模型。此后，他与 Matthias、Daniela Rus、Alexander Amini 等人共同推动 Liquid Foundation Models 产品化。Liquid 的特别之处不只是做了另一套模型，而是试图把“模型架构该长什么样”这个问题，交给真实芯片、真实数据和真实部署场景来回答。这期访谈里，Hasani 讲得最透的一件事是：AI 的战场不在发布那天的榜单，而在模型装进汽车、电脑、工厂之后，能否继续活下去、变得更好。

这期回答了 8 个问题：

1. 为什么一套看似可靠的评测，在模型上线后会迅速失效？
2. 模型架构到底该由研究人员预设，还是该由芯片和部署环境决定？
3. 为什么小模型反而需要更复杂的结构，大模型却要不断去掉“偏置”？
4. 端侧 AI 的第一驱动力究竟是隐私，还是云端推理成本？
5. 把模型塞进汽车或电脑后，为什么 benchmark 高分远远不够？
6. 企业能否把模型开发交给自助平台，而不再依赖大规模定制服务？
7. 机器人距离自己的“ChatGPT 时刻”，究竟还缺什么？
8. 多模态模型的下一个高价值场景，为什么可能是人类根本读不懂的数据？

被主持人追问“既然有好的 evals，为什么还要关心模型开发过程”时，Hasani 没有否认静态评测的意义。他承认，第一次把模型放进生产环境前，团队必须依赖一套固定测试来判断质量、能力和风险。但他立刻把问题往后推了一步：模型一旦上线，输入就不再是实验室里那批固定数据。新用户会带来新请求，老用户的行为会变，甚至某个社区会突然集体提出过去根本没出现过的需求。

他的原话很直白："because your evals are going to become obsolete. Static evals are going to become obsolete."（因为你的评测会过时。静态评测会过时。） 他举的不是“模型偶尔答错”这种小波动，而是大规模的 distribution shift，也就是数据分布变了：训练和测试时常见的问题类型，和生产环境里真正涌进来的问题类型不再是一回事。

这意味着，评测不能被当成一张拿到就永久有效的毕业证。它更像机场的雷达：飞机起飞前要检查，飞行途中也要持续刷新位置。团队真正要搭建的是数据、评测、训练和部署之间的闭环。生产数据暴露出新失败模式，评测标准要补上；评测发现模型偏离目标，训练和产品策略也要调整。静态 eval 仍然适合第一次部署，失效的不是它本身，而是把它当成永久标准的做法。

被问到 Liquid 如何把液态神经网络、state space models、卷积和注意力机制变成可扩展模型时，Hasani 先否定了一种很常见的创业叙事：找到一个“圣杯架构”，然后把它用于所有任务和所有设备。Liquid 的做法恰好相反。他们把 Hyena、state space models、Liquid neural networks 等路线的研究者和算子放进同一个搜索空间，让系统针对实际部署目标拼出混合架构。

这里的“算子”可以理解为模型中的基本计算积木：有的擅长处理长序列，有的便于并行，有的省内存。Liquid 的元系统会根据 GPU、NPU 或 CPU 这类目标设备，搜索不同积木的组合，并同时守住四个约束：质量不能明显下降、内存要更低、延迟要更小、计算速度要更快。Hasani 的总结是："the target device implies basically what should be that hybrid architecture."（目标设备基本决定了应该采用什么样的混合架构。）

LFM2 就是一个具体结果。它专门为 CPU 优化，约 80% 是 double-gated 1D convolutions，即带双门控的一维卷积；约 20% 是 group query attention。这不是“卷积击败注意力”，而是 CPU 的计算特征决定了这样的配比更合算。这意味着模型公司未来卖的不只是固定权重，更像是在做面向硬件的模型编译器：同一种能力目标，在不同芯片、内存和功耗约束下，应该生成不同计算图。代价也很明显：每支持一种新硬件、加入一种新算子，都要重新搜索、训练和验证，无法靠一个统一架构吃遍所有市场。

被问到架构搜索中有哪些直觉被实验推翻时，Hasani 给出的答案有点反常识。很多人会以为，大模型既然更强，就该堆入更多循环、门控和反馈结构；小模型资源少，反而应该尽量简单。但 Liquid 在候选架构上反复跑 scaling laws，也就是观察模型加数据、扩参数后训练表现的规律，得到的结论几乎相反。

在只有 8GB 内存等紧约束下，小模型可以加入多重反馈回路和更多结构复杂度。Hasani 认为，在约 200 亿参数以下，recurrence，也就是循环式计算，可能非常有效。它会把“上一步的信息”带到下一步，适合资源有限时榨出更强表达力。对音频这类天然按时间展开的数据，SSM、RNN 和连续时间系统也很合适；但他同样坦承，SSM 放到文本上表现并不好，甚至说它们“suck”。

他的概括是："the more biases you add to the system the more expressive dynamics you get in the larger scale you remove those biases."（你给系统加入的偏置越多，它的动态表达力越强；但到了更大规模时，你又要把这些偏置移除。） 这里的“偏置”不是道德意义上的偏见，而是人为塞进结构里的先验假设，例如“信息应当循环流动”“输入具有时间顺序”。这意味着小模型不能照抄前沿大模型：资源紧时，应该把任务知识写进结构；规模足够大时，低偏置、易扩展、适合硬件并行的计算形式反而更有利。复杂结构不是普遍更强，它必须和参数规模、数据模态一起看。

被问到为什么企业要把基础模型部署到数据中心之外时，Hasani 给出的第一答案不是隐私，而是账单。Liquid 正与 AMD 合作，让模型直接跑在笔记本上。他提到，全球每年约生产 3 亿到 4 亿台 AI PC，其中约 1 亿台可能由 AMD 提供核心硬件。与此同时，主流手机智能功能仍高度依赖云端：以 Apple Intelligence、Galaxy AI 这类混合方案为例，约 90% 的调用去云端，只有约 10% 留在设备上。

问题在于，如果一家公司要为 4 亿台手机，乃至数十亿用户免费提供智能功能，云端推理不是一个抽象的技术架构，而是一张不断累加的成本单。每一次调用都意味着服务器、带宽、电力和运维支出。把请求移到用户已经买单的设备上，相当于把一部分持续租金，变成一次性的本地计算能力。

这意味着端侧 AI 首先是单位经济模型的问题。当 AI 从付费增值功能变成默认功能，企业不可能让所有低风险、低复杂度请求都回传云端。隐私、离线能力、air-gapped 隔离环境和本地敏感信息过滤，都是端侧的重要附加收益。例如，用户准备把内容发给云端代码助手前，可以先让本地模型识别并过滤敏感数据。但边界也很现实：如今约九成调用仍在云端，恰恰说明端侧模型的能力和可靠性还不足以承接更多任务。省成本的前提，是本地模型先能稳定把活干完。

被问到 Liquid 的模型是否已进入真实业务、端侧模型如何量产时，Hasani 说得最重的一句是："production grade AI is like way more than just benchmarking the some quality benchmarks on the device"（生产级 AI 远不只是让模型在设备上跑过一些质量 benchmark。） Liquid 在过去两年半已经经历多轮生产部署，得到的教训是：模型下载下来能跑，和产品能长期稳定运行，中间隔着一整套工程问题。

端侧先要面对 thermal control，也就是热控制。模型持续推理会发热，设备受热后会降频，延迟和稳定性都可能变化。长上下文也是另一道坎：模型在短样本中表现正常，不等于输入拉长后仍能维持同样行为。汽车场景把这些问题放大了。Mercedes-Benz 是 Liquid 的客户之一，其车内多模态模型约 600MB，能连接摄像头、处理语音交互和文本推理。Liquid 计划先在北美全部第三代 Mercedes-Benz 车型上规模部署，运行它的芯片成本约 100 美元。

另一端是 Shopify。Shop App 已有 Liquid Foundation Model 提供服务，Liquid 称仅这一应用月请求量就超过 10 亿。这里的护城河不再是一张公开榜单，而是热控制、长上下文稳定性、OTA 远程更新、跨硬件验证和大规模真实运行数据。要留意的是，Mercedes 的部署在访谈时仍是计划。也正因为如此，生产难点常常不是发布前能否展示，而是上线后才暴露出来的可靠性问题能否被持续处理。

被问到 Liquid 的授权、定制和自助平台如何分工时，Hasani 描述了一条从“重服务”走向“自助化”的路线。早期客户会成为 design partners。Liquid 会配备 applied ML 团队，也就是应用机器学习团队，与客户一起开发方案，并对这一阶段收费；方案上线后，再按年或按设备收取模型授权费。一个垂直行业做出成熟方案后，后续客户需要的人工服务会减少，交付会更接近直接部署。

这背后是企业的真实疲惫。Hasani 说 Liquid 已与约 200 家《财富》500 强企业合作，看到许多公司自行下载开源模型、招人建团队，却仍未达到生产级交付。于是 Liquid 正测试 beta 平台，覆盖预训练、中训练、后训练、数据生成到 RL，也就是强化学习，目标是让企业自己拥有从模型开发到持续更新的流水线。

但他没有把“一键生成模型”说成终点。对于完全自动模式，他明确提醒："the quality of the resulting model is not going to be as good as when you're having an interactive kind of a developer actually interactively build something with it"（生成模型的质量，不会像让开发者真正交互式参与构建时那么好。） 这意味着企业未来不只是购买推理 token，而是逐步买回模型开发权；但近期最有效的形态仍是人机协作。自动化能降低门槛，却不能替代开发者对数据、目标和失败案例的判断。自助平台减少的是重复劳动，不是对专业参与的需求。

被问到多模态模型是否已经用于机器人，以及 world model 与 action model 是否必须采用不同架构时，Hasani 把问题拆成三层：模型架构、训练算法、数据处理机制。Liquid 已与 Rootech、意大利的 Gibbonics 等机器人公司合作，用视觉语言模型处理机器人本体摄像头输入，完成 instruction following 等 vision-action 任务。它们更多进入工厂和工业机器人场景，而不是直接押注人形机器人。

Hasani 的判断是，world modeling 更像算法问题，而不是一定要重造一套“机器人专属模型架构”。同一类 LFM 架构可以被放进 world-modeling pipeline，通过不同训练目标学习更好的物理世界表征。下一词预测让模型学会预测后续符号；世界模型则试图让它从观察中学到物体、空间、动作和后果之间更接近物理规律的关系。

但机器人距离自己的“ChatGPT 时刻”还没有答案。他的原话是："that's like a big big question mark on the algorithmic side"（这在算法层面仍是一个巨大的问号。） 这意味着下一次能力跃迁，未必来自给 Transformer 换个名字，可能取决于训练算法能否让模型稳定理解行动后果。Liquid 早期曾刻意放缓机器人业务，因为生产级机器人必须经过验证、确认和监管流程。如今模型成熟度和定制能力提升，才重新加速。即使算法取得突破，现实世界里的安全验证也不会自动消失。

被问到 Liquid 接下来的研究议程，以及小模型能否输出高质量视频时，Hasani 列出了几个方向：大规模多模态系统、更长时程推理、端侧助手的可靠性，以及从预训练到推理的效率基础设施。但其中最不寻常的一项，是 DNA foundation models。DNA 并不像文本那样由丰富词汇构成。Hasani 将其形容为只有 4 个 vocab，也就是只有四种基本“字母”，但序列长度极长的数据。

人眼可以读一句文字，却无法直接从超长 DNA 序列中看出结构和功能关系。连续时间系统和长序列处理能力，使 Liquid 自然把目光投向这类非人类可读的信号与生物数据。他说："DNA data could be like one of those places where where we can bring value"（DNA 数据可能会是我们能够带来价值的领域之一。） 这不是把多模态理解成“更会生成视频”。它指向的是另一种价值：让模型处理人类难以直接理解、但内部存在长程规律的数据。

Hasani 对小模型也没有过度承诺。对于 70 亿参数及以下模型，他承认它们无法输出高保真视频；但如果用 world modeling 训练，模型仍可能形成更好的内部物理表征。这意味着“理解”和“生成”是两种能力。模型未必能画出一段逼真视频，不代表它不能从视频中学到对动作和世界的更好表示。未来多模态竞争的一部分，或许不在内容生产，而在科学、工业和生物数据的表征能力。

“评测不是上线门票，而是必须持续重写的反馈系统”和“生产级 AI 的壁垒不在下载模型，而在可靠性交付”，其实在说同一件事：模型发布不是终点，而是它第一次进入真实世界。静态评测只回答“它现在能不能上线”；热控制、长上下文、OTA 更新和生产数据反馈，回答的是“它上线后能不能继续可靠地工作”。

同样，“不存在通吃的模型架构，部署芯片才是最终裁判”和“端侧 AI 的核心账本不是隐私，而是云端成本”也指向同一条主线。架构不是论文里的审美选择，而是由 CPU、NPU、内存、功耗和每次调用的成本共同塑造的。模型能否在本地跑，不只是体验问题，也决定一项免费智能功能能否被数亿用户长期使用。

Liquid 想争夺的，不是某一轮 benchmark 的冠军，而是基础模型进入生产环境后的持续演化权：硬件变化，架构随之调整；用户需求变化，评测随之重写；企业有了新数据，模型可以继续定制。对读者自己的团队也是一样。与其只问“该选哪个模型”，不如先问三个更难的问题：它会跑在哪台设备上？上线后谁来发现新失败模式？当数据和业务变了，谁有能力把模型一起改掉？