Linux 服务器部署 DeepSeek 大模型完全指南（2026 版）

摘要：这篇文章假设你有一台装了 Linux 的服务器------Ubuntu、Debian、CentOS 都行，物理机或云服务器都可以------并且你希望通过 Ollama 把 DeepSeek 的蒸馏模型跑起来，最终暴露成一个可调用的 API。全文从"登录服务器"开始，到"用 API Key 保护好的接口"结束，每一步都给出完整命令和预期结果，不需要你事先懂 Linux 系统管理。

先搞清楚你的服务器能不能跑

在敲任何安装命令之前，先确认两件事：GPU 有没有 ，以及内存/显存够不够。

登录服务器，执行：

bash 复制代码

lscpu | grep "Model name"
free -h
nvidia-smi

free -h 看内存总量。nvidia-smi 如果输出了 GPU 型号、显存大小和驱动版本，说明 NVIDIA 驱动已经就位；如果提示 command not found，说明没有 NVIDIA 驱动或没有 NVIDIA GPU。Ollama 在 Linux 上对 NVIDIA GPU 的支持最成熟，AMD 需要 ROCm v7，纯 CPU 也能跑但速度会明显下降。

显存与模型的对应关系 （Q4 量化）：1.5B 约 2GB，7B/8B 约 5--6GB，14B 约 9--10GB，32B 约 20GB，70B 约 43GB。一台 8GB 显存的机器跑 deepseek-r1:8b 是舒服的起点；24GB 显存（RTX 3090/4090）可以尝试 32B；如果没有 GPU，16GB 内存跑 7B/8B 的 CPU 推理是可行的，但不要指望 14B 以上还能有交互级的速度。

NVIDIA 驱动的版本要求：Ollama 官方要求驱动 531 或更新，计算能力 5.0+（GTX 750 Ti 及以上）。可以用下面这条命令单独查驱动版本：

bash 复制代码

nvidia-smi --query-gpu=driver_version --format=csv,noheader

如果版本低于 531，先去 NVIDIA 官网更新驱动，再继续后面的步骤。

第一步：一键安装 Ollama

Ollama 官方提供了一行安装脚本，在 Linux 上会自动完成下载、解压、创建 ollama 系统用户、注册 systemd 服务并启动。在终端执行：

bash 复制代码

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

这条命令做了以下几件事：把 Ollama 二进制安装到 /usr/local/bin/ollama，创建系统用户 ollama（shell 为 /bin/false，不能登录），把模型存储目录设为 /usr/share/ollama/.ollama/models，并在 /etc/systemd/system/ollama.service 写入服务单元。

安装完成后验证：

bash 复制代码

ollama --version
systemctl status ollama --no-pager

systemctl status 应该显示 active (running)。如果显示 inactive 或 failed，先看日志：

bash 复制代码

journalctl -u ollama -n 50 --no-pager

如果服务器没有外网 ，不能用一键脚本，改用离线安装：从另一台能上网的机器下载 ollama-linux-amd64.tar.zst，传到服务器后执行 sudo tar x -C /usr -f ollama-linux-amd64.tar.zst，然后手动创建 systemd 服务文件（内容见下一节），再 systemctl daemon-reload && systemctl enable --now ollama。

第二步：拉取并运行 DeepSeek 模型

Ollama 安装好之后，拉取模型只需要一条命令。先拉一个 8B 蒸馏版做验证：

bash 复制代码

ollama pull deepseek-r1:8b

下载量约 5GB，取决于服务器带宽，可能需要几分钟到十几分钟。下载完成后直接交互运行：

bash 复制代码

ollama run deepseek-r1:8b

进入 >>> 提示符后，输入一句测试：

复制代码

9.11 和 9.9 哪个大？为什么？

DeepSeek-R1 系列会输出 <think>...</think> 形式的推理过程，然后给出结论。看到这个行为，说明模型和推理引擎都正常。输入 /bye 退出交互模式。

如果要直接拉取更大或更小的版本，把 8b 换成 1.5b、14b、32b 即可。可以用 ollama list 查看本机已有哪些模型。

第三步：把 Ollama 配成一个正经的后台服务

