MiniMax H3 MAX 的 AI 直播火了：背后这家估值 45 亿美元的推理独角兽却鲜为人知

单次推理优化或速度本身从不是护城河。我们最关心的是：面对新的模型和架构，我们能多快跟进？——Batuhan Taskaya，Fal 创始工程师

MiniMax H3 MAX 「24 小时直播、无限 AI 生成」的爆火，让训练该模型的公司 Fal 进入开发者视野。

基于 MiniMax H3 后训练而来的 H3 Max，已经把视频生成速度推过了实时播放的门槛：Fal 公布的内部评估显示，生成 5 秒视频不到 3 秒，吞吐量约为 MiniMax H3 官方接口的 35 倍。随后上线的 H3 Max Live 更直接把它做成了一场实时实验——观众在聊天室输入 Prompt，下一段带声音的视频几秒内生成并接入直播流，让生成式视频从「等一个片段」变成可以持续运行的内容系统。

而 H3 Max 更值得注意的地方是，它并不只是快。在 Fal 的人工偏好评估中，它在整体质量、指令理解和美学表现三项指标上都排名第一。

但如果把时间往前拨几年，会发现 H3 Max 并不是 Fal 突然开始做模型研究后的产物。

今天的 Fal 是一家生成式媒体云公司，为图像、视频、音频等生成模型提供训练后优化、推理和部署基础设施。但 2021 年公司刚成立时，它甚至还不是一家 AI 公司。Fal 最初从数据工具和 Feature Store（特征存储）起步，名字本身就来自 Features and Labels。虽然当时还没有进入 AI 基础设施领域，但团队已经积累了一套能够在云端规模化运行 Python 代码的无服务器基础设施。

Stable Diffusion 等生成模型兴起后，Fal 开始把这套能力转向 AI 推理，并押注图像生成，随后逐步扩展到视频和音频。这个转型也获得资本市场持续加注：2024 至 2025 年间，Fal 连续完成多轮融资，累计披露融资约 3.37 亿美元，最新估值 45 亿美元。

而几乎完整经历这条路线的人，就是 Fal 工程负责人 Batuhan Taskaya。

Batuhan 是 Fal 最早期的工程师之一。加入公司之前，他长期活跃于 Python 开源和编译器生态；2021 年，在 Fal 完成种子轮融资前加入公司。此后，他先后做过云端 Python 分布式运行环境、编译器、自研推理引擎、应用机器学习和模型后训练，如今负责 Fal 的整个工程团队工作。

沿着 Batuhan 的经历往回看：一家最初做数据工具、只有 6 个人的公司，是怎样一步步把 Python 云计算、GPU 基础设施、推理优化和模型后训练串起来，最终走到 Minimax H3 Max。

核心观点

Batuhan Taskaya

Fal 创始工程师、工程负责人；

Python 开源维护者

H3 Max 不是 Fal 突然开始做模型，而是多年技术积累的一次汇流。 从无服务器 Python、GPU 基础设施、推理引擎到模型后训练，Fal 最终把「改造模型」和「加速推理」两条能力合到了一起。
Fal 押注图像，是一个 6 人团队主动做出的取舍。 当 LLM 已有 OpenAI 等强势玩家时，Midjourney 已验证图像需求，但市场仍缺少稳定、可扩展、成本足够低的生成式媒体基础设施。
Fal 真正的护城河不是某一次跑得最快，而是新模型出来后能多快优化到位。 单项性能迟早会被 NVIDIA 和开源社区追平，Fal 更看重持续跟进新模型、新 GPU 架构的速度。
从图像扩展到视频，本质上是沿同一批客户继续做深。 视频模型真正可用后，Fal 将其接入原有图像工作流；约一年时间，视频就从收入占比 0% 增长到接近 50%。
Fal 想做的不是基础模型公司，而是模型与应用之间的中立基础设施层。 它一边运行第三方模型，一边基于开源模型做微调、蒸馏和推理优化；最终衡量模型价值的，也不是公开排行榜，而是客户自己的留存、转化率和业务 Benchmark。
Batuhan 的个人经历，几乎就是 Fal 技术演进的缩影。 从 Python 开源维护、云端分布式运行环境，到编译器、自研推理引擎、应用机器学习和模型后训练，他个人角色的变化，也对应着 Fal 从数据工具一路深入 GPU 基础设施、生成式媒体推理乃至 H3 Max 的过程。

