企业官网建设流程全解析

GPU运维：大模型简单部署

上个月被叫去处理一台GPU服务器的部署问题，机器是客户那边刚到的，四张卡，系统盘和数据盘都分好了，驱动也装好了，结果模型一跑就崩，报错还时好时坏。折腾了大半天，最后发现问题是驱动和CUDA版本对不上，加上显存分配给两个进程冲突了。这活儿看起来不难，但其实里面坑不少。作为常年泡在GPU服务器和Linux运维一线的老兵，我把这几年做大模型部署踩过的坑、沉淀下来的方法整理成这篇东西，给那些正准备上手GPU机器部署大模型的运维兄弟们一个参考。

这套东西适合谁看？如果你手上有GPU服务器，计划跑大模型推理或微调，对Linux运维有一定基础但第一次接触模型部署；或者你已经部署过几次但总在环境问题上打转，那这篇文章基本能把你的问题覆盖掉。我会从硬件识别开始，讲到驱动、CUDA、镜像、并发隔离、量化选型，最后给一个完整的部署示例和一个快速排障清单。你可别嫌内容多，这些环节每一个都能让部署卡上半天。

1. 部署前先能接住哪些硬件问题

1.1 从nvidia-smi开始认识你的GPU

拿到一台GPU服务器，第一件事就是查询机器到底有几张卡、型号是什么、显存多大、驱动状态是否正常。命令行就一项：

nvidia-smi

输出里最需要关注的是几块内容。第一块是驱动版本，比如Driver Version: 535.154.05，这个数字决定你能装多新的CUDA。第二块是每个GPU的型号和显存，比如NVIDIA A100-SXM4-40GB，40G就是单卡显存上限。第三块是当前实时状态，包括利用率、显存占用、温度、功耗。很多运维兄弟习惯只看利用率，但真正卡模型性能的往往是显存占用而不是利用率，这条得记住。

如果nvidia-smi命令提示不存在，大概率是驱动没装好，后面我会专门讲驱动安装排查。还有一个小细节，有些机器用的是MIG模式（多实例GPU），把一张A100切成了多个小GPU实例，你用nvidia-smi看会看到类似MIG 1g.5gb这样的设备。如果部署模型时发现显存和预期不符，先看看MIG模式是不是被打开了，通过nvidia-smi -mig相关命令可以查看和关闭。

GPU妥了，CPU和内存也不能忽视。做推理时CPU主要承担数据预处理、token化这些工作，内存不够会触发swap，直接拖慢推理速度。我的习惯是，单机部署前先跑一轮htop和free -h，确认CPU核心数和可用内存，特别是那些打算用Docker部署的机器，容器内看到的内存上限和物理内存不一样，容易误判。

1.2 GPU型号选型与显存测算思路

不同模型对显存的胃口完全不同，选卡之前你得先有个大致概念。推理场景下，模型权重占用的显存约等于模型参数量乘以精度字节数。比如一个7B模型，用FP16（每个参数2字节）加载，光权重就需要大约14GB显存，再算上KV Cache、激活值、CUDA上下文，实际至少准备20GB以上才稳。

如果卡显存不够，常见方案是量化。把模型从FP16量化到INT8，显存占用直接减半；再到INT4，又可以再减半。现在很多推理框架比如vLLM、ollama都支持自动量化，你只需要告诉框架要加载4bit还是8bit版本即可。我有一个参考表，平时测算直接套用：

这张表只是权重大致估算，实际还得加几GB的运行时开销。所以选卡时不要只看权重能不能放下，一定要把推理时的激活值和KV Cache预留出来。我个人习惯是，推理场景预留1.2到1.5倍的权重占用，微调场景因为要存梯度和优化器状态，至少预留2到3倍权重占用。

2. 环境搭建别只盯着CUDA版本

2.1 驱动、CUDA Runtime与PyTorch的三角关系

驱动、CUDA Runtime（运行时库）、深度学习框架之间是有兼容关系的。驱动在最底层，负责和硬件通信；CUDA Runtime是封装好的编程接口；PyTorch这类框架则依赖CUDA Runtime来调用GPU能力。很多人犯的错误是，明明驱动支持CUDA 12.2，但PyTorch默认装的版本只支持CUDA 11.8，结果模型加载时疯狂报错或干脆找不到设备。

装PyTorch GPU版本的正确姿势，应该是先去PyTorch官网看当前稳定版对应哪个CUDA版本，然后装对应版本的包。比如pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118就是在装CUDA 11.8版本的PyTorch。装完验证：

python -c "import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

