为什么模型跑在另一台机器上

为本站提供服务的那台机器上，没有跑任何语言模型。摘要是在第二台设备上算出来的，它去取任务、做完计算，再把句子送回来。

理由是算术。一个 3B 模型占用一个多 GB 的内存，每次回答要花几秒。而整个应用里最重的一次数据库查询是 581 毫秒。把两者放在同一块板子上，意味着 379 000 个计数器的图片要排在一个文本生成器后面等——而它们才是真正的产品。

代价和收获

代价是一台第二机器和一条队列。任务最多一次发出二十个；队列有上限，满了就不再产生新的——已经写好的句子照常显示。一份一周前的摘要，可以。一份缺失的摘要，可以。一个因为同一块板子上有别的东西在思考而变慢的统计页面，不可以。

换来的是：计数这条路径永远不会和不可预测的东西共用一台机器。画一张计数器图片是一小份有边界的工作。生成文本不是：这里实测一句话的跨度从 5,4 秒到 54,3 秒，快慢之间差十倍，而这些树莓派事先一点也看不出来。

这是必须在动手搭建之前就定下来的部分，因为它是事后没法补救的那一部分。

第二台机器只收到那些在计数器自己的统计页面上本来就公开的数字，而且只来自统计页面本身就是公开的计数器——不是私密的，也没有加密码。这个 worker 不会知道任何一个访问那个页面的人打开它就读不到的东西。

这不是代码碰巧写成这样带来的幸运副作用。候选查询就是按这个过滤的，而没有这道过滤，整个功能就是把别人的数据交到第二台设备手上。不存在哪一版「我们会小心处理」，能好过：不要发出去。

从这件事里长出了两条规矩，它们比这个功能本身更值钱。

无界的工作不该待在有界的路径上。凡是运行时间无法预测到一个数量级之内的东西，就不该待在那台必须以毫秒作答的机器上。不是「一般都还行」——要紧的是慢的那种情况，而它总会到来。

先决定什么可以出去，再决定要造什么。如果答案是「worker 也需要那些私密计数器」，正确的反应不是把传输加固。正确的反应是：这个功能不覆盖私密计数器——而它做的正是这一点。