• ChatGPT 可以開統編了。OpenAI 已在台灣完成稅籍登記，自 2025 年 5 月 1 日起，未填統一編號的台灣用戶會被加收 5% 營業稅；有填統編的企業用戶，OpenAI 會寄出台灣格式的電子發票（eGUI）。
• Claude 目前還不行。Anthropic 的帳單頁面雖然有 Tax ID 欄位可以填統編，但它開立的是美式 PDF receipt，不是台灣財政部規定格式的二聯或三聯統一發票，多數公司的會計無法直接作為進項憑證。
• 但對很多單位來說，發票從來不是真正卡住的那一關。大專院校與政府機關的問題是「不能用個人信用卡刷卡」「必須有國內廠商」「必須跑請購與驗收流程」——這些就算對方開得出發票也解決不了。
• 更關鍵的是：拿到 eGUI 不等於核銷得過。境外電商開立的是二聯式性質的雲端發票，而政府機關、大專院校與有內控要求的企業，多半還需要國內廠商開立的三聯式統一發票，外加報價單、比價與驗收文件，才能完成請購與核銷。這一關，OpenAI 開再多張發票也補不上。

以下我們把企業、學校、政府單位在採購 AI 軟體時會遇到的每一個關卡拆開來講，並說明什麼情況下你可以自己處理、什麼情況下需要透過國內廠商代購。

一、先講結論：三種平台、三種狀況

台灣公司想買海外 AI 訂閱，會遇到的第一個岔路是「這家平台在台灣有沒有稅籍登記」。有登記的可以開電子發票，沒登記的只能給你一張英文收據。

換句話說，「國外 AI 軟體都開不了發票」這個說法在 2026 年已經不完全正確。有些平台補上了，有些還沒有。在決定要不要找代購之前，先確認你要買的那一家屬於哪一類，可以省下不少冤枉錢。

二、境外電商在台灣的發票規則，到底是怎麼一回事

台灣自 2017 年起實施境外電商課稅制度：外國業者只要在台灣銷售電子勞務、年銷售額達到一定門檻，就必須在台灣辦理稅籍登記、報繳營業稅，並開立雲端發票給台灣買受人。

Google、Meta、Apple、Microsoft、Adobe 這些大型業者早就完成登記，所以你刷 Google Workspace 或 Adobe 訂閱時可以填統編、拿得到電子發票。OpenAI 則是相對晚近才完成登記的一家，這也是為什麼很多人的印象還停留在「ChatGPT 開不了發票」。

什麼是 eGUI（電子發票）

eGUI 是台灣財政部的電子發票（Electronic Government Uniform Invoice）。境外電商開立的是雲端發票，有正式的發票號碼、會上傳到財政部整合服務平台，企業填了統編之後就能作為進項憑證扣抵營業稅。

但這裡有一個很多人忽略的重點：境外電商開立的是二聯式性質的雲端發票，不是三聯式統一發票。一般營利事業拿它扣抵營業稅通常沒問題，但只要進到公務預算核銷、計畫經費核銷或內部稽核的場域，要求就完全不同了——多數單位的規定寫的是「國內廠商開立之三聯式統一發票」，而且還要能對應到報價單、請購單與驗收證明。

換句話說，「開得出發票」和「報得了帳」是兩件事。這也是為什麼即使 ChatGPT 已經可以開統編，我們仍持續接到大量學校與機關的代購需求。

為什麼有的平台開得出、有的開不出

關鍵在於該業者有沒有在台灣完成稅籍登記。這是業者自己的商業與稅務決策，跟你買多少沒有關係——你就算買一百個帳號，沒登記的業者一樣開不出台灣發票。這也是為什麼「多買一點請對方開發票」這種談法對海外平台是行不通的。

三、ChatGPT 統編怎麼填？發票會怎麼寄？

這是目前最多人搜尋的問題之一，我們把步驟寫清楚。如果你只需要買 ChatGPT，而且公司信用卡刷得過，其實你可以自己完成，不需要透過任何代購。

ChatGPT 統編填寫步驟

1. 登入 ChatGPT 網頁版，點選左下角帳號名稱進入 Settings（設定）
2. 選擇 Subscription（訂閱） → Manage my subscription（管理我的訂閱）
3. 在 Billing information（帳單資訊） 中填入公司名稱、地址
4. 在 Tax ID 欄位選擇台灣，填入 8 碼統一編號
5. 儲存後，之後每期扣款都會依此開立電子發票

最重要的一點：請在第一次付款前就填好統編。已經開立的發票無法回頭修改買受人統編，只能作廢重開，而且有期限限制。很多公司是刷了三個月才想到要報帳，那三個月的發票就補不回來了。

ChatGPT 的 5% 營業稅是怎麼回事

自 2025 年 5 月 1 日起，OpenAI 對未提供台灣統一編號的台灣客戶加收 5% 營業稅。也就是說，個人用戶或忘了填統編的公司，實際支付金額會比原本的美金定價多 5%。

填了統編的營業人則適用不同的處理方式，發票會寄到帳戶綁定的電子郵件信箱。所以填統編不只是為了報帳，也可能直接影響你付多少錢。

填了統編，就一定報得了帳嗎？

不一定。以下三種情況，即使你把統編填得完全正確，帳還是報不掉：

• 單位規定要三聯式統一發票。境外電商開立的是二聯式性質的雲端發票，多數政府機關、學校與部分企業的核銷規定並不接受，送件會被退回。
• 必須有完整採購文件。公務預算與計畫經費需要台幣報價單、請購單、比價紀錄與驗收證明，而海外平台的自助購買流程只會給你一封扣款通知。
• 第一次付款前忘了填。已開立的發票無法回頭修改買受人統編，那幾期的費用等於自行吸收。這是我們最常接到的求救電話之一。

如果你屬於上面任何一種情況，問題就不在統編欄位，而在採購管道——需要的是一家在台灣有稅籍登記、開得出三聯式發票、也走得完請購流程的國內廠商。

ChatGPT 付款方式有哪些？刷卡失敗怎麼辦

OpenAI 目前僅接受信用卡與金融卡，不提供銀行匯款、ATM 轉帳或超商代收。實務上，台灣企業最常遇到的是這幾種狀況：

• 公司卡被銀行風控擋下。海外訂閱型扣款是盜刷高風險類別，不少發卡行預設會擋，需要打電話開通海外交易或調整額度。
• 公司根本沒有信用卡。許多中小企業、學校單位與政府機關本來就沒有可供線上刷卡的公司卡。
• 扣款成功但無法對帳。每月小額美金扣款、匯率不固定，財務對帳與預算控管都很麻煩。
• 員工離職卡片失效。用員工個人卡訂閱，人一走服務就中斷，帳號還可能一起帶走。

這些問題，OpenAI 開得出發票也解決不了——因為問題出在付款方式，不是憑證。

四、ChatGPT Business、企業版、團隊版，到底差在哪？

這幾個名稱在中文world裡被混用得很嚴重，先澄清：OpenAI 原本的團隊方案叫 Team，後來更名為 Business。所以你在中文網路上看到的「ChatGPT 團隊版」「ChatGPT 企業版」「ChatGPT Business」，很多時候講的是同一個東西。真正的頂級方案 Enterprise 則是另外議價的層級。

價格為參考值，實際以原廠當期公告為準。

公司到底該買 Plus 還是 Business？

很多公司一開始買了好幾個 Plus 帳號分給員工，用一陣子才發現問題。Plus 與 Business 的差別不只是價格：

• 資料使用政策。團隊與企業方案通常提供「資料不用於模型訓練」的保障，個人方案則需要自行到設定中關閉。對有營業秘密或客戶資料的公司，這是關鍵差異。
• 集中管理。Business 有管理者後台，可以統一新增／移除成員。用 Plus 的話，員工離職你可能連他用哪個信箱註冊都不知道。
• 共用工作區。團隊方案可以共享 GPTs 與專案，個人方案各做各的，知識無法累積在組織裡。
• 帳務單純。一張帳單、一個統編，而不是十個員工十張美金扣款紀錄。

判斷原則很簡單：員工三人以上，或公司有資安、稽核、內控要求，就直接上 Business。省下的行政成本遠超過價差。

五、Claude 訂閱與付費：台灣企業真正的難題

相較於 ChatGPT，Claude 的狀況目前對台灣企業比較不友善。

Claude 有哪些付費方案

Claude 訂閱可以開統編嗎？

Anthropic 的帳單設定中有 Tax ID 欄位，台灣公司可以把統一編號填進去，該號碼也會出現在收據上。但關鍵在於——它開立的是美式 PDF receipt，不是台灣財政部格式的統一發票。

這意味著：

• 沒有台灣發票號碼，不會上傳到財政部平台
• 多數公司的會計無法作為進項憑證扣抵營業稅
• 學校與政府單位的核銷制度通常直接退件
• 稽核時可能被要求補件，但補不出來

有些公司的作法是用「國外費用」科目認列，但這牽涉到扣繳與帳務處理，請務必先與貴公司的會計師確認，不要自行判斷。

Claude 企業版怎麼採購

Claude 的 Team 與 Enterprise 方案同樣以海外信用卡扣款為主。對於需要走請購流程、需要台灣統一發票、或無法使用信用卡的單位，實務上多半得透過在台灣有稅籍登記的國內廠商來完成採購。

六、真正卡關的不是發票，是這三種單位的採購流程

我們服務過的客戶裡，真正的痛點分布在三個很不一樣的族群。

企業：卡在付款方式與帳號管理

對一般營利事業來說，只要平台開得出發票，扣抵通常不成問題。真正麻煩的是：公司卡刷不過、財務不願意把公司卡綁在境外平台、每月小額美金扣款難以編列預算、員工帳號散落各處沒人管、續訂日期到了才發現服務中斷。

規模越大越明顯。當公司有二十個以上的 AI 訂閱帳號分散在五個平台，光是「誰在用什麼、什麼時候到期、花了多少錢」就沒有人講得清楚。

大專院校：卡在核銷制度與計畫期限

學校端的問題最尖銳。教學計畫、研究計畫、教育部補助案都有嚴格的核銷規定：需要合格憑證、需要驗收證明、需要在計畫期限內完成請購與核銷。

一張美式 receipt 送到出納組，多數情況會被直接退回。更棘手的是時間——計畫核銷通常有截止日，被退件之後往往已經來不及重新走一次採購程序，最後只能由教師自掏腰包，或是放棄使用該工具。

政府機關：卡在採購法規與付款方式

公務機關的限制最多：公務預算必須走請購、比價或議價程序，需要留下完整的採購紀錄；付款方式以匯款為主，多數單位根本不允許以個人信用卡代墊後再核銷；驗收程序需要明確的交付項目與文件。

這些要求，海外平台的自助購買流程完全無法配合。不是對方不願意，而是它的商業模式本來就不是為了台灣的公務採購設計的。

七、四種常見的錯誤做法，以及它們的風險

在正確解法之前，先講幾種很常見、但其實會出問題的做法。

做法一：員工用個人信用卡墊付，事後請款

這是最普遍的權宜之計，風險也最實際：發票抬頭是個人不是公司、稽核時說不清楚、員工離職後服務中斷且帳號可能一併帶走、公司對該帳號沒有任何控制權。對上市櫃公司或有內控要求的組織，這種做法在稽核時很難交代。

做法二：多人共用一個帳號

為了省錢讓五個人共用一組 Plus 帳號，除了違反多數平台的使用條款、可能被停權之外，更實際的風險是對話紀錄互相看得到。當有人把客戶資料或內部文件貼進去，等於全公司都看得到。

做法三：找個人代刷、代購

網路上有不少個人提供代刷服務。價格可能便宜，但你拿不到任何合格憑證、對方隨時可能消失、帳號控制權不在你手上，若涉及帳號轉售還可能違反原廠條款導致停權。公司採購找無法開立發票的個人，本身就無法報帳，等於白做。

做法四：掛在海外關係企業底下

有海外分公司的集團有時會這樣處理。這在稅務上牽涉關係人交易與費用分攤，需要有合理的分攤基礎與文件，不是把費用挪過去就沒事。請務必由會計師評估後再執行。

八、合規的解法：由台灣登記公司代購代付

目前對企業、學校與政府單位最務實的做法，是委託在台灣有稅籍登記的國內廠商代為採購與付款。

運作方式

1. 你告訴廠商需要哪些工具、幾個帳號、月繳或年繳
2. 廠商提供台幣正式報價單，可作為請購與比價文件
3. 你依公司或機關既有流程完成請購核准，以銀行匯款付款
4. 廠商完成原廠採購與付款，帳號開通至指定信箱
5. 廠商開立台灣三聯式統一發票，進項稅額可正常扣抵

為什麼這樣不違反原廠條款

關鍵在於「代訂代付」與「轉售帳號」是兩回事。合規的代購模式中，帳號註冊在你的公司或員工名下，所有權、使用權、密碼控制權都在你手上，廠商只處理採購、付款、發票這些行政事務，不共用帳號池、不轉售授權。

什麼情況你不需要代購

誠實地說——如果你只買 ChatGPT、公司信用卡刷得過、也不需要走請購流程，那你自己填統編就好，不需要任何人代購。這篇文章前面已經把步驟寫給你了。

需要代購的是這幾種情況：要買的平台開不出台灣發票（例如 Claude）、單位無法使用信用卡、必須走請購與驗收程序、需要三聯式發票、或是同時使用多個平台需要集中管理與統一帳務。

九、戰國策集團的 AI 軟體代購服務

戰國策集團（NSS Group）是台灣的一站式網路服務公司，服務超過 26 年，提供網域註冊、虛擬主機、SSL 憑證、企業郵件、網站設計、SEO 與 AI 導入等服務，客戶涵蓋上市櫃公司、大專院校、政府機關與中小企業。AI 軟體代購是我們針對「台灣單位買不到、報不了帳」這個具體問題所提供的服務。

我們處理什麼

• 代為採購與付款：ChatGPT Plus／Pro／Business、Claude Pro／Max／Team、Midjourney、Cursor、GitHub Copilot、Perplexity Pro 等主流海外 AI 訂閱，以及絕大多數海外 SaaS 工具。
• 開立台灣三聯式統一發票：由戰國策集團開立，載明貴單位統一編號，進項稅額可正常扣抵，會計以「軟體訂閱費」或「資訊服務費」入帳即可。
• 配合請購與核銷流程：提供台幣正式報價單，支援銀行匯款與 ATM 轉帳。政府機關與學校單位可配合公務預算、請購程序與計畫核銷期限。
• 帳號集中管理：五個以上帳號提供管理清單，方便 HR 或 IT 追蹤誰在使用哪些工具、何時到期，並主動提醒續訂。
• 導入顧問建議：不確定該買哪個平台、哪個方案時，我們會先了解你的使用情境再建議，而不是直接推最貴的。

合規性

我們採用代訂代付模式：帳號註冊在貴單位或員工名下，所有權、使用權與密碼控制權完全在客戶手上。我們不共用帳號池、不轉售授權，符合各原廠的使用條款。

適合誰

怎麼開始

把你需要的工具、帳號數量、月繳或年繳告訴我們即可，不確定的部分我們可以協助評估。收到需求後 24 小時內提供正式報價單，確認付款後當日完成開通，當月開立統一發票。

• 服務頁面：戰國策 AI 軟體代購服務
• 免付費客服專線：0800-003-191
• 官方 LINE：@119m

十、常見問題

ChatGPT 可以開統編嗎？

可以。OpenAI 已在台灣完成稅籍登記，在帳單資訊的 Tax ID 欄位填入 8 碼統一編號後，會開立台灣電子發票（eGUI）寄到帳戶信箱。請務必在第一次付款前填好，已開立的發票無法回頭修改買受人統編。但能開統編不代表一定核銷得過，詳見下一題。

拿到 ChatGPT 的電子發票，學校或政府機關就能核銷嗎？

不一定，這是最容易被誤會的一點。境外電商開立的是二聯式性質的雲端發票，而多數公務預算與計畫經費的核銷規定要求「國內廠商開立之三聯式統一發票」，並需搭配報價單、請購單與驗收證明——這些文件海外平台不會提供，也無法補開。若貴單位屬於這種情況，可透過戰國策 AI 軟體代購服務，由本公司開立三聯式統一發票並提供完整採購文件。

ChatGPT 發票沒收到怎麼辦？

發票由 noreply@tax.openai.com 寄出，請先檢查垃圾郵件匣，並確認帳單資訊中的統編與電子郵件填寫正確。若當初未填統編，該期發票無法補開統編抬頭。

ChatGPT 為什麼多收我 5% 營業稅？

自 2025 年 5 月 1 日起，OpenAI 對未提供台灣統一編號的台灣客戶依法加收 5% 營業稅。填入公司統編後適用不同的處理方式，這也是我們建議企業用戶務必填寫統編的原因之一。

ChatGPT 付款方式有哪些？可以匯款嗎？

OpenAI 官方僅接受信用卡與金融卡，不支援銀行匯款、ATM 轉帳或超商代收。若貴單位無法使用信用卡，或必須以匯款方式付款，可透過戰國策集團代購，我們接受銀行匯款與 ATM 轉帳。

ChatGPT 刷卡失敗、公司卡刷不過怎麼辦？

海外訂閱扣款屬於銀行風控的高風險類別，常見解法是聯繫發卡行開通海外交易。若仍無法解決，或公司本來就沒有可線上刷卡的公司卡，則需要透過國內廠商代購。

Claude 訂閱可以開統編或台灣發票嗎？

Anthropic 的帳單頁面有 Tax ID 欄位可填入統編，但它開立的是美式 PDF receipt，不是台灣格式的統一發票。多數公司的會計無法作為進項憑證，學校與政府單位的核銷制度通常也會退件。需要台灣發票時，可透過戰國策集團代購，由我們開立三聯式統一發票。

Claude 付費方案有哪些？企業版怎麼買？

Claude 提供 Pro、Max 個人方案，以及 Team、Enterprise 團隊與企業方案。企業方案同樣以海外信用卡扣款為主，需要走請購流程或需要台灣發票的單位，實務上多透過國內廠商採購。

ChatGPT Business、企業版、團隊版是同一個嗎？

多數情況下是。OpenAI 原本的團隊方案名為 Team，後更名為 Business，中文常被稱為「團隊版」或「企業版」。更上一層的 Enterprise 則是議價的大型企業方案。

公司該買 Plus 還是 Business？

員工三人以上，或公司有資安、稽核、內控要求，建議直接選 Business。除了價格之外，Business 提供集中管理成員、共用工作區，以及資料不用於模型訓練的保障。

代購會比自己買貴嗎？

會有服務費，因為包含了匯率轉換、營業稅、發票成本、客服與續訂管理。但對必須報帳的單位而言，一張無法核銷的收據等於全額損失，實質成本反而更高。如果你自己買得到也報得了帳，我們會直接建議你自己買。

