Eugene Cheah：测量并合理配置 AI 推理成本

Eugene Cheah 介绍 AI 推理经济学工作坊。他是 Featherless AI 创始人兼 CEO，并说明公司销售推理服务，因此例子反映了这一经验。

他说重点是大规模优化。对于支出较小的组织，他建议先寻找有价值的应用场景；他提出的支出门槛只是经验判断，并非通用界限。

四个步骤是测量用量、选择合适模型、购买容量和检查周边流程。首先要了解组织实际花费了多少。

Cheah 说有些客户共用一个 API key，导致难以归属成本。按团队和用途分别记账可以看清支出位置；密钥本身也需要适当的安全控制。

有了这些信息，就可以比较工作负载需求。交互用户可能需要快速响应，而后台任务可能可以接受较低速度和价格。

他对比长时间、多轮运行的智能体与路由、文档处理等高并发流程自动化。真实工作负载可能介于两者之间，但这种区分有助于发现不同成本驱动因素。

Cheah 介绍一个客户团队：他们把智能体工作负载从昂贵的托管模型切换到专用开放模型部署，并报告账单大幅下降。这是其公司的案例，不是对照实验，也不保证其他团队能保持质量。

在人们离线时安排工作，可以提高现有容量利用率。是否适合取决于截止时间、利用率和后台智能体获准执行的任务。

高并发自动化的例子包括客户支持、消息分类、文档处理和交易筛查。每次请求即使只节省一点成本，乘以大量请求后也可能很重要。

测量用量后，选择合适配置就是把模型和服务水平匹配到任务。Cheah 说，有些组织在较窄方案已经足够的场景中使用昂贵的通用模型。

他展示的模型例子只是可能很快过时的时间快照。某个模型在一种基准或领域表现好，并不代表它适合另一项任务；应测试实际工作负载。

Cheah 表示，部分专用开放模型在客户任务上相对于更大的模型表现良好。这些说法取决于具体评估、提示词和部署配置。

他提到仅做分类的模型也是输出选项有限的决策任务的一种选择。对于适合的任务，它们可能更便宜或更快，但不能直接替代需要生成丰富回答的系统。

长时间智能体运行往往在多轮中反复处理输入和缓存上下文。Cheah 说团队应测量输入、缓存输入和输出，而不只比较公开的输出 token 价格。

他观察到一种编码模式：用较强模型规划和审查，用更快、更便宜的模型实施。是否等效应依据团队质量标准测试，而不能直接假设。

人们未必只为了降低公司的账单而切换模型。Cheah 说速度、可用预算和自动路由都会影响选择，组织应了解这些激励。

如果交互任务和 CI 任务的延迟要求不同，它们可以使用不同服务水平。较慢的后台路径只有在仍满足截止时间和质量要求时才有价值。

对于非技术部门，他建议用“快速”或“财务”等任务标签，而不是要求每位用户理解模型名称。标签背后的模型发生变化时，仍需要测试，并在行为改变时沟通。

在嵌入式流程自动化中，大量请求通常迫使团队较早评估成本和质量。Cheah 建议建立有代表性的案例，再寻找满足任务要求的低成本模型。

他引用一个客户支持案例，称公司通过拆分工作负载和选择模型，大幅降低了月成本。结果只适用于该客户，不能证明普遍节省比例。

有些客服任务可以先分类，再路由到预定义回复，而不必从头生成。只有预定义回复和升级路径真正覆盖用户需求时，这种方式才有效。

达到足够规模时，为特定领域微调的小模型可能更经济。Cheah 介绍电信和商业例子，但建议团队评估自己的专门任务。

一种流程是从能力较强的模型开始，收集案例，再训练和评估较小模型。他指出不同提供商的数据使用条款不同，组织需要检查适用条款。

可以逐步在模型之间分配流量，并在切换期间监测质量。在获准的情况下，让较强模型处理少量影子流量可以帮助继续比较。

Cheah 转向容量。对于固定模型和硬件，追求单次响应最快，可能减少同时处理的请求数量，进而提高单次请求成本。

在他的示例配置中，批量处理更多请求降低了单个请求的速度，却显著提高了总吞吐。比例取决于模型、硬件、输入输出长度及服务系统。

有人等待时，为低延迟付费可能合理。后台任务可能接受较低速度，但合适目标仍须考虑完整任务和服务水平要求。

购买专用容量前，应测量基础负载和流量高峰。在安全和合同允许的情况下，稳定需求用预留容量、峰值用按需容量的组合可能有用。

专用容量可能闲置，盈亏平衡取决于价格和利用率。Cheah 建议根据组织实际流量验证部署方案，不要假设专用节点总是更便宜。

接下来他让团队检查流程，而不只是推理账单。生成更多内容不会自动带来更多有用工作或更快交付。

如果审查、CI 或组织决策成为瓶颈，更快生成修改可能只是转移排队位置。可信测试和审查实践可以帮助解决问题，但不能仅因速度而信任不安全的智能体。

Cheah 描述了一种模式：智能体生成很大的修改，审查者难以处理，可能丢弃后重新制作，于是同一任务消耗两次资源。

他建议拆分成更小、更模块化的修改，并改进测试。AI 生成的幻灯片或报告也有同样问题：发送者可能把核实负担留给别人。

他的规则是对交付物负责。无论提交代码、幻灯片还是报告，人都应检查并对内容负责，而不是把错误归咎于生成模型。

他说应同时测量成果和用量，也要承认跨团队比较成果很困难。token 数量本身不能衡量已经完成的工作。

他建议询问：哪些团队花了多少、哪些测试能证明便宜模型足够好、基础负载是多少、哪些任务有人等待，以及生成内容中有多少真正有用。

谈到调优，Cheah 说公司经常使用监督微调，但方法多种多样。他强调应评估结果，而不是只根据方法名称选择。

他介绍一次分类器实验，其中提示词调优模型在特定基准上表现良好。这个例子说明需要在目标任务上比较方法，而不是给出通用排名。

对于训练数据，他重视人工检查的案例，也讨论了尝试不同数据组合。质量不完美的轨迹是否有帮助取决于任务，必须用保留的评估数据检验。

一位参与者问到绑定特定模型生态的编码工具。Cheah 建议用更灵活的运行框架或规划者与执行者分工进行比较，但改变开发者工作流也有成本。

谈到缓存，他说一些大客户使用专用缓存。缓存设计、隐私、提示词格式和实际命中率都会影响结果。

Cheah 在许多情况下偏向按任务或部门路由。他提醒每轮在大量模型之间切换可能降低缓存复用，影响程度取决于具体实现。

他最后鼓励参与者带着具体问题交流。核心实践是测量工作负载、验证质量，再比较完整服务成本。