1. 為什么我建議你把大模型部署在Linux上先聊個(gè)實(shí)際場(chǎng)景。我手里有一臺(tái)二手工作站雙路E5處理器128G內(nèi)存顯卡是一張改過(guò)散熱的RTX 3090 24G。最開(kāi)始我想在Windows上跑大模型圖省事結(jié)果光配CUDA、cuDNN、Python環(huán)境就折騰了一天半——版本不匹配、路徑?jīng)_突、殺毒軟件莫名其妙把我的權(quán)重文件隔離了最后還把系統(tǒng)搞藍(lán)屏了一次。換到Linux之后全程沒(méi)超過(guò)四十分鐘。這不是說(shuō)Windows跑不了而是大模型這套基礎(chǔ)設(shè)施從CUDA驅(qū)動(dòng)到容器運(yùn)行時(shí)再到各個(gè)推理框架絕大部分都是優(yōu)先適配Linux的。PyTorch官方安裝命令Linux和Windows的差別不只是命令格式依賴(lài)庫(kù)的處理邏輯完全不同TensorRT-LLM直接不支持原生WindowsvLLM雖然能跑但官方文檔里連Windows的安裝章節(jié)都寫(xiě)得含糊。做這行的人都懂一句話Linux是生產(chǎn)環(huán)境Windows是桌面環(huán)境。這篇博文面向誰(shuí)兩類(lèi)人。第一類(lèi)是算法工程師手里有訓(xùn)練好的模型或者開(kāi)源權(quán)重想把模型部署到公司的GPU服務(wù)器上提供推理服務(wù)第二類(lèi)是運(yùn)維工程師被安排去搭建模型推理平臺(tái)之前沒(méi)接觸過(guò)大模型相關(guān)的東西。文章里我盡量不寫(xiě)廢話把從零到一的過(guò)程、命令、踩坑點(diǎn)都攤開(kāi)講。娛樂(lè)歸娛樂(lè)干活歸干活這篇是后者。2. 部署前的硬門(mén)檻硬件評(píng)估與顯存計(jì)算2.1 顯卡不是越貴越好先看顯存和算力匹配大模型部署第一個(gè)關(guān)鍵問(wèn)題是你手里的卡到底能跑多大的模型。這里有個(gè)最簡(jiǎn)單的估算公式模型占用顯存約等于參數(shù)量乘以對(duì)應(yīng)精度下的字節(jié)數(shù)再加上激活值、KV Cache和框架開(kāi)銷(xiāo)。以FP16精度為例1B參數(shù)大概占2GB顯存7B參數(shù)就要14GB左右13B接近28GB32B需要64GB70B直接奔著140GB去了。注意這只是模型權(quán)重本身還沒(méi)算推理過(guò)程中的中間緩存。所以很多人問(wèn)“8G顯存能不能跑7B模型”理論上有量化方案可以壓縮到6GB以內(nèi)但位寬越低輸出質(zhì)量越差這個(gè)后面細(xì)說(shuō)。不同顯卡的定位也要區(qū)分RTX 3060 12G / 4060 Ti 16G適合跑7B量化模型體驗(yàn)Qwen2.5-7B、Llama-3-8B這類(lèi)RTX 3090 24G / 4090 24G黃金甜點(diǎn)卡能跑14B量化或者7B全精度個(gè)人開(kāi)發(fā)者最常用的配置A100 40G / 80G、H100企業(yè)級(jí)可以跑70B量化或者多卡張量并行蘋(píng)果M系列統(tǒng)一內(nèi)存M2 Max 64G跑32B量化模型也能湊合但生態(tài)繞后面不展開(kāi)。我的建議是先把模型規(guī)模定下來(lái)再?zèng)Q定用什么卡。模型超過(guò)10B24G顯存是底線。2.2 CPU和內(nèi)存同樣不能忽視很多人把注意力全放在顯卡上結(jié)果CPU和內(nèi)存成了瓶頸。模型加載到顯存之前要先把權(quán)重從磁盤(pán)讀入內(nèi)存再到顯存。如果你的內(nèi)存只有32G下了一個(gè)14B的模型FP16權(quán)重28G內(nèi)存直接爆掉系統(tǒng)開(kāi)始swap速度慢到懷疑人生。內(nèi)存容量建議是模型權(quán)重的1.5到2倍128G內(nèi)存是比較從容的配置。CPU的要求相對(duì)低一些但如果你用的是中低端消費(fèi)級(jí)CPU在做prefill階段處理輸入token的時(shí)候CPU和內(nèi)存帶寬會(huì)拉低整體吞吐。實(shí)測(cè)下來(lái)消費(fèi)級(jí)平臺(tái)和服務(wù)器平臺(tái)在同等GPU下單請(qǐng)求響應(yīng)時(shí)間能差出20%到30%。還有個(gè)容易忽略的磁盤(pán)空間?，F(xiàn)在主流開(kāi)源模型權(quán)重動(dòng)輒幾十個(gè)GBQwen2.5-72B的FP16權(quán)重接近150G下之前先確認(rèn)磁盤(pán)余量。模型文件建議放在SSD上機(jī)械硬盤(pán)加載一次70B模型光讀盤(pán)就夠你喝杯咖啡了。# 查看顯存和GPU狀態(tài) nvidia-smi # 查看CPU和內(nèi)存 lscpu | grep -E Model name|Core|Thread free -h # 查看磁盤(pán)剩余空間 df -h /data/models3. 模型選型與下載別只會(huì)去Hugging Face3.1 國(guó)內(nèi)下載模型ModelScope比HF穩(wěn)得多部署大模型第一步是拿到權(quán)重。Hugging Face作為全球最大的模型倉(cāng)庫(kù)國(guó)內(nèi)訪問(wèn)經(jīng)常超時(shí)斷流下載幾十GB的文件斷了就得重來(lái)非常折磨人。我的建議是優(yōu)先用ModelScope魔搭社區(qū)阿里的國(guó)內(nèi)直連速度快下載穩(wěn)定而且模型種類(lèi)和HF基本同步。Qwen、Llama、DeepSeek、ChatGLM這些熱門(mén)模型都有官方權(quán)重的鏡像。如果一定要用Hugging Face有三個(gè)加速方案用hf-mirror.com鏡像站把HUGGING_FACE_HUB_ENDPOINT環(huán)境變量指過(guò)去用hf_transfer庫(kù)加速下載需要先pip安裝再設(shè)置HF_HUB_ENABLE_HF_TRANSFER1先下載單文件再手動(dòng)拼接適用于斷點(diǎn)續(xù)傳場(chǎng)景。ModelScope的命令行工具也很簡(jiǎn)單# 安裝modelscope庫(kù) pip install modelscope # 下載Qwen2.5-7B-Instruct從魔搭下載 modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir /data/models/Qwen2.5-7B-Instruct這里要提醒一下模型的版本、量化格式、對(duì)話模板差異巨大不要隨便下個(gè)同名模型就往上套。比如Qwen2.5系列就有Base基座和Instruct指令微調(diào)兩個(gè)大版本Instruct版自帶對(duì)話模板是給聊天用的Base版更適合做下游微調(diào)或者當(dāng)作embedding基座。你部署聊天服務(wù)應(yīng)該選Instruct版本。3.2 量化模型是什么4-bit和8-bit怎么選經(jīng)常看到有人問(wèn)“為什么同一個(gè)模型有多個(gè)文件大小比如7B的有4GB、7GB、14GB”這其實(shí)是不同精度。14GB是FP1616位浮點(diǎn)7GB是INT88位整數(shù)4GB是INT44位整數(shù)。量化就是把模型權(quán)重從高精度壓縮到低精度以犧牲一點(diǎn)質(zhì)量為代價(jià)換來(lái)更小的顯存占用和更快的推理速度。實(shí)際部署中我的經(jīng)驗(yàn)是兩個(gè)原則顯存充足時(shí)優(yōu)先用FP16或BF16全精度效果最好顯存緊張時(shí)用INT8比INT4穩(wěn)妥INT4有時(shí)候輸出質(zhì)量塌方尤其對(duì)數(shù)學(xué)、邏輯推理類(lèi)任務(wù)特別明顯。GGUF格式的量化模型通常用q4_K_M、q5_K_M、q8_0這些后綴表示不同量化級(jí)別q4_K_M是最常見(jiàn)的折中方案q8_0質(zhì)量更接近FP16但體積大近一倍。市面上很多一鍵部署工具默認(rèn)拉取的都是Q4量化版本。4. Ollama最省心的本地模型部署方式4.1 安裝Ollama裝完就能跑如果只想快速體驗(yàn)?zāi)Ｐ托Ч麤](méi)有復(fù)雜的服務(wù)化需求Ollama是目前最省心的方案。它一個(gè)二進(jìn)制文件搞定跑模型、提供API、管理模型生命周期對(duì)新手特別友好。Linux安裝就一行命令curl -fsSL https://ollama.com/install.sh | sh裝完之后啟動(dòng)服務(wù)systemctl start ollama systemctl enable ollama然后拉取模型運(yùn)行# 拉取Qwen2.5-7B-Instruct的Q4量化版本 ollama pull qwen2.5:7b # 運(yùn)行模型進(jìn)入交互式對(duì)話 ollama run qwen2.5:7b第一次運(yùn)行會(huì)自動(dòng)下載權(quán)重國(guó)內(nèi)網(wǎng)絡(luò)如果下載慢可以設(shè)置環(huán)境變量OLLAMA_MODELS指定模型存放目錄再用代理或者鏡像加速。注意Ollama默認(rèn)模型存儲(chǔ)在/usr/share/ollama/.ollama/models如果系統(tǒng)盤(pán)空間小建議提前改路徑# 修改Ollama模型存儲(chǔ)路徑寫(xiě)入環(huán)境變量 mkdir -p /data/ollama-models echo OLLAMA_MODELS/data/ollama-models /etc/environment systemctl restart ollama4.2 換模型和查模型很簡(jiǎn)單Ollama的模型管理命令非常直觀# 查看本機(jī)已下載的模型 ollama list # 刪除不用的模型 ollama rm qwen2.5:7b # 從已有modelfile創(chuàng)建自定義模型另外一個(gè)很多人不知道的細(xì)節(jié)Ollama原生提供OpenAI兼容的API接口端口是11434。你的應(yīng)用代碼只要把base_url換成http://服務(wù)器IP:11434/v1把a(bǔ)pi_key隨便填個(gè)字符串就能直接用OpenAI的SDK接入本地模型了。這意味著之前寫(xiě)的調(diào)用OpenAI接口的代碼幾乎零改動(dòng)就能切換到本地。# 驗(yàn)證API是否正常 curl http://localhost:11434/v1/models # 調(diào)用聊天接口 curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好介紹一下你自己}] }5. 更靈活的Docker部署GPU透?jìng)骱顽R像選擇5.1 為什么推薦Docker環(huán)境和版本隔離是關(guān)鍵Ollama雖然省事但如果你想部署多個(gè)模型、多個(gè)推理框架或者和別人共用同一臺(tái)服務(wù)器直接用宿主機(jī)環(huán)境很容易搞成“依賴(lài)地獄”——這個(gè)庫(kù)要這個(gè)版本那個(gè)庫(kù)要另一個(gè)版本還要互相沖突。Docker能完美解決這個(gè)問(wèn)題。每個(gè)容器有自己的運(yùn)行環(huán)境互不干擾。而且NVIDIA官方提供了nvidia-container-toolkit可以讓容器直接使用宿主機(jī)GPU物理性能損耗只有個(gè)位數(shù)百分比幾乎可以忽略。在Linux上部署Docker GPU環(huán)境的完整步驟# 1. 安裝Docker以Ubuntu 22.04為例 curl -fsSL https://get.docker.com | sh # 2. 安裝NVIDIA Container Toolkit distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit # 3. 重啟Docker sudo systemctl restart docker # 4. 驗(yàn)證GPU能否被容器識(shí)別 docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi如果第四步能正常輸出GPU信息說(shuō)明環(huán)境OK。這一步我建議所有人部署前先驗(yàn)證能省掉后面排查問(wèn)題的大把時(shí)間。5.2 用Docker跑Ollama和vLLMOllama官方也提供了Docker鏡像直接拉起來(lái)用docker run -d --gpus all -v /data/ollama-models:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama這里解釋一下參數(shù)含義-d是后臺(tái)運(yùn)行--gpus all把全部GPU傳給容器-v做了目錄掛載把容器的模型目錄映射到宿主機(jī)的/data/ollama-models這樣模型權(quán)重在宿主機(jī)也能看到以后重裝容器數(shù)據(jù)不丟。-p把容器的11434端口映射到宿主機(jī)。如果是追求高吞吐的生成式AI服務(wù)用vLLM更合適。vLLM是當(dāng)前最流行的推理加速框架通過(guò)PagedAttention、連續(xù)批處理等技術(shù)顯著提升吞吐量。部署方式照樣用Dockerdocker run --gpus all \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9這里提一個(gè)非常重要的概念gpu-memory-utilization意思是允許vLLM最多吃滿90%的顯存。留出10%的余量是為了防止OOM顯存溢出。如果你把值設(shè)成0.95然后同時(shí)來(lái)幾個(gè)長(zhǎng)對(duì)話請(qǐng)求很容易直接OOM崩潰。還有max-model-len它決定模型支持的最長(zhǎng)上下文長(zhǎng)度設(shè)的越大KV Cache占顯存越大在7B模型上從4096改成16384顯存占用能多出3到4GB要根據(jù)實(shí)際需求權(quán)衡。6. 踩坑實(shí)錄從部署到調(diào)優(yōu)的9個(gè)高頻問(wèn)題部署過(guò)程中我踩過(guò)不少坑這里整理一個(gè)高頻問(wèn)題速查表你如果遇到類(lèi)似問(wèn)題直接對(duì)照排查。現(xiàn)象可能原因解決辦法docker運(yùn)行提示無(wú)GPUnvidia-container-toolkit未安裝或Docker未重啟安裝toolkit后必須systemctl restart dockerOllama響應(yīng)特別慢模型未完全加載到顯存還在用CPU推理檢查nvidia-smi顯存占用確認(rèn)顯存充足中文輸出亂七八糟沒(méi)走對(duì)話模板或者模型選錯(cuò)版本使用Instruct版本檢查API請(qǐng)求是否正確構(gòu)造messages格式端口被占用11434或8000已被其他程序占用lsof -i:11434查看占用改端口或kill進(jìn)程顯存OOM并發(fā)請(qǐng)求太多或max-model-len設(shè)置過(guò)大降低并發(fā)數(shù)減小max-model-len調(diào)低gpu-memory-utilization下載模型經(jīng)常中斷網(wǎng)絡(luò)不穩(wěn)定或連接被重置用ModelScope下載后手動(dòng)導(dǎo)入Ollama模型回答內(nèi)容重復(fù)啰嗦溫度參數(shù)設(shè)置太高或未設(shè)置使用默認(rèn)temperature或調(diào)低到0.7以下多卡服務(wù)器只用了1張卡Ollama默認(rèn)只使用一張GPU設(shè)置環(huán)境變量OLLAMA_NUM_GPUallserver部署vLLM后接口503模型還在加載中或者顯存不足查看日志等待加載完成或換更小模型特別說(shuō)一下模型導(dǎo)入Ollama的問(wèn)題。你從ModelScope手動(dòng)下載回來(lái)的模型不是直接扔進(jìn)某個(gè)文件夾就能被Ollama識(shí)別。正確流程是用Modelfile來(lái)導(dǎo)入。如果你下載的是GGUF格式的模型文件Modelfile內(nèi)容就一行FROM ./qwen2.5-7b-instruct-q4_k_m.gguf然后執(zhí)行ollama create qwen2.5:7b-q4 -f Modelfile之后再運(yùn)行ollama run qwen2.5:7b-q4就可以了。7. 模型微調(diào)讓大模型更懂你的業(yè)務(wù)7.1 微調(diào)不是從零訓(xùn)練參數(shù)高效微調(diào)才是主流部署只是開(kāi)始。當(dāng)開(kāi)箱即用的通用大模型無(wú)法滿足特定業(yè)務(wù)需求時(shí)就得考慮微調(diào)。比如你做一個(gè)法律問(wèn)答助手Qwen2.5-7B通用版對(duì)法律條款的回答可能泛泛而談你需要用真實(shí)的法條問(wèn)答對(duì)去讓它“變得更專(zhuān)業(yè)”。微調(diào)不是從零訓(xùn)練而是基于預(yù)訓(xùn)練權(quán)重繼續(xù)學(xué)習(xí)。主流方式是參數(shù)高效微調(diào)其中最常用的是LoRALow-Rank Adaptation低秩適配。它的核心思想是凍結(jié)原始模型的全部參數(shù)只訓(xùn)練一小部分新增的低秩矩陣顯存和算力需求直接降一個(gè)數(shù)量級(jí)。原來(lái)微調(diào)7B全參可能需要80G顯存用LoRA 量化之后24G顯存就能跑。業(yè)界經(jīng)常用Unsloth這個(gè)庫(kù)來(lái)做微調(diào)它的口號(hào)是“2倍速度、50%顯存占用”在開(kāi)源社區(qū)口碑很好。一個(gè)完整的Unsloth微調(diào)腳本結(jié)構(gòu)大概是這樣from unsloth import FastLanguageModel import torch # 加載模型和分詞器自動(dòng)啟用4-bit量化 model, tokenizer FastLanguageModel.from_pretrained( model_nameQwen/Qwen2.5-7B-Instruct, max_seq_length2048, load_in_4bitTrue, ) # 注入LoRA適配器 model FastLanguageModel.get_peft_model( model, r16, # LoRA秩越大表達(dá)能力越強(qiáng)但計(jì)算量也越大 lora_alpha16, # 縮放系數(shù) lora_dropout0, # 實(shí)測(cè)設(shè)為0通常效果更好 biasnone, use_gradient_checkpointingTrue, ) # 加載數(shù)據(jù)集 from datasets import load_dataset dataset load_dataset(json, data_filesyour_data.jsonl, splittrain) # 定義訓(xùn)練參數(shù) from trl import SFTTrainer from transformers import TrainingArguments trainer SFTTrainer( modelmodel, tokenizertokenizer, train_datasetdataset, argsTrainingArguments( per_device_train_batch_size2, gradient_accumulation_steps4, learning_rate2e-4, num_train_epochs3, output_diroutput, fp16torch.cuda.is_bf16_supported(), logging_steps10, save_strategysteps, save_steps100, optimadamw_8bit, ), ) trainer.train()7.2 微調(diào)數(shù)據(jù)長(zhǎng)什么樣經(jīng)驗(yàn)與常見(jiàn)誤區(qū)微調(diào)效果最大化數(shù)據(jù)質(zhì)量比數(shù)據(jù)量更重要。我自己用下來(lái)幾千條精心構(gòu)造的指令數(shù)據(jù)效果可能好過(guò)幾萬(wàn)條爬來(lái)的臟數(shù)據(jù)。數(shù)據(jù)格式以JSONL為例每條包含instruction指令、input輸入可空、output期望輸出{instruction: 解釋什么是合同解除, input: , output: 合同解除是指合同有效成立后因一方或雙方當(dāng)事人的意思表示使合同關(guān)系歸于消滅的行為...} {instruction: 根據(jù)以下案情判斷是否構(gòu)成違約, input: 甲與乙簽訂供貨合同約定甲于3月1日前交貨甲未能按期交貨。, output: 構(gòu)成違約。甲未按合同約定的時(shí)間履行交貨義務(wù)...}很多新手容易犯的錯(cuò)誤把預(yù)訓(xùn)練語(yǔ)料直接拿來(lái)微調(diào)對(duì)話模型結(jié)果訓(xùn)練完模型說(shuō)話前言不搭后語(yǔ)。原因是格式不對(duì)——指令微調(diào)要求的是“問(wèn)題-回答”這種結(jié)構(gòu)化格式而不是純粹的文本續(xù)寫(xiě)。另外微調(diào)完的模型部署方式也有區(qū)別LoRA的adapter權(quán)重是依附在原模型上的用vLLM部署時(shí)需要額外指定--enable-lora和--lora-modules用Ollama則需要導(dǎo)入合并后的完整權(quán)重不能只放adapter文件。8. 并發(fā)與性能調(diào)優(yōu)從“能跑”到“跑得好”8.1 Ollama和vLLM的性能差異部署完成、能出結(jié)果只是第一步。線上服務(wù)面對(duì)真實(shí)流量時(shí)并發(fā)能力是關(guān)鍵。我拿Qwen2.5-7B-Instruct做過(guò)實(shí)際對(duì)比單張RTX 4090Ollama默認(rèn)配置下單請(qǐng)求延遲大概40ms/token吞吐量約25 token/svLLM開(kāi)啟連續(xù)批處理后同一模型在8并發(fā)下單請(qǐng)求延遲雖然漲到200ms但整體吞吐能到150 token/s以上。這說(shuō)明Ollama適合個(gè)人開(kāi)發(fā)和低并發(fā)場(chǎng)景vLLM適合真正對(duì)外提供服務(wù)。如果你的并發(fā)需求不高同時(shí)只有幾個(gè)人用Ollama加OLLAMA_NUM_PARALLEL環(huán)境變量調(diào)整并發(fā)worker數(shù)就夠了。要是給全公司提供服務(wù)老老實(shí)實(shí)上vLLM。vLLM還支持流式輸出、前綴緩存等特性對(duì)聊天體驗(yàn)提升非常明顯。# Ollama并發(fā)配置示例設(shè)置同時(shí)最多處理4個(gè)請(qǐng)求 echo OLLAMA_NUM_PARALLEL4 /etc/environment systemctl restart ollama8.2 用“一句頂一萬(wàn)句”的OpenAI兼容層做統(tǒng)一接入現(xiàn)在很多類(lèi)似于云廠商的模型服務(wù)都實(shí)現(xiàn)了OpenAI兼容接口好處是你的服務(wù)可以用一套標(biāo)準(zhǔn)接口接入不同后端想切換模型時(shí)改個(gè)URL就行。以vLLM啟動(dòng)的服務(wù)為例它默認(rèn)監(jiān)聽(tīng)8000端口接入代碼只需要這樣寫(xiě)from openai import OpenAI client OpenAI( base_urlhttp://10.0.0.5:8000/v1, # 換成你的服務(wù)器IP api_keyEMPTY, # 本地部署不校驗(yàn)key但字段不能省略 ) response client.chat.completions.create( modelqwen2.5, messages[ {role: system, content: 你是一個(gè)友善的助手。}, {role: user, content: 請(qǐng)介紹一下Linux服務(wù)器部署大模型的步驟}, ], temperature0.7, streamTrue, # 開(kāi)啟流式輸出 ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)這段代碼是最常用的流式對(duì)話輸出用戶體驗(yàn)好不會(huì)讓人對(duì)著一個(gè)轉(zhuǎn)圈圈的空頁(yè)面干等。使用OpenAI兼容層也是目前把所有主流推理框架接入統(tǒng)一層的最佳實(shí)踐。8.3 實(shí)測(cè)下來(lái)的一些經(jīng)驗(yàn)數(shù)值多次測(cè)試之后我總結(jié)出幾個(gè)比較靠譜的經(jīng)驗(yàn)值7B Q4模型在24G顯存上理論能支撐20路并發(fā)問(wèn)答但效果會(huì)隨著并發(fā)數(shù)增加明顯下降70B Q4模型在雙卡80G服務(wù)器上做張量并行首token時(shí)延從單卡的2400ms降到900ms左右max-model-len設(shè)成8192的7B模型KV Cache大約占3GB顯存如果調(diào)到32768光這一項(xiàng)就是12GB心里要有數(shù)開(kāi)啟vLLM的--enable-prefix-caching之后對(duì)于多輪對(duì)話場(chǎng)景重復(fù)前綴的token計(jì)算量可以減少30%左右。調(diào)優(yōu)沒(méi)有銀彈建議先跑通默認(rèn)配置然后逐步調(diào)整參數(shù)觀察吞吐和顯存曲線。關(guān)于監(jiān)控推薦用nvidia-smi做一個(gè)crontab定時(shí)采樣# 每5秒記錄一次GPU狀態(tài)持續(xù)半小時(shí) nohup nvidia-smi --query-gpuutilization.gpu,memory.used,temperature.gpu --formatcsv -l 5 gpu_monitor.log 21 9. 最后說(shuō)幾句實(shí)在話我在這個(gè)領(lǐng)域調(diào)試了快兩年一個(gè)非常深的體會(huì)是大模型部署的坑大部分不是模型的坑而是基礎(chǔ)設(shè)施的坑。CUDA版本不匹配、GLIBC版本太老、磁盤(pán)被日志寫(xiě)滿、防火墻攔了端口、DNS解析失敗每個(gè)看起來(lái)是小問(wèn)題排起來(lái)都能吃掉一整天。與其祈禱不出錯(cuò)不如一開(kāi)始就把環(huán)境管控好——能用Docker盡量用Docker依賴(lài)全部鎖版本磁盤(pán)和內(nèi)存提前規(guī)劃容量。另外一個(gè)很多人問(wèn)我的問(wèn)題“我應(yīng)該用Ollama還是vLLM”我的回答是看場(chǎng)景。個(gè)人學(xué)習(xí)、本地知識(shí)庫(kù)、給三五個(gè)人用Ollama夠了簡(jiǎn)單到像在用一個(gè)工具而不是部署一個(gè)系統(tǒng)公司里對(duì)外提供API或者要接比較復(fù)雜的業(yè)務(wù)邏輯直接上vLLM并發(fā)吞吐和穩(wěn)定性都有保障。兩者并不互斥同一臺(tái)機(jī)器上完全可以同時(shí)跑用不同端口隔離。如果你剛開(kāi)始接觸我的建議是從Ollama跑一個(gè)7B或8B的Instruct模型開(kāi)始花一個(gè)晚上把API調(diào)通然后用Python寫(xiě)個(gè)web服務(wù)殼子把自己的業(yè)務(wù)數(shù)據(jù)接進(jìn)來(lái)。這條路走通之后再去研究vLLM換掉Ollama后端就順理成章了。別一上來(lái)就想部署70B大模型那是另外一套完全不同的游戲。