嘉宾：Batuhan Taskaya（Fal 创始工程师、工程负责人；Python 开源维护者）

主持人：Tim Chen（Essence VC）、Robby（Modern Technical Fund）

注：为便于阅读，本文在原始播客转录稿基础上进行了提炼、重组与术语校正，并非完整对话。

从土耳其硬核 Python 开源维护者到 Fal 工程负责人

主持人：欢迎 Batuhan，你是如何认识 Fal 的创始团队，又为什么会在公司成立第一年就加入？

Batuhan： 大约在 2021 年，Fal 刚成立或还处在成立前夕。当时我人在土耳其，我觉得自己是当时土耳其少数几个真正硬核的开源维护者之一，尤其是在 Python 生态里。Fal 的创始团队正在围绕 Python 构建数据管道工具，因此主动联系了我。

一位创始人在纽约，另一位联合创始人兼技术负责人 Yurkem 在旧金山。我们虽然远程合作，但有相近的土耳其文化背景，相处也很投缘。几个月后，我在公司完成种子轮融资前正式加入，并一直工作到现在，我做过很多基础设施方面的工作。

最开始，我搭建了让 Python 代码在云端运行的分布式系统基础设施。后来公司开始做模型推理，我把重心转向编译器，参与自研推理引擎，用来运行和加速开源机器学习模型。再往后，我又进入应用机器学习和模型后训练。

所以我基本做过全栈，现在负责公司的整个工程团队。

从特征存储到生成式媒体云：Fal 的转型并非凭空发生

主持人：你们是怎么从最初的 Fal，一路做到今天的生成式媒体云的？

尤其是在 2022 年刚开始时，生成式媒体还远没有成为一个明确的大市场，虽然 GAN 已经存在，但行业还没有今天这样的共识。

所以从你加入、看到那个 Python 项目开始讲讲吧：后来到底发生了什么？

Batuhan： 我们最初做的是 Feature Store（特征存储）。其实 fal 这个名字就来自 features and labels。这个产品后来迭代了一阵，但到了 2021、2022 年，行业进入了「现代数据栈」非常火的阶段——Databricks、Snowflake 之后，大家都在谈数据转换、数据管道和大数据，那时候甚至还没有 ChatGPT，AI 也不是行业焦点。

我们当时发现一个空缺：本地的数据工具大量使用 Python，但到了云端，数据转换基本都是 SQL。

所以最初的问题很简单：能不能把 Python 带进云端的数据转换流程？

我们先基于 dbt 做了一个开源项目，让开发者可以在 dbt 工作流里运行 Python：一段 SQL 转换之后，可以接 Pandas DataFrame 处理，再继续跑 SQL。也就是说，让 SQL 和 Python 可以交替出现在同一条数据管道里。

有了这个基础之后，最自然的下一步就是上云、做规模化计算。比如把一个 1TB 的数据集拆成多份，并行跑 Python 转换，最后再用 SQL 汇总。

于是我们开始在云端做一个全托管、无服务器的 Python 运行时，目标是让 Python 代码在云端高效执行。这个基础后来也决定了我们的方向：Python 云计算最大的应用场景会是什么？答案逐渐变成了 AI 推理。

2022 年前后，Stable Diffusion、ChatGPT、DALL·E 等模型相继出现。我们手里正好已经有一套支持 GPU 的云运行时，于是最开始只是抱着实验心态：既然 GPU 已经有了，为什么不拿它来跑这些模型？

一开始，我们只是想看看，怎么把现有的云计算平台扩展到一个更常见的用例上。

我们后来发现，跑 AI 模型当然很有意思，但要把单个模型真正做成生产级服务，工作量其实非常大，因为其中还有大量性能可以挖掘。

当时我们必须做一个选择：到底专注优化哪一类模型？ 语言模型、嵌入模型，还是图像模型？可选方向很多，但团队只有 6 个人，不可能什么都做。

最后我们判断，图像是最值得切入的方向。

那时语言模型赛道已经很拥挤，OpenAI 也在大力推进 API；但图像这边，虽然 Midjourney 已经证明了市场需求非常大，真正可靠、可扩展、成本可控的图像推理 API 却几乎还是空白。

