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 Cache（KV 快取）管理，以免長提示耗盡記憶體，以及在品質代價可忽略時，選擇性量化成 FP8 等格式。公司經常強調精確度，認為有些供應商悄悄提供高度量化的檢查點版本，是以輸出品質交換速度，而 Fireworks 通常預設採用較高精確度格式。對應用程式開發者而言，真正關鍵的數字是首個 token 所需時間——聊天規模的提示通常只需數百毫秒——以及穩態解碼速度；視模型規模而定，後者從每秒數十至數百個 token 不等。正是這兩項數字，決定串流聊天介面與多步驟代理的回應感覺流暢，還是像卡住一樣。
同一套權重，不同的服務
一項常見誤解是，既然推論供應商提供相同的開放檢查點，它們就能彼此替換——不論向哪一家租用，Llama 都是同一個 Llama。實際上，檢查點只是起點：真正提供的數值精確度、負載下的批次處理行為、實際啟用的上下文長度，以及資料中心與使用者間的距離，都會改變應用程式體驗。兩家供應商的報價即使接近，每 token 延遲、輸出品質與函式呼叫可靠性仍可能有明顯差異。因此，實務工作者會用自己的提示測試供應商，而非只看牌價：以長提示為主的工作負載考驗提示擷取，頻繁來回對話的工作負載則考驗穩態解碼。在這類比較測試中，Fireworks 最常遇到的對手是 Together AI；OpenRouter 等彙整商則位於更上一層，同時在多家供應商間進行路由。
複合 AI 與 f1 的押注
Fireworks 更大的戰略主張，是實際應用程式都是複合 AI 系統：一項使用者請求會分支成檢索、呼叫便宜快速的模型處理簡單步驟、呼叫強大模型處理困難步驟，邊緣處還可能接上圖像或音訊模型。若正式環境 AI 真是這種形態，那麼一個透過同一套 API 託管多類模型，再以函式呼叫與結構化輸出將它們串接起來的平台，就比平台上的任何單一模型更有價值。公司透過 f1 明確押注這條路線；這是它在推動複合 AI 時預覽的一款推理模型，會在推論階段為困難問題投入更多運算。無論 f1 本身能否成為旗艦，這個方向都與整個業界一致：推理模型與代理迴圈，會讓每次使用者操作所觸發的推論呼叫成倍增加；對任何銷售高速推論的公司來說，這都是好消息。