模型遷移過程

本文描述了一個六階段的流程，將一個由 LLM 驅動的工作負載從一個基礎模型遷移到另一個模型：每個階段應考慮的事項、哪些 Microsoft Foundry 功能適用，以及不同團隊的工作內容如何改變。

模型遷移的意義

你生產的每個模型都有退役日期。 當你依賴的模型被替換，或是新模型能更好地滿足你的工作負載時，你就會遷移。 更換模型不是一句話的改變：不同的模型可以悄悄改變語氣、格式、JSON 形狀、延遲、成本或工具呼叫行為，並破壞依賴舊行為的下游程式碼。

成功的遷移能保留應用程式的行為，或以可衡量的方式改善它。 成功需要一個可重複的流程，以偵測漂移、安全適應，並在廣泛推廣前證明品質。

何時遷移

遷移通常由以下四個原因之一開始：

  • 一位模特兒即將退休。 在 Foundry 上，每個正式發行的模型都會訂有淘汰日期，而較舊的系列也會逐步由新系列取代。 有關退休政策及日期，請參閱 Foundry 模型生命週期與支援政策 及 模型退休時程。
  • 有更好的型號可用。 較新的型號提供更高品質、更低成本、更佳的延遲，或具備你工作負載所需的功能（例如結構化輸出或改良的工具呼叫）。
  • 成本或延遲問題迫使改變。 目前型號的延遲或單價已無法滿足你的需求。
  • 能力缺口阻礙了產品發展。 目前的型號無法做到你產品現在所需的功能。

退休當天會發生什麼事

Azure 在模型退役時會怎麼做，取決於你如何購買容量，而 Foundry 對每條路徑使用不同的術語：

  • 標準版、全球標準版和資料區標準版 (隨用隨付) 部署會依各區域輪流排程自動升級。 您可以將 versionUpgradeOption 設為下列其中之一來控制時機：OnceNewDefaultVersionAvailable、OnceCurrentVersionExpired 或 NoAutoUpgrade (這表示部署會在淘汰時停止運作)。 優先處理（Priority Processing）也遵循相同的路徑。
  • 佈建式 (PTU) 部署不會自動升級。 你可以自行遷移它們，可採用 就地 遷移（流量會在 20–30 分鐘的時間窗口內切換，且無停機時間）或 並行 遷移（建立新的部署、測試、切換流量，然後刪除舊的部署）。
  • 批次部署會遵循並行路徑：部署新模型、重新提交作業，並淘汰舊部署。

無論採用哪種路徑，開發者的挑戰都是一樣的：在特定日期，你的流量會開始流向不同的模式。 端點仍然有回應，並不代表你的應用程式仍然正常運作，因此無論是自動升級或手動遷移的工作負載，都能從本文描述的評估與驗證中受益。

退休日前遷移

自動升級只是隨用隨付部署的安全網，並非遷移計畫。 配置式部署沒有安全網。 無論如何，它不能取代移民計畫。 有兩項政策承諾讓您有空間依照自己的時間表遷移，而不必等待截止日期：

  • 替代模型在 Global Standard 中，約於退役前 90 天 可供使用；而在前一代模型即將退役的已佈建區域中，則約於退役前 30 天 可供使用。 利用此視窗評估新模型並手動遷移。
  • 退休日期 不可延長。 沒有例外程序，所以你沒計畫的日期仍然適用。

您不需要取代通知就能開始。 如果較新的模型更便宜、更快或能力更強，現在就讓它執行一次這個流程。 遷移會刻意讓除役日期淪為形式。 因為遷移會反覆發生，值得讓這個過程可重複。

哪些人適合使用遷移流程

當你的團隊在較大的產品或平台中建構一個以 LLM 為驅動的功能，並以大約每季一次的頻率進行遷移，並且有明確的擁有者（例如中央平台團隊或應用程式團隊）負責每次遷移時，遷移流程才是最合適的。

這個流程同樣適用於 AI 原生團隊，因為模型就是產品。 這些階段是相同的，但執行得更快，而且通常會平行進行，而非嚴格依序進行。

