双卡A100部署Ollama：双实例加并发参数调优，吞吐翻倍实战

双卡 A100、系统 Ubuntu 20.04，任务是在上面把 Ollama 跑起来，并且让两张卡都能出活儿。我一开始以为这活儿半小时就能收工，结果从装驱动到起服务，一路踩坑踩到怀疑人生：先是装完驱动发现 Ollama 起不来，后来好不容易起来了，又发现两张卡只有一张在动，另一张跟睡着了一样。最后靠双实例方案把两张卡都榨干，吞吐几乎翻倍。这篇就把完整过程、关键参数、翻车原因全部摊开讲，给后面要在 A100 上部署 Ollama 的同学做个参照。

先说结论：如果你手上是多卡服务器，别指望 Ollama 默认就能把多张卡用好，老老实实按“一张卡一个实例”的思路部署，然后用并发参数调优，这既稳又容易排查问题。接下来我按落地的顺序把每个环节都拆开讲。

1. 双卡部署的整体思路与方案选型

1.1 为什么选 Ollama 而不是 vLLM 或 LMDeploy

团队当时的需求很直白：内部要快速出一个 OpenAI 兼容的推理 API，模型以 7B 到 14B 为主，不需要搞太复杂的调度，最好一个人半天内能搞定。我掐指一算，Ollama 是最合适的：

• 安装即服务，自带 model 管理，ollama pull 拉模型，ollama run 直接能聊。
• 对 OpenAI 接口兼容做得不错，改个 base_url 就能接入现有客户端。
• 底层是 llama.cpp，对单卡推理优化很成熟，量化模型支持也到位。

vLLM 我在其他项目里也用过，吞吐上限确实高，但配置门槛摆在那儿：要写 served-model-name、gpu-memory-utilization、tensor-parallel-size，还要自己装 CUDA toolkit、处理 paged attention 编译问题。对于“快速给团队提供可用服务”这个目标来说，Ollama 的学习成本和运维成本都低得多。LMDeploy 同理，性能和功能没话说，但团队没人熟悉它，我不能为了炫技把交付时间拖长。

下表是我当时做的选型对比，可以给类似需求的同学参考：

一句话总结：Ollama 适合“先把服务跑起来、把业务验证通”的阶段，vLLM 适合“吞吐压到极限、准备长期运营”的阶段。我们第一阶段用 Ollama，完全够。

1.2 单实例跨卡跑还是双实例独立跑

Ollama 底层依赖 llama.cpp，不是没有跨卡能力，当模型权重超过单卡显存时，它会把权重拆到多张卡上。听起来很美好？实际用起来问题不少：

• 跨卡并行本质是张量并行，每一层计算都要在卡之间同步，通信开销绕不开。如果是 PCIe 互联的卡，带宽远不如 NVLink，性能损耗更明显。
• Ollama 没提供很好的参数让用户控制张量并行怎么切，什么时候切全看它自己判断，出了问题你连日志都看不懂。
• 最坑的是，一旦模型被拆到两张卡，两张卡的显存基本都会被占满，你想同时在另一张卡上跑别的模型，门都没有。

所以我的选型思路是：模型量级控制在单卡能放下的范围内，然后把两张卡当成两台独立的推理服务器，用 CUDA_VISIBLE_DEVICES=0 和 CUDA_VISIBLE_DEVICES=1 各起一个 Ollama 实例。这种方案的好处很直接：

• 两个实例完全隔离，互不干扰，挂了一个还能剩一个。
• 可以同时跑两个不同的模型，比如一张卡跑代码模型，另一张卡跑对话模型。
• 排查问题容易，哪个实例出问题看哪份日志，不用在跨卡调度的黑盒里搜原因。

1.3 双实例方案的收益与边界

双实例方案最核心的收益是并行吞吐翻倍。单实例在收到并发请求时，同一时间只能把一个请求喂给 GPU 算，其他请求排队。双实例等于有了两条独立的流水线，只要客户端能把请求分散到两个实例上，总吞吐就能接近翻倍。

但也有边界：

• 单模型最大可用显存被限制在一张卡的容量（80G），跑不了需要 100G+ 显存的超大模型。
• 两个实例各自持有权重副本，显存总量浪费在一些重复加载上。比如两张卡都加载同一个 14B 模型，权重相当于存了两份。
• 如果模型本身很小（比如 3B 甚至更小），A100 单卡就能喂饱成百上千并发，双实例的意义就没那么大，瓶颈会变成内存带宽或 CPU。

