企业官网建设流程全解析

1. 项目概述：为什么部署大模型最后都绕不开Linux服务器

大模型这波浪潮起来之后，我身边越来越多同事开始接触“大模型Linux服务器部署”这个事。有的是公司内部要做私有化的知识库问答，有的是个人买了块显卡想在服务器上跑一个私有聊天机器人，还有的是课程作业需要把模型跑起来出接口。不管哪种需求，最后落地的时候基本都会走到同一条路：把开源大模型部署到一台Linux服务器上，对外提供API接口。

这篇文章我会把自己从零开始踩坑到真正跑通的经验写出来，涵盖硬件选型、驱动环境、推理框架选择、Ollama和vLLM两套完整实操流程，以及最近帮朋友排查时遇到的典型问题。适合刚接触大模型部署、或者已经在Windows上跑过但想迁到Linux服务器上的朋友。全文不会绕弯子，就是直接告诉你什么方案能跑通、为什么这么选、以及哪些坑我已经替你踩过了。

1.1 为什么推荐Linux而不是Windows

这不是在制造阵营对立，而是实际对比下来，Linux服务器部署大模型的成本确实低得多。

一个很现实的原因是生态。NVIDIA驱动、CUDA工具包、PyTorch等深度学习框架，基本都是Linux上优先适配。官方文档里给的安装命令大多是apt、yum，GPU容器镜像也默认基于Linux，像nvidia-container-toolkit这种组件在Windows上压根没法直接用。你真想在Windows里跑大模型服务，最常见的方式是装WSL2，本质还是开了一个Linux子系统，那还不如直接上Linux来得干净。

另一个原因是资源占用。Windows系统本身吃内存和CPU，加上图形界面、后台服务，一台服务器如果装了Windows，白白占掉好几个G的内存，这对跑大模型来说是实实在在的浪费。Linux命令行界面下系统占用非常低，同样一台机器，能留给模型推理的资源更多。

再说运维层面。真实生产环境里，大模型通常要作为后台服务常驻运行，需要配systemd、写日志轮转、设置开机自启、用Docker做环境隔离，这些操作在Linux下都是一条命令或者一个配置文件的事。Windows上做类似的守护进程管理，要多费不少劲。所以我的建议很简单：正儿八经要部署，就用Linux，哪怕只是在一台旧电脑上玩，装个Ubuntu Server也值得。

1.2 本次部署的整体思路与方案选型

在动手装环境之前，先理清楚整条链路。大模型部署看起来高大上，拆开其实就四步：准备好硬件和系统、装好GPU驱动和运行环境、把模型文件加载到显存、对外提供推理接口。

模型文件怎么加载、接口怎么提供，这一步的选择最多。目前主流方案有两类：一类是Ollama这种开箱即用的工具，适合个人使用和小并发场景；另一类是vLLM这类专门为生产设计的推理引擎，适合并发高、要求吞吐量的服务。

我这次会两套都讲，但侧重点不同。如果只是自己测试、局域网内几十个人用，Ollama是最短路径，一条命令装完，两条命令就能跑起来；如果是公司内部多个业务系统接入，或者要做性能压测，vLLM是更稳的选择，它用到了一系列针对GPU显存和调度优化的手段，吞吐量比Ollama高不少。

模型方面，以当前主流的开源中文模型Qwen2.5系列为例，正好覆盖7B、14B这种最常用的规模。这类模型在消费级显卡上能跑，在专业GPU服务器上也能跑，非常典型。

2. 环境准备：硬件、系统、驱动与容器

很多人容易犯一个错误，模型还没下载呢，先把环境一通猛装，最后发现显卡驱动跟CUDA版本对不上，或者Docker起不来，白白折腾一整天。部署大模型其实讲究顺序：先确定显存规格，再装对应驱动，最后才轮到推理框架。

2.1 显存估算与硬件选型

大模型推理最核心的瓶颈就是显存。模型参数不是从磁盘流式读取的，而是要完整装进显存等待被调用，显存不够直接OOM，连跑都跑不起来。

显存占用怎么估算？一个最简单的公式：模型权重显存约等于参数量乘以每个参数的字节数。以FP16精度为例，每个参数占2字节，那么一个7B参数的模型，权重就需要约14GB显存。14B模型是28GB，听起来还够用，但这还只是权重部分。实际推理时还要加上KV Cache、CUDA上下文、推理引擎自身的临时缓冲区，通常额外预留2到4GB才算稳妥。