于是我们花了大约 6 到 9 个月「闭关」，专门研究一件事：

怎样让图像模型在云端跑得更稳定、更快、更便宜？

这也催生了我们最初的平台——一个面向开发者的生成式媒体平台。到了 2023 年底，我们开始正式全力推进这个方向，并逐步从图像 API 扩展到视频 API、语音、3D 模型、世界模型。原因也很直接：使用图像模型的开发者，往往也会需要视频和音频能力；但他们通常并不是语言模型 API 的核心用户，这是两套不同的市场。所以我们没有一边做媒体、一边再去追语言模型，而是围绕自己的用户群持续扩展。

这套路径带来了非常快的增长，也让我们逐渐从上层应用能力走向更底层的基础设施。我们开始为模型公司提供推理服务，支持他们带着自有模型接入，由我们负责优化和部署；同时也开始自建 CDN、分布式文件系统，以及更多类似超大规模云平台的底层能力。

这一策略之所以有效，也和市场结构有关。媒体模型赛道高度碎片化：有上百家公司在训练各种垂直模型，比如分割、抠图、背景移除等。正因为市场足够分散，我们反而有机会在其中拿下相当可观的份额。

所有人都在追 LLM，Fal 为什么偏偏押注图像？

主持人： 即使到今天，Fal 好像也没有特别强的直接竞争对手。很多公司都在追逐语言模型，语言模型仍然主导着行业讨论。

服务图像或视频模型，与服务语言模型到底有什么不同？在性能和基础设施上，你们需要建立哪些不同的能力？

Batuhan： 从技术层面看，语言模型通常是自回归模型，核心任务是预测下一个 token。而图像和视频模型则主要是扩散模型：从随机噪声出发，对整张图像或整段视频反复去噪，可能要重复二十次左右。这个过程高度重复，也非常消耗计算资源。

语言模型本质上是在移动一个巨大的万亿参数的矩阵来预测下一个 token，主要瓶颈通常是内存带宽。为了提高效率，服务商会把不同用户的请求组成批次，并在集群之间做并行计算。

图像和视频模型面对的是另一类问题，重点更偏向算法和底层计算内核的效率。这正是我们的优势所在：我们能够写出最好的内核，让这些模型跑得飞快。Fal 团队有分布式系统和性能工程背景，我们早期的优势，就是能够针对这些模型编写高效的计算内核，让它们运行得更快。

但我们从来没有把单次推理优化或速度本身看成护城河，开源项目最终会追上来。NVIDIA 光是做 TensorRT 这类推理引擎，可能就有四五十个人在投入。

我们真正关心的是：面对新的模型和架构，Fal 能多快完成跟进和优化。

新模型刚发布时，我们可以很快让它在 Fal 上达到更好的运行状态；如果只等待开源社区，可能要几个月才能达到类似的性能。我们会持续推出新的速度优化。这就是我们差异化的核心。语言模型领域的 vLLM、SGLang 也存在类似情况，它们与最大性能之间通常还留有距离。图像领域也是一样，只是面对的技术问题不同。

决定转型后，Fal 如何用 6–9 个月完成重建

主持人：决定做生成式媒体后，你们最先做的是什么？我猜测你们不会一上来就写推理引擎、定制内核吧？当时是怎么一步步执行的？

Batuhan： 最关键的市场判断是：语言模型赛道已经有 OpenAI 这样强势的玩家，而且它们能提供最好的模型和可规模化的 API，对我们这种小团队来说很难正面竞争。闭源方面，OpenAI 有 GPT-3 的 API。从 GPT-3 到 Llama 2 的差距，比今天前沿模型到 Kimi 的差距还要大。但图像生成领域不一样——Midjourney 已经证明了市场需求巨大，却没有开放 API；DALL·E 有 API 但模型当时不太好，市面上已有的图像 API 大多是简单把模型塞进 Docker 容器，速度慢、成本高、无法稳定扩展。

我们只是拿到一笔还算体面的种子轮融资，而看看那些公司，他们都在做 A 轮、B 轮。OpenAI 当时已经融资数十亿美元。对我们来说，专注于一个我们能真正做出差异化的类别，显然更合理。

这个落差让我们决定专注于图像。但真正的执行比这复杂得多。我们当时只有 6 个人，需要同时完成几件事。