此流程假設您是在基礎模型之間移轉，也就是在模型目錄中以已發佈形式部署的模型之間移轉，且未進行權重層級的自訂。 微調工作負載不在適用範圍內。 它們無法自動升級，因為它們各自有自己的訓練和部署汰役時程。 調整微調的工作負載意味著提煉或重新訓練，而非提示與結構描述變更。 如果您執行微調部署，建議及早規劃以針對取代基礎模型重新調整。

移轉階段

遷徙過程分為六個階段。 每一相產生一個輸出，下一相會使用這些輸出。 遷移階段包括：

探索→評估→調整→驗證→推出→退休

六階段模型遷移流程的圓圖，顯示發現、評估、調整、驗證、推出及退休，順時針排列。

下表說明每個階段及其支援的 Foundry 功能與工具。 除非標示為僅 Foundry，否則 Microsoft Foundry 與 Azure OpenAI 皆有此功能，這表示 Azure OpenAI 沒有對應功能。

本文後面的逐階段章節會解釋每個階段的存在原因、成功結果的樣貌、應考慮的事項、何時使用每個特徵，以及該階段通常會中斷的區域。

階段 Description 功能和工具
探索 了解模式變革即將到來或必要，並決定是否採取行動。
評估 選擇目標型號並確認其運作中可用。
適應 在新模型上重播目前的工作負載，診斷行為變化，並重新設計提示、參數、工具定義、輸出結構以及相關呼叫程式碼。
驗證 將調整後的工作量與品質評分標準進行評分，以判斷是否安全出貨。
推出 透過分階段公開提升至生產環境，監視線上行為，並執行認可或復原。
停用 停用舊版部署、釋放容量、歸檔評估結果，並更新下游相關文件。

遷移前：準備測試資料集

此準備步驟會彙整一組具代表性的輸入、預期產出及雙方同意的成功標準，然後才開始遷移工作。 此集合是流程中段的關卡相依性：若沒有輸入，您就無法在「調整」階段進行重播；若沒有基礎事實與標準，您就無法在 [驗證] 階段進行評分。

考量事項

  • 在選擇目標之前，先建立資料集。 資料集描述的是你的 工作負載，而非候選模型，因此你可以與 Discover 平行組裝。
  • 從真實或合成來源收集輸入。 使用擷取的正式環境流量或精選的特定領域範例，並採用 CSV 或 JSONL 格式。 當你還沒有代表性資料時，用 模擬器產生合成和對抗性輸入。
  • 在您需要之前先為擷取設定檢測。 生產內容擷取為選擇加入，且絕不溯及既往，因此您無法評估未記錄的流量。 現在就開始記錄提示、回應、延遲和令牌數量。
  • 凍結資料集。 整個遷移過程中，保持輸入、實地資訊和成功標準固定不變。 如果有任何改變，你就無法再比較來源和目標結果。

你還需要一份工作負載所使用的部署模型清單，包括它們的部署類型（標準、配置或批次）。 針對每個來源模型，請參考 模型退役時程，註明其退役日期及建議的替代模型。

第一階段：發現

「探索」階段的目的是辨識模型變更即將到來，或其值得進行評估，並決定是否採取行動。其輸出結果是進行/不進行 (go/no-go) 決策，而繼續沿用目前的模型也是有效的選擇。 成功的結果是早期且有結構的訊號，告訴你淘汰日期、替換型號和遷移時段，或是刻意決定繼續使用現有模型。

考量事項

  • 退休日期是什麼？你實際還有多少跑道？ 把淘汰日期（扣除驗證時間和推出時間）當作真正的截止日期。
  • 有沒有指定的推薦替代者，還是需要自己篩選候選人？
  • 這項變更是否帶有合規性或區域限制（對於受規範的工作負載而言，可用性與認證往往比品質更重要）？

常見斷裂的地方

團隊透過電子郵件、入口網站橫幅或內部訊息不穩定地了解退休消息，且他們發現訊號較晚。 這種延遲縮短了本已緊迫的窗口期。 獨立開發者和小團隊常常發現是因為生產錯誤而退休，而非公告。

你帶來的是什麼

淘汰計劃與模型 API 會透過穩定的合約公開資料。 成熟組織會在上方加一層薄薄的內部通知層，將通知轉發給正確的擁有者。

第二階段：評估