學校計畫經費快到期了，來得及嗎？

請儘早提供採購品項、金額、規格與收件資訊，並註明核銷截止日。戰國策集團會依案件狀況安排優先處理，協助加速完成報價、採購與電子憑證文件。

結語：先確認你卡在哪一關

買 AI 軟體報不了帳，在 2026 年已經不是單一原因造成的。ChatGPT 的發票欄位補上了，Claude 還沒有；而就算發票拿得到，政府機關與大專院校要的三聯式憑證、請購文件與驗收證明，海外平台一樣給不了。

所以第一步是先確認貴單位卡在哪一關。如果你是一般公司、公司卡刷得過、會計也接受境外電商的雲端發票，那自己填統編就好，這篇文章的步驟已經足夠。但如果你需要三聯式統一發票、需要台幣報價單走請購、無法使用信用卡，或是要買的平台根本開不出台灣發票——那就是戰國策集團可以接手的地方。

需要協助時，歡迎透過 戰國策 AI 軟體代購服務頁面留下需求，或直接撥打免付費專線 0800-003-191、加入官方 LINE @119m，我們的顧問會在一個工作天內與您聯繫。

本文所述之平台方案、價格與稅務規定以各原廠及主管機關當期公告為準。文中涉及帳務與稅務處理之部分，建議另行諮詢貴單位之會計師或主計單位。

SSL/TLS 憑證效期為什麼要縮短到 47 天？

直接回答：因為憑證效期越長，私鑰外洩後可被濫用的時間窗口就越大。2025 年 4 月 11 日，全球憑證政策制定組織 CA/Browser Forum 針對由 Apple 提出的 SC-081v3 提案進行表決，Apple、Google、Mozilla、Microsoft 四大瀏覽器陣營全數投下贊成票；29 家憑證頒發機構（CA）中有 24 家贊成、5 家棄權、無任何一家反對，正式確立 SSL/TLS 憑證效期逐步縮短至 47 天的時程。

推動這項變革的核心理由有三個。第一是降低憑證被濫用的風險：長效期憑證一旦私鑰外洩或憑證遭冒發，攻擊者可以在長達一年以上的時間內用它散布惡意程式或發動中間人攻擊；縮短效期能直接壓縮攻擊者的可利用時間。第二是確保驗證資料的新鮮度：網域控制驗證（DCV）的重用期限也將同步縮短，2029 年起僅剩 10 天，確保憑證對應的網域所有權資訊隨時是最新狀態。第三是提升加密敏捷性：面對後量子密碼學的轉換需求，短效期憑證讓整個產業能更快汰換老舊的加密演算法。

SSL 憑證效期縮短三階段時程表是什麼？

最新整理如下：目前（2026 年）SSL 憑證最長效期已經從 398 天降為 200 天，接下來還有兩波縮短。企業可以對照下表，檢視自己的憑證管理流程能否承受更新頻率的倍增。

SSL/TLS 憑證效期縮短時程表（2026 最新版）

值得注意的是，這份時程表沒有回頭路。從 398 天到 47 天，憑證效期縮短了 88%，而 DCV 驗證重用期縮到只剩 10 天，意味著幾乎每次換發憑證都要重新完成網域驗證。對還在用人工方式管理憑證的企業來說，這是管理負擔的 8 倍增長。

憑證效期縮至 47 天對企業網站有什麼影響？

簡明答案：如果沒有自動化機制，憑證過期導致網站中斷的機率將大幅上升。當瀏覽器偵測到憑證過期，會直接顯示「你的連線不是私人連線」的全頁警告，多數訪客會立刻離開，對電商網站而言等同營業中斷，也會傷害品牌信任與 SEO 排名。

以下是企業最常犯的錯誤，也是導入自動化前必須正視的痛點：

• 仰賴行事曆提醒與人工更新：一年一次還勉強可行，未來一年 8 次，只要負責同仁請假、離職或忘記，網站就會掛上警告頁面。
• 憑證資產盤點不完整：主網站有人顧，但 API 子網域、測試環境、郵件伺服器的憑證常被遺忘，而這些正是最常過期出事的地方。
• 多台伺服器手動部署：憑證換發後還要逐台安裝、重啟服務，每次更新都是一次人為疏失的機會。
• 低估驗證流程時間：DCV 重用期縮短後，每次更新都可能需要重新驗證網域，臨時處理容易來不及。

實務案例解析：2026 年 3 月新制上路後，我們觀察到不少台灣中小企業第一次遇到「一年要更新兩次憑證」就出現空窗，網站掛出安全警告數小時才被發現。這還只是 200 天時代；到了 47 天時代，沒有自動化的企業幾乎不可能不出事。

什麼是 ACME 自動化憑證更新協定？

ACME（Automatic Certificate Management Environment，自動憑證管理環境）是定義於 RFC 8555 的開放標準協定，讓伺服器與憑證頒發機構之間全自動完成憑證的申請、網域驗證、簽發、安裝與續期，全程無須人工介入。你只需要在伺服器上部署一次 ACME 用戶端（如 Certbot、acme.sh、win-acme），之後憑證會在到期前自動換發，網站加密連線全年零中斷。

手動更新與 ACME 自動化的差異，用一張表就能看清楚：

手動更新 vs ACME 自動化更新比較

企業該如何部署 ACME 自動化？一步步教你

專家建議依照以下五個步驟進行，完整拆解如下：

1. 盤點憑證資產：列出所有網域、子網域、伺服器與服務（網站、API、郵件、VPN）使用的憑證與到期日，建立憑證清冊。
2. 選擇支援 ACME 的憑證服務商：確認你的 SSL 憑證供應商支援 ACME 協定的自動申請與自動續期，而不是只提供人工下載安裝。
3. 部署 ACME 用戶端：依伺服器環境選擇 Certbot（Linux）、win-acme（Windows/IIS）或 acme.sh，完成與憑證商的帳號綁定（EAB 金鑰）。
4. 測試自動續期：使用測試指令模擬換發流程，確認驗證、簽發、部署、服務重載全部自動完成。
5. 建立到期監控與告警：即使全自動，也應設定憑證到期監控（如提前 14 天告警），作為最後一道防線。

如果企業內部沒有專責的 IT 人力處理這些設定，直接找有提供代管與安裝服務的憑證商會更有效率。戰國策 SSL 數位憑證服務已全面支援 ACME 自動化更新協定，企業憑證的申請與續期可全程自動化，並提供免費專人安裝服務，最快 20 分鐘核發憑證，搭配 24 小時全年無休的中文技術支援；憑證類型從單網域、萬用（Wildcard）、多網域（UCC）到 EV 進階驗證一應俱全，並提供 1 萬至 150 萬美元的 CA 責任保險與 7 天鑑賞期。深耕台灣網路服務 26 年、服務超過 30,000 家企業的戰國策集團，可以協助你在 47 天新制全面上路前，把憑證管理一次升級到位。

戰國策 SSL 憑證類型怎麼選？

網站架構的安全升級也可以一併規劃：如果你正準備把 AI 生成的網站系統上線，可參考vibe coding AI 生成的網站如何部署至戰國策虛擬主機；需要自架 VPS 的團隊則可延伸閱讀 Hermes Agent 安裝教學，把主機、憑證與自動化一次到位。

SSL 憑證效期縮短常見問題 FAQ

已購買的多年期 SSL 憑證會失效嗎？

不會。已簽發的憑證依簽發當下的規則有效至原到期日。多年期方案的本質是「一次購買多年額度、憑證分期換發」，因此購買 3 年期方案依然划算，只是換發頻率會隨新制逐步提高；選擇支援 ACME 自動換發的服務商，就完全不受影響。

免費憑證和付費憑證差在哪裡？

免費憑證（如 Let’s Encrypt）僅提供 DV 網域驗證，無企業身分驗證、無 CA 責任保險，也沒有原廠技術支援，出問題只能自己查文件。付費憑證提供 OV／EV 企業驗證強化信任度、附帶最高 150 萬美元的責任保險，並有專人協助安裝與排除障礙，對營運型網站與電商是必要投資。

企業什麼時候該開始導入自動化？

現在就要開始。2026 年 3 月起 200 天新制已生效，2027 年 3 月 15 日就會再縮短為 100 天。導入 ACME 自動化通常需要盤點、部署與測試 1 至 2 個月，越早完成，越能避開全面上路前的轉換塞車潮。詳細的新制報導可參考 iThome 的完整分析。

關於作者：本文由戰國策集團專業團隊撰寫。戰國策集團深耕台灣網路與資安服務 26 年，服務超過 30,000 家企業客戶，提供 SSL 數位憑證、虛擬主機、VPS、網站安全與 AI 數位轉型顧問服務。資料來源：CA/Browser Forum SC-081v3 決議、iThome 新聞報導。

💡 快速答案:AI 模型訓練和推理的 GPU 需求差在哪裡?

訓練要同時保存權重、梯度、優化器狀態與激活值,顯存約權重的 8-10 倍:7B 全參數訓練要 110-140GB,還吃多卡互連,是 H100 的主場。推理只需權重加 KV cache:同個 7B 模型 FP16 只要 14-16GB,一張 RTX 4090 可服務,INT4 量化再省一半。搞混兩者最浪費預算。

「我們要導入 AI,該租什麼 GPU?」這個問題沒辦法直接回答,因為它少了一個關鍵前提:你要跑的是訓練,還是推理?這兩種工作負載對硬體的要求差異之大,大到同一筆預算可能差出十倍的效果。把推理的需求拿去租訓練級的 8 卡 H100,是把錢丟進水裡;拿一張消費卡硬跑全參數訓練,是把時間丟進水裡。這篇文章把兩種負載的本質差異、顯存計算方式、硬體選型邏輯一次講清楚,最後給出讓同一批 GPU 發揮兩倍價值的混合策略。不需要 ML 背景,看得懂乘法就能跟著算完每一筆帳。

本質差異:一個在學習,一個在服務

訓練是讓模型「學會」:資料前向傳播算出預測,跟標準答案比對出誤差,再反向傳播計算每個參數的梯度,由優化器更新權重——這個迴圈重複數萬到數百萬步。推理是讓模型「工作」:只有前向傳播,權重完全不動,吃進 prompt、吐出 token,一次一步。

這個差異決定了一切。訓練是吞吐導向的批次作業:在乎「多久跑完一輪」,可以中斷續跑,對延遲無感,但要為梯度與優化器狀態付出巨額顯存,多卡之間還要頻繁同步。推理是延遲導向的線上服務:在乎「使用者等多久」,全年無休不能斷,顯存需求小得多,但要面對併發起伏與尖峰。用一句話記:訓練買的是算力與互連,推理買的是顯存容量與穩定服務。

營運節奏的差異同樣關鍵:訓練是「專案」,有開始有結束,排程可以彈性挪動,失敗的代價是重跑;推理是「營運」,有 SLA、有使用者體驗、半夜掛掉要有人爬起來處理,失敗的代價是商譽。這決定了兩者連租賃形態都不同——訓練適合短租衝刺,用完即退;推理適合長租加備援設計。把這兩種節奏塞進同一台機器、同一張預算表,就是多數 GPU 規劃失敗的起點。

顯存帳怎麼算:8-10 倍的差距從哪來

同一個 7B 模型,為什麼訓練要 110-140GB、推理只要 14-16GB?把顯存內容攤開就懂。訓練時,卡上要同時放四樣:FP16 權重(每參數 2 bytes,7B 約 14GB)、梯度(再 2 bytes)、AdamW 優化器狀態(FP32 動量與變異數,8 bytes,約 56GB)、外加隨 batch 與序列長度成長的激活值。合計每參數約 16-20 bytes,是純權重的 8-10 倍。

推理時,卡上只有 FP16 權重(14GB)加 KV cache(隨併發與 context 成長,單人使用約 1-2GB)。而且推理還有訓練沒有的省錢大招:INT4 量化把權重壓到四分之一,7B 從 14GB 縮到 5-6GB,品質損失多在 1-3% 內。這就是為什麼 LoRA 這類參數高效微調這麼受歡迎——它凍結原模型、只訓練低秩適配層,把「訓練帳」的梯度與優化器項目縮到趨近推理等級,7B 的 LoRA 訓練只要 18-24GB,詳細做法見 LLM 微調實戰。

推理端還有一個跟訓練相反的槓桿:批次。訓練的 batch 是為了學習效率,推理的 batching 則是把多個使用者的請求交錯塞進同一次運算,GPU 使用率從 20-30% 拉到 80% 以上,單卡吞吐翻好幾倍——代價是個別請求的延遲略升。這也是為什麼生產環境一定要用支援 continuous batching 的推論引擎:同樣的硬體、同樣的模型,服務容量差 5-10 倍,等於直接把月租除以五。

拿 7B 走一遍完整算式,你就再也不會忘記這個差距:權重 7B 參數乘 2 bytes 等於 14GB;訓練再加梯度 14GB、優化器狀態 56GB、激活值 10-50GB(隨 batch 與序列長度),合計 94-134GB。推理則是 14GB 權重加 KV cache——單人對話 1-2GB、20 路併發 10-20GB,合計 15-35GB。同一個模型,兩張預算表差出一個數量級;而且推理還能用 INT4 把權重壓到 5-6GB,訓練卻必須維持高精度,差距進一步拉大。

硬體選型:兩種負載看的規格完全不同

訓練機的三個關鍵規格:HBM 顯存頻寬(反向傳播是頻寬飢渴型運算)、卡間互連(NVLink 900GB/s 對上 PCIe 的 64GB/s,多卡訓練差距立現)、以及 ECC 記憶體與散熱穩定性(一輪訓練跑七天,第六天當機等於重來)。這些正是 H100 這類資料中心卡貴的理由,錢花在你看不到但訓練跑不掉的地方。

推理機的邏輯不同:單卡顯存容量決定放得下多大的模型,每 token 成本決定毛利,而消費級的 RTX 4090 在這兩項的性價比極高——這也是它成為推理神卡的原因。多卡互連對推理重要性低(除非模型大到必須跨卡切分),反而是多開副本做負載均衡更實際。一個常見的錯誤採購:為了「以後可能要訓練」而全上 H100,結果 90% 的時間在跑 7B 推理,單位成本是 4090 方案的三四倍。

那推理什麼時候輪到 H100?三種情況:模型大到單卡裝不下且要 FP16 品質(70B 以上)、長 context 場景讓 KV cache 動輒數十 GB、或高併發對外服務需要單點高吞吐。多卡策略也跟訓練相反:訓練的多卡是「合力算一件事」,要 NVLink 緊耦合;推理的多卡多數時候是「各自服務、負載均衡」,兩台單卡主機常常比一台雙卡主機更好用——還順便有了備援。

穩定性的要求也值得一提:訓練跑七天,中途壞卡靠檢查點續命;推理是全年無休,看的是故障率與換修速度。租用方案在這裡有隱形價值——硬體故障是主機商的問題,備品與換機時間寫在合約裡,比自購機器壞了現找料件安心得多。

功耗與散熱同樣是選型的一部分:一張 4090 滿載約 450W,8 卡 H100 主機整機動輒上萬瓦,電力與空調是機房等級的需求,這也是「把訓練機放辦公室角落」幾乎都以跳電或過熱降頻收場的原因。租用台灣機房的主機,電費、散熱、UPS、消防都包在月租裡;把這些隱形成本攤回自建方案上比較,帳面月租其實比看起來便宜。

對照表:同一個模型,兩種負載的配置

讀表的方式:橫著看是同一個模型從開發到上線的資源演變,直著看是你的預算能支撐的規模上限。多數企業的實際旅程是「租 H100 做一段時間的微調,上線後換成 4090 級推理機長期服務」——兩個階段、兩種規格、兩張報價單,合在一起才是專案的真實成本。

對照表也順便解釋了市場上一個常見的價格困惑:為什麼 H100 主機月租是 4090 的好幾倍,大家還是搶著租?因為它們根本不在同一個市場——H100 賣的是訓練與大模型推理的「能力」,4090 賣的是中小模型推理的「性價比」。拿 4090 的價格去砍 H100 的規格,或拿 H100 的規格去要求 4090 的價格,都是在浪費彼此的時間;先分清楚負載,報價單自然就看得懂了。

台灣案例:電子廠把同一筆預算用出兩倍效果

桃園一家電子組裝廠導入 AOI 瑕疵檢測的視覺模型加上產線知識問答的 LLM,最初的規劃是租一台 4×H100 主機包辦所有工作,月租七位數邊緣,財務直接退件。顧問重排後的架構:訓練需求(每月一次的瑕疵模型重訓、每季一次的 LLM 微調)改成短租 H100 主機,每次 3-5 天、月均成本約 NT$40,000-60,000;推理需求(產線 24 小時的即時檢測加辦公室的知識問答)交給兩台雙 4090 主機,月租合計約 NT$70,000。

結果是總月成本從原規劃砍掉超過一半,推理服務的 p95 延遲反而更好,因為推理機可以按產線位置就近部署、多副本分流。訓練短租的另一個好處是規格自由:下一季想試 32B 模型的微調,直接改租更大的配置,不用被自有硬體綁死。資料面也乾淨——檢測影像涉及客戶產品外觀,全程留在台灣機房,滿足客戶稽核的資料在地要求。

數字攤開更有說服力:原方案 4×H100 全年月租估 NT$180 萬年支出;新架構是訓練短租年約 NT$55-70 萬,加推理雙機年約 NT$84 萬,合計省下約四成,而且推理機的 p95 延遲從共用時代的不穩定,變成穩定壓在 0.8 秒內。財務長最買單的一句話是:「訓練的錢花在有訓練的月份,推理的錢才是固定成本。」預算結構跟著負載走,審預算的人也看得懂。

混合策略:讓 GPU 不再有下班時間

訓練與推理分開配置之後,還有一層進階玩法:時間分割。推理有明顯的日夜週期,辦公型應用晚上十點後使用率常掉到 10% 以下,這段時間正好拿來跑訓練:夜間排程啟動 LoRA 微調或資料處理,清晨完成後釋放顯存回到推理服務。一張 24GB 的卡,白天服務 10-20 路併發的問答,晚上跑 7B 的 QLoRA 迭代,等於一份月租買兩份產能。

落地這套策略的前提是服務層要俐落:推論引擎能快速卸載與重載模型、任務排程有優先權設計、監控能確認「早上八點推理服務一定回來」。這些工程細節在 AI 推論 API 自建教學 有完整展開。原則只有一條:先分清楚你的每一個工作負載是訓練還是推理,再決定它該住在哪種 GPU 上、住多久。想清楚這題,GPU 預算的效率至少差一倍。

風險控管兩條底線要守住:混用的那張卡,推理服務的恢復要有自動檢核——訓練任務結束後服務沒起來就告警加自動重啟;訓練任務要設資源上限與最晚結束時間,寧可訓練慢一天,不要早上八點推理服務起不來。時間分割是省錢技巧,不是走鋼索,把保險機制寫好才有資格用。

