企业官网建设流程全解析

在Linux服务器上部署大模型，正在变成越来越多后端工程师和运维团队的基础技能。最近我帮几个朋友在自己的Linux服务器上跑通了DeepSeek和Ollama，整个过程有点波折，但真跑通以后，后续加模型、加接口、接应用都非常顺。这篇东西的定位就是一份可复现的部署笔记，从硬件选型、方案对比，到具体安装命令、服务化、故障排查，再到Dify、微调这类延伸玩法，尽量把关键点一次讲透，让你少走我走过的弯路。

1. 动手部署前先解决三个核心问题：模型、硬件与系统

很多人拿到一台服务器，第一反应就是敲命令装Ollama，然后发现模型拉下来跑不动，或者跑起来巨慢，最后全卡在环境上。我现在的习惯是，在真正动手之前先把模型规模、硬件条件、操作系统三件事对清楚，这一步花不了半小时，但能省下后面两三天。

1.1 模型参数量与显存内存的估算法则

要估算一个模型需要多大显存，其实有个很粗暴的公式：权重占用 = 参数量 × 每个权重字节数，然后再加上推理过程中必须留出的KV Cache和激活值空间。以7B模型为例，如果用FP16精度，每个参数占2字节，那就是14GB权重；如果换成4-bit量化，每个参数约0.5到0.6字节，权重就被压到4GB出头。

不同规模模型在常见精度下的显存需求，我整理了一个参考表：

这个表只是权重占用的粗算，实际操作里还要看上下文长度。上下文开得越长，KV Cache占用越大，比如一个7B模型的32K上下文，KV Cache可能额外吃掉几GB显存。所以我给朋友的建议通常是：第一批模型先用量化版本跑，流程通了再谈升级精度。

内存这边也容易被忽略。如果显存不够，系统会用内存顶，推理速度会断崖式下降。考虑到进程加载、数据交换和系统本身的占用，内存至少应该是模型权重的两倍。硬盘则直接决定模型加载速度，同样的一个7B模型，机械硬盘和NVMe固态的启动时间能差出几分钟，预算允许的情况下优先NVMe。

1.2 服务器硬件与Linux发行版怎么选

硬件选型上，NVIDIA显卡依然是部署大模型的最省心选择，因为CUDA生态太完整了，Pytorch、各种推理框架、容器工具链都是优先支持NVIDIA。消费级显卡里，RTX 4090 24GB是目前单机自用的甜点卡，能跑7B、14B，甚至量化后的32B；预算更低就选RTX 3060 12GB，跑7B量化模型完全够用。企业级场景则看A100、H100这类，显存大、带宽高，但价格也高不少。

Linux发行版我推荐Ubuntu Server 22.04 LTS，原因是它的内核版本和驱动兼容性都很稳，遇到问题时网上的资料也最多。Debian 12、Rocky Linux 9也可以，但没有特殊理由的话，没必要在发行版选择上给自己增加难度。拿到系统后第一件事就是确认GPU驱动是否正常，终端里执行nvidia-smi，能看到类似下面的输出就说明驱动和显卡都被识别了：

+---------------------------------------------------------------------------------------+ | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 | +---------------------------------------------------------------------------------------+

如果提示command not found，说明驱动还没有装好，需要先解决驱动问题再继续。这里有一个常见的误区：很多人以为必须要手动装CUDA Toolkit才能部署大模型，其实Ollama这类工具会自带运行依赖，只要驱动版本别太老，一般都能正常工作。

1.3 你需要在服务器上准备的驱动与基础环境

驱动是基础，但还有几个环境变量和基础工具值得提前准备。一个是检查curl、wget是否装上，很多精简版Linux发行版默认不带这些工具。另一个是确保系统的glibc版本够新，如果你的服务器是特别老旧的发行版，后面装Ollama可能会报GLIBC版本过低的错误，升级到较新的Ubuntu或Debian版本通常能直接避开。

Docker不是必须的，但如果你打算用Docker部署，就得提前装好NVIDIA Container Toolkit，否则容器里识别不到GPU。我一般会在系统装好后执行一遍完整检查：nvidia-smi、docker --version、curl --version、free -h、df -h，把硬件、工具、磁盘、内存全部过一遍，确认没有明显短板再继续。

2. 四类主流部署方案对比，别一上来就闷头装

“Linux服务器部署大模型”这个事，很容易一搜教程就直接开干。但部署方案的选型其实比安装命令本身重要得多，方案选错了，后面可能整个推倒重来。目前互联网上讨论最多的是Ollama、vLLM、llama.cpp和Text Generation Inference，各有各的主场。

2.1 Ollama、vLLM、llama.cpp、TGI的适用场景

