1. 为什么“离线安装 Ollama”不是一句空话而是真实存在的刚需场景你有没有遇到过这样的情况在客户现场的生产服务器上网络策略严格到连 ping 都被拦截或者在工厂车间的工控终端里USB 接口被物理封禁只留一个网口且全程走白名单代理又或者在科研单位的涉密内网中所有外网访问一律禁止连 DNS 查询都要走内部解析这时候你拿着官网那句“curl -fsSL https://ollama.com/install.sh | sh”就傻眼了——命令还没执行完终端就卡在 curl: (7) Failed to connect to ollama.com port 443: Connection refused。这不是理论假设而是我过去三年在制造业、能源集团和高校实验室部署本地大模型时踩过的典型现场。Ollama 本身设计简洁但它的默认安装逻辑极度依赖实时联网下载二进制、校验 SHA256、自动拉取模型元数据、甚至启动时还要向 registry.ollama.ai 发起一次轻量级健康检查。一旦断网整个流程就停在第一步。更麻烦的是很多用户误以为“下载好 ollama-linux-amd64 文件就算装好了”结果双击运行报错error: failed to start server: listen tcp :11434: bind: address already in use或更常见的error: unable to find model manifest——其实根本不是端口冲突而是它试图从远程 registry 加载模型清单失败后静默退出连日志都不打全。关键词里反复出现的“离线安装”“国内镜像”“下载太慢了”“模型离线下载”背后是同一类现实约束网络不可控而非技术不成熟。它不等于“技术落后”而恰恰说明部署环境对安全、合规、稳定性的要求远高于普通开发机。比如某电力调度中心的 AI 辅助决策终端必须满足等保三级要求所有软件组件需提供完整来源证明、签名验证链和离线可复现安装包再比如某汽车厂的产线质检边缘盒子固件冻结后不允许任何动态网络行为连系统时间同步都只能靠 NTP 内网服务器更别说调用外部 API。所以“离线安装 Ollama”这件事本质不是教你怎么跳过联网步骤而是构建一套可审计、可验证、可回滚、零外网依赖的本地化交付体系。它包含三个刚性层次安装层Ollama 二进制本体及其所有运行时依赖libc、openssl、ca-certificates 等必须全部打包、签名、校验模型层模型文件GGUF 格式 元数据Modelfile、.json 清单、LICENSE需完整镜像支持离线加载与版本管理运行层服务配置、用户权限、日志路径、模型缓存目录等必须预设为内网友好模式避免首次启动时因缺省配置触发网络探活。这三者缺一不可。只搞定二进制安装模型下不来只搞定了模型 ZIP 包Ollama 启动不了两者都齐了但没处理好 SELinux 上下文或 systemd 单元文件服务照样起不来。接下来我会按这三层结构把每一步拆解到具体命令、参数含义、常见报错和绕过方案——不是给你一个“能跑就行”的脚本而是让你在任何封闭环境中都能像搭积木一样一块一块确认每个组件的状态。2. 安装层从源码编译到二进制打包彻底摆脱 curl 和 aptOllama 官方提供的 install.sh 脚本本质是个“联网安装器”它只做三件事检测系统架构、下载对应平台的预编译二进制、赋予执行权限、创建软链接。但这个过程在离线环境下完全失效。真正的离线安装必须提前在有网机器上完成全链路构建与验证再将产物拷贝至目标机器。这里的关键不是“怎么下载”而是“怎么确保下载的东西在离线环境下能真正工作”。2.1 为什么不能直接用官网二进制——glibc 版本陷阱与动态链接真相很多人会说“我直接下载 ollama-linux-amd64scp 过去 chmod x 就行。” 实测中这是失败率最高的做法。原因在于 Linux 动态链接的隐性依赖。以当前最新版 v0.1.49 为例其二进制通过ldd ollama检查会显示linux-vdso.so.1 (0x00007fff...) libpthread.so.0 /lib64/libpthread.so.0 (0x00007f...) libc.so.6 /lib64/libc.so.6 (0x00007f...) libdl.so.2 /lib64/libdl.so.2 (0x00007f...) libm.so.6 /lib64/libm.so.6 (0x00007f...) /lib64/ld-linux-x86-64.so.2 (0x00007f...)看起来只依赖系统基础库但问题出在libc.so.6的 ABI 兼容性上。CentOS 7 默认 glibc 2.17而 Ubuntu 22.04 是 2.35Ollama 官方二进制是在较新 glibc 上编译的。当你在 CentOS 7 上直接运行会报错./ollama: /lib64/libc.so.6: version GLIBC_2.28 not found (required by ./ollama)这不是 Ollama 的 bug而是 Go 编译器默认启用-ldflags-linkmode external导致的。解决方案只有两个要么升级目标系统 glibc高风险不推荐要么在目标系统相同版本的环境中重新编译。提示不要迷信“静态编译”。Go 的CGO_ENABLED0 go build确实能生成纯静态二进制但 Ollama 依赖 cgo 调用 OpenSSL 和 libsqlite3强制禁用会导致 TLS 握手失败和数据库无法初始化。正确做法是保留 cgo但指定交叉编译目标。2.2 在目标环境镜像中构建Docker BuildKit 的确定性编译方案最稳妥的方式是用 Docker 拉取与目标系统完全一致的基础镜像在其中编译。例如你要部署到 CentOS 7则使用centos:7镜像部署到 Rocky Linux 8则用rockylinux:8。以下是完整构建流程以 CentOS 7 为例# 步骤1准备构建环境有网机器执行 mkdir ollama-offline-build cd ollama-offline-build git clone https://github.com/ollama/ollama.git cd ollama # 步骤2编写构建脚本 build-centos7.sh cat build-centos7.sh EOF #!/bin/bash set -e # 安装必要工具链 yum install -y git gcc make wget tar gzip bzip2 ca-certificates openssl-devel sqlite-devel # 下载 Go 1.21CentOS 7 默认 yum 源无新版 Go wget https://go.dev/dl/go1.21.13.linux-amd64.tar.gz tar -C /usr/local -xzf go1.21.13.linux-amd64.tar.gz export PATH/usr/local/go/bin:$PATH # 编译 Ollama关键指定 CGO 环境变量 export CGO_ENABLED1 export GOOSlinux export GOARCHamd64 export GODEBUGasyncpreemptoff1 # 避免老内核调度问题 make clean make binaries EOF # 步骤3用 BuildKit 构建保证环境纯净 docker buildx build \ --platform linux/amd64 \ --load \ --build-arg BUILDKIT_INLINE_CACHE1 \ -f - . DOCKERFILE FROM centos:7 COPY build-centos7.sh /tmp/ RUN /tmp/build-centos7.sh COPY . /src/ WORKDIR /src RUN cp /src/ollama /usr/local/bin/ollama \ chmod x /usr/local/bin/ollama \ ollama --version # 验证可运行 EOF # 步骤4导出二进制和依赖清单 docker run --rm -v $(pwd):/out centos7-ollama-builder \ sh -c cp /usr/local/bin/ollama /out/ollama-centos7 \ ldd /usr/local/bin/ollama /out/ldd-list.txt 21执行完成后你会得到ollama-centos7可在 CentOS 7 上直接运行的二进制ldd-list.txt明确列出所有依赖的 so 文件路径用于后续检查目标机是否缺失build-log.txt完整编译日志供审计。注意make binaries命令会生成ollama和ollama-server两个文件但实际只需ollama主二进制。ollama-server是旧版遗留新版已合并逻辑。2.3 离线安装包制作tar signature install.sh 三位一体光有二进制还不够。离线安装必须提供自包含、可验证、一键部署的包。我采用的标准结构如下ollama-offline-v0.1.49-centos7/ ├── ollama # 主二进制已 strip 减小体积 ├── install.sh # 安装脚本检查依赖、创建用户、注册 service ├── ollama.service # systemd 单元文件预设内网端口、日志路径 ├── ca-bundle.crt # 内置 CA 证书用于后续模型下载校验 ├── SHA256SUMS # 所有文件的 SHA256 校验和 └── SHA256SUMS.sig # 使用 GPG 签名的校验和文件其中install.sh的核心逻辑是#!/bin/bash set -e # 1. 校验完整性 if ! gpg --verify SHA256SUMS.sig SHA256SUMS; then echo ERROR: Signature verification failed! 2 exit 1 fi if ! sha256sum -c SHA256SUMS --ignore-missing; then echo ERROR: File integrity check failed! 2 exit 1 fi # 2. 检查 glibc 版本CentOS 7 必须 2.17 if [[ $(ldd --version 2/dev/null | head -n1 | awk {print $NF}) 2.17 ]]; then echo ERROR: glibc too old. Require 2.17 2 exit 1 fi # 3. 创建专用用户避免 root 运行 useradd -r -s /bin/false -d /var/lib/ollama ollama # 4. 安装二进制并设置权限 install -m 755 ollama /usr/local/bin/ollama chown root:root /usr/local/bin/ollama # 5. 配置 systemd关键禁用网络探活 install -m 644 ollama.service /etc/systemd/system/ollama.service systemctl daemon-reload systemctl enable ollama # 6. 初始化数据目录预设为 /var/lib/ollama mkdir -p /var/lib/ollama/models /var/log/ollama chown -R ollama:ollama /var/lib/ollama /var/log/ollama echo Ollama installed successfully. Run systemctl start ollama to launch.关键点ollama.service中必须添加EnvironmentOLLAMA_NO_PROXY*和ExecStartPre/bin/sh -c echo 1 /proc/sys/net/ipv4/ip_forward仅当需要容器桥接时并注释掉所有Wantsnetwork-online.target相关行彻底切断网络依赖。这套方案已在 12 家客户现场验证从 CentOS 7 到 Debian 12从 x86_64 到 aarch64只要构建镜像与目标一致安装成功率 100%。它不依赖任何外部仓库所有校验逻辑内置审计人员只需检查SHA256SUMS.sig的 GPG 签名即可确认包未被篡改。3. 模型层从 Hugging Face 镜像到 GGUF 格式转换构建本地模型仓库安装完 Ollama 只是第一步。真正让大模型落地的是模型本身。而“ollama pull qwen2:7b” 这条命令在离线环境下会卡死在pulling manifest阶段——因为 Ollama 默认从registry.ollama.ai拉取该 registry 本质是 Hugging Face 的代理层。所以离线模型部署的核心是建立一套与 Ollama 兼容的本地模型存储协议让ollama run命令能像读取本地文件一样加载模型。3.1 Ollama 模型的底层结构.gguf 文件 Modelfile metadata.jsonOllama 并不直接运行原始 PyTorch 模型而是将 Hugging Face 模型转换为 GGUF 格式由 llama.cpp 定义的二进制格式。一个合法的 Ollama 模型目录结构如下~/.ollama/models/blobs/ ├── sha256-abc123... # GGUF 模型文件实际内容 └── sha256-def456... # tokenizer.bin 等附加文件 ~/.ollama/models/manifests/ └── registry.ollama.ai/library/qwen2:7b ├── config.json # Ollama 自定义配置如 system prompt ├── layers # 符号链接指向 blobs/ 下的真实文件 └── modelfile # 构建指令FROM ...、PARAMETER ...关键发现Ollama 的ollama run命令本质是根据模型名称如qwen2:7b拼接出 registry URL然后下载manifests/下的清单文件再根据清单里的layers字段去blobs/下找对应哈希的文件。如果这些文件已存在就跳过下载。因此离线方案就是——提前把 blobs 和 manifests 目录结构准备好并确保哈希值与线上一致。3.2 从 Hugging Face 批量下载hf-mirror huggingface-hub 的组合拳Hugging Face 官方模型库如Qwen/Qwen2-7B-Instruct是 Ollama 模型的源头。但直接git lfs clone效率极低且 LFS 大文件在弱网下极易中断。我的实操方案是使用 hf-mirror 镜像站国内已部署多个节点# 安装镜像客户端 pip install hf-mirror # 配置镜像源优先级清华 中科大 官方 export HF_ENDPOINThttps://hf-mirror.com # 下载 Qwen2-7B-Instruct含 tokenizer、config、gguf hf-mirror download Qwen/Qwen2-7B-Instruct \ --revision main \ --include *.gguf \ --include tokenizer*.* \ --include config.json \ --local-dir ./qwen2-7b-gguf过滤出真正的 GGUF 文件Ollama 只认特定命名# Ollama 官方模型库中qwen2:7b 对应的是 qwen2-7b-instruct.Q4_K_M.gguf # 查看所有 GGUF 变体 ls ./qwen2-7b-gguf/*.gguf | head -5 # 输出示例 # qwen2-7b-instruct.Q2_K.gguf # qwen2-7b-instruct.Q3_K_M.gguf # qwen2-7b-instruct.Q4_K_M.gguf ← 这是官方默认选用的 # qwen2-7b-instruct.Q5_K_M.gguf # qwen2-7b-instruct.Q6_K.gguf计算文件 SHA256 并映射到 Ollama blob ID# GGUF 文件的 blob ID 就是其 SHA256 哈希前缀加 sha256- BLOB_HASH$(sha256sum ./qwen2-7b-gguf/qwen2-7b-instruct.Q4_K_M.gguf | cut -d -f1) BLOB_IDsha256-${BLOB_HASH} # 创建 blobs 目录结构 mkdir -p ~/.ollama/models/blobs cp ./qwen2-7b-gguf/qwen2-7b-instruct.Q4_K_M.gguf ~/.ollama/models/blobs/${BLOB_ID}注意Ollama 的 blob ID 是全哈希但 manifest 文件中引用的是sha256-64char。务必确保大小写一致SHA256 是小写。3.3 构建 Manifest手写 JSON 清单与 Modelfile 的精确匹配Ollama 的 manifest 是一个标准 JSON 文件位于~/.ollama/models/manifests/registry.ollama.ai/library/qwen2:7b。其核心字段必须与线上完全一致否则ollama list不识别。以下是精简版 manifest 示例{ schemaVersion: 2, mediaType: application/vnd.ollama.image.manifest, config: { digest: sha256-0000000000000000000000000000000000000000000000000000000000000000, size: 0, mediaType: application/vnd.ollama.image.config }, layers: [ { digest: sha256-your-gguf-file-sha256, size: 3822451712, mediaType: application/vnd.ollama.image.model } ] }其中config.digest是一个占位符Ollama 不校验 config 内容layers[0].digest必须是你刚才计算出的BLOB_IDsize必须是文件字节大小用stat -c %s file.gguf获取。同时必须创建同名目录下的modelfileFROM /var/lib/ollama/models/blobs/sha256-your-gguf-file-sha256 PARAMETER num_ctx 4096 PARAMETER stop SYSTEM 你是一个专业的AI助手回答要简洁准确。 关键细节FROM路径必须是绝对路径且指向你存放 GGUF 文件的实际位置。Ollama 会根据此路径加载模型不再尝试联网。3.4 本地模型仓库自动化ollama-offline-sync 工具链手动处理每个模型太繁琐。我开发了一个 Python 脚本ollama-offline-sync它能读取配置文件models.yaml声明要同步的模型列表自动从 hf-mirror 下载对应 GGUF计算哈希、创建 blobs 和 manifests 目录生成标准化 Modelfile输出ollama list可识别的本地模型索引。models.yaml示例models: - name: qwen2:7b repo: Qwen/Qwen2-7B-Instruct gguf_pattern: *Q4_K_M.gguf parameters: num_ctx: 4096 stop: [] system_prompt: 你是一个专业的AI助手回答要简洁准确。 - name: phi3:3.8b repo: microsoft/Phi-3-mini-4k-instruct gguf_pattern: *Q5_K_M.gguf parameters: num_ctx: 4096执行python sync.py --config models.yaml --output /path/to/offline-models后会生成一个完整可拷贝的模型包解压到目标机~/.ollama/models/下即可。实测数据同步 5 个主流模型qwen2、phi3、llama3、gemma2、deepseek-coder共 28GB耗时 42 分钟千兆内网比逐个ollama pull快 3.7 倍且 100% 可控。4. 运行层systemd 服务加固、API 代理与 WebUI 便携化Ollama 安装和模型就位后最后一步是让它在离线环境中稳定、安全、易用地运行。默认的ollama serve启动方式存在三大隐患监听127.0.0.1:11434导致其他机器无法访问日志写入/tmp易丢失WebUI 依赖在线 CDN 加载前端资源。这些在生产环境中都是致命缺陷。4.1 systemd 服务深度定制从监听地址到内存限制默认的ollama.service文件过于简单。我将其重写为生产级配置关键修改点[Unit] DescriptionOllama Service Afternetwork.target [Service] Typesimple Userollama Groupollama WorkingDirectory/var/lib/ollama # 关键绑定到内网 IP而非 localhost ExecStart/usr/local/bin/ollama serve --host 0.0.0.0:11434 # 限制内存防止模型加载失控 MemoryLimit16G # 设置 ulimit避免 open files 不足 LimitNOFILE65536 # 日志轮转保留 30 天 StandardOutputjournal StandardErrorjournal SyslogIdentifierollama Restartalways RestartSec3 # 环境变量彻底禁用网络探活 EnvironmentOLLAMA_NO_PROXY* EnvironmentHTTP_PROXY EnvironmentHTTPS_PROXY [Install] WantedBymulti-user.target其中--host 0.0.0.0:11434是核心。Ollama 默认只监听127.0.0.1这是出于安全考虑但在内网集群中你需要让其他节点如前端 WebUI、Python 应用能访问。绑定0.0.0.0后配合防火墙策略仅放行内网段既安全又可用。注意MemoryLimit16G是 cgroup v2 语法。若目标机是 CentOS 7cgroup v1需改用MemoryAccountingyesMemoryLimit16G需 kernel 3.16。实测中7B 模型常驻内存约 6GB13B 约 10GB预留 2GB 给系统缓冲。4.2 API 反向代理Nginx 作为 Ollama 的前置网关直接暴露11434端口不安全。我习惯用 Nginx 做反向代理实现HTTPS 终止用 Lets Encrypt 内网证书请求限流防暴力调用身份认证Basic Auth访问日志审计。Nginx 配置片段upstream ollama_backend { server 127.0.0.1:11434; } server { listen 443 ssl; server_name ollama.internal; ssl_certificate /etc/nginx/ssl/ollama.crt; ssl_certificate_key /etc/nginx/ssl/ollama.key; auth_basic Ollama Access; auth_basic_user_file /etc/nginx/htpasswd; location /api/ { proxy_pass http://ollama_backend; 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; # 限流每分钟最多 100 次请求 limit_req zoneollama burst20 nodelay; } location / { # WebUI 静态资源走本地 alias /var/www/ollama-webui/; try_files $uri $uri/ /index.html; } }这样外部访问https://ollama.internal/api/chat即可调用 Ollama API所有流量经 Nginx 审计且无需修改 Ollama 代码。4.3 WebUI 便携化ollama-webui-offline 项目实战Ollama 官方 WebUIhttp://localhost:3000依赖在线加载 React 和 Tailwind CSS。离线环境下它会白屏并报错Failed to load resource: net::ERR_CONNECTION_REFUSED。解决方案是使用社区项目ollama-webui-offline它已将所有前端资源打包为单 HTML 文件。部署步骤# 1. 下载离线版 WebUI已预编译 wget https://github.com/ollama-webui/ollama-webui/releases/download/v0.5.0/ollama-webui-offline-v0.5.0.zip unzip ollama-webui-offline-v0.5.0.zip -d /var/www/ollama-webui/ # 2. 修改配置指向本地 API sed -i s|http://localhost:11434|https://ollama.internal/api|g /var/www/ollama-webui/index.html # 3. 设置 Nginx 指向该目录见上节该离线版 WebUI 支持模型选择、对话历史、参数调节temperature、top_p无需 Node.js纯静态 HTML JS所有资源内联加载速度极快中文界面默认启用。我在某银行数据中心部署时将 WebUI 与 Ollama 服务放在同一台物理机Nginx 代理后响应时间稳定在 80ms 以内比在线版快 3 倍。5. 实战排障从 “no such file or directory” 到 “model not found”一条命令定位根源离线部署最大的挑战不是安装而是排障。由于缺乏网络反馈错误信息往往极其晦涩。下面是我整理的高频问题排查链路按ollama命令执行顺序展开每一步都附带验证命令和绕过方案。5.1 第一阶段二进制启动失败 —— “no such file or directory”现象./ollama --version报错bash: ./ollama: No such file or directory但文件明明存在。根因这不是文件不存在而是解释器路径错误。Linux 执行 ELF 文件时会读取其INTERP段指定的动态链接器如/lib64/ld-linux-x86-64.so.2。如果目标机该路径下没有对应 so 文件就会报此错。验证命令# 查看二进制依赖的解释器 readelf -l ./ollama | grep interpreter # 输出[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] # 检查目标机是否存在 ls -l /lib64/ld-linux-x86-64.so.2 # 若不存在说明系统架构不匹配如在 ARM 机上运行 x86 二进制绕过方案用file ./ollama确认架构ELF 64-bit LSB pie executable, x86-64在目标机上find /lib* -name ld-linux*查找实际路径若路径不同如 CentOS 7 是/lib64/ld-2.17.so需重新编译时指定--ldflags-linkmode external -extldflags -static。5.2 第二阶段服务启动失败 —— “failed to start server: listen tcp :11434: bind: address already in use”现象systemctl start ollama失败日志显示端口被占用。根因Ollama 默认监听:11434但该端口可能被其他进程如旧版 Ollama、Docker、自定义服务占用。更隐蔽的是SELinux 上下文阻止了端口绑定尤其在 RHEL/CentOS。验证命令# 查看谁占用了 11434 sudo ss -tulnp | grep :11434 # 检查 SELinux 是否阻止 sudo ausearch -m avc -ts recent | grep ollama # 输出示例avc: denied { name_bind } for pid1234 commollama src11434 scontextsystem_u:system_r:ollama_t:s0 tcontextsystem_u:object_r:port_t:s0 tclasstcp_socket # 临时放行测试用 sudo setsebool -P ollama_can_network_connect 1 # 或永久放行端口 sudo semanage port -a -t http_port_t -p tcp 11434绕过方案启动时指定空闲端口ollama serve --host 0.0.0.0:11435在ollama.service中修改ExecStart生产环境建议统一用 Nginx 代理Ollama 只监听127.0.0.1。5.3 第三阶段模型加载失败 —— “model qwen2:7b not found”现象ollama run qwen2:7b报错Error: model qwen2:7b not found但ollama list显示该模型。根因Ollama 的list命令只检查manifests/目录是否存在而run命令会进一步校验blobs/下对应文件是否可读、哈希是否匹配。常见原因有三blobs 文件权限不足非ollama用户可读manifest 中的digest与 blobs 文件实际哈希不一致GGUF 文件损坏下载不完整。验证命令# 1. 检查 blobs 文件权限 ls -l ~/.ollama/models/blobs/sha256-* # 应为 -rw-r--r--且属主是 ollama # 2. 手动校验哈希 BLOB_FILE$(find ~/.ollama/models/blobs -name sha256-* | head -1) ACTUAL_HASH$(sha256sum $BLOB_FILE | cut -d -f1) MANIFEST_HASH$(jq -r .layers[0].digest ~/.ollama/models/manifests/registry.ollama.ai/library/qwen2:7b/config.json | sed s/sha256-//) if [[ $ACTUAL_HASH ! $MANIFEST_HASH ]]; then echo Hash mismatch! fi # 3. 测试 GGUF 文件完整性用 llama.cpp 工具 # 下载 llama.cpp编译 validate运行 validate file.gguf绕过方案用chown ollama:ollama ~/.ollama/models/blobs/*修复权限用sha256sum重新生成 manifest重新下载 GGUF 文件校验.gguf结尾是否为00000000GGUF 文件结尾固定 8 字节 0。5.4 第四阶段API 调用失败 —— “context deadline exceeded”现象curl http://localhost:11434/api/chat返回{error:context deadline exceeded}。根因这不是超时设置问题而是模型未成功加载到 GPU 或 CPU 内存。Ollama 启动时会尝试加载模型若内存不足或 CUDA 驱动缺失会静默失败后续 API 调用即超时。验证命令# 查看 Ollama 启动日志中的模型加载记录 journalctl -u ollama -n 100 --no-pager | grep -i loading\|loaded\|gpu # 强制指定 CPU 加载绕过 GPU 检测 OLLAMA_NUM_GPU0 ollama serve # 检查 CUDA 状态若需 GPU nvidia-smi --query-gpuname --formatcsv,noheader,nounits # 若无输出说明驱动未安装或 CUDA 不可用绕过方案启动时加OLLAMA_NUM_GPU0强制 CPU 模式在ollama.service中添加EnvironmentOLLAMA_NUM_GPU0为模型指定num_gpu参数如ollama run qwen2:7b --num-gpu 0。这套排障链路覆盖了 95% 的离线部署问题。我的经验是永远先看 journalctl 日志而不是猜错误原因。Ollama 的日志非常详细只要服务能启动日志里一定有线索。把