把整篇的判斷濃縮成四個問題:這個負載是一次性專案還是長期服務?顯存需求是權重的十倍(訓練)還是一點多倍(推理)?它需要多卡緊耦合還是多副本分流?尖峰在白天還是可以排進夜間?四題答完,該租 H100 還是 4090、該短租還是長租、該一台還是兩台,答案基本上自動浮現。之後每次規劃卡關,回來把這四題重答一次,比翻任何規格表都快。

「先租後買」的節奏也順帶講清楚:前六個月用租的,把負載形狀量出來——尖峰、離峰、訓練頻率、顯存水位;若使用率長期在七成以上且規格已經穩定,再評估買斷或簽長約換折扣。反過來,負載還在變的階段就買硬體,等於把不確定性直接鎖進資產負債表,那是財務最不想看到的一種浪漫。

找台灣在地的 GPU 主機夥伴

訓練短租 H100、推理長租 RTX 系列,這種分離式配置需要主機商同時具備兩種產品線與彈性租期。戰國策 GPU 主機提供 NVIDIA H100 與 RTX 系列多種配置,台灣機房、資料不出境,月租 NT$15,000 起,7×24 中文技術支援,訓練與推理可以分開租、隨階段調整。方案細節見 戰國策 GPU 主機,或加 LINE @119m、撥免費專線 0800-003-191,顧問會依你的工作負載組合試算最省的架構。

常見問題 FAQ

為什麼訓練需要的顯存是推理的近十倍?

訓練時卡上同時放權重(FP16 每參數 2 bytes)、梯度(2 bytes)、AdamW 優化器狀態(8 bytes)與激活值,合計每參數 16-20 bytes;推理只要權重加 KV cache。7B 的對比就是 110-140GB 對 14-16GB,差距近十倍。

RTX 4090 適合訓練還是推理?

推理是它的主場:24GB 顯存能跑 7B FP16 或 32B INT4,每 token 成本遠低於資料中心卡。訓練方面,單卡跑 7B-14B 的 LoRA/QLoRA 沒問題,但缺 NVLink 與 ECC,多卡全參數訓練效率差、穩定性風險高,大型訓練還是交給 H100。

H100 比 4090 貴好幾倍,貴在哪裡?

貴在訓練需要的三樣東西:80GB HBM 高頻寬顯存(頻寬約 3.35TB/s,是 4090 GDDR6X 的 3 倍以上)、NVLink 900GB/s 卡間互連、以及 ECC 與資料中心級穩定性。若你的負載是中小模型推理,這些溢價用不到,選 RTX 系列性價比更高。

推理的 KV cache 是什麼?會吃多少顯存?

KV cache 是推理時暫存注意力鍵值的快取,讓模型不用重算前文,代價是顯存:依架構每路 4K token 約 0.5-2GB,與併發數、context 長度成正比。20 路併發、8K context 的服務,KV cache 可達 20-40GB,規劃時要在權重外預留 20-40% 空間。

先租訓練機還是先租推理機?

看專案階段。要微調自有模型:先短租訓練規格(如 H100,一次 3-7 天),模型定版後換長租推理規格(如 4090 主機月租 NT$15,000-25,000)服務使用者。直接用現成開源模型的話,跳過訓練段,從推理機開始,POC 兩週內就能上線。

同一台主機可以白天推理、晚上訓練嗎?

可以,而且是中小團隊最省錢的玩法。推理服務入夜後使用率常掉到 10% 以下,排程在深夜卸載推理、跑 LoRA 微調,清晨恢復服務,一張 24GB 卡等於當兩台用。前提是任務排程、模型快速重載與開機自檢都要自動化,避免早上服務沒回來。

訓練和推理可以用同一種量化嗎?

不行,方向相反。推理常態使用 INT8/INT4 量化,省一半以上顯存、品質損失多在 1-3%;訓練必須維持較高精度(FP16/BF16 混合精度)以保梯度品質,QLoRA 雖然把凍結底模壓到 4-bit,可訓練的適配層仍是高精度。拿 INT4 權重直接全參數訓練會學壞。

推理服務要怎麼估需要幾張卡?

公式:先定尖峰併發數與延遲目標,單卡容量 = 權重 + 併發×每路 KV cache + 20% 餘裕。例如 32B INT4(20GB)配 15 路併發(約 15-20GB),需 40GB 以上,即一張 48GB 卡或兩張 4090。上線後看佇列深度與 p95 延遲決定加卡時機。

訓練短租真的比長租划算嗎?

多數情況是。企業微調的節奏常是每月或每季一輪,每輪 3-7 天,短租 H100 的月均支出約 NT$40,000-80,000;同規格長租且大半時間閒置,月租是它的好幾倍。只有訓練排程滿到每月超過 20 天時,長租或買斷才開始划算。

邊緣推理和機房推理怎麼選?

延遲極敏感或斷網不可接受的場景(產線即時檢測、門店互動)放邊緣小型 GPU;需要大模型、集中管理與彈性擴充的(知識問答、文件處理)放台灣機房主機,網路往返 5ms 上下對多數應用無感。常見架構是邊緣跑小模型、機房跑大模型,各司其職。

💡 快速答案:怎麼把自己的 AI 模型架成推論 API 服務?

POC 用 Ollama,生產用 vLLM 或 SGLang,提供 OpenAI 相容 API,前端改 base_url 就能接。7B 權重約 14-16GB 顯存,每路 4K 對話的 KV cache 抓 0.5-2GB,10-20 路併發用一張 24GB 卡起步,台灣機房月租 NT$15,000-25,000。

模型選好了、也驗證過效果,接下來的問題才是工程的開始:怎麼讓全公司、甚至你的客戶,穩定地用到這個模型?答案就是把它包成推論 API。這一步的難度常被低估——單人測試跑得飛快的模型,一上線就延遲爆炸;或者為了扛併發把規格拉滿,月底看帳單才發現 GPU 大半時間在發呆。自建推論 API 本質上是在延遲、併發、成本三個角之間找平衡,這篇教學把三角關係拆開講,給你可以直接套用的估算方法與架構建議。

為什麼要自建:三個過不去的檻

用現成的雲端模型 API 沒什麼不對,直到你撞上三件事之一。資料敏感:客戶對話、病歷、財務數據不能送出境,個資法與行業主管機關的要求擺在那裡;成本失控:按 token 計費的帳單跟著用量線性長,月百萬次呼叫的產品,API 費用常常超過自建月租的兩三倍;客製需求:你微調過的模型、特殊的取樣參數、需要保證的回應時間,公有 API 都給不了。成本這條再講個常見劇本:產品加了「AI 摘要」按鈕,上線時每天 2,000 次呼叫,三個月後功能被預設開啟、變成每天 5 萬次,API 帳單從五位數跳到六位數,而訂閱定價早就鎖死——毛利被吃掉的速度比任何人的反應都快,自建的固定月租在這種「功能普及化」劇本裡就是定價保險。三者中一項成立,自建就值得認真評估;兩項成立,基本上是遲早的事。

反過來也要誠實:三種情況不建議自建。用量太小——每天幾百次呼叫,API 月費幾百塊,自建怎麼算都不划算;完全沒有維運人力——連 Linux 都沒人碰的團隊,先用 API 把產品驗證起來;以及任務非旗艦閉源模型不可——開源模型盲測過確實不夠力的少數場景。自建是工程決策不是信仰,拿你的用量、資料屬性與人力對照上面六條,答案通常很清楚。

三角習題:延遲、併發、成本怎麼互相拉扯

看懂三角關係,要先認識兩個延遲指標。TTFT(Time to First Token)是使用者按下送出到看到第一個字的時間,決定「有沒有在動」的體感,健康值在 0.5-2 秒;生成速度(token/s)決定字流出來的速度,單人閱讀場景 20 token/s 以上就順。併發是同時處理的請求路數,成本則是你為此付出的 GPU 月租。

三者的拉扯關係很具體:併發拉高,同一張卡上的請求互搶算力,TTFT 與生成速度都會掉;要守住延遲就得加卡,成本上升;要省成本就得接受排隊,延遲變長。工程上沒有三全其美,只有「依產品需求選兩個保、放掉一個」:內部工具保成本與併發、犧牲一點延遲;對客戶的付費服務保延遲、用超額配置換體驗。規格單一直搖擺的團隊,多半不是不會算,是還沒想清楚產品定位,先回去把定位吵完再來選卡。先寫下你的目標值(例如 p95 TTFT 低於 1.5 秒、尖峰 30 併發、月預算 NT$60,000),再開始選規格,順序不要反過來。

給一組實測的感覺:一張 4090 跑 7B FP16 配 vLLM,單人使用 TTFT 約 0.3 秒、生成 70-100 token/s;把併發灌到 10 路,TTFT 升到 0.8-1.2 秒、每路生成掉到 30-50 token/s;灌到 25 路,TTFT 破 2 秒、開始排隊。同一張卡,體驗從「飛快」到「將就」到「不可用」,差的只是併發數——這就是為什麼規格討論一定要從「尖峰有幾路」開始,而不是從「模型幾 B」開始。

TTFT 的組成也值得拆開看:排隊等資源、prefill(把整段輸入一次算完)、然後才開始逐字生成。長輸入的 prefill 很重——丟一份 8K token 的文件進去,光 prefill 就可能占掉一兩秒,這是文件型應用的 TTFT 永遠比聊天型難看的原因。對策有三:前綴快取讓相同的系統提示詞不重算、超長輸入先截斷或摘要、把文件批次任務改走非同步路徑,別讓它跟即時對話搶同一條佇列。

推論引擎選型:效率差距可以到十倍

選擇邏輯很簡單:POC 用 Ollama 十分鐘上線;要對多人服務,直接上 vLLM——它的 continuous batching 會把不同請求的生成步驟交錯排進 GPU,同一張卡的有效吞吐是逐條處理的 5-10 倍,這一項就決定你要租一張卡還是五張卡。四個引擎都支援 OpenAI 相容 API,應用端程式碼可以完全不動,把 base_url 從商用服務換成自家端點即可,這也讓「先用商用 API 驗證產品、再切自建」的路徑幾乎零改寫成本。

引擎與量化的搭配有慣例可循:vLLM 生產部署搭 AWQ 或 GPTQ 的 4-bit 權重最順,顯存省一半以上、吞吐幾乎不折損;Ollama 用 GGUF 格式,拉檔即用。要留意的是不同引擎的預設參數差很多——最大併發數、KV cache 上限、context 長度都要按你的硬體明確設定,用預設值上線然後 OOM,是新手工程師的固定戲碼。

顯存預算:權重之外,KV cache 才是變數

推論顯存等於「模型權重加 KV cache 加少量開銷」。權重好算:7B FP16 約 14-16GB、32B INT4 約 18-20GB;KV cache 是每一路進行中的對話都要占用的快取,依模型架構,每路 4K token 大約 0.5-2GB,而且跟併發數與 context 長度成正比。這就是為什麼「單人測試沒問題,上線就 OOM」的劇本不斷重演:20 路併發、每路 8K context,KV cache 可能吃掉 20-40GB,比模型本體還大。

實用的估算流程:先定尖峰併發與平均 context,算 KV cache 總量,加上權重,再留 15-20% 餘裕。舉例:32B INT4(20GB)服務 15 路併發、平均 4K context(約 15-20GB KV cache),總需求 40-48GB,一張 L40S 48GB 剛好,或雙 4090 用張量平行分攤。若跑的是 DeepSeek R1 這類思考鏈很長的推理模型,context 消耗更兇,預留空間要再放大,各版本的具體數字見 DeepSeek R1 GPU 需求對照。

好消息是新一代架構與引擎都在幫你省這筆錢:採用 GQA 的模型(Llama 3、Qwen2.5 世代)KV cache 比舊架構省 4-8 倍;vLLM 的 PagedAttention 把 cache 切成小分頁按需配置,傳統部署裡三到五成的顯存碎片浪費幾乎歸零。同樣一張 24GB 卡,2023 年的部署方式撐 4-5 路併發,2026 年的組合拳可以撐 15-20 路——選對引擎本身就是最大的一次降本。

台灣案例:SaaS 團隊把月帳單砍掉六成

一家台中的 HR SaaS 公司,產品內建履歷解析與面談摘要功能,原本走海外商用 API。用戶成長後兩個問題同時爆:月 API 帳單衝到 NT$90,000 出頭並持續上升;金融與醫療類客戶在資安問卷上直接問「求職者個資是否出境」,答不好就丟單。他們花了六週切換到自建:模型選 Qwen2.5-14B 微調版,INT4 量化後 9-11GB,跑在台灣機房一台雙 4090 主機上(月租約 NT$35,000),vLLM 做服務層,尖峰實測 22 路併發。

六週的切換時程值得拆開參考:第 1-2 週租單卡主機做離線評測,拿 500 筆歷史請求對比自建模型與原 API 的輸出品質,確認可接受;第 3 週建雙卡生產環境與監控;第 4 週用 5% 真實流量做灰度,發現兩個格式邊界問題,修 prompt 解決;第 5 週流量放到 50%,壓測驗證尖峰;第 6 週全量切換,原 API 降為備援。全程使用者無感,這是照劇本走的結果,不是運氣。

切換後的數字:月固定成本 NT$35,000,比原帳單省六成,而且不再隨用量成長;p95 TTFT 從 2.8 秒(含跨海往返)降到 1.1 秒,台灣機房到台灣用戶的網路往返只有 5ms 上下;資安問卷的資料出境欄位從此填「否」,當季就簽下兩家原本卡關的金融客戶。他們保留了原本的商用 API 作為 fallback:自建端點健康檢查失敗時自動切換,雙保險的月成本不到 NT$1,000,因為 99% 的流量都走自建。

壓測方法他們也走了標準流程:用開源壓測工具重放歷史流量的放大版(平常尖峰的 1.5 倍),連續打 30 分鐘,盯 p95 延遲與錯誤率;再單獨測「長文件」路徑——履歷有一頁的也有八頁的,長輸入是延遲長尾的主要來源,單獨設超時與截斷規則後,p99 才穩下來。切換這種事,九成的信心來自壓測,一成才來自祈禱。

上線後才是重點:監控、SLA 與擴容節奏

推論服務的維運圍繞四個數字:p50/p95 TTFT、生成速度、佇列深度、GPU 使用率。前三個顧體驗,最後一個顧錢包——GPU 使用率長期低於 30%,表示規格買太大或該把批次任務排進離峰;佇列深度常態大於零,表示該擴容了。告警設在使用者抱怨之前:p95 TTFT 超標 20% 就通知,而不是等客服工單進來。儀表板不用花俏,四個數字加一條佇列趨勢線,值班的人一眼能看懂,就是好儀表板。

成本也要有月報:每月統計 token 總量、GPU 平均與尖峰使用率、換算的單位成本(每百萬 token 幾塊錢),跟商用 API 的牌價對照一次。這張報表有兩個用途——向管理層證明自建的價值持續成立,以及在用量成長到需要擴容時,用數據而不是感覺去申請預算。自建服務最怕的不是壞掉,是沒人說得清它到底省了多少錢。

資安層的最低標配:API key 按應用發放、每季輪替;閘道做速率限制擋暴衝與濫用;請求日誌全留但個資欄位遮罩;管理介面只開內網。這四件事一天可以做完,卻是資安問卷與稽核的必考題,別等被問到才補。

擴容的節奏建議「垂直先、水平後」:先把量化等級、批次參數、context 上限調到位,再考慮換大卡,最後才是多卡多副本加負載均衡。另外,推論主機與訓練主機的規格邏輯完全不同,別拿訓練的配置思維來配推論——這個常見誤區在 訓練與推理的 GPU 配置邏輯 有完整拆解。把這些機制建立起來,自建 API 的穩定度可以做到跟商用服務同級,成本卻是自己可控的。

人力配置的真實答案:一套自建推論 API 的日常維運,由一位後端工程師兼任就夠,前提是監控與告警已經自動化;需要專注投入的是前兩個月的建置與調校期。很多團隊卡在「我們沒有 AI 工程師」的心理門檻,實際上推論服務的維運技能跟一般後端服務八成重疊,缺的那兩成——顯存邏輯與引擎參數——一週可以補起來,或者選一家願意陪你調參數的主機商,把學習曲線再砍一半。

找台灣在地的 GPU 主機夥伴

推論 API 的規格會隨產品成長而演進:從單卡 POC、雙卡生產,到多副本高可用。戰國策 GPU 主機提供 NVIDIA H100 與 RTX 系列多種配置,台灣機房、使用者資料不出境,月租 NT$15,000 起,7×24 中文技術支援,擴容時可平滑升級不中斷服務。方案細節見 戰國策 GPU 主機,或加 LINE @119m、撥免費專線 0800-003-191,顧問可依你的併發與延遲目標試算最省的配置。

常見問題 FAQ

自建推論 API 和呼叫商用 API,成本怎麼比?

商用 API 按 token 計費,量小便宜;月呼叫量到百萬次後,帳單常達 NT$80,000-200,000。自建是固定月租:雙 4090 主機約 NT$35,000、H100 約 NT$60,000-80,000,用量再大也不變。月 API 費穩定超過自建月租 1.5 倍,就該評估切換。

TTFT 和 token/s 是什麼?目標值該設多少?

TTFT 是送出請求到第一個字出現的時間,對話產品建議 p95 壓在 1.5-2 秒內;token/s 是後續生成速度,單人閱讀 20 token/s 以上就流暢,程式生成建議 40 以上。兩者都要在「尖峰併發」下量測才有意義,單人測試的數字不能當 SLA。

一張 RTX 4090 能撐多少併發?

以 7B FP16 加 vLLM 估:權重 14-16GB,剩 8-10GB 給 KV cache,每路 4K context 約 0.5-1GB,尖峰 10-20 路併發可維持每路 20 token/s。32B INT4 權重占 18-20GB,單卡空間有限,併發壓在 5-8 路或改雙卡。

vLLM 為什麼比一般部署快這麼多?

兩個機制:PagedAttention 把 KV cache 分頁管理,顯存利用率從常見的 20-40% 拉到 90% 以上;continuous batching 讓不同請求的生成步驟交錯執行,GPU 不再等最慢的請求。合計效果是同卡吞吐提升 5-10 倍,等於直接省下 5-10 倍的硬體租金。

KV cache 到底要預留多少顯存?

粗略公式:每路併發、每 4K token 的 context,依模型抓 0.5-2GB(GQA 架構的新模型較省)。例如 15 路併發、平均 4K context,預留 8-30GB。實務建議:總顯存 = 權重 + KV cache 估算 + 15-20% 餘裕,上線後再用實測數據修正。

自建 API 的延遲可以比商用 API 低嗎?