如果输出cuda.is_available()为True，说明PyTorch能正常调用GPU。这一步是部署任何大模型的前提，我见过太多人跳过验证直接跑模型，到最后报错又回头查环境，浪费一整天。

驱动版本和CUDA版本的关系用一条命令就能查：

nvidia-smi | grep "CUDA Version"

这里显示的CUDA版本是驱动支持的最高版本。只要驱动支持的CUDA版本不低于你框架所需的CUDA版本，一般就能跑。比如说驱动显示CUDA Version: 12.2，那你装CUDA 11.8的PyTorch没问题，装12.1的也没问题，装13.0就不行。

2.2 容器化部署解决环境传染问题

后面部署多了你就会发现，每换一个项目就换一套CUDA和Python依赖，直接装在物理机上迟早会把自己搞疯。容器化是我强烈推荐的方式，用Docker或Podman把模型环境隔离起来，一个容器一套依赖，互不干扰。

GPU服务器的容器部署有个关键点：必须装NVIDIA Container Toolkit，否则容器里访问不到GPU设备。装完后运行容器时加--gpus all参数即可，简单示例：

docker run --gpus all --shm-size=8g -it --rm \ -v /data/models:/models \ -p 8000:8000 \ pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime \ bash

注意--shm-size参数，大模型推理时DataLoader和部分推理框架会用到共享内存，默认64M根本不够，极容易报"unable to allocate shared memory"之类的错误，我一般直接给8G以上。

容器内部的nvidia-smi能看到GPU吗？装了toolkit之后是可以的。跑一下确认：

docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi

看到显卡信息说明容器和GPU打通了，这一步通了后面装什么框架都顺。

2.3 PaddleOCR的GPU版本安装经验

大模型不光是LLM，OCR也经常出现在运维工作中。PaddleOCR的GPU版本安装有不少讲究，我顺手说下。首先PaddlePaddle和PyTorch一样，要选对CUDA版本。安装命令很直观：

python -m pip install paddlepaddle-gpu==2.6.0 -i https://mirror.baidu.com/pypi/simple

装完验证：

python -c "import paddle; paddle.utils.run_check()"

如果输出PaddlePaddle is installed successfully!，说明GPU可用。这里有个常见坑：PaddlePaddle不同大版本对CUDA版本有严格限制，装之前一定要查官方文档的版本匹配表。另外PaddleOCR运行时会自动下载模型权重，内网机器需要提前把模型文件下载好并配置好路径，不然到推理那一步会卡在下载上。

3. 从零完成一个大模型本地部署

3.1 模型选型与下载的实战考量

大模型本地部署第一步是选模型。Hugging Face上有海量开源模型，但你不能看到什么装什么。我的选型原则是，先看显存，再按任务需求选模型家族。7B级别模型适合单张24G卡；13B级别可以单卡或者双卡跑；70B级别基本要4卡以上加量化才能推理。

下载模型我用huggingface-cli或者modelscope，国内环境用ModelScope下载速度快很多，命令示例：

pip install modelscope modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir /data/models/Qwen2.5-7B-Instruct

下载前检查磁盘空间，用df -h /data/models看看够不够。一个7B模型FP16版大概15GB，量化版小很多。下载完成后检查模型目录里有没有config.json、.bin或.safetensors文件，基本能确认文件完整。

3.2 用vLLM起一个高性能推理服务

vLLM是目前我用的最多的推理框架，吞吐量高、显存管理好、支持连续批处理，部署起来也比想象中简单。前提是PyTorch环境装好，然后安装：

pip install vllm

然后启动一个Qwen2.5-7B模型的OpenAI兼容接口服务：

vllm serve /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000

几个参数我解释下，都是实际中经常要调的：--tensor-parallel-size是张量并行度，一张卡就是1，多卡就设为卡数，多卡部署模型会切分权重到多张卡上；--gpu-memory-utilization是允许使用显存的比例，默认0.9，意思是预留10%显存给CUDA上下文和其他开销；--max-model-len是最大上下文长度，越长越吃显存，如果显存不够就把这个值调小。

启动后验证服务是否正常：

curl http://localhost:8000/v1/models

返回模型ID说明服务起来了。再试一个对话请求：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen2.5-7b", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 100}'

这一步如果输出正常的JSON响应，大模型部署就算成功了。后面接业务系统，只需要把原来的OpenAI接口地址换成这台服务器的地址和端口。

3.3 用ollama走极简路线

