演讲者背景与服务规模
本次工作坊由 Featherless AI 的创始人兼 CEO Eugene Cheah（Twitter: @PicoCreator）主持，他同时也是 Linux 基金会旗下首个 AI 模型项目 Arabic AI 开源团队的核心成员。Featherless AI 的使命是让每个人、每种语言都能使用 AI，为此他们构建了全球最大的开放模型平台之一，拥有超过 40,000 个开源模型。这些模型不仅包括通用大模型，还涵盖针对特定地区或语言的垂直微调版本，例如乌干达首个语言模型 Sunflower。在服务能力方面，Featherless AI 能够支撑大规模并发请求，其部分最大客户每天处理高达 2 万亿个 Token。这些服务运行在约 512 块 AMD MI215 GPU上，通过私有化部署的 BM OE 模型（类似 Opus 4.8 级别的性能），将成本控制在每百万 Token 0.3（即 $0.03）左右，日均成本约 60K。这种在高性能下实现极低单价的能力，依赖于高度定制化的基础设施架构，而非公共云市场的标准配置。
适用对象与核心前提
Eugene Cheah 明确指出了本次工作坊的两个重要免责声明。首先，Featherless AI 销售推理服务，因此文中所有观点均基于其实际运营数据和对全行业的观察，并非针对特定供应商的营销。其次，本次内容主要面向每月 AI 支出超过 $10,000的组织。对于低于这一阈值的团队，Eugene 建议应将重点放在寻找高价值的内部应用场景上，因为强用例带来的价值远超节省的 Token 费用。他直言：“如果你们每月花费少于这个金额，可能最好专注于在组织内建立强大的用例……而不是试图优化 Token 支出账单。”对于高支出的企业，治理的核心在于通过精细化运营降低单位成本，从而释放更多资源用于创新。
第一步：测量与密钥隔离
治理 Token 成本的首要步骤是精确测量。Eugene 指出，许多企业在面对高昂账单时缺乏透明度。现场调查显示，仅有一半的参会者知道公司的总 Token 支出，而能精确到部门或团队层面的更少。许多客户最初使用单一共享 API 密钥，导致无法追踪具体消耗来源。因此，首要行动是拆分 API 密钥，按部门、团队或主要用例进行隔离。只有明确了“谁在花钱”以及“花在何处”，才能进一步分析工作负载的效率。例如，识别出哪些团队需要高吞吐量的实时响应（如前端交互），而哪些后台任务（如深夜运行的批处理）可以接受较低的优先级。这种测量能力是后续所有优化决策的基础，否则企业将在盲目中持续浪费预算。
工作负载类型与成本爆炸案例
AI 工作负载主要分为两种经济模型截然不同的类型：一种是代理型（Agentic）工作负载，如代码生成助手或长期运行的多租户 Agent；另一种是流程自动化（Process Automation）工作负载，如呼叫中心路由、邮件分类或会议转录。前者通常涉及长上下文和长时间运行，后者则是短上下文、高并发的任务隔离型应用。Eugene 分享了一个典型案例：某公司的一个五人开发团队，为了优化代码流程，连续运行 8 个高级 Agent（包括夜间运行的复杂任务）。他们此前使用 Opus 4.8 API，每月 Token 支出高达 $150,000，月消耗 Token 量达 1.16 billion。这种“云原生狂热”导致的成本失控，正是通过区分工作负载类型、调整模型层级（如后台任务不使用顶级昂贵模型）来缓解的典型场景。
工作负载分析与调度优化
降低 AI 成本的起点并非盲目更换模型，而是深入理解团队的工作流程与负载特性。演讲者指出，了解你的团队和工作流是做出正确技术决策的基础。以某客户为例，他们成功将实例从 5.2 版本升级至 GRM 5.3。这一单节点（single node）的迁移成本极低，每月费用不足 10,000 美元（less than $10k a month），且整个过程未对业务造成任何中断或负面影响。这种平滑升级证明了在明确负载需求的前提下，硬件资源的替换是可行且低风险的。
"Knowing your team allows you to make these decisions respectively."
除了硬件升级，流程自动化中的调度策略也是降低成本的关键。演讲者分享了一个具体案例：某团队此前全天候运行所有任务，后来调整为在团队成员休息的夜间调度后台代理（background agents）执行非紧急任务。这种错峰运行策略充分利用了硬件资源，避免了高峰期的算力浪费。通过这种方式，企业可以在不增加额外预算的情况下提升整体吞吐量。对于尚未开始追踪 Token 支出和分配的组织，演讲者强烈建议优先建立测量机制，因为所有最大的投资回报率（ROI）都始于准确的度量。为此，演讲者团队还开源了一款 Tokenomics 追踪工具，用于通过拆分 API Key 来精确监控各模块的消耗情况。
高吞吐量场景与“数量游戏”
AI 应用中的另一类典型成本结构是纯体积驱动（purely a volume game）的场景。这类工作负载通常具有高度预定义、上下文短但并发量极大的特点，例如呼叫中心决策、代码扫描或邮件过滤。演讲者提到一个电信运营商的案例，该客户在特定高峰时段（如新年期间）每分钟处理的消息量高达 1,000 万条（peak 10 million messages in a single minute）。尽管新年消息激增被视为“最糟糕”的高峰，但通过 AI 过滤包含不当内容（如亵渎或色情）的信息，系统能够高效处理海量数据。
"This is really not a long context, but a volume game."
这类场景的核心在于处理效率而非复杂推理。除了电信行业，金融机构中的 OCR 文档处理、审批流程以及交易风险评估也属于此类。这些任务通常涉及大量的重复性判断，而非长文本生成。对于这类高并发、短上下文的场景，优化重点在于如何以最低的单位成本处理百万甚至千万级的决策请求。演讲者强调，许多企业往往忽视了这类“数量游戏”的成本优化潜力，而将昂贵的通用大模型用于此类简单任务，导致资源错配。
开源模型的崛起与替代机会
随着 AI 技术的快速迭代，闭源模型不再具有绝对的性能垄断优势。演讲者指出，过去一年中最佳开源模型几乎无法匹敌最佳闭源模型，但今年这一差距正在迅速缩小。在某些公开基准测试中，Kimi K3 甚至在 UI 设计方面超越了 Opus 5.5。在客户内部的专业基准测试中，开源模型的表现同样出色。例如，Step 1.5 模型在金融用例的特定基准测试中达到了接近 Opus 和 Extra 的质量水平，尽管其模型规模仅为后者的十分之一（10x smaller）。这意味着在特定垂直领域，开源小模型可以作为闭源大模型的直接替代品（drop-in replacement），且成本可能降低 10 倍。
"Some of the open models are even on par or even surpassing."
此外，DeepSeek-V4 和 Flash 模型因其易于提示（easy to prompt）的特性而在各类负载中广受欢迎，尽管其基准分数未必能完全解释这种流行度。演讲者提醒听众，模型生态变化极快（每月都有新发布），因此企业应持续评估开源模型在特定用例中的表现。对于许多创新实验室而言，避免将昂贵的 AI 技术应用于所有琐碎任务至关重要。通过识别那些可以被小型、低成本开源模型替代的用例，企业可以显著优化 Token 经济结构。
新兴分类器模型与成本重构
近期出现的一类新模型——单样本分类器（one-shot classifiers，如 JAF 项目）正在改变成本结构。这类模型专为决策和分类任务设计，在技术上比现有通用模型便宜 10 倍甚至更快。然而，其局限性在于无法生成聊天回复（chat response），仅适用于明确的分类或判断任务。演讲者建议企业开始关注这类细分领域的模型，以进一步优化 Token 经济。
"These are models that are entirely focused on just making decisions and classification."
演讲者最后总结，Token 经济优化主要分为两个轨道：代理型（Agentic）工作负载和分类/决策型工作负载。代理型任务通常涉及长上下文和高输入预览（input preview），属于高现金密集型（extremely cash heavy）场景，且输出占比极小。对于这类任务，成本优化更为复杂；而对于分类类任务，则可通过采用专用的低成本模型实现大幅降本。企业需将这两类工作负载分开追踪和管理，才能精准定位成本优化的空间。不区分场景地统一使用昂贵的大模型是导致 AI 账单过高的主要原因之一。
输入输出比例决定实际 Token 成本
在 AI Agent 的交互模式中，用户请求中仅有约 1% 的内容转化为最终输出 Token。这种极低的比例源于 Agent 需要经历多轮“思考-执行-验证”的循环过程。尽管单次输出的 Token 数量可能很大，但输入端的数据会被反复复用和迭代。这意味着在计算部署成本时，不能仅看最终输出的大小，而必须考虑到输入数据在多轮交互中被高频重复消耗的事实。这种“冲洗并重复”（rinse and repeat）的模式是理解 Token 经济学的关键，因为输入值的累积效应往往比单次输出更具成本影响力。
摒弃“足够好”的误区，建立基准测试流程
许多企业在面对高昂的 AI Token 账单时感到无力，因为每月百万级代币、每代币10美元的成本结构在大多数部门根本无法获批。解决这一问题的核心不在于纠结“小模型是否足够好”，这是一个错误的提问方式。正确的做法是建立严格的测试用例、评估指标（Evals）和示例库，随后通过搜索流程找到最匹配且成本最低的模型。企业无需依赖拥有 40,000+ 模型的庞大平台，只需从 Hugging Face 下载约10个模型进行尝试即可启动搜索。通过迭代和微调，找到能通过大部分测试用例的最便宜模型。这种基于基准测试的搜索过程是降低成本的起点，而非盲目追求最新最强的通用大模型。
电信巨头案例：从闭源到开源微调的成本断崖式下降
以一家主要电信运营商客户为例，团队通过系统性的模型替换与微调流程，将推理成本从每月 250,000 美元大幅降低至 7,600 美元。这一显著成效源于对客服场景的精细化拆解：首先运行最佳模型以分析流量，随后拆分出可独立处理的子任务并匹配相应规模的模型。关键在于识别出大量 AI 流量实际上是分类任务（Classification Traffic）。即使是客户支持中的文本回复，许多团队已预设了输出模板放入上下文，此时使用轻量级分类器即可处理。这种将流量分流至专用小模型或分类器的策略，是降低 Token 账单的巨大杠杆。通过这种“最佳模型先行分析 -> 拆分任务 -> 匹配小模型 -> 微调”的流程，实现了成本的极致压缩。
垂直领域微调与数据构建策略：以 AT&T 和 Shopify 为例
在特定垂直领域，针对用例微调专用模型往往比通用大模型更具性价比。例如 AT&T 在客服场景中，通过微调将原本依赖的开放类 27B 参数模型降级为更小的 7B 模型，同时保持了服务质量。AT&T 作为 Launch Partner，其开源对话模型展示了这一成果：常规呼叫由小模型处理，复杂情况通过分类器触发升级。类似地，Shopify 针对其专有 Web Store 配置语言进行微调，因为现有通用模型在此特定编程任务上表现不佳。垂直领域的专有知识（如 AT&T 的基站排列逻辑）使得小模型微调成为必要且高效的选择。
数据蒸馏与影子流量：确保持续进化的经济模型
构建微调数据集不必从零开始。如果最强的昂贵模型能完成任务，可先小规模部署该模型以生成数据集（Data Distillation）。虽然部分实验室对此有服务条款限制，但如 Google Gemini 的前端模型提供专门 API 支持此用途。开源模型也欢迎此类蒸馏操作。收集数据后，可对不同参数规模（如 7B）进行微调测试以找到最佳平衡点。在流量分流至小模型后，建议保留一部分影子流量（Shadow Traffic）指向最佳大模型。这不仅用于持续构建新数据集，还能让企业跟随顶级开源模型的进步浪潮。单位经济学（Unit Economics）在此至关重要，因为 AI 模型在低成本规模下的迭代速度极快，保持数据闭环是确保持续优化的关键。
本地模型性能超越云端旗舰
当前开源大模型的进化速度令人震惊，即便是运行在消费级硬件上的模型，其基础能力也已大幅超越去年的云端旗舰产品。以 MacBook Pro 为例，目前能在笔记本上运行的最佳 MoE（混合专家）模型，如 31B、32B 或 27B 参数规模的版本，其表现已经明显优于 GPT-4。这意味着用户手中的笔记本电脑所承载的模型智能水平，实质上已经超越了去年最顶级的云端服务。虽然具体细节存在争议，但宏观趋势是明确的：本地部署的模型在微调后针对特定任务的表现极佳。这种高性能不仅限于单机，当这些高效模型被部署到 GPU 服务器集群时，能够以远高于云端 API 的效率进行规模化运行。这种从本地到云端的效率迁移，为降低推理成本提供了基础技术支撑。
吞吐量与延迟的非线性权衡陷阱
企业在购买 GPU 资源时，常陷入一个认知误区：认为速度提升能线性降低单位成本。事实上，单个请求的延迟（Tokens per second）与总成本之间存在巨大的非线性权衡。如果完全不考虑成本，使用顶级硬件（如 8 张 GPU）并以 Batch Size=1运行最佳模型，可能获得每秒 100-200 Tokens 的速度。然而，追求极致的吞吐量（如每秒数千 Tokens）往往需要昂贵的专用硬件（如 Cerebras），成本极高。一个关键的行业经验法则是：每提升 2 倍的速度，成本往往增加 3 倍且呈复合增长。以 JM 5.3 为例，单节点处理单个请求时速度为 112 Tokens/秒；若并行运行 16 个请求，虽然每个请求的速度减半（约 56 Tokens/秒），但总输出量提升了 10 倍，从而导致整体成本降低 9-10 倍。
"For every two x of speed, it's three x the cost and it compounds."
因此，在规划大规模部署时，首要任务是确定目标 Tokens/秒速度。大多数客户选择在 20-30 T/s（类似 ChatGPT 体验） 到 60 T/s 之间，极少数需要高达 120 T/s 的场景仅适用于极短链任务。对于面向用户的实时交互，高延迟是痛点；但对于后台作业或开发者工具，降低速度目标即可大幅节省成本。例如，将速度从 120 T/s 略微下调至更合理的范围，可能节省 50% 的成本，而对用户体验的影响微乎其微。后台任务绝不应以最高速度运行，这是优化成本最直接的手段。
混合部署架构与极致成本控制
在明确流量模式后，基础负载（Base Load）的确定性是节省成本的关键。许多企业的 AI 流量具有突发特性，但始终存在基础负载。对于这部分稳定需求，专用实例（Dedicated Instances） 是成本最低的选择，前提是资源被充分利用。对于突发流量，可结合公共云（Public Cloud） 进行弹性伸缩：限制专用实例容量以覆盖基础负载，让峰值溢出至公共云。这种混合架构需要基于对 Token 工作量的精确测量和验证。
"The biggest cost savings you have right now in the market is deploying a dedicated instance if you know your base workload."
通过这种精细化的流量管理和部署策略，成本优化效果显著。以 Featherless AI 服务的一个客户为例，该模型为 4.8 Opus 级别，处理了 2 Trillion（两万亿） Tokens。通过优化部署和权衡速度/成本，其最终支付价格低于 $0.03 / 1 Million Tokens。这一价格在市场上几乎无法通过其他通用渠道获得。值得注意的是，极端峰值对整体成本的影响往往被高估。除非企业每月仅运行一次极大规模的短时负载，否则基础工作量的优化才是成本控制的根本。忽视流量模式而盲目追求峰值性能，是导致 AI 账单过高的主要原因之一。
警惕投入产出比的失衡现象
除了技术层面的优化，组织内部的流程和问题同样值得关注。当前出现了一个令人担忧的趋势：许多企业在 AI 上的 Token 支出增加了 10-100 倍，但并未看到相应比例的生产力提升。这种投入与产出的严重失衡开始引发广泛讨论，部分报告指出 AI 在某些场景下的生产力提升仅为 6%-7%。这提示我们，在追求技术极致和成本优化的同时，必须重新审视 AI 应用的实际业务价值。单纯增加 Token 消耗并不等同于提升效率，企业需要建立更严格的评估机制，确保每一分 AI 支出都能转化为可衡量的业务成果。这不仅是一个技术问题，更是一个战略和管理问题。
AI滥用导致Token成本飙升而非效率提升
当前AI应用的普及程度并未达到许多人预期的规模，主要原因在于组织内部普遍存在“拿着大锤子到处敲”的滥用现象。AI本身并非无用，问题在于过度泛滥地部署和使用。许多团队将AI视为通用的Copilot随意调用，导致资源浪费。演讲者Eugene Cheah指出：“这不是AI没用的问题，而是我们倾向于到处 spam 它。”这种无序的扩张不仅没有带来预期的生产力飞跃，反而让使用者感到困扰。当AI介入过多时，人们甚至希望它能停止作为另一个Copilot存在。Token的消耗并不等同于实际完成的工作量，盲目增加Agent数量和Token用量往往无法解决根本问题。因此，必须警惕这种粗放的使用方式，并根据实际情况调整策略。
组织流程滞后成为新的效率瓶颈
随着AI部署规模的扩大和生成速度的加快，组织架构和处理流程往往无法同步提速。在编码环境中，第一个出现的瓶颈通常是CI/CD（持续集成/持续部署）流程；而在其他场景下，CPU可能成为瓶颈。更深层的问题在于信任与审查机制的缺失。演讲者提到：“缺乏信任是导致事情变慢的原因。”这种滞后可能是合理的，例如AI Agent设计不佳导致不可信；但也存在一种反向情况：即使Agent完美执行了任务，如果缺乏测试、验证和信任构建机制，人类依然不敢采纳，从而拖慢整体进度。这些非技术性的流程障碍对效率的影响远超想象。必须仔细审视AI的使用方式，并相应调整组织流程。
代码生成中的“反模式”与审查困境
一个常见的反面案例是，团队为了快速解决问题而自动化处理QA报告的问题，这本身是很好的实践。但当人们变得过于激进时，倾向于进行大规模代码变更（如修改四分之一甚至一半的代码库）。这种大范围的改动导致审查者无法处理，因为人类无法快速消化海量代码。当生成的代码量过大时，审查者往往选择忽略未生成代码的问题部分，或者要求Agent重新高亮相关变更。最终结果往往是审查者发现生成的代码过于庞大且难以理解，不得不丢弃Agent的第一次工作成果，转而手动结合Agent重新实现。这揭示了如果不经思考地堆砌AI产出，只会增加审查负担而非提升速度。解决之道在于建立更好的测试实践以自动化过滤问题，并将合并请求模块化以便审查。这属于人类流程范畴，与AI本身无关。
“Slop Grenade”现象与文化反思
这种低效不仅限于代码，也蔓延至PPT制作、报告生成等领域。例如，有人使用AI一次性生成整套幻灯片设计并分发给团队，导致其他人需要花费大量精力去筛选不一致、错位或数据矛盾之处。这种将生成负担转嫁给下游验证者的行为被称为“Slop Grenade”（垃圾手雷），即生成大量低质内容并扔给别人清理。演讲者强调：“不要让Slop Grenade发生。”这不仅是技术问题，更是文化和流程问题。尽管现状令人担忧，但演讲者仍持乐观态度，认为这是组织学习和适应的过程。关键在于深入了解自身业务领域，找到能节省数百万美元或大幅提升生产力的特定用例。正如沃尔玛通过在卡车里放置踏板来降低背部受伤率一样，最有效的AI应用可能并非最复杂的模型，而是针对特定痛点的简单改变。因此，避免盲目堆砌Token，转而优化流程和提升信任度才是正解。
确立责任归属与以结果为导向的衡量标准
在构建企业级AI治理框架时，首要原则是确立清晰的责任边界。演讲者提出了一条主观但至关重要的指导规则：防止“垃圾数据炸弹”（slop grenade）的发生，必须强制要求使用者拥有其提交或生成的所有内容。这意味着责任不能推卸给AI代理（Agent），如果生成内容出现错误，使用者必须承担全部责任。无论是文本、代码还是其他任何由AI生成的产物，责任主体始终是人而非机器。这种“所有权即责任制”的逻辑是防止滥用和确保数据质量的基础。
在衡量AI价值时，核心应从“使用量”转向实际产生的结果（Outcomes）。虽然业界常有一个经验公式：Token数量乘以单价除以产出效果，用于指导模型选择（如小模型、高效模型或大模型的取舍），但演讲者认为这一指标存在局限性。他建议将AI视为增强团队能力的补充剂或类固醇。以建筑工人增加肌肉质量为例，虽然AI能提升生产力，但团队本身的素质差异依然显著。因此，单纯依赖Token消耗量来衡量AI效能是片面的。企业应首先测量每个部门或团队消耗的Token数量，观察哪些团队表现更好、如何使用更合理。尽管这是一种有缺陷的测量方式，但它是起步阶段的关键步骤。通过内部测试（如谁花费了多少、基础负载是多少、哪些工作流需要更快速度），企业可以逐步优化其Token经济学。
微调策略的误区：从SFT到Prompt Tuning的转变
关于模型微调（Fine-tuning）的具体方法，业界常关注监督式微调（SFT）、强化学习（RL）等技术。演讲者指出，虽然在编程环境中RL因易于生成循环数据而流行，但在金融等严谨领域（如纽约的金融机构），往往缺乏适合RL的环境，因此SFT仍是主流选择。然而，过度纠结于微调技术本身可能是错误的方向。演讲者分享了一个关键案例：在Jeff模型发布后，团队尝试用开源的Qwen 27B模型进行复刻。起初，许多团队选择对Qwen 27B进行SFT微调；而Featherless AI则采取不同策略，直接对现有模型进行Prompt Tuning（提示词工程）。
两周后，当Hugging Face对超过10,000个问题进行大规模基准测试时，结果显示：经过Prompt Tuning的Qwen 27B击败了大多数经过SFT微调的同规模模型。演讲者强调，这并非为了炫耀，而是说明调优方法可能不是核心问题，关键在于评估（Evals）和最终结果。虽然该模型后来被Cloudflare基于更严谨流程微调的模型超越，但这一案例揭示了评估驱动决策的重要性。企业应关注的是如何通过有效的评估体系来验证模型性能，而非盲目追求某种特定的微调技术。这种以结果为导向的思维模式有助于企业在快速变化的AI生态中找到最优解。
数据质量与黄金样本：微调成功的基石
在进行SFT或任何模型优化时，数据集的质量至关重要。针对是否需要对错误数据进行过滤的问题，演讲者分享了个人经验：倾向于将数据分为两部分，其中包含较小的“黄金样本数据集”（Golden Trace Dataset）。虽然人们往往因懒惰而不愿过滤数据，但黄金样本对于实现超越基线性能至关重要。在训练过程中，会对这部分高质量数据赋予更高的权重。值得注意的是，近期关于“思考Token”的研究表明，即使模型在任务中失败（给出错误答案），微调过程仍能通过改善其推理思维带来收益，这说明非完美数据也有一定价值。
对于客户而言，微调小模型的核心动机通常非常明确：能否在保持性能接近原水平的同时（评估分数可能下降1%或甚至提升10%，因为基础模型未针对特定任务优化），将账单成本降低 100倍。演讲者指出，虽然增加黄金样本比例有时是必要的，但大多数情况下需要人工介入查看数据。尽管客户往往不喜欢这种繁琐的工作，但在追求极致性价比和性能平衡时，人工审核数据质量是不可或缺的一环。这种对数据细节的把控，结合前述的结果导向评估体系，构成了企业AI落地中成本与效能平衡的关键闭环。
摆脱厂商锁定：从单一依赖到灵活架构
面对代码支出主要来源于特定大模型（如 Claude Code）导致的生态锁定问题，首要策略是提升底层执行框架的灵活性。虽然部分组织倾向于完全绑定单一工具（如仅使用 Devin 或 Mboni），但更先进的做法是构建或使用通用的 Agent Harness（智能体执行框架）。通用框架具有更高的可移植性，能有效避免被单一供应商锁定。 在实际迁移中，许多团队转向了 Pi 等轻量级框架。这种转变的核心驱动力在于成本与效率：即使使用相同的底层模型，Pi 因其架构简单高效，能显著降低每 Token 的成本。这种轻量化特性使得团队能够轻松通过提示词工程对 Agent 进行微调，从而形成“实验-修改”的快速迭代循环。
结论
视频论证表明，AI成本失控主因并非技术瓶颈，而是缺乏精细化的Token经济学治理。核心策略包括：1. 精确测量与密钥隔离，识别高耗团队；2. 区分工作负载类型，代理型任务需优化调度与输入复用，分类/高并发场景应替换为低成本开源小模型或专用分类器；3. 摒弃“足够好”误区，通过基准测试与微调（如SFT或Prompt Tuning）匹配最廉价有效模型；4. 警惕“垃圾手雷”式滥用，建立以结果为导向的责任制。最终结论是：通过混合部署架构、错峰运行及垂直领域微调，企业可将成本降低数个数量级（如从$250k降至$7.6k），但需同步优化组织流程与信任机制，避免技术红利被低效管理抵消。