可以,而且低很多。台灣用戶呼叫海外 API,光網路往返就 60-150ms,加上排隊常見 p95 兩三秒;自建在台灣機房,網路往返 5ms 上下,搭配合理併發配置,p95 TTFT 壓在 1 秒上下是常態。對即時互動型產品,這是體感等級的差距。

怎麼做到服務不中斷的模型更新?

標準做法是藍綠部署:新模型先在第二個服務副本載入並通過煙霧測試,負載均衡器再把流量切過去,舊副本觀察 24-48 小時後下線。單卡預算做不了雙副本時,選離峰時段換模型,vLLM 重載一個 14B 模型約 3-8 分鐘,公告維護窗口即可。

需要準備 fallback 機制嗎?怎麼設計?

建議要。常見設計:自建端點健康檢查連續失敗 3 次,閘道自動把流量切到商用 API 或備用副本,並發告警。fallback 的月成本通常不到 NT$1,000(因為 99% 流量走自建),卻能把服務可用率從單機的 99% 拉到 99.9% 以上,對外服務尤其必要。

推論 API 的資安要注意什麼?

最少四件:API key 發放與輪替、請求與回應日誌(留存供稽核,注意個資遮罩)、輸入輸出的敏感內容過濾、以及網路層的 IP 白名單或 VPN。自建的意義是資料不出境,但機房內的存取控制與日誌若沒做,稽核一樣過不了,第一天就要納入架構。

從零開始自建,合理的時程是多久?

有經驗的團隊:第 1 週選型與 POC(Ollama 加內部測試),第 2-3 週建生產環境(vLLM、監控、日誌、fallback),第 4-6 週試營運與壓測,共 4-6 週。沒有 GPU 維運經驗的話,選有 7×24 中文支援的台灣主機商可以把前期環境問題的處理時間砍掉一半以上。

💡 快速答案:商用部署 Stable Diffusion 需要什麼 GPU、出圖速度多快?

SD 1.5 只要 4-6GB 顯存,SDXL 建議 10-12GB,SD3.5 與 FLUX.1 要 16-24GB,一張 RTX 4090 通吃。4090 出一張 1024 的 SDXL 圖約 4-6 秒,批次月產能 15 萬張以上。台灣機房單卡月租約 NT$15,000-25,000,商用前務必逐版本確認授權。

生成式 AI 的討論度都被 LLM 占走了,但真正在台灣企業裡默默賺錢的,常常是圖像生成。電商去背改景、廣告素材 A/B 量產、遊戲美術概念圖、產品打樣視覺——這些工作流一旦導入 Stable Diffusion 系列模型,產能是用「倍」在算的。不過商用部署跟玩家在自己電腦上跑圖是兩回事:顯存要抓多少、出圖速度怎麼估產能、授權條款哪些版本能商用、服務怎麼撐住多人同時用,每一題都有具體答案。這篇指南一次講完。

先盤點場景:你要的是「快」還是「多」

商用圖像生成的需求分兩型。互動型:設計師在工作流裡即時生圖改圖,重點是單張延遲,最好 10 秒內出圖,不然創作節奏會斷;批次型:半夜排程量產上千張商品圖或素材變體,重點是每小時吞吐與單張成本,延遲無所謂。兩型的 GPU 配置邏輯不同——互動型值得上單卡效能最強的卡,批次型看的是「每萬張成本」,有時兩張中階卡比一張旗艦卡划算。訓練自家風格模型(LoRA)又是第三種負載,吃的資源結構不一樣,可參考 訓練與推理的 GPU 配置邏輯。

開需求會議時,把三個問題先問清楚,規格自然浮現:每月要產多少張、誰在什麼流程裡用(設計師即時創作還是系統自動批次)、素材與成品的保密等級。第三題常被跳過,卻最關鍵——未上市商品照、客戶提供的原始素材,一旦流進境外生圖服務,合約上的保密條款就破了。這也是為什麼台灣的電商、遊戲與代理商,這兩年紛紛把出圖工作流搬回自建或租用的在地主機。

台灣市場的需求輪廓大致是:電商與代營運要商品情境圖量產,遊戲與 IP 產業要概念圖與宣傳素材,製造業拿它做產品外觀提案與型錄視覺,行銷代理商則是廣告素材的 A/B 變體海量測試。共通點是量大、風格要穩、交期以天計——正好是自建 GPU 產線最擅長的三件事,也是按張計費的境外服務最貴的三件事。

模型版本與顯存需求:從 SD 1.5 到 FLUX

2026 年還在商用戰場上的主力模型,顯存需求差距很大。SD 1.5 最老但生態最肥,512×512 原生解析度,推論只要 4-6GB,大量現成 LoRA 與 ControlNet 可用,適合量產小圖與風格固定的素材線。SDXL 是目前商用主流,1024×1024 原生解析度,推論建議 10-12GB,畫質與提示詞理解力都上一個檔次。SD 3.5 Large(8B 參數)與 FLUX.1(12B 參數)是畫質天花板,文字渲染與人手細節明顯進步,但 FP16 推論要 16-24GB,加上 ControlNet 或高解析修復流程,24GB 卡會逼近上限,FP8 量化可壓回 12-16GB,畫質損失輕微。

經驗上的配卡建議:純 SD 1.5 產線用 12-16GB 卡就夠;SDXL 為主、偶爾跑 FLUX,一張 RTX 4090(24GB)是甜蜜點;FLUX 全流程加訓練 LoRA,直上 48GB 的 L40S 或 RTX 6000 Ada,省去顯存調度的所有麻煩。

選版本時別只看畫質,要看「生態資產」。SDXL 的社群累積最厚:上千個風格 checkpoint、數萬個 LoRA、成熟的 ControlNet 全家桶(姿勢、深度、線稿、佈局控制)與 IP-Adapter 參考圖機制,商用工作流需要的「可控性」幾乎都靠這些配件堆出來,而新模型的配件生態要再等半年到一年才會齊。這就是為什麼 2026 年的商業產線上,SDXL 仍然是主力、FLUX 負責高規格單張輸出的分工格局。

硬體配套也交代一下:模型 checkpoint 一個 2-7GB,加上 LoRA 庫與 ControlNet 權重,硬碟直接抓 1TB NVMe 起跳;系統記憶體 32-64GB,模型切換與批次排程時吃得兇;輸出圖的儲存與備份另外算,量產線一個月幾百 GB 很正常。這些配套在租用方案裡先確認清楚,比事後加購省事。

出圖速度對照:秒數背後是產能與成本

幾個讓數字更準的細節。步數影響線性:20 步的時間約是 30 步的三分之二,搭配 LCM/Turbo 類加速技術可壓到 4-8 步,速度翻好幾倍,適合先快速出草稿再精修的流程。高解析放大(upscale)與 ControlNet 每加一層,時間多 30-100%。還有排隊時間:多人共用時真正的體感延遲是「生成時間加排隊」,這就是下一節服務化要解的問題。用月產能回推,一張 4090 主機月租 NT$15,000-25,000,量產情境的單張成本不到 NT$0.2,跟按張計費的雲端生圖 API(單張約 NT$0.5-4)差距一個數量級。

還想再壓速度,加速堆疊照這個順序上:先確認 FP16 與高效注意力機制(新版框架多半預設開啟),再套 LCM 或 Turbo 類的少步數模型,最後才是 TensorRT 編譯——它能再快 30-50%,但每換一個模型或解析度都要重新編譯,適合模型固定的量產線,不適合天天換風格的創作環境。互動與批次的參數也不同:互動用 batch 1 求快,批次拉 batch 4-8 榨吞吐,同一張卡兩種設定的時薪產能差三成以上。

解析度是另一個常被低估的變數:同一張卡,SDXL 從 1024 拉到 1536 見方,時間接近翻倍;要 2048 以上的大圖,先出 1024 再走放大流程,品質更穩、總時間反而更短。至於負向提示詞與 CFG 這類參數,對速度影響輕微,放心按品質需求調,產能規劃時不用把它們算進變數。

商用授權地雷:每個版本規則都不一樣

技術選型前,先讓法務看授權,這是圖像生成商用化最常翻車的地方。SD 1.5 與 SDXL 用 CreativeML OpenRAIL 系授權,商用基本開放,但有禁止用途清單;SD 3.5 用 Stability AI 社群授權,年營收 100 萬美元以下企業可免費商用,超過要買企業授權;FLUX.1 要特別小心:schnell 版是 Apache 2.0 隨便用,dev 版是非商用授權,拿 dev 直接做商業服務就是違約,商用要走 BFL 的授權方案。

另外兩件事一起交代:生成內容的著作權在台灣現行實務下,純 AI 產出難以主張著作權保護,商業使用要靠人工參與創作與合約安排;訓練自家 LoRA 用的素材,確認你有權利使用,拿客戶圖庫訓練前先把授權條款寫進合約。這些功課做在前面,比出事後補救便宜太多。

管理上建議建一張「授權清冊」:表列每個在用的模型與 LoRA、授權類型、可否商用、來源連結與下載日期,新模型進產線前先過這張表。特別注意合併模型(merge)與微調衍生版——它們繼承原始模型的授權,拿非商用底模 merge 出來的東西照樣不能商用;社群下載的風格 LoRA 更是重災區,訓練素材來路不明的,商業案子直接避開。這張清冊花一天建立,能擋掉未來九成的授權糾紛。

再往前看一步:主要平台與廣告通路陸續要求 AI 生成內容標示,台灣的主管機關也在跟進研議。把「AI 生成、人工審核」的標示與紀錄機制先做進流程,產出的每張圖都留有模型版本與參數的中繼資料,未來法規落地時你只需要開個開關,而不是回頭補三個月的資料。

台灣案例:電商代營運的出圖農場

一家台北的電商代營運公司,替 40 多個品牌管商品頁,長期痛點是攝影棚產能:一檔活動要 300-500 張情境圖,外包攝影單張 NT$300-800、來回兩週。他們在台灣機房租了兩台 RTX 4090 主機(月租合計約 NT$40,000)建出圖農場:白天設計師用 ComfyUI 做互動創作與修圖,晚上跑批次——商品去背後套 SDXL 情境模板,自動生成不同場景、光線、節慶主題的變體,隔天早上人工挑圖。

三個月後的數字:每月產出約 6 萬張候選圖、採用約 4,500 張,單張採用成本從外包的數百元降到十位數;一檔活動的素材製作週期從兩週壓到三天。品牌客戶在意的資料問題也順帶解決——商品原始圖與未上市新品照全部留在台灣機房,不經過任何境外生圖服務,代營運合約裡的保密條款直接過關。機器在台灣還有個實際好處:傳輸大批 PSD 與成品圖走內網或國內頻寬,幾 GB 的檔案分鐘級搞定,不用跟跨海頻寬搏鬥。

他們的批次工作流值得拆開看:商品圖先自動去背與構圖對位,套用預先調好的 SDXL 情境模板(棚拍、居家、戶外、節慶四大類),ControlNet 鎖住商品輪廓避免變形,生成後自動跑一輪放大與色彩校正,再進人工挑圖。每個商品產 12 個變體、人工挑留 1-2 張,挑圖率穩定在一成上下——這個數字很重要,產能規劃時要用「候選張數」而不是「採用張數」去算 GPU 需求,兩者差了十倍。

服務化:讓一張卡服務一個部門

單機跑 ComfyUI 或 WebUI 是個人用法,商用部署要加三層。佇列層:用 Redis 或內建 queue 把請求排隊,尖峰時設計師看到的是「排隊中第 3 位」而不是逾時錯誤;API 層:把常用工作流(去背、換景、放大)固化成參數化 API,讓 PM 與行銷不碰節點圖也能出圖;資產層:模型、LoRA、工作流版本化管理,不然三個月後沒人知道哪個 checkpoint 配哪個 LoRA 才能重現當初的風格。這套 API 化的思路與 LLM 服務共通,可參考 AI 推論 API 自建教學。

容量規劃的粗略公式:一張 4090 跑 SDXL 約每分鐘 10-15 張,一個 10 人設計團隊的互動使用加上夜間批次,單卡通常夠;超過 20 人或有對外服務,再加卡做負載分流。從一張卡開始,用佇列長度數據決定何時擴充,比一次到位猜規格務實。

維運面把四件事自動化就很省心:任務失敗自動重試(顯存偶發不足、模型載入逾時是常客)、每日產能與佇列報表、輸出內容的安全過濾(商用環境必開,尤其是開放自由 prompt 的內部工具)、以及模型與工作流的版本備份。監控指標盯兩個就夠——平均單張生成時間(飆高代表有人塞了超大解析度或掛錯模型)與佇列等待 p95(超過一分鐘就是擴充訊號)。這套機制建好,一個設計部門的出圖農場,每週維運時間可以壓在兩小時內。

若農場要服務多個部門或多個客戶,再加一層簡單的配額管理:每個專案有月度張數配額與優先級,超額走申請流程。這不是官僚,是讓產能衝突浮上檯面的機制——沒有配額的共用農場,三個月後一定演變成先搶先贏,協調的隱形成本比寫這層邏輯高得多。

找台灣在地的 GPU 主機夥伴

圖像生成的商用部署,從單張 RTX 4090 的設計部門共用機,到多卡 H100 的量產農場,規格跨度很大。戰國策 GPU 主機提供 NVIDIA H100 與 RTX 系列多種配置,台灣機房、素材與商業資料不出境,月租 NT$15,000 起,7×24 中文技術支援,產能不夠隨時加卡。方案細節見 戰國策 GPU 主機,或加 LINE @119m、撥免費專線 0800-003-191,顧問可依你的出圖量與工作流建議配置。

常見問題 FAQ

跑 Stable Diffusion 最少需要多少顯存?

SD 1.5 推論 4-6GB 就能跑,SDXL 建議 10-12GB,SD 3.5 Large 與 FLUX.1 需要 16-24GB(FP8 量化可壓到 12-16GB)。商用環境建議直接配 24GB 的 RTX 4090:主流模型全部通吃,還留得下 ControlNet 與放大流程的空間。

RTX 4090 出一張圖要幾秒?

SDXL 1024×1024、30 步約 4-6 秒;SD 1.5 的 512 小圖 1-2 秒;FLUX.1 dev 20 步約 15-25 秒。搭配 LCM/Turbo 加速可把步數壓到 4-8 步,SDXL 能進到 2 秒內。批次量產時單卡每小時穩定產出 600-900 張 SDXL 圖。

哪些 Stable Diffusion 版本可以商用?

SD 1.5 與 SDXL 走 OpenRAIL 系授權,商用開放但有禁止用途;SD 3.5 對年營收 100 萬美元以下企業免費商用,超過需企業授權;FLUX.1 schnell 是 Apache 2.0 可自由商用,dev 版為非商用授權,商業服務必須另購授權。上線前務必逐版本核對。

商用出圖該自建 GPU 還是用生圖 API?

月出圖量是分水嶺。雲端 API 單張約 NT$0.5-4,月產一萬張就要 NT$5,000-40,000 且素材要上傳境外;自建單卡 4090 主機月租 NT$15,000-25,000,月產能 15 萬張以上,單張成本壓到 NT$0.2 以下。月量破萬張或素材敏感,自建幾乎必勝。

SDXL 和 FLUX 該選哪個?

量產與生態優先選 SDXL:速度快 3-5 倍、LoRA 與 ControlNet 資源最齊,商品圖情境圖綽綽有餘。文字渲染、手部細節、複雜構圖要求高的主視覺,才用 FLUX 或 SD 3.5。多數團隊的實務解是雙軌:SDXL 跑量、FLUX 出精稿,一張 24GB 卡就能切換。

一個 10 人設計團隊需要幾張卡?

通常一張 RTX 4090 就夠:互動使用尖峰約 3-5 人同時排隊,SDXL 每張 4-6 秒,佇列體感仍順;夜間再排批次任務把閒置時段用滿。建議先單卡上線、監控佇列長度,平均等待常態超過 30 秒再加第二張卡,擴充有數據依據。

訓練自己風格的 LoRA 需要什麼規格?

SDXL LoRA 用 20-100 張標註圖、24GB 顯存的卡訓練 1-3 小時就有可用結果;FLUX LoRA 建議 24-48GB 顯存、時間再多五成。重點反而在素材權利:訓練圖要有合法使用權,替客戶訓練品牌風格模型時,把素材授權與產出歸屬寫進合約。

出圖服務多人共用要怎麼架?

標準架構三層:ComfyUI 或 Diffusers 當生成核心,前面加佇列(Redis/RabbitMQ)吸收尖峰,再包一層參數化 API 讓非技術同事直接用固定工作流。搭配任務優先級(互動優先、批次讓路),單卡就能同時服務設計部門與夜間量產線。

生成的圖片著作權歸誰?可以商用嗎?

台灣現行實務上,無人類創作參與的純 AI 產出難以取得著作權保護;有實質人為創作(構圖指導、後製合成)的成品較有主張空間。商用本身可行,但建議以合約約定產出的使用權歸屬,並保留創作過程紀錄,以降低爭議風險。

顯存不足會發生什麼事?怎麼緩解?

輕則自動切到 CPU/RAM 分流讓速度掉 5-10 倍,重則直接 OOM 中斷任務。緩解手段依序:改用 FP8/半精度、降批次數、關閉不必要的 ControlNet、用 tiled VAE 分塊處理高解析圖。若每天都在用這些手段,就是該升 48GB 卡的訊號。

💡 快速答案:DeepSeek R1 各版本分別需要什麼 GPU 才能跑?

蒸餾版 7B/8B 需 14-16GB 顯存,一張 RTX 4090 可跑;32B 的 INT4 量化約 18-20GB、FP16 要 64-70GB;70B 要 140-150GB,建議雙 H100。滿血 671B 是 MoE 架構,FP8 需 700GB 以上、8×H200 等級。多數企業從 32B 蒸餾版起手。

DeepSeek R1 在 2025 年初用一紙 MIT 授權和逼近閉源旗艦的推理能力,把「企業自建 AI」的門檻直接砍了一截。一年多過去,它仍是台灣企業私有部署詢問度最高的模型家族——但也是版本誤會最多的一個。很多人以為自己要部署的是「那個 671B 的 DeepSeek」,實際上多數場景該用的是 7B 到 70B 的蒸餾版,兩者的硬體需求差了一個數量級,月租差距可以從一萬五到七位數。這篇把每個版本的 GPU 需求、實測速度、適用場景一次對照清楚,再給出台灣企業的選版決策路徑,幫你把預算花在真正需要的推理能力上。

R1 為什麼紅:推理模型加 MIT 授權

R1 屬於推理模型(reasoning model):回答前會先生成一長段思考鏈,把問題拆解、驗算、自我修正,再給出答案。這讓它在數學、程式、邏輯分析、複雜文件比對這類任務上,表現遠超同尺寸的一般指令模型。對企業更關鍵的是授權:MIT 授權幾乎沒有商用限制,可以改、可以蒸餾、可以包進產品賣,法務審查的阻力比社群授權的模型小得多。