所以选硬件前先做一道简单的数学题。如果你手头是一张消费级RTX 4090 24GB，跑7B模型用FP16完全没问题，跑14B模型就会比较紧张，需要用量化方案压缩权重，比如INT4精度下7B模型只需要约4GB，14B约8GB。如果是企业级的A100 80GB或者多卡服务器，那基本上主流开源模型都能放心跑。

我整理了一个参考表格，大家可以直接对照：

这里提醒一句，买卡不要只看显存，还要注意显存带宽。大模型推理是典型的带宽密集型任务，显存带宽低的卡跑起来会很吃力。消费级显卡里4090的带宽就明显高于同系列的60级别，这也是为什么同样7B模型，4090跑起来速度快一大截。

2.2 Linux系统安装与GPU驱动

系统选择上，Ubuntu 22.04 LTS是当前最稳的选择，因为NVIDIA驱动、CUDA、PyTorch都有针对它的预编译包，遇到问题搜索也最容易找到答案。Debian、CentOS系也能装，但配套工具链总是慢半拍。国内的一些服务器系统如果基于Ubuntu或CentOS的包管理方式，同样可以按对应命令操作。

装好系统后的第一件事，不是直接装CUDA，而是先看一眼驱动状态。执行nvidia-smi，如果已经能显示出GPU型号和显存，说明驱动是好的，只需要确认版本；如果提示command not found，则先安装驱动。Ubuntu下最简单的方式是通过系统自带的驱动管理器：

# 推荐使用ubuntu-drivers工具自动选择合适驱动 sudo ubuntu-drivers autoinstall # 重启后验证 nvidia-smi

驱动版本和CUDA版本是配套关系。注意nvidia-smi显示的是当前驱动支持的最高CUDA版本，实际使用不一定要装到那么高，关键是你要用的推理框架需要什么版本。比如vLLM当前要求CUDA 12.x，那驱动至少选支持CUDA 12的版本。这一点容易搞混，我在后面vLLM安装环节还会再说。

2.3 容器与Python环境

环境隔离这件事，吃过亏的人才懂。我见过有人直接在系统环境里装PyTorch，装到一半把系统的Python环境弄坏了，连pip都用不了。大模型部署涉及Python、CUDA运行时、各种依赖库，版本之间相互影响很大，强烈建议用Docker或者Python虚拟环境隔离。

Docker方案对生产环境最友好。安装Docker后，还需要装nvidia-container-toolkit，这样容器里才能使用GPU：

# 以Ubuntu为例，安装nvidia-container-toolkit 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 systemctl restart docker

装完后用docker run加--gpus all参数，容器内就能直接调用GPU了。这条命令在之后的Ollama部署中还会用到，因为官方镜像本身就推荐用容器方式运行。

3. 推理框架选型：Ollama还是vLLM

框架选型是整个部署过程中最容易纠结的环节。我的建议是别纠结，先想清楚你的场景是“给自己用”还是“给别人用”，这两个答案对应的框架完全不同。

3.1 Ollama：上手最快的本地推理工具

Ollama本质上是一个大模型运行和管理工具，它帮用户解决了两件麻烦事：一是模型下载和格式转换，二是推理服务的启动。它把常见的开源模型做成了可以直接拉取的归档，一条ollama pull命令就能下载好按要求量化过的模型，一条ollama run就能启动交互式对话。很多人说的“ollma部署大模型”，指的就是这个工具。

Ollama还内置了一个兼容OpenAI格式的HTTP API服务，默认监听11434端口。这就意味着你不需要额外写适配代码，任何会调OpenAI接口的程序都能通过改一下base_url来对接本地模型，非常方便。

它的缺点是并发吞吐能力一般。长上下文、多用户并发场景下，Ollama的性能会明显下滑，而且可调的参数比较少，不太适合做精细的性能调优。这一点从架构上也能理解，它把易用性放在第一位，是个通用工具而非大规模推理引擎。

3.2 vLLM：面向生产的高并发推理引擎

同样是启动一个OpenAI兼容API服务，vLLM的性能表现要好得多。它做对了几件事：使用PagedAttention管理KV Cache，显存利用率大幅提升；内置连续批处理机制，多个并发请求会动态拼接到同一个批次里推理，而不会一个请求卡住其他请求；支持张量并行，多张GPU卡可以协同推理同一个模型。

代价是上手成本高一些，模型格式、启动参数都需要自己关注，对环境的依赖也更多。大多数情况下需要装PyTorch和一堆依赖包，不像Ollama那样一个二进制文件搞定。

