大模型从“能用”到“真正部署到 Linux 服务器的生产环境”中间其实隔着一道不小的坎。我自己过去一年多给不同团队搭过不少次大模型服务从单卡工作站到多卡 GPU 服务器都碰过这里把整套流程、踩过的坑、以及最后沉淀下来的部署思路一次性讲清楚。这篇文章适合三类人想在公司内网搭一个私有化大模型服务的运维、准备把开源模型接到业务系统里的后端开发以及刚拿到一台 GPU 服务器、不知道从哪儿下手的算法工程师。先说结论Linux 服务器部署大模型卡点从来不是“敲命令”而是三件事——硬件怎么评估、模型怎么选、推理引擎怎么挑。这三件事想明白了后面其实就是照着流程执行最多在版本兼容上花点时间。1. 部署前的核心决策算力、显存与模型匹配1.1 先给显存算一笔账别拿到服务器就开跑很多人第一次部署翻车不是技术问题而是显存不够。大模型推理时模型权重需要完整放进显存里。一个 7B 参数模型用 FP16 精度保存权重大概是 7×214GB再加上推理时动态分配的 KV Cache、CUDA context 和各种中间张量实际占用往往比单纯权重多 20%-30%。我一般会这样快速估算24GB 显存跑 7B-8B 模型最舒服基本可以留出足够空间给长上下文14B 模型想流畅跑建议 32GB 以上显存24GB 也能跑但需要量化或者把上下文长度压到很低70B 级别模型就别指望单卡了FP16 权重大概 140GB至少得两张 80GB 的卡或者多张 48GB 卡并行通常还会用 AWQ/GPTQ 量化到 4bit把权重降到 35GB 左右再考虑部署。显存不够的典型表现是程序启动后一小会儿直接报CUDA out of memory或者系统开始把显存数据换到内存速度慢到没法用。我见过不少人硬拿 16GB 显存的卡去跑 14B 模型输入一长就直接崩最后只能把max_model_len从 8192 降到 2048 才勉强跑起来体验很差。1.2 模型参数、精度与显存对照表为了让你直观选型这里把常见规模的模型做了一个对照。注意实际项目里的显存占用还受推理引擎、上下文长度、并发请求数影响下表只能作为起点的粗略估算。模型参数规模FP16/BF16 权重显存4bit 量化后权重显存建议部署显卡1B-3B2GB-6GB0.6GB-1.8GB4GB 以上即可CPU 也能凑合7B-8B14GB-16GB4.5GB-5.5GB单张 24GB如 RTX 409013B-14B26GB-28GB8GB-9GB单张 48GB 或两张 24GB32B64GB20GB 左右两张 48GB 或单张 80GB70B140GB35GB-40GB两张 80GB 或四张 48GB这里多说一句量化。很多人第一次听“4bit 量化”会担心效果变差它确实会有一定精度损失有点像图片从无损 PNG 压成高画质 JPEG肉眼大部分场景看不出来但极端细节会有损失。日常对话、文本总结、代码生成这类任务4bit 量化后的质量完全可用如果做数学推理、复杂逻辑任务建议保留 FP16或者至少用 8bit 而不要直接压到 4bit。1.3 你的场景到底需要什么模型模型选型不是“越大越好”而是“够用就好”。如果只是做内部知识库问答或日常闲聊7B-8B 级别的通用对话模型完全够用如果是面向外部用户的高并发 API 服务建议用 14B-32B 甚至更大的模型同时用 vLLM 这类高性能推理引擎如果你要处理的是长文档、代码仓库这类超长输入场景还得额外看模型的上下文长度而不是只看参数规模。场景决定部署方案这是我反复强调的一点。公司内部几十个人测着玩跟线上每天几万次调用技术架构完全是两码事。前者用 Ollama 一把梭没问题后者就得从推理引擎、并发参数、监控告警全部考虑到位。2. Linux 服务器环境准备驱动、CUDA 与容器运行时2.1 操作系统选型与基础检查做 GPU 服务器部署我首选 Ubuntu 22.04 或 24.04 LTS。原因很实在NVIDIA 驱动、CUDA、容器运行时对 Ubuntu 的支持最完善社区踩坑资料也多。用 CentOS 7 这类老系统搞大模型部署不是不行但内核版本、GCC 版本、glibc 版本都可能跟新版本 PyTorch 或 vLLM 冲突排查起来非常痛苦。拿到一台机器后先执行下面这组基础检查命令确认 CPU、内存、磁盘和 GPU 状态# CPU 与内存 lscpu free -h # 磁盘空间模型文件动辄几十 GB务必看剩余空间 df -h # 显卡是否被系统识别 lspci | grep -i nvidia # NVIDIA 驱动是否装好 nvidia-smi如果nvidia-smi能正常输出说明驱动已经装好直接跳到下一步。如果提示command not found说明驱动还没有安装需要接着往下走。2.2 NVIDIA 驱动安装能省事就省事Linux 安装 NVIDIA 驱动有几种方式我最推荐的是通过发行版仓库装尤其是 Ubuntu 上用ubuntu-drivers工具。sudo apt update sudo apt install ubuntu-drivers-common ubuntu-drivers devices sudo ubuntu-drivers installubuntu-drivers install会自动帮你选一个合适版本装完后重启再执行nvidia-smi验证。整个过程大概五分钟比去官网下载.run文件手动安装省心得多。我自己早期也爱从官网下.run包手动装结果经常遇到内核头文件版本对不上、nouveau 开源驱动没禁用导致装失败的问题后来就学乖了能用仓库包绝不留手动安装。不建议直接在正在运行的服务器上装官网.run包还有一个原因它默认会覆盖已有的驱动文件如果机器上还跑着其他 CUDA 任务容易引发冲突需要先停服务再把依赖捋清楚操作风险远高于收益。2.3 CUDA Toolkit 到底要不要装这是新手最容易懵的问题。打开nvidia-smi后右上角会显示一个 CUDA Version比如 12.4这其实是当前驱动支持的最高 CUDA 版本不表示系统里已经装好了完整的 CUDA Toolkit。如果你准备直接用 Docker 部署宿主机上其实不需要装完整 CUDA Toolkit。原因很简单NVIDIA 官方的 PyTorch 镜像、vLLM 镜像里已经自带了对应版本的 CUDA 运行库容器内直接用就行宿主机的驱动只要支持相应版本即可。如果是直接在宿主机上用 Python 装 vLLM 或 PyTorch那就需要装匹配的 CUDA Toolkit或者直接用 pip 安装 PyTorch 官方预编译的 CUDA 版本后者通常更简单因为 PyTorch 的 pip 包会把 CUDA runtime 一起打包不需要再单独配置环境变量。2.4 Docker 与 NVIDIA Container Toolkit现在主流的大模型部署方案基本都会用 Docker。原因很直接服务器环境太容易被“搞脏”今天给这个项目装一套 CUDA明天给那个项目装一个 Python 环境互相对不上版本最后整个机器状态不可控。Docker 把模型、推理引擎、依赖全部打包换机器也能平滑迁移。Docker 默认是访问不了 GPU 的要额外安装 NVIDIA Container Toolkit# 安装 Docker 后配置 NVIDIA 容器运行时 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \ | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \ | sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g \ | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker安装完成后用一条命令验证容器能不能正常访问 GPUdocker run --rm --gpus all ubuntu:22.04 nvidia-smi如果能看到和宿主机一致的 GPU 列表说明环境已经打通。很多人在这一步卡住容器里跑大模型一直提示“没有检测到 GPU”根因就是没装 NVIDIA Container Toolkit或者装完没有重启 Docker 让 runtime 配置生效。2.5 部署前自检清单环境准备完成后建议用 30 秒过一遍这套自检检查项命令期望结果驱动是否可用nvidia-smi显示 GPU 型号、驱动版本、显存磁盘空间df -h剩余大于模型文件体积至少 2 倍内存free -h建议不低于 32GBCPU 推理需要更大内存Docker GPU 支持docker run --rm --gpus all ubuntu:22.04 nvidia-smi显示 GPU 信息端口占用ss -tlnp确认 8000、11434 等目标端口未占用3. 推理引擎选型从 Ollama 到 vLLM 怎么取舍3.1 Ollama本地私有化部署的第一站Ollama 是现在把模型落地的“快速通道”。它的价值是把复杂的模型加载、推理、API 服务封装成几个简单命令让一个人五分钟内把一个大模型跑起来。安装非常简单curl -fsSL https://ollama.com/install.sh | sh systemctl start ollama拉取模型ollama pull qwen2.5:7b-instruct启动推理ollama run qwen2.5:7b-instructOllama 底层对显存管理做了不少优化模型按需加载不使用时会释放显存这对一台服务器上要交替测试多个模型的场景非常友好。它还提供了 OpenAI 兼容的 HTTP API默认监听11434端口这意味着你可以用 OpenAI SDK 直接连它做开发。不过 Ollama 的短板也明显在高并发场景下的吞吐优化不如 vLLM自带的路由和批处理策略偏简单。如果你只是内网几十人内部试用Ollama 足够如果要做对外 API 服务建议把 Ollama 当“体验道具”生产部署换 vLLM。3.2 vLLM高并发服务的事实标准vLLM 是目前开源大模型推理引擎里生产使用最广的一个。它的核心优势有三个PagedAttention 显存管理、Continuous Batching 连续批处理、以及极高的吞吐量。普通推理框架处理请求时每来一个请求就单独计算一次多路请求互相抢显存vLLM 会把多个请求动态拼成一个 batch 一起算通过显存分页管理大幅提高 GPU 利用率。实际压测里vLLM 的吞吐往往是原生 PyTorch 推理服务的数倍这也是很多团队舍得用它的直接原因。安装 vLLM 可以直接用 pippip install vllm然后用一行命令启动一个 OpenAI 兼容服务vllm serve /opt/models/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000vLLM 对 GPU 驱动和 CUDA 版本有明确要求生产环境建议直接使用官方 Docker 镜像避免宿主机上 Python 依赖互相污染。但要注意vLLM 是一个迭代很快的项目新版本经常调整启动参数如果你参考的是两三年前的博客文章命令很可能对不上建议以你安装版本的官方文档为准。3.3 还要不要考虑 llama.cpp 和 SGLangllama.cpp 的价值在于它不依赖 NVIDIA GPU也能在纯 CPU 或 Apple Silicon 上运行。它使用 GGUF 量化格式在资源受限环境下表现很突出。如果你的服务器没有独立显卡又确实想跑一个大模型做离线测试llama.cpp 是值得试的路线但务必对速度有心理预期CPU 跑 7B 模型通常只有每秒几个 token 的生成速度。SGLang 是另一个高性能推理引擎在部分场景下吞吐比 vLLM 还有优势并且对结构化输出、多模态输入的支持更完善。不过它对硬件和版本的要求更高部署复杂度也更大多数团队第一套模型服务并不需要一上来就上 SGLang等团队对推理服务有了更明确的性能需求后再过渡也不迟。3.4 推理引擎横向对比引擎适合场景显存效率并发能力上手难度OpenAI API 兼容Ollama本地体验、内部试用、快速验证中中低极低是vLLM生产环境高并发 API高高中是llama.cppCPU、边缘设备、量化模型中低低是SGLang复杂控制、多模态、极致吞吐高高较高是所以我的建议是新手先用 Ollama 跑通模型拿到一次成功体验确定要上生产后用 vLLM 替代 Ollama 承担 API 流量。这两条腿走路是最稳的组合。4. 实操全流程真的在 Linux 服务器上把模型跑起来4.1 用 Ollama 快速完成第一次部署假设你手里是一台装好 Ubuntu 22.04 的服务器有一张 24GB 显存的显卡目标是把 7B 模型跑起来并给局域网内的同事提供一个可调用的 API。先确保服务在运行并监听外部地址。Ollama 默认只监听本机回环地址需要修改 systemd 服务配置来对外提供服务sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf EOF [Service] EnvironmentOLLAMA_HOST0.0.0.0 EOF sudo systemctl daemon-reload sudo systemctl restart ollama然后拉取模型并验证ollama pull qwen2.5:7b-instruct # 确认模型列表 ollama list # 调用本地 API 测试 curl http://127.0.0.1:11434/api/generate \ -H Content-Type: application/json \ -d { model: qwen2.5:7b-instruct, prompt: 用一句话解释什么是大模型, stream: false }如果返回了一段正常的文字说明你的第一个大模型服务已经成功跑起来了。局域网里的其他机器可以通过http://服务器IP:11434来访问这个服务。4.2 生产级部署用 vLLM 启动 OpenAI 兼容服务当你确认模型效果没问题并且要面向更多用户提供服务时换成 vLLM。这里以本地已经下载好的模型目录为例。先介绍如何获取模型权重。Hugging Face 是最大的模型仓库但国内服务器访问经常不稳定更推荐用 ModelScope 魔搭社区或者直接使用已经配置好的内网镜像。把模型权重下载到服务器后目录结构一般是这样的/opt/models/Qwen2.5-7B-Instruct/ ├── config.json ├── generation_config.json ├── model.safetensors.index.json ├── model-00001-of-0000X.safetensors ├── tokenizer.json └── tokenizer_config.json然后启动 vLLM 服务vllm serve /opt/models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192这里解释一下几个关键参数--gpu-memory-utilization 0.9表示允许 vLLM 使用 90% 的显存。不要设成 1.0因为驱动、CUDA context 和其他进程还要留一点空间满了容易 OOM。我一般设 0.85-0.92。--max-model-len 8192是支持的最大上下文长度。设置得越大预留给 KV Cache 的显存就越多。如果你遇到显存不足第一件事就是把这个参数调小。--host 0.0.0.0让服务监听所有网卡地址这样局域网内其他机器也能调用。多卡并行时增加参数vllm serve /opt/models/Qwen2.5-14B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 2--tensor-parallel-size 2表示把模型切成两份分别放在两张卡上并行计算。多卡服务器常见的有两种互联方式NVLink 和 PCIe。NVLink 带宽更高通信开销小PCIe 也能跑只是卡间通信会慢一些但通常不会成为主要瓶颈。服务起来后验证接口curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /opt/models/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好介绍一下你自己}], temperature: 0.7 }vLLM 的/v1/chat/completions接口和 OpenAI 格式完全一致所以后端正则开发时可以无缝切换到本地服务。4.3 用 systemd 托管服务比 nohup 稳定一百倍很多新手喜欢用nohup python xxx 启动服务然后窗口一关进程还在。这种方式最大的问题是服务崩溃了没人拉起来机器重启后也不会自动运行。生产部署请务必使用 systemd。创建一个服务文件sudo tee /etc/systemd/system/vllm.service EOF [Unit] DescriptionvLLM Inference Server Afternetwork.target [Service] Typesimple Userroot EnvironmentCUDA_VISIBLE_DEVICES0 ExecStart/usr/local/bin/vllm serve /opt/models/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000 --gpu-memory-utilization 0.9 --max-model-len 8192 Restartalways RestartSec10 [Install] WantedBymulti-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now vllm之后查看日志直接用journalctl -u vllm -f重启服务用systemctl restart vllm不用再担心进程意外退出。我见过不少人把服务跑在 screen 或 tmux 里一旦忘记哪个会话对应哪个服务维护成本会直线上升。4.4 没有 GPU 的服务器怎么办如果服务器上没有任何 NVIDIA 显卡也不一定要放弃。用 llama.cpp 跑 GGUF 量化模型是一条可走的路线只是速度会慢一个量级。典型流程是先下载 GGUF 格式的量化模型文件比如 7B 模型的 Q4_K_M 版本大约 4.5GB然后用 llama.cpp 启动服务git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make -j$(nproc) ./build/bin/llama-server \ -m /opt/models/qwen2.5-7b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080我在 32 核 CPU 服务器上测试过7B Q4 量化模型大约能跑到每秒 2-5 个 token单用户聊天勉强能接受但多用户就会陷入排队地狱。所以 CPU 部署只建议作为无卡场景的验证方案不要指望它能承担真实业务流量。5. 部署完成后必须做的优化与稳定性加固5.1 显存利用率监控与参数调优服务跑起来只是开始。第一次启动完成后我习惯开着显存监控看一段时间watch -n 1 nvidia-smi重点观察几个指标显存占用是否稳定在预期范围内、GPU 利用率是否持续有波动、温度是否过高。如果发现单次请求没问题但并发一上来就 OOM优先调整三个参数降低--max-model-len从 8192 降到 4096显存占用立刻降低一截降低--gpu-memory-utilization不过这会减少可用于 KV Cache 的总量可能影响并发上限限制并发请求数量vLLM 对应参数是--max-num-seqs这三个参数之间是互相影响的没有固定最优值。我的调参顺序是先量化或换小模型解决显存瓶颈再根据需求调节上下文长度最后才用并发限制兜底。5.2 用真实请求压一压服务部署完成后不要只拿浏览器点两下就说“能用了”建议做一个最简单的并发测试。写一个简短的 Python 脚本模拟 20 个并发请求import json import time import threading import urllib.request def send_request(idx): payload { model: /opt/models/Qwen2.5-7B-Instruct, messages: [{role: user, content: 给我讲个笑话}], max_tokens: 100 } req urllib.request.Request( http://127.0.0.1:8000/v1/chat/completions, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json} ) start time.time() with urllib.request.urlopen(req, timeout60) as resp: resp.read() print(f请求 {idx} 耗时 {time.time() - start:.2f}s) threads [] for i in range(20): t threading.Thread(targetsend_request, args(i,)) threads.append(t) t.start() for t in threads: t.join()如果 20 个并发请求全部成功且平均耗时在可接受范围内这个服务才算具备基本可用性。如果大批量超时或报错需要回到参数调优环节。5.3 Docker 化部署环境隔离与一键迁移vLLM 官方提供了 Docker 镜像可以直接把模型挂在容器里运行docker run -d \ --name vllm-server \ --gpus all \ -v /opt/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000Docker 化的好处不止隔离环境更重要的是可以让模型服务像普通微服务一样纳入 CI/CD 管理。新来的同事不需要懂 CUDA、不用装 Python 环境只需要docker pull和docker run。实际上现在各个团队最喜欢这种交付方式因为只要镜像在换机器就只是时间问题。5.4 接入内网时给服务加一道反向代理模型服务启动后默认没有鉴权谁拿到端口都能调。如果只是在内网用问题还不大但只要服务跨部门或者有暴露到公网的可能性就必须加一道控制层。最简单的做法是用 Nginx 做反向代理配合 API Key 校验或基本认证server { listen 80; server_name model.internal.example.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }更完整一点可以在 Nginx 层实现请求频率限制防止某个调用方写了个死循环把 GPU 资源打满。模型服务的算力是稀缺资源没有访问控制的 GPU 服务本质上是给整个团队埋了一颗雷。6. 高频问题与排障实录都是真实踩过的坑6.1 vLLM 启动报 CUDA out of memory这个报错八成的根因是模型规模超过显存容量。解决方案按优先级排序改用量化版本模型、降低--max-model-len、降低--gpu-memory-utilization、增加 tensor parallel 的卡数。还有一个小可能显存没有被完全释放比如上一次推理进程退出异常用nvidia-smi看一下是否有残留进程占用有就kill -9清理。6.2 容器里看不到 GPU宿主机执行nvidia-smi正常但容器内执行报错或找不到设备。99% 是因为没装 NVIDIA Container Toolkit或者装了但没有执行nvidia-ctk runtime configure --runtimedocker并重启 Docker。另一个容易忽略的点是 Docker 版本太老不支持--gpus参数建议升级 Docker Engine 到 23.0 以上。6.3 下载模型权重慢或总是中断默认从 Hugging Face 拉取大文件常常不稳定。最稳妥的做法是换用国内的 ModelScope或者先下载到本地再传到服务器。下载完务必检查文件完整性很多模型目录下有sha256校验文件用sha256sum比对一下避免模型文件半截导致加载时报各种奇怪的错误。6.4 Ollama 拉取模型时报错或直接没有 GPU 加速Ollama 在部分环境里会走 CPU 模式表现是模型能跑但速度很慢。先执行ollama ps查看模型是在 GPU 上还是 CPU 上。如果显示100% CPU说明 Ollama 没有检测到 CUDA 驱动需要检查驱动、CUDA 版本和可执行文件权限。某些场景还需要把运行 Ollama 的用户加入video和render组否则设备节点没有权限访问。6.5 服务日志里全是 timeout 或 connection reset这种情况通常不是大模型本身的问题而是上游请求方把连接超时时间设置得太短。大模型推理是典型的“慢接口”如果一个 prompt 比较复杂生成几百个 token 可能需要几十秒。调用方一定要把超时时间放宽到 60 秒以上同时确认模型服务所在主机的防火墙和云安全组规则放行了对应端口。6.6 排障速查表现象第一排查顺序常用命令GPU 不可见驱动 → Container Toolkitnvidia-smi、docker run --rm --gpus all ubuntu nvidia-smi显存不足显存占用 → max-model-lennvidia-smi启动卡住磁盘余量 → 模型完整性 → 内存df -h、free -h推理极慢GPU 利用率 → 是否走了 CPUnvidia-smi、ollama psAPI 不稳定超时设置 → 端口规则curl -v、ss -tlnp服务频繁退出显存泄漏 → 日志journalctl -u vllm -f这几个问题是我在实际部署中反复遇到的。大模型部署失败很少有一个特别玄学的原因绝大多数都是驱动没装好、显存估算错误、模型下载不完整、参数配错这几个基础问题。把环境检查和日志截图做好基本能定位 80% 的问题。从我个人经验来看在 Linux 服务器上部署大模型真正推荐的路线是先接受 Ollama 的低门槛把一个模型真正跑起来体会一次“为什么大模型服务需要 GPU”等要对外提供稳定服务时立刻切换到 vLLM 加 systemd 加 Nginx 的架构。最后再提醒一句模型服务上线后记得把系统更新和内核升级当作重要事项我遇到过不止一次因为升级内核导致 NVIDIA 驱动失效、模型服务起不来的情况。先把这一整套流程走通一次你对大模型部署的整个链路就会有完整的体感后面再遇到新模型、新引擎也只是换汤不换药。 
长河君 · 2026/9/7 16:17:08 · 阅读 1.2k Linux服务器部署大模型全流程：显存估算、推理引擎选型与生产实践
大模型从“能用”到“真正部署到 Linux 服务器的生产环境”中间其实隔着一道不小的坎。我自己过去一年多给不同团队搭过不少次大模型服务从单卡工作站到多卡 GPU 服务器都碰过这里把整套流程、踩过的坑、以及最后沉淀下来的部署思路一次性讲清楚。这篇文章适合三类人想在公司内网搭一个私有化大模型服务的运维、准备把开源模型接到业务系统里的后端开发以及刚拿到一台 GPU 服务器、不知道从哪儿下手的算法工程师。先说结论Linux 服务器部署大模型卡点从来不是“敲命令”而是三件事——硬件怎么评估、模型怎么选、推理引擎怎么挑。这三件事想明白了后面其实就是照着流程执行最多在版本兼容上花点时间。1. 部署前的核心决策算力、显存与模型匹配1.1 先给显存算一笔账别拿到服务器就开跑很多人第一次部署翻车不是技术问题而是显存不够。大模型推理时模型权重需要完整放进显存里。一个 7B 参数模型用 FP16 精度保存权重大概是 7×214GB再加上推理时动态分配的 KV Cache、CUDA context 和各种中间张量实际占用往往比单纯权重多 20%-30%。我一般会这样快速估算24GB 显存跑 7B-8B 模型最舒服基本可以留出足够空间给长上下文14B 模型想流畅跑建议 32GB 以上显存24GB 也能跑但需要量化或者把上下文长度压到很低70B 级别模型就别指望单卡了FP16 权重大概 140GB至少得两张 80GB 的卡或者多张 48GB 卡并行通常还会用 AWQ/GPTQ 量化到 4bit把权重降到 35GB 左右再考虑部署。显存不够的典型表现是程序启动后一小会儿直接报CUDA out of memory或者系统开始把显存数据换到内存速度慢到没法用。我见过不少人硬拿 16GB 显存的卡去跑 14B 模型输入一长就直接崩最后只能把max_model_len从 8192 降到 2048 才勉强跑起来体验很差。1.2 模型参数、精度与显存对照表为了让你直观选型这里把常见规模的模型做了一个对照。注意实际项目里的显存占用还受推理引擎、上下文长度、并发请求数影响下表只能作为起点的粗略估算。模型参数规模FP16/BF16 权重显存4bit 量化后权重显存建议部署显卡1B-3B2GB-6GB0.6GB-1.8GB4GB 以上即可CPU 也能凑合7B-8B14GB-16GB4.5GB-5.5GB单张 24GB如 RTX 409013B-14B26GB-28GB8GB-9GB单张 48GB 或两张 24GB32B64GB20GB 左右两张 48GB 或单张 80GB70B140GB35GB-40GB两张 80GB 或四张 48GB这里多说一句量化。很多人第一次听“4bit 量化”会担心效果变差它确实会有一定精度损失有点像图片从无损 PNG 压成高画质 JPEG肉眼大部分场景看不出来但极端细节会有损失。日常对话、文本总结、代码生成这类任务4bit 量化后的质量完全可用如果做数学推理、复杂逻辑任务建议保留 FP16或者至少用 8bit 而不要直接压到 4bit。1.3 你的场景到底需要什么模型模型选型不是“越大越好”而是“够用就好”。如果只是做内部知识库问答或日常闲聊7B-8B 级别的通用对话模型完全够用如果是面向外部用户的高并发 API 服务建议用 14B-32B 甚至更大的模型同时用 vLLM 这类高性能推理引擎如果你要处理的是长文档、代码仓库这类超长输入场景还得额外看模型的上下文长度而不是只看参数规模。场景决定部署方案这是我反复强调的一点。公司内部几十个人测着玩跟线上每天几万次调用技术架构完全是两码事。前者用 Ollama 一把梭没问题后者就得从推理引擎、并发参数、监控告警全部考虑到位。2. Linux 服务器环境准备驱动、CUDA 与容器运行时2.1 操作系统选型与基础检查做 GPU 服务器部署我首选 Ubuntu 22.04 或 24.04 LTS。原因很实在NVIDIA 驱动、CUDA、容器运行时对 Ubuntu 的支持最完善社区踩坑资料也多。用 CentOS 7 这类老系统搞大模型部署不是不行但内核版本、GCC 版本、glibc 版本都可能跟新版本 PyTorch 或 vLLM 冲突排查起来非常痛苦。拿到一台机器后先执行下面这组基础检查命令确认 CPU、内存、磁盘和 GPU 状态# CPU 与内存 lscpu free -h # 磁盘空间模型文件动辄几十 GB务必看剩余空间 df -h # 显卡是否被系统识别 lspci | grep -i nvidia # NVIDIA 驱动是否装好 nvidia-smi如果nvidia-smi能正常输出说明驱动已经装好直接跳到下一步。如果提示command not found说明驱动还没有安装需要接着往下走。2.2 NVIDIA 驱动安装能省事就省事Linux 安装 NVIDIA 驱动有几种方式我最推荐的是通过发行版仓库装尤其是 Ubuntu 上用ubuntu-drivers工具。sudo apt update sudo apt install ubuntu-drivers-common ubuntu-drivers devices sudo ubuntu-drivers installubuntu-drivers install会自动帮你选一个合适版本装完后重启再执行nvidia-smi验证。整个过程大概五分钟比去官网下载.run文件手动安装省心得多。我自己早期也爱从官网下.run包手动装结果经常遇到内核头文件版本对不上、nouveau 开源驱动没禁用导致装失败的问题后来就学乖了能用仓库包绝不留手动安装。不建议直接在正在运行的服务器上装官网.run包还有一个原因它默认会覆盖已有的驱动文件如果机器上还跑着其他 CUDA 任务容易引发冲突需要先停服务再把依赖捋清楚操作风险远高于收益。2.3 CUDA Toolkit 到底要不要装这是新手最容易懵的问题。打开nvidia-smi后右上角会显示一个 CUDA Version比如 12.4这其实是当前驱动支持的最高 CUDA 版本不表示系统里已经装好了完整的 CUDA Toolkit。如果你准备直接用 Docker 部署宿主机上其实不需要装完整 CUDA Toolkit。原因很简单NVIDIA 官方的 PyTorch 镜像、vLLM 镜像里已经自带了对应版本的 CUDA 运行库容器内直接用就行宿主机的驱动只要支持相应版本即可。如果是直接在宿主机上用 Python 装 vLLM 或 PyTorch那就需要装匹配的 CUDA Toolkit或者直接用 pip 安装 PyTorch 官方预编译的 CUDA 版本后者通常更简单因为 PyTorch 的 pip 包会把 CUDA runtime 一起打包不需要再单独配置环境变量。2.4 Docker 与 NVIDIA Container Toolkit现在主流的大模型部署方案基本都会用 Docker。原因很直接服务器环境太容易被“搞脏”今天给这个项目装一套 CUDA明天给那个项目装一个 Python 环境互相对不上版本最后整个机器状态不可控。Docker 把模型、推理引擎、依赖全部打包换机器也能平滑迁移。Docker 默认是访问不了 GPU 的要额外安装 NVIDIA Container Toolkit# 安装 Docker 后配置 NVIDIA 容器运行时 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \ | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \ | sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g \ | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker安装完成后用一条命令验证容器能不能正常访问 GPUdocker run --rm --gpus all ubuntu:22.04 nvidia-smi如果能看到和宿主机一致的 GPU 列表说明环境已经打通。很多人在这一步卡住容器里跑大模型一直提示“没有检测到 GPU”根因就是没装 NVIDIA Container Toolkit或者装完没有重启 Docker 让 runtime 配置生效。2.5 部署前自检清单环境准备完成后建议用 30 秒过一遍这套自检检查项命令期望结果驱动是否可用nvidia-smi显示 GPU 型号、驱动版本、显存磁盘空间df -h剩余大于模型文件体积至少 2 倍内存free -h建议不低于 32GBCPU 推理需要更大内存Docker GPU 支持docker run --rm --gpus all ubuntu:22.04 nvidia-smi显示 GPU 信息端口占用ss -tlnp确认 8000、11434 等目标端口未占用3. 推理引擎选型从 Ollama 到 vLLM 怎么取舍3.1 Ollama本地私有化部署的第一站Ollama 是现在把模型落地的“快速通道”。它的价值是把复杂的模型加载、推理、API 服务封装成几个简单命令让一个人五分钟内把一个大模型跑起来。安装非常简单curl -fsSL https://ollama.com/install.sh | sh systemctl start ollama拉取模型ollama pull qwen2.5:7b-instruct启动推理ollama run qwen2.5:7b-instructOllama 底层对显存管理做了不少优化模型按需加载不使用时会释放显存这对一台服务器上要交替测试多个模型的场景非常友好。它还提供了 OpenAI 兼容的 HTTP API默认监听11434端口这意味着你可以用 OpenAI SDK 直接连它做开发。不过 Ollama 的短板也明显在高并发场景下的吞吐优化不如 vLLM自带的路由和批处理策略偏简单。如果你只是内网几十人内部试用Ollama 足够如果要做对外 API 服务建议把 Ollama 当“体验道具”生产部署换 vLLM。3.2 vLLM高并发服务的事实标准vLLM 是目前开源大模型推理引擎里生产使用最广的一个。它的核心优势有三个PagedAttention 显存管理、Continuous Batching 连续批处理、以及极高的吞吐量。普通推理框架处理请求时每来一个请求就单独计算一次多路请求互相抢显存vLLM 会把多个请求动态拼成一个 batch 一起算通过显存分页管理大幅提高 GPU 利用率。实际压测里vLLM 的吞吐往往是原生 PyTorch 推理服务的数倍这也是很多团队舍得用它的直接原因。安装 vLLM 可以直接用 pippip install vllm然后用一行命令启动一个 OpenAI 兼容服务vllm serve /opt/models/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000vLLM 对 GPU 驱动和 CUDA 版本有明确要求生产环境建议直接使用官方 Docker 镜像避免宿主机上 Python 依赖互相污染。但要注意vLLM 是一个迭代很快的项目新版本经常调整启动参数如果你参考的是两三年前的博客文章命令很可能对不上建议以你安装版本的官方文档为准。3.3 还要不要考虑 llama.cpp 和 SGLangllama.cpp 的价值在于它不依赖 NVIDIA GPU也能在纯 CPU 或 Apple Silicon 上运行。它使用 GGUF 量化格式在资源受限环境下表现很突出。如果你的服务器没有独立显卡又确实想跑一个大模型做离线测试llama.cpp 是值得试的路线但务必对速度有心理预期CPU 跑 7B 模型通常只有每秒几个 token 的生成速度。SGLang 是另一个高性能推理引擎在部分场景下吞吐比 vLLM 还有优势并且对结构化输出、多模态输入的支持更完善。不过它对硬件和版本的要求更高部署复杂度也更大多数团队第一套模型服务并不需要一上来就上 SGLang等团队对推理服务有了更明确的性能需求后再过渡也不迟。3.4 推理引擎横向对比引擎适合场景显存效率并发能力上手难度OpenAI API 兼容Ollama本地体验、内部试用、快速验证中中低极低是vLLM生产环境高并发 API高高中是llama.cppCPU、边缘设备、量化模型中低低是SGLang复杂控制、多模态、极致吞吐高高较高是所以我的建议是新手先用 Ollama 跑通模型拿到一次成功体验确定要上生产后用 vLLM 替代 Ollama 承担 API 流量。这两条腿走路是最稳的组合。4. 实操全流程真的在 Linux 服务器上把模型跑起来4.1 用 Ollama 快速完成第一次部署假设你手里是一台装好 Ubuntu 22.04 的服务器有一张 24GB 显存的显卡目标是把 7B 模型跑起来并给局域网内的同事提供一个可调用的 API。先确保服务在运行并监听外部地址。Ollama 默认只监听本机回环地址需要修改 systemd 服务配置来对外提供服务sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf EOF [Service] EnvironmentOLLAMA_HOST0.0.0.0 EOF sudo systemctl daemon-reload sudo systemctl restart ollama然后拉取模型并验证ollama pull qwen2.5:7b-instruct # 确认模型列表 ollama list # 调用本地 API 测试 curl http://127.0.0.1:11434/api/generate \ -H Content-Type: application/json \ -d { model: qwen2.5:7b-instruct, prompt: 用一句话解释什么是大模型, stream: false }如果返回了一段正常的文字说明你的第一个大模型服务已经成功跑起来了。局域网里的其他机器可以通过http://服务器IP:11434来访问这个服务。4.2 生产级部署用 vLLM 启动 OpenAI 兼容服务当你确认模型效果没问题并且要面向更多用户提供服务时换成 vLLM。这里以本地已经下载好的模型目录为例。先介绍如何获取模型权重。Hugging Face 是最大的模型仓库但国内服务器访问经常不稳定更推荐用 ModelScope 魔搭社区或者直接使用已经配置好的内网镜像。把模型权重下载到服务器后目录结构一般是这样的/opt/models/Qwen2.5-7B-Instruct/ ├── config.json ├── generation_config.json ├── model.safetensors.index.json ├── model-00001-of-0000X.safetensors ├── tokenizer.json └── tokenizer_config.json然后启动 vLLM 服务vllm serve /opt/models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192这里解释一下几个关键参数--gpu-memory-utilization 0.9表示允许 vLLM 使用 90% 的显存。不要设成 1.0因为驱动、CUDA context 和其他进程还要留一点空间满了容易 OOM。我一般设 0.85-0.92。--max-model-len 8192是支持的最大上下文长度。设置得越大预留给 KV Cache 的显存就越多。如果你遇到显存不足第一件事就是把这个参数调小。--host 0.0.0.0让服务监听所有网卡地址这样局域网内其他机器也能调用。多卡并行时增加参数vllm serve /opt/models/Qwen2.5-14B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 2--tensor-parallel-size 2表示把模型切成两份分别放在两张卡上并行计算。多卡服务器常见的有两种互联方式NVLink 和 PCIe。NVLink 带宽更高通信开销小PCIe 也能跑只是卡间通信会慢一些但通常不会成为主要瓶颈。服务起来后验证接口curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /opt/models/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好介绍一下你自己}], temperature: 0.7 }vLLM 的/v1/chat/completions接口和 OpenAI 格式完全一致所以后端正则开发时可以无缝切换到本地服务。4.3 用 systemd 托管服务比 nohup 稳定一百倍很多新手喜欢用nohup python xxx 启动服务然后窗口一关进程还在。这种方式最大的问题是服务崩溃了没人拉起来机器重启后也不会自动运行。生产部署请务必使用 systemd。创建一个服务文件sudo tee /etc/systemd/system/vllm.service EOF [Unit] DescriptionvLLM Inference Server Afternetwork.target [Service] Typesimple Userroot EnvironmentCUDA_VISIBLE_DEVICES0 ExecStart/usr/local/bin/vllm serve /opt/models/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000 --gpu-memory-utilization 0.9 --max-model-len 8192 Restartalways RestartSec10 [Install] WantedBymulti-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now vllm之后查看日志直接用journalctl -u vllm -f重启服务用systemctl restart vllm不用再担心进程意外退出。我见过不少人把服务跑在 screen 或 tmux 里一旦忘记哪个会话对应哪个服务维护成本会直线上升。4.4 没有 GPU 的服务器怎么办如果服务器上没有任何 NVIDIA 显卡也不一定要放弃。用 llama.cpp 跑 GGUF 量化模型是一条可走的路线只是速度会慢一个量级。典型流程是先下载 GGUF 格式的量化模型文件比如 7B 模型的 Q4_K_M 版本大约 4.5GB然后用 llama.cpp 启动服务git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make -j$(nproc) ./build/bin/llama-server \ -m /opt/models/qwen2.5-7b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080我在 32 核 CPU 服务器上测试过7B Q4 量化模型大约能跑到每秒 2-5 个 token单用户聊天勉强能接受但多用户就会陷入排队地狱。所以 CPU 部署只建议作为无卡场景的验证方案不要指望它能承担真实业务流量。5. 部署完成后必须做的优化与稳定性加固5.1 显存利用率监控与参数调优服务跑起来只是开始。第一次启动完成后我习惯开着显存监控看一段时间watch -n 1 nvidia-smi重点观察几个指标显存占用是否稳定在预期范围内、GPU 利用率是否持续有波动、温度是否过高。如果发现单次请求没问题但并发一上来就 OOM优先调整三个参数降低--max-model-len从 8192 降到 4096显存占用立刻降低一截降低--gpu-memory-utilization不过这会减少可用于 KV Cache 的总量可能影响并发上限限制并发请求数量vLLM 对应参数是--max-num-seqs这三个参数之间是互相影响的没有固定最优值。我的调参顺序是先量化或换小模型解决显存瓶颈再根据需求调节上下文长度最后才用并发限制兜底。5.2 用真实请求压一压服务部署完成后不要只拿浏览器点两下就说“能用了”建议做一个最简单的并发测试。写一个简短的 Python 脚本模拟 20 个并发请求import json import time import threading import urllib.request def send_request(idx): payload { model: /opt/models/Qwen2.5-7B-Instruct, messages: [{role: user, content: 给我讲个笑话}], max_tokens: 100 } req urllib.request.Request( http://127.0.0.1:8000/v1/chat/completions, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json} ) start time.time() with urllib.request.urlopen(req, timeout60) as resp: resp.read() print(f请求 {idx} 耗时 {time.time() - start:.2f}s) threads [] for i in range(20): t threading.Thread(targetsend_request, args(i,)) threads.append(t) t.start() for t in threads: t.join()如果 20 个并发请求全部成功且平均耗时在可接受范围内这个服务才算具备基本可用性。如果大批量超时或报错需要回到参数调优环节。5.3 Docker 化部署环境隔离与一键迁移vLLM 官方提供了 Docker 镜像可以直接把模型挂在容器里运行docker run -d \ --name vllm-server \ --gpus all \ -v /opt/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000Docker 化的好处不止隔离环境更重要的是可以让模型服务像普通微服务一样纳入 CI/CD 管理。新来的同事不需要懂 CUDA、不用装 Python 环境只需要docker pull和docker run。实际上现在各个团队最喜欢这种交付方式因为只要镜像在换机器就只是时间问题。5.4 接入内网时给服务加一道反向代理模型服务启动后默认没有鉴权谁拿到端口都能调。如果只是在内网用问题还不大但只要服务跨部门或者有暴露到公网的可能性就必须加一道控制层。最简单的做法是用 Nginx 做反向代理配合 API Key 校验或基本认证server { listen 80; server_name model.internal.example.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }更完整一点可以在 Nginx 层实现请求频率限制防止某个调用方写了个死循环把 GPU 资源打满。模型服务的算力是稀缺资源没有访问控制的 GPU 服务本质上是给整个团队埋了一颗雷。6. 高频问题与排障实录都是真实踩过的坑6.1 vLLM 启动报 CUDA out of memory这个报错八成的根因是模型规模超过显存容量。解决方案按优先级排序改用量化版本模型、降低--max-model-len、降低--gpu-memory-utilization、增加 tensor parallel 的卡数。还有一个小可能显存没有被完全释放比如上一次推理进程退出异常用nvidia-smi看一下是否有残留进程占用有就kill -9清理。6.2 容器里看不到 GPU宿主机执行nvidia-smi正常但容器内执行报错或找不到设备。99% 是因为没装 NVIDIA Container Toolkit或者装了但没有执行nvidia-ctk runtime configure --runtimedocker并重启 Docker。另一个容易忽略的点是 Docker 版本太老不支持--gpus参数建议升级 Docker Engine 到 23.0 以上。6.3 下载模型权重慢或总是中断默认从 Hugging Face 拉取大文件常常不稳定。最稳妥的做法是换用国内的 ModelScope或者先下载到本地再传到服务器。下载完务必检查文件完整性很多模型目录下有sha256校验文件用sha256sum比对一下避免模型文件半截导致加载时报各种奇怪的错误。6.4 Ollama 拉取模型时报错或直接没有 GPU 加速Ollama 在部分环境里会走 CPU 模式表现是模型能跑但速度很慢。先执行ollama ps查看模型是在 GPU 上还是 CPU 上。如果显示100% CPU说明 Ollama 没有检测到 CUDA 驱动需要检查驱动、CUDA 版本和可执行文件权限。某些场景还需要把运行 Ollama 的用户加入video和render组否则设备节点没有权限访问。6.5 服务日志里全是 timeout 或 connection reset这种情况通常不是大模型本身的问题而是上游请求方把连接超时时间设置得太短。大模型推理是典型的“慢接口”如果一个 prompt 比较复杂生成几百个 token 可能需要几十秒。调用方一定要把超时时间放宽到 60 秒以上同时确认模型服务所在主机的防火墙和云安全组规则放行了对应端口。6.6 排障速查表现象第一排查顺序常用命令GPU 不可见驱动 → Container Toolkitnvidia-smi、docker run --rm --gpus all ubuntu nvidia-smi显存不足显存占用 → max-model-lennvidia-smi启动卡住磁盘余量 → 模型完整性 → 内存df -h、free -h推理极慢GPU 利用率 → 是否走了 CPUnvidia-smi、ollama psAPI 不稳定超时设置 → 端口规则curl -v、ss -tlnp服务频繁退出显存泄漏 → 日志journalctl -u vllm -f这几个问题是我在实际部署中反复遇到的。大模型部署失败很少有一个特别玄学的原因绝大多数都是驱动没装好、显存估算错误、模型下载不完整、参数配错这几个基础问题。把环境检查和日志截图做好基本能定位 80% 的问题。从我个人经验来看在 Linux 服务器上部署大模型真正推荐的路线是先接受 Ollama 的低门槛把一个模型真正跑起来体会一次“为什么大模型服务需要 GPU”等要对外提供稳定服务时立刻切换到 vLLM 加 systemd 加 Nginx 的架构。最后再提醒一句模型服务上线后记得把系统更新和内核升级当作重要事项我遇到过不止一次因为升级内核导致 NVIDIA 驱动失效、模型服务起不来的情况。先把这一整套流程走通一次你对大模型部署的整个链路就会有完整的体感后面再遇到新模型、新引擎也只是换汤不换药。