微調瓶頸並非算法問題

微調瓶頸並非算法問題

DeepSeek V4 Pro 已上線 → 立即嘗試。

博客

微調瓶頸

微調瓶頸並非算法問題

發佈時間：2026年3月28日

目錄

最終目標始終是智能體

反覆出現的瓶頸

集成與數據主權

迭代速度

為任務選擇合適的工具

從託管到完全控制的階梯

未來方向

立即開始微調

團隊往往追逐最新的訓練算法，但真正的瓶頸是集成、迭代速度，以及何時使用SFT、RFT或DPO。

TL;DR：集成摩擦和緩慢的迭代週期才是真正阻礙微調的瓶頸，而非算法。我們分享了在多個項目中觀察到的模式，例如Cursor和Genspark等團隊如何突破這些瓶頸，以及工作流的未來趨勢：完全自主的微調循環，可自動閉環。

大多數尋求微調幫助的團隊並非在訓練算法上遇到困難。他們面臨的是圍繞算法的一切：如何讓獎勵函數與內部API通信而不泄露數據；每次實驗需等待數天，因為每個步驟都分散在不同工具中；以及判斷問題是否適合使用SFT、RFT或DPO。過去一年中，與一批最具創新性的初創公司、數字原生企業和財富500強公司合作，我們在每個項目中都看到了這些重複模式。

最終目標始終是智能體

每個尋求微調幫助的團隊都在構建特定領域的智能體。代碼修復、客户支持、深度研究、金融操作——用例不同，但形式相同。通用前沿模型遇到質量天花板，前進的道路是模型級定製。

這個天花板是具體的。Genspark的深度研究智能體在封閉前沿模型上得分僅為0.76。他們通過Fireworks轉向基於開放模型的RFT，得分超過0.82——這一跳躍是提示工程無法單獨實現的。我們合作的一家大型數字原生企業，在使用RFT微調後，任務質量提升30%，延遲降低2.5倍。提示工程只能帶你走到一定程度，要達到新的能力層級，需要微調。

在一個單一賬户中，我們看到了從升級檢測到獎勵建模再到AI驅動的搜索等用例——全部同時運行。這種廣度説明微調是構建智能體系統的持續基礎設施，而非一次性操作。

智能體之旅

每個團隊都遵循相同的軌跡：通用模型達到質量天花板，微調縮小差距，最終結果是生產中的特定領域智能體。

反覆出現的瓶頸

在這些項目中——不同行業、模型規模、用例——相同的問題反覆出現。有趣的是，這些問題都不涉及訓練算法本身，而是圍繞算法的所有方面。

集成與數據主權

最常見的障礙是集成。獎勵函數、內部評分器和評估API必須保持在客户環境中。敏感業務邏輯和專有數據不能離開用於第三方評分。

Fireworks在兩個層面解決這個問題。對於需要完全數據隔離的團隊，Training API允許你在數據永不離開環境的情況下運行訓練循環——你控制Python進程，數據保留在你這邊，只有權重更新通過平台流動。對於託管微調，安全的自帶存儲桶存儲和遠程環境確保評估器在客户VPC內執行。

一個團隊因合規要求被限制使用特定的非中文開源模型。模型可用性和地緣政治需求與訓練算法一樣影響微調工作流。平台必須支持廣泛的基礎模型。

數據主權架構

獎勵函數、評分器和訓練數據保留在客户環境中。訓練平台安全連接，數據不離開VPC。

迭代速度

訓練任務很少是瓶頸。週期時間才是。團隊花費數週設置訓練基礎設施，整理嘈雜數據集，運行一次作業，然後通過離線評估發現模型在質量上仍不達標。等到他們迭代數據、調整超參數並重新訓練，又過去一週。實際GPU時間只是總週期的一小部分。

速度最快的團隊已將該差距從數週縮短到數小時。高頻作業提交、快速反饋改進內容、實驗間最少手動設置。一個團隊在數週內運行了超過100個作業。另一個團隊提交了數十個RFT作業，幾乎連續迭代。這些節奏看起來更像是CI流水線而非ML實驗。我們與Cursor在Composer 2上的合作是最清晰的例子——Fireworks為分佈式RL訓練基礎設施提供支持，幫助Composer 2在編碼基準測試中超越頂級前沿封閉源模型，得益於緊密的推理-訓練循環，每約5小時即可交付新檢查點。

將微調和部署放在同一平台是實現這一點的關鍵。訓練好的LoRA適配器在幾分鐘內部署——無需模型導出，無需單獨的服務棧。eval-protocol CLI針對實時部署運行評估。成本估算器讓團隊在投入GPU時間前規劃迭代預算。

這裏還有一個隱藏的倍增器：超參數優化。訓練/測試分離紀律、網格搜索和學習率調整對最終模型質量仍有巨大影響。大多數構建智能體的產品團隊沒有專門的ML工程師來正確執行此操作，而草率的實驗設置是微調“不起作用”的主要原因之一。我們認為這是工具最有改進空間的領域之一——想象一個系統，它觀察跨運行的評價指標並自動調整訓練配置，而不是需要ML專家照顧每個實驗。我們正在構建這一點，它比您想象的更近。