第一，把系统从单云平台重构为多云 GPU 基础设施。 我们原来只是在 Google GKE（Google Kubernetes Engine，谷歌 Kubernetes 托管服务）上跑 Kubernetes，启动一个 pod 就能工作。但 2023 年 GPU 极度紧缺，Google 可能只能给你 8 块卡。为了拿到更多算力，我们必须支持 Lambda Labs、CoreWeave 等新出现的云厂商。这意味着要自己写调度层、自己建分布式文件系统、重新搭可观测和监控栈，几乎把原来基于 GKE 的一套全换掉。

我们本可以选择高价从 Google 签长约买 GPU，但那样就太贵了。我们选择去找最便宜的 GPU，自己搭建编排和系统层。

第二，开始系统性地做性能优化。 刚上 API 时，我们用 PyTorch 跑同样的模型，速度和别人一样。但生成一张图理论上需要多少 FLOPs、GPU 能提供多少 FLOPs，是可以算出来的——我们实际慢了 3 到 4 倍。这几乎不可接受。

我虽然是编译器背景，做过 PyPy JIT （即时编译器，在程序运行时把频繁执行的 Python 代码编译成机器码，从而提升运行速度）和数据库查询引擎，但完全没有 GPU 经验。不过性能工程的方法论是通用的：跑代码、做性能剖析、定位瓶颈、尝试优化、解决、再找下一个瓶颈。几个月内，我们就把 GPU 利用率从大约 30% 提升到 70–80%。

第三，在技术上赌一把的同时，用商业指标验证。 拿着原来的数据工具想法融了资，突然说要完全转型，这是很大的决策。所以我们在闭关期间就定了一个门槛：先拿下两个大客户，看看新业务能不能跑出收入。 特别是 Burkay 和 Gorkem，他们当时非常专注于怎么让两个大客户用上我们的 API，看看行不行。

对于一家新公司、一条你毫无经验的新产品线来说，最初获取客户的过程非常残酷。但一旦熬过去，就像打开了闸门。我们花了将近 9 个月才拿到两个客户，但正是这两个客户，让我们从新业务做到 100 万美元年化收入。

这给了我们放弃旧产品的证据。因为如果要靠原来的数据工具做到 100 万美元年化收入，会难得多。之后我们正式对外推出平台，约一年从 100 万美元涨到 1000 万美元，又在 2024 年 8 月到 2025 年 8 月再涨十倍，达到约 1 亿美元年化收入。

主持人： 这太疯狂了，从最开始的两个客户，到现在服务各种生成式媒体。在这么短的时间内，你们已经形成了一个应用开发者和模型构建者的市场。

从图像生成到视频收入占比近半：Fal 如何沿着同一批客户扩展生成式媒体版图

主持人：你们从图像开始，后来是怎么想到扩展到视频、音频的？或者说你们搭建平台的方式让你们可以自然扩展？讲讲你们决定不断扩展品类的心路历程。

Batuhan： 图像模型最早出现在 2022 年。第一个真正可用的视频模型要到 2024 年中才出现——Sora 年初发了预告，但实际可用的模型大概是 7 月前后。那时候我们已经深入图像领域一段时间了。

视频和图像的客户需求天然衔接：当时的视频模型大多是图生视频，图像就是生成视频的前置步骤。所以一旦模型质量过关，加视频模型进去是很自然的事。我们其实早在客户提出需求之前就有人在问，但我们说，再等等，等模型足够好。

当时也已经有一些视频模型了，但效果其实还不太行。有的模型只能生成 25 帧，也就是大约 1 秒的视频。可如果只能生成 1 秒，实际能做的事情非常有限，甚至都很难把它称作一段视频。

那时候大家会想各种比较极端的办法，比如先生成一个 8 FPS、3 秒钟的视频，再通过插帧把它补到 24 FPS。但本质上，生成出来的内容并没有因此变得更丰富，只是把原来的那些画面补得更流畅而已。

所以我们当时的想法很简单：先等。

等到视频模型真正变得足够好，我们才开始去问之前的客户：「我们现在平台上增加了这个视频模型，你们会用吗？」客户真的开始用了，我们才把这些模型正式加入平台。

2024 年 8 月到 2025 年，视频收入从 Fal 平台收入的 0% 涨到了接近 50%，成为新增收入的重要驱动力。