一键脚本已经创建了 systemd 服务，但默认监听 127.0.0.1:11434，只允许本机访问。这一节要做两件事：确认服务开机自启 ，以及为后面暴露 API 做好准备。

确认开机自启

bash 复制代码

sudo systemctl enable ollama

如果安装时已经自动 enable，这条命令会提示 Created symlink ... 或直接无输出，都正常。

用 systemd override 修改配置（关键）

不要直接编辑 /etc/systemd/system/ollama.service 。正确做法是用 systemctl edit 创建覆盖文件，这样 Ollama 升级时你的自定义配置不会被覆盖：

bash 复制代码

sudo systemctl edit ollama

这会打开一个空文件（或带注释的编辑器），在 [Service] 段落下添加需要的环境变量。最基本的两个是监听地址和模型存储路径：

ini 复制代码

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/data/ollama/models"

OLLAMA_HOST=0.0.0.0:11434 让 Ollama 监听所有网络接口，局域网内的其他机器才能访问到它。OLLAMA_MODELS 把模型从默认的系统盘路径挪到独立数据盘（如果服务器有数据盘的话），避免模型文件撑爆根分区。

保存退出后，执行：

bash 复制代码

sudo systemctl daemon-reload
sudo systemctl restart ollama

然后验证监听状态：

bash 复制代码

ss -tlnp | grep 11434

应该看到 0.0.0.0:11434 或 *:11434，而不是 127.0.0.1:11434。

⚠️ 一个必须理解的风险 ：0.0.0.0 意味着这台服务器的 11434 端口对所有能路由到它的地址开放，而 Ollama 本身没有任何认证机制 ------任何人知道 IP 和端口，就可以调用模型、拉取模型、查看已安装模型列表。如果你只是想在局域网内用，配合防火墙限定来源网段是可以接受的；如果要暴露到公网，必须先完成后面的 Nginx 反向代理和 API Key 步骤，不要让 11434 裸奔在公网上。

第四步：GPU 配置与显存调优（有 NVIDIA 显卡必看）

Ollama 会自动检测 NVIDIA GPU 并把模型层卸载到显存。但"自动"不等于"最优"，在显存紧张或多卡场景下需要手动干预。

确认 Ollama 在用 GPU

运行一个模型后，另开一个终端执行：

bash 复制代码

nvidia-smi

在进程列表里应该能看到 ollama 相关的进程占用了显存。如果看不到，说明 Ollama 回退到了 CPU，需要检查驱动版本和 CUDA 兼容性。

限制使用的 GPU

服务器有多张卡时，用 CUDA_VISIBLE_DEVICES 指定 Ollama 使用哪几张。在 systemd override 中加入：

ini 复制代码

Environment="CUDA_VISIBLE_DEVICES=0"

等号右边是 GPU 编号，0 表示第一张卡。可以用 nvidia-smi -L 查看所有卡的列表。使用 UUID（如 GPU-abc123）比数字编号更可靠，因为编号顺序可能随驱动或重启变化。

显存不够时的关键参数

OLLAMA_GPU_OVERHEAD 用于在每张 GPU 上预留一部分显存，防止模型加载时把显存占满导致驱动层 OOM。单位是字节，预留 2GB 写作：

ini 复制代码

Environment="OLLAMA_GPU_OVERHEAD=2147483648"

对于 8GB 显存跑 8B 模型这种"刚好卡在边界"的情况，预留 1--2GB 往往能让加载过程更稳定。

另一个影响显存占用的大头是 上下文长度 。Ollama 的默认 num_ctx 可能较高，KV Cache 会随上下文线性增长。如果遇到 OOM，通过 API 调用时在请求中把 num_ctx 降到 4096，通常能释放出可观的显存，而日常对话和代码补全很少需要超过 4K 的上下文。

第五步：放行防火墙（局域网场景）

如果服务器开启了 ufw 或 firewalld，需要显式放行 11434 端口。

Ubuntu/Debian（ufw） ：

bash 复制代码

sudo ufw allow 11434/tcp

但更安全的做法是只允许特定网段，例如只允许 192.168.1.0/24：

bash 复制代码

sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp

CentOS/RHEL（firewalld） ：

bash 复制代码

sudo firewall-cmd --permanent --add-port=11434/tcp
sudo firewall-cmd --reload

如果使用 iptables 直接管理规则，对应的命令是：

bash 复制代码

sudo iptables -A INPUT -p tcp --dport 11434 -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 11434 -j DROP

放行后，从局域网内另一台机器用 curl 测试：

bash 复制代码

curl http://<服务器IP>:11434/api/tags

返回 JSON 模型列表即说明网络层通了。

第六步：Nginx 反向代理 + API Key 认证（公网暴露的唯一正确姿势）

只要调用方跨越了"完全信任"的边界------无论是公网、还是公司内网中你无法控制的设备------就必须在 Ollama 前面加一层带认证的反向代理。Ollama 本身没有 API Key 支持，Nginx 的职责就是校验请求头、限流、TLS 终止，然后才把合法请求转发给 127.0.0.1:11434。

安装 Nginx

bash 复制代码

sudo apt update && sudo apt install -y nginx    # Debian/Ubuntu
# 或
sudo yum install -y nginx                        # CentOS/RHEL

生成 API Key

bash 复制代码

openssl rand -hex 16

输出一个 32 位十六进制字符串，把它保存到安全的地方（密码管理器或服务器的环境变量文件）。不要把这个字符串写进代码仓库或聊天记录。

写 Nginx 配置

创建 /etc/nginx/conf.d/ollama-api.conf：

nginx 复制代码

# 定义合法的 API Key 映射
map $http_authorization $is_valid_key {
    default 0;
    "Bearer 把这里替换成你生成的API_KEY" 1;
}

# 限流：每个 IP 每分钟最多 60 次请求
limit_req_zone $binary_remote_addr zone=ollama_limit:10m rate=60r/m;

server {
    listen 443 ssl;
    server_name ai.yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/ai.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ai.yourdomain.com/privkey.pem;

    location /v1/ {
        if ($is_valid_key = 0) {
            return 401 '{"error":"Unauthorized"}';
        }

        limit_req zone=ollama_limit burst=10 nodelay;

        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;
        proxy_set_header X-Forwarded-Proto $scheme;

        # 流式响应必须关闭 buffering
        proxy_buffering off;
        proxy_cache off;
    }

    location /api/ {
        deny all;
    }

    location /health {
        access_log off;
        return 200 "OK";
    }
}

这份配置的核心逻辑：/v1/ 路径做 API Key 校验和限流后转发到 Ollama；/api/ 是 Ollama 原生路径，直接 deny all，只暴露 OpenAI 兼容端点，减少攻击面；/health 用于负载均衡器或监控探活。proxy_buffering off 是流式输出必须的，否则客户端会等到完整响应才收到数据。

申请 TLS 证书

如果已有域名并解析到这台服务器，用 Certbot 自动申请 Let's Encrypt 证书：

bash 复制代码

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d ai.yourdomain.com

Certbot 会自动修改 Nginx 配置并配置续期。如果没有域名，可以在内网使用自签名证书，或者先只用 HTTP 在内网测试，但公网暴露必须使用 HTTPS。

重载 Nginx 并验证

bash 复制代码

sudo nginx -t && sudo systemctl reload nginx

从另一台机器测试带 Key 的调用：

bash 复制代码

curl https://ai.yourdomain.com/v1/chat/completions \
  -H "Authorization: Bearer 你生成的API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-r1:8b","messages":[{"role":"user","content":"你好"}]}'

如果返回包含 choices[0].message.content 的 JSON，认证链路就通了。不带 Key 或用错 Key 应该返回 401。

调用方代码示例

用 OpenAI Python SDK 调用时，只需要把 base_url 指向你的代理域名，把 api_key 设为你生成的 Key：

python 复制代码

from openai import OpenAI
import os

client = OpenAI(
    base_url="https://ai.yourdomain.com/v1",
    api_key=os.environ["OLLAMA_PROXY_KEY"],
)

