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