音频目前占比还比较小，不到 10%。原因是 Fal 并不把音频模型卖给呼叫中心或客服坐席——那些不是我们的客户。我们服务的是创意音频用例，比如把多个视频剪成故事书后配一点背景音。所以不管图像、视频还是音频，我们都在围绕创意和媒体生产这个场景收敛，而不是什么都做。

这和呼叫中心用例完全不同，我们更偏向媒体领域。

开源策略：API 与开源模型并行

主持人：我觉得还有一个特别重要的问题，Fal 的开源策略到底是什么？

Fal 最早围绕 dbt 做的项目就是开源的，所以你们从一开始就在开源生态里。现在进入生成式 AI 之后，你们的平台上又运行了大量开源模型——这显然也是你们能够托管这些模型、做性能优化，再把它们作为服务提供给客户的重要基础。

从更长远的角度看，除了直接使用这些开源模型之外，开源是否是 Fal 建立这家公司、形成长期竞争力的一项核心战略？

Batuhan： 我们非常相信开源。我自己曾经花了四五年时间做开源，给 Python 语言和编译器相关项目贡献。

我们的思路是：哪些部分对用户自己运行东西是有用的？

策略分两方面。一方面，我们消费开源模型——Black Forest Labs、Alibaba 等公司训练并开源了非常好的基础模型，我们把它们作为 API 运行和优化。另一方面，我们有一个五六人的后训练团队，会针对不同用例做微调、蒸馏，让模型跑得更快，并把这些成果也开源发布。

所以 Fal 整体的商业模式其实很简单：如果你需要 API，就直接用 API；但理想情况下，任何能通过 Fal API 使用的能力，也都应该有对应的开源模型可以让你自己运行。

这个模型可以是我们训练的，也可以是其他团队训练的。只要它是开源的、用户能够获取和运行，这就是我们一直坚持的方向。

与此同时，我们也不只是使用开源生态里的东西。我们会持续给自己依赖的开源库贡献代码，一些推理优化也会回馈社区。我们的优化团队和 NVIDIA 合作得非常紧密，会一起把部分优化能力移植到更广泛的生态中。

所以对我们来说，开源不只是「拿开源模型来提供 API」这么简单。它还包括：我们怎样把自己在推理、性能优化上的一部分成果重新贡献回社区。

Fal 推理引擎的核心：不是静态速度，而是持续跟进新模型的能力

主持人：Fal 的推理引擎为什么让用户愿意选择你们？

Batuhan： 平台上线之后，我们最开始听到的一类反馈是：「我们只是把 API 从你们的竞争对手切到 Fal，用户留存率就提高了。」

甚至有一个客户专门做过实验。他们故意把 Fal API 的响应放慢，想看看留存率会发生什么变化。因为我们的价格当时比某个竞争对手稍贵，他们想验证：用户到底愿不愿意为更好的性能支付溢价？

结果证明他们愿意。

所以性能对我们来说一直非常重要。而它背后主要来自两方面：第一是纯粹的性能工程，第二是对模型本身的理解。

任何做机器学习推理的团队，基本都可以从两个方向优化模型。

第一，是完全不改变模型本身，只让同一个模型跑得更快。

你可以保持计算结果不变，只调整计算方式：重新排列计算图、使用速度更快的计算内核、利用 GPU 特性、把不同操作做成流水线等等。模型做的还是同一套计算，只不过执行方式变得更加高效。

我们把这一类称为算法和推理层面的优化，Fal 有一整支团队专门做这件事。

GPU 本身其实是非常复杂的机器，而且每一代架构都有很大的差异。

比如一个简单的矩阵乘法，可能很容易达到 GPU 理论性能的 60%–70%；但如果运行 attention 这样的复杂操作，利用率可能只有 30%–40%。

那么问题就变成了：

怎样把一个只能利用 30%–40% GPU 性能的通用操作，针对具体模型和硬件进行优化，让它提升到 80%–90%？

这就是我们性能工程团队每天在解决的问题，而且每换一代 GPU，这些工作几乎都要重新做。从 A100 到 H100 是一次很大的架构变化，从 H100 再到 Blackwell，变化更大。有些团队可能要花几个月，才能把工作负载从 H100 迁移到 Blackwell，并重新达到原来的性价比水平。

我们希望能够非常快地完成这个过程。

