离线GPU环境部署Ollama：驱动、运行时与一键修复全指南

这事要从我上周的一次实际部署说起。某团队在一台GPU算力平台上做本地推理服务平台把外网切断得很彻底只有SSH和文件上传两条通道。按照官方文档把ollama装好、模型也导进去了一切看着都正常可启动后一跑小模型日志里死活不出现GPU型号那一行输出慢到让人怀疑机器是租来练耐心的。查了两天最后把问题拆成驱动、运行时、安装包三条线才算真正解决。这篇整理出完整链路和一键脚本给还在离线环境GPU不识别里折腾的人一条无脑路径。1. 离线GPU实例上把ollama装好三件容易被忽略的事1.1 官方一行命令装完我却只能看到CPU在跑Ollama官方给的安装方式是curl -fsSL https://ollama.com/install.sh | sh这条命令会自己下载适配的二进制、注册systemd服务还会顺手配置环境变量。但离线机器上它从一开始就跑不通因为第一步的下载就没了源头。很多人这时候会选择在网上随便找个tar包丢上去解压解压完ollama -v能输出版本号就觉得装好了。真正的坑在第二步模型推理时ollama能不能找到GPU。我当时的现象很典型——ollama serve能起模型也能正常对话但加载模型时日志里没有一条关于GPU的信息。往下拉日志才看到默认走了CPU后端一个1.5B的小模型一次生成要等好几秒。这种状态如果不停下来排查后面所有项目进度都会被拖在看起来能跑、实际上跑不动的尴尬里。离线安装的正确打开方式是准备三样东西Ollama的Linux tgz包、NVIDIA容器运行时工具包如果平台是容器环境、以及离线的模型文件。三者缺一个就必然出现命令能执行但GPU型号不出现这类问题。后面第三部分会给出完整的清单和脚本这里先把现象认清楚。1.2 先分清三种假成功命令能跑不等于GPU在干活排障时我见过最多的误判是把ollama命令正常当成ollama服务在GPU上正常。根据日志表现基本可以分成三种假成功服务假死型ollama serve是启动了但监听地址停留在127.0.0.1外部机器根本没连上去。你在本机测试一切正常换个机器用IP访问就是连接拒绝。这个问题多出在OLLAMA_HOST没有设置或者被systemd单元文件里的默认值覆盖。CPU兜底型ollama确实在跑模型也确实加载了但底层用的是CPU后端。日志里看不到inference compute字段也不会有GPU型号、显存大小这类信息。有些人会觉得反正有输出可能就是版本日志精简了这就彻底跑偏了。静默失败型日志里出现CUDA初始化失败之类的错误但ollama会自动降级到CPU继续跑服务不崩溃、接口也不报错只有性能数据不对劲。这种最坑因为它不会主动告诉你我没用GPU。所以启动ollama后第一步不是急着测试对话功能而是确认日志里有没有GPU相关信息。看到librarycuda和型号名才叫真的成功看到libraryggml、CPU、NO CUDA这类字眼都说明GPU链路还是断的。2. 从驱动到推理框架的链路拆解nvidia-smi正常为什么还不够2.1 一条完整的GPU推理链路看清楚谁在服务谁在写一键脚本之前必须先理清这条链路。GPU推理不是把程序扔到显卡上跑这么简单它至少分三层最底层是机房宿主机上的内核驱动负责和A100这类GPU硬件通信。你可以把它理解成硬件操作系统的API。驱动层之上是用户态运行时库核心文件是libcuda.so、libnvidia-ml.so以及CUDA工具链。应用层通过libcuda.so发起GPU调用通过libnvidia-ml.so查询显存和温度。最后才是应用层也就是ollama以及它内部的llama.cpp运行器。常规物理机的链路是ollama → libcuda.so → 驱动 → GPU。中间任何一个环节断掉ollama就看不到设备。但云平台租来的GPU实例链路里往往还夹着一层容器运行时。平台通过NVIDIA Container Toolkit把宿主机上的GPU设备映射到容器内ollama实际上是跑在容器里它看不到宿主机物理设备只能看到容器运行时给它的/dev/nvidia0等设备节点和对应的库文件。这就是为什么你自己在本地物理机上测试一切正常一上云平台就没有输出使用GPU型号。因为问题根本不在ollama而在容器运行时没把GPU能力传递进去。2.2 断点不出在驱动而出在进程看不到驱动库很多排障思路首先就是nvidia-smi。在物理机上如果nvidia-smi能正常输出GPU信息驱动就是好的。但在容器环境和云实例里这个结论要被推翻。我遇到的情况就是宿主机驱动完全正常SSH上去执行nvidia-smi -L能清晰列出GPU型号和显存但ollama进程就是认不出来。原因在于ollama所在的环境里没有libcuda.so的加载路径。进程找不到库就会放弃CUDA后端安静地退到CPU。打个比方驱动是电厂的发电机组libcuda.so是输电网应用是你家的电器。电厂明明在发电但你家没接电线电器当然不工作。nvidia-smi能出结果只说明驱动是健康的不代表应用能走到它面前。所以在排查链路时要按照驱动 → 运行时库 → 应用的顺序逐层验证。判断节点很明确驱动层nvidia-smi -L有输出。设备节点ls /dev/nvidia*能看到nvidia0、nvidiactl、nvidia-uvm等。如果没有这些节点容器或调度层就没把GPU映射进来。库文件ldconfig -p | grep libcuda能看到libcuda.so的条目。如果找不到说明运行时头文件缺失。应用层ollama启动日志里出现librarycuda和GPU名称。前三层由平台和镜像决定最后一层才由ollama的安装方式决定。把这四个检查点写进脚本里就能实现无脑运行。3. 一键修复脚本离线包准备、运行与逐段解读3.1 离线包清单四个文件缺一个就白折腾离线环境里最怕的不是步骤复杂是包不全。基于多次踩坑我整理了一份固定清单每次开新实例都按这个传文件文件用途说明ollama-linux-amd64.tgzollama主程序及运行器从联网机器下载后上传版本建议0.3.x以上老版本日志不打印GPU型号nvidia-container-toolkit-base_*.deb容器运行时基础工具仅在平台使用容器/docker环境时需要裸机可跳过nvidia-container-toolkit_*.deb容器运行时配置工具用于生成docker的nvidia runtime配置模型文件归档包离线模型在联网机器ollama pull后打包OLLAMA_MODELS目录上传这里特别提醒版本不要随手拿旧的。早期版本的ollama在日志里只会打出inference compute ... librarycuda compute7.5并不会直接显示GPU名称。如果你拿到的包是几个月前的即使GPU链路全通也不会出现型号输出很多人就是被这一点误导以为没识别成功。另外模型文件归档包一定要带上manifests和blobs两个子目录只拷大文件不拷清单文件ollama服务端根本认不出模型。3.2 脚本关键段逐行拆解探测、补运行时、启动、验证下面这个脚本就是标题里无脑运行的落地方案。它做的事情不是单纯的./install.sh而是检测-修复-启动-验证的完整闭环任何一步失败都会明确告诉你卡在哪#!/usr/bin/env bash set -e # 0. 必需以root执行 if [ $(id -u) -ne 0 ]; then echo [错误] 请用root或sudo执行 exit 1 fi WORKDIR$(pwd) echo [1/6] 检测GPU硬件与驱动... if nvidia-smi -L /dev/null 21; then nvidia-smi -L else echo [错误] nvidia-smi不可用请先在平台后台确认实例已分配GPU exit 1 fi echo [2/6] 检测并安装容器运行时工具... if ! command -v nvidia-ctk /dev/null 21; then if ls nvidia-container-toolkit*.deb /dev/null 21; then dpkg -i nvidia-container-toolkit-base_*.deb nvidia-container-toolkit_*.deb 2/dev/null \ || apt-get -f install -y 2/dev/null || true else echo [警告] 未找到container toolkit安装包跳过裸机场景不影响 fi fi command -v nvidia-ctk /dev/null 21 nvidia-ctk runtime configure --runtimedocker || true systemctl restart docker 2/dev/null || service docker restart 2/dev/null || true # 3. 安装ollama主程序 echo [3/6] 解压ollama到系统目录... if [ ! -x /usr/local/bin/ollama ]; then tar -C /usr/local -xzf ollama-linux-amd64.tgz # 新版ollama解压后lib在/usr/local/lib/ollama部分环境需要创建软链 ln -sf /usr/local/lib/ollama /usr/lib/ollama 2/dev/null || true fi ollama -v || exit 1 # 4. 配置基础参数 echo [4/6] 准备模型目录与服务参数... mkdir -p /data/ollama-models export OLLAMA_MODELS/data/ollama-models export OLLAMA_HOST0.0.0.0 export OLLAMA_DEBUG1 # 5. 后台启动serve echo [5/6] 启动ollama serve... pkill -f ollama serve 2/dev/null || true sleep 2 nohup ollama serve /data/ollama.log 21 sleep 5 # 6. 检查日志中是否出现GPU信号 echo [6/6] 验证GPU后端是否生效... if curl -s http://127.0.0.1:11434/api/version /dev/null 21; then echo ollama API已启动 else echo [错误] API未启动查看/data/ollama.log tail -50 /data/ollama.log exit 1 fi if grep -iE inference compute|librarycuda|gpu /data/ollama.log | head -20; then echo [OK] GPU后端已生效 else echo [检查] 日志中未找到GPU信息请继续阅读下文排错清单 tail -80 /data/ollama.log fi第一段set -e的作用是遇到错误立即退出避免后续步骤在一个坏环境上继续跑出一堆更迷惑的错误。硬性要求root是因为ldconfig、dpkg、systemctl这些操作都需要管理员权限普通用户执行会在中途莫名其妙失败。tar -C /usr/local -xzf是标准离线安装路径。这里注意一个细节旧版包解压出来是usr/local/bin/ollama单文件新版包则还附带一个usr/local/lib/ollama目录里面才是真正干活的运行时组件。如果只把bin拷走而漏掉libollama能启动但加载GPU运行器时会直接缺文件。第4步里设置OLLAMA_MODELS/data/ollama-models是刻意为之。平台上用户目录的空间配额往往不大而模型文件动辄几十GB放在/data这种数据盘才安全。更重要的是后续你在本机把模型打包上传时只要两边都用同一个OLLAMA_MODELS路径解压后立刻可识别不用再去改配置。最后检查日志是我临时加上去的防呆设计。脚本运行完不自动去看日志就没有解决读者我不知道有没有成功的焦虑。grep到了GPU字段就亮绿灯否则直接抛日志尾部让问题暴露在明面上。3.3 无脑背后的防御式改造环境不知道配置时该怎么兜底无脑运行不是说脚本一行跑完完全盲目。真正的无脑是脚本能自己判断当前环境缺了什么再决定补什么。因为同是GPU离线环境不同平台差别很大有的给你裸机有的给你一个预装好Docker的镜像有的则只给一个容器。在脚本里我做了三处防御第一处command -v nvidia-ctk判断不存在才执行安装已经存在就跳过。这样在物理机上跑不会误装无用的工具。第二处nvidia-ctk runtime configure --runtimedocker后面特意跟了|| true。这句的意思是配置失败也继续。不是逃避问题而是考虑到平台可能用的是非Docker的容器引擎配置这一步失败了并不代表后面不能启动。再往后systemctl restart docker也加了|| true因为有些环境没有systemd用service命令也一样。通过降低单步失败的致命度脚本才能在未知架构里继续走下去。第三处pkill -f ollama serve是为了重复执行脚本时不产生端口冲突。很多人第一次跑失败了日志里全是旧进程的输出回头调试时就分不清新日志和旧日志白白浪费很多时间。杀掉残留进程再重启每次都是从干净状态开始。这种每步先探测、失败后尝试替代方案、最后统一验证的结构才是让不同环境的读者都能直接跑通的真正原因。与其把每种平台的差异讲一大堆不如把判断逻辑写进脚本让大家一键跳过那些重复劳动。4. 验证与排错确认GPU型号真正出现以及不出现的处理顺序4.1 三种由轻到重的验证手段脚本跑完亮绿灯还不够我习惯再做三轮独立验证分别从日志、进程、速度三个维度锁定结论第一轮是日志。ollama serve日志里如果出现类似下面这行说明ollama确实走了CUDA后端time2025-01-18T10:00:00.000Z levelINFO msginference compute id0 librarycuda variantv12 compute7.5 nameNVIDIA A100-SXM4-40GB total40 GiB关键字段有三个librarycuda表示后端是CUDAnameNVIDIA A100-SXM4-40GB是之前怎么都等不到的GPU型号total40 GiB是显存大小。如果你看到的信息只有libraryggml或CPU字样那说明GPU链路仍然没通。第二轮是显存占用。启动一个大一点的模型后另开一个SSH窗口执行nvidia-smi看进程列表里有没有占用显存的ollama、ollama_llama_server或python进程。有GPU加速的进程会占掉几十GB显存。虽然不严谨但可以直观确认卡上真的住了人。第三轮是实测速度。用相同提示词分别测试大模型和小模型感受单token生成时延。GPU正常的1.5B小模型通常每秒几十tokenCPU环境下只有每秒几个token差距非常明显。速度测试虽然是三大方法中最粗糙的但也是对上面两个方法的交叉验证尤其适合那些日志被截断、没法确认到底跑没跑GPU的场景。4.2 日志里始终没有GPU型号的排查清单如果日志里干净得像没发生过加速一样别急从上到下一步一步查。我把遇到过的真实情况和对应处理方式整理成了一张表现象根因处理方式nvidia-smi -L都报错平台实例本身