最便宜的推理供应商最危险：Meta PyTorch老兵把大模型推理的门道讲透了

两年前，用GPT-3处理一百万token要花60美元。今天，一个160亿参数以下的开源模型，同样的量只收20美分，能力还更强。300倍的降价，就发生在这门叫「推理」的生意里。

这期Cognitive Revolution请来的，是Fireworks AI的两位联合创始人：林乔（Lin Qiao）和Dmytro Ivchenko。两人都在Meta做了五年PyTorch，那是今天全球AI应用默认的开发框架。Fireworks做的事叫推理服务，帮开发者把大模型跑得又快、又稳、又便宜。

主持人Nathan Labenz开门见山：推理是不是一门低毛利的商品生意？林乔的回答很干脆。

倒卖显卡的生意，创业第一周就放弃了

林乔回忆，公司刚成立时确实讨论过做GPU套利，显卡紧缺，转手就有利润。团队很快否掉了这个方向。转售硬件是低毛利生意，撑不起一家长期公司。

市面上还有更危险的玩法：有些推理供应商用Uber早期烧钱补贴的方式定价，价格明显压到成本线以下。林乔的原话很直接：

这种人为压出来的价格，撑不起可持续的长期生意。开发者在这类平台上构建应用时至少要小心，因为这些公司烧完融资就会消失。

那Fireworks靠什么立足？三个词：低延迟、高质量、低总拥有成本（TCO）。林乔特意补了一句，低价从来排不上号，低TCO只是高性能带来的副产品。

为什么TCO这么关键？传统应用跑在便宜的CPU上，毛利很高。生成式AI跑在GPU上，卡贵，还特别吃电，普通风冷压不住温度，得用液冷，甚至把显卡整个泡进油里做浸没式冷却。这些全是运营成本。很多AI应用死掉，死因是产品能跑通，账算不过来。Fireworks干的活，就是把这笔账救回来。

Nathan自己也踩过坑。他说工程师做自建方案时，很少把自己的工资算进成本，账面数字远低于真实数字。

Meta的五年，压成五天

两位创始人在Meta的经历，是这期节目里最有分量的部分。林乔给了一组数字：Meta内部部署了超过60万块H100等效算力，耗电相当于60万个美国家庭，大约是两个旧金山市的用电规模。这不是一夜建成的，团队花了五年多。

五年里踩的第一个坑叫「zipper」。2018年Meta内部有多个AI框架，移动端的Caffe2、服务端的ONNX，任务是统一成一个PyTorch。团队想了个理想主义方案：把好用的PyTorch前端和高性能的Caffe2后端像拉链一样缝起来。结果惨败，两个框架的集成成本，比重写一个新框架还高。

最后他们保留PyTorch前端，把后端重写成TorchScript解释器。设计哲学就此定型：死守易用性这条线，把全部复杂性吞进后端。两年前团队又推出TorchCompile，连手动标注代码的步骤都自动化了，这就是PyTorch 2。

第二个教训更贵。他们原以为把PyTorch推进生产环境就是换几个库，结果发现框架创新需要一整套全新的基础设施服务来支撑：新的数据加载器、新的数据变换层、新的训练循环、新的分布式推理服务。五年后，他们从零写出整个PyTorch平台，每天在50个数据中心处理50万亿次推理。

Fireworks的野心就藏在这段经历里：把Meta那五年，压缩成行业的五周，甚至五天。

真正的对手是OpenAI和Anthropic

聊到竞争，林乔的答案出乎意料：Fireworks的对手名单里没有其他推理供应商，真正的对手是OpenAI和Anthropic。

先看价格。Fireworks把16B参数以下的模型定在每百万token 20美分，Anthropic的Haiku收25美分。价格已经贴身肉搏，拼低价没有出路，只能拼质量。

林乔的核心判断是：同尺寸的开源和闭源模型，质量最终会收敛。理由有两条：小模型的参数量决定了知识吸收的上限，而各家能拿到的训练数据也在趋同。就在录制那周，Mistral刚放出8个专家、每个约22B参数的MoE新模型，Fireworks当天就上线了支持；Llama 3几周内要开源；Google的Gemma持续更新，阿里的Qwen和零一万物的Yi也越来越强。

质量一旦收敛，开源的生态优势就会放大：开发者微调开源模型后再开源出去，一棒接一棒，有复利效应。Fireworks整个公司押在这个生态上。