stream = client.chat.completions.create(
    model="deepseek-r1:8b",
    messages=[{"role": "user", "content": "用 Python 写一个二分查找"}],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Key 通过环境变量传入，不要硬编码。

第七步：系统级加固------让 11434 彻底不被外部看到

Nginx 反向代理生效后，还应该确保 11434 端口本身对外部完全不可见。最彻底的做法是把 OLLAMA_HOST 改回 127.0.0.1:11434，让 Ollama 只监听本地回环，所有外部流量都必须经过 Nginx。在 systemd override 中修改：

ini 复制代码

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_MODELS=/data/ollama/models"

daemon-reload 并重启 Ollama 后，用 ss -tlnp | grep 11434 确认监听地址变回 127.0.0.1。此时从外部直接访问 http://服务器IP:11434 应该连接失败，只有经过 Nginx 的 https://ai.yourdomain.com/v1/ 才能到达 Ollama。这是纵深防御的核心一步：反向代理做认证，监听地址做网络隔离，两者缺一不可。

第八步：监控与日常运维

API 暴露之后，你需要知道服务是否还活着、模型是否还在显存里、请求量有多大。Ollama 提供了内置的 /metrics 端点，输出 Prometheus 格式的指标：

bash 复制代码

curl http://127.0.0.1:11434/metrics | grep ollama_

可以看到 ollama_model_requests_total（请求总数）、ollama_model_list_requests_total（列表请求数）等。如果需要更完整的监控（显存占用、token 速度、模型加载状态），可以部署 ollama-exporter 或 ollama-metrics sidecar，把指标接入 Prometheus 和 Grafana。

日常运维最少要记住这几条命令：

bash 复制代码

sudo systemctl status ollama --no-pager      # 服务是否活着
journalctl -u ollama -f                      # 实时看日志
nvidia-smi                                   # GPU 显存和进程
ollama ps                                    # 当前加载了哪些模型
ollama list                                  # 已安装模型列表

如果发现模型长时间占着显存不释放，可以调整 OLLAMA_KEEP_ALIVE：设为 5m 表示最后一次请求后保留 5 分钟，0 表示立即卸载，-1 表示永不卸载（适合专用推理服务器）。OLLAMA_NUM_PARALLEL 控制并发请求数，对单卡服务器建议设为 1 或 2，设得过高会导致请求排队和显存竞争。

常见故障速查

ollama pull 卡住或超时。 检查服务器能否访问 ollama.com 和模型 CDN。如果网络受限，考虑从能上网的机器用 ollama pull 后把 ~/.ollama/models 目录整体拷贝过来。

systemctl status 显示 failed。 先看 journalctl -u ollama -n 50 --no-pager。常见原因是 OLLAMA_MODELS 路径不存在或没有写权限。创建目录并 sudo chown ollama:ollama /data/ollama/models 后重启。

GPU 没被使用，推理很慢。 先用 nvidia-smi 确认驱动正常。如果驱动正常但 Ollama 仍走 CPU，检查是否有 CUDA_VISIBLE_DEVICES=-1 之类的覆盖配置，或者驱动版本低于 531。Linux 休眠/唤醒后可能丢失 NVIDIA UVM 模块，执行 sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm 重新加载。

Nginx 返回 502 Bad Gateway。 说明 Nginx 连不上 127.0.0.1:11434。检查 Ollama 是否在运行、OLLAMA_HOST 是否仍是 0.0.0.0 但 Ollama 重启失败。curl http://127.0.0.1:11434/api/tags 在服务器本机应该能通。

流式输出没有逐字返回。 Nginx 配置缺少 proxy_buffering off;，加上后 reload。

写在最后

把 DeepSeek 部署到 Linux 服务器上，本质上是在做三件事：让推理引擎以系统服务的方式稳定运行，让 GPU 被正确利用，以及让 API 在越过信任边界时受到保护。这三件事里，最容易出问题的是第三件------Ollama 的设计哲学是"默认信任本机"，它出厂时没有认证。本机调用是最安全的默认态；局域网共享要配合防火墙限定来源；一旦跨越信任边界，Nginx + API Key + 监听回环不是可选项，而是底线。 做到这一点，你得到的就不是一个"在服务器上跑起来的玩具"，而是一个可以被应用安心调用的私有推理后端。