最近一个月连续帮几个团队搞定了大模型在Linux服务器上的部署，从个人玩票的小项目到要给几十人提供服务的内部平台都碰了一遍。过程中踩了不少坑，也总结出一套相对稳定的落地路径。这篇就把我在Linux服务器上部署大模型的全过程拆开讲清楚，包括硬件评估、环境准备、工具选型、实际部署命令，以及高频问题的排查方法，希望能帮你少走几天弯路。
如果你正准备在自己手头的Linux服务器上把大模型跑起来，或者已经在折腾但被显存、CUDA、Docker这些环节卡住，这篇文章应该适合你。我尽量用实际操作的视角来讲，不堆理论，每个步骤都给出可以直接照抄的命令和配置。
1. 部署前先想清楚三件事
很多人在Linux服务器上部署大模型翻车，往往不是操作步骤的问题，而是最开始就没想清楚“我要跑什么样的模型、拿它来干嘛”。这三个问题想明白，后面基本就是在执行。
1.1 硬件底线：显存、内存、磁盘怎么算
大模型推理最核心的资源是显存，不是CPU也不是内存。显存决定了你最多能跑多大的模型。
有个简单的估算方法：1B参数的模型，FP16精度大概占2GB显存，再加上激活值和KV Cache之类的开销，算3GB比较稳。所以7B模型FP16大概需要21GB显存，13B大概40GB，70B至少要200GB以上，单卡根本放不下。
但这说的是FP16，实际部署时基本都会做量化。INT4量化之后，7B模型只要大概7-8GB显存，13B大概15GB左右，这样一张3090（24GB）或者4090（24GB）就能跑得很舒服。量化会牺牲一点精度，但这种损失在绝大多数对话和内容生成场景里几乎感知不到。
内存方面，至少保证CPU内存是显存的2倍，比如24GB显存的卡配32GB或者64GB内存比较合理。磁盘则是个经常被忽略的点，一个7B模型文件大约4-8GB，70B量化后也有40-50GB，加上Docker镜像、Python环境、日志等，建议预留至少100GB可用空间。我见过有人服务器磁盘剩余不到10GB，模型下载到一半直接写满，导致服务崩溃。
GPU型号上，目前性价比最高的是RTX 3090、4090这类的消费级卡，24GB显存足以覆盖绝大多数中小模型。企业预算充足可以用A100、H100这些专业卡。多个卡可以组张量并行，但不是简单叠加，要框架配合。
1.2 先定场景再选工具
同一个大模型，在不同使用场景下最优的部署方案完全不同。我通常会把需求分成三类：
第一类是个人实验、开发者本地调试。这种场景并发低、要灵活，往往今天跑A模型明天换B模型。这类需求用Ollama这类开箱即用的工具最合适，一条命令把模型拉下来就能聊天，环境变量切模型也方便。
第二类是团队共享服务，比如给公司内部几十人提供统一的问答能力。这种场景并发有一定要求，又要稳定。此时Ollama还勉强能用，但更推荐vLLM这类专门做推理优化的框架，吞吐量高很多。
第三类是生产环境的API服务，对延迟、并发、可用性都有明确指标。这种必须上vLLM或者Triton这样的专业推理服务，配合Docker做隔离和编排。
很多新手一上来就找部署教程，照着装了个vLLM，发现配置复杂、参数又多，半个月还在折腾环境。其实他如果只是自己跑着玩玩，装个Ollama十分钟就完事了。所以先定场景，再选工具，这比任何技术细节都重要。
1.3 模型选型的几个参考
模型选择也要结合显存和场景。我的日常推荐是：
- 7B~8B级别：Qwen2.5-7B-Instruct、DeepSeek-R1-Distill-Qwen-7B、Llama-3.1-8B，适合显存8-16GB的场景，中文能力都不错。
- 14B~32B级别：Qwen2.5-14B/32B、DeepSeek-R1-Distill-Llama-70B需要更大显存，单卡24GB只能跑INT4量化版本。
- 72B以上：建议直接上多卡方案或者用API，本地部署的性价比已经很低了。
搜索热词里出现的“deepseek部署”“ollama本地部署”基本都是跑前面几个小模型。至于DeepSeek-R1完整版是671B的MoE模型，本地部署需要极高配置，普通团队不建议尝试。
2. Linux环境准备：少走三天弯路
部署环境一旦乱，后面所有步骤都会带着病跑。我这里把Linux服务器上部署大模型的环境准备流程完整列一遍，每一步都是踩过坑后留下的版本。
2.1 先检查系统现状
接手一台服务器，先看清配置再动手。三条命令搞定：
# 查看CPU、内存、磁盘 lscpu free -h df -h # 查看GPU型号和当前驱动状态 nvidia-sminvidia-smi输出的信息很关键，除了看显卡型号，还要看右上角的Driver Version和CUDA Version。这里的CUDA Version是当前驱动支持的最高CUDA版本，不只是当前已经在用的版本。很多依赖会要求CUDA 11.8或者12.1，驱动版本太旧会直接卡在下一步。
系统层面，Ubuntu 22.04 LTS是我用得最顺的版本，兼容性问题最少。如果是CentOS 7这种老系统，建议先升级或者迁移到基于Ubuntu的环境。不是说CentOS不能跑，而是很多新框架对老内核支持不好，同样的问题在Ubuntu上查资料都方便很多。
2.2 驱动与CUDA：最容易翻车的环节
NVIDIA驱动安装方式很多，推荐用官方仓库装，稳定且方便后续维护：
# 添加NVIDIA官方仓库（以Ubuntu为例） sudo apt update sudo apt install -y nvidia-driver-535 sudo reboot驱动装完，执行nvidia-smi能看到显卡信息就说明驱动没问题。这时候有一个关键区别要分清：系统驱动装好后，带的是运行时CUDA；而PyTorch、vLLM这些框架通常会自己带CUDA运行时，不需要单独装完整的CUDA Toolkit。除非要做编译工作，否则不用装全套CUDA，省掉很多版本冲突的麻烦。
如果PyTorch检测不到GPU，优先检查驱动版本和PyTorch对应的CUDA版本是否匹配。例如你用的PyTorch带的是CUDA 12.1，但服务器驱动只支持到CUDA 11.8，那就铁定报错。解决办法是升级驱动或者安装对应支持的PyTorch版本。
# 确认PyTorch能正常使用GPU import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))这段测试代码我在每台新服务器上都先跑一遍，输出True才继续往下装，不然等模型拉到一半才报设备错误，排查成本高得多。
2.3 Docker与GPU透传配置
容器化部署是我强烈推荐的方式，环境隔离、迁移方便、不污染宿主机。安装Docker：
curl -fsSL https://get.docker.com | bash sudo systemctl enable --now docker但Docker里要使用GPU，必须装NVIDIA Container Toolkit，很多人漏了这一步就报“无法识别GPU”：
# 以Ubuntu为例 sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker验证方式：
docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi能正常输出显卡信息就说明GPU透传没问题。另外，部署大模型时容器要加--shm-size参数，默认64MB会不够，建议设置2GB以上，否则并发请求稍微多一点就报内存错误。
2.4 Python环境与用户权限
即使走Docker路线，宿主机上也得有一个可用的Python环境做测试、写脚本。推荐用Miniconda管理，干净且版本隔离：
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh conda create -n llm python=3.11 -y conda activate llm顺带提一下Linux新建用户的问题。部署大模型服务时千万别用root直接跑，权限太大会有安全风险。规范做法是建一个专用用户：
sudo useradd -m -s /bin/bash llm-service sudo passwd llm-service sudo usermod -aG docker llm-service这样服务的文件、日志、模型都归这个用户管理，出了问题隔离性也好。还有一个细节是ssh连接超时问题，大模型下载动辄几GB，SSH断开的次数我碰过太多次。建议用tmux或者screen挂长任务：
tmux new -s download # 在tmux里执行下载命令 # 按 Ctrl+B 然后按 D 脱离会话 # 重新连接：tmux attach -t download3. 部署工具选型：Ollama、vLLM、llama.cpp到底选谁
工具链的选择直接影响你后续的维护成本。我把主流方案按适用场景分开讲，你直接对号入座。
3.1 Ollama：个人体验和轻量服务的首选
Ollama可以说是目前本地跑大模型门槛最低的方案。它把模型下载、量化、推理服务化全包了，一条命令拉起一个OpenAI兼容的API服务。
典型用法：
# 安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取并运行模型 ollama run qwen2.5:7b-instruct就这么简单，模型自动下载、自动做量化、自动起服务。而且Ollama默认提供一个127.0.0.1:11434的HTTP接口，兼容OpenAI的/v1/chat/completions格式，写代码对接非常方便。
要让局域网或者外部访问，需要修改监听地址。我碰到好几个人抱怨Ollama只能在服务器本机访问，其实就是默认监听127.0.0.1。设置环境变量OLLAMA_HOST=0.0.0.0并重启服务就行。
Ollama适合的场景是：并发要求不高（个位数）、需要快速尝试各种模型、不想维护复杂环境。缺点是并发能力一般，高并发下吞吐量比vLLM差不少。
3.2 vLLM：并发和生产环境的王牌
vLLM的核心优势在于PagedAttention和Continuous Batching，它把显存利用率拉高了一个量级。同样一张4090跑同一个13B量化模型，vLLM的并发吞吐量能做到Ollama的3-5倍。
启动一个模型做API服务：
vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --quantization awq这才是生产环境该有的样子。参数可调空间大，语义也清晰。不过使用门槛较高，要理解tensor-parallel-size、max-model-len、gpu-memory-utilization这些概念，调不好会浪费显存或者直接OOM。
vLLM的部署我用Docker做，一方面隔离系统环境，另一方面换版本方便：
docker run --gpus all \ -p 8000:8000 \ --shm-size=2g \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct3.3 llama.cpp：极限显存下的救兵
如果你手头只有一张8GB显存的卡，甚至没有独显只有CPU，llama.cpp系列值得认真考虑。它用GGUF量化格式把模型压得很小，同时支持CPU推理，速度虽然不如GPU但胜在能跑。
它的API服务方式是通过llama-server提供OpenAI兼容接口，还支持在CPU内存和GPU显存之间分配层数，非常灵活。对于老服务器或者带显卡但显存小的机器，llama.cpp是最后的兜底方案。
3.4 Transformers与LLaMA-Factory
如果你要做的是大模型微调或者代码级开发，就要用到Hugging Face Transformers库。它灵活、可控，适合研究场景，但直接拿来做生产推理服务性能不够。
配合LLaMA-Factory这类微调工具，可以在本地对模型做LoRA微调，调整完再导出去用vLLM或者Ollama部署。路线是：微调用Transformers/LLaMA-Factory，推理用vLLM/Ollama。
做一个简单对比：
| 工具 | 上手难度 | 并发能力 | 适合场景 |
|---|---|---|---|
| Ollama | 极低 | 中低 | 个人体验、轻量服务 |
| vLLM | 中高 | 高 | 生产环境、并发API |
| llama.cpp | 中 | 中低 | 显存极小、CPU推理 |
| Transformers | 高 | 低 | 研究、微调、二次开发 |
4. 实操：把DeepSeek-R1跑起来
这一章给三个完整的实操方案，你在服务器上照着敲就能跑通。模型以当前热度很高的DeepSeek-R1蒸馏系列为例，这套流程同样适用于Qwen、Llama等其他模型。
4.1 用Ollama五分钟拉起本地模型
这是最快的一条路。在确认NVIDIA驱动没问题后：
# 1. 安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 2. 看模型列表 ollama list # 3. 运行DeepSeek-R1蒸馏版（7B） ollama run deepseek-r1:7b第一次运行会自动从模型仓库下载，7B模型大概4-6GB，网速好的话几分钟就完。下载完进入交互式命令行，直接就能提问。如果要退出聊天用/bye。
如果需要让局域网的人使用，要给Ollama开放监听。因为Ollama是systemd管理的，修改方式有讲究：
sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf << 'EOF' [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" EOF sudo systemctl daemon-reload sudo systemctl restart ollama这样同一个局域网里的人就能访问http://你的服务器IP:11434了。实测一个8人的小团队用7B模型，日常问答和文档总结完全够用。
4.2 用vLLM跑一个生产级API服务
当并发上来了，Ollama会明显变慢，这时候就上vLLM。
先在conda环境里装：
conda activate llm pip install vllm启动服务：
vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92参数含义逐个说明：
--host 0.0.0.0允许外部访问，不设置的话只允许本机。--max-model-len 8192限制最大输入加输出总长度，调大占用显存多，调小了长文本会报错。--gpu-memory-utilization 0.92允许模型最多使用92%的显存，留一部分给中间计算和系统缓冲。显存刚好卡在边缘时，这个值可以往低调。
启动成功后，服务会提供OpenAI兼容接口，调用方式和调用GPT接口一模一样：
curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B", "messages": [{"role": "user", "content": "用一句话介绍Linux"}] }'返回的JSON结构里，choices[0].message.content就是模型答案。这段代码可以直接套进任何会调OpenAI接口的程序里，只要把base_url改成本地地址就行。
4.3 模型文件从哪下载、怎么管理
很多场景下服务器在局域网内，不能直接访问海外模型服务，这时候从ModelScope下载更稳定。ModelScope对国内用户友好，下载速度快。
先安装工具：
pip install modelscope然后下载模型：
modelscope download --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B --local_dir /data/models/deepseek-r1-7b下载完的模型目录结构一般是：
/data/models/deepseek-r1-7b/ ├── config.json ├── model.safetensors.index.json ├── model-00001-of-0000X.safetensors ├── tokenizer.json └── ...用vLLM加载本地模型时，直接指定这个目录：
vllm serve /data/models/deepseek-r1-7b \ --host 0.0.0.0 \ --port 8000模型文件管理建议统一放在/data/models下，不要散放在用户目录，后面维护起来方便。模型名尽量带版本或日期，比如deepseek-r1-7b-v1.2，方便回滚。
4.4 给模型配一个Web界面
命令行聊天只是验收模型，真正给团队用还是要一个Web界面。我自己用的组合是Open WebUI加Ollama，或者Dify接vLLM。
Open WebUI对Ollama支持最好，一个命令搞定：
docker run -d --gpus all \ -p 3000:8080 \ -v open-webui:/app/backend/data \ -e OLLAMA_BASE_URL=http://宿主机IP:11434 \ --name open-webui \ ghcr.io/open-webui/open-webui:main然后访问http://服务器IP:3000，注册账号进去就能和模型聊天了，界面体验很像ChatGPT。
如果是企业内部流程集成，Dify更合适。它本身是一个LLM应用开发平台，可以接Ollama或者vLLM作为模型供应方，再用可视化编排的方式设计Agent流程、知识库问答。Dify部署用它的docker-compose脚本，具体步骤在它官网有。
4.5 写一段Python代码调用模型API
既然已经部署成OpenAI兼容接口，业务代码对接就非常顺。无论你用的是Ollama的11434端口还是vLLM的8000端口，代码只是换个base_url的区别。
from openai import OpenAI client = OpenAI( base_url="http://你的服务器IP:8000/v1", api_key="EMPTY" ) resp = client.chat.completions.create( model="deepseek-ai/DeepSeek-R1-Distill-Qwen-7B", messages=[ {"role": "user", "content": "帮我写一段递归遍历目录的Python代码"} ], temperature=0.7, max_tokens=2048 ) print(resp.choices[0].message.content)注意base_url要写到/v1，后面不要跟斜杠。本地测试建议先跑这段代码确认接口通，再去改业务调用。
5. 显存不够？性能调优的六个有效手段
决定一个部署方案能不能稳定跑起来，关键看显存管理。下面整理了我实测有效的调优手段。
5.1 量化：精度和显存的博弈
量化的直观效果是把模型权重用更低的位宽存储。FP16（16位）是标准精度，INT8（8位）大约显存减半，INT4（4位）再减半。
我用一张表总结：
| 量化级别 | 7B模型约需显存 | 13B模型约需显存 | 精度损失 |
|---|---|---|---|
| FP16 | ~21GB | ~38GB | 无 |
| INT8 | ~12GB | ~20GB | 极小 |
| INT4 | ~8GB | ~13GB | 小，可忽略 |
Ollama会自动用适配的量化格式，不需要操作。vLLM加载量化模型要指定对应参数，比如AWQ量化模型，启动时带--quantization awq。GGUF格式则配合--quantization gguf。
我做过一个测试，用同一个7B模型跑一批中文阅读理解题，FP16的准确率比INT4高不到1个百分点，但显存占用差了接近3倍。对于绝大部分业务场景，INT4完全够用。
5.2 上下文长度和KV Cache
很多人忽略了上下文窗口对显存的影响。模型生成每个token，都需要把之前所有token的Key和Value保存在显存里，这部分叫KV Cache。上下文越长，KV Cache占用越大。同样是7B模型，2048的上下文和8192的上下文，KV Cache的显存消耗可能差好几GB。
如果业务里不需要特别长的上下文，建议把max-model-len设成4096或者2048，显存能省出一大截。如果你发现一加长文本就OOM，先别急着怪模型，看看是不是上下文长度设置过高。
5.3 关键启动参数逐个说
vLLM的几个参数我实际调用的经验：
--gpu-memory-utilization：默认是0.9，意思是模型和KV Cache最多用90%显存。单卡24GB显存，模型只剩小几GB给KV Cache时，可以把值往0.95调，但风险是系统其他进程没有显存余量。--max-num-seqs：限制并发的序列数，默认256。并发窗口开太大，每个请求长度又不稳定，容易触发OOM。我会根据显存动态调整，24GB卡一般设64。--enforce-eager：关闭CUDA Graph加速，减少启动时显存预占用，但会稍微降低推理速度。显存紧张时用它救急有效。
Ollama调参相对有限，主要通过OLLAMA_KEEP_ALIVE、OLLAMA_NUM_PARALLEL这类环境变量控制模型驻留和并发。如果参数调到头还是卡，那说明该换更大的机器或者迁移到vLLM了。
5.4 监控与压测
部署上线前，我建议至少跑一轮简单的压测，看看服务到底能承受多大并发。
# 用nvidia-smi持续监控显存占用，每2秒刷新一次 watch -n 2 nvidia-smi # 用curl做简单并发请求测试 for i in $(seq 1 20); do curl -s -o /dev/null -w "请求$i: %{http_code} 耗时%{time_total}s\n" \ -H "Content-Type: application/json" \ -d '{"messages": [{"role": "user", "content": "你好"}]}' \ http://localhost:8000/v1/chat/completions & done wait观察响应时间和显存变化，如果显存占用一直顶到100%，说明并发超过服务能力了。这时候要么降并发，要么加显存，要么换更大的机器。注意压测不要用生产环境跑，模型的输出质量和延迟会互相影响。
6. 常见问题排查实录
我把这段时间被问到最多、也最常踩的几个问题列成一份排查清单，每一条都是实际遇到的，对应具体解决方案。
6.1 显存不足与OOM
现象：启动时报CUDA out of memory或者直接Killed。
排查顺序：
- 执行
nvidia-smi看显存是不是被其他进程占了，比如之前遗留的Python进程没杀掉。 - 用
fuser -v /dev/nvidia*可以查到哪个进程占用了GPU。 - 清理无用进程，再调低
gpu-memory-utilization或者换更小的量化模型。
注意多个服务不要同时加载多个大模型到同一块卡上，不同模型的加载会互相挤爆显存。
6.2 GPU能用但PyTorch认不到
现象：nvidia-smi正常显示显卡，但torch.cuda.is_available()返回False。
原因基本是PyTorch自带的CUDA版本和驱动能支持的CUDA版本不匹配。解决方式：
# 卸载现有PyTorch pip uninstall torch torchvision torchaudio # 安装与驱动匹配的版本，例如CUDA 12.1 pip install torch --index-url https://download.pytorch.org/whl/cu121装完再跑一次验证脚本，看到True就说明好了。
6.3 模型下载总是中断
现象：下载到一半卡住或者自动断掉，重新下载又从零开始。
解决建议：
- 优先使用带断点续传的工具，比如ModelScope、Hugging Face CLI。
- 下载任务放到tmux里跑，避免SSH断开导致中断。
- 不要在高负载情况下下载，磁盘IO竞争会拖慢速度。
- 下载完先校验文件完整性再加载，带
.safetensors分片文件的模型尤其要注意分片是否齐全。
6.4 外网或局域网访问不了
现象：服务在服务器本机可以访问，但其他电脑访问不到。
排查步骤：
- 先用
curl http://127.0.0.1:8000/v1/models确认服务正常。 - 再用局域网IP测试
curl http://服务器IP:8000/v1/models，不通就可能是防火墙问题。 - 开放对应端口，Ubuntu上可以用：
sudo ufw allow 8000/tcp - 检查云服务器安全组规则，云厂商的安全策略默认会挡住所有外部流量，需要在控制台里放行端口。
- 确认服务启动参数里
--host是0.0.0.0而不是127.0.0.1。
6.5 Docker容器里看不到GPU
现象：容器起来后，nvidia-smi报错，说找不到NVIDIA驱动。
原因就是没装NVIDIA Container Toolkit，或者装了但没有重新加载Docker守护进程。按第2.3节的命令执行一遍，然后：
sudo systemctl restart docker如果还不行，查一下Docker版本是否太老，老版本对GPU支持不完善，建议升级到较新的稳定版。
6.6 回答变慢或乱码
变慢的原因通常有三个：显存不够，模型在做CPU回退；并发太高，服务在排队；上下文太长，KV Cache占满了显存。
乱码问题基本和模型本身或者tokenizer有关，常见于量化出错。先重新下载原版模型试试，排除文件损坏的可能；再确认模型确实支持中文，有些英文开源模型对中文支持很差，不是部署问题。
最后再分享一个小技巧
部署过程里我感受到的一个明确规律是：不要一开始就追求最复杂、最“专业”的方案。很多个人的服务器就一张24GB的卡，非要去折腾多卡分布式推理，纯属浪费时间。老老实实Ollama拉一个7B量化模型，跑起来再说，等团队规模上来了再平滑迁移到vLLM，这才是性价比最高的路径。
另外，模型文件记得定期备份，特别是辛辛苦苦微调跑出来的模型。服务器磁盘损坏或者误删文件的时候，你就知道一份离线备份有多重要了。
如果你在部署中也踩了什么我上面没提到的坑，欢迎回来交流。这个领域发展很快，新的工具、新的模型天天在更新，但基本的部署逻辑短时间内不会变。