不过一旦部署好，vLLM的服务质量和稳定性对得起这个折腾过程。我做过一次简单压测，同样一台机器跑同样一个7B模型，vLLM的每秒请求处理数差不多是Ollama的三到四倍，而且越到高并发差距越明显。

3.3 两套方案的适用场景对比

我整理了一个对比表，方便你按自己的场景选择：

如果你拿不准，我建议先装Ollama把链路跑通，哪怕后面生产环境要用vLLM，先能成功调用一次模型再说，心态上就不慌了。

4. 实操：在Linux服务器上把大模型真正跑起来

理论讲再多，不如亲手把服务拉起来。下面两套方案我都按完整流程写出来，照着敲命令就能跑通。

4.1 使用Ollama部署大模型

Ollama的安装可以算是我见过最友好的之一。一条命令搞定：

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

脚本会自动完成二进制安装和systemd服务注册。装完后默认服务就启动了，可以用ollama list查看现有模型列表。因为Ollama默认把模型存放在/usr/share/ollama/.ollama/models，如果系统盘空间不大，建议先改到数据盘再下载模型。方法是通过环境变量指定：

# 修改服务配置，追加Environment行 sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf << 'EOF' [Service] Environment="OLLAMA_MODELS=/data/ollama/models" EOF sudo systemctl daemon-reload sudo systemctl restart ollama

第一次下载模型前做个检查很关键，看看磁盘剩余空间够不够。以Qwen2.5 7B的4bit量化版为例，文件大小大约4.7GB，14B的量化版约9GB。用以下命令拉取模型：

# 拉取Qwen2.5 7B，ollama会自动选择合适的量化版本 ollama pull qwen2.5:7b

下载速度看网络情况，如果比较慢，可以考虑把模型下载请求发到模型托管平台ModelScope，然后在Ollama中导入已有的GGUF格式文件。这条路径适合服务器网络到国外资源延迟较高的场景。

模型拉下来之后，先直接在终端里试一轮对话，确认没有报错：

ollama run qwen2.5:7b

进入交互界面后随便聊两句，比如让它写一段Python代码，看看响应速度和回答质量。确认没问题，再用curl测试HTTP API是否正常：

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

看到返回JSON里包含content字段，这一步就圆满了。这时候你的Linux服务器已经变成了一台有OpenAI兼容接口的模型服务器，局域网内任何程序都能通过http://服务器IP:11434来调用。

4.2 使用vLLM部署大模型

vLLM的安装稍麻烦一些，但它给我的安全感更足，因为我能精确控制每一块显存怎么用。推荐用Docker部署，免去Python环境互踩的麻烦。这里以Qwen2.5 7B为例：

# 拉取官方vLLM镜像，版本号可以按需调整 docker pull vllm/vllm-openai:latest # 启动服务，加 --gpus all 才能让容器使用GPU docker run --gpus all \ --ipc=host \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --max-model-len 8192

注意这里的几个参数：--served-model-name是你对外提供的模型名，可以随便起，调用API时要用这个名字；--max-model-len控制最大上下文长度，直接影响KV Cache占用，如果显存紧张可以下调到4096；--port默认是8000，我用-p把宿主机8000映射到容器8000。

首次启动时，vLLM会从模型仓库下载模型文件。如果下载缓慢，一样建议先通过ModelScope把模型文件下载到本地，然后挂载目录进去：

# 假设模型文件已下载到/data/models/Qwen2.5-7B-Instruct docker run --gpus all \ --ipc=host \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --max-model-len 8192

启动后观察日志，看到约等于“Starting vLLM server on http://0.0.0.0:8000”的提示说明服务已经起来了。同样用curl验证一下接口：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen2.5-7b", "messages": [{"role": "user", "content": "用Python写一个快速排序"}]}'

vLLM还提供了一个很有用的指标接口，访问http://localhost:8000/metrics可以获取Prometheus格式的性能指标，包括吞吐量、请求延迟、显存使用等。生产环境中接入监控系统时非常有用。

4.3 让模型服务常驻后台与开机自启

用docker ps看容器状态是很快，但Docker容器重启策略只能保证容器崩溃时自动起来，没法保证宿主机重启后容器跟着起来。一个更稳妥的做法是给容器加--restart=always参数：

docker run --gpus all \ --restart=always \ --ipc=host \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b