評估階段的目的是選擇候選目標模型，並確認你是否能執行：合適的區域、合適的部署類型、足夠的配額，以及與現有模型並存的可用性，以確保回滾的可行性。 成功的結果是明確選擇候選模型，並在調校開始前確認區域、SKU、配額與成本。

考量事項

  • 候選人之間的品質與定位。 當多個模型同時飛行時，決定哪一款能符合 你的 品質負擔，而不只是哪一款在公開基準測試中得分最高。
  • 您自己的流量成本。 不同世代的定價結構會有所變動。 推理全長、快取輸入和結構化輸出的額外開銷可能會使單位經濟效益產生 2 倍以上的波動，因此請根據歷史流量來預估每月成本，而非僅憑定價。
  • 作戰可用性。 確認區域、SKU 和配額，並且目標能與來源並行運行，這樣你就能保留回滾路徑。
  • 合規閘門。 對於受規範的工作負載，認證與區域可用性可以在品質進入討論前篩選候選人名單。

常見斷裂的地方

當多位候選人的立場不明確時，選擇癱瘓就會開始。 團隊到了計畫中途才發現，所選的模型未在其區域或 SKU 中提供。 或者成本預測顯示新模式在實際流量上實質上更昂貴。

你帶來的是什麼

基準測試是基於 公開 資料集計算，因此將排行榜視為篩選器而非終點線，並根據自己的工作量確認候選名單。 成本預測也是同樣的情況：月度視圖來自你自己的代幣日誌，一旦有了流量資料，這就很簡單了。

第三階段：適應

調整階段的目的是讓工作負載在新模型上運作良好。 先原封不動地重放既有工作負載（以隔離模型驅動的行為變化），診斷哪些地方發生了變化，然後再以迭代方式重新工程化。 成功的結果是將行為與真實或代表性流量並列比較，並追蹤每一個變化。

「調整」不只是提示編輯

提示是最明顯的層面，但移轉通常還會牽涉到另外四個層面：

  • 參數。temperature、top_p、max_tokens以及推理工作量控制項在不同世代之間並非一一對應，而且較新的模型系列可能不支援某些參數。
  • 工具定義。 你可能需要重新措辭或精簡那些過去一向能可靠地引導舊模型的參數名稱、說明和必填欄位。
  • 輸出結構。 不同模型在遵循結構化產出的方式上有所不同。 你可能需要在舊模型大致滿足的結構中加入明確的限制，或者你終於能強制執行一個結構。
  • 呼叫程式碼。 API 介面與 SDK 的差異（Chat Completions 與 Responses、串流格式，以及新增或重新命名的請求欄位）。 你可能也需要更新那些原本假設舊有回應結構的下游解析邏輯。

對於代理型和工作流程類工作負載而言，結構描述和工具呼叫相關工作往往比提示詞工作占更大比重。

考量事項

  • 調整前先原樣重播。 在目標模型上執行你目前的設定，完全不做任何更改。 這種方法幫助你區分 模型 改變的行為與 你 引入的改變，並提供基準。
  • 注意到底發生了什麼變化。 冗長度、推理深度、對結構化輸出的遵循程度、工具呼叫的形式、拒絕行為及延遲波動通常都會改變。
  • 重播真實追蹤，以找出工具呼叫的迴歸問題。 額外欄位、重新命名的引數和變更的順序只會在真實追蹤中顯現，而非單輪基準測試。
  • 追蹤你的變化。 提示重新設計很容易進行，也很容易遺失。 保留原件，並記錄下哪些改變以及原因。

鑄造廠特色

Foundry 有三個功能支援此階段：

  • 提示優化器 是位於代理遊樂場系統指令欄位正下方的 優化 按鈕。 它會運用提示工程的最佳實務來重構你的指令，顯示每個段落中針對每項變更的推理，並支援迭代流程：加入例如 「完全保持 JSON 綱要不變」 這樣的建議，然後重新最佳化。 僅在 Foundry 提供，Azure OpenAI 不提供。
  • 代理優化 會將指令、工具與模型選擇調整以配合代理工作負載。 僅在 Foundry 提供，Azure OpenAI 不提供。
  • 模擬器會在您沒有可供重播的生產環境資料時，產生合成和對抗式輸入。

常見斷裂的地方

對於嵌入式、面向產品的工作負載，這個階段通常花費最多時間，因為診斷流程是手動的：團隊會重跑提示、比較差異，且很少記錄變更內容或原因。

