廉价生成需要昂贵账本

今天 HN 上几篇内容，读起来像是同一个系统的不同切面。

一篇叫《Human Routers of Machine Words》，语气很重，几乎是在骂所有把 AI 输出原样发到公共空间的人。另一篇《AI Coding at Home Without Going Broke》讨论个人如何低成本使用 AI 编程：自建机器、租开源模型 API、组合 frontier subscription。TensorZero 的 README 则把 LLM gateway、observability、evaluation、optimization 和 experimentation 合成一个 LLMOps 平台。还有两篇更偏硬件：一个人用 RTX 5080 加 RTX 3090 跑 Qwen 3.6 27B Q8，调到 80 tokens/s 以上；Google Research 介绍 UCSD 用 2000 台退役 Pixel 手机做低碳计算集群。

它们的共同点不是 AI 很强，而是 AI 让"生成"变便宜之后，账本变复杂了。

过去内容和代码的生产成本很高。写一篇文章、写一段代码、搭一套推理环境、部署一批计算节点，都需要明显的人力或资本投入。成本高本身会形成一种过滤。你要写，就得想清楚；你要买 GPU，就得算回本；你要部署服务，就得关心利用率。

现在过滤层被削薄了。AI 可以把模糊想法迅速变成文章，把规格说明迅速变成代码，把一次长任务拆成许多自动步骤。云 API 和订阅把前期硬件成本变成月费或 token 费。本地模型和开源权重又让个人可以绕开部分云端限制。生成变轻，实验变快，试错成本下降。

这当然是好事。但问题是，很多成本没有消失，只是换了位置。

《Human Routers of Machine Words》最尖锐的部分，不是它讨厌 AI 文风，而是它指出"写作就是思考"。作者反对那种说法：想法是我的，文字只是 AI 生成的。他认为想法并不是先在脑中完整存在，然后由文字机械表达出来；相反，写作过程本身会迫使人发现因果断裂、概念混乱和取舍矛盾。你写下"因为"，突然发现自己并不知道原因；你写下"因此"，才发现推理链不成立。

这点放在软件工程里也一样。很多设计问题只有在你真正写规格、写代码、写测试时才会暴露。模糊想法总是美好的，因为它可以同时拥有互相冲突的优点；具体实现只能选择一种形状。AI 如果直接把模糊输入包装成顺滑输出，就可能跳过这个必要的摩擦。

于是成本转移到了读者身上。作者没有完成的澄清工作，变成读者要在每一个"因为"和"所以"里重新审计。一个看似完整的 AI 文本，可能只是把没有想清楚的 bullet points 抹平。它降低了输出者的成本，但提高了公共空间的验证成本。

这和前几天写到的"请求别人注意力时，要展示人类努力"是一条线。注意力不是免费的。AI 让生成成本下降，但没有让判断成本下降。你把未消化的 AI 输出交给别人，等于把思考债务转嫁给对方。

《AI Coding at Home Without Going Broke》则讨论另一个账本：AI 编程的成本账。作者把个人 AI coding 分成三种方式。第一种是自建机器，买硬件跑开源模型，之后不按 token 付费，但前期成本高，而且家用硬件很难长期满载，今天买的配置明年可能就落后。第二种是租开源模型 API，避免押注硬件，随时切换更便宜或更强的模型。第三种是组合 OpenAI 和 Anthropic 的 frontier subscription，用几百美元订阅换取远高于标价 API 的使用价值，但这适合人工驱动的高价值任务，不适合全天候 agent。

作者给出的实践建议是混合：frontier 模型负责 hard thinking 和 spec writing，便宜模型处理机械实现。用规格驱动开发，把昂贵模型用于计划和判断，把便宜模型用于填充和执行。

这个建议比"本地还是云端"更现实。AI 编程不是单一任务。规格设计、架构取舍、bug 定位、代码生成、重构、测试补齐、文档更新，它们对模型质量、上下文长度、延迟和成本的要求不同。把所有任务都丢给最贵模型，是浪费；把所有任务都丢给便宜模型，是把风险埋进代码里。

所以真正重要的是路由。哪个任务值得用 frontier 模型，哪个任务可以用开源模型，哪个任务必须人工判断，哪个任务根本不该自动化。AI 工程的成本优化不是简单地找最便宜 token，而是把不同层级的判断和执行放到正确位置。

TensorZero 的价值正在这里。它不是单纯的模型网关，而是把 gateway、observability、evaluation、optimization 和 experimentation 放在一起。README 里强调统一访问不同 LLM provider，存储 inference 和 feedback，评估单次推理或端到端 workflow，用真实生产指标优化 prompt、模型和推理策略，并支持 A/B testing、routing、fallback 和 fine-tuning 数据生成。

这说明 LLM 应用的账本不能只在账单系统里。你不能只知道这个月花了多少 token，还要知道这些 token 产生了什么结果，哪些请求成功，哪些失败，哪些 prompt 版本更好，哪些模型在特定任务上更划算，用户反馈如何回流，评估集是否代表真实场景。

没有这样的账本，AI 系统很容易陷入一种幻觉：看起来生成很多，实际不知道质量；看起来省钱，实际把错误转移给客服、工程师或用户；看起来模型升级了，实际某些工作流退化了。便宜生成如果没有反馈闭环，会制造便宜噪音。

这也是为什么 LLMOps 不只是运维。传统运维关心可用性、延迟、错误率和成本。LLM 应用还要关心输出质量、任务成功率、评估漂移、prompt 版本、模型路由、用户反馈和优化实验。它需要把"生成结果是否有用"纳入系统指标。

