微調瓶頸並非演算法問題

微調瓶頸並非演算法問題

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聯絡我們。