你帶來的是什麼

  • 先從優化器開始，再驗證。 他們是在單次處理中套用 通用 最佳實務，而不是針對你的資料集進行擬合，且調整的是指令文字，而非工具定義或輸出結構描述。 將輸出視為品質不錯的草稿：先複製原始提示詞（因為沒有版本歷史），再根據凍結資料集重新評估，之後再決定是否採信這項變更。
  • 規劃跨家族搬遷時的額外實務工作。 並不存在「針對目標模型 X 進行最佳化」這種流程，因此在不同模型系列之間切換時，必須刻意進行提示詞和結構描述的轉換。
  • 在需要之前先記錄交通狀況。 「重播」的效果取決於擷取品質，而內容擷取需自行選擇加入，且不會溯及既往。

第四階段：驗證

驗證階段的目的是透過根據精選資料集的品質評分標準，判斷該適應後的工作負載是否安全可交付。 評分標準可以是基於規則、參考文獻、以LLM作為評審、人類審查，或是特定領域的框架。 成功的結果是交付一套可信賴的評估套件，運行於凍結資料集上，讓應用程式團隊與審核者都信賴。

驗證是一個階段，但它有兩個接觸點，所以不要把它當作單一的終點事件來處理：

  • 要早點準備。 在「移轉之前、調整之前」中凍結資料集和成功準則。 一旦這些改變，你的來源和目標就不再可比。
  • 於流程後期分兩輪執行關卡檢查。 首先在凍結資料集上執行目前的模型，建立一個來源基準，也就是您必須超越的數字。 然後以同一組項目為目標評分，並作出決定。

考量事項

  • 保持資料集和標準凍結。 這是保持結果可比性過程中最重要的一門學科。
  • 衡量與簽核對應的三個維度：品質 (評估者或審查者評分)、延遲 (首個權杖時間與輸送量，僅針對您要移轉的呼叫獨立計算)，以及成本 (每次要求的輸入與輸出權杖成本)。
  • 讓評分標準與工作量相匹配。 臨床摘要評分標準、針對代理人的工具呼叫序列斷言，或既有的使用者回饋訊號，可能比一般分數更有意義。
  • 將關卡機制視為 AI 原生團隊的參考訊號。 評估不再是一次性通過/失敗，而是在每次提交時持續執行，並與 Roll out 融合。

鑄造廠特色

Foundry 有兩個功能支援此階段：

  • Azure AI 評估 SDK 內建超過 30 個評估器，涵蓋紮實性、相關性、檢索性、一致性、流暢度、基於參考的指標（F1、BLEU 及 ROUGE）、安全性、代理及 Azure OpenAI 評分器。 它還包含可自訂、以 LLM 擔任評判的機制，用於針對特定任務的評分規準。
  • 入口評估 會對模型、代理、資料集和追蹤目標執行相同的評估器。

針對已凍結的資料集，使用相同的一組評估器對 來源和目標兩者 進行評估，使數據具有可比性。

Dimension 要測量什麼 哪裡
Quality 來源與目標上的評估者分數 Azure AI Evaluation SDK，入口網站評估
Latency 首次代幣時間與吞吐量 基準排行榜與營運指標
Cost 每次請求的輸入與輸出令牌成本 評估結果與模型定價

常見斷裂的地方

大多數團隊沒有評估套件，而有的團隊往往是自己打造的。 對於受管制的工作負載，還必須在其上加上人工或品質管理審查，而這也因此成為 瓶頸。 這些遷移停滯在驗證階段，而非適應階段。

你帶來的是什麼

評估器已可運行，但若要從 您自己的 正式環境流量中整理出符合特定領域需求的測試集，對模型（非代理）工作負載而言，仍需手動處理。 正是因為這個需求 ，準備步驟 本身就能帶來回報。

第五階段：推出

此階段的目的是分階段將已驗證的組態推進至生產環境：先從非生產環境開始，接著進行 Canary 發佈或依權重比例釋出，最後再擴大開放範圍。 在整個過程中，監看即時延遲、錯誤，以及理想情況下相對於遷移前基準值的品質。 然後認可或復原。 成功的結果包含：透過 Canary、按權重分配或影子流量來逐步開放流量，建立超越延遲與錯誤率的即時品質訊號，並保留完善的復原機制。