所以适合双实例的场景很典型：7B 到 32B 级别的模型，并发请求量中高，希望两张卡都物尽其用。我们后面的部署和压测都基于这个定位来聊。

2. 环境准备与安装避坑

2.1 驱动、CUDA 和第一轮“翻车”

机器是 Ubuntu 20.04.6 LTS，双卡 A100 80G。第一次翻车就发生在环境准备阶段，说多了都是泪。

我当时的操作顺序是：先装 NVIDIA 驱动，再用 apt 把 CUDA toolkit 也装上了，然后重启。重启之后 nvidia-smi 正常显示两张 A100，我心想稳了。结果跑一个简单的 CUDA sample 直接报错，错误信息指向 CUDA driver 和 runtime 版本不匹配。折腾半天，卸载重装了好几次驱动，最后才搞清楚问题根源：系统里同时存在多套 CUDA 环境，PATH 和 LD_LIBRARY_PATH 引到了错误版本。

这里分享一个关键认知：Ollama 的预编译二进制自带 CUDA runtime，不依赖系统的 CUDA toolkit。也就是说，你只要把 NVIDIA 驱动装好，确认 nvidia-smi 能识别 GPU，Ollama 就能正常用 GPU 推理。系统级 CUDA 完全不用装，装了反而是给自己埋雷。

所以正确的环境准备流程是：

bash复制# 1. 确认系统版本
lsb_release -a

# 2. 安装驱动（推荐用 ubuntu-drivers 自动选版本）
sudo ubuntu-drivers autoinstall
sudo reboot

# 3. 驱动装完，确认 GPU 可见
nvidia-smi

看到类似下面的输出就说明驱动层面没问题了：

bash复制+-----------------------------------------------------------------------------+
| NVIDIA-SMI 535.154.05   Driver Version: 535.154.05   CUDA Version: 12.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-Mode | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  A100-SXM4-80GB          On  | 00000000:3B:00.0  Off |                    0 |
|   1  A100-SXM4-80GB          On  | 00000000:5E:00.0  Off |                    0 |
+-------------------------------+----------------------+----------------------+

注意驱动版本建议选 535 或更新的，A100 在 535 系列下兼容性很好。另外建议把 NVIDIA persistence mode 打开，避免显存和性能因为掉卡而波动：

bash复制sudo nvidia-smi -pm 1

提示：如果系统里已经装乱了 CUDA，不要急着重装系统，先把 /usr/local/cuda 目录下的多版本处理好，然后检查 ~/.bashrc 或 /etc/environment 里有没有残留的 CUDA 环境变量。Ollama 真的不需要系统 CUDA toolkit，别在它身上浪费时间。

2.2 安装 Ollama：官方脚本、手动二进制与模型下载加速

Ollama 官方给了一键安装脚本：

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

这条命令在海外网络环境很顺畅，但在国内经常卡在下载环节，要么是脚本拉不下来，要么是下载 Ollama 二进制时速度感人。我实测下来，两种方式最稳：

方式一：手动下载二进制

直接从 GitHub Releases 下载对应架构的二进制压缩包，传到服务器 /usr/local/bin/ 目录下解压：

bash复制cd /tmp
# 假设已经下载了 ollama-linux-amd64.tgz
tar -C /usr/local -xzf ollama-linux-amd64.tgz
chmod +x /usr/local/bin/ollama
ollama --version

这里提醒一句：手动放二进制文件后，千万别忘记 chmod +x，我后来给别人远程排查问题时不止一次发现是权限问题导致启动失败。

方式二：官方脚本配镜像加速

如果脚本能拉下来，只是下载二进制慢，可以给脚本加代理环境变量（如果你有合法的加速渠道就用，没有就老实手动下载），或者用一些开源镜像站把 ollama-linux-amd64.tgz 提前下好再分发。这里的核心思路是绕开慢速下载环节，而不是一直等它超时。

模型下载慢是另一大痛点。跑了 ollama run qwen2.5:14b，你会发现模型文件动辄十几 GB，从官方仓库拉真的要等到天荒地老。我当时的解决思路是“借道”：用 ModelScope 或者国内高校镜像站下载 GGUF 格式的模型文件，再通过 Ollama 的 Modelfile 手动创建模型。

bash复制# 1. 先在镜像站下载 qwen2.5-14b-instruct-q4_k_m.gguf
# 2. 写一个 Modelfile
FROM /data/models/qwen2.5-14b-instruct-q4_k_m.gguf

# 3. 用 Ollama 创建本地模型
ollama create qwen2.5-14b -f Modelfile

# 4. 创建完成后直接跑
ollama run qwen2.5-14b