vLLM虽然功能强，但配置起来还是要一些心智负担。如果你只想快速体验或者给内部小范围用，ollama是更轻的选择。ollama是把模型下载、依赖管理、推理服务全打包好了，装完就能用。

安装ollama一条命令：

curl -fsSL https://ollama.com/install.sh | sh

然后拉取模型并运行：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

ollama默认提供OpenAI兼容接口在http://localhost:11434，同样可以用curl验证。需要GPU的话，ollama会自动检测NVIDIA驱动并用GPU推理，基本不需要额外配置。ollama对显存不够的情况会自动做部分层卸载到CPU，但这种模式下推理速度明显变慢，建议还是保证显存充足。

3.4 多卡部署的一个落地案例

前几天我把一台双卡A800服务器部署成推理节点，跑的模型是70B量化版。两张卡各80G显存，FP16直接跑70B肯定不现实，我用AWQ量化成4bit，权重大概40G，再加KV Cache等开销，双卡80G刚好能放下。具体命令：

vllm serve /data/models/Qwen2.5-70B-Instruct-AWQ \ --served-model-name qwen2.5-70b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.95 \ --max-model-len 4096 \ --port 8000

多卡部署时--tensor-parallel-size 2会把模型权重切分到两张卡上，同时计算也并行。启动后通过nvidia-smi观察，两张卡的显存占用应该相差不大，如果一张卡明显比另一张高，优先检查NVLink/NVSwitch是否连接正常。可以通过nvidia-smi topo -m查看卡之间的拓扑连接，P2P通信是否走NVLink。

4. 部署后运维和性能调优

4.1 GPU占用不高但服务慢的排查路径

这是运维里最常遇到的怪问题：GPU利用率只有20%，显存也没满，但推理速度就是上不去。我总结了一套排查路径，照着走基本能定位。

第一步，看CPU和内存。top命令如果没有大问题，继续看数据加载管线，是不是每次推理前都要做大量数据预处理或token化，CPU瓶颈会造成GPU轮流等待。第二步，检查GPU之间通信和CPU与GPU之间PCIe带宽。nvidia-smi里有GPU-Util和Volatile GPU-Util的区别，低利用率很可能代表数据传输开销太大。第三步，检查并发配置。如果是vLLM，适当调大--max-num-seqs（一个批次最多并行处理的序列数）可以提高连续批处理的效率；调小--max-model-len则可以减少显存碎片。

另外还有一种情况是GPU温度过高触发降频。笔记本类或散热不好的工作站经常遇到，用nvidia-smi -q -d TEMPERATURE查看温度，如果超过85度，风扇转速和功耗上限也检查一下。服务器一般没有风扇控制权限，但可以确认机房空调或服务器风道是否正常。

4.2 显存泄漏与进程清理

大模型服务跑几天后显存越来越满，最后OOM被杀，这是比较典型的显存泄漏或残留进程问题。遇到这类问题第一步是看还有哪些进程在占用GPU：

nvidia-smi fuser -v /dev/nvidia*

fuser是Linux自带的命令，可以查看哪些进程占用了NVIDIA设备文件。如果发现僵尸进程，直接kill -9清掉。我的习惯是每次部署新服务前，用fuser -v /dev/nvidia*检查一遍是否有遗留进程占用显存，清理干净再启动。

如果是vLLM服务自身越跑越慢，可以定期重启服务释放显存碎片，或者在启动参数里加--enable-prefix-caching来减少重复前缀计算对显存的占用。还有一种情况，并发请求量大时，排队时间过长导致响应变慢，这种就要通过日志区分是排队等待还是推理本身慢。

4.3 GPU监控与告警的快速配置

没有监控的GPU集群就像没有仪表盘的汽车，跑得再快心里也没底。运维上我最常用的一套组合是nvidia-smi+ Prometheus + Grafana，或者更轻的方案是写个简单的shell脚本定期记录GPU状态。

轻量监控脚本思路很简单，用nvidia-smi --query-gpu=utilization.gpu,memory.used,temperature.gpu --format=csv输出数值，配合cron或systemd timer定期执行。生产环境建议用dcgm-exporter配合Prometheus采集GPU指标，再配Grafana面板展示。告警规则至少要覆盖三项：显卡温度超过阈值、显存占用接近上限、GPU利用率长期为0但任务未结束（可能是卡死）。

这里提一句，监控项不用一口气全上，先保障能回答三个问题：卡是否在工作、显存是否够用、温度是否正常。有这三条，就能挡住大部分故障了。

4.4 常见问题速查与处理建议

