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