这样既能绕开官方仓库的下载瓶颈，模型文件也通过镜像站做到了加速。GGUF 文件放到你规划好的模型目录里，后面显存和目录规划一节我会展开说。

2.3 systemd 服务与目录规划，别等部署完再后悔

手动安装二进制之后，系统不会自动注册 Ollama 服务。我一开始直接在终端里跑 ollama serve，看起来没问题，但终端一关服务就断了，而且开机也不会自启。正经做法是写 systemd service。

先规划好目录。模型文件经常几十个 G，强烈建议不要放到系统根分区，最好挂载独立的 NVMe 或数据盘，按下面的结构组织：

bash复制/data/
├── ollama/
│   ├── models/    # Ollama 模型文件，通过 OLLAMA_MODELS 指定
│   ├── logs/      # 实例日志，后面排查问题要用

在 /etc/systemd/system/ollama.service 写入：

ini复制[Unit]
Description=Ollama Service
After=network-online.target

[Service]
Type=simple
EnvironmentFile=/etc/ollama/ollama.env
ExecStart=/usr/local/bin/ollama serve
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

对应的 /etc/ollama/ollama.env：

bash复制OLLAMA_MODELS=/data/ollama/models
OLLAMA_HOST=0.0.0.0:11434

然后启动并设置开机自启：

bash复制sudo systemctl daemon-reload
sudo systemctl enable --now ollama
sudo systemctl status ollama

这里有个坑我先替大家踩了：EnvironmentFile 里的变量不要加引号，OLLAMA_MODELS="/data/ollama/models" 这样写 systemd 会把引号也解析进变量值，Ollama 会去找一个带引号的目录，直接启动失败。我在这上面耗了快半小时，最后用 cat -A 一看才发现是引号问题。

3. 双实例部署与显存规划，让每张卡各司其职

3.1 先算清显存账本：权重、KV Cache 和预留空间

A100 80G 看起来很大，但真跑起来并不宽裕。部署双实例前，我先算了一笔显存账。

以 Qwen2.5-14B-Instruct 为例，用 Q4_K_M 量化后权重约 9GB，FP16 格式约 28GB。Ollama 加载模型时，除了权重，还要为每个并发请求分配 KV Cache。KV Cache 的计算公式大致是：

text复制KV Cache 字节数 = 2 × 层数 × KV 头数 × 头维度 × 上下文长度 × 字节数 × 并发数

以 7B 模型为例，假设层数 32、KV 头数 32、头维度 128、上下文长度为 4096、FP16 存储（2字节）时，单个请求的 KV Cache 大约是 2×32×32×128×4096×2 = 2GB。并发数开到 4，就要预留 8GB。14B 模型的 KV Cache 还要更大。

所以我的显存规划思路是：

• 权重独占一部分（Q4_K_M 量化下 14B 大约 9-11GB）。
• KV Cache 按并发数和上下文长度动态增长。
• 额外留出 2-4GB 余量，防止显存抖动着抖动着就 OOM。
• 通过 OLLAMA_GPU_OVERHEAD 让 Ollama 在计算可用显存时主动扣掉一部分，保底不易爆。

实际查看显存状态用两个命令，一个看 OS 层面，一个看 Ollama 内部视角：

bash复制watch -n 1 nvidia-smi
ollama ps

ollama ps 会显示当前加载了哪些模型、占了多少显存、上下文窗口多大，排查问题非常有用。

3.2 用 systemd 模板创建双实例，核心就两步

双实例部署的思路，第一步是让每个实例只能看到一张卡，第二步是让每个实例监听不同的端口。我用 systemd 模板服务一次搞定。

先创建模板文件 /etc/systemd/system/ollama@.service：

ini复制[Unit]
Description=Ollama Service (%i)
After=network-online.target

[Service]
Type=simple
EnvironmentFile=/etc/ollama/%i.env
ExecStart=/usr/local/bin/ollama serve
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

然后创建两份环境变量文件。

/etc/ollama/gpu0.env：

bash复制CUDA_VISIBLE_DEVICES=0
OLLAMA_HOST=0.0.0.0:11434
OLLAMA_MODELS=/data/ollama/models
OLLAMA_NUM_PARALLEL=4
OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_GPU_OVERHEAD=2147483648

/etc/ollama/gpu1.env：

bash复制CUDA_VISIBLE_DEVICES=1
OLLAMA_HOST=0.0.0.0:11435
OLLAMA_MODELS=/data/ollama/models
OLLAMA_NUM_PARALLEL=4
OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_GPU_OVERHEAD=2147483648

启动：