第二，则是直接对模型本身做后训练。

我们有另一支独立的后训练团队，会使用蒸馏、KV Cache 等机器学习技术去优化图像和视频模型。

这时候得到的已经不再是和原模型完全等价的模型。它的行为可能和原模型有 90%、95% 的相似度：有些场景甚至会超过基础模型，有些场景则可能表现得稍差一些。

因为它本质上已经是另一个模型，所以我们会通过不同的 API 提供。

比如同一个图像模型，我们可能会提供一个 Turbo Edition（加速版）。它可能是经过蒸馏的版本，价格更低、速度更快。根据具体用例，你可以选择 Turbo 版，也可以继续使用原始模型。

但如果我们做的是前面那种纯推理优化，原则就完全不同：我们会尽可能忠实于原始模型，不希望优化改变它的输出表现。这也是为什么评测是整个过程中最重要的事情之一。

你必须确定：我做了这么多优化之后，模型输出到底有没有被改变？

这件事不能只依赖简单的数值比较。生成模型本身存在非常大的随机波动，数据噪声也非常高，所以我们搭建了一整套评测体系。

一是数学评测，二是人工偏好评测。

在进行重大优化之前，我们会分别拿到两个结果：一个是优化后模型生成的结果，另一个是使用 PyTorch 运行原始模型得到的结果。

然后把两组结果交给人来判断：「这里有两个输出。我们认为它们应该差不多，但你觉得哪一个更好？」

通过这种方式，我们可以验证优化是否对模型质量产生了影响。对于经过蒸馏等后训练得到的新模型，我们也会进行同样的评测，去理解这些改变究竟带来了什么影响。

所以 Fal 内部实际上有两支团队围绕这件事工作：

一支团队负责在不改变模型行为的前提下，把推理做到更快；另一支团队负责通过后训练，得到更快、更便宜，甚至在特定场景下表现更好的新模型。

还有一个容易被忽略的区别是，我们绝大多数优化都针对服务器级 GPU，比如 A100、H100、B200。

这和大家在消费级硬件上做的优化其实是两个不同的世界。消费级可能是 RTX 5090、4090 这样的游戏显卡，或者 MacBook 上的 M4 芯片；而我们关注的是数据中心里的服务器级芯片，以及这些硬件在大规模模型推理时的性能。

现在实际上正在形成两个不同的优化生态，而 Fal 基本只专注服务器级芯片这一边。

客户服务方式的变化：从自助到解决方案工程

主持人： 我觉得很有意思的一点是，Fal 所处的市场其实和 Together、Fireworks，以及 Baseten、Modal 这类公司不太一样，对吧？

因为大家其实都在做类似的事情：写定制计算内核、做模型推理优化。但我的感觉是，Fal 的客户范围可能非常广，而真正贡献大量收入的，往往只是其中相对少的一部分客户。

对于这些大客户，你们显然不能只是把内核优化好就结束了，还需要确保他们的具体需求真正被满足。

我看到很多基础设施公司做到这个阶段后，工程师都会直接和客户坐下来，一起做类似解决方案工程的工作：理解他们具体在做什么、瓶颈在哪里，然后决定究竟应该优化模型、优化推理系统，还是做其他定制工作。

所以我很好奇，Fal 是怎么决定工程资源该投入到哪里的？

因为处在模型和应用之间这一层，可以做的事情其实非常多。面对这么大的优化空间，你们怎么判断：哪些问题值得做，哪些不值得做，又优先为哪些客户做？

Batuhan： 这件事其实挺有意思。我们最早的一批客户基本都是 AI Native 公司，很多也是和我们一样的创业公司。

他们通常非常清楚自己要什么：知道该用哪个模型，也知道具体要什么配置。他们需要 Fal 做的，更多是把模型运行得更稳定、更容易扩展、更快，同时把成本降下来。

所以最初这些客户其实并不太需要我们帮他们选模型，也不需要太多针对具体用例的咨询，但随着我们开始进入企业市场，情况慢慢发生了变化。

有些企业客户此前甚至从来没有用过图像模型。他们第一次打开 Fal，会直接问我们：「你们平台上有 100 个模型，我到底该用哪一个？」

这时候我们就必须先问：你的具体用例是什么？比如客户想做虚拟试衣：输入一张真人照片，再输入一件衣服，希望模型生成穿上这件衣服后的效果。

