用一台 NVIDIA DGX™ B300 伺服器打造台灣金融模型：推理評測快約 6 倍，保留工具呼叫能力
企業想讓 AI 更熟悉自己的專業領域，除了選擇模型，也得處理資料、訓練成本與部署環境。本次金融領域實驗還有一個重要前提：資料必須留在機房內。
APMIC（亞太智能機器股份有限公司）用一台配備 8 張 NVIDIA Blackwell Ultra GPU 的 NVIDIA DGX™ B300 伺服器，微調大型模型，讓它學習台灣金融教材，並取得相當卓越的成果，該模型能以更精簡的推理輸出與更短的整批評測耗時，取得接近原模型的金融題庫準確率，讓領域微調的價值，從單看答對多少題，延伸到完成這些題目需要多少輸出與時間。
以 LoRA (Low-Rank Adaptation) 為例，開啟推理時，平均每題輸出由 3,352 降至 986 tokens，減少約 71%。在相同題庫、重複次數與並行設定下，整批評測時間由原模型的 90.98 分鐘降至 14.70 分鐘，約為 1/6.19；準確率則由 78.4 降至 75.2。雖然分數下降，這組結果仍呈現了解題效率上的實質改善。這裡的效率指輸出量與整批評測耗時，尚不能據此判定模型對題目的理解能力提升。以下先看成果，再說明資料如何影響解題方式，以及這項效率改善的適用範圍。
重點摘要
|
背景：為什麼要在地端微調 120B 模型
金融業需要 AI 理解法規、授信、信託、外匯等專業問題，也需要掌握資料的使用範圍。當教材、內部規範與考題不能離開企業機房時，在企業自己的伺服器上完成訓練與部署，也就是「地端」作業，便成為值得評估的做法。
本文的「微調」，是以已訓練好的模型為基礎，再用領域資料調整它的參數，讓回答更符合需求。「單一節點」則是指一台伺服器；這台伺服器內可以裝有多張 GPU，共同分擔運算。
我們選擇的 Nemotron 3.5 Super VL，是 NVIDIA 的混合架構推理模型。它的總參數約為 121B，也就是約 1,210 億個參數；每處理一個 token，約啟用其中的 12B。Token 是模型處理文字的基本單位，可能是一個字、詞，或詞的一部分，不能直接視為中文字數。
從架構來看，它結合 Mamba-2、Transformer 注意力機制與 MoE（混合專家模型，含 512 個路由專家），並內建多 token 預測模組（MTP head）與視覺編碼器。MoE 會依輸入選用部分專家運算，因此總參數量與每次實際啟用的參數量不同。這個差異有助於理解運算成本，但不代表訓練時只需載入啟用的那部分權重。
在台灣金融證照題庫上，原模型開啟推理時已有 78 分以上的表現。我們想進一步回答兩個問題：
在地端的單一節點上，能不能有效率地微調這個等級的模型？
以台灣金融教材資料微調後，模型能否更符合金融應用需求，同時保留工具呼叫能力？
實驗怎麼做：資料與兩種微調方式
資料準備延續了 APMIC 過去整理領域資料與把關資料品質的實務經驗。這次除了整理金融教材，我們也透過評測檢視資料對模型行為的影響：模型學到了哪些知識，又改變了哪些回答習慣。
訓練資料包含 4 份由台灣金融教材衍生的繁體中文資料集，共 14,792 筆，涵蓋銀行授信、信託、外匯、理財規劃、內控稽核與防制洗錢等主題。我們採用監督式微調（SFT），也就是提供回答示範，讓模型學習。每筆示範都包含「推理（<think>）＋解答」；因此，模型學習的內容也包括解題過程的寫法。
LoRA 保留原始權重，只訓練額外加入的小型參數模組（adapter），因此需要更新的參數較少。全參數微調（Full FT） 則直接更新語言模型的全部參數，調整範圍更大，也需要更多訓練記憶體。本次兩種方法都不更新視覺編碼器。
本次比較原模型、LoRA 與 Full FT 的金融題庫及工具呼叫表現。由於 LoRA 的實驗週期較短，本次先以 LoRA 作為主要迭代版本；Full FT 加上通用資料、工具呼叫資料等擴充組合，尚未完成驗證。因此，本文不是要判定 LoRA 一定優於 Full FT，而是先記錄目前可觀察到的結果。環境、容器、訓練設定與記憶體估算完整保留於文末技術附錄。
先看評測結果：領域表現與工具呼叫的取捨
我們從兩個面向評估模型：台灣金融證照題庫用來觀察領域問答表現，BFCL 則用來檢查工具呼叫能力。
以下的 Thinking ON 表示開啟推理模式，模型會先產生推理內容，再給出答案；Thinking OFF 表示關閉這個模式。本文也將 OFF 稱為「快速回答模式」，但它只是模式名稱，微調後不一定回答得更快。
為了讓比較條件一致，原模型與微調模型皆使用相同的文字生成設定（temperature 1.0、top_p 0.95），分數取多次評測的平均值。金融題庫以百分制呈現答對比例；少數題目有多個正確答案，答對其中任一答案即給分。文中的「提升幾分」是分數相減，不是相對成長百分比。
先處理資料污染
如果考試題目早已出現在練習教材中，分數提高就可能包含記住答案的效果。模型評測也有同樣的問題。
我們以字面比對找出訓練資料與測試集的重疊，發現約 10% 的題目已出現在訓練資料裡，主要集中於內控稽核、外匯與理財規劃等科目。因此，下表除了全部題目的分數，也另外列出「未見題目」的成績。
這裡的「未見」，是指本次比對未發現題目出現在微調資料中，無法保證改寫過的相似題都已排除〔註 2〕。分開呈現，才能更清楚判斷微調是否改善了對新題目的回答能力。
台灣金融證照題庫
模型 | Thinking OFF：全部 | OFF：未見題目 | Thinking ON：全部 | ON：未見題目 |
原模型 | 71.6 | 72.8 | 78.4 | 79.5 |
LoRA（2 epochs） | 75.4 | 74.9 | 75.2 | 74.9 |
Full FT（1 epoch） | 74.8 | 73.9 | 76.0 | 74.9 |
BFCL（工具呼叫，單輪 AST）
工具呼叫是指模型依問題選擇外部工具，並產生符合要求的參數。例如查詢匯率時，模型需要提出正確的查詢要求，而不只是寫出一段看似合理的答案。本次採用 BFCL 的單輪 AST 評測，檢查工具呼叫的結構與參數是否符合預期；它涵蓋的範圍有限，不能代表完整的 Agent 任務能力。
模型 | Thinking OFF | Thinking ON |
原模型 | 81.0 | 82.4 |
LoRA（2 epochs） | 79.2 | 79.3 |
Full FT（1 epoch） | 65.6 | 23.9 |
結果解讀
本次先以 LoRA（2 epochs） 作為主要分析對象，原因是它的實驗週期較短，能快速完成一輪資料與模型行為的檢查。以下結果用來說明目前的取捨，不代表 LoRA 已經是所有情境下的最佳方法：
領域問答更準確：在快速回答模式（thinking OFF）下，準確率比原模型高 3.9 分（75.4 vs 71.6）；排除訓練時看過的題目後仍有 +2.1 分〔註 2〕。
Agent 能力保留：工具呼叫（BFCL）在 thinking OFF / ON 下分別維持原模型的 97.7% (79.2 / 81.0) 與 96.3% (79.3 / 82.4)，顯示它在本次工具呼叫測試中保留了大部分表現〔註 6〕。這個比例是相對於原模型的分數，並非工具呼叫成功率達到 96–98%。
推理模式的優勢在於解題效率：LoRA 在全部題目上的準確率比原模型低 3.2 分，但平均輸出減少約 71%，整批評測時間由 90.98 分鐘降至 14.70 分鐘，約縮短 84%。若只追求準確率，原模型仍較佳：在未見題目上，兩種微調方式都比原模型低約 4.5 分。效率與分數需要一起評估，詳見「實際推論速度」一節。
LoRA 與 Full FT 的比較
Loss（損失值）衡量模型輸出與訓練目標之間的差距；驗證 loss 則是在保留、不參與參數更新的資料上計算。同樣條件下，loss 較低通常表示模型更能符合這份資料的回答方式，但它並不等同於金融題庫的答對率。
圖 2 中，Full FT 的驗證 loss 較低；搭配圖 1 卻可看出，它的未見題目表現與工具呼叫能力並未更好。因此，判斷資料與微調是否有效，需要一起看訓練過程和實際任務結果，避免僅憑 loss 下結論。
LoRA（2 epochs） | Full FT（1 epoch） | |
1 epoch 時的驗證損失（validation loss） | 0.494 | 0.470 |
證照題庫 OFF：未見題目 | 74.9 | 73.9 |
證照題庫 ON：未見題目 | 74.9 | 74.9 |
證照題庫 ON：訓練時看過的題 | 76.3 | 80.1 |
BFCL OFF / ON | 79.2 / 79.3 | 65.6 / 23.9 |
Full FT 更快學會這份資料的回答方式：在相同的 1 epoch 比較點，驗證 loss 較低；在訓練時看過的題目上，分數也較高。這種更貼近資料的現象，稱為「擬合」。
更好的擬合沒有帶來更高的未見題目分數：Full FT 在 thinking OFF 下比 LoRA 低約 1 分，ON 則相同。這與模型較偏向記憶訓練資料的解釋一致，但小幅分數差異仍不能保證具有統計顯著性〔註 2〕。
Agent 能力的差異很大：LoRA 的工具呼叫只下降 2–3 分；Full FT 則大幅退化，而且訓練越久越嚴重（半個 epoch 時 thinking ON 已從 82.4 降至 35.3）。模型會說「我來查詢匯率」，卻沒有真的呼叫工具，而是直接編出一個數字。這類原有能力的退步常被稱為「遺忘」，也是後續調整資料組成時要檢查的重點。
就這份資料與目前的實驗設定而言，LoRA 使用約 1/4–1/5 的 VRAM、每步訓練時間相近，並保留較多工具呼叫表現。這讓它適合作為較快的迭代起點；但 Full FT 若加入通用資料與工具呼叫資料，能否降低遺忘、取得更好的整體結果，仍需後續實驗驗證。兩種方法的學習率與訓練輪數不同，且各僅訓練一次，因此本文不把結果解讀成 LoRA 一定優於 Full FT。
實際推論速度
「推論」是指模型收到輸入後，運算並產生回覆的過程；「推理」則是本文用來描述模型解題的方式。要看懂速度差異，需要分清楚：模型每秒能產生多少 token，以及完成一題總共要產生多少 token。
本節比較微調前後完成題目的時間，所有速度數據都以相對值呈現。服務本身的壓力測試與部署效能，另見文末「技術附錄五：基礎推論效能」。
LoRA 權重合併後，以及 Full FT 微調後，模型的架構與大小都與原模型相同。因此，不能把這次加速理解成模型變小了，或每個 token 的運算成本大幅降低。在推理模式下，觀察到的主要變化是完成一題所需的輸出長度縮短了；MTP 的實際加速效果仍可能受微調影響〔註 4〕。
下表使用相同服務設定（DP=2 × TP=4、MTP 開啟、固定同時處理的請求數），比較評測耗時。ON 與 OFF 各自以同模式的原模型為 1.0，兩組相對值不能直接互比。推理模式的金融題庫評測共有 1,346 題、每個設定重複 3 次，因此合計 4,038 次作答；原模型整批耗時 90.98 分鐘，LoRA 為 14.70 分鐘，Full FT 為 15.11 分鐘。每題平均耗時是由整批評測總時間除以題數換算，並非逐一量測使用者等待回覆的時間〔註 5〕。
模型 | 模式 | 平均輸出 tokens / 題 | 每題平均耗時（原模型 = 1.0） | 準確率（全部題目） |
原模型 | thinking ON | 3,352 | 1.0 | 78.4 |
LoRA | thinking ON | 986 | 0.16（快約 6 倍） | 75.2 |
Full FT | thinking ON | 1,018 | 0.17（快約 6 倍） | 76.0 |
較少的輸出與時間，仍取得接近原模型的分數：以 LoRA 為例，平均輸出從 3,352 降至 986 tokens，減少約 71%；整批評測時間由 90.98 分鐘降至 14.70 分鐘，約為原模型的 1/6.19。準確率由 78.4 降至 75.2，表示效率改善伴隨 3.2 分的下降，而非維持完全相同的答題能力。
少數超長回答也會拖慢整批評測：這套評測以檔案為單位等待結果。多數請求完成後，如果還有少數題目持續生成長篇回答，部分處理資源就會閒置。微調後的回答長度較一致，在同時處理相同數量請求的設定下，整體輸出吞吐量約為原模型的 1.8 倍。
金融題庫的加速不能直接套用到工具呼叫：BFCL 在推理模式下，LoRA 的總耗時約為原模型的 1.9 倍，Full FT 約為 3 倍。Full FT 出現以文字回答取代工具呼叫的情況，平均輸出也從 313 增加到約 1,000 tokens。
深入分析：微調如何改變模型的推理方式
前面的結果顯示，微調後的模型能以較少輸出與較短評測時間完成題目，但也犧牲了部分準確率。為了找出保留效率優勢、改善答題表現的方向，我們進一步比較原模型與微調模型輸出的推理內容（reasoning content）：模型花多少篇幅解題、是否重新確認判斷，以及這些寫法與訓練資料有多相似。
以下分析的是模型輸出的文字，並不能直接觀察模型內部的思考。語言與自我檢查比例以字元及關鍵字規則估算；p90 表示第 90 百分位數，用來觀察較長回答的長度。
原模型 | 微調後（LoRA / Full FT） | |
輸出 tokens 中位數 / p90（含答案） | 1,357 / 8,672 | 約 960–1,000 / 約 1,300 |
推理是否依難度調整長度 | 是：答錯題的推理長度約為答對題的 3.5 倍 | 否：答對與答錯的推理長度幾乎相同 |
含自我檢查（「等等」、「wait」、「再確認」等） | 約 72% | 約 1% |
推理語言 | 約 70% 以英文為主、約 18% 為簡體中文 | 幾乎全為繁體中文 |
微調後的推理寫法與 SFT 資料十分相近：固定以「讓我思考一下」開頭，推理段的長度中位數約 450 字，接近訓練資料的 509 字。內容多半直接給出確定判斷，較少出現重新檢查或修正的語句。
另一個明顯差異是，原模型在答錯題目上往往產生更長的推理；微調後，答對與答錯題目的推理長度卻相近。這表示模型輸出的解題篇幅變得更固定，但光看篇幅仍無法判定推理品質。
為了進一步比較，我們以原模型的推理長度作為題目難度的近似指標，將題目分組。這不是獨立的難度測驗，但能協助觀察退步較集中在哪一類題目：
題目難度（原模型推理長度） | 原模型 | LoRA |
簡單（< 1.5k 字） | 94.2 | 93.6 |
中等（1.5k–4k 字） | 89.2 | 84.2 |
偏難（4k–9k 字） | 73.8 | 67.8 |
最難（> 9k 字） | 53.7 | 53.7 |
準確率下降主要集中在中等與偏難的題目。這個結果與「微調後較少展開推理及自我檢查，可能影響部分題目的表現」的解釋一致；因果關係仍需要對照實驗驗證。
以一道涉及法規期限的題目為例：原模型先承認「需要確定法律依據」，列出幾種可能的規定，中途寫下「等等，讓我再重新審視」，再逐一用邏輯排除干擾選項，最後答對。微調後的模型則用很短的推理直接斷言「依規定應於某日起二日內公告」，但這條規定是模型自己編出來的，因而答錯。
根據訓練資料與模型輸出的比對，我們提出一個可能的解釋〔註 3〕：這份 SFT 資料的推理，是由另一個模型在已知答案的情況下改寫成精簡版本。這種寫法適合說明既定答案，卻未必保留探索不同可能性、檢查錯誤與修正判斷的過程。
當模型學習這種寫法時，可能也減少了原先較長的推理與自我檢查。換句話說，示範答案即使簡潔、流暢，也不保證能成為較強模型的合適訓練材料。這是目前的解釋，尚未證實為退步的直接原因。
這次分析讓我們把資料品質的檢查，從答案本身延伸到示範的解題過程：推理資料的品質，除了內容與答案是否正確，也要看示範的解題方式是否適合目標模型。後續品質檢查需要將資料內容、模型輸出與任務評測一起比較，才能確認調整資料是否帶來預期的改善。
單機執行的成本與端到端流程
除了模型表現，這次實驗也確認了地端執行的可行性。配備 8 張 NVIDIA Blackwell Ultra GPU 的單一伺服器，能容納 LoRA 與全參數微調的記憶體需求，並接續完成部署與評測，資料全程留在機房內。
在本次設定下，兩種方法每個訓練步驟都約需 10 秒；走完一輪訓練資料約需 1.3–1.4 小時。LoRA 的記憶體峰值約為 50 GiB，Full FT 約為 190 GiB。因此，LoRA 的主要資源優勢是節省記憶體與存檔空間，而兩者的每步訓練時間相近。完整估算與量測方式見「技術附錄三：VRAM 需求與訓練速度」。
端到端流程
一次完整實驗，從資料準備開始，經過訓練與部署，最後以評測確認結果。LoRA 與全參數微調的部署前處理不同，完成後則使用相同的評測流程：
資料整理、前處理與污染檢查都納入同一套流程，後續的逐題評測結果則用來分析資料品質，作為下一輪調整的依據。
整套流程皆由腳本執行，方便依相同步驟重做實驗。各階段耗時會自動記錄到 APMIC Trackio，最後產出格式一致的評測報告，以及可供商業智慧（BI）系統同步的逐題回覆資料。
這次實驗告訴我們什麼？
這次實驗帶來三個實務判斷：
單機可以完成這個規模的地端微調。 8 張 NVIDIA Blackwell Ultra GPU 讓訓練、部署與評測能在同一台伺服器上完成，一輪實驗只需數小時。
LoRA 提供了較快的迭代起點。 推理模式下，平均輸出減少約 71%，整批評測時間由 90.98 分鐘降至 14.70 分鐘，約縮短 84%，準確率則下降 3.2 分；同時，工具呼叫分數保留原模型的 96–98%。這是一項有明確取捨的效率改善。由於本次尚未完成 Full FT 與通用／工具呼叫資料的擴充實驗，不能據此判定 LoRA 是最終最佳選擇。若優先追求金融題庫準確率，原模型開啟推理仍較佳；關閉推理時，LoRA 則是分數提高、耗時增加。
資料品質必須連同模型行為一起檢查。 題目是否重疊、格式是否正確、示範如何解題，以及原有能力是否退步，都會影響對微調效果的判斷。本次對推理風格的分析提供了改善方向，成因仍待驗證。
下一步
APMIC 將以這次逐題評測與推理分析的結果，調整後續的資料整理方式。由於 LoRA 適合快速迭代，接下來會先用它驗證資料品質與推理示範的方向，再評估 Full FT 與資料擴充組合。另一項方向是「自我蒸餾」（self-distillation），利用原模型自身產生的推理內容，整理出更適合它學習的示範。
我們也會嘗試加入工具呼叫與通用資料，檢查能否減少原有能力的退步，並更嚴格地區隔訓練資料與評測題目。後續實驗將持續比較領域準確率、輸出長度、評測耗時與工具呼叫表現，目標是在保留精簡推理與效率優勢的同時，改善較難題目的解題品質。
附註
VRAM 估算：依參數量計算（BF16 為 2 bytes、fp32 為 4 bytes），不含活化值（activation）、通訊緩衝區（buffer）與記憶體碎片，只作為量級參考。
分數的不確定性：每個設定只訓練一次，約 1–2 分的差距（例如 +2.1、OFF 低約 1 分）無法保證具有統計顯著性，也就是目前還不能排除這些差異來自實驗波動。本次實驗以字面比對判定「未見題目」，改寫過的相似題可能偵測不到，未見題目的增益仍可能略為高估。
成因是推論：「SFT 推理的品質低於原模型、模仿後導致退步」是根據本次觀察提出的解釋，尚未用對照實驗驗證因果。
MTP 未重測：MTP head 沒有隨微調更新，我們也沒有對微調後的模型重新進行推論壓力測試。推測式解碼會由主模型驗證候選 token；MTP head 未更新可能降低候選 token 的接受率，進而影響實際加速效果。
評測負載下的速度：推理模式金融題庫評測共有 1,346 題、每個設定重複 3 次，共 4,038 次作答；原模型整批耗時 90.98 分鐘、LoRA 14.70 分鐘、Full FT 15.11 分鐘。每題平均耗時以評測總耗時 ÷ 作答次數換算，為固定並行負載下的近似值，並非逐一量測各請求所得的延遲。
Agent 能力的衡量範圍：本文以工具呼叫（BFCL v3 單輪 AST）作為 Agent 能力的指標；多輪 Agent 任務、一般知識與多模態能力沒有評測。「96–98%」為 LoRA 的 BFCL 分數除以原模型分數，Full FT 不在此範圍內。
致謝
感謝 NVIDIA 提供 Nemotron™ 3.5 Super VL 模型、NeMo AutoModel 與 NIM，以及 NVIDIA DGX™ B300 平台的技術支援。
技術附錄一：環境與容器準備
這套環境的分工：NVIDIA DGX™ B300 伺服器提供運算與記憶體，NeMo AutoModel 負責訓練，NVIDIA NIM 將模型部署成可供應用程式呼叫的服務，twinkle-eval 負責評測，Trackio 則記錄實驗過程。
項目 | 內容 |
硬體 | 1 台伺服器，8× NVIDIA Blackwell Ultra GPU（每卡 288 GB HBM3e，約 268 GiB 可用），NVLink 全互連 |
模型 | NVIDIA Nemotron 3.5 Super VL 120B-A12B，BF16 |
訓練框架 | NVIDIA NeMo AutoModel（FSDP2 + Expert Parallel） |
部署 | NVIDIA NIM（vLLM backend），DP=2 × TP=4，MTP 開啟 |
評測 | twinkle-eval：台灣金融證照題庫、BFCL v3（工具呼叫，單輪 AST），thinking OFF / ON |
實驗追蹤 | APMIC Trackio：每個訓練步驟的損失值（loss）、吞吐量與各階段耗時 |
表中的 BF16 是儲存模型數值所用的 16 位元格式；FSDP2 與 Expert Parallel 則負責把訓練工作分散到多張 GPU。部署設定 DP=2 × TP=4，表示有兩組模型副本，每組由四張 GPU 共同執行。
容器準備：為什麼自行建置
容器會把程式與所需套件放進同一個執行環境，減少不同機器之間的環境差異。本次需要自行建置容器，主要是為了取得較新的模型支援。
實驗當時，官方 NeMo AutoModel 容器的發布時程，與 AutoModel GitHub 主分支（main branch）的更新並不同步。Nemotron 3.5 Super VL 的模型實作、權重轉換與訓練設定範例（recipe）仍在更新中。因此，我們以官方容器為基底，保留已驗證的 CUDA 環境，再加入主分支的 AutoModel 程式碼。Dockerfile 如下：
FROM nvcr.io/nvidia/nemo-automodel:26.08
# 以最新的 AutoModel main branch 覆蓋容器內的版本
COPY Automodel /opt/Automodel
# 只重裝 AutoModel 本身，並升級它需要的 transformers 版本
RUN cd /opt/Automodel \
&& uv pip install --python /opt/venv/bin/python --no-deps -e . \
&& uv pip install --python /opt/venv/bin/python "transformers==5.15.1"
git clone https://github.com/NVIDIA-NeMo/Automodel.gitdocker build -t automodel-n35vl -f Dockerfile .修改 | 原因 |
以官方容器為基底 | 沿用容器內預先編譯的 CUDA 相依套件，例如 PyTorch、Transformer Engine、DeepEP、mamba-ssm，不必自己重新編譯 |
COPY 最新的 AutoModel | 取得最新的 Nemotron 3.5 Super VL 模型實作、state dict adapter 與 recipe |
--no-deps | 僅重新安裝 AutoModel 本身，避免套件管理工具依新版的相依性設定升級容器內已驗證可用的 CUDA 套件 |
升級 transformers | 新版 AutoModel 需要較新的 transformers 才能正確載入 Nemotron 3.5 Super VL 的 processor 與模型 |
.dockerignore 排除 Automodel/.git | 縮小建置內容（build context） |
如果建置環境無法透過 Docker 預設的 bridge 網路連外（例如主機採用特殊的防火牆規則），可以在 docker build 加上 --network host。
技術附錄二：完整訓練設定
我們以 NeMo AutoModel 官方的 Nemotron 3.5 Super VL 訓練設定範例為基礎，比較兩種微調方式。
下表的 lr 是學習率，用來控制每次參數更新的幅度；epoch 是走完一輪訓練資料。LoRA 的 rank 與 alpha，則分別影響新增模組的參數規模與更新強度。
方法 | 設定 |
LoRA | rank 64 / alpha 128，套用於 Mamba、attention、MoE latent projection 與 shared experts 的線性層；lr 2e-4，2 epochs |
Full FT | 語言模型全參數（1,207 億可訓練參數），視覺塔凍結；lr 1e-5，1 epoch |
兩種方法的 global batch size 都是 32，表示每次參數更新合計使用 32 筆樣本；Expert Parallel 設為 8，將專家運算分散到 8 張 GPU。另啟用 activation checkpointing，透過重新計算部分中間結果來節省記憶體。
訓練時關閉 MTP head；負責整理批次資料的 collate function，則設為不將樣本填補至固定長度（max_length: null），避免短樣本也要進行大量無效運算。
技術附錄三：VRAM 需求與訓練速度
訓練大型模型時，GPU 記憶體除了存放模型權重，還要保存更新參數所需的資料，以及運算中的中間結果。對這次 120B 等級的模型而言，記憶體容量是能否在單機完成全參數微調的關鍵。
我們依參數量估算 GPU 記憶體（VRAM）需求〔註 1〕，再與實測值對照。以下使用 GiB 作為單位；它與硬體規格常用的 GB 採用不同換算方式。NVIDIA Blackwell Ultra GPU 每張卡約有 268 GiB 可用；實測值是 PyTorch 記錄的已配置記憶體峰值，GPU 的實際總用量還會略高。
全參數微調（Full FT）
以較精確的參數量計算，模型共有 121.5B 參數，其中 120.7B 會參與訓練，視覺編碼器則維持不變。下表列出的訓練狀態，可理解為模型在學習時需要保留的工作資料：權重是模型目前的參數，梯度提供更新方向，主權重與 Adam 動量則用來支援參數更新。
項目 | VRAM（GiB） |
BF16 模型權重 | 226 |
BF16 梯度 | 224 |
fp32 master weights （store_param_remainders：以 bf16 權重加 16-bit 餘數還原） | 224 |
Adam 一階 / 二階動量（bf16） | 450 |
合計（不含 activation） | 約 1,125 |
平均每卡（8 GPU） | 約 141 |
實測每卡（一般 step / 峰值） | 174 / 190（另含 activation、FSDP all-gather 與 EP 通訊 buffer） |
節省記憶體的最佳化器（optimizer）設定是關鍵：以 bf16 儲存 Adam 動量、以 16-bit 餘數表示 fp32 master weights，讓 1,207 億參數的訓練狀態能容納於 8 張 NVIDIA Blackwell Ultra GPU 的記憶體中。
單一節點就能完成：NVIDIA 官方的全參數微調範例使用 4 節點、32 張 NVIDIA H100 GPU（每卡約 65 GiB）。NVIDIA Blackwell Ultra GPU 則讓我們在單一節點上完成，省去跨節點網路與共享儲存的設定。
LoRA
項目 | VRAM |
凍結的 BF16 權重 | 226 GiB（每卡約 28 GiB） |
LoRA 參數與 optimizer 狀態（1.77 億參數） | 約 3 GB，可忽略 |
實測每卡 | 平時約 36 GiB，遇到最長約 12,000 tokens 的樣本時峰值約 50 GiB |
如果只做 LoRA，NVIDIA Blackwell Ultra GPU 並非必要條件：NVIDIA 官方範例在單節點 8× NVIDIA H100 GPU 上就能執行（每卡約 36–39 GiB）。本次使用 NVIDIA Blackwell Ultra GPU 的好處，是能完整保留最長約 12,000 tokens 的樣本，後續也有增加批次大小的空間。
LoRA 與 Full FT：VRAM 用量差在哪裡
LoRA 與 Full FT 都要載入同一份 BF16 模型權重。記憶體用量的主要差別，在於哪些參數需要更新。Full FT 要為 1,207 億個參數保存梯度與更新所需的狀態；LoRA 只更新 1.77 億個 adapter 參數，原始權重便不需要這些額外資料。
每卡 VRAM（GiB，8 GPU） | LoRA | Full FT | 差異 |
BF16 模型權重 | 28 | 28 | 相同 |
梯度 | ≈ 0（只有 adapter） | 28 | |
fp32 master weights（remainder） | ≈ 0 | 28 | |
Adam 一階 / 二階動量 | ≈ 0 | 56 | |
訓練狀態小計 | 約 28 | 約 141 | 約 5 倍 |
實測：一般 step | 約 36 | 約 174 | 約 4.8 倍 |
實測：峰值（最長序列） | 約 50 | 約 190 | 約 3.8 倍 |
LoRA | Full FT | |
硬體參考（NVIDIA 官方範例） | 單節點 8× H100 | 4 節點 32× H100；本次為單節點 8× NVIDIA Blackwell Ultra GPU |
每個檢查點（checkpoint） | adapter 355 MB | 僅儲存模型約 450 GB |
部署前處理 | 合併 adapter（約 3 分鐘） | 補回訓練時未匯出的 MTP head |
Checkpoint 是訓練過程中保存的模型檔案，方便後續載入與評測。依本次紀錄，Full FT 需要約 4–5 倍的 VRAM；由於保存的是完整模型，checkpoint 的儲存空間也比 LoRA adapter 大數百倍。
LoRA 與 Full FT 的 GPU 記憶體用量曲線
小結：使用 NVIDIA DGX™ B300 伺服器的優勢
8× 80 GB 級 GPU | 8× NVIDIA Blackwell Ultra GPU | |
LoRA | 可以 | 可以，處理長序列與增加批次大小更有餘裕 |
全參數微調 | 需要多個節點（官方範例為 4 節點） | 單一節點 |
訓練、部署、評測在同一台完成 | 全參數微調時無法 | 可以 |
一輪實驗（訓練 + 部署 + 評測） | 需要跨節點協調 | 數小時 |
NVIDIA DGX™ B300 伺服器的主要價值，是讓這次全參數微調所需的記憶體能容納在一台伺服器內。至於訓練速度，則要另外看實測。下表中的 step 是一次參數更新；吞吐量表示每秒處理的 token 數，數值越高，代表同一時間能處理的資料越多。
LoRA | Full FT | |
可訓練參數 | 1.77 億（0.15%） | 1,207 億（99.3%） |
每卡峰值記憶體 | 約 50 GiB | 約 190 GiB |
每 step 時間（GBS 32） | 約 10 秒 | 約 10 秒 |
每卡吞吐量（tokens/s，中位數） | 564 | 634 |
1 epoch（454 steps，1,890 萬 tokens） | 約 1.3 小時（由 2 epochs 的訓練時間換算） | 約 1.4 小時（含兩次存檔） |
每次儲存 checkpoint | 數秒 | 約 3.5–4 分鐘（匯出約 230 GB 的 HF 權重） |
在這台 NVIDIA DGX™ B300 伺服器與本次設定下，Full FT 與 LoRA 的每步訓練時間相近。因此，LoRA 的主要優勢是節省記憶體與模型存檔空間，不能直接推論它在這次實驗中會訓練得更快。Full FT 較明顯的額外耗時，出現在儲存 checkpoint。
技術附錄四：實作過程中解決的問題
除了選好硬體與訓練方法，實際執行時還需要處理資料格式、權重轉換與存檔問題。以下整理本次遇到的狀況，供準備重現實驗的團隊參考：
容器版本：以官方容器為基底，改用 AutoModel 最新的主分支版本（見「技術附錄一：環境與容器準備」）。
填補（padding）造成的運算浪費：多模態 collate function 一旦設定 max_length，就會將所有樣本填補至該長度。我們的資料平均約 1,300 tokens、最長約 12,000 tokens，改成 max_length: null 可以避免大量無效的 padding 計算。
多輪對話的標籤（label）：chat template 會移除歷史輪次的推理內容，導致標籤無法對齊。我們先於前處理階段處理標籤對齊問題，再透過 collate function 確認全部 14,792 筆資料的損失遮罩（loss mask）皆正確，確認用來指定「哪些文字要計入訓練損失」的設定符合預期。
LoRA 合併回 HF 權重：AutoModel 匯出的 adapter 使用 Transformers v5 的命名，與原始 checkpoint 不同。我們撰寫了離線合併工具，逐一對權重分片（shard）套用 W + (α/r)·BA，保留視覺塔與 MTP head，整個合併過程約需 3 分鐘，完成後即可直接透過 NIM 部署。
Full FT 權重上線：NIM 預設透過 MTP head 進行推測式解碼（speculative decoding）以加速推論，但訓練時依官方設定範例關閉了 MTP head，匯出的權重不含 MTP 層。我們從原始權重補回 MTP 與視覺塔 buffer，讓 Full FT 模型能以和原模型相同的設定部署。補回的 MTP head 沒有隨微調更新，候選 token 仍由主模型驗證，但加速效果可能下降〔註 4〕。
磁碟空間：包含最佳化器狀態的 Full FT checkpoint 會占用大量磁碟空間。評測只需要模型權重，因此我們僅儲存模型，每個 checkpoint 約 450 GB。
技術附錄五：基礎推論效能
我們在同一台 NVIDIA DGX™ B300 伺服器上，以 NIM（DP=2 × TP=4）部署原模型，使用 vllm bench serve 進行壓力測試，輸入為 ShareGPT 對話，並開啟推理模式。
這裡的「吞吐量」表示整體每秒產生多少 token；「每 token 延遲」則反映持續產生文字的等待時間。兩者觀察的角度不同：同時處理更多請求，可能提高總吞吐量，也可能讓個別使用者等得更久。
項目 | 相對表現 |
MTP（speculative decoding）開 vs 關 | 輸出吞吐量提升 1.5–2.1 倍，每 token 延遲降到約 0.5–0.65 倍；平均每步接受約 3 個 token |
同時處理 300 個請求 vs 單一請求 | 總輸出吞吐量提升約 18 倍，每個請求的 token 延遲則增加約 15 倍 |
TP=2（2 張 GPU）vs DP=2 × TP=4（8 張 GPU） | 每張 GPU 的吞吐量約為 3.6 倍；8 卡部署的優勢在單一請求延遲與總吞吐量 |
MTP 在本次測試中有明顯的加速效果：它先提出多個候選 token，再由主模型驗證，有機會減少逐一生成的時間。在同時處理的請求較少時，效果最明顯（約 2 倍）。
部署方式要配合使用需求：本次測試中，較小的 TP 有較高的每卡吞吐量；若重視單一請求的回應速度，則可考慮讓較多 GPU 共同執行一組模型。
留言