飞龙服务器离线部署Ollama全指南：ARM64+麒麟系统适配实战 1. 项目概述为什么在飞龙服务器上离线部署Ollama不是“选修课”而是必答题飞龙服务器——这个以飞腾CPU为心脏、银河麒麟操作系统为神经系统的国产化计算平台正快速铺进政务、金融、能源、军工等对数据主权和供应链安全有刚性要求的关键领域。我去年参与某省级政务云二期建设时客户明确提了一条铁律“所有AI能力模块必须在无外网连接的生产环境内完成全链路部署与验证不允许任何节点临时出网下载依赖。”这句话背后是真实存在的合规红线等保三级要求中关于“核心业务系统不得依赖不可控外部网络资源”的条款以及信创替代工程中“软硬件全栈自主、运行环境全程可控”的落地指标。而Ollama作为当前轻量级大模型本地化推理的事实标准工具其价值恰恰在于让Qwen、Llama、Gemma这类百亿参数模型能在单台服务器上以极低门槛跑起来。但它的默认安装逻辑——从GitHub Release拉二进制、从registry.ollama.ai拉模型层、自动更新CUDA驱动——在飞龙服务器的封闭网络里直接变成一条死路。你点开官网文档看到的第一行命令curl -fsSL https://ollama.com/install.sh | sh在内网服务器上执行后只会返回curl: (7) Failed to connect to ollama.com port 443: Network is unreachable。这不是技术故障是环境错配。所以“飞龙服务器麒麟系统Ollama离线部署”这个组合本质上是一套面向国产化封闭环境的AI能力交付SOP。它解决的不是“能不能跑”而是“如何在政策合规、网络隔离、硬件异构的三重约束下把一个开源AI工具变成可审计、可复现、可运维的生产级组件”。适合谁不是给个人开发者写博客用的而是给信创集成商的实施工程师、政企IT部门的系统管理员、以及国产化替代项目中的AI能力交付负责人。他们需要的不是“Hello World”而是一份能直接打印出来贴在机房墙上、让新来的同事照着步骤操作两小时就能让ollama run qwen2:1.5b成功返回响应的实操手册。这背后涉及的是飞腾CPU的ARM64指令集适配、麒麟系统特有的glibc版本锁、离线YUM源的构建逻辑、模型文件的分层校验机制以及最关键的——如何绕过Ollama官方安装脚本里那些“不联网就活不成”的硬编码检查。接下来的内容就是我把这套方案在三个不同客户现场踩坑、填坑、再优化后的完整复盘。2. 整体设计思路为什么必须放弃“一键安装”转而构建“四层离线包体系”在飞龙服务器上做Ollama离线部署最危险的思维陷阱就是试图把外网环境下的“curl | sh”流程简单平移过来。我第一次尝试时就是把官网install.sh脚本下载下来手动替换了里面的URL地址结果在/usr/bin/ollama二进制文件校验环节直接失败——因为脚本里嵌了一个硬编码的SHA256哈希值而这个值只对应官方编译的x86_64版本飞腾的ARM64版哈希完全不同。这让我意识到离线部署的本质不是“断网版安装”而是“重构交付单元”。我们最终采用的是“四层离线包体系”每一层都解决一个不可妥协的约束2.1 第一层基础运行时离线包解决“能不能启动”的问题核心矛盾在于Ollama不是一个纯Go二进制它重度依赖系统级组件。飞腾CPU运行的是ARM64架构而麒麟V10 SP1主流版本默认搭载的glibc是2.28但Ollama官方ARM64二进制要求glibc≥2.31。直接升级glibc这是Linux系统的“心脏移植”99%会导致系统崩溃。我们的解法是不升级系统而是降级Ollama。通过反向追踪Ollama的Go编译链我们发现v0.1.32版本是最后一个使用Go 1.21.6编译的版本该版本生成的二进制对glibc的最低要求恰好是2.28。于是第一层包的核心内容就是ollama-v0.1.32-linux-arm64二进制文件 libcuda.so.1从NVIDIA官网下载的ARM64兼容版注意不是x86_64的libnvidia-ml.so.1同理。这里有个关键细节飞龙服务器的GPU驱动通常由厂商预装但Ollama需要的是CUDA用户态库而非内核驱动。我们实测发现直接拷贝/usr/lib/aarch64-linux-gnu/libcuda.so.1过去会报version GLIBCXX_3.4.29 not found因为麒麟系统自带的libstdc太老。最终方案是从CentOS Stream 8的ARM64镜像里提取libstdc.so.6.0.28并创建软链接libstdc.so.6 - libstdc.so.6.0.28放在Ollama同目录下。这样ldd ./ollama显示的所有依赖项都能被正确解析。2.2 第二层系统服务离线包解决“能不能常驻”的问题麒麟系统使用systemd但Ollama官方提供的ollama.service文件里有一行ExecStartPre/bin/sh -c mkdir -p /var/lib/ollama这在离线环境下没问题真正致命的是RestartSec10和StartLimitIntervalSec60的组合——当Ollama因模型加载失败而崩溃时systemd会在60秒内尝试重启10次然后彻底放弃。而离线环境下的首次启动失败90%是因为模型路径配置错误或权限问题。我们的改造是将StartLimitIntervalSec改为0禁用启动限制并在ExecStart前增加一个预检脚本/usr/local/bin/ollama-precheck.sh内容只有三行检查/var/lib/ollama目录是否存在且属主为ollama用户检查/etc/ollama/下是否有config.json检查/usr/bin/ollama是否具有x权限。这个脚本的退出码直接决定service是否启动把模糊的“启动失败”变成了清晰的“哪一步没准备好”。2.3 第三层模型仓库离线包解决“有没有模型跑”的问题这是最容易被低估的一层。“离线下载模型”不是简单地把.gguf文件拷过去。Ollama的模型存储结构是分层的/var/lib/ollama/models/blobs/下存放的是SHA256哈希命名的原始模型层如sha256-abc123...而/var/lib/ollama/models/manifests/下存放的是JSON格式的清单文件记录了这些层如何组装成一个逻辑模型如qwen2:1.5b。如果只是把qwen2:1.5b.Q4_K_M.gguf文件丢进blobs目录Ollama根本识别不了。正确做法是在外网机器上用ollama pull qwen2:1.5b完整拉取一次然后打包整个/var/lib/ollama/models/目录。但这里有个坑manifests里的JSON文件包含绝对路径和时间戳直接拷贝到内网服务器会导致ollama list不显示模型。解决方案是用Python脚本遍历所有manifest文件将其中的created_at字段统一替换为当前时间戳并将rootfs.diff_ids数组里的哈希值全部映射为内网服务器上实际blobs文件的SHA256值用sha256sum重新计算。这个脚本我们命名为fix-manifests.py它成了离线包制作流水线里的关键一环。2.4 第四层运维支撑离线包解决“好不好维护”的问题交付给客户的不能只是一个能跑的程序而是一套可诊断、可回滚、可审计的运维体系。这一层包含ollama-healthcheck.sh检查端口、磁盘空间、GPU显存占用ollama-rollback.sh一键回退到上一个已知稳定版本的二进制和模型ollama-audit.log模板记录每次ollama run的模型名、参数、耗时、显存峰值以及最重要的ollama-firewall-config.sh——因为麒麟系统默认启用firewalld而Ollama监听的11434端口必须放行。这个脚本不是简单地firewall-cmd --add-port11434/tcp而是先检查当前zone通常是public再用--permanent参数持久化规则最后firewall-cmd --reload。我们曾在一个客户现场遇到过临时放行端口后服务器重启firewalld恢复默认策略导致所有AI服务中断。这个教训被固化进了第四层包。提示四层离线包不是四个独立ZIP而是一个带版本号的tar.gz解压后结构清晰runtime/、service/、models/、tools/。每个目录下都有README.md用最简语言说明“这个目录里有什么”、“必须放在哪里”、“执行什么命令生效”。这是给一线实施人员的“防呆设计”。3. 核心细节解析与实操要点飞腾CPU与麒麟系统的五个致命兼容点在飞龙服务器上部署Ollama最大的挑战从来不是功能实现而是那些藏在系统底层、文档里绝不会写的“隐性兼容点”。这些点往往让一个在外网测试完美的方案在内网服务器上启动即崩溃。以下是我在三个项目中反复验证、最终形成标准化处理流程的五个关键细节3.1 飞腾CPU的浮点运算单元FPU与GGUF量化格式的冲突Qwen2、Llama3等主流模型的GGUF文件普遍采用Q4_K_M或Q5_K_M量化方式。这种量化依赖于x86_64 CPU的AVX2指令集进行高效解压。飞腾CPU如D2000、S5000虽然支持ARMv8.2的FP16指令但GGUF解压库llama.cpp的默认ARM64编译版本并未启用针对飞腾FPU的深度优化。结果就是ollama run qwen2:1.5b能启动但首token生成时间长达47秒而同样配置的x86_64服务器只要1.2秒。解决方案不是换模型而是重编译llama.cpp。我们从llama.cpp的GitHub仓库拉取v1.22.0 tag修改CMakeLists.txt在set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -marcharmv8.2-afp16)后追加-mfpuneon-fp-armv8并确保LLAMA_ACCELERATE选项开启。编译出的libllama.so替换Ollama源码中/vendor/github.com/ollama/ollama/llm目录下的同名文件再重新构建Ollama ARM64二进制。实测首token时间降至3.8秒完全可用。这个过程耗时约2小时但换来的是性能的质变。3.2 麒麟系统SELinux策略与Ollama模型目录的权限死锁银河麒麟V10默认启用SELinux且策略级别为targeted。当Ollama以ollama用户身份尝试读取/var/lib/ollama/models/blobs/下的模型文件时SELinux会拦截并记录avc: denied { read } for pid1234 commollama namesha256-abc... devdm-0 ino56789 scontextsystem_u:system_r:ollama_t:s0 tcontextunconfined_u:object_r:default_t:s0 tclassfile。这不是简单的chmod 755能解决的因为default_t上下文是SELinux的默认标签对敏感目录无效。标准解法是semanage fcontext -a -t ollama_var_lib_t /var/lib/ollama(/.*)?然后restorecon -Rv /var/lib/ollama。但问题在于ollama_var_lib_t这个类型在麒麟系统的SELinux策略包里并不存在。我们的实操方案是导出现有策略sestatus -v /tmp/sestatus.log找到ollama_t相关的规则用audit2allow -a -M ollama_custom生成自定义策略模块再semodule -i ollama_custom.pp。这个模块的核心就一行allow ollama_t default_t:file { read open getattr };。它精准地放行了Ollama进程对default_t标签文件的读取权限而不影响其他服务的安全策略。3.3 麒麟系统内核参数与大模型内存分配的临界点飞龙服务器的内存配置通常为64GB或128GB看似充裕但Ollama加载一个7B参数的Qwen2模型Q4_K_M量化实际需要约5.2GB显存3.8GB系统内存。问题出在麒麟系统的vm.swappiness默认值是60这意味着内核会非常积极地把进程内存页交换到swap分区。而大模型的权重矩阵是连续的大块内存频繁swap会导致page fault飙升ollama run命令卡在loading model阶段长达数分钟。我们实测发现将vm.swappiness设为1echo 1 /proc/sys/vm/swappiness并永久写入/etc/sysctl.conf能让模型加载时间从3分42秒缩短到18秒。但这还不够因为飞龙服务器的NUMA节点布局特殊——CPU和GPU内存可能位于不同NUMA节点。我们通过numactl --hardware确认后强制Ollama进程绑定到GPU所在的NUMA节点numactl --cpunodebind0 --membind0 /usr/bin/ollama serve。这步操作让显存访问延迟降低了40%是性能调优的隐藏王牌。3.4 麒麟系统防火墙与Ollama API端口的“隐形拦截”很多工程师会忽略一点麒麟系统的firewalld不仅管理网络端口还管理iptables规则链。Ollama的API默认监听127.0.0.1:11434这看起来是本地回环无需放行。但当你用curl http://localhost:11434/api/tags测试时却返回Connection refused。原因在于麒麟系统启用了iptables的INPUT链默认DROP策略而127.0.0.1流量依然要经过INPUT链。firewall-cmd --list-all显示ports: []让人误以为没拦截。真相是iptables -L INPUT -n会显示一条REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited。解决方案不是关掉firewalld违反安全基线而是添加一条精确规则iptables -I INPUT -p tcp -s 127.0.0.1 --dport 11434 -j ACCEPT并用iptables-save /etc/sysconfig/iptables持久化。这条规则必须插在REJECT规则之前否则无效。我们在交付文档里把这个操作称为“回环端口白名单加固”它比单纯firewall-cmd更底层、更可靠。3.5 麒麟系统字体渲染与Ollama Web UI的中文乱码Ollama自带的Web UI访问http://localhost:11434在麒麟系统上打开所有中文菜单、按钮、模型描述都显示为方框。这不是Ollama的问题而是麒麟系统缺少中文字体缓存。fc-list :langzh返回空证明中文字体未注册。麒麟系统自带的wqy-microhei.ttc字体文件在/usr/share/fonts/wenquanyi/但fontconfig没有扫描这个路径。标准修复是mkdir -p /etc/fonts/conf.d/创建10-wqy-microhei.conf内容为?xml version1.0? !DOCTYPE fontconfig SYSTEM fonts.dtd fontconfig dir/usr/share/fonts/wenquanyi//dir match targetpattern test qualany namefamilystringserif/string/test edit namefamily modeprepend bindingstrongstringWenQuanYi Micro Hei/string/edit /match /fontconfig然后执行fc-cache -fv。这个操作会让Ollama Web UI的中文字体渲染立刻恢复正常。我们把它做成tools/fix-fonts.sh作为离线包的“用户体验补丁”。注意以上五个点每一个都经过至少两次客户现场验证。它们不是理论推演而是血泪教训的结晶。比如第3.1点我们曾因未重编译llama.cpp在某市大数据局的演示现场让领导等待了整整47秒才看到第一个AI回复场面极其尴尬。从此重编译成为离线包制作的强制前置步骤。4. 实操过程与核心环节实现从外网准备到内网交付的完整流水线离线部署的成功80%取决于外网准备阶段的严谨性。一个疏忽就会让内网服务器上的两小时等待变成无意义的循环。以下是我们打磨出的、可100%复现的七步流水线每一步都附带关键命令、预期输出和避坑提示。4.1 步骤一外网环境初始化Windows电脑需安装WSL2 Ubuntu 22.04这是整个流程的起点也是最容易被跳过的一步。为什么必须用WSL2而不是纯Windows因为Ollama的模型拉取、manifest修正、二进制校验等操作高度依赖Linux shell工具链curl,jq,sha256sum,tar。在Windows CMD或PowerShell里模拟会遇到路径分隔符、换行符、权限模型等一系列兼容问题。操作在Windows上启用WSL2wsl --install安装Ubuntu 22.04wsl --install -d Ubuntu-22.04启动Ubuntu执行sudo apt update sudo apt install -y curl jq wget tar gzip关键检查运行uname -m必须输出x86_64。这是为了确保后续下载的ARM64二进制是在一个干净、无污染的环境中准备的。如果误用ARM64的WSL2如Windows on ARMcurl下载的二进制可能被自动转码导致哈希值错误。4.2 步骤二下载并验证Ollama ARM64二进制核心是获取正确的版本与哈希目标是获取ollama-v0.1.32-linux-arm64并验证其完整性。不能直接从GitHub Release页面下载因为那个页面的Download按钮指向的是CDN加速链接哈希值不稳定。操作# 创建工作目录 mkdir -p ~/ollama-offline cd ~/ollama-offline # 从GitHub API获取v0.1.32的Release信息 curl -s https://api.github.com/repos/ollama/ollama/releases/tags/v0.1.32 | \ jq -r .assets[] | select(.name ollama-linux-arm64) | .browser_download_url | \ xargs wget -O ollama-linux-arm64 # 下载官方发布的SHA256SUMS文件 curl -s https://github.com/ollama/ollama/releases/download/v0.1.32/SHA256SUMS | \ grep ollama-linux-arm64 | \ awk {print $1} expected-sha256.txt # 计算下载文件的SHA256 sha256sum ollama-linux-arm64 | awk {print $1} actual-sha256.txt # 比较 diff expected-sha256.txt actual-sha256.txt || echo 哈希校验失败预期输出diff命令无输出表示校验通过。如果失败说明下载被CDN劫持必须清空~/.wget-hsts并重试。4.3 步骤三构建离线模型仓库重点是manifest的“去外网化”这是最耗时也最关键的一步。目标是让ollama list在内网服务器上能正确显示模型。操作# 启动一个临时Ollama服务仅用于拉取模型 ./ollama-linux-arm64 serve sleep 5 # 拉取目标模型以qwen2:1.5b为例 ./ollama-linux-arm64 pull qwen2:1.5b # 停止临时服务 pkill -f ollama serve # 复制模型目录 cp -r ~/.ollama/models ./models-offline # 运行manifest修正脚本fix-manifests.py见下文 python3 fix-manifests.py ./models-offlinefix-manifests.py核心逻辑import os, json, hashlib, glob from pathlib import Path models_dir Path(./models-offline) blobs_dir models_dir / blobs manifests_dir models_dir / manifests for manifest_file in manifests_dir.rglob(*.json): with open(manifest_file, r) as f: data json.load(f) # 1. 更新created_at为当前时间 data[created_at] datetime.datetime.now(datetime.timezone.utc).isoformat() Z # 2. 修正diff_ids中的哈希值 for i, diff_id in enumerate(data.get(rootfs, {}).get(diff_ids, [])): # diff_id格式为 sha256:abc123... hash_part diff_id.split(:, 1)[1] blob_path blobs_dir / hash_part if blob_path.exists(): # 重新计算该blob的实际SHA256 with open(blob_path, rb) as f: actual_hash hashlib.sha256(f.read()).hexdigest() data[rootfs][diff_ids][i] fsha256:{actual_hash} # 写回 with open(manifest_file, w) as f: json.dump(data, f, indent2)避坑提示fix-manifests.py必须在models-offline目录的父目录下运行且blobs_dir路径必须与内网服务器上/var/lib/ollama/models/blobs/的路径一致。否则修正后的哈希值在内网服务器上找不到对应文件。4.4 步骤四制作四层离线包tar.gz的结构与压缩策略离线包不是简单打包而是有严格结构和压缩策略的交付物。操作# 创建标准目录结构 mkdir -p offline-pkg/{runtime,service,models,tools} # 复制二进制和依赖库 cp ollama-linux-arm64 offline-pkg/runtime/ollama cp /usr/lib/aarch64-linux-gnu/libcuda.so.1 offline-pkg/runtime/ cp /usr/lib/aarch64-linux-gnu/libnvidia-ml.so.1 offline-pkg/runtime/ cp libstdc.so.6.0.28 offline-pkg/runtime/ # 复制service文件 cp ollama.service offline-pkg/service/ cp ollama-precheck.sh offline-pkg/service/ # 复制模型 cp -r models-offline/* offline-pkg/models/ # 复制tools cp ollama-healthcheck.sh offline-pkg/tools/ cp ollama-rollback.sh offline-pkg/tools/ cp fix-fonts.sh offline-pkg/tools/ # 生成README cat offline-pkg/README.md EOF # 飞龙服务器Ollama离线部署包 v0.1.32 ## 使用说明 1. 将本包解压到内网服务器任意目录 2. 执行 sudo ./install.sh 3. 启动服务 sudo systemctl start ollama 4. 验证 curl http://localhost:11434/api/tags EOF # 最终打包使用gzip兼顾压缩率与解压速度 tar -czf ollama-flydragon-offline-v0.1.32.tar.gz offline-pkg/关键参数tar -czf中的z代表gzip压缩。我们测试过xz和zstd虽然压缩率更高但内网服务器尤其是老型号飞腾的CPU解压速度太慢tar -xJf可能耗时超过5分钟影响交付体验。gzip在压缩率约35%和解压速度之间取得了最佳平衡。4.5 步骤五内网服务器环境预检交付前的“最后一道闸门”在把离线包拷到客户服务器前必须执行一套预检脚本确保环境100%就绪。这个脚本叫precheck.sh它会输出一份清晰的“就绪报告”。precheck.sh核心内容#!/bin/bash echo 飞龙服务器Ollama离线部署预检报告 echo # 检查CPU架构 echo 1. CPU架构检查: ARCH$(uname -m) if [[ $ARCH aarch64 ]]; then echo ✅ 通过: 当前为ARM64架构 ($ARCH) else echo ❌ 失败: 非ARM64架构 ($ARCH)请确认是否为飞腾CPU服务器 exit 1 fi # 检查麒麟系统版本 echo -e \n2. 麒麟系统版本检查: KYLIN_VER$(cat /etc/os-release | grep VERSION_ID | cut -d -f2 | tr -d ) if [[ $KYLIN_VER 10* ]]; then echo ✅ 通过: 银河麒麟V10 (版本 $KYLIN_VER) else echo ❌ 失败: 非银河麒麟V10 (版本 $KYLIN_VER)不兼容 exit 1 fi # 检查glibc版本 echo -e \n3. glibc版本检查: GLIBC_VER$(ldd --version | head -1 | awk {print $NF}) if (( $(echo $GLIBC_VER 2.28 | bc -l) )); then echo ✅ 通过: glibc版本 $GLIBC_VER ≥ 2.28 else echo ❌ 失败: glibc版本 $GLIBC_VER 2.28需升级系统或更换Ollama版本 exit 1 fi # 检查GPU驱动 echo -e \n4. GPU驱动检查: if nvidia-smi -L /dev/null; then echo ✅ 通过: NVIDIA GPU驱动已加载 else echo ⚠️ 警告: 未检测到NVIDIA GPU驱动Ollama将降级为CPU模式性能大幅下降 fi echo -e \n 预检完成所有关键项均通过 交付动作将precheck.sh和ollama-flydragon-offline-v0.1.32.tar.gz一起拷贝到U盘交给客户IT。他们只需在服务器上运行bash precheck.sh看到“所有关键项均通过”就可以放心进行下一步安装。4.6 步骤六内网服务器一键安装install.sh的魔鬼细节install.sh是离线包的灵魂它必须做到“零交互、零失败、零残留”。install.sh核心逻辑精简版#!/bin/bash set -e # 任何命令失败立即退出 # 1. 解压离线包 tar -xzf ollama-flydragon-offline-v0.1.32.tar.gz # 2. 安装runtime cp offline-pkg/runtime/* /usr/bin/ chmod x /usr/bin/ollama chown root:root /usr/bin/ollama # 3. 安装service cp offline-pkg/service/ollama.service /etc/systemd/system/ cp offline-pkg/service/ollama-precheck.sh /usr/local/bin/ chmod x /usr/local/bin/ollama-precheck.sh # 4. 初始化模型目录 mkdir -p /var/lib/ollama/models cp -r offline-pkg/models/* /var/lib/ollama/models/ chown -R ollama:ollama /var/lib/ollama # 5. 应用SELinux策略 if command -v semodule /dev/null; then semodule -i offline-pkg/tools/ollama_custom.pp 2/dev/null || true fi # 6. 加载防火墙规则 iptables-restore offline-pkg/tools/iptables-rules.v4 # 7. 启动服务 systemctl daemon-reload systemctl enable ollama systemctl start ollama # 8. 输出成功信息 echo ✅ Ollama离线部署成功 echo 模型列表: ollama list echo 测试API: curl http://localhost:11434/api/tags echo Web UI: http://$(hostname -I | awk {print $1}):11434魔鬼细节set -e确保任何一步失败脚本立即停止避免留下半成品状态。chown -R ollama:ollama必须在systemctl start之前执行否则Ollama进程因权限不足无法读取模型。iptables-restore使用的iptables-rules.v4文件是在外网准备阶段用iptables-save iptables-rules.v4生成的它包含了那条关键的ACCEPT回环规则。4.7 步骤七交付后验证与客户培训让能力真正落地安装完成只是开始。我们坚持“交付即培训”给客户IT提供一份《Ollama日常运维速查表》里面全是实战场景场景命令说明查看Ollama服务状态systemctl status ollama -l-l参数显示完整日志便于排查启动失败原因查看GPU显存占用nvidia-smi --query-compute-appspid,used_memory --formatcsv,noheader,nounits精确监控Ollama进程的显存消耗卸载一个模型ollama rm qwen2:1.5b释放磁盘空间注意此操作不可逆强制重载模型热更新ollama serve 当ollama run卡住时杀死旧进程并重启serve导出模型为GGUF文件ollama show qwen2:1.5b --modelfile | grep FROM用于模型二次开发或跨平台迁移这张表被打印成A4纸贴在客户机房的服务器机柜上。它让客户IT无需翻阅长篇文档3秒内就能找到解决问题的命令。5. 常见问题与排查技巧实录来自三个客户现场的“血泪问题库”在交付过程中我们收集了超过47个真实问题。以下是最具代表性、最高频、也最容易被官方文档忽略的六个问题每一个都附带了“现象-根因-三步解决法”的完整排查路径。5.1 问题一ollama list为空但/var/lib/ollama/models/目录下明明有文件现象客户执行ollama list输出为空检查/var/lib/ollama/models/blobs/和manifests/目录都存在且文件大小正常。根因分析这是manifest修正不彻底的典型表现。manifests/目录下的JSON文件其rootfs.diff_ids数组里引用的哈希值与blobs/目录下实际文件的SHA256值不匹配。Ollama在启动时会遍历所有manifest对每个diff_id计算SHA256如果找不到对应文件或哈希不匹配就直接跳过这个manifest导致模型不显示。三步解决法定位问题manifestcd /var/lib/ollama/models/manifests ls -la找到最近修改的JSON文件。提取diff_idjq -r .rootfs.diff_ids[0] problem-manifest.json得到类似sha256:abc123...的字符串。验证文件存在性cd /var/lib/ollama/models/blobs ls -la | grep abc123。如果无输出说明文件缺失如果有输出运行sha256sum abc123...将结果与manifest里的diff_id对比。不一致则用fix-manifests.py重新修正。实操心得我们后来在install.sh末尾增加了自动校验步骤find /var/lib/ollama/models/manifests -name *.json -exec jq -r .rootfs.diff_ids[] {} \; 2/dev/null | while read id; do hash\${id#sha256:}; [ -f /var/lib/ollama/models/blobs/\$hash ] || echo MISSING: \$hash; done。这个命令会直接列出所有缺失的blob哈希一目了然。5.2 问题