周三下午，一个工程师对着成本报表愣了很久。Cerebras上的推理速度快得不像这个时代，但账单上的数字让他清醒过来——没有缓存，多轮对话的成本是竞争对手的40倍。

这是RapidNative团队的真实处境。他们把智能体跑在Cerebras上，GLM 4.7的流式输出"第一次让人感觉像未来"。但产品复杂度的膨胀和成本结构的残酷，把技术理想拽回了地面。

打开网易新闻 查看精彩图片

事情是从简单到失控的。最初的RapidNative一次只生成一个组件：一个模型、一份系统提示、一块屏幕输出。整个系统能装进人的脑子。但真实应用需要规划模式、子智能体、MCP服务器、可组合的技能。团队自己造了一套，结果"系统变得嘈杂"。

与此同时，Claude Code、OpenCode、Flue（Astro作者的新项目）不约而同走向了同一套架构：技能、子智能体、规划模式、MCP。行业标准正在收敛，RapidNative的自研方案成了"更差的版本"。

真正的冲击来自成本核算。Cerebras目前不支持提示缓存。在RapidNative或OpenCode这类编码会话中，每一轮都要重发完整对话历史。有缓存时，只需为新token付费；没有缓存，每一轮都要为全部历史买单。

同一模型（GLM 4.7）的对比数据：支持缓存的供应商 versus Cerebras，会话进行几轮后，token成本差距约40倍。

速度很重要。但没那么重要。

团队现在的解法是把智能体拆成两半，都留在Cerebras上。主智能体跑GPT OSS 120B，单token成本比同平台的GLM 4.7低5-6倍。缓存缺失的问题还在，但更便宜的单价缓解了长对话的失血。屏幕生成子智能体继续用GLM 4.7，短上下文、单次输出，速度是核心卖点，没有长历史需要重发，缓存缺失的伤害有限。

同一个供应商，不同模型对应不同子任务。推理正在从单一端点变成路由器。

这不是撤离Cerebras的计划。恰恰相反——在他们上线缓存之前，用更便宜的模型对冲长上下文成本，是一种权宜。一旦Cerebras支持提示缓存，40倍的差距会瞬间抹平，眼下这套架构折腾也就失去了必要。

团队最期待的事很明确：Cerebras加上提示缓存。在那之前，同平台换用低价模型是正在评估的过渡方案。

技术选型永远是在多个变量间找平衡。速度、成本、功能完整性，很少能同时满分。RapidNative的困境和应对，其实是AI基础设施成熟期的典型样本——当底层能力出现阶段性盲区，应用层只能用架构复杂度来换生存空间。

缓存会来的。问题是，多少团队能撑到那时候，以及为此要付多少学费。