芙蓉塘外有轻雷最近几个月，来问我“怎么把大模型放到自己服务器上跑”的人明显变多了。有做内部知识库的，有想给团队弄个AI问答机器人的，还有单纯受不了各家API按量收费、想搞个私有化部署的。虽然大家需求五花八门，但最后都会落到同一个问题上：大模型 + Linux服务器 + 部署，这三件事怎么串起来。
这篇文章就是我从零开始折腾本地大模型部署的完整记录。我会从硬件准备、环境安装、模型选型、推理框架对比，到具体的部署命令和踩坑实录，全部盘一遍。不管你是刚接触大模型的小白，还是已经跑通过的老手，都可以对照着查缺补漏。
1. 为什么选Linux服务器来部署大模型
1.1 本地部署到底解决了什么问题
先聊聊动机。现在市面上的大模型API服务已经很成熟了，直接调接口确实省事，但很多场景下你没法完全依赖第三方服务。企业内部数据不能往外传、需要离线使用、调用频率高到按量计费扛不住、或者想深度定制模型行为，这些需求都会把你推向“自己部署”这条路。
本地部署大模型的核心价值就三点：数据不出内网、成本可控（尤其高调用量场景）、以及完全自主的定制能力。缺点也很直白——硬件投入不小，技术门槛比调API高一大截，后续还要持续维护。所以动手之前，先想清楚自己的需求是不是真的需要本地部署，不然很容易变成花钱买罪受。
1.2 Linux在模型部署中的绝对统治地位
为什么几乎所有大模型部署教程都默认用Linux？最直接的原因：大模型训练和推理框架的底层依赖，从CUDA、cuDNN到各个深度学习框架，都是优先支持Linux的。Windows上虽然也能跑，但很多坑是Windows特有的，比如驱动冲突、路径问题、WSL转发的性能损耗。真实的生产环境里，服务器几乎清一色是Linux，尤其以Ubuntu和CentOS系列为主。
另一个关键点是显卡驱动。NVIDIA的驱动和CUDA工具链在Linux下的兼容性比Windows好得多，尤其是多卡场景。后面我会详细讲驱动和CUDA怎么装，这里先记住一个结论：如果打算正经部署大模型，一台带GPU的Linux服务器是标准答案，省心程度远超Windows。
1.3 你需要什么样的服务器：先算清楚账
在动手之前，先搞清楚自己的硬件家底。大模型部署最核心的资源是显存，模型权重有多大，推理时基本就要占多大显存，再加上KV Cache和中间激活值，实际占用通常是模型权重的1.2到1.5倍。比如一个7B参数、4比特量化的模型，权重大约4GB，但运行起来要预留6到8GB显存才稳。
内存方面建议至少32GB起步，因为加载模型、做文本预处理都需要内存缓冲。硬盘要预留模型存储空间，一个7B模型大约15GB（FP16），70B模型要140GB左右。如果你的服务器没有NVIDIA显卡，或者显存低于6GB，那基本只能跑跑1.5B以下的小模型，体验会比较受限。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前的核心技术准备
2.1 NVIDIA驱动与CUDA的安装要点
拿到服务器后第一件事就是装显卡驱动。这一步看起来简单，实则翻车率极高。我先说结论：能用apt或者dnf直接装的驱动版本，一定要和后面要装的CUDA版本、以及推理框架要求的CUDA版本对齐，否则就会出现“装上了但跑不起来”的尴尬局面。
更稳妥的做法是用NVIDIA官方提供的runfile安装驱动，然后用nvidia-smi命令验证。装好驱动后检查输出，右上角会显示CUDA Version，那个数字是当前驱动支持的最高CUDA版本。比如显示CUDA Version: 12.4，就说明这个驱动可以支撑CUDA 12.4及以下的所有版本。然后去CUDA Toolkit页面选择对应版本安装，这里推荐装runfile方式，千万别装deb方式，因为deb经常会顺手把你系统里的驱动替换掉，搞出连环坑。
2.2 Docker：大模型部署的救星
在我自己踩过几轮环境依赖的坑之后，强烈建议你使用Docker来部署大模型。Docker可以把CUDA、推理框架、模型运行环境整个打包隔离，换机器、重装系统后只需要重新拉镜像就能恢复服务，省掉大量环境配置时间。
安装Docker之后，还需要装NVIDIA Container Toolkit，这样才能让容器里访问到宿主的GPU。装完之后在Docker里执行nvidia-smi确认识别成功。个人经验：一旦走上Docker路线，后面切换不同框架、不同模型版本会从容很多。比如原来在一台机器上同时跑Ollama和vLLM服务，如果直接装在系统里，依赖冲突是迟早的事；用容器隔离，各跑各的，互不干扰。
2.3 存储规划与文件系统选择
大模型文件动辄几十GB，下载和读取对存储都有要求。普通机械硬盘不是不能跑，但加载模型的速度会明显拖慢首次启动时间。建议用SSD或NVMe，尤其是跑大模型推理时，模型权重要加载到内存/显存里，磁盘读取速度直接影响启动耗时。
文件系统方面，ext4和xfs都是稳妥选择。有一个容易忽略的点：最好给模型单独挂一个分区或者目录，方便后期做快照、迁移。我习惯把模型统一放在/opt/models目录下，并且只给模型数据单独划一块空间，这样备份和管理时很清晰。另外，如果服务器上要跑多个不同模型，强烈建议按模型名建子目录，比如/opt/models/deepseek-r1-7b、/opt/models/llama3-8b，一眼就能看出哪个模型在哪个位置。
3. 模型选型与获取：从权重文件到推理服务要走几步
3.1 开源模型怎么挑：参数规模与量化等级
现在开源大模型社区非常热闹，主流的几大系列包括Llama系、Qwen系（通义千问）、DeepSeek系、Mistral系等等。选模型时第一步要看参数规模：1.5B和3B级别的适合CPU都能跑的场景，7B到8B是目前消费级显卡的甜点区，13B到14B开始需要24GB以上显存，70B级别基本是专业显卡的天下了。
参数规模之外还要看量化方式。这里的量化可以理解为把模型权重从高精度压缩到低精度，用少量精度损失换取体积和显存的大幅缩减。常见的有4比特和8比特量化，很多热门模型都有官方量化版，比如带Q4_K_M这类后缀的就是一份成熟可用的4比特量化权重。如果显存吃紧但不严重，可以优先选择量化版本。
3.2 模型下载的正确打开方式：Hugging Face与ModelScope
下载模型权重，最大的模型仓库是Hugging Face，上面几乎能找到所有开源模型。但国内直连上下载速度不稳定，所以更多人会选择ModelScope（魔搭社区），它把很多热门模型都同步了一份，下载速度快不少。还有一类常用做法是配置镜像站加速，这个可以根据自己网络情况灵活选择。
下载模型时不要整个仓库盲目clone，因为有些仓库体积动辄几百GB，绝大多数是你用不到的训练数据。用huggingface-cli或者git lfs指定单独文件下载就行。实际上对部署来说，最关键的是权重文件和配置文件，通常位于snapshots目录下。下载完成后放到模型目录，下一步就是交给推理框架去加载了。
3.3 模型、框架、硬件的匹配关系
很多人会在第一步就栽跟头：模型下载好了，加载时报各种错。根本原因就是模型、推理框架、硬件三者不匹配。以GGUF格式为例，这是llama.cpp和Ollama支持的模型格式，通常已经做了量化。如果你下载的是safetensors格式的原始权重，那要用transformers库或vLLM来加载，Ollama则不直接支持。
所以下载模型之前，先确定你打算用什么推理框架，再按框架支持的格式去选文件。我的经验是：图省事选Ollama，它自带模型仓库，一条命令就能拉取和运行；要追求高并发和细粒度控制就选vLLM，但模型格式要用safetensors；要做实验、调参、微调就用transformers。这个选择顺序能帮你少走很多弯路。
4. 推理框架选型：Ollama、vLLM及其他
4.1 Ollama：五分钟上手的首选
Ollama是现阶段最流行的本地大模型运行工具，它把模型下载、格式转换、推理服务全部封装好了。我的评价是：它对新手极度友好，对老手也够用，适合绝大多数场景。安装只需要一条命令：curl -fsSL https://ollama.com/install.sh | sh，然后在shell里执行ollama run llama3就能直接进入交互对话。
Ollama本质上是对llama.cpp等后端的封装，支持GGUF格式模型，内部做了大量算子优化，单卡场景下性能是很好的。启动后会默认监听11434端口，提供OpenAI兼容的API接口，这意味着你后面接Dify、ChatBox这类应用层会非常方便。如果你只是想先跑通一个可用的AI服务，选Ollama是最不折腾的路径。
不过Ollama也有它自己的天花板。它最大并发能力一般，多请求排队时延迟会升高，且对多卡并行支持不够灵活。如果目标是面向几十人甚至上百人提供在线服务，直接用Ollama硬扛很快会撞上性能瓶颈，这时候就该上vLLM了。
4.2 vLLM：面向高并发生产环境的引擎
vLLM是针对大模型推理场景专门优化的高性能引擎，好的一点是它通过PagedAttention等技术极大提升了显存利用率和吞吐量。在多用户同时请求的场景下，性能表现非常亮眼。它支持Hugging Face格式（safetensors）的模型权重，可以直接从ModelScope或HF下载后用vLLM加载。
vLLM的安装方式也推荐用Docker，官方镜像已经打包好了运行环境。启动服务时用一条命令指定模型路径、端口、显存占用、并发数等关键参数。相比Ollama，vLLM的调优参数更多，相应的学习曲线也陡一些。我建议先把Ollama跑通，再考虑切换到vLLM，这样至少能确保自己对模型和请求流程有一个基本认识。
4.3 轻量方案与其他工具
除了Ollama和vLLM，还有几个工具值得了解。llama.cpp是底层运行时，纯C++实现，CPU和GPU都能跑，Ollama的底层就有它的影子。LM Studio则是一个带图形界面的桌面版工具，适合在Windows或Mac上做快速实验，如果你在Linux服务器上操作，这个用处不大。还有就是Dify这类应用编排平台，通常作为大模型的上层应用框架来使用，把模型服务和知识库、工作流串起来。
工具选型没有绝对的答案，核心看场景：个人使用或小团队内网用，优先Ollama；生产环境、并发请求高，选定vLLM；如果模型要改造微调，那就要以transformers为主。还有一个观点：动手部署之前不要纠结哪个更好，先跑通一个再迁移，比纸上谈兵高效得多。
5. 完整部署实操：从零跑通一个7B模型服务
5.1 环境检查与硬件确认
部署之前先把底数摸清。登录服务器后，执行uname -a查看内核版本，执行cat /etc/os-release确认操作系统。然后重点检查GPU：执行命令nvidia-smi，观察输出的显卡型号、显存大小和驱动版本。如果命令不存在或者报错，说明NVIDIA驱动没装好，先回头处理驱动，再继续后面的步骤。
确认GPU就绪后，还要检查Docker是否安装。直接执行docker run --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi，如果Docker容器里也能输出显卡信息，说明NVIDIA Container Toolkit也配置好了。这一步是我在很多次悲剧之后的经验总结：不要在系统里一路装到模型加载那一步，才发现Docker GPU权限没有配好，浪费半天时间。
5.2 启动Ollama服务并拉取模型
环境就绪后，启动Ollama。如果你用Docker方式，命令如下：
bash复制docker run -d --gpus=all -v /opt/models:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
这里把宿主的/opt/models挂载到容器内的模型存储目录，好处是模型数据持久化在宿主机上，容器删了重建也不丢模型。启动后进入容器执行：
bash复制docker exec -it ollama ollama run llama3
第一次运行会自动下载模型权重，下载完成后进入对话界面，直接输入文字就能对话。退出对话后，Ollama服务保持后台运行，接下来可以做API接入。可以用curl命令做一次快速验证：
bash复制curl http://localhost:11434/api/generate -d '{"model": "llama3", "prompt": "你好"}'
如果返回了一段JSON格式的生成内容，整个链路就算跑通了。
5.3 接入OpenAI兼容的API与应用层
Ollama启动后默认就提供OpenAI兼容的接口，因此很多现成的应用可以直接对接。比如在Dify中配置模型供应商时，选择OpenAI-API-compatible类型，填上服务器IP加上11434端口和模型名，就能把Dify的聊天应用和本地大模型连起来。
如果你想把服务暴露给局域网里其他人使用，需要注意Ollama默认只监听127.0.0.1，需要设置环境变量OLLAMA_HOST=0.0.0.0并重启容器。同时服务器防火墙要放行11434端口，这个很多人会忘记，导致别人访问不到。如果你用的是云服务器，还要在安全组里配置入方向规则。这块我在后面问题部分会具体展开。
5.4 换用vLLM跑同一套模型的对比体验
当QPS或并发要求上来后，把模型迁移到vLLM是顺理成章的事。vLLM使用Hugging Face格式的权重，所以先到ModelScope或Hugging Face下载safetensors格式的模型。我以Qwen2.5-7B-Instruct为例，下载下来的目录结构大概包含config.json、tokenizer.json和多个safetensors分片文件。
然后启动vLLM服务的命令如下：
bash复制docker run --gpus all -p 8000:8000 \
-v /opt/models/qwen2.5-7b-instruct:/models/qwen2.5-7b-instruct \
vllm/vllm-openai:latest \
--model /models/qwen2.5-7b-instruct \
--served-model-name qwen2.5-7b \
--tensor-parallel-size 1 \
--gpu-memory-utilization 0.9
启动后，vLLM会在8000端口提供OpenAI兼容接口，意味着之前给Ollama用的应用层代码几乎不用改，只要把API地址和模型名替换掉就行。对比下来，vLLM在多请求并发时的吞吐和稳定性确实更好，但前提是显存够用、参数调对。
6. 常见问题与排查技巧实录
6.1 显存不足：进程被杀或加载直接报错
跑大模型最常见的故障就是显存OUT OF MEMORY。症状有两种：一种是加载模型时直接OOM报错，另一种是服务跑了一段时间后被系统杀掉。第一种通常是模型太大，超过了显卡显存上限，解决办法是换更小参数模型，或者用量化版本。第二种往往是推理过程中KV Cache越积越多，把显存占满了，需要限制最大并发连接数，或者在应用层做请求排队。
排查显存占用最常用的命令是watch -n 1 nvidia-smi，实时盯着显存和GPU利用率。还有一个容易被忽略的坑：多卡服务器上NVIDIA驱动默认会做显存共享，如果其他进程占用了显存，你启动新模型时可能因为共享显存不足而失败。排查时用nvidia-smi查看所有进程，把无用进程kill掉再重试。
6.2 服务卡顿和响应慢的隐藏原因
有人经常遇到这种问题：找个模型本地跑，对话时一个字一个字往外蹦，慢得想砸键盘。排除掉硬件不足的原因，大概率是模型启动了CPU推理或者GPU利用率极低。如果模型参数和显存不匹配，框架可能退回到CPU模式运行，这个时候再大的模型都是灾难。解决办法就是确认GPU推理是否正确，在Ollama中执行ollama ps查看模型运行的processor类型，在vLLM日志里看GPU显存占用情况。
还有一个常见的卡顿原因是磁盘IO瓶颈，尤其是用机械硬盘加载大模型时。首次请求需要把权重从磁盘读入显存，如果是几十GB的模型，等待时间会很长。解决思路是换SSD，或者确保模型已经在操作系统的page cache里。更进阶的做法是在加载完成后先发一个预热请求，让权重真正驻留显存，之后响应就会快很多。
6.3 端口、防火墙和远程访问的连环坑
本地怎么测都正常，一换到局域网别的机器上访问就超时，这基本是防火墙、监听地址或云安全组的问题。Linux下先检查服务监听地址是否包含0.0.0.0，如果是127.0.0.1，外部请求肯定进不来。再检查防火墙状态，执行firewall-cmd --list-all或ufw status，确保对应端口已放行。
如果你用的是云服务器，还有一道安全组要检查。控制台的入方向规则必须允许对应端口的访问，这部分很多人容易遗漏。我的习惯是部署完服务后，第一时间用另一台机器执行telnet测端口连通性，快速判断问题在网络层还是应用层。省得抓瞎半天。
6.4 容器退出、模型丢失和权限问题
Docker容器的数据持久化是个经典坑。如果启动Ollama时忘了挂载模型目录，容器一旦被删除重建，之前下载的模型全部消失，需要重新拉取。这个我遇到过不止一次，所以把-v /opt/models:/root/.ollama写进了自己的默认启动命令里。模型下载和存储尽量放在宿主机独立目录，前后端服务可以随时重建。
另外要注意文件权限，容器里运行的用户和宿主机的用户UID可能不同，如果模型挂载目录的权限不对，会报Permission denied。简单做法是把目录权限设为755并确保文件所有者为当前用户。如果在模型目录下执行chmod -R 755操作，大部分权限问题能解决。
7. 部署之后的维护与扩展思考
7.1 服务监控与自动重启
模型服务不像普通Web服务，显存、GPU温度都需要额外留意。推荐用nvidia-smi的定时采样来记录GPU状态，或者用上Prometheus + Grafana这种监控方案。对个人或小团队来讲，最简单的做法是写一个shell脚本，定时检测服务进程是否存在，挂了自动拉起。保证基础可用性永远比复杂的监控系统更重要。
日志方面，Ollama和vLLM默认都会把日志输出到标准输出，Docker方式下用docker logs命令就能查看。建议配置日志轮转，防止日志文件无限膨胀把磁盘写满。部署到生产环境后，第一时间做一次重启测试，确认服务能自动恢复。这个步骤我每次部署都会做，非常管用。
7.2 多模型的共存与切换
服务器上的显存资源是固定的，但模型可以根据场景切换使用。比如日常问答用一个7B模型，写代码用一个代码增强模型，知识库再挂一个嵌入模型。Ollama支持同时管理多个模型，不需要的时候执行ollama stop把模型从显存卸载。vLLM也支持在同一个服务内加载多个模型，只要显存放得下。
我个人的习惯是：保持一个默认模型常驻，其他模型按需启动。比如默认跑Qwen2.5-7B作为主力问答，需要别的能力时再临时启动对应模型。如果有多台服务器，还可以按模型类型分工，一台跑对话模型，一台跑向量模型，把显存资源最大化利用。
7.3 下一步：微调与私有知识库
部署稳定之后，很多人会想进一步增强模型能力。最自然的两个方向是模型微调和接入私有知识库。模型微调就是用你的行业数据对模型做进一步训练，让它更懂你的业务语言。这比部署推理模型要复杂不少，需要准备训练数据、配置训练框架、并占用更多显存和训练时间。但如果做得好，效果提升会非常明显。
私有知识库则更多是工程层面的整合，典型方案是结合Dify或RAGFlow这类框架，用本地向量数据库存储文档切片，查询时先检索再让大模型生成答案。这种方案把大模型当成理解和生成的引擎，具体知识从外部库获得，既控制成本又保证数据不出内网。我自己在跑通基础部署后，就是沿着这个方向把内部文档问答服务搭起来的。
我个人跑了这么多天最大的体会是：部署大模型这件事，真正的难点不在某个单一环节，而在于从硬件、系统、框架到模型、应用，每一步都需要有足够的耐心去验证和排查。先跑通一个最小的可用服务，再逐步加并发、加模型、加应用，这个节奏是最稳的。另外就是养成在宿主机目录持久化模型、用Docker隔离环境、写好启动脚本记录这类小习惯，后面能省下成倍的时间。希望这篇记录能帮你把第一台大模型服务器顺利跑起来。