Ollama则更简单，安装脚本默认就注册了systemd服务，无非在遇到OOM问题时需要检查服务状态。查看服务最近日志的命令是journalctl -u ollama --no-pager -n 100，如果看到OutOfMemory相关的字样，说明需要调整Ollama的最大上下文长度参数OLLAMA_NUM_PARALLEL等。Ollama官方支持通过OLLAMA_NUM_PARALLEL控制并行请求数，这个值设大了可能显存不够，设小了浪费性能，建议从1开始慢慢加。

5. 常见问题与排查技巧实录

部署过程不会一帆风顺，这里把我在实际项目中碰到的典型问题和解决思路整理出来，希望能帮你少走弯路。

5.1 显存不足导致OOM

显存不够是最常见的问题，尤其在用FP16精度跑模型的时候。一次我在一台24GB显存的机器上部署一个13B模型，模型加载成功了，但一发起推理请求就报CUDA out of memory。

这种问题排查思路很固定。先用nvidia-smi看一下当前显存占用，看看是模型本身就占不满，还是加载模型后剩余显存不够分配KV Cache。如果剩余显存不多，优先调整--max-model-len参数，把上下文长度从8192降到4096，KV Cache的占用会显著下降。还不行的话，就只能换更低精度的量化版模型，比如从FP16换成INT4，显存需求可能从28GB降到7GB左右。

还有一个容易忽略的点是，同一个GPU上可能同时跑了好几个推理服务。用nvidia-smi能看到每个进程的显存占用，把不用的进程清掉，释放显存，有时候比调整模型参数更立竿见影。

5.2 模型下载缓慢或失败

大模型文件动辄几个GB，网络环境不好时下载半小时以上是常事。Ollama的模型源默认在海外，如果下载速度不理想，可以考虑从ModelScope客户端下载模型文件后在Ollama中导入。ModelScope上有专门的Ollama支持，下载完的GGUF文件可以用ollama create命令打包成本地模型：

ollama create my-qwen -f /data/gguf/Modelfile

Modelfile里只需要写一行FROM /data/gguf/qwen2.5-7b-q4_k_m.gguf，然后Ollama就会把它注册成本地模型。

对vLLM来说，我强烈建议提前用huggingface-cli或者ModelScope的Python SDK把模型仓库完整下载到本地，部署时挂载进去。这样做不仅能规避网络不稳定问题，还能避免每次重新部署都要重复下载大文件的痛苦。

5.3 推理速度慢与并发能力不足

推理速度慢，先分清楚是“单请求慢”还是“并发时整体吞吐低”。

单个请求就慢，大概率是模型太大或者显存带宽不够。有条件的减小模型规模或者使用更激进的量化，比如跑7B模型用FP16在24GB显存上可能只有20 tokens每秒左右，换成4bit量化能到40到50。如果并发时整体吞吐低，则需要关注推理引擎的批处理能力。Ollama的默认并行度很低，可以通过环境变量OLLAMA_NUM_PARALLEL调高并行请求数，但注意观察显存占用；vLLM则默认开启连续批处理，并发表现一般不用调太多参数。

最后一个性能杀手是上下文长度。很多人习惯把max-model-len设得很高，比如32768，但用户实际使用过程中根本不会一次传这么多token。长上下文意味着KV Cache占满显存，不仅可用的批处理空间变小，甚至可能导致需要额外重复计算。先评估业务需求，再设置合适的max-model-len，一般8192已经能满足绝大多数场景。

6. 写在最后：一些部署体会和实用建议

做Linux服务器部署大模型这件事，回头看最耗时间的其实不是安装本身，而是环境适配和问题排查。版本对不对、驱动匹配不匹配、显存够不够，每一步都有可能卡住。

我个人比较推荐的路径是：第一阶段先用Ollama把链路整体跑通，熟悉模型下载、API调用、基本参数调整，别一上来就折腾vLLM；第二阶段再部署vLLM，重点观察它在并发场景下的性能优势，结合vLLM的metrics指标做参数调优；第三阶段才开始考虑多卡并行、微调等进阶操作。这个过程中，写文档记录每一条命令和环境版本非常值得，哪怕只是记在备忘录里，也能在下次重装时省下大量时间。

最后分享一个小技巧：部署完成后，第一时间把服务配置写成纯Docker Compose文件提交到Git仓库，包括启动命令、环境变量、端口映射。之后无论换机器还是重建环境，只要拉代码、跑docker compose up就能恢复服务。这个习惯我在好几个项目里都验证过，是真的省心。