但开源小模型现在还差一口气，往往需要微调。这里有个关键洞察：企业面对的问题其实很窄。林乔举了一串例子：按意图路由到不同agent、给商品目录做分类、搜索结果重排序、从收据和医疗账单里抽结构化数据、改写销售跟进邮件。把模型对齐到一个窄问题上，远比让它同时搞定一百个问题容易。所以现实里的任务，小模型加微调基本都能拿下。

主持人Nathan用自家公司Waymark做了佐证。他们的核心功能是给商家写视频脚本，用的是微调过的GPT-3.5。GPT-4也试过，太慢，而且业务规则太多，prompt里塞不下，成本反倒是其次。微调数据集只有几百条，效果就相当好。窄任务的微调，几百条数据就够，多数人高估了门槛。

微调为什么快？Fireworks主打LoRA（低秩适配）：冻结预训练权重，往Transformer每一层注入两个小矩阵，只训练这两个小矩阵。林乔现场算了笔账：一个2000乘5000的权重矩阵，原始参数1000万个；分解成2000乘1和1乘5000两个小矩阵，参数量变成7000个，缩水上千倍，训练开销跟着骤降。

推理侧还有更妙的玩法。假设客户有100个LoRA适配器，天真的做法是每个都和基座模型合并后部署，显存里躺着100份完整模型。Fireworks的做法像一棵树：基座模型当树干，100个适配器挂在树干上共享显存。同样的业务，成本直接省100倍。他们是最早这么做的公司之一。

产品设计上还有个务实细节：Fireworks的API刻意做到和OpenAI兼容。林乔的逻辑是，开发者先用OpenAI试想法，等需要更深度的微调、更低的延迟和成本时，迁移过来的改动最小。

硬件一换代，代码就得重写

这部分Dmytro讲得最硬核。Transformer推理真正吃性能的只有两个操作：矩阵乘法和注意力。但文本生成分成两个阶段，优化策略完全不同：

• 处理输入的prefill阶段，token多，瓶颈在算力，batch可以开到几万；
• 逐个生成token的decode阶段，瓶颈在显存带宽，batch通常只有16到200。

Nathan一开始把两个阶段的区别理解成逐token搬运参数，Dmytro给了个更简单的版本：prefill阶段token多到能把GPU算力喂饱，decode阶段token太少，GPU大部分时间在等数据从显存搬过来。典型应用的输入输出比大约10比1，所以两个阶段都得单独优化。KV缓存把生成的复杂度从二次方降到线性，多查询注意力（MQA）这类技术又把缓存体积砍到几分之一，但缓存再小也得常驻显存。

NVIDIA为什么一家独大？Dmytro拆成两半：一半是硬件，H100有2 petaflops算力，Blackwell翻倍，超芯片冲到10 petaflops，显存带宽和互联同步升级；另一半是开发者生态，CUDA深耕多年，护城河极深。AMD的MI300硬件规格已经反超，ROCm软件栈在开源追赶；Intel的Gaudi 3性能卡在H100和Blackwell之间。挑战者都有机会，但软件生态的债得一天天还。

真正让优化永无止境的，是硬件换代。Dmytro梳理了精度演进：从FP32到FP16，再到FP8，Blackwell上出现FP4，最新论文甚至做到1.58比特，参数只剩0、1、负1三个值，乘法直接消失，只剩加法。每换一次精度，指令集就变一次。为旧硬件写的kernel，放到新卡上可能只剩一半性能。FlashAttention 2是为上一代Ampere架构写的FP16实现，放到H100上跑，性能直接腰斩。

编程栈也在变复杂。H100的Tensor Core要靠CUDA核心异步启动，两层异步叠加，导致公开的高质量H100 kernel数量断崖式下跌。OpenAI的Triton编译器是条出路：用Python写，编译成中间表示再落到硬件指令，代码可读性和可维护性好得多，性能能逼近手工调优。但想压榨到极致，最后还是得检查生成的指令。

至于专用芯片，Dmytro点了Groq的名：把共享显存搬到芯片内部，生成速度快得惊艳，代价是算力单元缩水、片上内存昂贵、每部署一个模型要花数百万美元搭专用环境。演示很酷，现实世界里还只是边缘案例。

并行策略也有口诀。张量并行切权重，能降延迟但吞吐会掉；流水线并行切层，只救装不下的大模型，对延迟没帮助；数据并行切输入，最便宜但注意力计算要特殊处理。能不切就不切，每多切一次，吞吐就掉一截，毕竟跨GPU通信比GPU内部访问寄存器贵好几个数量级。

