分類：主機服務

💡 快速答案: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

💡 快速答案:GPU 與 CPU 的差異是什麼,為什麼 AI 訓練都用 GPU? CPU 只有數個到數十個強大核心,擅長複雜邏輯、分支判斷與一步接一步的序列任務,像幾位十項全能的大廚;GPU 有數千到上萬個小核心,能同時對大量資料做一模一樣的簡單運算,像整條工廠流水線。AI 訓練的本質是巨量矩陣乘加,幾乎沒有分支,正好能拆給幾千個核心同時算,所以 GPU 常比 CPU 快數十倍。兩者是分工:CPU 負責指揮與邏輯,GPU 負責平行算力。 為什麼一講到 AI,大家都在搶 GPU? 如果你最近看過任何一則科技新聞,大概都遇過同一句話:「AI 需要大量 GPU。」奇怪的是,你的筆電裡明明有一顆不便宜的 CPU,課本還說它是電腦的大腦,為什麼一算 AI,大家卻搶著要另一種晶片?這篇文章用最白話的方式,把 GPU 與 CPU 差異一次講清楚,也順便回答另一個常被搜尋的問題:什麼是 GPU 伺服器。你不需要資工背景,只要想像過餐廳的廚房和工廠的流水線,就能看懂現代運算世界最重要的一次分工。讀完之後,下次家人問起新聞裡的 AI 晶片之亂,你可以用一頓晚餐的時間講給他們聽。 先給最短版本的答案:CPU 像幾位十項全能的大廚,人數少,但再刁鑽的菜都做得出來;GPU 像幾千名只負責一道簡單工序的作業員,單看一個人不起眼,整條線動起來的產量卻嚇死人。難的菜交給大廚,大量重複的簡單工作交給流水線,這就是兩顆晶片的分工。接下來我們把比喻拆開,看看它們在晶片層面各自對應什麼。 ▲ CPU 擅長邏輯與序列;GPU 同時對巨量資料做相同運算 CPU:少而精的十項全能大廚 一顆現代 CPU 通常只有數個到數十個核心:家用桌機常見 6 到 16 核,伺服器等級可以到 64 核、96 核,頂多一百出頭。但每個核心都非常強:時脈動輒 3 到 5 GHz,等於每秒數十億個節拍;核心旁邊配了層層快取(L1、L2、L3),容量從幾十 KB 到上百 MB,讓最常用的資料幾乎不用等待就能取用,延遲極低;再加上分支預測、亂序執行這類聰明機制,專門對付「充滿判斷與跳轉」的程式。 換成廚房語言:CPU 核心就是米其林等級的大廚。客人臨時改單,他當場改流程,這叫分支判斷;一道功夫菜十個步驟環環相扣,少一步都不行,這叫序列任務;煮到一半要嚐味道再決定加不加鹽,這叫邏輯控制。作業系統的排程、資料庫的交易、網站

