Fireworks AI
为什么重要
深度解析
Fireworks AI 占据了开放模型发布与上层产品之间的那一层软件栈：它出售推理即服务，也就是高速推理。公司由 Meta PyTorch 团队的工程师于 2022 年创立，押注未来很大一部分生产级 AI 会运行在开放权重检查点上，而不是闭源 API 上；在这个世界里，团队需要的不是另一个模型，而是一种高速、可靠到无聊的既有模型运行方式。平台用兼容 OpenAI 的端点托管热门开放发布——Llama、DeepSeek、Qwen、Mistral 的模型，再加上图像生成器、语音转录和嵌入模型——底层由自定义服务栈支撑，招牌是 FireAttention kernel。围绕核心服务，公司也补齐了生产团队会要的东西：微调、函数调用、结构化输出，以及一套被它称为复合 AI 的多模型流水线路线。
无服务器与专用部署
Fireworks 主要以两种形态销售Model Serving。无服务器档完全按 token 付费：调用 API，与其他租户共享 GPU 容量，只为实际生成内容买单，因此天然适合原型、尖峰流量和模型横向比较。专用档则把一部分 GPU 容量只留给你的工作负载；流量稳定后，它能换来更可预测的尾延迟和更好的单位经济性——就像云计算中预留实例与按需实例的取舍。实际工作中，团队通常先从无服务器开始，测出真实用量，再把一两个重度模型移到专用部署，长尾部分继续留在无服务器上。
微调遵循同样的模式。监督微调通过平台完成，LoRA 适配器则在共享的基础模型容量上提供服务，因此每个微调变体都不需要自己常驻一个部署。最后一点比听起来更重要：它把同一个模型大量专用变体的服务成本，大致压缩到只运行基础模型的成本，这才让按客户或按功能做微调在经济上说得通。
速度从哪里来
推理供应商的产品几乎就是它的服务栈，而 Fireworks 的服务栈围绕 FireAttention 构建。这套自定义注意力实现，超出了 vLLM 等开放服务框架开箱即用的范围。性能增益来自一袋熟悉的技巧，只是执行得足够好：针对每代硬件调优的融合 GPU kernel、让硬件在大量并发请求下始终吃满的连续批处理、精细的KV缓存管理，避免长提示词撑爆内存，以及在质量代价可以忽略时，选择性量化到 FP8 等格式。公司很爱谈精度，认为有些供应商悄悄提供高度量化的检查点版本，是在拿输出质量换速度，而 Fireworks 通常默认使用更高精度格式。对应用开发者来说，真正关键的数字是首 token 时间——聊天规模的提示词通常只需几百毫秒——以及稳态解码速度；根据模型大小，后者从每秒几十到几百 token 不等。正是这两个数字，决定流式聊天界面和多步智能体响应起来像不像卡住。
同一套权重，不同的服务
一个常见误区是，既然推理供应商提供的是同一份开放检查点，那它们就可以互换——无论去哪里租，Llama 都是同一个 Llama。实际上，检查点只是起点：真正提供的数值精度、负载下的批处理行为、实际启用的上下文长度，以及数据中心与用户的距离，都会改变应用体验。两家供应商即便报价相近，每 token 延迟、输出质量和函数调用可靠性仍可能相差明显。这就是为什么实践者会拿自己的提示词测试供应商，而不是只看标价：长提示词为主的工作负载考验提示词摄入，来回对话很多的工作负载则考验稳态解码。在这类对比测试中，Fireworks 最常遇到的对手是 Together AI；OpenRouter 等聚合器则位于更上一层，同时在许多供应商之间路由。
复合 AI 与 f1 的押注
Fireworks 更大的战略主张是，真实应用都是复合 AI 系统：一次用户请求会分叉成检索、调用便宜快速的模型处理简单步骤、调用强模型处理困难步骤，边缘处也许还会接上图像或音频模型。如果生产 AI 真长这个样子，那么一个用同一 API 托管多类模型、再以函数调用和结构化输出把它们串起来的平台，就比平台上的任何单一模型都更值钱。公司用 f1 明确亮出这条路线；这是它在复合 AI 推进中预览的一款推理模型，会在推理时为困难问题投入更多计算。f1 本身能不能成为旗舰尚且不论，这个方向与整个行业一致：推理模型和智能体循环会让每次用户操作触发的推理调用成倍增加，对任何销售高速推理的公司来说，这都是好消息。