bash复制sudo systemctl daemon-reload
sudo systemctl enable --now ollama@gpu0 ollama@gpu1

验证一下两个实例是否各自就位：

bash复制curl http://127.0.0.1:11434/api/version
curl http://127.0.0.1:11435/api/version

两个都能正常返回版本号，说明双实例已经起来了。这个方案的好处是全靠 systemd 管理，重启、看日志、开机自启都是标准操作，不用额外写守护脚本。

注意：两个实例的 OLLAMA_MODELS 指向同一个模型目录是刻意为之。模型文件在磁盘上只存一份，两个实例共享，各自加载到自己的显存里，互不影响。但如果你的两个实例跑完全不同的模型，也可以各指向不同目录，看实际需求。

3.3 并发参数调优，决定吞吐的关键

双实例只是骨架，真正把吞吐拉起来的是并发参数。Ollama 有四个环境变量直接影响负载能力，挨个讲清楚：

OLLAMA_NUM_PARALLEL 控制一个模型最多同时处理几个请求。默认值是 1 或 2，这意味着就算客户端同时打了 8 个请求，Ollama 也可能只处理一个，其他全部排队。双卡环境下，我建议根据模型大小和显存余量调到 4 到 8。数值越大，单实例内部并行度越高，但 KV Cache 占用也随之上涨。调到多少合适，得结合显存账本看，不是越大越好。

OLLAMA_MAX_LOADED_MODELS 控制最多同时加载几个模型。如果设得大于 1，不同模型可以常驻显存，切换时不用重新加载。但多加载一个模型就多占一份显存，对于要压满吞吐的场景，我更建议设成 1，让实例把所有显存资源集中伺候一个模型。

OLLAMA_GPU_OVERHEAD 单位是字节，用来告诉 Ollama 在计算可用显存时预留多少空间给 CUDA context、计算图、临时缓冲区等。我设的是 2147483648，也就是 2GB。不设的话，Ollama 会尽量把显存用满，遇到显存碎片或临时需求时很容易 OOM，服务直接挂。

OLLAMA_KEEP_ALIVE 控制模型加载后驻留内存的时间。单位是秒，默认 5 分钟。频繁调用时，模型一直驻留显存，省去加载时间；长时间没请求，模型自动卸载，把显存释放出来。在压测场景建议设成 -1（永久驻留），避免偶发空闲导致模型被卸载，影响压测数据稳定性。

bash复制OLLAMA_KEEP_ALIVE=-1

还有个容易踩的坑是 num_ctx。Ollama 默认的上下文长度并不高，不同版本默认值有差异，直接显式指定最稳。调用时在 API 参数里传：

json复制{
  "model": "qwen2.5-14b",
  "prompt": "你好",
  "options": {
    "num_ctx": 8192,
    "num_predict": 512
  }
}

但要记住：上下文长度翻倍，KV Cache 占用几乎翻倍。如果开 8192 上下文再加上 8 并发，显存压力会大很多。生产环境的参数一定要在真实模型上跑一轮压测再定，不要照搬。

4. 压测与吞吐实测，看参数怎么把双卡榨干

4.1 压测方案：我用了哪些工具和指标

部署完双实例，接下来就是拿数据说话。我的压测思路很简单：用模拟真实请求的方式，同时往两个实例打请求，观察每个请求的首 token 延迟、生成速度，以及两张卡的利用率和总吞吐。

工具没有引入重型压测平台，直接写了个 Python 脚本，用 concurrent.futures 发起并发请求，从 /api/generate 取流式输出，统计耗时和 token 数。

python复制import json
import time
import requests
import concurrent.futures

URL = "http://127.0.0.1:11434/api/generate"
PROMPT = "请写一段 200 字的产品介绍，主题是智能客服系统。"
MODEL = "qwen2.5-14b"

def send_one(_):
    payload = {
        "model": MODEL,
        "prompt": PROMPT,
        "stream": True,
        "options": {"num_ctx": 8192, "num_predict": 256}
    }
    start = time.time()
    r = requests.post(URL, json=payload, stream=True)
    text = ""
    for line in r.iter_lines():
        if not line:
            continue
        data = json.loads(line)
        text += data.get("response", "")
    elapsed = time.time() - start
    tokens = len(text)
    return tokens, elapsed, text[:10]

with concurrent.futures.ThreadPoolExecutor(max_workers=8) as ex:
    results = list(ex.map(send_one, range(16)))

total_tokens = sum(r[0] for r in results)
total_time = max(r[1] for r in results)
print(f"总 token 数: {total_tokens}")
print(f"最慢请求耗时: {total_time:.2f}s")
print(f"总吞吐: {total_tokens / total_time:.2f} tokens/s")