💡 快速答案:雲端遊戲和 VR 串流的延遲要壓到多少毫秒才不會有感? 雲端遊戲從按鍵到畫面反應的總延遲壓在 100 毫秒以內即可順暢遊玩,50 毫秒以下多數玩家已感覺不出與本機差異;VR 串流更嚴苛,從轉頭到畫面更新需低於約 20 毫秒,否則容易暈眩。實務作法是三管齊下:把 GPU 放在靠近玩家的在地邊緣機房,將網路來回時間從跨海的 40 毫秒壓到 10 毫秒內;用 NVENC 硬體編碼把壓縮延遲降到毫秒級;再以 90 到 120Hz 高更新率縮短每格等待時間。 想像你在台北家裡按下手把的攻擊鍵,而真正算出那一刀畫面的顯示卡,其實在幾十公里外的機房裡。它必須在你眨一次眼的十分之一時間內,把指令收進來、畫面算出來、壓縮成影片、傳回你的螢幕。這就是雲端遊戲每秒鐘重複六十次以上的魔術,而魔術成敗只有一位評審:延遲。 人類對延遲的忍耐力,比多數工程師想像的低。實務經驗指向幾個門檻:總延遲超過 100 毫秒,玩家會覺得手感「怪怪的」;壓到 50 毫秒以下,多數人分不出雲端與本機的差別;而戴上頭盔的虛擬實境(VR)更殘酷,從你轉頭到畫面跟上若超過 20 毫秒,內耳前庭系統就會抗議,輕則出戲,重則暈眩想吐。這篇文章用顧問視角拆開整條延遲鏈:每一毫秒花在哪裡、怎麼省回來,以及為什麼對台灣團隊而言,機房位置比算力大小更關鍵。 雲端遊戲的架構:GPU 在機房,手把在你家 先把管線攤開。雲端遊戲的本質是「把遊戲主機搬進資料中心」:伺服器端的 GPU 即時算出遊戲畫面,再由 GPU 內建的硬體編碼器 NVENC 把每張畫面壓縮成影像串流,格式可用 H.264、HEVC 或最新的 AV1,經網路送到玩家的手機、電視或筆電;終端裝置解碼顯示,玩家的按鍵與搖桿輸入則反向回傳雲端,驅動下一張畫面。這條迴圈每秒要跑 60 到 120 次,任何一站塞車,整條線就跟著慢。 這個架構的美妙之處在於終端可以很弱:三年前的中階手機也能玩 3A 大作,因為它只負責解影片。難處則全部集中到伺服器與網路上——GPU 要算得快、編碼要壓得快、封包要跑得快,任何一環拖慢,玩家的手感就會像「隔著一層果凍出拳」。至於 GPU 為什麼天生擅長這種每秒上百張的即時算圖工作,可以參考我們寫過的 GPU 與 CPU 差異解析,這裡不重複展開。 值得單獨介紹的是 NVENC 這顆低調的功臣。它是獨立於算圖核心之外的

💡 快速答案:大學實驗室做 AI 研究,GPU 應該自購還是租用? 關鍵看利用率:若 GPU 長期利用率能維持 70% 以上,自購攤提三到五年通常較省;若需求集中在計畫衝刺期、時有時無,租用免前期資本支出、可列經常門核銷,總成本反而更低。以四卡伺服器約 NT$200 萬的規模試算,利用率僅三到四成時,改採租用或小自購加租用的混合模式,三年可省下數十萬元,還能在衝刺期租到 80GB 的 H100 跑大模型微調。建議先以過去 12 個月的實際使用紀錄算出利用率再決策。 七月的核定通知寄到信箱,北部某大學資工系的教授盯著清單上的設備費額度,心裡盤算的不是要買哪一張卡,而是三年後這台機器還值多少錢、學生畢業後誰來管它。這幾乎是每一位投入 AI 研究的計畫主持人都躲不掉的課題:算力要用買的,還是用租的?這個問題沒有放諸四海皆準的答案,卻有一套清楚的計算框架——VRAM 需求、利用率、電費、折舊、經費科目,一項一項攤開來算,答案自然會浮現。本文以資深顧問的視角把這筆帳完整算一遍,並附上一份三年總持有成本(TCO)試算,供大專院校科學研究團隊在編列與執行計畫經費時參考。 AI 研究要多少算力?先看 VRAM,再談卡數 許多採購決策的第一個錯誤,是把算力簡化成卡的張數或每秒浮點運算次數。對 AI 研究而言,第一道門檻其實是 VRAM:它決定模型「放不放得進去」,算力才決定「跑得快不快」。訓練與推論的記憶體需求天差地遠——推論只需容納模型權重與少量啟動值,訓練卻要同時保存權重、梯度與最佳化器狀態,記憶體需求往往是推論的三到四倍以上。不少實驗室買卡時只算了推論的帳,開訓第一天就爆記憶體,這種故事每年都在校園裡上演。 具體門檻可以抓幾個錨點:7B 參數等級的語言模型,若採用 LoRA、QLoRA 這類參數高效微調方法,單張 24GB 的 RTX 4090 就能動工;13B 模型搭配 4-bit 量化也勉強可行,只是批次大小與序列長度會被壓縮。一旦要做全參數微調,7B 模型就需要 80GB 等級的 H100 或 A100,13B 以上動輒兩卡、四卡起跳,還得靠 NVLink 或高速網路把多卡串成一體。視覺大模型與擴散模型同理:研究原型可以在 24GB 上跑小解析度實驗,要重現論文等級的完整訓練排程,80GB 與多卡幾乎是標配。 換句話說,一間實驗室的算力需求天生是「兩層結