那我们可以给他推荐几个适合虚拟试衣的模型。

但问题马上又来了：「你说这是最好的模型，所谓『最好』到底指什么？」

有的模型可以做到非常高的像素级还原，对原图和衣服都很忠实，但速度比较慢；有的模型速度快很多，更适合快速生成草稿；还有一些模型会加入更多生成式处理，让衣服和人物融合得更自然，但也因此不会完全忠于输入图像。

所以你很难脱离具体业务，单独说哪个模型「最好」。

归根到底，最后还是要看客户自己的 Benchmark。

这也是那些真正拥有终端用户的公司非常有价值的一点：他们有真实用户在消费这些模型生成的内容，也就有自己的业务数据和指标体系。

很多 Fal 客户的评测体系其实做得非常完善，他们可能会直接跟我们说：「给我三个模型，我们自己跑 A/B 测试。」然后分别观察哪个模型的用户反馈更好、哪个模型带来的转化率更高。最终，他们通常就是通过这种方式决定该使用哪个模型，而不是单纯看一个公开排行榜或者某个统一的模型分数。

再往企业级走一步，我们还会提供更深的服务。

Fal 有一支 Creative Engineering（创意工程）团队，会直接和客户合作，为他们做定制模型的后训练。

我们会从客户自己的业务场景中收集数据，然后基于这些数据训练或微调模型，让它更适合这个客户具体的使用场景。

所以到了这个阶段，我们关心的问题就不再只是：「哪个现成模型最好？」

而是：「你真正关心的业务指标是什么？我们怎样和你一起，把模型在这个指标上的表现做到最高？」

这就是我们服务企业客户时最核心的方式，而且 Fal 做这件事非常深入。我们和客户之间已经有数千个 Slack 频道，工程师会直接待在这些频道里，客户遇到问题可以直接和工程师交流。我们的工程团队并不是只在后台优化模型和基础设施，很多时候他们也会直接参与客户的实际使用过程。

定制模型不会因为基础模型越来越强就消失

主持人：Fal 有没有想过自己训练模型？你们会一直是市场平台吗？

Batuhan： 生态里确实有这个争论，比如 Cursor、Intercom 都在训练自己的模型。但 Fal 同时服务模型供应商和终端客户，所以我们更希望自己处在一个中立的位置。

如果你是模型提供商，我们帮你把自己的模型部署、运行起来；如果你是应用客户，想使用某个开源模型，我们也帮你把它跑起来。

我们目前不看好自己预训练模型，我们更擅长在开源基座模型上做后训练，并把这些成果开源。

过去 12 个月，Fal 平台上单一最大模型贡献的收入不到 10%。模型碎片化非常严重，平均生命周期也很短。即使模型越来越小、训练效率越来越高，训练一个模型仍然要投入很多。而且因为模型的生命周期并不长，你基本上被困在必须不断、快速、高强度地产出越来越好的模型里。

主持人：这也引出了另一个问题。你刚才提到，Fal 会帮一些客户做定制模型，但与此同时，市场上每天又有大量新模型不断出现。

所以当客户面临选择时，你们会怎么帮他判断：在模型更新这么快的市场里，什么时候值得做定制模型，什么时候应该等下一代开源模型。

Bacuhan： 一般来说，市场上发布的新模型都是面向通用场景的基础模型。但我们帮客户训练定制模型时，针对的通常是非常具体、非常垂直的用例。

这个范围可以窄到什么程度？从「图像编辑」缩小到「虚拟试衣」已经很具体了，但还可以继续缩小到比如：专门做睡衣的虚拟试衣。

我们通常只会在客户拥有大量专有数据的情况下做这种定制。

比如一家企业过去很多年一直在用 Photoshop 处理图片，或者长期用真人进行拍摄，已经积累了大量真实业务数据。这些数据可能是它过去 10 年、20 年一点点沉淀下来的，而训练通用模型的公司根本接触不到。

这时候，定制模型的价值就体现出来了。你可以拿一个开源基础模型，在它上面用这些专有数据进行微调。这样，模型一方面保留了基础模型原本已经学到的通用能力，另一方面又能获得客户自己数据里的特定知识和上下文。

所以我认为，定制模型这件事不会因为基础模型越来越强就消失。

