感谢各位莅临本次工作坊，面对众多因Token账单而苦恼的听众，我的心情颇为复杂。我是Eugene Cheah，Felis AI的首席执行官兼创始人，也是Linux基金会旗下首个AI开源项目Arabic AI背后的团队成员。我们的使命是让每个人、每种语言乃至方言都能享受人工智能的便利，为此我们构建了全球最大的开源模型平台，涵盖超过40,000个模型。这不仅包括通用大模型，还包含如乌干达首个本土语言模型Sunflower等高度专业化的微调模型。
在规模方面，Felis AI服务着日均处理2万亿Token的大型客户，成本控制在每百万Token约0.3美元（即每天6万美元），依托512块AMD MI215 GPU实现。这种配置能支撑私有400B参数模型达到接近Opus 4.8级别的性能，满足高并发与海量Token需求。这种在高性能下极致的成本控制，是公共云市场无法提供的，需要高度定制化的规模化部署方案。
在此需澄清两点：首先，我们销售推理服务，但本次分享适用于所有提供商；其次，本工作坊聚焦于大规模优化。若贵司月支出低于1万美元，建议优先专注于打造高价值应用场景而非过度优化Token成本。对于大规模用户，我们将探讨四大核心策略：测量、规模适配（Right-sizing）、容量采购及流程审查。
首先是“测量”，这是最基础也常被忽视的一环。调查显示，仅半数人知晓总Token支出，更少人能精确到部门或团队级别。许多客户初期使用单一共享密钥，导致无法追踪数据源。因此，必须按部门和主要用例拆分API密钥，以明确Token流向。只有清晰掌握数据分布，才能基于实际负载进行后续优化，避免资源浪费并提升管理透明度。
明确支出后进入“规模适配”阶段。不同团队和负载对速度的需求各异：核心业务团队可能需要高Token/秒的响应速度，而深夜运行的后台代理则无需为此支付溢价。切勿为后台任务购买高性能实例，这既浪费资金又无必要。通过区分优先级，您可以更合理地规划专用容量采购，无论是开源还是闭源模型，都能根据实际生产力需求进行精准匹配。
在AI工作负载中，存在两种经济模型截然不同的类型：智能体（Agentic）工作与流程自动化。前者如编码助手，常长时间运行并处理多轮上下文压缩，最大化Token消耗；后者如呼叫中心或邮件路由，具有短上下文、任务隔离和高并发特征。理解这两者的差异至关重要，因为它们的成本结构和优化策略完全不同，混合管理容易导致资源错配。
以某五人开发团队为例，他们连续运行智能体进行代码编写和夜间自动化任务。此前使用Opus 4.8 API，月支出高达15万美元，消耗约1,160亿Token。尽管他们已尝试在夜间运行以避开高峰，但高昂的持续调用成本仍令人咋舌。这种因盲目追求高性能模型而导致的支出爆炸，是许多企业在采用云端AI服务初期面临的典型问题。我们需要通过精细化的策略来遏制此类无效消耗，实现真正的成本治理。
他们切换到了GRM 5.3实例。之前是5.2版本，他们已经升级到5.3了，那就像是一个单节点实例。每月的费用不到1万美元，而且他们没有遇到任何中断或影响。因此，了解你的团队有助于你做出相应的决策。正如我前面提到的，了解流程和负载也允许你将任务拆分出去。例如，以前他们全天候运行所有服务，但现在开始安排一些后台代理在团队休息时（即夜间）运行。这样你就可以相应地利用他们的硬件资源了。
正如我简要提到的，流程自动化的另一方面纯粹是一个规模游戏。这类任务极其预先定义明确。我可以私下给你一个更具体的例子，你可以想象一下每天数百万甚至数千万次的决策场景：比如呼叫中心中的判断、代码扫描行数，或者是过滤电子邮件和短信。我们合作的一家电信公司轻松就能在单分钟内达到1000万条消息的峰值。这并不令人惊讶，毕竟新年祝福是最糟糕的情况之一。
他们过滤短信的原因是因为他们提供了一项关于“为儿童提供安全电话”的功能，所以需要AI来扫描内容是否包含脏话、色情内容等。这确实不是一个长上下文的问题，而是一个规模游戏。其他类似的情况包括制表人-检查者流程、审批流程和文档处理，这些对多个组织来说都是规模游戏。我推测在座的金融机构（既然我们在纽约）会有很多OCR识别、大量文档、众多审批以及交易风险管控，这些都属于这一类别。
如果你还没有追踪你的令牌支出和令牌视图拆分情况，我们即将开源一个代币经济学跟踪工具。这只是一个非常花哨的说法，实际上就是拆分你的API密钥并追踪哪个API密钥花费了多少费用。这与本次演讲的主题是分开的。如果你想获取更多信息，请随意扫描这个二维码。如果你希望获得本次演讲的幻灯片以及AI工程频道发布录像时的通知，你也可以在那里填写表格。好的，以上就是关于“测量”的部分。
如果你不先进行测量，基本上可以忽略我说的其他所有内容，先从测量开始吧，因为通过测量你就能获得最大的投资回报率。但一旦你有了数据衡量标准，问题就变成了如何正确地调整规模（right-size）。这时候事情就变得复杂了。一般来说，随着AI在企业内部的大规模部署，我们观察到一个模式：因为AI是那个闪亮的新锤子，我们就试图把它应用到每一件事上。特别是在创新实验室里，我们只是试着把AI用到每一件该死的事情中。
我曾见过一些组织甚至将AI应用到极其愚蠢的小事上。因此，有很多模型可供选择，而且许多模型都非常昂贵。弄清楚如何使用以及它们适合哪里是流程中的重要一步。我知道开源模型，我想在座的很多人可能都听说过开源模型，这也是我们的业务线之一。很多公司来找我们，希望找到适合他们用例的开源模型作为即插即用替代品。我们通常会根据他们的用例进行指导。
这是一些通用的经验法则，可能会每月更新一次，因为开源模型每隔几个月就会发布新版本，闭源模型也是如此。情况变化很快。但今年我们发现令人兴奋的变化是：差距正在缩小。去年，最好的闭源模型几乎总是优于最好的开源模型。但随着今年的到来，我们开始看到差距缩小，甚至出现一些开源模型与闭源模型持平或超越的情况。
例如在Opus 5.5更新发布之前，Kimi K3在某些UI设计的基准测试中击败了Opus。这些是非常公开的基准测试结果。在客户内部的基准测试中，我们已经开始看到开源模型在特定用例的专门基准测试中击败闭源模型。特别值得一提的是Step One Five模型，尽管它比Opus小10倍，但在金融基准测试和用例中达到了接近Opus甚至更高的质量。
这真的是最好的编码模型吗？不，但在该用例中，它实际上非常强大且胜任。因此格局正在缓慢变化，对于许多用例来说，你可以找到即插即用替代品，有时甚至便宜10倍（前提是你了解自己的负载并相应地替换）。特别值得一提的是DeepSeek-V4和Flash。不知为何，这个模型在所有负载中都非常受欢迎，因为对许多公司来说它很容易提示（prompting）。
我列出的其他模型在其类别中都是默认的优秀选择。DeepSeek-V4和Flash似乎无论情况如何都很受欢迎，尽管基准分数并不能完全解释为什么它如此流行。另一个需要强调的是，几周前引入了一类新的AI模型，称为分类器（classifiers），最著名的是JAF。开源项目如simple JAF已经开始兴起。这些模型完全专注于做出决策和对任务进行分类。
从技术层面上讲，它们的主要优势是通常比现有模型便宜10倍或更快。缺点是它不能提供聊天回复（chat response）。因此，这些是正在发生的变化，你可能需要开始关注如何改善你的代币经济学。回到代币经济部分，主要有两条轨道，重要的是分别追踪它们：在智能体（agentic）方面，我们谈论的是长运行、长上下文。正如我之前所说，这种负载往往极其消耗现金（cash heavy），输入预览极重且输出很少。我们在智能体用例中看到的正是这种情况。
只有1%的请求是针对输出令牌的。这非常合乎逻辑，因为需要多轮交互，反复冲洗并重复。但这也会决定你的令牌成本。就像你看到的部署成本一样，输出可能拥有最大的数值，但即使输入值或现金小得多，在这种用例中也会被大量重复。是的，这不是编码代理工作坊，但我们看到许多组织中最常见的模式之一是在尝试扩大其AI代理部署规模时。在编码团队中，他们倾向于让最好的代理进行规划，而更快、更便宜的代理负责实施，然后也许再由最好的代理再次进行审核。
这种拆分在所有代理框架中都非常普遍是有充分理由的，因为你获得了两全其美的效果。因为实施阶段往往是一个非常消耗令牌的流程。许多过程反复来回，比如修改文件、测试、检查结果并不断重复。大多数这些代理——特别是像Gemini 5.3 Flash这样的模型，在假设其他代理进行规划的情况下，完全有能力以与更强大的代理（如Astra或Opus）相同的质量水平完成任务。
我们与一些组织合作过，其中规划和审核代理使用的是最先进的前沿肌肉模型，而执行实施的工人则使用GRM 5.3 Flash或Deep Seek 4.1 Flash作为示例。我们从这种拆分模式中观察到一个现象是，尽管我们希望大家都这样做，但没人真的会为了节省公司资金而切换模型。人们通常懒得去切换模型。你需要提供激励措施来促使他们这样做，或者如果你的代理框架足够好……
比如像M这样的某些框架可以自动化这个过程。它使用较弱的模型作为基线，然后在需要更智能的咨询时使用更大的、更聪明的模型来自动切换。这有助于减少摩擦，并帮助用户规模下的令牌经济效益得到改善。我们现在给客户的一条主要经验法则是：你要使用更聪明的模型，既然它已经作为基线如此昂贵……
但你需要让更快、更便宜的模型变得更快。这自然设定了一种激励措施。人们希望快速完成工作。如果模型足够聪明能完成任务且更便宜，他们就会使用它，因为它更快，而不是因为更便宜。我们曾见过团队中两个模型都是较聪明的一个，而较便宜的模型保持相同的每秒令牌速度。只要他们有超额的令牌预算……
没有人会切换。而在另一方面，我们看到了另一个极端的团队情况：他们设定了极其低的预算。因此，如果他们使用更聪明的模型……
他们在一天内就会烧光它。于是每个人都切换到了Dharma中的更快模型，因为那是他们的预算限制。这几乎就像更聪明的模型不存在一样。因此，要注意团队动态以及他们如何切换模式。最佳的权衡在于速度，因为人们对此有天然的激励措施。所以更快、更便宜……
他们会相应地切换过去。再次提醒，要测量，并且你要分别测量两种令牌键。但这不仅仅关乎测量。例如，CI/CD是目前后台运行的非常常见的用例。我们帮助团队设置了针对用户（人类）运行的高速每秒令牌，但对于CI/CD管道来说……
则是速度较慢但规模上更便宜的每秒令牌。这仅仅是根据任务优先级性质的不同而决定的。你可以在密钥级别控制这一点。因此，另一个主要发现是我们在团队部署方面有经验……
例如，对于某些公司而言，有多少人有幸或不幸地经历过CEO说：“每个人现在都必须实施AI，每个人都必须拥有第二大脑。”是的。多个组织已经开始了这项工作。在某些情况下……
甚至在阿联酋，这实际上已成为该国法律强制规定的要求。因此，许多部门并不准备好了解各自的权衡利弊。所以一条好的经验法则是：开发人员倾向于知道……
好吧，所有这些智能模型之间有什么权衡？例如Deep Seek Flash和GR553之间的区别。大多数……你的财务部门完全不知道。你的支持部门也完全不知道。他们只会选择第一个模型并继续使用它。所以我们的一般经验法则是：给部门模型标签，但不要使用模型名称……
这也让你在切换时拥有更多的控制权。正如之前建议的那样，快速与智能的对比，但在某些情况下还有财务代理或Excel电子表格代理。这些是针对各自任务微调的高度专业化代理。这也给了你更多的控制权，允许你交换模型……
它允许你将流量拆分并在不告诉“嘿，用户请尝试这个”的情况下进行测试。缺点也是当这样做时……
如果搞砸了，用户有时会抱怨。但拥有这种控制权是一件好事。即使你这样做……
我们看到的另一种模式可能是某些Dash预览版本。这是它的一个变体，但它在不过度增加组织间沟通负担的情况下给了你控制权。这极其重要……
因为我们合作的一些团队中，我们 literally 看到成员在谈论今年时运行Llama 2模型……
因为没有人切换选项。是的，所以你确实需要建立这个机制。好的，流程跟踪（Process Track）。我之前提到的许多事情……
实际上并不怎么适用于流程跟踪，因为流程跟踪往往更深入地集成到应用程序和工作流中。这纯粹是由流量的巨大体量决定的……
是的，在流程跟踪的所有团队中……
他们往往默认就更加注重正确的规模调整。因为如果你运行像万亿级别的……
大多数部门不会批准像每百万token 10美元这样高昂的成本，这根本不可能。因此，他们通常会尽早开始进行评估和基准测试，随后找到最适合的模型规模。常见的疑问是如何知道小模型是否足够好？其实这是一个错误的问题，你不需要去纠结这一点。你需要做的是建立测试用例、评估标准和示例集，然后在此基础上进行搜索和筛选过程。
像我们这样的公司很乐意提供帮助，因为我们拥有超过40,00个模型资源。但实际上，你也可以从Hugging Face下载10个模型进行尝试，这并不困难。通过搜索找到能通过大部分测试且成本最低的模型，然后在此基础上迭代和优化、微调。我们还有一套更具体的流程（虽非我们独有），例如曾协助一家大型电信运营商将推理成本从每月25万美元降至7,600美元。
这一成果是通过切换现有闭源模型实现的，具体步骤包括：首先运行最佳模型以观察效果，然后拆分出可分离的模块，接着确定适合部署的模型规模，最后进行微调。这一过程主要针对客户支持等用例。正如Jeff和Simple Jeff（我们开源的复刻项目）所强调的，你会惊讶地发现你的AI流量中有多少比例是分类任务。
归根结底，虽然客户支持涉及文本回答，但许多团队已为模型预设了上下文中的标准文本回答。在这种情况下，你可以使用分类器来处理大部分情况。这是AI领域的一个新转变，也是降低Token账单的关键杠杆之一。以微调为例，许多模型和流程在规模化后都能受益，此时开始微调自有模型显得尤为重要。
另一方面，对于代码类模型，有些组织如Devin会为你提供微调服务。大多数开发者通常只想要最好的模型，除非身处AI行业，否则很难跟上最佳代码模型的微调节奏。但在特定领域内，针对用例微调专用模型可能很有价值，尤其是当模型规模较小时。例如AT&T在微调后，从27B参数的大模型缩小到了甚至更小的7B模型。
AT&T已公开了这一成果，我们是其首发合作伙伴之一，你可以尝试他们公开的对话模型。这些就是他们在幕后使用的技术核心，关键在于规模效应。鉴于AT&T及其呼叫中心的巨大体量，这是一个通过微调使模型专业化以适配用例的绝佳案例。随后像Shopify这样的大型组织也开始采用类似做法，且不一定需要大规模微调。
例如，Shopify因其网店配置拥有专有编程语言，现有模型表现不佳，故进行微调。AT&T也有类似案例，如基站排列等电信特定任务。虽然我不是该领域的专家，但他们确实有此类用例并进行了相应微调。你可能也有类似场景。那么如何启动这样的模型呢？好消息是，如今你可以轻松引导数据生成：如果最昂贵但性能最好的大模型能完成任务，你就可以开始着手。
一种常见做法是自行生成或准备数据（尽管这很困难且无人喜欢），但另一条路径是使用昂贵的大模型在小规模部署中生成数据集。需注意某些实验室的服务条款可能禁止此行为，建议咨询律师；但也有如Google Gemini等前沿模型明确提供专用API服务以支持此操作。
这允许你基于强效模型构建针对自身用例的数据集，随后可大幅缩减至如7B规模。或者利用开源模型进行蒸馏运行。收集数据后，你可以微调不同规模的模型以寻找最佳匹配。再次引用80/20法则：AT&T在呼叫中心的不同层级使用27B和7B模型。常规呼叫可由较小模型处理，若遇到分类器触发的复杂情况则升级至更大模型。
这样即可实现流量分流，达到高效水平。在此过程中，我们通常建议团队即使完全迁移至微调模型后，仍应将部分流量作为影子流量分配给最佳模型。因为顶级模型仍在持续进步，此举可确保持续构建高质量数据集，从而顺应最佳开源模型的演进趋势。
这里的单位经济效益至关重要。我要提醒大家的是，人们严重低估了AI的发展速度，尤其是那些能以更低成本大规模运行的模型。
举个例子，我喜欢衡量一下：在这台最昂贵的 MacBook Pro 上我能买到最好的模型是什么。如今的最佳模型，无论是 31B、32B 还是 27B 参数的 MoE（混合专家）模型，都已经比 GPT-4 好得多。因此，本质上来说，能在笔记本电脑上运行的模型已经优于你去年拥有的最佳模型了（大概如此）。人们喜欢争论细节，但我们就宽泛地说吧。当你针对特定任务微调它时，这意味着如果你能在笔记本电脑上分别运行该模型，你就可以在 GPU 服务器上以规模更有效地运行它。是的。
这就引出了下一个话题：购买 GPU，这显然越来越具有挑战性。所以，这就是像我们这样的公司发挥作用的地方。通过大量的客户交流，我们发现人们往往对事情不成线性扩展感到惊讶。我的意思是，单个请求的每秒令牌数（tokens per second）与请求本身的成本之间存在巨大的权衡。例如，如果你不关心成本，你可以在最好的硬件上运行最佳模型（假设是固定模型），使用所有八张 GPU，批处理大小为 1。
你可以获得每秒 100 或 200 个令牌的速度。如果你真的想要每秒数千个令牌（这不是我们的专长），像 Cerebras 这样的公司也很乐意提供这种服务，而且成本更高。因此，肯定有一些用例是合理的。但是，很多人陷入了一个误区，认为“如果我有了速度，成本可能减半”。这完全不是回事。我常说的一条经验法则是：“每两倍的速度的提升，成本会增加三倍，并且这种效应会累积。”
以 JM 5.3 为例，一个节点可以看到相同的服务器在运行单个请求时达到每秒 112 个令牌。但是，如果你并行运行 16 个请求，所有请求的速度大约减半，但总输出量却增加了十倍。这使得成本降低了约 9 到 10 倍，仅仅是改变了目标速度配置文件而已。因此，当许多客户问我们“如何大规模部署”时，第一个问题通常是：“你想要什么样的模型质量？以及你想要的每秒令牌速度是多少？”
然后我们开始推荐所需的 GPU 数量和部署方式。这个目标每秒令牌数是一个重要的权衡因素。本质上，在更极端的情况下（虽然很少有人真的以每秒 10 个令牌运行，但确实有一些奇怪的用例允许这样做），你可以获得更惊人的总吞吐量。通常我们看到客户选择在 20 到 30 之间（这大致相当于 ChatGPT 的速度，无需过多思考），一直到大约 60，这是最快的速度。
如果他们想要每秒 120 个令牌的速度，通常就在这个范围内。大多数人根据任务链的长度在 20-30 到 60 之间选择。是的，所以我一般只建议在面向用户（无论是开发人员还是客户）时才为每秒令牌的速度付费。这些都是你想要做出的权衡。即使在此范围内，我们也见过案例表明，稍微降低一点速度（例如从 120 降下来），就可以轻松节省两倍的成本，而对客户的影响几乎可以忽略不计。
再次强调，后台作业请不要以每秒 120 个令牌的速度运行，这样做毫无意义。是的。所以，一旦你之前提到的“测量”完成，即你能看到你的流量模式后……许多流量模式具有一定的突发性质和基础负载（因为总有人在某个时间运行某些东西，特别是后台代理）。这就是你可以规划部署的地方。
我知道在金融领域可能没有这个选项，因为他们只使用专用实例部署。但在某些允许混合使用的情况下（即拥有专用实例并突发到公共云），你有一定的灵活性。因此，目前市场上最大的节省成本的方法是在你知道基础工作负载的情况下部署专用实例。只要充分利用它，你就有了相应的节省。但这取决于你的流量模式而变得复杂一些，这些事情可以进行测试和验证。
这基本上是所有推理公司都会与你合作的事情，并不只有我们如此。我们会说：“嘿，你知道你的流量工作负载吗？能分享一些数据吗？”然后随后我们会说：“好的，我们建议这样。你可以尝试切换到这个方案。”我们可以向你展示你的节省情况（在大多数情况下）。在一些极端案例中，如果你有大量的峰值，你可能希望将专用容量限制在一定数量内，让峰值溢出到公共云。
不同的用例有不同的正确规模调整方法，但通过再次测量你的令牌工作负载（在开始时），你可以开始探索这些选项，节省可能是巨大的。就像我们服务的客户处理了 2 万亿个令牌（使用的是类似 Opus 级别的模型），他们支付的每百万令牌价格低于 0.3 美元。这种价格在别处是得不到的。是的，简单的免责声明是：峰值确实很重要。
很少有人会在极端末端出现短期峰值（例如每月以那种规模运行一次工作负载），然后其他都不重要。所以，通常存在基础工作负载，只是看基础工作负载有多大而已。是的。那么最后一点是检查你的流程。从这里开始，这与推理优化无关了。有些幻灯片听起来对 AI 非常批判性，但我通常是一个乐观主义者。我只是想澄清这一点，因为事情可能会被断章取义地引用。
我们开始看到的一个“潘多拉魔盒”式的问题或棘手问题是，许多组织开始问：“嘿，我的令牌支出增加了 10 倍甚至 100 倍，但我没有看到同等规模的结果。”我们开始看到来自各种组织的报告……
这并非我们许多人曾承诺或设想的规模。不幸的是，事实如此，因为我们正处于这样一个阶段：每个人都在用一把大锤子敲打一切。这并不是说人工智能没有用处，而是我们倾向于到处滥用它。是的，有时候我真的想说：“能不能请你不要像另一个副驾驶那样做？”因为实在太多了。你需要思考如何分别使用它。
我们开始意识到的另一个主要问题是，人工智能正以更大的规模和更频繁地部署，人们在创建内容方面变得更快，但组织流程可能无法跟上同样的速度。在编码环境中，第一个瓶颈将是持续集成和持续部署（CI/CD），你们可能也听说过 CPU 成为了各自的瓶颈。另一件事是现有的流程问题：你如何建立信任？如何进行审查？我认为之前的演讲者详细讨论了信任。是的，缺乏信任是导致事情变慢的原因。
这也许是合理的。也许人工智能代理设计糟糕，不值得信任。但情况也可能相反：假设那个代理完美地完成了所有工作，但因为缺乏测试、验证和信任构建机制，人们却不信任它。这也会拖慢进度。这些因素产生了更大的影响。因此，再次提醒你们要警惕“锤子”的使用方式，并相应地做出调整。
这又回到了一个观点：令牌（tokens）不等于完成的工作量。我要强调的一个主要例子是，这种情况比我愿意看到的更频繁地发生：有时滥用更多的代理和令牌意味着你多次完成了相同的任务。这是我们开始看到的一个反模式，虽然从整体上看，工程组织通过更快地清除问题、自动化解决问题（例如当质量保证团队报告问题时，代理自动修复而无需工程师介入）提高了生产力。
但我们面临的一个常见问题是，人们变得非常雄心勃勃。他们不再进行小改动，而是开始进行巨大的更改，比如修改一半或四分之一的代码库。如果经过适当的测试计划，这很好。但很多时候，由于更改规模如此之大，瓶颈变成了审查者合并代码的速度。因为一切都在人类无法处理的巨大范围内进行，我们开始看到的另一个常见反模式是：有人实施了代理生成的代码。
由于生成了大量代码，那些没有生成代码的问题既没有被审查者注意到，也没有被捡起。于是有人需要让代理用代码解决问题。当代理生成了那堆巨大的代码（如果正确审查提示词，本应少得多）时，审查者看着它心想：“这么多代码。我能让我的代理高亮显示相关的更改并重新实现吗？”最终，他们开始用人工结合代理的方式重建它。
换句话说，他们直接丢弃了第一个代理的工作成果。发生这种情况有多个原因。例如，审查者希望保持对主代码库的控制和质量，但这正是一个典型的瓶颈案例：如果你没有深思熟虑流程，只是不断投入更多资源，速度并不会增加。因此，请审查你的流程。解决这个问题的一个好方法是自然地引入更好的测试实践以便自动化过滤。
同时提醒团队：“嘿，拆分你的合并请求或使其更具模块化，以便于审查流程。”这些都是人类流程，与人工智能无关。是的，我们有时对人工智能过于兴奋了。这不仅仅是代码问题。我们看到因为人工智能代理被部署来制作演示文稿，这份在整体设计上是完全由人工智能生成的幻灯片。我经历了多次迭代，这不是零样本生成。
我对每一页至少进行了30次更改以修改文本，但设计是由代理完成的。在组织内部，你开始注意到有些人只需一次提示就能生成整个幻灯片集合并四处传播。他们开始在会议上使用这些内容，然后轮到其他人去过滤不一致之处、错位之处？为什么这两个数据点完全不同？
这也是另一个例子，与前面的情况相同：人们生成代码、幻灯片或报告，负担转移到了下游的某个验证事物的人类身上。因此，请密切关注这种组织变化。我仍然保持乐观的原因是我认为这本身并不一定是坏事，因为问题在于每个人都需要学习。这就是我们开始相应调整流程的地方。
另一个主要问题是，关于如何使用人工智能有很多常见的例子。你比作为人工智能专家的我更了解你们组织的领域知识。会有用例，其中人工智能可以替代自动化流程，例如节省数百万美元或以巨大规模提高生产力，只有你们自己知道这些用例。我喜欢提到沃尔玛最著名的例子之一（我相信是沃尔玛）。
他们在每辆卡车上 literally 放了一个踏脚凳。这是一个最简单的改变，但它降低了数百万的账单费用，因为它减少了搬运重物时的背部受伤情况。人工智能的使用也需要这样具体的事情。它甚至不一定是最好的 AI 模型，但实际上可以产生最大的影响。
重申我之前的观点，最近流行的一个术语叫做“垃圾手雷”（slop grenade）。即生成大量人工智能内容，然后留给别人去处理。不要让“垃圾手雷”发生。这是一种文化和流程问题。
我会制定一些指导原则，这更具主观性。人们对此会有分歧。为了防止“垃圾数据炸弹”的发生，必须强制执行这样的规定：每个人都要对自己提交或生成的内容负责。例如，这张幻灯片上写着“我拥有所有生成文本”。如果出现问题，责任在我，而不是我的 AI 代理。我不能把责任推给代理，我必须承担这份责任。代码也是如此，任何生成的内容都适用这一原则。此外，你还需要衡量结果而非使用量。
这就变得复杂了，因为我不想解释得太冗长，但有一个简单的公式被许多人视为经验法则：使用量乘以价格除以实际产生的结果。这有助于指导许多决策，比如选择更小、更高效的模型，更快的模型或更大的模型等。但我不喜欢的是这个公式忽略了 AI 更像是一种增强团队能力的补充剂或类固醇的类比。
以建筑工作为例，假设 AI 能增加工人的肌肉量（尽管这在伦理上并不恰当，仅作为思维训练的例子）。有些团队使用它后生产力提高，有些不。但即使没有这种增强，很明显某些团队本身就比其他团队强得多。因此，AI 作为补充剂并不一定改变一切。你需要意识到结果很难分别衡量，但你可以开始测量和观察这一点。
回到第一步：测量。你知道每个部门、每个团队消耗的代币量，你可以开始看到哪个团队表现更好，他们使用了多少代币。你能看出什么有效。正如我所说的，这是一种有缺陷的测量方式。这就是高层概览。如果你想在公司内部启动流程，可以联系我或我的团队，或者问自己六个问题：哪个团队花了多少？必须测试什么才能使用更便宜的模型？基础负载是多少？每个团队的默认模型是什么？
哪些工作流有人工等待，需要更快的速度？以及我们生成的内容中有多少是有用的。这些是开始提问以优化代币经济学的指导性问题。接下来是问答环节。是的，当你提到微调模型时……测试、测试。嗯，我正在尝试理解你是指类似 SFT（监督式微调）的微调，还是针对特定用例或数据有其他类型的微调方法？
一般来说，往往倾向于 SFT。我们确实提供微调服务且多为 SFT 类型。目前有很多方法正在发生，我知道 RL（强化学习）现在很流行，特别是在编码环境中，因为容易在循环中生成数据。但我们意识到对于许多组织（例如纽约的金融机构），并没有适合金融任务的 RL 环境，因此往往更基于 SFT。
还有一些组织如 Adapted Adoption AI 开始自动化数据集的 refinement，以便训练模型基于 SFT 或思维链。专注于此可能是错误的问题。在我看来，人们应该关注的是评估指标（evals）。这里有一个很好的例子：Jeff 模型推出时，我们做了一个名为 Simple Jeff 的开源项目，复制了现有开源模型的 API。许多人很快意识到 Qwen-27B 在这项任务上表现很好，多个团队去微调 Qwen-27B。
而我们采取的方法是接受任何模型并在其上构建 API。我们看到基准测试和现有模型，为什么不尝试提示调优（prompt tuning）而不是微调？两周后，当 Hugging Face 进行大规模基准测试时，我的提示调优 Qwen-27B 击败了大多数微调的 27B 模型。这不是炫耀，因为我知道现在我的模型已被近期更正规基础上的 Cloudflare 微调模型击败。
但这说明调优方法可能不是正确的问题，关键在于你的评估指标和导致的结果是什么？接着问：如果你做 SFT 或其他操作，是否需要为数据集收集黄金轨迹（golden traces）？或者像你说的那样，前沿模型有 80% 的准确率，剩下 20% 出错。如果基于此微调，模型也会错 20%？你需要过滤掉这些只获取黄金轨迹进行训练吗？还是可以把所有轨迹扔进去训练？
这更多是个人 opinion 和技术。我尝试拆分数据集，因为人们懒得过滤。所以我至少获取一个黄金轨迹数据集，它可能小得多，然后用更重的权重进行微调。但有多篇论文指出，特别是关于思维令牌（thinking tokens），即使是失败的任务，较小的模型在微调和训练后也能受益，因为它改进了思维过程，即使答案错误。
这是一个很好的案例：尝试然后测量，70% 的情况下有效。有时你需要增加黄金轨迹的比例，但这只是一个经验法则。我认为许多客户在尝试将较小模型进行 SFT 时遵循的一般规则是：能否保持相近的性能水平？也许评估分数下降 1%，甚至在某些情况下提高 10%，因为基础模型未针对这些任务专门化。
更重要的是，它是否将我的账单减少了 100 倍？这通常是动机所在。是的，黄金样本对于超越基线至关重要。有时这需要人类实际查看数据，虽然我希望客户多看看数据，但人们不喜欢这样做。
问：你会如何处理主要来自 Claude Code 及其所有集成的代码支出？因为这样你的模型就完全锁定在 Claude 生态系统中了，我猜。你对如何处理这类情况有什么建议吗？
答：嗯，是的，不幸的是 Claude Code 就是完全锁定的例子。[笑声]
所以，嗯，有时候第一步实际上是让他们能够切换框架（harness）。目前看来“框架”是一个灵活得多的东西。比如，我们看到有些组织是完全锁定的，“我只会用 Devin 或 Mboni”。我们也看到一些更灵活的组织，他们 literally（字面上）在创建自己的代理框架。我的反应是：“为什么？为什么要从头开始创建自己的代理框架？”
但像我们看到的常见切换目标之一是 Pi。这也是因为围绕它有很多兴奋点。人们已经证明，即使使用相同的模型，由于 Pi 简单高效的方式，它的每 token 成本要低得多。
从那里开始，我认为 Pi 编码代理框架的美妙之处在于它很容易适应，因为它非常轻量级。我们看到了很多团队开始通过提示他们的代理来进行修改。一旦他们做到了这一点，就开始进入实验和更改的循环。
让他们非常有动力去改变的一种常见方法实际上是引入一个足够好且非常快的模型，比如每秒 100 个 token。然后突然他们开始尝试这个。有些人或像一些最初的转变是他们仍然使用 Claude Code 作为规划器（planner）。然后他们指示 Claude Code：“用这个 Pi 代理和这个模型来执行实现。”因此有了规划器与实现的分离。是的，这就是转变开始发生的地方。改变人们的代理并不容易，但确实如此。
问：嗯，是的，这些例子可能包括在 Claude 内部将这个较小的代理暴露为 MCP（模型上下文协议），或者拥有这些工具，你可以将任务卸载。我想这是你会说可行的吗？
答：MCP 更棘手，因为除非做得正确，否则 MCP 代理无法访问你的文件系统。所以通常只是像 Pi 这样更简单的东西，他们运行批处理命令 pie this。是的，通常情况就是这样。
问：谢谢。
答：嗯。
问：如果可能的话，你能分享一些关于缓存解决方案的案例研究吗？特别是那些在缓存方面非常深思熟虑的，以及为特定客户产生的结果，即使是匿名的也可以。
答：你谈论的具体挑战是什么？你做了一次缓存……好的，你的问题更像是你想要匿名的……等等，你不想保存客户私有信息在缓存中吗？
答：不，所以像与你合作过的客户那样，你是否有任何案例研究可以分享关于他们因为深思熟虑如何缓存以及不同的缓存方法而能够产生的结果？
答：嗯，我认为这个我们可以私下讨论。但一般来说，对于我们的更大规模客户，我们为他们部署专用缓存。所以这在某种程度上解决了很多 PI 问题，因为该缓存仅用于那个客户。嗯，是的，当然还有提示格式化，但我可能需要更深入地挖掘具体你想问什么的地方。简短的回答是“是的”，但对此有很多解释方式。
答：酷。抱歉问了这个。
问：关于基于轮次或任务的自动路由有什么想法？
答：哦，嗯，我一般更倾向于基于任务。主要是因为这在部门或组织层面更容易控制期望。所以，这又回到了像“嘿，一个部门可能有一个标签模型和我为他们自动路由该模型”这样的场景。
我知道现在基于轮次的自动路由有很多炒作。但基于轮次自动路由的一个问题是，你需要将你的基于轮次的自动路由限制在最多两到三个模型。否则，你的缓存使用效率将极低。所以，例如，我们看到针对 GPT-4o 和 GPT-4o Flash 的基于轮次的方法。明白吗？
但是如果你放入 30 个模型，并且它在每一轮都改变你的模型，你低的缓存命中率开始会破坏你的优化。
答：是的，我以前见过这种情况。我看到它在请求级别上运行，但这没有意义……
答：嗯。但两个模型通常是可以的。基于任务和组织的做法最有意义。是的。
答：嗯，是的，我同意。
问：好的，谢谢。如果任何人想专门找我提出更多问题，欢迎在下一个演讲者到来之前上前问我或在我旁边找到我。是的，非常感谢。