代價也要先講明:思考鏈是用 token 買來的。同一個問題,一般模型 300 字收工,R1 可能先「想」2,000 到 8,000 個 token 才開始回答,輸出總量常是 3-10 倍,回應時間以十秒到分鐘計,KV cache 的顯存占用也跟著暴增。簡單的分類、摘要、格式轉換用 R1 是浪費——更慢、更貴、還不見得更準;R1 的主場是「答錯成本很高、值得讓它想久一點」的題目:合約條款衝突檢查、財務數字勾稽、程式除錯、多條件的方案評估。

務實的部署形態因此很清楚:R1 幾乎不會是企業唯一的模型,而是跟一般指令模型並排,由應用層按任務路由——日常雜務走快的,難題走 R1。這個「雙模型」前提會影響你後面每一個規格決策。

判斷哪些任務值得導到 R1,有個很土但有效的方法:把過去三個月人工修改率最高的十類任務攤開,圈出「錯了會賠錢」的那幾類——對帳異常分析、報價條件檢核、程式碼審查、合約風險標記。以一家導入過的公司為例,R1 只接手全系統 15% 的流量,卻消化掉了返工與客訴成本的大宗;剩下 85% 的摘要翻譯雜務,繼續讓一般模型用三分之一的成本跑。

版本釐清:滿血 671B 與蒸餾版是兩回事

DeepSeek R1 本尊是 671B 參數的 MoE(混合專家)模型。MoE 的特性是每次推論只「啟用」約 37B 參數,計算量像個中型模型,但路由器隨時可能點名任何一組專家,所以全部 671B 的權重都得待在顯存裡——這就是為什麼它計算不算太重、顯存需求卻是怪獸級:FP8 精度下要 700GB 以上,屬於 8×H200 單機或雙節點 8×H100 的世界。

官方同步釋出了一整排蒸餾版:以 Qwen 為底的 1.5B、7B、14B、32B,和以 Llama 為底的 8B、70B,用 R1 生成的推理資料訓練,學到了思考鏈的行為模式,能力隨尺寸遞減。底模血統有實務意義:Qwen 底的版本中文表現通常較穩,Llama 底的英文生態工具較齊,做繁中應用的台灣企業多半從 Qwen 底的 14B 或 32B 開始測。

坊間常見的誤解是「蒸餾版是閹割品,沒有價值」。實測結論恰好相反:32B 蒸餾版在多數企業推理任務上已能交付可用的品質,而部署成本只要滿血版的二十分之一。務實的問法不是「要不要上 671B」,而是「32B 夠不夠、什麼題目才值得升 70B」。

下載時的命名陷阱也提醒一下:模型倉庫上叫 DeepSeek-R1 的是 671B 本尊,蒸餾版的全名是 DeepSeek-R1-Distill-Qwen-32B 這種格式,少看一眼就會下錯檔案;社群還流通大量第三方微調與量化變體,品質參差不齊。企業部署建議認官方帳號的權重,量化版挑下載量大、附評測數據的來源,並把檔案雜湊值記進部署文件,日後出現怪行為才有辦法追查到底是模型的問題還是自己的問題。

GPU 需求對照表:1.5B 到 671B

表中速度是單使用者連續生成的區間值,實際會隨推論引擎、context 長度與量化方式浮動。另外提醒:R1 系列因為思考鏈很長,顯存要在權重之外多留 20-40% 給 KV cache,尤其是 32B 以上搭配 8K-32K context 的場景,這筆帳漏算是部署後 OOM(顯存不足)的頭號原因。

量化格式的選擇也交代一下:走 vLLM 生產部署,選 AWQ 或 GPTQ 的 4-bit 版本,吞吐與相容性最好;用 Ollama 快速起步,抓 GGUF 格式的 Q4_K_M 等級即可,品質與體積的平衡點很成熟。同一個 32B,不同量化等級的顯存可以差出 5GB 以上,下載前先看清楚檔名後綴,別拿 Q8 的檔案塞 24GB 的卡。

context 長度對顯存的影響值得單獨講:同樣是 32B INT4,限制 8K context 的服務跟開放 32K 的服務,KV cache 預算差了四倍。文件分析型應用——把整份合約或規格書丟進去那種——幾乎都要 16K 起跳,這時單卡 24GB 就不夠看了,直接規劃 48GB 卡或雙卡配置,省得上線一週就被顯存不足的警報追著跑。

部署實測筆記:三種常見配置的真實表現

我們在台灣機房實際部署過的三種典型配置,數字給你參考。配置一:單張 RTX 4090 跑 32B 的 INT4 量化版(AWQ),Ollama 起服務,單流輸出 25-35 token/s,一題需要完整思考鏈的分析題約 40-90 秒跑完,適合 10-30 人的內部使用。配置二:單張 H100 80GB 跑 32B FP16 配 vLLM,單流 40-55 token/s,continuous batching 下同時服務 15-20 路併發仍能維持每路 20 token/s 以上,適合百人級企業或對外服務。

配置三:雙 4090 跑 70B INT4,張量平行切兩卡,單流 15-22 token/s。品質上,70B 對 32B 的優勢集中在長鏈推理與艱深領域題,一般企業問答的盲測勝率差距約一成;但速度慢了四成,月租多一倍。這也是為什麼我們最常給的建議是:32B 起手,用你自己的題目測,證明不夠再升級。

兩個實測才會知道的細節。TTFT(第一個字出現的時間)在 R1 上要重新理解:如果你把思考鏈隱藏、只給最終答案,使用者會盯著空白畫面等一兩分鐘,體驗極差——建議至少顯示「思考中」的進度或摘要。還有思考長度的長尾:同一個模型,九成題目 2,000 token 內想完,偶爾一題會想到 10,000 token 以上,不設上限的話,尖峰時段一題就能拖垮整條佇列,上線前一定要配 token 預算與逾時截斷。完整的模型挑選方法論可以參考 私有 LLM 部署完整攻略。

上線前的壓測劇本照抄即可:用歷史真題組一個 100 題的混合集,短題七成、長題三成,以目標併發數灌進去跑半小時,記錄 p50/p95 延遲、總吞吐與截斷率;再故意塞進三題已知會想很久的難題,確認佇列調度不會被單題塞死。這套流程一個下午跑得完,能提前抓出九成的容量問題,比上線後被使用者抓到便宜太多。

台灣企業怎麼選:法遵是加分題,任務是必考題

R1 對台灣企業還有一層現實意義:它讓「資料不出境的高階推理能力」變成可負擔的選項。金融業要分析內部審計報告、製造業要比對製程異常紀錄、律所要跑合約條款審閱——這些資料按個資法與各行業主管機關的要求,出境都是麻煩事,而 R1 蒸餾版讓這類任務可以完全在台灣機房內完成,MIT 授權也讓法務不用再為商用條款開好幾輪會。

一家新竹的 IC 設計服務公司是很典型的樣板:他們用單張 H100 跑 32B 蒸餾版,做內部技術文件的推理問答與規格衝突檢查,規格書與客戶資料全程不落地到任何境外服務,法遵審查兩週過件。導入時他們拿 50 題歷史案例盲測,32B 在「找出兩版規格書的矛盾點」這類題目的命中率約八成五,資深工程師的平均審閱時間從 50 分鐘降到 15 分鐘——剩下的一成五漏網,由人工複核補上,人機分工反而比全自動更受工程師信任。

金融場景再給一個輪廓:某投顧團隊把 32B 蒸餾版接進晨會流程,清晨自動比對前一日的公告與研究底稿,標記數字不一致或說法矛盾的段落,供研究員開盤前複核。跑在單張 H100 上,每天處理約 300 份文件,負載尖峰集中在清晨 6 到 8 點,其餘時段這張卡就轉去服務一般的內部問答——推理模型與指令模型共用硬體、分時排程,是把 H100 月租攤薄的標準做法,值得直接抄進你的架構。

選版的決策樹很短:預算單卡 24GB 以內,選 7B/8B 做輔助性任務;要正經的推理品質,32B INT4 是性價比之王;唯有當你用 50 題實際業務題盲測、確認 32B 明顯不夠,才考慮 70B;至於滿血 671B,除非你要對外提供旗艦級 AI 服務或做模型研究,否則多數企業碰不到需要它的那一天。

從模型到服務:上線前的最後三關

選好版本只是一半,R1 上線還有三個特有的坑。思考鏈的顯示策略:內部工具可以顯示完整推理過程輔助查核,對外服務通常隱藏、只回最終答案,兩者的 token 成本與體驗設計差好幾倍,要在產品設計時就決定。context 與併發的預算:R1 一題思考動輒數千 token,32B FP16 每路 4K context 的 KV cache 約再吃 1-2GB,併發數要按這個帳去乘。超時與截斷機制:給思考鏈設 token 上限(常見 4K-8K)與逾時保護,避免個別難題把整個服務卡死。

監控也要為推理模型調整:除了常規的延遲與吞吐,多看兩個指標——平均思考 token 數(突然變長常代表題型漂移或 prompt 被改壞)與截斷率(超過 5% 就該檢討上限設定或題目分流)。搭配每月一次的答案品質抽查,R1 服務才能長期穩定。版本更新也要守紀律:新版蒸餾模型先進影子環境跑一週,對同一批題目比較思考長度與答案品質,確認沒有回歸再切流量;思考鏈行為對系統提示詞極度敏感,任何一行改動都要走同一套回歸,別讓小改動把平均思考長度翻倍,延遲跟成本一起爆炸。這些服務化細節——OpenAI 相容 API、批次策略、告警設計——的完整做法,見 AI 推論 API 自建教學。把這三關過完,R1 才算真正從「跑得動」變成「用得住」。

找台灣在地的 GPU 主機夥伴

部署 R1 蒸餾版,從單張 RTX 4090 跑 32B INT4,到雙 H100 跑 70B FP16,規格彈性很大。戰國策 GPU 主機提供 NVIDIA H100 與 RTX 系列多種配置,台灣機房、資料不出境,月租 NT$15,000 起,7×24 中文技術支援,可以先租單卡驗證、確認版本後再升級。方案細節見 戰國策 GPU 主機,或加 LINE @119m、撥免費專線 0800-003-191,顧問會依你的任務類型建議 R1 版本與對應規格。

常見問題 FAQ

DeepSeek R1 滿血版和蒸餾版差在哪?

滿血版是 671B 的 MoE 模型,推理能力最強,但 FP8 就要 700GB 以上顯存,屬於 8×H200 等級的部署;蒸餾版是把 R1 的推理風格訓進 Qwen/Llama 底模,有 1.5B 到 70B 六個尺寸,一張 RTX 4090 就能起步。多數企業任務用 32B 蒸餾版已可交付。

一張 RTX 4090 可以跑哪個版本的 R1?

24GB 可跑:7B/8B 的 FP16 版(14-16GB)、14B 的 INT4 版(9-11GB)、32B 的 INT4 版(18-20GB,較緊)。跑 32B 時建議把 context 控制在 8K 內,留足 KV cache 空間,單流速度約 25-35 token/s,內部使用夠流暢。

部署滿血 671B 需要什麼等級的硬體?

FP8 精度需要 700GB 以上顯存,對應 8×H200(1,128GB)單機,或雙節點 8×H100 加高速互連;INT4 量化可壓到 350-400GB,單機 8×H100(640GB)勉強可行。這是月租七位數的等級,建議先確認 32B/70B 蒸餾版真的不敷使用再評估。

R1 是推理模型,和一般 LLM 用起來差在哪?

R1 回答前會先輸出思考鏈,自我拆解與驗算,數學、程式、邏輯題的正確率明顯高於同尺寸一般模型;代價是輸出 token 常多 3-10 倍、回應時間以十秒計。簡單的摘要分類任務用一般模型更划算,R1 適合答錯成本高的分析型任務。

R1 蒸餾版的實際生成速度多快?

單使用者:7B 在 4090 上約 60-100 token/s,32B INT4 約 25-35,H100 跑 32B FP16 約 40-55,70B INT4 雙 4090 約 15-22。加上思考鏈長度,一題完整推理常需 30 秒到 2 分鐘,設計使用者體驗時要把等待時間納入。

為什麼說 32B 是企業部署的甜蜜點?

32B 蒸餾版的推理品質已足夠處理多數企業分析任務,INT4 量化後 18-20GB 顯存讓單張 24GB 卡就能服務,月租成本約 NT$15,000-25,000;升到 70B 品質提升約一成,成本卻翻倍。先用 32B 搭配自家題庫實測,確認不足再升級,是最省錢的路徑。

R1 的 KV cache 為什麼特別吃顯存?

思考鏈讓每次生成的 token 數暴增,context 累積得比一般模型快。以 32B FP16 為例,每路 4K context 的 KV cache 約 1-2GB,10 路併發就要再多 10-20GB。部署時顯存要在權重外預留 20-40%,並給思考鏈設 4K-8K 的 token 上限。

R1 可以商用嗎?授權有什麼限制?

R1 與其蒸餾版採 MIT 授權,可商用、可修改、可再散布,幾乎沒有附帶條件,是目前主流開源模型中授權最寬鬆的之一。注意蒸餾版的底模授權仍要一併確認:Qwen 底的多為 Apache 2.0,Llama 底的要遵循 Meta 社群授權條款。

用 R1 做繁體中文任務,表現如何?

R1 系列的中文能力整體優秀,繁中輸出偶有簡繁混用,可用系統提示詞強制繁體並搭配後處理修正,實務上處理後的繁中可用率在 95% 以上。對用字精確度要求極高的場景(法律、公文),建議在評測集加入用字檢查項目再決定版本。

從下載模型到上線服務,大概要多久?

單卡跑蒸餾版的話很快:權重下載數十 GB 約半天,Ollama 或 vLLM 起服務 1-2 小時,加上內部評測與提示詞調校,一週內可完成 POC。正式上線含權限、日誌與監控,常見時程是 3-6 週。滿血版因涉及多卡多節點調校,要另抓 2-4 週。

💡 快速答案:什麼時候一台 GPU 主機不夠用、需要多節點分散式訓練?

單台 8×H100 約有 640GB 顯存,70B 的 LoRA 微調、32B 以下全參數微調都夠;要全參數訓練 70B(需 700GB 以上)或做預訓練才須跨節點。關鍵不是卡數而是網路:節點間至少 100Gbps 的 InfiniBand 或 RoCE,否則通訊等待會吃掉 30-40% 算力,加卡不加速。

「一張 GPU 不夠,那我多租幾台主機串起來就好了吧?」這句話對了一半。多節點分散式訓練確實是大模型時代的標準解法,但它不是把主機疊起來就會變快的魔法:節點之間的網路頻寬、平行策略的選擇、故障恢復的機制,任何一環沒做對,你花三倍的錢可能只換到 1.5 倍的速度。這篇入門文把「什麼時候真的需要多節點」講清楚,再用白話拆解幾種平行策略與網路需求,並用一個台灣新創的實際訓練專案示範怎麼把叢集用在刀口上。看完的目標很務實:讓你在對的時間點做對的擴充決策,而不是提早半年付叢集的錢。

先算清楚:一台主機的天花板在哪

2026 年的主流訓練主機是單機 8 卡:8×H100 80GB 共 640GB 顯存,或 8×H200 141GB 共 1,128GB。這個容量能做什麼?以 FP16 混合精度、AdamW 優化器估算,全參數微調的顯存需求約是模型權重的 8-10 倍:7B 需要 110-140GB,單機輕鬆;32B 約 500GB,單機 8×H100 緊繃但可行;70B 需要 700GB 以上,單機 H100 裝不下,這就是第一道跨節點的門檻。

把 70B 的帳攤開看會更有感:FP16 權重 140GB、梯度再 140GB、AdamW 優化器狀態(FP32)約 560GB,合計 840GB 還沒算激活值——就算開滿 gradient checkpointing 與 ZeRO 分片,640GB 的單機也是塞不進去的,這不是調參數能解的問題,是物理限制。反過來說,8×H200 的 1,128GB 單機就能硬扛,所以「要不要跨節點」有時候也是「要不要換更大單機」的選擇題,兩個方案都該拿來報價比較。

換成 LoRA 這類參數高效微調,帳完全不同:70B 的 LoRA 只要 150-190GB,兩三張 H100 就夠,根本不用跨節點。所以判斷的順序應該是:先確認你的訓練方式(全參數還是 LoRA)、模型規模與資料量,再回頭看單機夠不夠。訓練與推論的顯存邏輯差異,可以參考 訓練與推理的 GPU 配置邏輯。

除了「放不放得下」,另一個天花板是「跑不跑得完」。訓練時間大致與「資料 token 數乘以模型參數量」成正比:同樣 300 億 token 的語料,14B 模型用單機 8×H100 要跑一個多月,16 卡叢集能壓進三週;若是 70B,單機就算塞得下也要跑上季度等級,商業上根本等不起。所以多節點的第二個理由是時程——當「慢慢跑」的時間成本超過「租叢集」的價差,跨節點就從奢侈品變成必需品,這筆帳要拿專案死線來算,不是拿硬體價格算。

四種平行策略,白話拆解

資料平行(Data Parallel)最直觀:每張卡放一份完整模型,各吃不同批次的資料,反向傳播後同步梯度。前提是單卡放得下整個模型,所以它解決的是「訓練太慢」而不是「模型太大」。ZeRO 與 FSDP 是資料平行的進化版,把優化器狀態、梯度、甚至權重切碎分散到各卡,讓每卡只保管一部分,單卡顯存需求大幅下降,是目前中型規模訓練的主力。

張量平行(Tensor Parallel)把單一層的矩陣運算切開,由多張卡合力算一層,通訊極度頻繁,基本上只能在有 NVLink 的同一台主機內做。管線平行(Pipeline Parallel)則把模型按層切段,前幾層放節點一、後幾層放節點二,像工廠流水線。真正的大規模訓練是三者混用:節點內張量平行、節點間管線加資料平行。

對號入座的口訣:模型放得下單卡、只嫌慢——用資料平行;模型放不下單卡、但單機多卡總量夠——ZeRO/FSDP 或張量平行;單機總量都不夠——管線平行加資料平行跨節點。好消息是你不需要手刻這些,DeepSpeed、Megatron-LM、PyTorch FSDP 都把策略包好了,設定檔幾行就能切換;壞消息是框架不會幫你判斷哪種組合適合你的模型與網路,這個功課還是得自己做,而且選錯組合的代價是以「天」計的訓練時間。

ZeRO 的三個階段也值得認識一下,因為它是最多人實際用到的:stage 1 只切優化器狀態,通訊負擔最小;stage 2 加切梯度;stage 3 連權重都切,單卡顯存壓到最低、通訊也最重。實務上的起手式是 stage 2 配 gradient checkpointing,不夠再上 stage 3;另有 offload 選項能把狀態丟到 CPU 記憶體換更多空間,速度會再掉兩三成,適合「就差一點點塞不下」的邊界情況。

