Fireworks AI简介
挑战与解决方案
- 极致吞吐量： 在异构多云环境中，实现了1TB/s+ 的总聚合模型部署吞吐量。
- 快速冷启动： 将 750GB 模型的加载时间缩短至约一分钟；整体副本启动时间从数小时降至 1-3 分钟。
- “一次下载，随处复用”： Alluxio 可以编排每个集群内的single-fetch机制，从模型仓库只需拉取一次模型，即可以网络带宽上限速度提供给所有并发的 GPU 使用。
- 透明的 Kubernetes 集成： 原生部署于 Kubernetes环境，无需修改应用层代码或工作流。
- 削减 50% 数据出口（egress）成本： 通过下线在每个区域搭建的临时存储并消除跨区域的重复数据传输来实现。
- 经实践验证的可扩展性： 每天稳定承载约 2PB 的数据服务量，在生产峰值爆发期间仍保持90-100%的缓存命中率。
大规模的模型冷启动
Fireworks 构建了一个高度分布式的推理平台，该平台基于计算与存储分离的架构。模型权重存储在 Google 云存储（GCS）和其他 S3 兼容的对象存储中，而推理任务则在跨多个云平台和区域的 GPU 集群上运行。
随着平台规模扩展，模型冷启动成为了关键瓶颈。
Fireworks AI会定期部署规模从 70GB 到超过 1TB（如 Kimi）的大模型，每次部署通常涉及 10 到 100 多个副本。例如在新模型推出、自动扩展或集群重启时，数百台GPU服务器会在单个集群内同时尝试下载相同模型文件。在此规模下，真正的制约因素并非GPU或集群内的网络容量，而是来自对象存储的带宽和速率限制。这会产生高度突发、同步化的流量模式，给对象存储的带宽带来极大压力。
在 Fireworks AI 采用 Alluxio 之前的架构中，模型分发主要依赖于自定义的pipeline，从而实现：
- 从主对象存储（GCS）下载模型
- 将模型复制到更靠近推理的区域对象存储中
- 在 GPU 服务器上使用基础的节点级缓存
该方案在小规模环境下尚可运行，但随着业务增长便难以支撑。
技术挑战
- 高并发模型加载：Fireworks AI 面临着在数十个 GPU 云平台中同时下载相同、热门大模型的高峰负载与并发挑战。模型的单次部署可能包含 10 至100多个副本，每个副本都需要完整复制模型文件。数百台 GPU 服务器在单个集群内同时下载相同文件（单个文件大小为 70GB 至 1TB），会产生巨大的带宽需求并造成 IO 瓶颈。
- 冷启动延迟严重： 缓慢的下载速度导致初始模型部署的延迟很高。副本的启动时间受限于 inbound 网络带宽，而这一带宽在不同云提供商之间差异很大，通常远低于集群内部带宽。将大模型下载到 200 多个 GPU 节点可能需要 20 分钟以上，在某些情况下，由于 GCS 限流，甚至可能超过一小时。
- 手动 pipeline 管理：同步多个同时启动的副本、配置和管理区域性对象存储缓存，以及手动协调整体的初始化等操作，这些操作会带来了巨大的运维开销和人力消耗。
- 可扩展性问题：随着业务的超高速增长，Fireworks AI 意识到需要配备专职工程师来监控模型分发 pipeline，以确保其可靠性。
业务挑战
- 客户体验影响：缓慢且不稳定的冷启动是客户面临的关键业务痛点。尽管模型加载速度提升对营收的影响难以量化，但优化后的用户体验能有效提升客户留存率、ARR 续订、PoC 转化率及整体品牌声誉。
- 数据出口成本负担：Fireworks AI 每年需支付数万美元的 GCS 数据出口费用，其中区域对象存储和主 GCS 存储都会产生显著成本。
- 工程资源浪费：GCS 速率限制导致工程师每周需耗费数小时来专门操作整个模型加载，浪费了宝贵的工程时间。
Alluxio 解决方案成果
| 指标 | 采用Alluxio前 | 采用Alluxio后 |
| 模型加载时长 | 20+ 分钟，因存储限流可能超过1小时 | 800GB+ 模型（ 100+ 副本并行加载），每个副本需 2-3 分钟；750GB 模型（在理想条件下）仅需约 1 分钟 |
| 缓存命中率 | 不适用 | 90-100% |
| 集群总吞吐量 | 受限于inbound网络带宽和对象存储 | 800 GB/s – 1 TB/s+ |
| 单副本吞吐量 | 受限于inbound网络带宽和对象存储速率限制；加载 800GB 模型需要 20 分钟 | 平均 8-10 GB/s，峰值可达 14 GB/s |
| 多云数据出口成本 | 来自主 GCS 和区域暂存桶的高额费用 | 通过去重和淘汰暂存层，降低 了50% 的出口成本 |
| 冷启动带来的影响 | GPU 频繁处于闲置状态 | GPU 频繁处于闲置状态的情况基本消除 |
以下是 Fireworks 提供的性能结果：
图 1：模型加载期间的读吞吐量
图 3：集群利用率 – Fireworks AI 的单个集群的存储利用率
图 4：一天内的总读取字节数，约 2 PB 数据
业务影响
- 工程开销降低：每周减少超过 4 小时的手动 pipeline 管理时间；
- 成本节省：数据出口成本减少约 50%，带来每年数万美元的节省；
- 客户体验优化：更快速、可靠的模型加载可带来显著的用户体验提升；
- 可扩展性增强：Alluxio 可随着 Fireworks AI 的业务高速增长进行线性扩展，无需额外工程资源支持。
大规模分发模型权重的经验
Alluxio 在 Fireworks AI的规模化运营表明，要在生产环境中实现 TB/s 级别的吞吐量，并非简单添加分布式缓存即可。随着模型权重规模增长至数百 GB 甚至 TB 级别，部署范围扩展到数十个 GPU 集群，实际性能受到缓存预热行为、冷读路径以及高度同步的突发流量等因素的影响。通过与 Alluxio 密切合作，Fireworks 识别并解决了几个生产环境特有的瓶颈问题，从而显著提高了业务可靠性和性能表现。
大模型的高效缓存预热
Fireworks 工程师通常在部署前将模型权重预加载到 Alluxio 中，以避免数据冷读。然而，当单个模型文件达到数十或数百 GB 时，即便原始带宽充足，缓存预热速度仍低于预期。
调查后发现，缓存预热过程（在 Alluxio 中提交加载作业）被重构为每个文件划分成多个小分区（8MB），这是针对数据湖的优化。通过将预热过程调整为处理更大的分区（256MB），我们能够显著降低Alluxio 分布式作业执行中的调度和协调开销，并将预热速度提升约 20 倍，这使得在部署过程中，从而在部署过程中实现大型模型在GPU副本间的高效加载与复用。
关键洞见： 当文件规模超过特定阈值时，缓存预热性能将主要受分块策略与预取策略影响。
在缓存未命中时进行积极预取
即使进行预热，由于缓存淘汰、新模型检索和集群变动，生产环境中仍不可避免会出现冷读。针对超大文件的默认冷读行为会引入不必要的启动延迟。在 Fireworks AI，我们启用了积极的异步预取机制，使得对大模型文件的首次读取会立即触发对整个文件的后台获取。这样冷读性能提升了约 5 倍，显著降低了模型启动时的尾部延迟，并减轻了缓存未命中的影响。
关键洞见： 对于大型、不可变的模型权重，将首次读取视为预取整个文件的信号，能极大地改善启动延迟和用户体验。
消除高突发性同步工作负载的隐藏并发限制
在大模型部署或自动扩展等事件期间，数百个 GPU 副本会尝试同时加载同一模型。在极端并发情况下，部分 Alluxio Worker 开始拒绝请求，导致缓存未命中并随后fallback到远程模型仓库。虽然这不会阻塞或导致 GPU 应用程序出错，但会降低其速度并产生数据出口成本。
于是，我们调整了 Worker 端的并发处理机制，通过微小队列延迟换取显著提升的吞吐量与稳定性，从而更好地吸收突发流量。远程存储fallback现象基本消除，即使在并发量激增时，Alluxio Worker 节点仍能保持响应能力。
关键洞见： 在 AI 基础设施中，最危险的负载并非稳态的负载，而是那些考验协调机制与并发极限的同步突发事件。
持续高性能是一种运维准则
随着Fireworks AI扩展其多云GPU集群，性能调优不能仅是一次性操作。Alluxio被视为核心生产基础设施，并完全集成到Fireworks AI基于Kubernetes的CI/CD管道中，实现了跨集群的统一配置、部署和调优。性能提升能在全球范围内可靠实施，而无需专门的运维监督。
关键洞见： 在此规模下，持续高性能是系统的一种运维准则，而非一次性优化。