迭代速度

成功交付與停滯不前的團隊之間的區別：將評估-訓練-部署週期從數天的分散工具縮短為以小時計量的緊密循環。

為任務選擇合適的工具

迭代最快的團隊不再將微調視為單一技術。在一個單一賬户中，我們經常看到SFT、RFT和DPO同時用於同一產品——每種方法針對問題的不同部分。

方法選擇遵循問題，而非相反。當你有高質量演示數據和定義明確的輸出格式時使用SFT——蒸餾、結構化提取、風格遷移。當獎勵信號比正確答案更清晰時使用RFT——智能體任務、工具使用、任何正確性難以標記但容易評估的情況（RFT的工作原理）。當你擁有強偏好對並希望在沒有編寫獎勵函數的情況下對齊行為時使用DPO。

真正的力量在於組合使用。我們常見的一種模式：從SFT開始，從演示數據中蒸餾出強基線，然後切換到RFT以推高SFT無法單獨捕獲的智能體行為質量。平台使這變得簡單。使用eval-protocol，你可以通過--warm-start-from直接從之前的SFT適配器熱啓動RFT運行，因此微調後的PEFT檢查點成為強化訓練的起點，無需手動導出。為了實現更深層次的控制，Training API允許你跨作業邊界加載先前訓練作業的檢查點——SFT運行流入RFT運行，並保留完整的優化器狀態。

模型選擇也是搜索空間的一部分。我們看到團隊同時進行多種規模的實驗——低於1B用於快速迭代，200B以上MoE用於生產質量，有時在同一周內兩者兼用。平台必須使方法和模型之間的切換無摩擦。我們還支持多模態用例的視覺微調。

從託管到完全控制的階梯

存在一致的成熟度模式。團隊幾乎總是從託管微調開始——通過API進行SFT、DPO或RFT。這是正確的起點。它將基礎設施從關鍵路徑中移除，並驗證微調是否適用於該問題。

然後他們遇到天花板。深度領域適應，特別是在大型MoE架構上，需要更多控制：自定義損失函數、自定義數據管道、優化器步長訪問、LoRA無法達到的全參數更新。託管達到80%的需要剩餘20%的差距正是團隊要麼停滯要麼從頭重建堆棧的地方。

Training API彌合了這一差距。相同的基礎設施，相同的部署目標，但你可以帶來自己的訓練循環。自定義GRPO、DAPO或混合目標。對高達200B+模型的全面參數更新。使用實時服務檢查點的推理內循環評估。無需部署GPU集羣。快速入門讓你在幾分鐘內運行。

從最高抽象層開始，當需要時降低到更細粒度。關鍵在於過渡是無縫的——你不應為了獲得更多控制而重新平台化。

選擇你的控制級別

從完全託管的微調作業到菜譜式SFT/DPO/GRPO工作流，再到自定義Python訓練循環。同一平台在每個級別。

未來方向

行業正從手動ML實驗轉向CI/CD風格的微調循環——其邏輯終點是自我運行的循環。

我們描述的每個瓶頸都是一個不需要手動的手動步驟。集成不應需要數週的自定義連接器工作——訓練平台應原生接入客户的評估基礎設施。迭代不應因人類決定何時重新訓練而停滯——平台應觀察評估指標，檢測迴歸，並自動開始訓練運行。超參數調整不應每次都需要ML專家——系統應觀察數千個先前運行的經驗，並推薦可能收斂的配置。

將這些結合起來，你得到一個本身就是智能體的微調工作流。

評估到重新訓練的循環自動關閉。系統觀察模型在生產中出錯的地方，選擇合適的訓練方法，配置運行，對保留數據驗證結果，並在質量提升時部署。人類定義什麼是好的並設置防護欄。系統完成其餘工作。

與我們合作的團隊已經手動拼接這些循環的片段——編寫腳本監控評估儀表板、觸發重新訓練並控制部署。我們正在構建使該循環成為一等原語的基礎設施。更多細節即將發佈。

智能微調

未來狀態：評估到重新訓練的循環自動關閉。人類設定目標和防護欄；系統處理觀察、訓練、驗證和部署。

立即開始微調

如果其中任何內容聽起來熟悉，你現在就可以開始。

• 託管微調 ——通過API進行SFT、DPO和RFT。16B以下模型可免費微調。從微調概述開始。

• 需要更多控制？ ——對於自定義訓練循環、全參數更新和推理內循環評估，請聯繫我們瞭解更多關於訓練產品的信息。

我們正在致力於自動超參數優化、評估驅動重新訓練以及端到端閉環的智能微調工作流。如果你想提前試用或討論你的微調架構，請通過我們的聯繫頁面或Discord聯繫我們。