網路才是主角:頻寬決定加卡有沒有意義

多節點訓練的成敗,八成取決於節點之間的網路。看幾個數量級就懂:單機內 NVLink 的卡對卡頻寬約 900GB/s,PCIe 5.0 x16 約 64GB/s,而一般企業機房的 10GbE 乙太網路換算只有 1.25GB/s——差了七百倍。梯度同步是每一步訓練都要做的事,若網路太慢,GPU 會有 30-40% 甚至更多時間在等資料,你付的是 8 卡的錢,拿到 5 卡的效能。

具體算一次你就不會再懷疑這件事:70B 模型的 FP16 梯度一份 140GB,資料平行每一步都要做全體同步(all-reduce 的實際傳輸量約是梯度量的兩倍),在 10GbE 上光傳輸就要上百秒,而一步的計算時間可能只有幾秒——網路慢到這種程度,加節點是負優化。換成 100Gbps(12.5GB/s)的 RDMA 網路,加上 NCCL 的通訊與計算重疊技術,同步時間能壓到與計算時間同級,叢集才開始「像一台機器」。

所以跨節點訓練的入場標準是:節點間至少 100Gbps 的 InfiniBand 或 RoCE,大型叢集普遍上到 400Gbps。搭配得當,2-4 節點的擴展效率(scaling efficiency)可以維持在 85-95%;用普通乙太網路硬跑,效率常掉到 50-70%,等於加一倍的卡只快三四成。租用多節點方案時,「節點間網路規格」這一行比 GPU 型號更值得追問。另外別忘了儲存:多節點要共享資料集與檢查點,NVMe 等級的共享儲存與夠粗的儲存網路,不然資料載入會變成新瓶頸,GPU 利用率照樣上不去。

進場前的驗收動作很簡單:拿 nccl-tests 跑一輪 all-reduce 頻寬測試,實測值應該到標稱頻寬的八成以上;再跑一小時的迷你訓練,盯著 GPU 利用率——健康的叢集應該穩定在 90% 以上,若在 60-70% 之間鋸齒狀跳動,九成是通訊或資料載入在拖後腿。這兩個測試合計半天,能把「租了才發現不對」的風險擋在簽約之前,正規的主機商都願意配合你做。

什麼規模需要幾個節點:對照表

表格透露的重點:絕大多數企業微調需求停在「單機多卡」就能解決,真正需要跨節點的,是全參數訓練 70B 以上、或做持續預訓練(continual pre-training)注入大量領域語料的團隊。一個常見的規劃錯誤是「預算不夠就把節點切小」——用四台 2 卡機組叢集,不如一台 8 卡機:節點越多、跨網路的通訊占比越高,小節點叢集的效率天生吃虧。同樣預算永遠優先把單節點餵滿,再考慮加節點。表中的顯存估算已含優化器狀態,但激活值依 batch 與序列長度浮動,實際規劃再留一到兩成緩衝會安全得多。

台灣案例:新創訓練 14B 繁中領域模型

一家台北的 AI 新創要做金融領域的繁中模型:以開源 14B 底模做持續預訓練,語料 300 億 token,涵蓋公開財報、法規與新聞。他們評估過三條路:買 8 卡機(資本支出 NT$1,500 萬起、交期兩三個月)、海外雲(H100 每卡時 US$2.5-6,整案含實驗估 NT$250-400 萬,資料還要出境)、以及台灣機房租用 2 節點 16×H100 加 200Gbps InfiniBand 的方案,最後走第三條。

執行分兩階段:第一階段用單節點跑 1B 小模型,把資料管線、tokenizer、評測、檢查點機制全部驗證一遍,兩週;第二階段 16 卡全開跑 14B 主訓練,21 天完成,scaling efficiency 實測 91%。過程中不是沒出事——第 9 天一張卡 ECC 錯誤觸發中斷,因為每 30 分鐘存一次檢查點到共享儲存,重啟後只損失了 20 分鐘進度;這種「一定會發生的故障」,正是前兩週把續訓機制跑順的價值所在。

語料工程也占了整案三分之一的工時:300 億 token 的原始資料先過去重與品質過濾,砍掉近四成;再依「領域語料七成、通用語料三成」的配比混合,避免模型學了金融卻忘了普通話;每一批資料都留了 1% 做驗證集,訓練途中每天看一次 loss 與下游任務分數,發現異常能立刻定位是哪一批資料的問題。他們的心得很直接:多節點訓練燒錢的速度是每小時計的,資料沒準備好之前,一分鐘叢集都不要開。

成本這樣拆:叢集租期三個月(含前置與緩衝)控制在七位數初,大約是自購方案的六分之一,而且訓練結束就退租,不用養一台每年折舊六位數的鐵。對台灣團隊還有一個實際的點:凌晨三點的 NCCL 通訊錯誤,打電話有中文工程師一起查,不用等美西時區上班——多節點訓練的除錯常常是「環境問題」而不是「程式問題」,在地支援的價值在這種時刻最明顯。

還沒到多節點的你,該做的三件事

看完如果你發現自己的需求其實是「微調 32B 以下」,恭喜,省下一大筆:一台單卡或雙卡主機就能開工,方法見 LLM 微調實戰。如果你在單機 8 卡的邊緣,先把三件事做滿再談擴充:開 gradient checkpointing 用兩三成的速度換 30-50% 顯存、用 ZeRO-3 或 FSDP 把狀態切碎、評估 LoRA 能不能取代全參數。三招用盡還是不夠,才進多節點。

真的要進場,依這個節奏走:從 2 節點開始,把 NCCL 參數、網卡綁定、檢查點續訓、故障重啟的 SOP 全部跑順,量到穩定的 scaling efficiency 之後,再決定要不要往 4 節點以上加。跳過這一步直接租大叢集的團隊,常常花一週的叢集租金在查一個網卡設定,那是全案最貴的學費。多節點訓練是能力,不是身分象徵;在對的時間點用對的規模,才是把每一塊 GPU 預算都花在算力而不是等待上。

排程上還有一個省錢技巧:訓練專案的叢集需求是脈衝式的——資料準備期用單卡機、主訓練期租滿、收尾評測期再縮回單卡。跟主機商把這條曲線講清楚,分階段租用,比整案期間全程掛著大叢集省 30-50%。台灣機房的另一個優勢在這裡:溝通成本低,規格調整常常一通電話當天生效,海外供應商光開工單來回就是兩三天。

找台灣在地的 GPU 主機夥伴

從單卡實驗機、單機 8 卡,到多節點訓練專案,戰國策 GPU 主機提供 NVIDIA H100 與 RTX 系列的彈性配置,台灣機房、資料不出境,月租 NT$15,000 起,7×24 中文技術支援,訓練型專案可以短租、用完即退。方案細節見 戰國策 GPU 主機,或加 LINE @119m、撥免費專線 0800-003-191,由顧問依你的模型規模與訓練排程試算節點數與網路規格。

常見問題 FAQ

什麼情況一定要用多節點訓練?

兩種:全參數訓練 70B 以上模型(顯存需求 700GB 起,超過單機 8×H100 的 640GB),或持續預訓練需要在合理時間內吃完數百億 token 語料。若只是 LoRA 微調,70B 也只要 150-190GB,單機 3-4 張 H100 就能解決,不必跨節點。

資料平行、張量平行、管線平行差在哪?

資料平行是每卡一份完整模型、分頭吃資料,解決「訓練太慢」;張量平行把單層運算切給多卡合算,解決「單層太大」,通訊量極高只適合 NVLink 內;管線平行把模型按層切段跨卡跨節點放,解決「模型太深」。大型訓練通常三者混用,由框架自動調度。

節點之間的網路要多快才夠?

跨節點訓練的入場標準是 100Gbps RDMA(InfiniBand 或 RoCE),大型叢集普遍用 400Gbps。對照組:10GbE 乙太網路只有 1.25GB/s,跑梯度同步會讓 GPU 閒置 30-40% 以上。租用前務必確認節點間網路規格,這行字比 GPU 型號更影響實際訓練速度。

scaling efficiency(擴展效率)多少算合格?

2-4 節點的健康值是 85-95%:意思是卡數翻倍、實際吞吐拿到 1.7-1.9 倍。若實測掉到 70% 以下,先查節點間頻寬、NCCL 拓撲設定與資料載入瓶頸。效率長期低於 75% 時,多租的節點等於在燒錢,不如先回單機把配置調順。

ZeRO 和 FSDP 是什麼?能省多少顯存?

兩者都是把優化器狀態、梯度、權重切碎分散到多卡的技術,ZeRO 來自 DeepSpeed,FSDP 是 PyTorch 原生版。以 ZeRO-3 全切為例,單卡顯存需求可降到接近「總需求除以卡數」,讓 8×80GB 有機會跑動 500GB 級的全參數訓練,代價是通訊量增加、速度慢 10-30%。

多節點訓練中途斷掉怎麼辦?

標準做法是週期性存檢查點(checkpoint):每 30-60 分鐘或每 N 步把權重與優化器狀態寫進共享儲存,故障後從最近檢查點續訓,損失控制在一小時內。檢查點檔案很大(70B 全狀態約 800GB 以上),儲存要配 NVMe 並預留 3-5 份的空間。

訓練 70B 模型大概要多少張 H100、多久?

全參數微調 70B、資料量 100 萬筆指令等級:常見配置是 2 節點 16×H100,訓練數天到兩週,視序列長度與 epoch 數而定。若改用 LoRA,單機 4×H100 數天內可完成,成本差 3-5 倍。先確認任務真的需要全參數,再上重裝備。

租多節點叢集,月費大概什麼量級?

台灣機房的行情,單機 8×H100 等級月租約在七位數上下浮動,2 節點翻倍,另計 InfiniBand 網路與儲存。好消息是訓練專案通常 1-3 個月結束,短租加用完即退,總成本常只有自購的 10-20%,還不用扛折舊與機房維運。

單機多卡和多節點,程式要改多少?

用 PyTorch FSDP、DeepSpeed 或 Accelerate 的話,單機到多節點主要是改啟動參數與環境設定(節點清單、NCCL 網卡綁定),訓練程式碼本身改動很小。真正花時間的是叢集除錯:網卡挑錯、防火牆擋掉通訊埠這類環境問題,佔了多數導入工時。

可以先在單機驗證,再擴到多節點嗎?

這是最推薦的路徑:先用單機小模型(如 1B-7B)把資料管線、評測、檢查點機制全部跑通,確認 loss 曲線健康,再原封不動放大到多節點。90% 的訓練問題在小規模就能暴露,單機驗證的幾天時間,能省下多節點階段數十萬的試錯機時。

💡 快速答案:企業要私有部署 LLM,該怎麼選模型和 GPU 規格?

依任務難度選模型:內部問答用 7B-14B,進階分析用 32B——INT4 量化後約 18-20GB 顯存,24GB 卡可跑;70B 需 140GB 以上、至少雙 H100。授權上 Qwen 是 Apache 2.0、DeepSeek 是 MIT 最單純。台灣機房單卡月租 NT$15,000 起,POC 兩到四週。

過去兩年,台灣企業對生成式 AI 的態度走了一個完整的弧線:從「先用 ChatGPT 試試」,到法務跳出來擋下所有把客戶資料貼進境外服務的行為,再到現在——「我們能不能自己架一套?」答案是可以,而且 2026 年的開源模型生態已經成熟到,多數企業任務用開放權重模型就能做到商用等級。這篇攻略把私有 LLM 部署的完整決策鏈走一遍:為什麼要私有化、模型怎麼挑、GPU 規格怎麼配、推論引擎怎麼選,以及一個台灣金融業的實際導入時程與成本。讀完你可以直接拿著這份清單跟主機商或內部團隊開需求會議,每一個環節都有可以驗證的數字。

三個回不去的理由:法遵、成本、延遲

企業選擇私有部署,理由通常不是情懷。第一個是資料主權與法遵:個資法對當事人資料的利用有明確界線,金管會對金融機構使用雲端服務另有委外規範,醫療則有醫療法與人體研究的資料限制。把病歷、對帳單、客訴紀錄送進境外 API,法遵部門要背的評估與舉證成本,常常比 GPU 還貴。私有部署把整條資料流關在自家或台灣機房內,稽核時一句「資料不出境」能省掉大半文書工作。

第二個是成本結構:API 按 token 計費,用量成長帳單跟著失控;自建是固定月租,量越大單位成本越低。一個內部工具從 50 人試用擴大到全公司 800 人,API 帳單會長 16 倍,自建主機可能只需要從單卡升級成雙卡。第三個是延遲與可控性:台灣機房內網往返 5ms 以內,海外 API 動輒 100ms 起跳,還要承受對方改版、限流、模型下架的風險——2025 年幾波商用模型無預警調價與版本汰換,讓不少把 LLM 綁進核心流程的公司吃過悶虧。當你的產品把 LLM 當成核心元件而不是玩具,這三點遲早會把你推向私有化。

要不要「全部」私有化則是另一題。務實的答案常是分流:敏感資料與高頻任務走私有模型,偶發的長尾雜務留在商用 API,兩邊用同一套 OpenAI 相容介面切換。這種混合架構讓你不必為了 5% 的特殊需求,把私有叢集規格拉到天上。

模型怎麼挑:授權先看,再看中文能力

2026 年可商用的開放權重模型主要三個家族。Qwen2.5 系列(0.5B 到 72B)多數尺寸採 Apache 2.0 授權,商用最乾淨,繁體中文能力在開源陣營裡屬第一梯隊,是台灣企業的預設起點。DeepSeek 系列採 MIT 授權,R1 推理模型與其蒸餾版(7B 到 70B)在數學、程式、多步推理任務上表現突出,各版本的顯存需求整理在 DeepSeek R1 GPU 需求對照。Llama 3.x 系列生態工具最完整,但用的是 Meta 社群授權,有月活躍用戶數等附帶條件,法務過件前要看清楚。

繁體中文有幾個實測才會浮現的細節:部分模型輸出會夾雜簡體字或中國用語(「軟件」「視頻」這類),對外文件不能接受,解法是系統提示詞強制台灣用語加後處理檢查,或直接挑繁中表現穩定的模型版本;金融與法律的專有名詞理解也要專門測,「附買回」「融資融券」這種詞彙,不同模型的表現差距很大。建議的做法是準備 50-100 題你自己領域的測題,拉兩三個候選模型做盲測,由業務單位而不是工程師評分。

挑尺寸的原則比挑家族簡單:內部問答、摘要、格式轉換,7B-14B 就夠;涉及多步推理、長文分析、程式生成,32B 是品質與成本的甜蜜點;70B 留給對答案品質錙銖必較的場景。別迷信參數量——盲測常常發現 14B 在你的任務上跟 32B 打平,一年省下的月租差價是六位數。另外記得看模型的「款式」:一般指令模型反應快、適合日常任務;推理模型(如 R1 系列)會先輸出思考過程,難題正確率高但 token 消耗數倍,兩種各架一個、按任務路由,是越來越主流的配置。

下載與供應鏈也別隨便:權重一律從官方 Hugging Face 帳號或可信鏡像取得,核對雜湊值並記錄版本;推論框架與相依套件鎖定版本,進了內網就不隨意更新。曾有企業從來路不明的鏡像抓了號稱加速版的權重,行為跟官方版有出入,查了兩週才找到源頭。私有部署的安全紅利,建立在你對每一個元件的來源都有掌握的前提上,這份清單值得放進資安檢核表。

GPU 規格對照:從 7B 到 70B 的顯存帳

三個規劃要點。量化是私有部署的好朋友:INT4 讓顯存需求砍半再砍半,主流任務的品質損失多在 2-3% 內,先上量化版、有預算再升 FP16 是務實路線。KV cache 要另外算:表中權重之外,每一路併發、每 4K token 的上下文,依模型會再吃 0.5-2GB,對外服務至少預留 30% 顯存。還有升級路徑:用支援張量平行的推論引擎,之後從單卡換雙卡、雙卡換 H100,服務層程式碼幾乎不用改。

用一個情境把 KV cache 講得更白:你部署 32B INT4(權重 20GB)在一張 24GB 卡上,單人使用一切正常;開放給 50 人後,尖峰 6 路併發、每路 8K 上下文,KV cache 需要 6-12GB,這張卡立刻爆。同一個模型,規格卻要看「誰在用、怎麼用」,這就是為什麼報規格前要先回答併發數與上下文長度兩個問題,而不是只報模型名字。長文件分析場景(動輒 32K 上下文)更要特別小心,單路的 KV cache 就可能吃掉 4-8GB。

推論引擎與服務化:從 Ollama 到 vLLM

模型下載下來只是權重檔,要變成服務還缺一層推論引擎。POC 階段用 Ollama 最快,一行指令拉起模型,適合給內部小規模試用;要上生產環境,vLLM 或 SGLang 才是正解——它們的 continuous batching 與 PagedAttention 能把同一張卡的吞吐拉高 5-10 倍,並提供 OpenAI 相容 API,前端應用只要改一行 base_url 就能從商用 API 無縫切換過來。

服務化的細節——延遲怎麼壓、併發怎麼估、要不要開多副本——是另一篇的主題,見 AI 推論 API 自建教學。這裡只強調一件最常被忘掉的事:私有部署不等於裸奔。API key 的發放與輪替、請求與回應日誌(含個資遮罩)、輸入輸出的敏感詞過濾、每月用量報表——這些治理機制要在第一天就做,不然「私有」只是把風險從供應商搬回自己家。金融業的稽核尤其會查日誌完整性與權限分離,補做的成本是先做的三倍起跳。

維運面給一個誠實的預期:私有 LLM 上線後的常態工作量,約是每週半天到一天——看監控、處理個案、每月演練一次故障重啟、每季評估一次新模型。這不需要專職團隊,但需要一個明確的負責人;完全沒有 Linux 維運能力的公司,建議把這層外包給主機商的託管服務,別讓系統變成沒人敢動的孤兒。

台灣案例:投信公司的內部文件助理

一家台北的投信公司,120 名員工,想讓研究員用自然語言查詢內部研究報告、公開說明書與法遵文件。資料屬性決定一切:這些文件不能離開公司控制範圍,金管會的雲端委外規範也讓境外 API 直接出局。他們的做法是在台灣機房租一台 H100 80GB 主機,跑 Qwen2.5-32B FP16 配 vLLM,前面接 RAG 檢索層,月租約 NT$70,000。

時程走得很典型:第 1-2 週用一張 4090 主機(月租 NT$18,000)做 POC,拿 80 題研究員實際會問的問題盲測 7B、14B、32B 三個尺寸,結論是 32B 在跨文件比對題上正確率高出 14B 約 12 個百分點,值得上;第 3-6 週建正式環境、接 SSO 權限與稽核日誌;第 7-8 週試營運。POC 用小卡、正式上大卡的兩段式做法,讓他們在只花 1.8 萬的階段就修正了兩個方向性決策——原本想用 70B,盲測發現對他們的題型增益不到 3 個百分點,直接省下一半月租。