Ollama是我个人最常用的入门方案，一条命令就能装好，拉模型、换模型版本、起服务都很简单，而且它默认暴露的接口和OpenAI的Chat Completions格式兼容，后面接Dify、FastGPT这类应用非常方便。它的内部调度在低并发场景下足够用，但扛不住每秒几十个请求的压力。

vLLM是冲着性能和吞吐去的，核心是PagedAttention技术，显存利用率比朴素推理高很多。如果你的目标是做一个对外服务的API，前期就能预期有比较大的并发量，建议直接用vLLM。但它对模型格式有要求，也不是所有模型都能一把梭。

llama.cpp是纯C++实现的推理引擎，最突出的能力是GGUF量化模型，没有NVIDIA显卡、只有纯CPU的服务器也能跑。很多嵌入式设备和低成本服务器会选它。TGI则是HuggingFace官方出的推理服务，和HuggingFace生态结合最紧密，功能全但部署和调优的学习成本高一些。

2.2 选择Ollama作为入门路线的三个理由

我之所以推荐先试Ollama，核心原因有三个。第一，它把模型下载、文件管理、进程守护、API服务全都封装好了，对刚接触大模型部署的人来说，这是最节省时间的路径。第二，它使用起来接近于“Docker之于容器”的体验，ollama pull、ollama run、ollama list几个命令就能完成日常操作。第三，它跨平台且支持GPU加速，一台老的CPU服务器也能跑，只是慢一点，不会完全不可用。

2.3 什么时候应该换掉Ollama

Ollama毕竟是面向个人和小团队的轻量工具，当你遇到下面这些情况，就该考虑换vLLM或TGI：一是并发请求持续超过两位数，二是需要对显存做更细粒度的控制，三是需要多模型多副本的自动扩缩容。识别这个信号主要看延迟和失败率，如果模型明明没OOM，但请求经常排队或超时，那就说明Ollama的调度已经到瓶颈了。

3. 实操：在Linux服务器上用Ollama部署DeepSeek

接下来是全文最核心的部分，我以Ollama和DeepSeek-R1系列为例，演示从零开始在Linux服务器上跑通一个本地大模型。这个流程我在Ubuntu Server 22.04和Debian 12上都验证过，可以照着敲。

3.1 安装Ollama的两种方式

第一种方式是用官方脚本安装，也是最推荐的方式：

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

脚本会自动检测操作系统、下载二进制、配置systemd服务。安装完成后执行ollama --version确认版本号，正常会打印类似ollama version 0.x.x的内容。

第二种方式是手动安装，适合服务器无法直接用脚本，或者你想固定某个特定版本的情况。去官方GitHub Release页面下载对应架构的二进制包，解压后把ollama可执行文件放到/usr/local/bin/，再把模型目录和用户权限设置好。这种方式能让你精确控制版本，但需要手动处理systemd和权限，新手还是建议直接用脚本。

3.2 环境变量与GPU可见性确认

安装完成后先别急着拉模型，先确认Ollama能不能看到GPU。执行下面这个命令，如果返回的是GPU available相关的信息，说明加速已经生效，如果返回的是CPU推理，也不用慌，继续往下走，只是速度慢一些。

ollama serve

Ollama默认只监听本机的127.0.0.1，也就是说只能在这台服务器上访问。如果你想从其他机器调用这个API，需要设置环境变量OLLAMA_HOST=0.0.0.0:11434。这个变量可以在启动Ollama前用export设置，也可以写到systemd服务配置文件里。如果是用官方脚本安装的，Ollama已经注册成systemd服务，稍后我会讲怎么改配置。

3.3 拉取模型并完成首次对话

DeepSeek-R1系列发布以后热度很高，它有几个规格可以选。我拿deepseek-r1:7b举例，这是7B规模、默认4-bit量化的版本，显存需求比较友好。

ollama pull deepseek-r1:7b

这个命令会从模型仓库拉取所有文件，模型体积在4GB到6GB之间，具体取决于网络链路和镜像源。下载中断也没关系，再次执行ollama pull会断点续传。下载完成后直接运行：

ollama run deepseek-r1:7b

看到>>> Send a message (/? for help)这样的提示符就说明模型已经加载成功，可以直接输入问题。比如输入“你好，简单介绍一下你自己”，模型会正常回话。这一步如果通过，说明模型本身、硬件加速、系统环境全都没问题，接下来要做的是把它变成一个能对外提供服务的接口。

3.4 把模型封装成HTTP API

Ollama自带REST API，最常用的是生成接口和OpenAI兼容接口。先测试原生的生成接口：

curl http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "介绍一下Linux系统", "stream": false }'

如果返回内容里包含"response"字段，接口就通了。官方还兼容了OpenAI的格式，接口路径是/v1/chat/completions，这样绝大多数现成的OpenAI SDK可以无缝切换，只需要把base_url改成http://你的服务器IP:11434/v1。