真正会不断变化的，只是底下使用的是哪个基础模型。如果下个月出现了一个更好的基础模型，那就把新的模型换进来。整个定制和后训练流程并不需要推倒重来，你仍然可以继续使用自己积累的那套专有数据。

基础模型可以不断替换，但客户过去多年积累的数据不会消失，这才是定制模型最大的价值。

今天生成式媒体领域最大的技术难题：扩展媒体模型与算力紧缺

主持人：今天生成式媒体领域以及 Fal 面临的最难的技术问题是什么吗？

Batuhan： 最大的问题还是扩展媒体模型。图像模型已经比较接近「难以分辨真假」，大概 95–96% 的水平。但视频还远没有到这个程度，不知道你们有没有在 Twitter 上看到 Seedance 2，当时非常火，现在也不断有新的视频模型出来。但整体来看，视频模型距离语言模型今天的成熟度还差得很远，而且视频本身又是非常计算密集的模型。

我一直觉得这里存在一个不匹配。

如果看 AI 出现之前整个媒体产业的规模——电影、广告、短视频、游戏、视觉内容，这本来就是一个极其庞大的市场。但今天投入到视频模型训练上的资金，与这个市场本身的重要性并不成比例。

其中一个原因很简单：训练视频模型太贵了。

不过情况在改变，每三个月左右都能看到一次阶跃式提升。

好消息是视频数据几乎是无限的。文本数据有限，但你可以拿相机出去无限拍摄。数据侧没问题，关键还是算力。

对 Fal 来说，另一个大问题是算力紧缺又回到了 2023 年的状态。而且这一次不只是 Google、AWS、Microsoft 这样的超大规模云厂商缺算力，而是几乎所有云计算公司都在缺。你看看 Claude Code、Codex 这些产品，每天都在生成海量 token，这些 token 最后都要跑在某块芯片上。

如果 Anthropic 想把收入从 20 亿美元做到 200 亿美元年化收入，它需要什么？需要更多算力。

这也是为什么过去几个月，我们一直在研究更多硬件选择。比如能不能更多使用 AMD GPU，能不能使用 Google TPU，能不能使用 AWS Trainium。

目的都一样：想办法获得更多可用算力。

我们当然还是会尽可能使用 NVIDIA，但问题是，现在如果你突然需要几千块 NVIDIA GPU，并不是今天下单明天就能拿到。很多时候要提前三个月、甚至六个月预订。

所以如果你今天就需要新增算力，就必须开始考虑 NVIDIA 之外的硬件。

这也是 Fal 现在非常重要的一项工作：让我们的推理系统能够运行在更多不同的芯片上，从而继续扩大算力容量，服务更多客户。

给创始人的建议：精简的团队、关心你的客户、好的产品

主持人：最后，你会给其他进入这个领域的创始人什么建议？

Batuhan： 从赛道本身来看，这是我这辈子见过增长速度最快的领域，真的非常疯狂。

如果要给创业者一些建议，我觉得第一点是：尽可能保持团队精简。

现在可以看到人均 500–600 万美元收入的公司，这在以前很难想象。小团队执行更快，也给了你更多回旋余地。我们能这么容易转型，很大程度上因为当时只有 6 个人。我们没有提前招很多人、把组织做得很重，所以当市场发生变化时，可以很快掉头。

这次转型后来几乎改变了整家公司。

第二，真正关心你的客户。

我觉得今天最重要的资产就是客户，以及你和客户之间建立起来的关系。技术会被追上，模型会不断更新，很多东西都很难形成永久的壁垒。但客户关系仍然是最难被复制的东西之一，所以要非常认真地服务客户。

第三，产品、产品、产品。这极其重要。

主持人： 太好了。感觉我们快速回顾了一家疯狂公司的旅程，也回顾了你个人的旅程。非常感谢你加入我们。

Batuhan： 这太棒了，谢谢你们邀请。

参考与来源

fal直播现场：https://fal.live/
Fal's Bet on Generative Media 播客来源：
https://ossstartuppodcast.substack.com/p/episode-194-fals-bet-on-generative
Fal 官方博客 Introducing H3 Max by fal:
https://blog.fal.ai/introducing-h3-max-by-fal

编译：@三水、@鲍勃

彩蛋：基于 H3 Max 和 Suno，Batuhan 制作的个人形象演唱视频。