上線三個月的營運數字:研究員平均每天問 340 次,尖峰併發 8 路,p95 回應延遲 2.1 秒;使用率最高的不是原本設想的報告查詢,而是「幫我把這段英文法遵函釋整理成繁中重點」這類翻譯摘要任務,佔了四成流量——這也是私有部署的隱藏優勢,用量爆了也不心疼,員工才敢把它用進日常。法遵部門的評語比任何跑分都有說服力:資料流全程在境內,稽核一次過。

導入時程與總成本怎麼抓

綜合幾十個案子的經驗,私有 LLM 部署的合理時程是:POC 兩到四週(單卡主機、量化模型、內部評測集),試營運四到六週(正式規格、權限與日誌、小範圍開放),然後全面上線。硬體之外的成本大頭是人:需要一位能維運 Linux 與容器的工程師兼職照顧,加上業務單位一位懂資料的窗口。全案抓下來,中型企業第一年的總持有成本多落在 NT$50 萬到 200 萬之間,對比動輒七八位數的商用授權案,這個數字通常過得了董事會。時程的最大變數在資料:文件散亂、權限歸屬不明的公司,前置整理常吃掉一半時間,這部分請誠實評估。

驗收建議寫成里程碑:POC 結束要有盲測分數與規格建議書;試營運結束要有 p95 延遲、可用率與使用量報表;全面上線滿一個月,要有部門滲透率與滿意度數字。每一關都有可驗證的產出,預算追加才有依據,專案也不會走著走著變成沒人敢驗收的懸案。

把第一年 TCO 拆開看會更好談預算:主機月租(單卡 NT$15,000-25,000 或 H100 級 NT$60,000-80,000)占五到七成,導入期的顧問或工程工時占兩到三成,剩下是評測、資安檢測與雜項。第二年起只剩月租與少量維運,成本曲線是前高後低。至於「租還是買」:買一台 H100 等級主機資本支出數百萬,加上機房、電力、備品與三年折舊,只有在負載長期滿載時才划算;先租十二個月把規格試到收斂,再拿真實使用率去算買斷的回本期,是財務上最站得住腳的順序。

最容易被砍掉重練的錯誤只有一個:第一天就買卡。模型迭代太快,今天為 70B 買的 8 卡機,半年後可能被 32B 的新模型追平。用台灣機房的月租主機把規格試到收斂,再決定要不要自建,是風險最低的路。

找台灣在地的 GPU 主機夥伴

私有 LLM 部署的每個階段需要的火力不同:POC 用單張 RTX 4090,正式環境可能要 H100 多卡。戰國策 GPU 主機提供 NVIDIA H100 與 RTX 系列多種配置,台灣機房、資料不出境,月租 NT$15,000 起,7×24 中文技術支援,規格可隨導入階段升級。方案細節見 戰國策 GPU 主機,或加 LINE @119m、撥免費專線 0800-003-191,顧問會依你的資料敏感度與任務需求試算規格。

常見問題 FAQ

私有部署 LLM 最低的硬體門檻是多少?

一張 24GB 的 RTX 4090 就能起步:7B 模型 FP16 推論占 14-16GB,或 32B 的 INT4 量化版占 18-20GB,都放得下。台灣機房這種單卡主機月租約 NT$15,000-25,000,足夠支撐數十人的內部使用,是最常見的 POC 起點。

開源模型商用,授權上要注意什麼?

Qwen2.5 多數尺寸是 Apache 2.0、DeepSeek 是 MIT,商用幾乎沒有附帶條件;Llama 3.x 用 Meta 社群授權,有大型平台月活門檻與再散布規定,需要法務確認。另外注意部分模型的量化版與衍生版授權可能與原版不同,下載來源要留紀錄備查。

7B、32B、70B 模型的能力差距到底多大?

以企業任務實測,7B 足以應付摘要、分類、格式轉換;32B 在多步推理與跨文件分析上,正確率常比 7B 高 15-25 個百分點;70B 再往上的增幅通常剩 3-8 個百分點,但顯存需求翻倍。建議用自己的 50-100 題測題盲測,而不是看排行榜。

INT4 量化會讓模型變笨嗎?

主流 GPTQ、AWQ 量化在常見任務上的品質損失約 1-3%,多數使用者感覺不出來;顯存卻能省 70% 以上,32B 從 64-70GB 壓到 18-20GB。要求最高的場景(法律條款比對、程式生成)可以 FP16 與 INT4 各架一套 A/B 實測再決定。

私有部署後,模型多久要更新一次?

開源模型大約每 3-6 個月出現一波明顯升級。建議每季用固定評測集重測一次新模型,分數高出 5 個百分點以上再換,避免追版本疲勞。換模型的成本主要在重跑評測與回歸測試,權重本身下載替換半天內可完成。

vLLM 和 Ollama 該用哪個?

POC 與個人使用選 Ollama,安裝到起服務 10 分鐘搞定;正式環境選 vLLM 或 SGLang,continuous batching 可把同卡吞吐拉高 5-10 倍,多人併發下的 p95 延遲差距非常明顯。兩者都有 OpenAI 相容 API,前期驗證、上線切換很順。

金融業用私有 LLM,法遵上可行嗎?

可行,而且私有化正是為了過法遵:資料全程留在境內機房,滿足個資法與金管會對委外及資料治理的要求,搭配存取控制與完整日誌即可受檢。台灣已有投信、銀行把內部文件助理跑在自建或租用 GPU 主機上的案例,稽核重點是資料流向與權限紀錄。

私有 LLM 的回應速度大概多快?

單使用者:7B 在 RTX 4090 上約每秒 60-100 個 token,32B INT4 約 25-40 個,一段 300 字回答 10 秒內完成;上 vLLM 後 10-20 路併發仍可維持每人每秒 20 個 token 以上。台灣機房網路往返約 5ms,體感比海外 API 快得多。

除了 GPU,主機的 CPU 和記憶體要怎麼配?

推論主機的通則是:系統記憶體至少是總顯存的 1.5-2 倍(載入與轉檔時要用),CPU 8-16 核心即可,硬碟建議 NVMe SSD 500GB 起跳放多版本權重。RAG 場景另外加向量資料庫的 16-32GB 記憶體。這些在租用方案裡通常已包含,確認規格單即可。

一年的總持有成本大概多少?

以 120 人企業、32B 模型、單張 H100 規格估:主機月租約 NT$60,000-80,000,一年 72-96 萬;加上工程師兼職維運與前期導入顧問,第一年總成本常落在 NT$100-200 萬。同樣用量走商用 API,帳單加法遵評估往往不會比較便宜,且資料須出境。

💡 快速答案:RAG 是什麼、企業導入需要什麼 GPU 配置?

RAG(檢索增強生成)先把文件切塊轉成向量索引,提問時檢索出最相關段落,交給 LLM 生成附來源的回答,模型不必重訓,知識更新是分鐘級。50 人內用 7B-14B 模型,一張 RTX 4090 主機就能起步,台灣機房月租約 NT$15,000-25,000;200 人以上建議 32B 模型與 48-80GB 顯存。

企業想讓 AI 回答內部知識,第一直覺常是「微調一個自己的模型」。但 2026 年的實務標準答案,八成是 RAG。原因很直接:公司的知識天天在變,產品規格改版、SOP 更新、法規修正,你不可能每次都重訓模型;而 RAG 只要更新索引,幾分鐘內新知識就上線。這篇文章講清楚 RAG 的運作原理、三段式的 GPU 需求怎麼估、導入成本落在什麼區間,並用一個台灣製造業的案例展示從評估到上線的完整過程。看完你應該能自己畫出第一版架構圖,並且對「這件事要花多少錢」有一個誤差不超過三成的估計。

RAG 是什麼?一條「檢索加生成」的流水線

RAG 的全名是 Retrieval-Augmented Generation,檢索增強生成。流程拆開看只有四步:把企業文件切成 300-800 字的小塊(chunking),用 embedding 模型把每一塊轉成向量存進向量資料庫;使用者提問時,問題同樣轉成向量,到資料庫裡找出最相近的 3-8 個段落;可以再加一層 reranker 模型精排,把真正相關的段落挑到前面;最後把這些段落連同問題一起塞進 prompt,讓 LLM 生成回答,並附上引用來源。

用一個具體例子走一遍。員工問「特休沒休完可以換錢嗎?」系統把這句話轉成向量,從索引裡撈出人事規章第 3.2 節與勞基法相關段落,reranker 確認這兩段最相關,LLM 讀完後回答:「依公司人事規章 3.2 條,年度未休畢特休依比例折算工資……」並在答案下方列出出處。使用者點開出處就是原始文件,這條「可驗證」的路徑,正是企業敢把 RAG 交給全公司用的原因。

規模感也給一下:一份 200 頁的 PDF 大約切成 400-800 個 chunk;一萬份文件、百萬級 chunk 的向量索引(1024 維、FP16)本體約 2-4GB,加上原文與中繼資料,整套索引通常在 10-20GB 之間——對現代主機來說是很輕的負擔。關鍵在於:模型本身完全不用動,LLM 負責閱讀理解與寫作,知識全部放在外部索引,加新文件的邊際成本趨近於零。

為什麼企業知識庫首選 RAG 而不是微調

把知識「訓進」模型有兩個結構性問題。一是更新成本:每次文件異動都要重跑訓練,一輪動輒數小時到數天,而企業知識的半衰期很短——電商的品規週週改,製造業的製程參數月月調,金融業的法遵函釋隨時來。二是不可追溯:模型答錯了,你不知道它是從哪筆資料學歪的,對需要稽核軌跡的產業是致命傷。RAG 剛好相反,答案旁邊就掛著來源文件,稽核人員點開就能核對。

成本差距也很具體。維護一套 RAG 索引,新增文件是增量更新、秒級完成,全量重建一次的 GPU 機時通常不到一小時;而同等知識量的微調,單輪訓練成本是它的數十倍,還要先把文件改寫成上萬筆問答格式的訓練資料,這道工序本身就是一個小專案。

還有一個很少被講白的面向:RAG 會逼你把知識治理做起來。哪些文件是現行版、誰有權看哪一類、過期文件怎麼下架——這些問題在建索引的第一週全部會浮出來,而它們本來就該被回答。反過來看,微調把知識揉進權重裡,版本與權限完全無從管理,答案對錯只能事後抽查,對受監理的金融、醫療產業幾乎是不可接受的黑盒。很多公司做完 RAG 之後回頭感謝的,其實是這一段被迫完成的文件大掃除。

當然,RAG 也有做不到的事:它改不了模型的語氣、輸出格式與任務行為,那是微調的守備範圍,兩者的分工可以參考 LLM 微調實戰。成熟團隊的終局架構多半是混合式:RAG 管知識、LoRA 管行為,先做 RAG 驗證價值,半年後再視需要補一層微調,投資順序不要反過來。

GPU 需求拆解:embedding、reranker、LLM 三段

RAG 系統的顯存消耗來自三個模型,量級差很多。embedding 模型(如 bge-m3、multilingual-e5 這類 0.3-2B 參數的模型)推論只要 2-6GB;reranker 模型同樣輕,2-4GB 就夠;真正的大戶是負責生成的 LLM——7B 模型 FP16 推論約需 14-16GB,14B 約 28-32GB,32B 約 64-70GB,若用 INT4 量化可以再省一半以上,32B 壓到 18-20GB,一張 24GB 卡就裝得下。

延遲的組成也值得認識:embedding 一次查詢 10-30ms,向量搜尋 10-50ms,reranker 50-150ms,而 LLM 生成占掉九成時間——一段 300 字的回答,以每秒 30-60 個 token 的速度要跑 10-20 秒。所以優化體感的重點永遠在生成段:開串流輸出讓使用者邊生成邊閱讀,體感延遲立刻從「等 15 秒」變成「等 1 秒」。建索引的吞吐則看 embedding:一張 4090 每秒可處理數百到數千個 chunk,百萬級索引初次建置約 1-3 小時,夜間排程綽綽有餘。

併發的速算法也給一個:內部工具的尖峰併發約是總人數的 5-10%,100 人公司抓 5-10 路。7B 模型配一張 4090,撐 10-20 路沒問題;32B INT4 因為權重就占掉 18-20GB,單卡併發建議壓在 5-8 路,超過就分雙卡或升 48GB 卡。先用保守配置上線、看兩週監控數據再決定加不加卡,永遠比一次到位便宜。

三段可以塞在同一張卡,也可以分開。50 人以內的內部知識庫,一張 RTX 4090 同時跑 7B INT4 生成加 embedding 綽綽有餘;使用者破兩百人、尖峰併發 10-20 路時,建議把 embedding 與 reranker 留在小卡或 CPU,生成模型獨占一張 48GB 以上的卡,否則檢索尖峰會跟生成搶資源,延遲直接翻倍。另一個常被忽略的顯存項目是 KV cache:併發越高、對話越長,占用越大,規劃時要在模型權重之外預留 20-40% 顯存。

規模對照表與成本區間

讀表時注意三件事。規模看的是「尖峰併發」而不是員工總數,一般內部工具的併發約是總人數的 5-10%;模型尺寸決定答案品質的天花板,32B 對 7B 的優勢在跨文件推理題上特別明顯,常有 15-20 個百分點的正確率差距;GPU 之外還有配角成本——向量資料庫吃的是 CPU 與 16-32GB 記憶體、索引與日誌的儲存、以及建置評測集的人力,這些加總約占專案總成本一到兩成。

對照雲端 API 的帳:呼叫商用模型 API 每百萬 token 約 US$0.5-15,小量使用便宜;但企業知識庫的痛點通常不是錢,而是文件必須送到境外模型商手上。自建 RAG 的月租是固定成本,量再大都不會爆,敏感文件也從頭到尾不離開機房,這兩點才是台灣企業選擇自建的主因。

拿數字算個分水嶺:一次問答連同檢索段落約消耗 3,000-6,000 個 token,200 人公司每天 500 次問答,月消耗大約 3,000-9,000 萬 token。走中階商用 API 月費看起來還可控,但前提是「文件可以出境」而且「用量不再成長」;一旦任一前提破掉——來了敏感專案、或使用量隨導入深化翻了三倍——自建的固定月租立刻反超。多數企業算完這筆帳,就把 API 留給不敏感的雜務,核心知識庫走自建。

台灣案例:精密加工廠的 SOP 知識庫

台中一家 280 人的精密加工廠,累積了 1.2 萬份文件:ISO 程序書、設備原廠手冊、工安 SOP、歷年異常處理紀錄。痛點很典型——新人找一份正確版本的 SOP 平均要 20 分鐘,夜班遇到設備異常只能打電話吵醒資深工程師。而這些文件混著客戶 NDA 與製程參數,受營業秘密法保護,法務直接否決任何「上傳到境外雲端 AI」的方案。

他們最後在台灣機房租了一台雙 4090 主機,跑 Qwen2.5-32B 的 INT4 量化版,配 bge-m3 做繁中檢索,月租約 NT$45,000。導入花了兩個月:第一個月清文件、建索引、跑 150 題內部評測集把命中率從 71% 調到 93%;第二個月試營運與權限分級。過程中真正難的不是模型,是文件工程——三成的手冊是掃描檔,要先過 OCR 與人工抽驗;製程參數表不能直接切塊,得整表保留並補上表頭說明;不同部門的文件還要掛權限標籤,業務看不到製程資料,產線查不到報價單,這些前置工作占掉全案一半以上的工時。

上線後新人查 SOP 的時間從 20 分鐘縮到 2 分鐘內,夜班打給資深工程師的次數少了六成。附帶的好處是延遲:機房在台灣,問答往返網路延遲 5ms 上下,比呼叫海外服務的 60-150ms 順暢得多,產線平板上用起來像即時對話。廠長事後的評語很實在:這套系統最大的價值不是 AI 多聰明,是它終於逼公司把二十年的文件整理成一套有版本、有權限的資產。

成本結構也值得記下來:這個案子的外部支出就是兩個月機器月租共約 9 萬元,其餘全是內部工時;同樣範圍交給系統整合商從零客製,市場報價常落在 NT$150-300 萬。自建加租機的組合,把試錯成本壓到外包報價的零頭,這也是我們一貫建議企業「先小做、驗證了再放大」的底氣。

常見翻車點:九成的爛 RAG 都是檢索的錯

導入 RAG 失敗的專案,問題極少出在 LLM,幾乎都出在檢索。常見的坑排下來:chunk 切太大或太小——300-800 字、前後保留 10-20% 重疊是穩健起點,表格與條列要特殊處理;embedding 模型不擅長繁體中文——選 bge-m3 或 multilingual-e5 這類多語模型,別拿純英文模型硬上;沒放 reranker——多這一層 2-4GB 顯存的小模型,常常就是命中率從七成到九成的差距;以及沒有評測集——上線前準備 50-200 題有標準答案的內部問題,每次調參數都重跑,不然你永遠在憑感覺調。

幻覺控制也有標準做法:在 prompt 裡強制「只能根據提供的段落回答,並列出引用編號」,檢索相似度低於門檻時直接回「資料庫中查無相關內容」,寧可不答也不要瞎掰。這些設定做齊,企業內部問答的可用率把握做到九成以上。

上線不是終點,RAG 是要養的。固定的維運節奏建議:新文件自動進索引(每日或每週排程)、每月跑一次評測集回歸確認沒有品質飄移、每季檢視一次「查無資料」與低分回答的清單,回頭補文件或調切塊。這些工作每月大約半人日,卻是系統一年後還好用的關鍵。想再深入私有化部署的模型選型與服務化細節,可以接著讀 私有 LLM 部署完整攻略。

找台灣在地的 GPU 主機夥伴

RAG 是企業 AI 裡投資報酬最好算的一種:GPU 需求從單張 4090 起步,隨使用人數線性成長,不會一開始就逼你上重裝備。戰國策 GPU 主機提供 NVIDIA H100 與 RTX 系列配置,台灣機房、資料不出境,月租 NT$15,000 起,7×24 中文技術支援,POC 到正式環境可以無痛升級。方案與規格見 戰國策 GPU 主機,或加 LINE @119m、撥免費專線 0800-003-191,顧問會依你的文件量與使用人數建議配置。

常見問題 FAQ

RAG 和微調最大的差別是什麼?

RAG 把知識放在外部向量索引,模型不動,文件更新後幾分鐘就生效,回答還能附上來源;微調是把行為訓進模型,適合改語氣與格式,但知識一變就要重訓,單輪成本是重建索引的數十倍。企業知識庫九成情境應該先做 RAG。

導入 RAG 最低的 GPU 門檻是多少?