Python调用示例也贴一下，方便做自动化脚本：

import requests url = "http://127.0.0.1:11434/v1/chat/completions" payload = { "model": "deepseek-r1:7b", "messages": [ {"role": "user", "content": "写一段Python快速排序代码"} ] } resp = requests.post(url, json=payload) print(resp.json()["choices"][0]["message"]["content"])

3.5 使用Docker运行Ollama的补充方案

如果你更习惯容器化，也可以用Docker运行Ollama。第一步确保宿主机已经装好NVIDIA Container Toolkit，然后用下面的命令启动：

docker run -d --gpus all \ -v /data/ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama

-v /data/ollama:/root/.ollama是把模型存储目录挂载到宿主机的/data/ollama，这个很关键，否则容器一旦删除，模型文件就全丢了。--gpus all让容器使用宿主机全部GPU。容器启动后，再执行docker exec -it <容器ID> ollama pull deepseek-r1:7b拉取模型。容器化方案的好处是环境隔离，换机器迁移时直接把数据目录拷走即可，缺点是排查问题时多一层容器网络要处理。

4. 从临时进程到正式服务：systemd、Nginx与模型数据管理

跑通模型只是第一步，真正能在生产环境或者团队内部使用，还需要把Ollama托管成系统服务、加上访问入口和权限控制，并且考虑模型文件的备份迁移。这一节讲的就是怎么把一个临时进程变成正经服务。

4.1 用systemd托管并支持远程访问

官方脚本安装Ollama时，已经自动创建了一个systemd服务文件，通常在/etc/systemd/system/ollama.service。查看当前监听地址：

systemctl status ollama

如果只监听了127.0.0.1，需要编辑服务文件，加入或修改Environment配置：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

然后执行：

sudo systemctl daemon-reload sudo systemctl restart ollama sudo systemctl enable ollama

enable是设置开机自启，restart是让新配置立即生效。这种场景下不推荐直接export OLLAMA_HOST，因为重启后就丢了，写在systemd里才是一劳永逸。

4.2 用Nginx转发并增加访问控制

监听0.0.0.0之后，局域网内其他机器的确能访问了，但同时也意味着任何能扫到这个端口的人都能调用你的API，白嫖算力还是小事，被恶意灌请求把服务器打挂就麻烦了。我的做法是在前面加一层Nginx，只暴露Nginx的端口，同时加一道最简单的HTTP Basic认证。

先安装Nginx并生成用户密码文件：

sudo apt install nginx apache2-utils sudo mkdir -p /etc/nginx/conf.d sudo htpasswd -c /etc/nginx/.ollama_htpasswd aiuser

然后在Nginx配置里加一个server块，将/路径转发到Ollama的11434端口，并开启认证。配置核心写法：

