💡 快速答案: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 規劃失敗的起點。 ▲ 7B 全參數訓練 110-140GB;推理 FP16 只要 14-16GB 顯存帳怎麼算:8-10 倍的差距從哪來 同一個 7B 模型,為什麼訓練要 110-140GB、推理只要 14-16GB?把顯存

💡 快速答案:怎麼把自己的 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 把產品驗證起來;以及任務非旗艦閉源模型不可——開源模型盲測過確實不夠力的少數場景。自建是工程決策不是信仰,拿你的用量、資料屬性與人力對照上面六條,答案通常很清楚。 ▲ 7B 權重 14-16GB,每路 4K 對話 KV cache 抓 0.5-2GB 三角習題:延遲、併發、成本怎麼互相拉扯 看懂三角關係,要先認識兩個延遲指標。T

💡 快速答案:商用部署 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 產線最擅長的三件事,也是按張計費的境外服務最貴的三件事。 ▲ RTX 4090 批次月產能 15 萬張;FLUX.1

💡 快速答案: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,有個很土但有效的方法:把過去三個月人工

💡 快速答案:什麼時候一台 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)

💡 快速答案:企業要私有部署 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 相容介面切換

💡 快速答案: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 微調該選 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 迭代的邊際成本趨近於零,微調一輪動輒數千元機時起跳,能用 promp

💡 快速答案:浸沒式液冷伺服器是什麼?為什麼高密度 GPU 機房要把伺服器泡進液體裡? 浸沒式液冷伺服器就是把整台伺服器浸入不導電的介電冷卻液中散熱,分為單相(液體不沸騰,靠泵浦與對流循環帶熱)與兩相(液體在晶片表面沸騰汽化,以潛熱散熱,效率更高)兩種。液體帶熱能力遠勝空氣,單櫃可支援 30 到 100kW 以上的 GPU 高密度部署,機房 PUE 能從氣冷的 1.4-1.6 降到約 1.05-1.1,散熱電費大減,還能拆除風扇、大幅降低噪音與故障率。 走進一座傳統機房,最先感受到的是風:上千顆風扇的轟鳴、冷通道的寒意、熱通道撲面而來的熱浪。走進一座浸沒式液冷機房,卻安靜得像圖書館,伺服器整台泡在清澈的液體裡,只剩泵浦低鳴。這不是科幻場景,而是 AI 時代高密度 GPU 機房正在發生的散熱革命。這篇文章用顧問的視角,把浸沒式液冷伺服器的原理、單相與兩相的差異、PUE 電費帳本、與氣冷及冷板方案的取捨,以及台灣機房的導入現況,一次講清楚。 當機櫃功率衝破 30kW:氣冷正在逼近物理極限 十年前,一座標準機櫃裝滿伺服器,總功率大約 3 到 5kW,機房空調吹一吹就能應付。今天一台八卡的 AI 訓練伺服器,滿載功率就可能超過 10kW;疊四台進同一櫃,單櫃輕鬆突破 40kW。NVIDIA 新世代 GPU 平台的參考架構,單櫃功率更已規劃到 100kW 以上。業界的共識很直白:AI 機櫃的功率密度在五年內成長了一個數量級,而且還在往上爬。 麻煩在於,空氣本質上是很差的導熱介質:熱容量低、導熱係數低,要帶走同樣的熱量,需要非常大的體積流量。機房因此塞滿風扇、空調箱與冷熱通道封閉設施,整棟建築有相當比例的電力不是拿來運算,而是拿來吹風。當單櫃功率超過大約 20 到 30kW,氣冷開始捉襟見肘:風量再大,晶片熱點依舊壓不住,GPU 為了自保觸發降頻,你買來的算力就這樣悄悄打了折。風扇本身也吃電、也會壞,密度越高,這條路就越走越窄。 許多機房的第一反應是「攤開放」:一櫃只裝三分之一,把熱源稀釋。代價是機位租金與樓地板面積翻倍,叢集節點被迫拉遠,網路佈線與延遲一起惡化。如果你正在規劃 AI 訓練或高效能運算叢集,這道散熱天花板遲早會撞上;想先補齊運算架構的基礎,可參考這篇 HPC 高效能運算入門指南,本文則聚焦散熱這一側的解法。 ▲ 氣冷機房 PUE 1.4-1.6