POC 等級只要一張 24GB 的 RTX 4090:跑 7B 模型的 INT4 量化版約占 5-6GB,加上 bge-m3 embedding 的 2-4GB 與 KV cache,單卡綽綽有餘。台灣機房這種主機月租約 NT$15,000-20,000,兩週內可以搭出能給主管試用的版本。

RAG 一定需要 GPU 嗎?用 CPU 不行嗎?

檢索段可以用 CPU,但 embedding 建索引會慢 10 倍以上;生成段用 CPU 跑 7B 模型每秒只有個位數 token,一個回答要等一兩分鐘,基本不可用。實務上一張入門 GPU 就能讓回答速度到每秒 30-60 個 token,體驗完全不同。

文件要怎麼切塊(chunking)比較好?

通用起點是每塊 300-800 字、前後重疊 10-20%,依標題與段落邊界切而不是硬切字數。表格建議整張保留並附上表頭說明,條列式 SOP 以步驟為單位。切法對命中率的影響常達 10-20 個百分點,值得花一天實驗。

向量資料庫該選哪一套?

百萬級以下向量,Qdrant、Milvus、pgvector 都夠用,差異主要在維運習慣:已有 PostgreSQL 的團隊用 pgvector 最省事,獨立部署選 Qdrant 輕量好管。向量檢索通常吃 CPU 與記憶體,抓 16-32GB RAM 起步即可,不占 GPU 顯存。

RAG 的回答品質要怎麼量化?

上線前建 50-200 題有標準答案的評測集,追兩個數字:檢索命中率(正確段落有沒有進前 5)與答案正確率(人工或 LLM 評分)。健康的系統命中率要 85% 以上、正確率 90% 上下;每次調 chunk、換模型都重跑,才知道是變好還變壞。

怎麼降低 RAG 的幻覺?

三件事做齊:prompt 強制只依提供段落回答並附引用編號;檢索相似度低於門檻就回「查無資料」,不硬答;加 reranker 把不相關段落擋在生成之前。實務上這樣可以把幻覺率壓到 5% 以下,剩下的靠評測集持續抓漏。

200 人規模的公司,RAG 主機月費大概多少?

尖峰併發 10-20 路、用 32B INT4 模型加完整檢索鏈,建議 2×RTX 4090 或一張 H100 80GB,台灣機房月租約 NT$40,000-80,000。比起呼叫雲端 API,固定月租的好處是用量再大帳單也不會失控,且文件全程不出機房。

RAG 適合處理 Excel 和圖面這類非文字資料嗎?

表格類資料要先轉成結構化文字或用表格感知的解析器處理,效果才穩;工程圖面、照片則需要多模態模型(如 Qwen-VL 系列),顯存需求會多 30-50%。建議第一期先做純文字文件,驗證價值後再擴充多模態,風險最低。

資料完全不能出公司,RAG 做得到嗎?

可以,這正是自建 RAG 的主場:embedding、向量資料庫、LLM 全部跑在你租用或自有的主機上,文件與問答紀錄都不離開機房。台灣機房方案還能滿足個資法與客戶 NDA 的稽核要求,金融與製造業已有大量落地案例。

💡 快速答案:LLM 微調該選 LoRA 還是 Full Fine-tuning?

八成企業場景用 LoRA 就夠:凍結原模型、只訓練低秩適配層,顯存約全參數微調的 1/3-1/10,7B 模型一張 RTX 4090 就能跑。Full Fine-tuning 效果上限較高,但 7B 就要 110GB 以上顯存、成本高 5-10 倍。建議先用 QLoRA 花半天驗證資料有訊號,再決定要不要加碼。

「我們想微調一個自己的模型」,這大概是 2026 年台灣企業 AI 導入會議上出現頻率最高的一句話。但再往下追問,十個團隊有八個說不清楚要微調什麼、需要幾張 GPU、預算該抓多少,甚至分不清自己要解的問題到底需不需要微調。這篇文章把 LLM 微調的兩條主要路線——LoRA 與 Full Fine-tuning(全參數微調)——的原理、顯存需求、訓練時間與租用成本一次算清,並附上一個台灣電商團隊從 POC 到上線的完整時程。先講立場:除非你已經用 LoRA 驗證過效果而且確定不夠,否則不要從全參數微調開始,這條原則能替多數團隊省下第一筆冤枉錢。

先確認你要解的是「行為問題」還是「知識問題」

微調改變的是模型的「行為」:輸出格式、語氣、領域用語、任務套路。它並不擅長把新知識塞進模型腦袋。想讓 LLM 回答公司內部文件、產品規格、常變動的政策條文,正確工具是 RAG(檢索增強生成),不用重訓模型,知識更新也是即時的,做法可以參考 RAG 企業知識庫方案指南。

那什麼情境值得微調?幾個典型:客服回覆必須完全符合品牌語氣與 SOP;輸出要是嚴格的 JSON 或報表格式,prompt 調到極限仍有 5% 上下的格式錯誤;醫療、法律、精密製造這類術語密集的領域,通用模型講話「不像內行人」;或者你想把原本要 70B 模型才穩定的任務壓進 7B 小模型,推論成本直接砍到三分之一以下——這是最容易回本的一種。

一個花半天就能做完的自我檢查:拿 20-30 題實際業務問題,用你手上最強的模型加上能寫出的最好 prompt 跑一遍。如果錯的是「答案內容」,例如模型不知道你們的產品規格,那是知識問題,微調救不了;如果錯的是「表達方式」——格式跑掉、語氣不對、廢話太多——才輪到微調上場。另外記住成本結構:prompt 迭代的邊際成本趨近於零,微調一輪動輒數千元機時起跳,能用 prompt 解決的問題,永遠優先用 prompt。多數企業最後的架構是混合的:RAG 管知識,微調管行為,兩邊各司其職。

Full Fine-tuning:效果上限最高,顯存是無底洞

全參數微調就是把模型每一個權重都拿出來更新。效果上限最高,但顯存開銷驚人,因為訓練期間要同時擺四樣東西:模型權重(FP16 每參數 2 bytes)、梯度(2 bytes)、AdamW 優化器狀態(FP32 動量加變異數,8 bytes),再加上隨序列長度與 batch size 成長的激活值。

經驗法則:全參數訓練的顯存需求,大約是「FP16 權重容量」的 8 到 10 倍。7B 模型權重約 14GB,全參數訓練就要 110-140GB,單張 H100 80GB 裝不下,2 張起跳,還得搭配 DeepSpeed ZeRO 或 FSDP 把狀態切到多卡。32B 約 500GB 上下,70B 直接衝破 700GB,進入多節點叢集的世界——那是另一門學問,可見 多節點分散式訓練入門。

激活值是最容易被低估的一項:它隨 batch 與序列長度線性成長,4K 序列、batch 8 的設定下,7B 的激活值可以再吃掉 30-60GB,所以實務估算永遠要留緩衝。另一筆隱性成本是實驗管理——全參數微調的每個 checkpoint 都是完整模型,7B 一份 14GB,訓練途中存十份就是 140GB 儲存;超參數掃五組,機時與儲存全部乘以五。這些帳在報價單上看不到,卻真實反映在時程與月結帳單上。

資料需求同樣是門檻:全參數微調通常要上萬到數十萬筆高品質資料才不容易過擬合,一輪訓練以天計。對多數企業,這條路的合理時機只有一個:LoRA 已經證明有效,而你需要再擠出最後幾個百分點,或者要做深度的領域續訓。

LoRA:凍結原模型,只訓練低秩適配層

LoRA(Low-Rank Adaptation)的思路完全不同:原模型權重全部凍結,在注意力層旁邊掛上兩個低秩矩陣(rank 一般取 8-64),只訓練這一小撮新增參數,通常僅占原模型參數量的 0.1% 到 1%。

因為梯度與優化器狀態只需要為這不到 1% 的參數保留,整體顯存需求大約降到全參數微調的 1/3 到 1/10。7B 模型跑 FP16 LoRA 約需 18-24GB,一張 RTX 4090(24GB)剛好能吃下;QLoRA 更進一步把凍結的底模量化成 4-bit,7B 只要 8-12GB,16GB 的消費卡都能拿來做實驗。

幾個實務參數直接給你抄:rank 從 16 或 32 起手,純風格任務 8 就有感,複雜任務再往 64-128 試;適配層先只掛注意力層的 Q、K、V、O 四個投影矩陣,效果不足再加 MLP 層,代價是參數量與顯存多三四成;學習率抓 1e-4 到 2e-4,比全參數微調高一個數量級。還有個反直覺的優點:當你的資料只有幾千筆,LoRA 因為可訓練參數少,反而比全參數更不容易過擬合——小資料集的企業場景等於天然適配。

工程面的好處也別忽略。訓練產出的 adapter 檔案只有幾十到幾百 MB,版本管理與回滾都輕鬆;同一個底模可以掛多組 adapter,客服、翻譯、摘要各練一個,推論時動態切換,一台主機同時服務多個任務。對人力有限的台灣中小團隊,這種可維運性比跑分高一兩分重要得多。

GPU 需求對照表:7B 到 70B 一次看清

兩個實務提醒。表中數字以 2K-4K 序列長度、小 batch 估算,序列拉到 8K 以上或 batch 加大,激活值會讓顯存再多吃 20-50%;另外,開 gradient checkpointing 可以省下 30-50% 顯存,代價是訓練慢兩到三成,當顯存卡在門檻邊緣時,這是最划算的交換。

訓練時間也給個基準,以 2 萬筆、平均 1K token 的指令資料跑 3 個 epoch 估算:7B LoRA 在 RTX 4090 上約 6-10 小時,H100 約 2-4 小時;14B 大致乘以二;32B 的 QLoRA 在雙 4090 上要 15-25 小時。換算成錢:台灣機房 4090 主機月租 NT$15,000-25,000,攤下來一輪訓練的機時成本不過幾百元——真正貴的是工程師指揮機器的時間,所以把迭代週期縮短,比省那一點機時重要得多。

用這張表抓預算的流程很直接:先定模型規模(絕大多數企業從 7B-14B 起步),再定訓練方式(預設 QLoRA),最後對出顯存與卡數。容易被忽略的是主機配套:載入與轉檔階段很吃系統記憶體,RAM 建議抓總顯存的 1.5-2 倍;資料集加上多版本 checkpoint,硬碟建議 NVMe SSD 500GB 起跳。這些在正規的租用方案裡通常已包含,自組機器時卻最常漏算,開訓當天才發現 RAM 不夠是很常見的慘劇。

成本試算與導入案例:兩週從 POC 到上線

先看租用行情。海外雲端 H100 每小時約 US$2.5-6,一次 6 小時的 7B LoRA 訓練折合 NT$500-1,500,單看很便宜。但實務上一個案子會迭代數十次,加上資料前處理、失敗重跑與除錯占用的機時,月帳單很容易衝到 NT$40,000-80,000,而且企業資料得出境。台灣在地 GPU 主機走包月制,RTX 4090 等級月租約 NT$15,000-25,000,吃到飽迭代,資料留在台灣機房,個資法遵評估也單純得多。

看一個實際案例。台北一家 35 人的跨境電商,想把客服 email 草擬自動化,選了 Qwen2.5-7B-Instruct 做 QLoRA,資料是 2.3 萬筆去識別化的歷史工單。時程是:第 1-2 天環境建置與資料清理;第 3 天跑通第一輪訓練,單輪約 4 小時;第 4-10 天共迭代 11 輪,主要在調資料配比與 rank;第 11-14 天做離線評測與上線。設備就是台灣機房一台單卡 4090 主機,整個專案的硬體成本等於一個月月租 NT$18,000。上線兩個月後,客服首次回覆時間從平均 4 小時降到 18 分鐘,AI 草稿採用率 76%。同樣的迭代量若按小時租海外 H100,估 NT$35,000-60,000,還沒算個資出境評估的隱形成本。

這個案子有兩個值得抄的細節。資料清理占掉整個專案約六成工時:他們把 5 萬筆原始工單去重、濾掉罐頭回覆、遮罩個資後只剩 2.3 萬筆可用,但正是這一步讓效果跳上來——第一版直接拿全量原始資料訓練的模型,盲測分數比底模還差。評測做得樸素而有效:上線前用 50 題真實客服情境做人工盲測,上線後每週抽 100 封 AI 草稿人工複核,採用率與修改幅度都進儀表板,「76% 採用率」這個數字就是這樣來的,不是感覺。

雲端與在地的比較,還有兩筆帳常被漏掉。上傳與下載的時間成本:幾十 GB 的資料集與模型權重在跨海頻寬上來回,每次迭代多等半小時起跳,兩週的專案硬是被拖成三週。還有法遵文件成本:客戶資料要出境,法務得做傳輸影響評估與契約檢核,這些人力成本往往超過機時費本身。台灣機房把這兩筆直接歸零,這才是月租數字之外真正的差異。

再補一個時程上的提醒:兩週上線的前提是資料已經存在、只需要清理。如果工單還散在個人信箱、客服系統沒有匯出機制,請先花兩到四週把資料管線建起來再開案,否則 GPU 租了只能空轉。評估微調專案時,「資料在哪、誰能拿到、乾不乾淨」這三個問題,永遠比「要租哪張卡」優先。

LoRA 的極限:什麼時候該誠實加碼

LoRA 不是萬靈丹。三種情況它會明顯不夠力:語言或領域移轉幅度太大,例如要讓英文底模深度學會台語文書寫;需要動到模型底層能力,像長推理鏈或更換 tokenizer;以及大規模續訓與蒸餾。此時的升級路徑通常是把 rank 拉高到 128-256 並套用到更多層,再不行才解凍部分層,最後才是全參數微調。

順帶回答一個常見的進階問題:DPO、RLHF 這些對齊技術呢?它們解的是「在多個可行回答之間挑更好的那個」,通常接在監督式微調(SFT)之後,資料要成對的偏好標註,顯存需求與 LoRA SFT 同級或略高。多數企業案子做到 LoRA SFT 就能交付,對齊訓練留給有專職 ML 團隊的公司;至於資料量以十億 token 計的領域續訓,進場前先確認你真的有那個量級的語料,多數產業其實沒有。

我們給客戶的標準建議是反過來走:先用 QLoRA 花半天、幾百元機時,驗證「你的資料有沒有訊號」。有效果,八成的案子就停在 LoRA 直接上線;有效果但不夠力,才值得討論全參數與更大的 GPU 配置。從第一天就上全參數微調的團隊,多數是把預算燒在還沒驗證過的假設上。預算排序也很直觀:先花錢整資料,再花錢租卡,買卡永遠放最後。

給一張可以直接對照的判斷清單:資料少於 5,000 筆、任務屬於格式語氣類、預算在六位數以內——停在 LoRA;盲測顯示模型能力天花板明顯、可用資料超過 10 萬筆、團隊有專職 ML 人力——才值得進全參數。拿這五條對照你的專案,九成的情況答案已經出來了,剩下一成,先跑一輪 QLoRA 再說。

找台灣在地的 GPU 主機夥伴

微調專案的 GPU 需求有明顯階段性:POC 期一張 4090 就夠,放大期可能要 H100 多卡。戰國策 GPU 主機提供 NVIDIA H100 與 RTX 系列多種配置,機器放在台灣機房、資料不出境,月租 NT$15,000 起,7×24 中文技術支援,可以隨專案階段彈性升級。方案細節見 戰國策 GPU 主機,或加 LINE @119m、撥免費專線 0800-003-191,由顧問依你的模型規模與資料量試算配置。

常見問題 FAQ

用 LoRA 微調 7B 模型最少需要多少顯存?

FP16 LoRA 約需 18-24GB,一張 RTX 4090(24GB)可以執行;QLoRA 把底模量化成 4-bit 後只要 8-12GB。若序列長度超過 4K 或 batch 加大,建議直接抓 24GB 以上,搭配 gradient checkpointing 還能再省 30-50% 顯存。

LoRA 的效果會比全參數微調差很多嗎?

在指令跟隨、語氣風格、格式控制這類任務上,LoRA 與全參數微調的差距多在 1-3% 以內,人工盲測常分不出來。差距明顯的是深度領域移轉與新語言學習。建議先用 LoRA 驗證方向,確認有效再評估是否值得多花 5-10 倍成本上全參數。

微調需要準備多少訓練資料?

風格與格式類任務約 500-3,000 筆高品質樣本就有感;任務型指令微調常見 5,000-50,000 筆;全參數領域續訓以十萬筆起跳。資料品質比數量重要,1,000 筆人工校對過的乾淨樣本,效果往往勝過 3 萬筆帶雜訊的原始資料。

7B 模型 LoRA 微調一輪要跑多久?

以 2 萬筆、平均 1K token 的指令資料訓練 3 個 epoch 估算:RTX 4090 約 6-10 小時,H100 約 2-4 小時;QLoRA 因量化運算反而慢 10-20%。整個專案含迭代通常要跑 10-20 輪,所以包月主機會比按小時計費划算。

該選微調還是 RAG?

要模型「知道最新內部知識」選 RAG,知識更新即時、回答可附來源;要改變「行為與語氣」選微調。實務上七成企業案子從 RAG 起步,最成熟的架構是 RAG 管知識、LoRA 管格式語氣,兩者並用,總成本反而比硬用單一方案低。

QLoRA 是什麼?量化會不會犧牲效果?

QLoRA 把凍結的底模用 NF4 格式壓到 4-bit,只有 LoRA 適配層維持高精度,7B 的訓練顯存從 18-24GB 降到 8-12GB。多數公開評測顯示效果損失在 1-2% 內,對預算有限的團隊是首選起點,驗證有效後再換 FP16 LoRA 收尾即可。

微調後模型會不會忘記原本的能力?

會,術語叫災難性遺忘。全參數微調最嚴重,LoRA 因為凍結原權重,影響小得多。實務解法是在訓練資料混入 5-10% 通用指令資料,並在驗證集加入通用能力測項;若通用分數掉超過 3-5%,通常是學習率太高或 epoch 太多。

一張 RTX 4090 能微調 70B 模型嗎?

單張 24GB 不行。70B 即使用 QLoRA 也需要 42-50GB 顯存,至少要 2 張 4090 合計 48GB 搭配分片,或一張 48GB 的 L40S 勉強容納。認真做 70B 建議 2-3 張 H100 跑 FP16 LoRA,訓練速度與穩定度跟消費卡是兩個世界。

微調專案該租 GPU 還是買卡?

迭代期建議用租的:台灣機房 4090 主機月租約 NT$15,000-25,000,免押金、硬體故障有人處理,兩三個月專案期的總成本遠低於購置。等你有全年不間斷的訓練需求且用量穩定,再評估買斷,回本週期一般抓 12-18 個月。

訓練資料要整理成什麼格式?

主流是 JSONL,每行一筆,含 instruction、input、output 欄位,或 OpenAI 式的 messages 對話格式。真正花時間的是去識別化、去重與品質篩選,這部分通常占專案 40-60% 的工時,比訓練本身還重,建議一開始就排進時程。