我把实际运维中高频出现的问题整理成表格，方便大家现场对照处理。这是我反复折腾GPU服务器后沉淀下来的经验，也是给团队做培训时的基础材料。

5. 部署节奏、工具链路和运行复盘

5.1 从零到服务的四步走

一套大模型部署任务，我习惯拆成四个阶段，每个阶段有明确的完成标志，不会因为模型跑不通就手忙脚乱。

第一，环境确认阶段。查GPU型号、驱动版本、CUDA版本、磁盘空间、内存。完成标志是nvidia-smi正常显示所有卡且温度正常。

第二，基础环境搭建阶段。安装Python、Docker、NVIDIA Container Toolkit、PyTorch GPU版。完成标志是你跑通了torch.cuda.is_available()为True。

第三，模型准备阶段。根据显存选模型和量化级别，下载模型权重。完成标志是模型文件完整出现在本地目录，能加载进框架。

第四，服务化部署阶段。用vLLM或ollama起服务，验证接口可用，再接入业务或监控。完成标志是curl测试通过且nvidia-smi能看到显存稳定占用。

这四个阶段的顺序不能乱。很多人喜欢一上来就装大模型框架，结果环境冲突，最后又回头从驱动开始查，浪费时间。按这个流程走，一步一验证，出问题时定位范围会小很多。

5.2 微调场景下的GPU运维注意点

如果部署目标不是推理而是微调，运维侧又有区别。微调比推理更吃显存，因为要保存梯度和优化器状态。有个粗算法：微调显存需求约为权重的3到4倍。所以7B模型微调至少要28GB以上，单卡24G会非常吃紧，最好双卡起步。

微调任务启动后，建议先用nvidia-smi持续盯几分钟，观察多卡利用率是否均衡。如果就一张卡在跑、其他卡空闲，大概率是模型并行或数据并行配置不对。常见的并行方式有数据并行（每张卡一份完整模型，吃不同数据）和张量并行（模型切分到多张卡），不同方式对显存和通信的要求完全不同。运维侧只需保证多卡之间的通信正常，再配合训练脚本中的并行参数设置。

数据处理环节也要注意，如果数据集特别大，DataLoader的num_workers设太低会导致GPU等待数据，利用率上不去。建议num_workers和CPU核心数匹配，prefetch_factor适当调大，这些参数对训练速度影响明显。

5.3 把部署过程沉淀为可复用文档

踩过这么多坑之后，我最大的心得是：每一次部署都要形成文档。不是说写正式报告，而是把命令、参数、坑、解决方法记录下来。下次部署同类模型，直接在文档基础上改，一小时就能搞定。我自己的文档模板包含这几块：硬件清单、驱动和CUDA版本、环境变量、模型路径、启动命令、验证命令、常见报错处理。团队里其他成员拿到这份文档，不需要反复问人就能独立部署，运维效率提升很快。

还有一个实践是“一键部署脚本”的沉淀。把环境初始化、驱动检测、容器创建、模型启动这些步骤写成Shell脚本或Ansible playbook，新机器到达后跑一遍就能复现环境。这对于多台机器批量部署特别有用，也避免人工操作带来的不一致问题。

5.4 为什么我推荐先“简单部署”再“精细调优”

模型部署尤其是AIGC时代的大模型部署，最大的敌人不是技术难度，而是信息过载和过于完美的预期。有人一上来就觉得要上RAG、要上微调、要上高并发架构，结果两三天过去了，最基本的模型都还没跑通。

我的建议是，第一次部署不要追求完美，先跑通最小可用版本。用ollama或vLLM默认参数把模型跑起来，能通过API返回结果就算成功。跑通之后，再根据实际流量和硬件情况逐步调整并发参数、量化方式、缓存策略。这个顺序能让你快速建立对系统的感知，知道瓶颈在哪里，再针对性地优化。

部署完成后，一定要做一轮基础压测。简单点就用脚本批量发请求，观察响应时间和GPU利用率。压测不用太复杂，能回答“这台机器能支撑多大的并发量”就够了，这对接下来的容量规划很有价值。

结尾的几句实在话

我花了不少篇幅在环境检查和问题排查上，因为这恰恰是大模型部署中最不性感但最要命的环节。真正让部署翻车的，往往不是模型本身，而是GPU驱动对不上、显存估算错误、容器权限没打通这类细枝末节。

如果你现在正准备第一次上手，我的建议很简单：先挑一个7B左右的模型，选一张显存够用的卡，按文章里的流程走一遍，能跑通一次完整链路，后面再遇到更大模型、多卡并行、微调这些需求时，你会有底气得