这个脚本只是参考，压测时还要开另一个终端用 nvidia-smi dmon 实时看 GPU 利用率。如果只跑脚本不看卡的状态，等于只测了一半，因为你不知道每一张卡的负载到底怎么样。

4.2 参数调整前后的实测数据，对比一目了然

我用 Qwen2.5-14B-Instruct (Q4_K_M) 在不同配置下各跑了一轮，记录典型值如下：

数据是典型值，不同模型、不同量化、不同 prompt 会有浮动，但趋势很稳定：单实例并发再高，另一张卡始终是 0%，总吞吐大概被锁在单卡上限；切到双实例后，请求被分到两个实例，两张卡同时跑，总吞吐直接翻倍。

这个对比还说明一个道理：Ollama 单实例的多并发只是把请求排队塞进同一张卡，不是能力上限不够，而是物理资源只有一张卡。双实例的价值就是把第二张卡从“旁观者”变成“主力”。

4.3 从“双卡各跑各的”到“整体吞吐翻倍”，还有一个坑

双实例部署好、压测数据也好看，但接入真实业务时我还踩了一个坑：客户端把所有请求都打到了 11434 端口，导致 GPU0 忙死、GPU1 闲死，整体吞吐又打回原形。

问题不在 Ollama，而在入口层缺了负载均衡。解决办法很简单，我直接用 Nginx 做了 round-robin 反代：

nginx复制upstream ollama_backend {
    server 127.0.0.1:11434;
    server 127.0.0.1:11435;
}

server {
    listen 80;

    location / {
        proxy_pass http://ollama_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 600s;
    }
}

这样客户端只认一个地址，Nginx 把请求轮流分发到两个实例，双卡利用率就都上来了。如果你是直接用 OpenAI SDK 对接，也可以在自己的代码里实现轮询，两个 base_url 交替使用，效果一样。

提示：Nginx 的 proxy_read_timeout 一定要调大，默认 60 秒在大模型生成场景根本不够用。模型生成一段长文本很容易超过一分钟，超时后客户端会收到错误断流，排查问题时很容易误判成 Ollama 的问题，实际是 Nginx 在中间把连接掐了。

5. 常见问题排查与实战心得

5.1 高频翻车点速查表

部署和压测过程中，我把遇到的高频问题整理成了表格，后面排查问题直接照着看：

5.2 排查三板斧：日志、显存、进程

遇到问题不要瞎猜，按顺序查三个地方，90% 的问题都能定位。

第一板斧是日志。systemd 管理的服务，日志直接看：

bash复制sudo journalctl -u ollama@gpu0 -f
sudo journalctl -u ollama@gpu1 -f

Ollama 的日志写得还算直白，显存不足、端口冲突、模型加载失败都会有明确提示。压测时我习惯开着日志窗口实时观察，看到报错马上能定位是哪个实例。

第二板斧是显存。nvidia-smi 看当前占用和进程，nvidia-smi dmon -d 1 看每秒的利用率曲线。双实例部署后，如果 GPU0 和 GPU1 的显存占用严重不对等，基本可以断定请求没有分流，或者 CUDA_VISIBLE_DEVICES 配错了。

第三板斧是 Ollama 内部状态：

bash复制curl http://127.0.0.1:11434/api/ps
curl http://127.0.0.1:11435/api/ps

这个接口会返回当前加载的模型、显存占用、上下文长度和并发状态，能直接看出来一个实例到底在干什么。

5.3 几句实在话，写给要在多卡上跑 Ollama 的人

整个流程走下来，我最深的感受是：多卡部署 Ollama 的难点不在 Ollama 本身，而在于你能不能把资源边界划清楚。强行让一个实例管理两张卡，短期看起来省事，长期维护和排障都是负担。用 CUDA_VISIBLE_DEVICES 把卡隔离成独立实例，再通过负载均衡把请求分散过去，反而最稳。

再补一个容易忽略的小细节：手动安装 Ollama 二进制后，chmod +x 别漏；写 systemd 的 env 文件时，值两边不要加引号。这两个问题看似小，但都能让服务起不来，而且报错信息不够直观，很容易让人误判成驱动或 CUDA 问题，浪费时间。

如果后续要把这套双实例方案往生产方向推，我会建议再加上监控告警，盯着每个实例的显存占用、GPU 利用率和请求失败率。至于要不要从 Ollama 迁移到 vLLM，就取决于吞吐需求是否真的到了 Ollama 撑不住的地步，到那时候再做迁移，成本也完全可控。