简介：面向银河麒麟V10操作系统用户，提供一套在离线环境下部署deepseek大语言模型服务的完整操作指南。内容涵盖硬件与系统环境检查、ollama安装及系统服务配置、环境变量与模型存储路径设置、deepseek-r1模型离线获取与导入方法，以及chatbox客户端安装、桌面快捷方式创建和交互配置，并附有远程访问模型服务的说明。资源为docx格式文档（1个文件，压缩包约2.69MB），文字步骤清晰，适合在无互联网连接的国产化环境中需要本地部署AI服务的运维与技术人员参考。当前已有5532人学习使用，文档中结合了作者在飞腾FT-2000处理器上的实际部署经验，对命令操作、权限配置、服务状态验证等关键环节均有详细记录，可帮助读者规避常见坑点，快速完成ollama与deepseek的离线落地。
1. 银河麒麟V10离线部署DeepSeek：无显卡的FT-2000 ARM机器也能跑14B模型
把 DeepSeek 跑在银河麒麟 V10 的 FT-2000 机器上，而且是在完全离线、没有显卡的环境里，这件事听起来挺反直觉——14B 模型在 ARM CPU 上推理，速度不敢恭维，但作为内网问答助手，完全够用。我拿到一份完整的离线安装记录，从 ollama 0.5.7 的解压部署、systemd 服务化，到 deepseek-r1:14b 蒸馏模型的离线导入，再到 Chatbox 客户端和远程访问，每一步都落到了具体命令上。这份指南适合两类人：一类是要在国产化终端上做 AI 能力演示的交付工程师，另一类是内网环境里想自建私有大模型问答服务的运维。全文默认无显卡，纯 CPU 推理方案，不涉及显卡加速配置。
2. 离线安装ollama：目录规划、系统服务与环境变量三板斧
2.1 选型逻辑：为什么是 ollama 而不是裸跑 Python 推理
在国产化机器上部署大模型，路径有好几条：用 Transformers 写 Python 脚本、用 llama.cpp 量化版直接跑、或者用 ollama 这种带 API 的服务框架。我一般劝后来者直接选 ollama，理由有三个。
第一，模型管理。ollama 自带模型仓库机制，ollama list、ollama pull 这些命令把模型的下载、导入、删除都收拢成一条命令，不用自己维护散落的 GGUF 文件和 tokenizer。第二，接口统一。它暴露 /api/generate、/api/chat 标准 HTTP 接口，Chatbox 这类桌面客户端直接对接，不用自己写 Web 服务包装一层。第三，systemd 集成简单。服务文件写好后，开机自启、崩溃重启、日志查看都是系统级能力，比 nohup 挂后台稳得多。
这台机器的处理器是 FT-2000，ARMv8 架构，系统是麒麟 V10 SP1 的 ARM64 版本。ollama 官方对 Linux ARM64 提供 tgz 包，下载文件名是 ollama-linux-arm64.tgz，对应 0.5.7 版本。tgz 包不需要编译，解压即用，这在内网离线环境里是最大优势——不用碰编译器、不用解决构建依赖。
2.2 目录规划与官方 tgz 解压
目录规划沿用原方案的 /opt/deepseek 作为总目录，理由有两个：一是干净统一，ollama、模型、Chatbox 全收在一个父目录下，备份时直接打包 /opt/deepseek 即可；二是后续写 systemd 服务路径时不容易出错。
先创建目标目录并解压：
cd /opt/deepseek mkdir ollama tar -C /opt/deepseek/ollama -xzf ollama-linux-arm64.tgztar 的 -C 参数指定解压目标目录，/opt/deepseek/ollama 必须提前创建。解压后检查核心二进制：
ls -l /opt/deepseek/ollama/bin/正常情况下会看到 ollama 可执行文件。tgz 包解压出来的目录结构已经排好，bin 下就是主程序，不需要额外配置动态库路径。这里有个细节：解压前先确认目标目录是空的，否则 tar 在覆盖同名文件时会逐个询问，离线操作时容易卡住。
2.3 用专用用户跑服务：ollama 用户与权限
服务用什么用户跑，很多人图省事直接用 root。这里不推荐：ollama 的模型管理逻辑会在 OLLAMA_MODELS 目录下做 sha256 校验和层合并，用 root 跑一旦出问题权限边界就没了。原方案单独创建了 ollama 系统用户，我照做了。
sudo useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama sudo usermod -a -G ollama $(whoami)第一条命令的含义逐项拆解：-r 表示创建系统账户，-s /bin/false 禁止该用户登录，-U 同时创建同名用户组，-m 和 -d 指定家目录为 /usr/share/ollama。第二条命令把当前执行用户加入 ollama 组，这样你在调试模型目录时不会频繁遇到 Permission denied。
要注意的是，真正运行服务的是 ollama 用户，当前用户加组只是为了看模型文件方便。如果后续发现模型目录无法读取，优先检查目录属主，而不是直接 chmod 777。
2.4 systemd 服务文件与环境变量的配合
服务化是整个部署里最关键的一环。机器重启后 ollama 不自己起来，前面全白做。原方案写的 /etc/systemd/system/ollama.service 我复现时只改了 ExecStart 路径，其他保持一致：
[Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/opt/deepseek/ollama/bin/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 EnvironmentFile=/opt/deepseek/ollama/ollama.conf [Install] WantedBy=default.targetEnvironmentFile 指向的环境变量文件必须提前创建，否则服务一启动就失败。内容如下：
OLLAMA_HOME=/opt/deepseek/ollama OLLAMA_MODELS="/opt/deepseek/ollama/models" OLLAMA_HOST="0.0.0.0" OLLAMA_ORIGINS="*" PATH=$OLLAMA_HOME/bin:$PATH四个变量分别管四件事：OLLAMA_HOME 是 ollama 的安装根目录；OLLAMA_MODELS 指定模型文件存放位置，这一点决定了模型导入后占用哪个目录；OLLAMA_HOST 设为 0.0.0.0 让服务监听所有网卡接口，这样局域网内其他机器才能访问，这也是后面远程连接的前提；OLLAMA_ORIGINS 设为 * 是为了放行跨域请求，Chatbox 这类 Web 技术栈客户端连不上时，多半就是这里没放宽。
写完两个文件后按顺序执行：
sudo chown -R ollama:ollama /opt/deepseek/ollama sudo systemctl daemon-reload sudo systemctl enable ollama sudo systemctl start ollama sudo systemctl status ollamachown 把整个 /opt/deepseek/ollama 的属主改成 ollama，防止服务写入模型文件时越权失败。daemon-reload 在每次修改 service 文件后是必做项，忘记重载会让修改不生效。status 输出里看到 active (running)，说明服务起来了；日志里 [GIN-debug] 开头的路由注册信息，看到 /api/tags、/api/version 就说明 API 服务已经注册完成。
3. 离线模型导入：从联网机器搬运 deepseek-r1 到内网机的完整路径
3.1 为什么必须在同架构联网机器上准备
离线导入模型这件事，看起来就是把模型文件拷贝过来，但里面有一个容易翻车的细节：架构一致性。
ollama 的模型文件本质上是 GGUF 格式，这种格式本身不区分 CPU 架构，推理时才需要编译对应架构的内核。但 ollama pull 下载下来的目录结构里，除了 GGUF 文件，还有 manifest 和按 sha256 命名的分层数据。联网机器上执行 ollama show --modelfile 导出的 modelfile.txt，其中有 FROM 字段指向一个本地路径。在准备机上操作时这个路径很正常，一旦把 modelfile 拷到另一台机器，路径就失效了。
我见过有人在 x86 的联网机上导出 modelfile，再把 gguf 拷到 ARM 目标机，ollama create 时报各种文件不存在。原方案里特别强调"在同架构联网机器上安装 ollama"，这行字背后就是这段血泪经验。所以准备机的要求是：与目标机同为 ARM64 架构、能联网、安装同一版本或相近版本的 ollama。
3.2 拉取模型并导出 modelfile 与 gguf
在联网准备机上执行：
ollama pull deepseek-r1:14b这个命令从 ollama 官方模型仓库拉取 deepseek-r1 的 14B 版本。模型下来后，用 show 命令导出它的构成：
ollama show --modelfile deepseek-r1:14b > modelfile.txt重定向到 modelfile.txt 后，打开它，重点看第 5 行附近的 FROM 字段。原方案里的经验是：FROM 后面指向的文件就是真正的模型权重文件。我把它单独复制出来，重命名为 deepseek-r1-14b.gguf，方便拷回内网后辨认。
cp /home/user/.ollama/models/blobs/sha256-xxx deepseek-r1-14b.gguf这里有个容易忽略的点：ollama 的模型存储目录里文件以 sha256 哈希命名，没有可读性，复制出来改名是方便后续手工确认。modelfile.txt 里的 FROM 路径先不用改，只要把 modelfile.txt 和 gguf 放在同一个传输目录里一起带走，到内网机上再改。
拉取完毕后用 ollama list 确认：
ollama list如果 NAME 列能看到 deepseek-r1:14b，说明模型在准备机上已经注册完整。这一步的作用是确保源模型文件没损坏，不会把坏文件带到内网。
3.3 在内网机器上用 ollama create 重新组装
把 modelfile.txt 和 deepseek-r1-14b.gguf 拷贝到内网目标机 /opt/deepseek 目录，执行导入：
ollama create deepseek-r1:14b -f modelfile.txt导入过程会打印一串类似下面的日志：
gathering model components copying file sha256:6e9f90f02bb3b39b59e81916e8cfce9deb45aeaeb9a54a5be4414486b907dc1e 100% parsing GGUF using existing layer creating new layer sha256:369ca498f347f710d068cbb38bf0b8692dd3fa30f30ca2ff755e211c94768150 creating new layer sha256:6e4c38e1172f42fdbff13edf9a7a017679fb82b0fde415a3e8b3c31c6ed4a4e4 creating new layer sha256:f4d24e9138dd4603380add165d2b0d970bef471fac194b436ebd50e6147c6588 writing manifest success逐行解读一下：gathering model components 是收集模型组件；copying file 后跟的 sha256 是 GGUF 文件的哈希，100% 表示拷贝完成；parsing GGUF using existing layer 表示该哈希在本地已存在，直接复用；creating new layer 是生成新的元数据层；最后 writing manifest success 表示模型清单写入成功，导入完成。
这里容易出问题的还是 FROM 路径。modelfile.txt 里 FROM 如果写的是准备机上的绝对路径，而你在内网机执行 create 时文件放在别的目录，命令会直接找不到源。我用的办法是先改 FROM 相对路径：
sed -i 's|^FROM .*|FROM ./deepseek-r1-14b.gguf|' modelfile.txt ollama create deepseek-r1:14b -f modelfile.txtsed 替换后再 create，FROM 基于当前目录解析，gguf 文件就放在执行命令的目录下，不会再出路径问题。
3.4 验证模型：list、run 与日志
导入完成后先看注册结果：
ollama list输出里能看到 deepseek-r1:14b，SIZE 约 9.0 GB，MODIFIED 是刚才的时间。如果 SIZE 明显偏小，比如只有几百 MB，说明导入的 gguf 不完整，要回头检查拷贝过程。
然后做一次实际推理验证：
ollama run deepseek-r1:14b进入对话交互界面后随便问一句"你好"，看有没有正常回复。这一步验证模型权重能被 CPU 加载并推理。14B 模型通常要 16 GB 内存起步，FT-2000 平台上 32 GB 内存跑起来比较轻松。如果报内存不足，边界在物理内存而不是 CPU 主频。
验证完按 Ctrl+D 退出。确认服务进程状态用：
ollama psps 只在模型被调用过之后才有输出，刚启动没跑过请求时列表是空的，这不是故障。如果 ps 能看到模型，说明它已经常驻内存，可以响应请求了。
4. 排查：装完起不来、模型报错、Chatbox 连不上的五个坑
4.1 现象一：systemctl start ollama 后服务处于 failed 状态
现象：执行 sudo systemctl start ollama 后，状态不是 running 而是 failed，journalctl 日志末尾报 "Failed to start Ollama Service"。
原因：最常发生在 EnvironmentFile 指向的 ollama.conf 不存在，或者 service 文件里 User/Group 对应用户不存在。其次是配置文件里变量格式错误，比如行末有多余空格。
解决：按顺序检查三件事：配置文件是否存在、用户是否存在、daemon 是否重载。
sudo ls -l /opt/deepseek/ollama/ollama.conf sudo id ollama sudo systemctl daemon-reload sudo systemctl start ollamaid ollama 如果提示用户不存在，说明 useradd 那步没执行成功，回 2.3 节重跑。配置文件的变量值建议统一不带引号（特殊路径除外），避免 systemd 解析环境变量时出意外。
4.2 现象二：ollama create 报文件找不到
现象：执行 ollama create deepseek-r1:14b -f modelfile.txt 时，终端报 FROM 指定的文件不存在，或提示 "file does not exist"。
原因：modelfile.txt 里的 FROM 行写的是准备机上的绝对路径，比如 /home/user/.ollama/models/blobs/sha256-xxx，内网机没有这个路径，ollama create 会严格按 FROM 路径找源文件。
解决：把 FROM 改成当前目录相对路径。
sed -i 's|^FROM .*|FROM ./deepseek-r1-14b.gguf|' modelfile.txt ollama create deepseek-r1:14b -f modelfile.txtTEMPLATE、PARAMETER 这些字段不涉及路径，不用动。这个坑我在第三次部署时仍然踩到，后来形成习惯：任何机器上执行 create 之前，先 vim 打开 modelfile.txt 看 FROM 是不是相对路径。
4.3 现象三：局域网内其他机器连不上 11434 端口
现象：本机能跑，另一台机器访问 http://服务器IP:11434 超时，telnet IP 11434 不通。
原因：最常见的是 OLLAMA_HOST 没设成 0.0.0.0，ollama 默认只监听 127.0.0.1，局域网自然不通。另一个可能是系统防火墙拦截了 11434。
解决：先确认环境变量，再看监听地址。
cat /opt/deepseek/ollama/ollama.conf sudo ss -tlnp | grep 11434如果 OLLAMA_HOST 不是 0.0.0.0，改完重启：sudo systemctl restart ollama。ss 输出显示 127.0.0.1:11434 说明环境变量没生效，回头看 service 文件里 EnvironmentFile 路径是否正确。防火墙放行命令：
sudo firewall-cmd --zone=public --add-port=11434/tcp --permanent sudo firewall-cmd --reload麒麟系统如果是 iptables 管理，直接 iptables -I INPUT -p tcp --dport 11434 -j ACCEPT 放行。
4.4 现象四：Chatbox 里报 Failed to fetch
现象：Chatbox 配好 API 地址后，点发送消息立即报 Failed to fetch 或 network error。
原因：Chatbox 是 Web 技术栈客户端，跨域请求被 OLLAMA_ORIGINS 默认值拦截会出现这类错。另外 API 地址写成 https 也会报同样的网络错误，因为服务端没有开 TLS。
解决：把 ollama.conf 里 OLLAMA_ORIGINS 设为 *，重启 ollama 服务。然后检查 API 地址是否 http://IP:11434，不要带 https 前缀。我在配置客户机器时见过至少三次把 http 写成 https 的情况，这个低级错误比跨域问题更容易被忽略。
4.5 现象五：双击 Chatbox.AppImage 没反应
现象：AppImage 加了执行权限，双击桌面图标没有窗口弹出，命令行执行报缺库。
原因：AppImage 依赖系统 FUSE 组件和部分动态库。麒麟 V10 上常见缺 libfuse2，另外原方案里提到的 zlib1g-dev 包缺失也会导致起不来。
解决：命令行先跑一次看真实报错：
/opt/deepseek/Chatbox-1.9.8-arm64.AppImage提示缺 libfuse.so.2 就安装：
sudo apt install libfuse2zlib 相关报错就用 dpkg 装附带的 zlib1g-dev 包。装完依赖再双击。桌面图标如果还是没反应，检查 Chatbox.desktop 里 Exec 是不是绝对路径，以及 chmod +x 是否对桌面文件执行过。
5. 把服务变成日常工具：Chatbox 桌面入口、远程访问与常用命令
5.1 制作可双击的桌面图标
Chatbox 是 AppImage 格式，双击本来就能执行，但每次进目录找文件太麻烦。照原方案写一个桌面入口：
sudo vim /opt/deepseek/Chatbox.desktop内容如下，Exec 路径必须和 AppImage 实际路径一致，Icon 指向 png 图标文件，没有可以先不填：
[Desktop Entry] Version=1.0 Name=Chatbox Comment=This is my cool application Exec=/opt/deepseek/Chatbox-1.9.8-arm64.AppImage Icon=/opt/deepseek/Chatbox.png Terminal=false Type=Application Categories=Utility;Application;保存后执行 chmod +x /opt/deepseek/Chatbox.desktop。麒麟桌面双击提示 untrusted 时，右键属性里勾选允许执行即可。
5.2 Chatbox 连接参数配置
打开设置，API 服务商选 Ollama，模型选 deepseek-r1:14b，关键参数如下：
| 参数 | 值 | 说明 |
|---|---|---|
| API Host | http://127.0.0.1:11434 | 本机用 127.0.0.1，远程填实际 IP |
| 模型名称 | deepseek-r1:14b | 必须与 ollama list 输出一致 |
| API 路径 | /v1/chat/completions | Chatbox 走 OpenAI 兼容接口 |
注意别把 API 路径配成 /api/chat，配错直接 404。
5.3 远程主机接入模型
远程接入只改一处：API Host 的 127.0.0.1 换成模型机内网 IP，比如 http://192.168.1.100:11434。前提是 OLLAMA_HOST 为 0.0.0.0、防火墙放行 11434。联调前先 telnet 探端口，通了再配客户端。
5.4 常用命令与日常维护
日常维护靠几条命令就够：
ollama list # 查看已导入模型 ollama run deepseek-r1:14b # 运行模型进入对话 ollama ps # 查看已加载模型 ollama stop deepseek-r1:14b # 停止模型释放内存 ollama rm deepseek-r1:14b # 删除模型，必须先 stopstop 和 rm 容易搞混，rm 前不 stop 会报文件占用。CPU 机器上模型变慢先看内存占用，14B 模型在 FT-2000 上有性能上限。
这套流程我前后做了三遍，前两遍都栽在 modelfile 路径和 OLLAMA_ORIGINS 上。从那以后，每次做离线模型部署我都强制把"查看 FROM 路径、确认 OLLAMA_HOST、telnet 验证端口"三步走一遍，基本没再翻车。希望这份记录能让你在内网环境里少走几步弯路，早点把 DeepSeek 跑起来。
本文还有配套的精品资源，点击获取
