最近總有朋友問我一個(gè)很實(shí)際的問題做 AI 應(yīng)用到底是買 GPU、用 TPU還是試試 LPU這三個(gè)詞現(xiàn)在幾乎成了“AI 芯片”的代名詞但真到了掏錢選型的時(shí)候大部分人都是懵的。跑訓(xùn)練的人說 GPU 是唯一真理谷歌生態(tài)里走出來的工程師說 TPU 才是大規(guī)模訓(xùn)練的終極答案做推理優(yōu)化的朋友又猛吹 LPU 的低延遲如何顛覆體驗(yàn)。聽一圈下來不但沒搞明白反而更不知道該怎么選。先給個(gè)我的結(jié)論**不存在絕對(duì)的“性價(jià)比之王”只有“適合你當(dāng)前場(chǎng)景”的那個(gè)選項(xiàng)。**訓(xùn)練、微調(diào)、推理、邊緣部署算的賬完全不一樣。芯片本身的跑分高不高只是一回事真正決定你花錢值不值的是生態(tài)成熟度、單位算力成本、工程遷移成本這些被忽略的“隱性賬單”。這篇文章就不繞彎子了直接把這三種芯片的底細(xì)翻一翻再結(jié)合我實(shí)際跑過的訓(xùn)練、微調(diào)、推理任務(wù)告訴你什么場(chǎng)景下選誰最劃算以及那些文檔里不會(huì)寫的坑。1. 先搞清楚三家人到底在做什么1.1 GPU通吃型選手靠堆核心吃飯GPU 大家最熟尤其是 NVIDIA 的 A100、H100 系列。它的核心思路是“并行堆料”——把成千上萬個(gè)簡(jiǎn)單的計(jì)算核心堆在一起同時(shí)處理海量數(shù)據(jù)。做矩陣運(yùn)算時(shí)GPU 可以把一個(gè)大矩陣拆成無數(shù)小塊分給不同核心同時(shí)算再匯總結(jié)果。這套架構(gòu)的強(qiáng)項(xiàng)是“通用”。不管你是做 LLM 訓(xùn)練、圖神經(jīng)網(wǎng)絡(luò)、科學(xué)計(jì)算還是視頻編解碼只要算法能寫成矩陣運(yùn)算GPU 都能跑而且性能都還不錯(cuò)。生態(tài)更是無敵PyTorch 默認(rèn)支持 CUDAHuggingFace 上幾乎每個(gè)模型都開箱即用地跑到 GPU 上FlashAttention、DeepSpeed 這些優(yōu)化庫也全是圍繞 CUDA 生態(tài)做的。但 GPU 有個(gè)天然短板顯存帶寬和容量跟不上算力增長(zhǎng)。A100 的內(nèi)存帶寬大概是 2TB/s 級(jí)別H100 到 3.35TB/s聽著很嚇人但和芯片內(nèi)部的浮點(diǎn)算力相比依舊是個(gè)瓶頸。模型參數(shù)、中間激活值都要在顯存和計(jì)算單元之間來回搬運(yùn)很多場(chǎng)景下“等數(shù)據(jù)”的時(shí)間比“算數(shù)據(jù)”的時(shí)間還長(zhǎng)。打個(gè)比方GPU 像一支什么活都能接的施工隊(duì)工具齊全、經(jīng)驗(yàn)豐富哪個(gè)項(xiàng)目都能上但物料搬運(yùn)環(huán)節(jié)經(jīng)常拖后腿工期一大就得靠人海戰(zhàn)術(shù)堆時(shí)間。1.2 TPU谷歌的“偏科生”為矩陣乘而生TPU 是 Google 從 2016 年開始自研的專用芯片全稱 Tensor Processing Unit聽起來就很“張量”。它的核心設(shè)計(jì)目標(biāo)是把矩陣乘法做到極致。為此TPU 采用了一種叫“脈動(dòng)陣列”的結(jié)構(gòu)數(shù)據(jù)像波浪一樣在計(jì)算單元陣列里流動(dòng)每個(gè)單元只做最簡(jiǎn)單的乘加運(yùn)算但整個(gè)陣列能在一個(gè)時(shí)鐘周期內(nèi)完成大量矩陣運(yùn)算。和 GPU 不一樣TPU 不是“通用計(jì)算卡”它更像一條專門為矩陣乘法定制的流水線工廠。你把一個(gè)矩陣乘法的任務(wù)交給它它能在極短的時(shí)間內(nèi)交付但如果你想讓它跑一個(gè)不規(guī)則的算法、一個(gè)冷門的算子對(duì)不起效率會(huì)大幅下降甚至根本不支持。TPU 的另一個(gè)特點(diǎn)是片上存儲(chǔ)巨大TPU v5e 每顆芯片有 16GB 的 HBM但在架構(gòu)上它更依賴高帶寬的片上存儲(chǔ)來喂飽計(jì)算陣列。配合 XLA 編譯器做聯(lián)合優(yōu)化訓(xùn)練超大規(guī)模模型的效率非常驚人。Gemini、Gemma 這些模型就是靠 TPU 集群訓(xùn)練出來的。但它的問題也很明顯封閉生態(tài)。用 TPU 基本意味著你要接受 JAX 或 TensorFlow 的編程模型PyTorch 雖然也能跑但支持度和性能都存在折扣。更要命的是 TPU 不對(duì)外售賣只能通過 Google Cloud 租用硬件規(guī)格、配額大小都是云廠商說了算。1.3 LPU推理賽道的新人思路反著來LPU 是 Groq 公司提出的概念全稱 Language Processing Unit明擺著就是沖著大語言模型推理來的。它的設(shè)計(jì)思路和 GPU、TPU 完全相反——不追求峰值算力而是追求數(shù)據(jù)不搬家。LPU 最激進(jìn)的地方在于它沒有傳統(tǒng)意義上那種依賴外部顯存的架構(gòu)而是把巨大的 SRAM靜態(tài)隨機(jī)存取存儲(chǔ)器直接堆在芯片上。模型權(quán)重加載進(jìn)去之后計(jì)算過程中幾乎不需要到外部?jī)?nèi)存取數(shù)據(jù)。這一下就把“內(nèi)存帶寬瓶頸”這個(gè)老大難問題給繞開了。所以 LPU 做 LLM 推理時(shí)延遲能做到極低通常幾十毫秒內(nèi)出 token。我實(shí)測(cè) GroqCloud 上的 Llama-3-70B 模型首 token 延遲和每 token 速度都能到毫秒級(jí)體感比常規(guī) GPU 推理快了一個(gè)量級(jí)。代價(jià)是什么什么都得自己適配。LPU 本質(zhì)上是“為編譯期調(diào)度而生”的架構(gòu)運(yùn)行前需要用它的 Halo 編譯器把計(jì)算圖排好模型轉(zhuǎn)換、算子適配的功夫少不了。且因?yàn)槠?SRAM 容量有限Groq 芯片大概是 230MB 級(jí)別能放的模型規(guī)模也受限跑超長(zhǎng)上下文的大模型時(shí)大權(quán)重?zé)o法一次性放進(jìn)去碎片化處理綜合吞吐未必占優(yōu)。LPU 目前并不是什么活都能干的通用芯片而是專攻“在線推理”這一件事的偏門利器。一句話總結(jié)三家定位芯片設(shè)計(jì)目標(biāo)代表產(chǎn)品生態(tài)難度擅長(zhǎng)場(chǎng)景GPU通用并行計(jì)算NVIDIA A100/H100、AMD MI300X低PyTorch/CUDA 全通吃訓(xùn)練、微調(diào)、推理、多模態(tài)TPU大規(guī)模矩陣運(yùn)算TPU v4/v5e、TPU Pod高JAX/TensorFlow 為佳超大規(guī)模預(yù)訓(xùn)練、張量密集型任務(wù)LPULLM 在線推理Groq LPU、GroqCloud高需 Halo 編譯器適配低延遲在線推理、單 token 高速生成這三種方案本質(zhì)上都是“馮諾依曼瓶頸”的解題思路。算力增長(zhǎng)永遠(yuǎn)比內(nèi)存帶寬快GPU 選擇用高帶寬顯存硬撐TPU 用脈動(dòng)陣列減少數(shù)據(jù)搬運(yùn)次數(shù)LPU 干脆把所有數(shù)據(jù)堆在芯片上不搬了。2. 從訓(xùn)練到推理性價(jià)比該怎么算2.1 訓(xùn)練場(chǎng)景GPU 生態(tài)護(hù)城河太深了先來算訓(xùn)練這筆賬。市面上主流的開源模型無論是 Llama、Qwen 還是 Mistral權(quán)重格式、微調(diào)腳本、推理框架幾乎全部默認(rèn) GPU 優(yōu)先。PyTorch 的DataLoader、autocast、FSDPHuggingFace 的Trainer這些訓(xùn)練基礎(chǔ)設(shè)施全是圍繞 CUDA 構(gòu)建的。你用 GPU拿到的是一整套成熟工具鏈用 TPU得上 JAX 重寫訓(xùn)練循環(huán)用 LPU現(xiàn)在基本沒法做正經(jīng)訓(xùn)練。以訓(xùn)練一個(gè) 7B 參數(shù)的模型為例一張 A100 80G 跑 FP16 混合精度理論吞吐大概在 150-200 TFLOPs實(shí)際打個(gè)五折一個(gè) epoch 處理幾億 token 下來耗時(shí)在數(shù)小時(shí)到數(shù)天之間。這張卡在主流云平臺(tái)的租用價(jià)格大概 2-3 美元每小時(shí)。如果是想跑 70B 甚至更大的模型單卡顯存不夠就得上多卡并行。NVIDIA 的 NVLink 和 NCCL 通信庫把多卡互聯(lián)這件事做到了開箱即用的水平四卡、八卡甚至幾十卡的集群都能比較平滑地?cái)U(kuò)起來。TPU 在純算力上其實(shí)不輸 GPU甚至在大規(guī)模數(shù)據(jù)并行時(shí)表現(xiàn)更優(yōu)。Google 內(nèi)部那套高效訓(xùn)練流程是圍繞 TPU Pod 建的幾千顆芯片組成一個(gè)集群算力密度遠(yuǎn)超普通 GPU 機(jī)房。但對(duì)絕大多數(shù)團(tuán)隊(duì)來說這個(gè)優(yōu)勢(shì)根本夠不著你首先要能申請(qǐng)到 TPU 配額云上稀缺其次要把訓(xùn)練代碼遷移到 JAX調(diào)試 XLA 編譯報(bào)錯(cuò)和算子不支持的問題這一套下來耗費(fèi)的工程師時(shí)間可能比省下的算力錢還貴。所以訓(xùn)練場(chǎng)景的性價(jià)比可以歸納成一個(gè)公式綜合成本 單位算力價(jià)格 × 訓(xùn)練時(shí)長(zhǎng) × 人工適配成本。GPU 贏在最后一項(xiàng)幾乎為零。除非你團(tuán)隊(duì)的工程能力足夠強(qiáng)且訓(xùn)練規(guī)模大到了 TPU 的算力優(yōu)勢(shì)能覆蓋遷移成本否則第一階段老老實(shí)實(shí)租 GPU 是最穩(wěn)的選擇。2.2 微調(diào)場(chǎng)景真正決定花銷的是顯存微調(diào)這件事如今已經(jīng)被 LoRA、QLoRA 這類參數(shù)高效微調(diào)手段給“卷”下來了。理論上一張 24GB 顯存的消費(fèi)級(jí)顯卡RTX 4090就能對(duì) 7B 模型做 QLoRA 微調(diào)這在兩三年前是不可想象的。哪怕你想微調(diào) 70B 級(jí)別的模型用 4-bit 量化加 LoRA單卡 48GB 以上的專業(yè)卡也能跑。我的經(jīng)驗(yàn)是微調(diào)場(chǎng)景下性價(jià)比的核心不是芯片架構(gòu)而是顯存容量和帶寬。LoRA 只訓(xùn)練少量低秩矩陣計(jì)算量不大但模型權(quán)重和激活值仍然占據(jù)顯存。假設(shè)一個(gè) 7B 模型在 FP16 下權(quán)重占約 14GBQLoRA 4-bit 后降到 4GB 左右加上激活、梯度一張 24GB 卡剛好能裝下。用租卡的方式來算一張 24GB 顯存、性能接近 A10 的云卡價(jià)格大約在 0.7-1 美元每小時(shí)。一個(gè) 7B 模型的 LoRA 微調(diào)數(shù)據(jù)量不大時(shí) 2-4 個(gè) epoch 通常在 2-4 小時(shí)內(nèi)能收斂算下來單次微調(diào)成本在 2-4 美元。這個(gè)量級(jí)的開銷單獨(dú)為微調(diào)去采購整張專業(yè)卡反而不劃算租就完了。TPU 在微調(diào)場(chǎng)景上最大的問題是配額和形態(tài)。Colab 上能免費(fèi)蹭到的 TPU 是 v2-8單片能力大概只相當(dāng)于一張中等顯卡而真正的 TPU v5e 在云上按片計(jì)費(fèi)價(jià)格并不比同級(jí)別的 GPU 便宜多少。更關(guān)鍵的是JAX 生態(tài)里雖然也有 LoRA 實(shí)現(xiàn)但很多 HuggingFace 上的 PEFT 工具鏈沒法直接用遷移成本還是高。2.3 推理場(chǎng)景LPU 低延遲到底值多少錢推理是最容易把“性價(jià)比”算清楚也最容易算錯(cuò)賬的場(chǎng)景。先區(qū)分兩種推理需求在線低延遲推理和離線批處理推理。這兩種需求對(duì)芯片的要求完全不同。離線批處理比如晚上批量生成一批摘要、處理一批分類任務(wù)延遲要求不高大家更關(guān)心吞吐量和單 token 成本。這種場(chǎng)景下 GPU 配 vLLM、TensorRT-LLM 這類推理引擎已經(jīng)優(yōu)化得很成熟吞吐量可以拉到很高性價(jià)比很穩(wěn)。TPU 在這種場(chǎng)景下也能用TensorFlow Serving 和 JAX 推理在 TPU 上都能跑但因?yàn)樯鷳B(tài)小眾部署工具鏈要自己搭。在線低延遲推理比如聊天機(jī)器人、代碼補(bǔ)全、實(shí)時(shí)翻譯用戶對(duì)“第一個(gè)字出來的時(shí)間”極其敏感。這時(shí)候 LPU 的價(jià)值就體現(xiàn)出來了。我實(shí)測(cè)過的 GroqCloud API跑 Llama-3-70B 這種大模型首 token 延遲能做到幾十毫秒級(jí)別每 token 生成速度達(dá)到數(shù)百 token 每秒。同樣的模型用 GPU 加 vLLM 部署首 token 延遲通常會(huì)到幾百毫秒生成速度一兩百 token 每秒已經(jīng)算優(yōu)秀了。不是說 GPU 不行而是 LPU 的片上存儲(chǔ)架構(gòu)天然適合低延遲場(chǎng)景。但 LPU 的性價(jià)比有個(gè)隱蔽陷阱按 token 計(jì)費(fèi)。GroqCloud 的 API 價(jià)格看起來不高但如果你有持續(xù)、大規(guī)模的推理流量按 token 累計(jì)的成本會(huì)非?？?。相比之下GPU 是按時(shí)租用只要業(yè)務(wù)運(yùn)轉(zhuǎn)資源可以按需伸縮。如果要長(zhǎng)期支撐百萬級(jí)日活用戶、每天處理數(shù)十億 tokenLPU 的按量賬單大概率比租用 GPU 集群更貴。所以買不買 LPU 的賬取決于你的業(yè)務(wù)模式業(yè)務(wù)類型推薦方案理由高并發(fā)、低延遲 C 端產(chǎn)品LPU或 GPU優(yōu)化引擎用戶體驗(yàn)依賴延遲LPU 優(yōu)勢(shì)顯著高吞吐、延遲不敏感任務(wù)GPU 批處理單位 token 成本更低生態(tài)成熟多模型、多任務(wù)混跑GPU靈活性最高推理引擎支持模型切換超大規(guī)模、內(nèi)部有 JAX 團(tuán)隊(duì)TPU成本可控且算力密度大2.4 成本賬本租卡、按量計(jì)費(fèi)與隱性成本選定了場(chǎng)景還有一層賬要算清楚算力從哪來。自有硬件、云上租卡、API 按量計(jì)費(fèi)三種方式的成本結(jié)構(gòu)完全不同。自有硬件的賬是這么算的一張 A100 80G 的市場(chǎng)價(jià)大概在 1.5-2 萬美元左右按照 GPU 卡 3-5 年的折舊周期算每月折舊成本在 400-500 美元。還要加上機(jī)房電費(fèi)一張 A100 功耗 400W加上散熱一個(gè)月電費(fèi)輕松上百美元、機(jī)房租金、運(yùn)維人力、故障替換。算下來一張自購卡每個(gè)月真實(shí)成本可能在 800-1200 美元。而云上租用同等規(guī)格的卡包月價(jià)格通常也在 800-1500 美元區(qū)間。自購的優(yōu)勢(shì)主要體現(xiàn)在“高利用率”場(chǎng)景如果你能把這臺(tái)機(jī)器 24 小時(shí)跑滿自學(xué)肯定劃算否則很容易變成“花錢買閑置”。云上租卡的彈性更大按小時(shí)計(jì)費(fèi)高峰擴(kuò)、低谷縮。它的隱性成本在于數(shù)據(jù)存儲(chǔ)和網(wǎng)絡(luò)傳輸模型權(quán)重在云端多個(gè)實(shí)例間復(fù)制、訓(xùn)練數(shù)據(jù)上傳下載這些流量費(fèi)用在賬單里可能比算力本身還醒目。建議拿到賬單后單獨(dú)看“Egress”“Storage”兩項(xiàng)很多人第一次看到都會(huì)被嚇一跳。API 按量計(jì)費(fèi)模式最省心尤其適合中小團(tuán)隊(duì)和驗(yàn)證期項(xiàng)目但要注意它不適合高頻大規(guī)模調(diào)用。量大的話要么和廠商談?wù)劭垡锤纱嗲谢?GPU 租用模式自己部署。3. 實(shí)操三類芯片我都怎么上手用3.1 GPU 環(huán)境三步配好驅(qū)動(dòng)、CUDA、PyTorch別嫌基礎(chǔ)GPU 環(huán)境配錯(cuò)的人太多了。我之前見過一個(gè)朋友用pip install torch裝完之后跑torch.cuda.is_available()永遠(yuǎn)返回False查了半天才發(fā)現(xiàn)那個(gè) PyPI 默認(rèn)包是 CPU 版需要去 PyTorch 官網(wǎng)按 CUDA 版本重新裝。正確的流程分三步。第一步裝驅(qū)動(dòng)。NVIDIA 官網(wǎng)下載對(duì)應(yīng)型號(hào)的驅(qū)動(dòng)Windows 直接安裝即可Linux 上建議用apt裝nvidia-driver-545這類帶版本號(hào)的包不要用系統(tǒng)默認(rèn)的nouveau開源驅(qū)動(dòng)。裝完執(zhí)行nvidia-smi能看到顯卡型號(hào)和驅(qū)動(dòng)版本就說明 OK 了。第二步裝 CUDA Toolkit。注意兩點(diǎn)一是版本要和驅(qū)動(dòng)匹配工具包官網(wǎng)有個(gè)兼容性矩陣表驅(qū)動(dòng)版本決定了你能裝多新的 CUDA二是如果你只是跑 PyTorch其實(shí)不需要單獨(dú)裝整個(gè) CUDA ToolkitPyTorch 的 wheel 包自帶了 CUDA 運(yùn)行庫你只需要確認(rèn)驅(qū)動(dòng)支持即可。只有在編譯自定義 CUDA 算子或裝特定庫時(shí)才需要完整 Toolkit。第三步裝 PyTorch GPU 版。正確方式是# 去官網(wǎng)選對(duì)應(yīng) CUDA 版本的命令 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121裝完立刻驗(yàn)證import torch print(torch.__version__) print(torch.cuda.is_available()) # True 才正常 print(torch.cuda.get_device_name(0))能打印出 “NVIDIA A100” 之類的設(shè)備名環(huán)境就算成了。一個(gè)小提醒多環(huán)境隔離用 conda但 conda 默認(rèn)源里的 torch 也可能裝成 CPU 版裝之前一定要看安裝日志里帶沒帶cu121這樣的后綴。還有 Windows 用戶容易出現(xiàn)驅(qū)動(dòng)老、CUDA 新導(dǎo)致不匹配的問題建議統(tǒng)一記住一個(gè)經(jīng)驗(yàn)驅(qū)動(dòng)盡量更新CUDA 版本和 PyTorch 版本對(duì)齊別在同一臺(tái)機(jī)器上混裝多套 CUDA Toolkit。3.2 TPU 上手Colab 與 JAX 的配合TPU 的上手路徑我就推薦一個(gè)最接地氣的Google Colab 的免費(fèi) TPU。雖然性能比不上云端 Pod但體驗(yàn)整個(gè)流程完全夠用。Colab 里把“運(yùn)行時(shí)類型”切到 TPU然后安裝 JAX 的 TPU 版本pip install jax[tpu] -f https://storage.googleapis.com/jax-releases/lts/lts_jax_releases.html -q裝完驗(yàn)證一下是否識(shí)別到 TPUimport jax import jax.numpy as jnp # 強(qiáng)制使用 TPU jax.config.update(jax_platform_name, tpu) print(jax.devices())能看到TpuDevice就說明連接成功。跑一個(gè)簡(jiǎn)單的矩陣乘法試試key jax.random.PRNGKey(0) a jax.random.normal(key, (4096, 4096)) b jax.random.normal(key, (4096, 4096)) # JIT 編譯第一次比較慢 matmul_fn jax.jit(lambda x, y: x y) c matmul_fn(a, b) print(c.shape)這里有個(gè)關(guān)鍵點(diǎn)TPU 上跑任何運(yùn)算第一遍都要經(jīng)過 XLA 編譯會(huì)明顯慢一截之后跑就快了。所以如果你在 TPU 上做訓(xùn)練務(wù)必把整個(gè)訓(xùn)練循環(huán)包在jax.jit里否則性能和“裸跑”沒區(qū)別。還有一點(diǎn)要提醒Colab 的免費(fèi) TPU 資源有限長(zhǎng)時(shí)間占用會(huì)被限制。而且 TPU 的顯存其實(shí)是 HBM當(dāng)你通過 JAX 分配內(nèi)存時(shí)經(jīng)常遇到 OOM因?yàn)?JAX 是惰性分配很多錯(cuò)誤直到真正執(zhí)行時(shí)才暴露。建議小規(guī)模驗(yàn)證好邏輯、確認(rèn)內(nèi)存布局沒問題之后再放大數(shù)據(jù)量別一上來就加載十幾 GB 的數(shù)據(jù)。3.3 LPU 接入一個(gè)請(qǐng)求就體驗(yàn)低延遲LPU 最友好的上手方式就是 GroqCloud 的 API不用自己部署硬件注冊(cè)拿個(gè) key 就能體驗(yàn)。最省事的接法是用 OpenAI SDK把 base_url 換成 Groq 的端點(diǎn)代碼改動(dòng)量很小。from openai import OpenAI client OpenAI( api_key你的GROQ_API_KEY, base_urlhttps://api.groq.com/openai/v1, ) response client.chat.completions.create( modelllama-3.1-8b-instant, messages[ {role: user, content: 用一句話解釋什么是大語言模型} ], max_tokens512, temperature0.7, ) print(response.choices[0].message.content)如果你想親自感受 LPU 和 GPU 的延遲差異自己做個(gè)簡(jiǎn)單的計(jì)時(shí)器就行。核心測(cè)兩個(gè)指標(biāo)首 token 延遲從發(fā)送請(qǐng)求到收到第一個(gè) token 的耗時(shí)和生成速度每秒能輸出多少 token。Groq 的流式響應(yīng)配合time模塊能比較直觀地看出差異。我是真的被 Groq 的速度驚到過一次跑了 Llama-3-70B流式輸出幾乎是無停頓地往外蹦字比本地的 4090 推理還快。但也要提醒LPU 目前對(duì)上下文長(zhǎng)度支持有限Groq 的模型規(guī)格頁面上會(huì)標(biāo)注每個(gè)模型的 max context length調(diào)用前務(wù)必確認(rèn)你的輸入長(zhǎng)度在那個(gè)范圍內(nèi)不然會(huì)被直接截?cái)嗷驁?bào)錯(cuò)。4. 常見問題與避坑實(shí)操從報(bào)錯(cuò)到選型都別踩雷4.1 顯存不夠報(bào)警怎么辦跑大模型顯存 OOM 是最常見的報(bào)錯(cuò)尤其用 GPU 時(shí)。很多人一報(bào)錯(cuò)就以為要換更大的卡其實(shí)多數(shù)情況下調(diào)一調(diào)就能跑起來。先看顯存被什么吃了。按占用從大到小排列激活值中間計(jì)算結(jié)果 優(yōu)化器狀態(tài)Adam 的動(dòng)量和方差 梯度 模型權(quán)重。優(yōu)化器狀態(tài)在混合精度訓(xùn)練時(shí)每個(gè)參數(shù)要占 12 字節(jié)FP32 的動(dòng)量和方差各 4 字節(jié)FP32 主權(quán)重 4 字節(jié)比模型本身還吃顯存。手動(dòng)算一遍心里就有底了。解決手段分優(yōu)先級(jí)。第一招開梯度累積把 batch size 拆小顯存不夠時(shí)最干凈的方案。第二招開梯度檢查點(diǎn)gradient_checkpointing用時(shí)間換空間把中間激活不保存、反向時(shí)重算顯存占用能降一半以上。第三招上 LoRA 或 QLoRA把可訓(xùn)練參數(shù)量降到千分之一級(jí)別顯存占用直接少一個(gè)量級(jí)。第四招如果還不行削減序列長(zhǎng)度LLM 顯存和序列長(zhǎng)度近似線性相關(guān)這是很多人忽略的“隱藏開關(guān)”。在云上租卡時(shí)也要注意別被“顯存”這個(gè)單一指標(biāo)忽悠。同樣是 80G 顯存A100 和 H100 的算力差一倍價(jià)格也差一倍。租之前先想清楚你的瓶頸到底是顯存容量還是算力。微調(diào)類任務(wù)顯存敏感H100 的算力優(yōu)勢(shì)反而不明顯從頭預(yù)訓(xùn)練或大批量推理H100 的性價(jià)比才體現(xiàn)得出來。4.2 驅(qū)動(dòng)、CUDA 版本混亂怎么排查GPU 報(bào)錯(cuò)里最常見的幾類都和驅(qū)動(dòng)、CUDA 版本不匹配有關(guān)我把典型的報(bào)錯(cuò)和排查路徑整理成一張表報(bào)錯(cuò)信息大概率原因解決思路CUDA driver version is insufficient驅(qū)動(dòng)版本低于 PyTorch 所需 CUDA 版本升級(jí)驅(qū)動(dòng)或降低 PyTorch 的 CUDA 版本ImportError: libcudnn.so.8: cannot open shared object filecuDNN 未安裝或版本不對(duì)安裝匹配的 cuDNN或改用自帶 cuDNN 的 PyTorch wheeltorch.cuda.is_available()返回 False裝成了 CPU 版 torch按官網(wǎng)命令重裝 GPU 版NVRM: GPU is fallen off the bus云主機(jī) GPU 被物理移除或驅(qū)動(dòng)崩潰重啟云實(shí)例檢查實(shí)例規(guī)格是否變更CUDA error: out of memory顯存耗盡按 4.1 的步驟調(diào) batch 或精度這里有幾個(gè)實(shí)操心得。第一看到CUDA driver version is insufficient不要急著重裝 CUDA先運(yùn)行nvidia-smi看右上角的 “CUDA Version”那才是驅(qū)動(dòng)支持的最高版本。如果驅(qū)動(dòng)支持 12.2你裝 PyTorch 的 cu121 版本就完全沒問題。第二不要在系統(tǒng)級(jí)環(huán)境里同時(shí)裝多套 CUDA、cuDNN用 conda 或 venv 把每個(gè)項(xiàng)目的依賴隔離干凈項(xiàng)目之間互不干擾。第三云上租卡出現(xiàn) GPU 被移除、驅(qū)動(dòng)崩潰這類問題優(yōu)先重啟實(shí)例很多臨時(shí)性問題重啟就自愈了。4.3 TPU 與 LPU 的限制是明牌別硬碰TPU 和 LPU 的優(yōu)點(diǎn)很突出但限制更突出最怕的就是大家抱著“嘗鮮”心態(tài)沖進(jìn)去最后發(fā)現(xiàn)和現(xiàn)有技術(shù)棧不兼容。TPU 的核心限制有三個(gè)。第一編程模型必須是 JAX 或 TensorFlowPyTorch 雖然能通過 PJRT 橋接跑但算子支持不全容易回退到 CPU 導(dǎo)致性能雪崩。第二分布式訓(xùn)練時(shí) TPU Pod 的互聯(lián)拓?fù)涫枪潭ǖ哪愕哪Ｐ筒⑿胁呗员仨氠槍?duì)它的拓?fù)渥鲈O(shè)計(jì)不像 GPU 集群那樣隨便改。第三云上 TPU 配額是稀缺資源申請(qǐng)大規(guī)格 Pod 可能要排期對(duì)時(shí)效性要求高的項(xiàng)目根本等不起。LPU 的限制更直接。第一模型要經(jīng)過 Halo 編譯器適配不是隨便拿個(gè) PyTorch 模型就能跑目前支持的模型譜系有限。第二片上 SRAM 容量有限超長(zhǎng)上下文場(chǎng)景比如 32K 以上輸入會(huì)很吃力甚至直接不支持。第三API 按 token 計(jì)費(fèi)業(yè)務(wù)量上來后成本不可控。我見過一個(gè)小團(tuán)隊(duì)把 Groq 當(dāng)主力推理結(jié)果一個(gè)月 API 賬單比之前租 GPU 貴了一倍多因?yàn)樗麄兊膱?chǎng)景是大量長(zhǎng)文本批處理根本不適合 LPU。選型前請(qǐng)對(duì)照一下自己團(tuán)隊(duì)的技術(shù)棧和業(yè)務(wù)場(chǎng)景團(tuán)隊(duì)情況建議不建議PyTorch 重度用戶、訓(xùn)練推理都要做GPU 租用或自購直接上 TPU 或 LPU已有 JAX 工程經(jīng)驗(yàn)、部署大規(guī)模訓(xùn)練TPU 可以認(rèn)真評(píng)估為了 TPU 臨時(shí)學(xué) JAX新項(xiàng)目只做在線聊天/代碼補(bǔ)全類推理LPU 值得一試用 LPU 跑長(zhǎng)文本批處理預(yù)算有限、團(tuán)隊(duì)人少先 GPU API 或租卡自購硬件或大規(guī)格 TPU最后分享一個(gè)我最近踩的坑。給朋友調(diào)一個(gè) Groq API 接入項(xiàng)目沒仔細(xì)看模型規(guī)格就直接用了默認(rèn)的llama-3.1-70b-versatile結(jié)果輸入一段 30K 字符的長(zhǎng)文檔響應(yīng)直接報(bào)context_length_exceeded錯(cuò)誤。查文檔才發(fā)現(xiàn)這個(gè)模型的 max context 只有 32K tokens按照中文字符換算我的輸入早就超額了。后來換成支持 128K 上下文的模型問題才解決。這件事給我的教訓(xùn)是用任何算力平臺(tái)之前先讀它的規(guī)格文檔尤其是上下文長(zhǎng)度和計(jì)費(fèi)方式這兩項(xiàng)最容易在項(xiàng)目上線后暴雷。我個(gè)人在實(shí)際項(xiàng)目里的選擇邏輯是如果沒有特殊理由第一選擇永遠(yuǎn)是 GPU——不是因?yàn)樗阅茏顝?qiáng)而是因?yàn)樗睢安徽垓v”。等業(yè)務(wù)穩(wěn)定、用量起來之后再根據(jù)推理負(fù)載、成本結(jié)構(gòu)去橫向評(píng)估是否引入 TPU 或 LPU。算力本質(zhì)上就是把錢變成計(jì)算時(shí)間的工具誰能在你當(dāng)前的場(chǎng)景里把每分錢花得最值誰就是那個(gè)“性價(jià)比之王”。