Fireworks 创始人 Lin Qiao：小模型如何民主化 AI 应用场景 | 训练数据
摘要
Fireworks AI 创始人兼 CEO Lin Qiao 分享了从领导 PyTorch 到构建生成式 AI 推理平台的非凡旅程。作为 Meta 前 PyTorch 负责人，Lin 曾将 PyTorch 从研究框架打造成支撑全球机器学习生态的基石——日均处理超过 5 万亿次推理请求。她创立的 Fireworks 致力于将这一整套推理与微调栈"从 5 年压缩到 5 周甚至 5 天"，帮助企业以前所未有的速度和低成本将 AI 投入生产。Lin 提出了一个关键市场洞察：训练规模与研究员数量成正比，推理规模与客户数量成正比——而 AI 产品的客户数量最终将远超 AI 研究员。她深入阐述了"小模型策略"为何是企业的正确选择：在开源模型质量快速追赶闭源模型的趋势下，真正的差异化来自针对具体使用场景的定制化微调和极致优化。Lin 还分享了她对 Nvidia 竞争格局、模型商品化、以及"函数调用模型"如何成为连接模型与 API 的关键粘合剂的独到见解。
正文
从 PyTorch 到 Fireworks：简化之道的传承
Lin Qiao 在 Meta 的经历堪称传奇。当她接手 PyTorch 时，Meta 内部实际上有三个不同的深度学习框架：用于移动端的 Caffe2、用于服务端生产的 ONNX、以及用于研究但"过于复杂"的 PyTorch。她的任务是将三个框架统一为一个——这被称为一个"不可能完成的任务"。
最初的方案是一个看似简单的折中：用 PyTorch 的前端 + Caffe2 的后端，把它们"缝合"在一起。但这两个框架从未被设计为协同工作，集成复杂度甚至超过了从零开始构建一个新框架。最终团队做出了一个大胆的决定：保留 PyTorch 优雅简单的 API 设计，但从头重建整个后端。
这就是 PyTorch 1.0（TorchScript）的由来。
"我们本以为替换其他框架只是换个库的事——能有多难？我们估计这是一个六个月的工程。结果证明，要支持 Meta 的全部 AI 工作负载，需要整整五年。"团队不得不从零开始重建整个推理和训练栈——从高效数据加载到分布式推理，再到大规模训练扩展。当 Lin 离开 Meta 时，PyTorch 每天支撑超过 5 万亿次推理。这催生了 Fireworks 的核心使命：将整个行业从 AI 模型到生产部署的时间从五年压缩到五周甚至五天。
Lin 将 PyTorch 的成功归因于一个核心理念：简约即规模（Simplicity scales）。"这是一种永不停歇的对简约的追求——不断让用户体验变得更简单，把更多复杂性隐藏在后端。"这一理念直接延续到了 Fireworks：提供一个极其简单的 API，但背后隐藏着大量的自动化、自调优和复杂性管理。
训练 vs 推理：为什么推理才是更大的市场
Lin 分享了一个她早在创业时就形成的核心洞察：训练规模与研究员数量成正比，推理规模与客户数量成正比。
在 AI 发展初期，大部分注意力集中在训练——更大的模型、更多的参数、更长的训练时间。但随着生成式 AI 的成熟，推理正在成为更大的市场。"如果你有一个面向消费者的 AI 产品，低延迟是生死攸关的——没有人会愿意等半分钟才收到回复。同时，如果你的产品真的有用，用户规模会迅速扩大。如果你在小规模时就在亏钱，规模扩大后只会破产得更快。"
她观察到的客户旅程具有高度一致性：初创公司通常从 OpenAI 开始——因为它提供了最强大的模型来进行实验和产品市场匹配（PMF）探索。但一旦他们找到了 PMF 并需要规模化时，两个痛点同时出现：
1. 延迟太高：消费者应用需要毫秒级响应
2. 成本不可持续：无法在单位经济效益为负的情况下增长
这就是他们转向 Fireworks 的时刻。Fireworks 的优势在于：它不是仅仅提供模型推理，而是通过手写 CUDA 内核、分布式推理、跨 GPU 的解耦推理、语义缓存、以及针对特定使用场景的优化来将延迟和成本降到极致。
小模型的威力：千花齐放 vs 一枝独秀
Lin 对开源与闭源模型的未来有一个清晰的预测：在同一模型大小级别内（例如 7B-70B 乃至 100B 参数），开源模型和闭源模型的质量终将趋同。"这只是一个时间问题——几年后我们回到这个播客来看看谁是对的。"
如果这一趋势成真，那么真正的差异化就不在于模型的原始能力，而在于针对具体使用场景的定制化能力。闭源模型公司（OpenAI、Anthropic 等）聚焦于少数几个模型——他们押注的是"通用性"，追求 AGI。但企业面临的现实是不同的：有成千上万种具体问题需要解决。
"这就是小模型的威力所在。它更容易微调，更容易针对特定问题空间进行优化，更容易实现高质量。它让千花齐放。"
Lin 举了一个具体例子：基于 Llama 3 做函数调用（function calling）微调，比基于 Mixtral 或 Llama 2 容易得多——因为 Llama 3 的基础能力（指令遵循、逻辑推理）已经极其强大。这意味着微调从一个"重新训练"的问题变成了一个"对齐"的问题——成本大幅降低，效果大幅提升。
微调的复杂性：远非"一键完成"
尽管 Lin 是微调的坚定倡导者，她也坦诚地指出了微调的复杂性。"人们觉得微调很简单——只是调一下参数。但实际上，端到端的微调需要企业完成一整套流程：从生产环境中收集数据 → 追踪和分析 → 标注 → 选择微调算法（监督微调、DPO、偏好学习等）→ 决定使用参数高效微调（LoRA）还是全量微调 → 调整超参数……每一个环节都有技术深度，而大多数应用开发者甚至从未接触过 AI。"
更复杂的是，很多"失败案例"其实不是模型的问题，而是产品设计的问题。她举了一个例子：一个 AI 助手在表格中自动生成内容——当光标在某个单元格中时，"自动生成"应该是什么意思？是扩展单元格内容？是生成更多行？还是什么都不做？这本质上是一个 PM 应该思考的产品设计问题，而非模型能力问题。
Fireworks 的愿景是：将所有这些繁琐的技术细节（数据自动标注、微调算法自动选择、超参数自动调优）全部自动化，同时保留产品设计部分给用户——让应用开发者只需要关心"我的产品应该如何响应"，而不是"我应该用什么微调算法"。
函数调用模型：连接一切的粘合剂
Lin 分享了 Fireworks 最令人兴奋的产品方向：函数调用模型（Function Calling Model）。
当前的基础模型无论如何强大，其知识都是有限的——训练数据有截止日期，互联网上可爬取的信息终究有限，大量知识隐藏在 API 和企业私有系统之后。Fireworks 的解决方案是构建一个智能的"路由器"层——一个能够理解可用 API、自动决定调用哪个 API、并以最精确的方式执行调用的模型。
"你可以把它想象成一个更大规模的混合专家模型（Mixture of Experts, MoE）——MoE 有一个路由器坐在几个大专家上面，每个专家专精于自己的领域。我们的愿景是构建一个能访问数百个专家的 MoE——每个专家都更小、更敏捷、但能在特定问题上提供极高质量的输出。"
实际上，Fireworks 已经提供了超过 100 个模型——涵盖语言模型、图像生成、音频生成、视频生成、嵌入模型和多模态模型。函数调用模型将成为协调所有这些模型和外部 API 的"大脑"——让开发者不需要自己搞清楚"我应该用哪个模型、如何微调、如何连接 API"。
竞争格局：Nvidia、OpenAI 与未来架构
关于 Nvidia 的竞争，Lin 的回答是"竞争即将到来"——这既是经济学的必然（任何利润丰厚的市场都会吸引竞争），也是行业趋势（业界天然不喜欢垄断）。她从两个维度分析：在通用 GPU 领域，AMD 正在崛起；在专用 AI 芯片领域，当模型空间趋于稳定、问题定义清晰时，定制化 ASIC 将发挥重要作用。
在模型能力是否即将进入平台期的问题上，Lin 给出了一个微妙的回答：一方面，她认为同一模型规模级别的能力确实会趋向稳定，这意味着优化和定制化的价值将上升；但另一方面，她以 Meta 的经历提醒自己——"我们曾经认为推荐系统排序模型已经稳定了，但几年后发现完全不是这样，模型架构创新在一个看似稳定的空间里重新爆发，将 S 曲线推向了新的高度。在生成式 AI 领域，同样的事情会再次发生。"
至于 OpenAI 是否让她夜不能寐——Lin 的回答是"不"。OpenAI 在追求 AGI，这是一个了不起的使命，但它解决的是一个与企业问题不同的问题。企业有成千上万种具体的、定制化的问题需要解决——这正是小模型和 Fireworks 的核心战场。OpenAI 也在将模型做得越来越小、越来越便宜——这在某种程度上验证了 Lin 的策略方向。
"我认为对于同一模型规模级别，闭源和开源的质量会趋同。真正有意义的事情是推动自动化的、针对具体用户场景和工作负载的定制化——我无法确定 OpenAI 是否有兴趣做这件事。"