AI 產(chǎn)業(yè)的高速發(fā)展正在改變的不只是軟件生態(tài)還有全球硬件出口結(jié)構(gòu)。公開(kāi)貿(mào)易數(shù)據(jù)中有一個(gè)值得關(guān)注的現(xiàn)象亞洲主要芯片出口地區(qū)在 AI 相關(guān)產(chǎn)品上的出口額首次超過(guò)日本。這說(shuō)明 AI 芯片、高帶寬存儲(chǔ)HBM、AI 服務(wù)器等硬件需求已經(jīng)形成一條真實(shí)且快速增長(zhǎng)的技術(shù)鏈條。對(duì)后端工程師、算法工程師和運(yùn)維工程師來(lái)說(shuō)這個(gè)現(xiàn)象不應(yīng)該只停留在新聞層面而是應(yīng)該理解AI 算力到底由哪些硬件構(gòu)成訓(xùn)練和推理時(shí)資源如何被消耗遇到顯存不足、GPU 利用率低、驅(qū)動(dòng)不匹配時(shí)應(yīng)該從哪里排查。這篇文章會(huì)沿著一條可復(fù)現(xiàn)的主線展開(kāi)先理解 AI 出口增長(zhǎng)背后的算力結(jié)構(gòu)再準(zhǔn)備一套能在本地或云上運(yùn)行的 GPU 環(huán)境接著用一個(gè)小模型驗(yàn)證顯存消耗并部署一個(gè)最小推理服務(wù)最后給出從驅(qū)動(dòng)到推理的排錯(cuò)鏈路和工程化建議。即使你現(xiàn)在沒(méi)有 GPU也可以先按文中思路在云 GPU 實(shí)例上操作核心邏輯不會(huì)變。1. 不要只把 AI 出口增長(zhǎng)當(dāng)新聞先看懂它背后的算力結(jié)構(gòu)1.1 大模型訓(xùn)練和推理為什么離不開(kāi)專(zhuān)用硬件大模型訓(xùn)練的核心是大量矩陣乘法。以常見(jiàn)的 7B 參數(shù)模型為例一次前向計(jì)算需要對(duì)數(shù)百億個(gè)參數(shù)做矩陣運(yùn)算這些參數(shù)不能每次從磁盤(pán)加載必須常駐顯存。用 FP16 精度表示每個(gè)參數(shù)占 2 字節(jié)所以 70 億參數(shù)僅權(quán)重一項(xiàng)就需要約 14GB 顯存。這還沒(méi)有計(jì)算梯度、優(yōu)化器狀態(tài)和激活值。訓(xùn)練階段比推理階段更占顯存。Adam 優(yōu)化器會(huì)為每個(gè)參數(shù)維護(hù)兩倍于參數(shù)大小的額外狀態(tài)梯度本身也占用一份顯存。因此單卡 24GB 要訓(xùn)練一個(gè) 7B 模型會(huì)非常緊張通常需要混合精度、梯度累積和分布式策略配合。這也解釋了為什么 AI 芯片廠商會(huì)把“顯存容量”和“顯存帶寬”作為核心指標(biāo)。推理階段雖然不需要優(yōu)化器狀態(tài)但長(zhǎng)文本生成時(shí)KV Cache 會(huì)隨著序列長(zhǎng)度快速膨脹。并發(fā)請(qǐng)求越多顯存占用越不可控。這也是為什么 AI 推理框架會(huì)反復(fù)強(qiáng)調(diào) PagedAttention、連續(xù)批處理和量化。1.2 HBM 和先進(jìn)封裝出口增長(zhǎng)鏈條里的關(guān)鍵部件傳統(tǒng)顯卡使用 GDDR 顯存成本低、容量大但帶寬受限于位寬。HBM 的思路是使用 3D 堆疊技術(shù)把多顆 DRAM 芯片垂直堆疊起來(lái)再通過(guò)硅中介層與 GPU 或加速芯片封裝在一起。這樣縮小了顯存與計(jì)算核心之間的物理距離將數(shù)據(jù)搬運(yùn)延遲控制在很低的水平。HBM 的核心特點(diǎn)可以這樣理解高帶寬滿足大規(guī)模矩陣運(yùn)算對(duì)數(shù)據(jù)吞吐的需求。節(jié)省面積堆疊結(jié)構(gòu)比多顆獨(dú)立顯存顆粒更緊湊。功耗相對(duì)可控同樣帶寬下HBM 比 GDDR 更省電。AI 加速芯片為了喂飽計(jì)算單元需要 TB/s 級(jí)別的顯存帶寬。傳統(tǒng) GDDR 在帶寬上很難滿足因此 HBM 成為 AI 芯片的重要選擇。先進(jìn)封裝技術(shù)則負(fù)責(zé)把這些器件整合進(jìn)同一顆芯片內(nèi)部制造難度和成本都顯著高于普通封裝。1.3 AI 服務(wù)器和傳統(tǒng)服務(wù)器的本質(zhì)區(qū)別傳統(tǒng)服務(wù)器以 CPU 為中心擴(kuò)展性主要體現(xiàn)在內(nèi)存容量和網(wǎng)絡(luò)吞吐上。AI 服務(wù)器則以 GPU 或?qū)Ｓ眉铀倏樗懔χ行恼麢C(jī)設(shè)計(jì)要圍繞加速卡的功耗、散熱、NVLink 互聯(lián)和高速網(wǎng)絡(luò)展開(kāi)。維度傳統(tǒng)服務(wù)器AI 服務(wù)器核心計(jì)算單元多路 CPU多張 GPU / 加速卡內(nèi)存普通 DDR顯存 CPU 內(nèi)存關(guān)鍵帶寬內(nèi)存帶寬、網(wǎng)卡帶寬顯存帶寬、卡間互聯(lián)帶寬功耗通常數(shù)百瓦到一千瓦單卡數(shù)百瓦整機(jī)可達(dá)數(shù)千瓦散熱方式風(fēng)冷為主風(fēng)冷、冷板式液冷或浸沒(méi)式液冷軟件棧虛擬化、數(shù)據(jù)庫(kù)、大數(shù)據(jù)CUDA、PyTorch、容器調(diào)度、推理引擎對(duì)普通開(kāi)發(fā)者來(lái)說(shuō)最直觀的差異是運(yùn)行環(huán)境的變化。在 AI 服務(wù)器上部署服務(wù)不只要考慮應(yīng)用本身還要確認(rèn)驅(qū)動(dòng)、CUDA 版本、顯卡算力、顯存配額和溫度功耗限制。1.4 出口數(shù)據(jù)背后的技術(shù)含義AI 相關(guān)產(chǎn)品出口增長(zhǎng)說(shuō)明的不只是某一家公司賣(mài)出了更多加速卡而是整條產(chǎn)業(yè)鏈在同時(shí)放量高帶寬存儲(chǔ)、先進(jìn)封裝、電源模塊、高速 PCB、散熱組件、網(wǎng)絡(luò)交換設(shè)備都在跟進(jìn)。對(duì)工程師而言這意味著未來(lái)工作中會(huì)遇到更多 AI 工作負(fù)載需要學(xué)會(huì)配置 GPU 環(huán)境、監(jiān)控顯存、優(yōu)化推理延遲。2. 先搭一個(gè)可復(fù)現(xiàn)的 GPU 開(kāi)發(fā)環(huán)境再談優(yōu)化2.1 環(huán)境準(zhǔn)備清單無(wú)論你是使用本地工作站還是在云廠商購(gòu)買(mǎi) GPU 實(shí)例都需要先確認(rèn)以下軟件環(huán)境。下面是一份常見(jiàn)組合實(shí)際版本請(qǐng)以項(xiàng)目依賴(lài)為準(zhǔn)。組件推薦范圍說(shuō)明操作系統(tǒng)Ubuntu 20.04 / 22.04對(duì) CUDA 兼容性最好NVIDIA 驅(qū)動(dòng)525 及以上越新越能支持新卡但也要匹配 CUDACUDA11.8 或 12.x需要和 PyTorch 編譯版本匹配Python3.9 至 3.11多數(shù) AI 框架和工具鏈支持PyTorch2.x自帶 CUDA 支持安裝時(shí)需要選擇對(duì)應(yīng)版本安裝 PyTorch 時(shí)要注意默認(rèn)從 PyPI 安裝的版本可能不包含 CUDA 支持。正確做法是訪問(wèn) PyTorch 官方安裝命令選擇你當(dāng)前 CUDA 版本對(duì)應(yīng)的安裝源。2.2 先用三行命令確認(rèn)驅(qū)動(dòng)和 CUDA 狀態(tài)進(jìn)入環(huán)境后第一步不是直接跑模型而是確認(rèn)驅(qū)動(dòng)是否工作。nvidia-smi輸出會(huì)包含顯卡型號(hào)、驅(qū)動(dòng)版本、CUDA 版本、顯存總量、當(dāng)前溫度、功耗和利用率。例如----------------------------------------------------------------------------- | NVIDIA-SMI 525.85.12 Driver Version: 525.85.12 CUDA Version: 12.0 | |--------------------------------------------------------------------------- | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | || | 0 Tesla T4 On | 00000000:00:1B.0 Off | 0 | | N/A 42C P0 21W / 70W | 0MiB / 15360MiB | 0% Default | -----------------------------------------------------------------------------再檢查編譯工具鏈nvcc -Vnvidia-smi顯示的 CUDA 版本是當(dāng)前驅(qū)動(dòng)支持的最高版本nvcc -V顯示的是實(shí)際安裝的 CUDA Toolkit 版本。兩者可以不同。開(kāi)發(fā)時(shí)必須讓 PyTorch 的 CUDA 版本和nvcc版本保持一致否則可能出現(xiàn)在編譯擴(kuò)展時(shí)找不到頭文件的問(wèn)題。2.3 在 Python 里確認(rèn) PyTorch 能訪問(wèn) GPU驅(qū)動(dòng)正常后創(chuàng)建一個(gè)虛擬環(huán)境并安裝 PyTorch。然后運(yùn)行下面這段代碼import torch print(torch version:, torch.__version__) print(cuda available:, torch.cuda.is_available()) if torch.cuda.is_available(): device torch.device(cuda) x torch.randn(1024, 1024, devicedevice) y (x * x).sum() print(cuda device:, torch.cuda.get_device_name(0)) print(result:, y.item()) else: print(CUDA not available, check driver and PyTorch version.)如果輸出中cuda available: True說(shuō)明 PyTorch 已經(jīng)能調(diào)用 GPU。這段代碼非常簡(jiǎn)單但它能一次性排除絕大多數(shù)環(huán)境問(wèn)題cuda available為 False請(qǐng)檢查驅(qū)動(dòng)、CUDA 版本和 PyTorch 安裝源。如果執(zhí)行x torch.randn(1024, 1024, devicedevice)報(bào)錯(cuò)通常是顯存或權(quán)限問(wèn)題。2.4 學(xué)習(xí)環(huán)境和生產(chǎn)環(huán)境的差異本地開(kāi)發(fā)可以用單卡快速驗(yàn)證生產(chǎn)環(huán)境則要提前考慮容器化。推薦在 Docker 鏡像中固定 CUDA 和 PyTorch 版本。官方鏡像通常以nvidia/cuda為基礎(chǔ)再疊加 Python 依賴(lài)。這樣即使不同項(xiàng)目需要不同 CUDA 版本也可以通過(guò)容器隔離避免污染宿主機(jī)環(huán)境。注意不要只驗(yàn)證程序能啟動(dòng)。還要驗(yàn)證 GPU 確實(shí)被調(diào)用否則模型可能默默跑在 CPU 上訓(xùn)練速度慢幾十倍卻找不到原因。3. 用監(jiān)控腳本驗(yàn)證模型的每一份顯存都花在哪里3.1 顯存是 AI 場(chǎng)景的第一個(gè)硬約束顯存不像 CPU 內(nèi)存那樣容易彈性擴(kuò)展。一張 24GB 的顯卡可用的就是 24GB一旦超限就會(huì)直接觸發(fā) Out of Memory。模型訓(xùn)練時(shí)的顯存占用大致由這幾部分組成模型權(quán)重梯度優(yōu)化器狀態(tài)激活值臨時(shí)計(jì)算緩沖區(qū)推理階段主要是模型權(quán)重、激活值和 KV Cache。如果使用 Hugging Face 的transformers庫(kù)加載模型時(shí)可以通過(guò)model.hf_device_map和model.dtype查看模型放置位置和精度。更多時(shí)候最簡(jiǎn)單的方法是在運(yùn)行模型前后觀察顯存變化。3.2 使用 pynvml 寫(xiě)一個(gè)輕量監(jiān)控腳本NVIDIA 官方提供了nvidia-ml-py庫(kù)可以在 Python 中讀取 GPU 信息。安裝后即可編寫(xiě)監(jiān)控腳本pip install nvidia-ml-py然后創(chuàng)建一個(gè)monitor_gpu.pyimport time import pynvml pynvml.nvmlInit() count pynvml.nvmlDeviceGetCount() try: while True: for i in range(count): handle pynvml.nvmlDeviceGetHandleByIndex(i) util pynvml.nvmlDeviceGetUtilizationRates(handle) mem pynvml.nvmlDeviceGetMemoryInfo(handle) temp pynvml.nvmlDeviceGetTemperature( handle, pynvml.NVML_TEMPERATURE_GPU ) total_gb mem.total / 1024**3 used_gb mem.used / 1024**3 print( fGPU {i}: util{util.gpu}%, fmem{used_gb:.2f}/{total_gb:.2f}GB, ftemp{temp}C ) time.sleep(2) finally: pynvml.nvmlShutdown()這個(gè)腳本每?jī)擅胨⑿乱淮巍Ｔ跊](méi)有負(fù)載時(shí)顯存占用很低啟動(dòng)模型后顯存會(huì)瞬間上升生成或訓(xùn)練過(guò)程中GPU 利用率會(huì)接近峰值。3.3 運(yùn)行監(jiān)控并記錄輸出在沒(méi)有負(fù)載時(shí)輸出接近GPU 0: util0%, mem0.00/24.00GB, temp39C啟動(dòng)一個(gè)模型推理后輸出可能變成GPU 0: util96%, mem4.82/24.00GB, temp67C第一行告訴你環(huán)境是干凈的第二行說(shuō)明模型確實(shí)被加載到了 GPU并且計(jì)算占用了帶寬。如果運(yùn)行模型時(shí)util依然接近 0則需要懷疑數(shù)據(jù)加載或 CPU 預(yù)處理卡住了。3.4 生產(chǎn)監(jiān)控建議本地腳本適合調(diào)試生產(chǎn)環(huán)境建議接入標(biāo)準(zhǔn)監(jiān)控體系。NVIDIA 提供了 DCGMData Center GPU Manager可以輸出更細(xì)粒度的指標(biāo)。配合 Prometheus 和 Grafana可以把 GPU 利用率、顯存占用、溫度、功耗、NVLink 流量都展示在面板上。指標(biāo)工具用途GPU 利用率DCGM判斷算力是否打滿顯存占用DCGM判斷是否需要擴(kuò)容或調(diào)優(yōu)溫度DCGM / nvidia-smi判斷散熱是否正常功耗DCGM判斷是否觸發(fā)功耗墻卡間通信速率DCGM / nvbandwidth判斷多卡并行效率4. 部署一個(gè)最小推理服務(wù)驗(yàn)證顯存估算與推理優(yōu)化4.1 使用 Hugging Face 加載一個(gè)小模型為了快速看到顯存變化可以安裝transformers并加載一個(gè)小模型。這里使用distilgpt2它是 GPT-2 的蒸餾版本體積小適合在開(kāi)發(fā)環(huán)境驗(yàn)證流程。pip install transformers torch fastapi uvicorn先寫(xiě)一段加載并生成文本的腳本from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_name distilgpt2 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name).to(cuda) inputs tokenizer(AI hardware export, return_tensorspt).to(cuda) with torch.inference_mode(): outputs model.generate(**inputs, max_new_tokens20) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))運(yùn)行時(shí)需要聯(lián)網(wǎng)下載模型權(quán)重。首次下載會(huì)慢一些之后模型會(huì)緩存在本地的~/.cache/huggingface目錄中。運(yùn)行期間可以開(kāi)另一個(gè)終端執(zhí)行監(jiān)控腳本會(huì)看到顯存被占用。4.2 顯存不足時(shí)的幾種調(diào)整手段不同模型、不同并發(fā)策略下顯存消耗差異很大。遇到CUDA out of memory時(shí)按順序嘗試以下手段方法說(shuō)明適合場(chǎng)景設(shè)置torch_dtypetorch.float16用半精度加載模型權(quán)重占用減半推理為主開(kāi)啟device_mapauto自動(dòng)將層放到 GPU 或 CPU單卡顯存不足使用 4bit / 8bit 量化進(jìn)一步壓縮權(quán)重大模型本地推理減小max_new_tokens降低 KV Cache 占用短文本生成降低并發(fā)請(qǐng)求避免多個(gè)請(qǐng)求同時(shí)占用顯存生產(chǎn)服務(wù)例如加載時(shí)指定半精度model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto )這樣權(quán)重從 FP32 變?yōu)?FP16顯存占用可減少一半。4.3 包裝成 FastAPI 推理接口把上面的邏輯封裝成 HTTP 接口方便后面接入業(yè)務(wù)系統(tǒng)from fastapi import FastAPI from pydantic import BaseModel from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_name distilgpt2 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto ) app FastAPI() class GenerateRequest(BaseModel): text: str class GenerateResponse(BaseModel): generated: str app.post(/generate, response_modelGenerateResponse) def generate(req: GenerateRequest): inputs tokenizer(req.text, return_tensorspt).to(cuda) with torch.inference_mode(): outputs model.generate(**inputs, max_new_tokens30) result tokenizer.decode(outputs[0], skip_special_tokensTrue) return GenerateResponse(generatedresult)啟動(dòng)服務(wù)uvicorn app:app --host 0.0.0.0 --port 8000用 curl 測(cè)試curl -X POST http://127.0.0.1:8000/generate \ -H Content-Type: application/json \ -d {text: AI development}正常返回會(huì)包含生成的文本。4.4 優(yōu)化前后的驗(yàn)證方式優(yōu)化前先記錄一次峰值顯存優(yōu)化后再記錄一次。對(duì)比對(duì)象不是“誰(shuí)的代碼更短”而是顯存峰值下降多少生成速度是否可接受輸出質(zhì)量是否變化如果量化后輸出明顯變差說(shuō)明壓縮過(guò)度需要換更大的模型或更高的精度。這個(gè)取舍沒(méi)有絕對(duì)標(biāo)準(zhǔn)只能根據(jù)業(yè)務(wù)要求判斷。注意不要只驗(yàn)證模型能加載還要驗(yàn)證并發(fā)請(qǐng)求下的顯存變化。單請(qǐng)求和十并發(fā)請(qǐng)求的顯存占用差異可能非常大。5. 從驅(qū)動(dòng)到推理遇到報(bào)錯(cuò)按這條鏈路排查5.1 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因檢查方式處理建議torch.cuda.is_available()為 False驅(qū)動(dòng)未安裝或 PyTorch 版本不匹配nvidia-smipython -c import torch; print(torch.cuda.is_available())安裝匹配 driver 和 PyTorch CUDA 版本CUDA out of memory顯存不足或程序未釋放顯存監(jiān)控腳本觀察顯存減小 batch、量化、換大顯存卡GPU 利用率很低CPU 數(shù)據(jù)加載成為瓶頸nvidia-smi觀察利用率增加 DataLoadernum_workers檢查預(yù)處理耗時(shí)溫度過(guò)高且降頻風(fēng)道堵塞或散熱模塊故障nvidia-smi -q -d TEMPERATURE清理散熱調(diào)整功耗上限推理速度很慢未使用torch.inference_mode()檢查代碼上下文推理時(shí)使用torch.inference_mode()多卡訓(xùn)練不收斂卡間通信配置錯(cuò)誤使用nvbandwidth測(cè)試互聯(lián)帶寬檢查 NVLink、網(wǎng)卡和集合通信庫(kù)版本5.2 先看驅(qū)動(dòng)再看框架版本遇到 CUDA 相關(guān)報(bào)錯(cuò)最忌諱的是盲目重裝驅(qū)動(dòng)。先按下面順序排查nvidia-smi是否能列出 GPU。如果命令都不存在說(shuō)明驅(qū)動(dòng)未正確安裝。nvcc -V是否顯示了 Toolkit 版本。如果沒(méi)有說(shuō)明只裝了驅(qū)動(dòng)沒(méi)裝 CUDA Toolkit。python -c import torch; print(torch.__version__)是否顯示cu118或cu121之類(lèi)后綴。如果沒(méi)有后綴說(shuō)明 PyTorch 是 CPU 版本。其中最常見(jiàn)的坑是驅(qū)動(dòng)支持 CUDA 12.x但 PyTorch 是從默認(rèn) PyPI 安裝的 CPU 版本導(dǎo)致 import 后torch.cuda.is_available()始終為 False。解決辦法是卸載后按 PyTorch 官網(wǎng)提供的 CUDA 版本命令重新安裝。5.3 顯存不足時(shí)看日志里的設(shè)備編號(hào)報(bào)錯(cuò)日志通常會(huì)包含類(lèi)似RuntimeError: CUDA out of memory. Tried to allocate 512.00 MiB (GPU 0; 23.70 GiB total capacity; 20.12 GiB already allocated; ...)。這里的重點(diǎn)不是最后那句“out of memory”而是already allocated前面的值。如果已分配顯存很高而你并沒(méi)有加載大模型很可能是上次運(yùn)行的程序沒(méi)有退出顯存沒(méi)有釋放?？梢杂胣vidia-smi找出占用進(jìn)程的 PID再確認(rèn)是否屬于當(dāng)前服務(wù)。nvidia-smi輸出中Processes部分會(huì)顯示 GPU 上的進(jìn)程列表。如果看到殘留 Python 進(jìn)程檢查后清理。5.4 顯存沒(méi)有超限但報(bào) OOM 的特殊情況有時(shí)候顯存明明沒(méi)有耗盡但照樣報(bào) CUDA out of memory。這可能是因?yàn)樯暾?qǐng)單個(gè)張量時(shí)剩余顯存碎片化嚴(yán)重或者當(dāng)前卡沒(méi)有空閑連續(xù)內(nèi)存塊。這種情況可以通過(guò)設(shè)置環(huán)境變量開(kāi)啟顯存分配器的內(nèi)存擴(kuò)展或預(yù)分配行為來(lái)緩解export PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128max_split_size_mb控制顯存分配器拆分大塊內(nèi)存的閾值。調(diào)整過(guò)小會(huì)增加分配開(kāi)銷(xiāo)過(guò)大可能造成顯存浪費(fèi)需要根據(jù)實(shí)際模型測(cè)試。6. 從單卡到集群AI 工程實(shí)踐最佳實(shí)踐6.1 環(huán)境檢查清單每次開(kāi)始新的 AI 項(xiàng)目建議先完成這份環(huán)境檢查[ ]nvidia-smi能看到全部 GPU且驅(qū)動(dòng)版本符合要求。[ ]python -c import torch; print(torch.cuda.is_available())輸出為 True。[ ]transformers、torch版本與項(xiàng)目要求一致。[ ] 磁盤(pán)剩余空間足夠存放模型權(quán)重。[ ] 顯存監(jiān)控腳本能正常讀取指標(biāo)。[ ] 服務(wù)端口未被占用。這個(gè)清單不需要多復(fù)雜但能省掉大量環(huán)境類(lèi)問(wèn)題。6.2 上線前必須考慮的問(wèn)題本地能跑通的模型服務(wù)和生產(chǎn)環(huán)境能穩(wěn)定運(yùn)行是兩回事。用容器鎖定版本鏡像中固化 CUDA、PyTorch、Python 版本避免宿主機(jī)升級(jí)導(dǎo)致依賴(lài)錯(cuò)亂。設(shè)置顯存上限在 Docker 或 Kubernetes 中配置 GPU 資源限額避免一個(gè)任務(wù)打滿整張卡。記錄指標(biāo)不只是 GPU 利用率還要記錄請(qǐng)求延遲、生成 token 數(shù)、輸入長(zhǎng)度、隊(duì)列長(zhǎng)度。模型文件離線化生產(chǎn)環(huán)境不建議每次都從 Hugging Face Hub 拉模型提前下載到本地對(duì)象存儲(chǔ)或鏡像目錄。設(shè)置超時(shí)和重試大模型推理耗時(shí)不穩(wěn)定接口層需要配置合理的超時(shí)時(shí)間。做好回滾模型版本和應(yīng)用版本分開(kāi)管理新模型發(fā)布異常時(shí)能快速切換舊模型。這些不是可選項(xiàng)。數(shù)據(jù)、配置、模型、代碼只要有一層失控線上排障都會(huì)非常痛苦。6.3 從單機(jī)推理走向分布式訓(xùn)練如果模型規(guī)模繼續(xù)增長(zhǎng)單卡無(wú)法滿足訓(xùn)練需求就會(huì)引入多卡并行和集群調(diào)度。分布式訓(xùn)練通常涉及數(shù)據(jù)并行、張量并行、流水線并行等策略。數(shù)據(jù)并行適合大部分場(chǎng)景但卡間通信會(huì)成為瓶頸。torchrun是 PyTorch 自帶的啟動(dòng)工具可以簡(jiǎn)化多卡訓(xùn)練啟動(dòng)torchrun --nproc_per_node4 train.py運(yùn)行時(shí)要留意NCCL相關(guān)日志。NCCL 負(fù)責(zé) GPU 之間的集合通信版本和網(wǎng)絡(luò)配置不匹配時(shí)會(huì)報(bào)unexpected connection failure或timeout。檢查點(diǎn)排查順序是網(wǎng)卡驅(qū)動(dòng)、IP 路由、NVIDIA 相關(guān)通信庫(kù)版本、防火墻規(guī)則。6.4 下一步可以怎么學(xué)回到開(kāi)頭提到的 AI 出口增長(zhǎng)現(xiàn)象。硬件只是基礎(chǔ)設(shè)施真正決定業(yè)務(wù)效果的是把大模型用到實(shí)際場(chǎng)景中的能力。當(dāng)前比較值得延伸的方向包括AI Agent學(xué)習(xí)大模型如何調(diào)用工具、管理上下文、處理多輪任務(wù)。AI 應(yīng)用開(kāi)發(fā)掌握提示詞設(shè)計(jì)、RAG 檢索增強(qiáng)生成、向量數(shù)據(jù)庫(kù)。AI 模型部署深入 vLLM、SGLang 等推理引擎理解吞吐和延遲優(yōu)化。AI 平臺(tái)工程學(xué)習(xí) GPU 調(diào)度、容器資源隔離、集群監(jiān)控和成本控制。推薦的學(xué)習(xí)順序是先把本文中的單機(jī)推理跑通再擴(kuò)展監(jiān)控、壓測(cè)和容器化最后再進(jìn)入分布式訓(xùn)練。不要一開(kāi)始就追求大規(guī)模集群否則很多基礎(chǔ)概念沒(méi)有建立起來(lái)環(huán)境問(wèn)題會(huì)覆蓋掉真正要學(xué)的算法和工程知識(shí)。AI 出口數(shù)據(jù)的增長(zhǎng)是產(chǎn)業(yè)鏈對(duì)算力需求最直接的回應(yīng)。作為工程師最重要的是把這些算力資源變成可控、可觀測(cè)、可優(yōu)化的工程能力。環(huán)境可復(fù)現(xiàn)、顯存可監(jiān)控、報(bào)錯(cuò)可排查比臨時(shí)拼湊一個(gè)能跑的程序更有長(zhǎng)期價(jià)值。