server { listen 8080; server_name _; auth_basic "ollama"; auth_basic_user_file /etc/nginx/.ollama_htpasswd; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这样外部访问就变成了http://服务器IP:8080，而且必须先通过用户名密码认证。如果团队有统一的认证系统，再往后可以接更复杂的SSO或Token机制，但基础版已经能挡住绝大多数扫描和误用。

4.3 模型目录位置与迁移备份

Ollama的模型文件默认存储在~/.ollama/models，也就是当前用户的Home目录。查看当前模型列表用：

ollama list

如果你用非root用户运行Ollama，要特别小心权限问题。我之前遇到过把模型目录放在/root/.ollama下，然后用另一个用户启动服务，结果完全读取不到模型的情况。解决办法是把模型目录设置为环境变量OLLAMA_MODELS指向一个共享目录，再统一交给负责运行Ollama的用户管理。

备份模型也很简单，直接压缩模型目录即可：

tar -czf ollama_models_backup.tar.gz ~/.ollama/models

恢复时解压到新机器的对应目录，再启动Ollama就能看到原来的模型。多个大模型并存时，磁盘空间增长很快，我建议先跑ollama list看看都有哪些模型占了多大空间，长期不用的直接ollama rm <模型名>清理掉，免得磁盘被撑爆。

5. 部署过程中最常见的坑与排查实录

这部分是整篇博客里我最想写给后来人的内容。我见过太多人在部署时遇到问题就盲目重装，其实绝大多数问题都有迹可循，关键是通过日志和命令先定位，再做针对性处理。

5.1 问题排查速查表

这张表只是速查，下面挑几个我实际踩过、修复过程也比较有代表性的展开说。

5.2 GPU没有被利用怎么处理

部署完以后发现推理慢得离谱，第一件事永远是打开一个新终端，执行nvidia-smi。如果输出里完全没有Python或ollama进程，说明推理根本没有用上GPU。最常见的原因是没有安装好NVIDIA Container Toolkit（Docker部署时），或者CUDA_VISIBLE_DEVICES被意外设置成了空值。

检查Ollama日志也很重要：

journalctl -u ollama -f

日志里如果出现no GPU found或者using CPU，就顺着这个线索去查驱动和容器工具链。还有一种情况是，模型本身是纯CPU版本或GGUF的CPU量化版本，如果是为了省事用CPU跑的，那也不算错误，只是性能天花板有限。

5.3 并发请求与性能调优经验

Ollama默认同一时间只在显存里保留一个模型，并且单模型默认并发有限。如果团队多人同时访问，可以通过环境变量提升并发能力：

Environment="OLLAMA_NUM_PARALLEL=4" Environment="OLLAMA_MAX_LOADED_MODELS=2"

OLLAMA_NUM_PARALLEL表示同一个模型允许同时处理的请求数，适当地提高可以让单张GPU利用率更充分。但并发不是越高越好，显存有限时并发过高的直接后果就是OOM。我的经验是，7B量化模型在24GB显存的卡上，开4并发比较稳，开8并发就随时可能爆显存。

如果真到了需要两位数并发的阶段，建议把Ollama换掉，直接用vLLM。vLLM的PagedAttention机制会把显存调度得更精细，吞吐量比特意调优的Ollama高不少。切换成本也没有想象中高，因为vLLM也提供OpenAI兼容接口，模型参数格式上稍微调整就能接上。

6. 模型跑起来只是开始：知识库、Dify与微调

当模型在Linux服务器上稳定运行，API也能被外部调用了，下一步一般就是想让它真正解决业务问题。大部分人不会只满足于在终端里聊天，而是会往知识库问答、智能体、业务系统集成这些方向走。这里我主要聊三条延伸路径：Dify应用层、模型微调、同机其他AI任务的资源规划。

6.1 通过Dify快速搭建应用层

Dify是目前很火的开源LLM应用开发平台，能可视化编排Prompt、管理知识库、接入多个模型，并且完全支持对接本地部署的Ollama。部署Dify本身也走Docker Compose，在服务器上安装好Docker和Compose后，拉取官方部署仓库，执行docker compose up -d就能起一套Web控制台。

在Dify的“设置-模型供应商”里找到Ollama，填上服务地址http://<你的服务器IP>:11434，模型名称填deepseek-r1:7b，类型选择“LLM”，保存后就能在应用编排界面里用了。比较实用的一个场景是：先在Dify里建一个知识库应用，把企业内部的文档传上去，Dify负责做文档分段、向量化，再借助本地大模型完成语义检索和回答生成。整个过程数据不出内网，既能控制成本，也照顾了数据隐私需求。

6.2 LoRA微调与数据准备

如果你手里的模型在专用领域的表现不够好，可以考虑微调。对于大多数中小团队和个人开发者，我不建议从零预训练，那是成本深渊，推荐用LoRA或QLoRA在已有模型基础上做参数高效微调。常用方案是LLaMA-Factory或Unsloth，前者功能全面，后者显存友好、速度更快。

数据是微调的重中之重。很多人误以为样本越多越好，实际上几百到上千条高质量、格式规范的问答对往往就能看到明显效果。数据准备好后，在服务器上通过LLaMA-Factory的脚本指定基础模型、数据文件和输出目录，就能开始训练。需要提醒的是，微调对显存的要求比单纯推理高不少，7B模型做LoRA微调建议至少配16GB以上显存，用QLoRA则可以把门槛降到12GB左右。

6.3 同机运行其他AI应用时的资源规划

很多人的Linux服务器不只是跑大模型，还会跑ComfyUI、语音识别、向量数据库等。我的经验是，如果这些任务都要共享同一块GPU，一定要做好显存预算，否则就会出现“跑图的时候模型加载失败，跑模型的时候图像生成直接OOM”的情况。

一个简单的策略是错峰运行：把需要大显存的任务按时间段隔离，例如大模型推理服务在白天给业务用，图像生成任务放到晚上批量执行。另一个策略是显存不够时限制推理并发，用OLLAMA_NUM_PARALLEL控制住大模型对显存占用的上限，给其他任务留出空间。最后一点是始终关注磁盘，微调中间产物和模型快照都非常吃空间，建议定期清理。

我在实际部署中的体会是，Linux服务器上跑大模型，真正花时间的地方往往不是模型本身，而是环境、资源和服务化这些“周边工作”。先把一个小模型完整跑通，再做性能优化和应用扩展，是性价比最高的路径。最后再说个小技巧：遇到任何部署问题，先看日志，再用最小化方式验证，不要一上来就重装，这是我在无数坑里摔出来的经验。