本地双 GPU 那篇文章把账本拉到硬件层。作者用 RTX 5080 和二手 RTX 3090 组合，在 Qwen 3.6 27B Q8 上跑到 80 tokens/s 以上。文章细节很多：主板要能把 PCIe x16 拆成双 x8；BIOS 里要关 CSM、开 Above 4G Decoding 和 ReSize BAR；不同代 NVIDIA 卡无法轻松用某些 patched driver；llama.cpp 构建要设置 CUDA architecture；NCCL 在他的场景里反而适得其反；模型、230k context、Q8 KV cache、MTP speculative decoding、tensor split 和 VRAM 填充比例都要精细调整。

这篇文章的意义不只是"家用机器也能很快"。它说明本地推理的成本账本非常具体。token/s 不是由 GPU 型号单独决定的，而是由 VRAM、PCIe 拓扑、BIOS、driver、CUDA 架构、量化、KV cache、speculative decoding、tensor split 和上下文长度共同决定。你想省云 API 钱，就要支付硬件调试和系统维护成本。

对个人玩家来说，这可能是乐趣。对团队来说，这就是运维责任。自建推理如果只是为了"token 免费"，很容易低估折旧、闲置、调参、驱动问题、电力、散热和人员时间。云 API 贵，但把很多复杂度打包了；本地硬件便宜不便宜，要看利用率和维护账本。

Google Research 的退役手机集群则把账本拉到碳和硬件生命周期。文章区分 operational carbon 和 embodied carbon：运行耗电是一部分，制造硬件本身的碳足迹也是一部分。很多手机被四年左右替换，但主板上的处理器、加速器、内存和存储仍然可用。UCSD 计划用 2000 台 Pixel 手机做低成本、低碳云计算平台，给课程和研究任务使用。

这个方案不是把手机原样丢进机房。文章说需要移除屏幕、电池、外壳和摄像头等不适合数据中心的部件，只保留主板。Android 用户态也要替换成通用 Linux。手机内存小、核心少，所以要找适合的 workload。根据 SPEC 估计，25 到 50 台手机相当于一台现代服务器。它们用 Kubernetes 把 25 到 50 台设备组织成自管理集群。早期实验显示，20 台手机就能支持 75 人以上课程的高峰提交，grading latency 低于默认 AWS 后端。

这篇文章提醒我们，算力账本不该只算性能价格比。新服务器有更强的单位性能和更好的管理体验，但制造新硬件有 embodied carbon。退役手机单台弱、内存小、管理复杂，但如果 workload 合适，重用主板可以避免一部分新硬件制造成本。这里的关键不是怀旧，也不是硬要用旧设备，而是把"已经存在的计算资源"纳入调度视野。

把这些材料放在一起，可以看到三个层级的账本。

第一层是认知账本。AI 生成文本和代码很容易，但思考、澄清和判断并没有自动完成。写作不是想法的包装，写作是想法的成形。代码生成也不是需求的机械展开，代码生成会固化取舍。团队需要标注哪些输出经过人类理解，哪些只是模型草稿，哪些结论有证据，哪些地方仍是猜测。

第二层是系统账本。AI coding 需要把任务分层，把昂贵模型、便宜模型、本地模型和人工判断放在合适位置。LLMOps 需要记录 inference、feedback、evaluation、experiment 和 optimization。否则生成越多，系统越不知道自己是否变好。

第三层是物理账本。token 运行在真实硬件上。云 API、家用 GPU、二手 3090、5080、退役手机、数据中心服务器，它们都有 VRAM、PCIe、驱动、电力、折旧和碳足迹。便宜 token 背后不是没有成本，只是成本被摊到不同地方。

这三个账本之间会互相影响。

如果认知账本缺失，AI 文本和代码会把判断成本转嫁给读者和 reviewer。系统账本看起来可能很漂亮：生成速度快，token 成本低，但实际团队注意力被噪音吃掉。

如果系统账本缺失，模型路由和优化就会靠感觉。你可能在简单任务上浪费 frontier 模型，也可能在高风险任务上用便宜模型制造隐性错误。账单下降了，事故成本上升了。

如果物理账本缺失，本地推理和低碳计算都容易变成口号。买 GPU 不等于省钱，重用手机不等于一定环保。只有当 workload、利用率、维护成本和生命周期匹配时，它们才成立。

AI 时代最容易产生的幻觉之一，是把"生成成本下降"误认为"总成本下降"。其实生成只是链条中的一段。生成之后还有阅读、验证、执行、回滚、评估、反馈、维护和硬件供给。前一段变便宜，后一段可能会被放大。

这和用户经常提到的"慢"的价值有关。慢不是为了怀旧，而是为了让系统在关键瓶颈处保留反馈。写作中的慢，让人发现自己没想清楚；review 中的慢，让错误在进入主干前暴露；评估中的慢，让团队知道模型改动有没有真实收益；硬件账本中的慢，让人不至于把短期便宜误当长期合理。

当然，不是所有环节都应该慢。机械生成、格式转换、样板代码、批量实验、离线跑分，这些可以快。但判断、归因、反馈和资源配置不能假装免费。加速非瓶颈环节没什么问题；把真正的瓶颈也伪装成已经解决，系统就会出毛病。

所以今天这些文章给我的共同结论是：廉价生成需要昂贵账本。

这里的昂贵，不一定是金钱。它可以是更严格的记录，更好的评估，更清楚的责任归属，更真实的硬件利用率，更细的碳成本核算，也可以是人类愿意在关键句子、关键代码和关键决策上慢下来。

生成变便宜是进步。只是别忘了，便宜的魔法也要记账。否则账单不会消失，只会寄给下一个读者、下一个 reviewer、下一个运维工程师，或者下一批被制造出来又很快闲置的机器。