考量事項

  • 了解你的部署類型。 你的部署類型決定了機制：標準系列部署可以依你控制的時程自動升級。 佈建式、批次及微調部署皆為手動移轉。 下表顯示了各類型的機制。
  • 保留回滾走廊。 讓舊版部署維持可連線，直到您有把握為止。 因取代期限逼迫而非基於實證所做出的復原決策，代表您太晚開始的警訊。
  • 如果不能用 Canary 模式，就用陰影或鏡像模式。 受管制的流程（PHI、金融交易）通常無法讓新模型接觸到真實的客戶流量。 等效的做法是離線執行新模型，將輸出與舊模型比較，而不影響使用者。
  • 留意離線評估遺漏的迴歸問題。 真實使用者的延遲與邊緣情況行為只能在生產負載下顯現。

依部署類型的遷移機制

部署類型 移轉方法 Quota
標準、全域標準、資料區標準 依循分批排程自動升級。 控制時序為 versionUpgradeOption （OnceNewDefaultVersionAvailable， OnceCurrentVersionExpired， 或 NoAutoUpgrade）。 優先處理（Priority Processing）也遵循相同的路徑。 自動結轉
已備妥 手動：就地 (流量會在 20 到 30 分鐘內逐步切換) 或並行 (進行新部署、切換流量，然後刪除舊部署)。 先確保目標模型配額
Batch 並行部署：部署新模型、重新提交作業，然後停用舊部署。 確保目標模型配額
微調（本文範圍外） 不會自動升級；訓練與部署的退役時程分開計算。 重新微調，或在取代的基礎模型上進行提煉。 確保目標模型配額

流量移轉後，請串接持續性評估，在 Foundry 可檢視性儀表板上針對抽樣比例的生產流量進行評分，並連結至追蹤以進行根本原因分析，同時建立品質下降時的 Azure 監視器警示機制。

常見斷裂的地方

離線評估未被忽略的品質迴歸結果，會出現在生產負載下。 復原決策往往是被取代期限逼迫，而非基於實證，這代表移轉工作開始得太晚了。

你帶來的是什麼

兩個部署之間的加權路由是在你自己的閘道或應用程式層中實作，而回滾緩衝期則是刻意保留的一種做法，用來讓舊版部署在一段期間內持續維持可用狀態（嵌入式系統團隊通常希望約 30 天）。 兩者都值得在設計一次後，於每次遷移時重複使用。

第六階段：退休

汰除階段的目的是讓舊有部署退役、釋放容量、將評估產出物歸檔，並將此變更向下游傳達至客戶文件、行銷頁面、支援作業手冊，以及需要保留的稽核日誌。 最終，舊的部署消失，部署次數下降，教訓延續到下一個週期。

考量事項

  • 把退休當作治理，而不僅僅是清理。 對於受管制的工作負載，保留義務可能需要將產物保存多年。
  • 確認來源確實已不存在。 確認舊版本已淘汰，然後刪除該部署，使其停止佔用容量。
  • 將學到的經驗延續下去 將新的生產追蹤整合回你的黃金資料集，讓 下一次 遷移能更便宜地開始。

常見斷裂的地方

團隊跳過淘汰階段，導致殭屍部署不斷累積。 未積極執行淘汰作業的團隊，其執行中的部署數量遠多於同行，且其中大多數都是先前移轉所留下的結構性殘骸。 一個常見的忽略步驟是溝通：行銷和產品文件在更換後仍會提及舊型號。

你帶來的是什麼

可觀察性儀表板顯示部署數量呈下降趨勢，但決定哪些部署仍具負載性，則是團隊自行判斷。 讓退休成為明確的追蹤任務，而非寄望。

遷徙很少是非黑即白的

實際遷移通常是分割狀態的：部分工作負載在新模型上運行，而延遲敏感或風險較高的路徑則留在舊模型上，有時會持續數週。 規劃分階段部署與分階段回滾，而不是一次性從舊模型切換到新模型。 淘汰階段往往比「全面推出」落後數週甚至數月，而這些持續殘留的舊部署正是造成部署蔓延的主因。

相關內容

  • 上次更新時間：