数据库的老故事，正在推理行业重演

林乔打了个比方。二十多年前数据库刚普及时，每家公司都得雇DBA手工调参数，这批人收入很高。后来数据库系统里长出了优化器，观察工作负载，自动建索引、自动分区，DBA这个职业就慢慢消失了。

她认为推理行业正走同一条路。今天的Fireworks还要根据客户的工作负载人工挑配置：客户在乎首token延迟还是端到端延迟？输入输出比多少？上下文多长？有没有重复prompt？每个答案对应延迟成本曲线上不同的点。

延迟的定义也因应用而异。语音应用真正卡脖子的是前30个token的到达时间，因为语音流式输出前得先攒够一小段才能开口。Nathan说他给企业高管做分享时，第一条建议就是学会看帕累托曲线，从延迟成本到误报漏报，每一层都逃不开这条曲线。

Fireworks的产品分三档。开发者档入门，商业档是无服务器按量付费，企业档客户带着明确的预算和负载画像来，Fireworks帮他们在曲线上选好点，部署专属配置。Nathan举了个典型场景：一家企业有三个应用，语音应用要求首token极快，后台批处理只求最便宜，聊天机器人居中。按这套打法，三个应用会得到三种完全不同的部署配置。而企业流量分布永远偏斜，几个大头应用单独优化，长尾应用合并成一个部署桶，用一套配置兜住。

终局是自动化：系统观察客户跑的真实负载，自我调优，延迟越来越低，质量越来越高，客户不用再找人工选配置。就像当年的数据库优化器，只是这次调优的对象换成了GPU集群。

函数调用、独家生意，和明天就能用的清单

Fireworks也自己训练模型，比如函数调用模型，已经开源两版，第三版在路上。林乔的解释是一个知识分层框架：LLM的知识受训练数据限制，有时间截止，也拿不到爬不到的私有信息；大量知识活在其他模态（图像、视频、音频）和各种API里。一家企业内部动辄几百个API接口，还有键值存储、文档库、生产日志。函数调用就是把所有这些知识源串起来的那一层。她设想的应用形态是个人助理：学习你的偏好，在你开口之前把活干完。

节目末尾有个加录的彩蛋：主录制一周后，Fireworks宣布与Stability AI达成合作，成为Stable Diffusion 3的独家推理供应商。技术上的关键点是SD3改用了Transformer架构，以前基于ResNet和卷积的老架构退休了，文本模型上积累的优化经验可以大部分平移到图像模型上。

图像生成和文本生成有个本质区别：从随机噪声出发，每次前向传播做一步去噪，SD3默认跑约50步，turbo版本只要约4步，牺牲质量换速度。量化策略也不同：文本模型必须保住激活值里的尖峰，因为尖峰影响下一个token的选择；图像模型的尖峰砍掉也无所谓，整体聚合才重要。文本模型的经验不能无脑照搬到图像模型。

至于为什么用户调用的还是Stability的API域名，Dmytro解释，Stability对模型滥用很敏感，专门训练了输入过滤模型，输入消毒这一环必须握在自己手里，所以请求先到Stability，过滤后再路由到Fireworks。

Nathan是Mamba架构的爱好者，追问SSM会不会进路线图。林乔的回答很冷静：客户需求几乎为零。SSM去掉了Transformer的二次方复杂度，理论上擅长长上下文，但纯SSM模型的质量至今追不上同级别的Transformer。AI21 Labs开源的混合架构Jamba是折中方案，实际效果还有待验证。更麻烦的是，行业连长上下文质量的统一评测标准都没有，常用的「大海捞针」测试太简单。

最后是这份清单，明天就能用：

• 选推理供应商，别看最低单价，看延迟稳定性。把工程师自建基础设施的工资算进TCO，大多数自建都不划算。
• 窄任务先试微调，几百条数据就够。用LoRA，迭代飞快，别一上来就堆几万条数据。
• 部署多个微调模型时，找支持共享基座的供应商，成本差距是百倍级的。
• 在补贴定价的平台上建应用，记得留迁移后路。选API兼容OpenAI的供应商，切换成本最低。

这门生意的本质，用林乔的话说就是：你专心做产品，脏活累活我们包了。至于脏活有多脏，60万块H100和五年PyTorch，就是答案。