简介：这份PDF面向在国产Linux发行版上尝试AI模型本地部署的运维人员、开发者与AI爱好者，围绕银河麒麟桌面及高级服务器操作系统，梳理DeepSeek的网页访问、客户端接入、本地部署和接口集成四条路径。内容说明通过麒麟软件商店安装聊天客户端的配置方法，也给出服务器环境安装ollama、启动服务、下载运行DeepSeek-R1并按机器配置选择模型规模的流程，还涉及代码编辑器辅助编程、接口密钥获取、部分架构依赖库缺失排错及桌面端部署截图。文档由麒麟软件生态技术服务中心人员于2025年2月整理初稿，提示内网使用、模型大小选择与常见问题，并说明OCR识别可能存在个别误差。资源包内含1个PDF文件，大小约1.98MB，便于按目录查阅和离线留存。已有513人学习，适合需要国产操作系统AI部署参考的读者。
1. DeepSeek 本地部署翻车，多半是第一步就选错了
一台 aarch64 的麒麟高级服务器，运维照着网上文档把 ollama-linux-amd64.tgz 下载、解压进 /usr/local，ollama serve一执行直接报cannot execute binary file。这跟模型没关系，是包和机器架构对不上。银河麒麟桌面操作系统和银河麒麟高级服务器操作系统都基于 Linux 内核，CPU 分 x86_64 和 aarch64 两条线，ollama 的发布包也分 amd64 和 arm64，错一个字母就是零启动。DeepSeek 本地化部署在麒麟上并不难，难的是先看清手里是什么机器，再决定用脚本装还是离线包装、跑 1.5b 还是 7b。下面按“清点环境 → 装 ollama → 起服务拉模型 → 接客户端 → 排错 → 验证”的顺序走一遍，桌面版和服务器版都能照着做，纯内网环境同样适用。
2. 环境清点：麒麟版本、CPU 架构与模型档位先对齐
2.1 三条命令把机器底细摸干净
在动手装任何东西之前，先在目标机器上敲三条命令。很多“装不上”的问题在这一步就能提前避开。
cat /etc/.kyinfo # 麒麟系统版本、补丁号，部分版本会直接标出架构 uname -m # 输出 x86_64 或 aarch64，决定下载哪个包 free -h # 内存总量，直接决定能跑多大的 DeepSeek-R1/etc/.kyinfo是麒麟系特有的版本文件，里面能读到系统标识和补丁批次，比uname -r更贴近发行版本身。uname -m那条最关键：x86_64 对应 ollama-linux-amd64.tgz，aarch64 对应 ollama-linux-arm64.tgz，源文档里提到的“ARM 架构 libstdc++ 报错”也只会出现在后一条线上。free -h看的是 available 那一列，不是 total——机器上跑了别的服务，total 再大也没用。
再补两条防止后面踩空：
df -h /usr/local # ollama 二进制落在这里，模型默认落在 /usr/share/ollama strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX_3.4.2最后那条命令会列出系统自带 libstdc++ 支持到的符号版本。如果最高只到 GLIBCXX_3.4.20 之类，而机器又是 ARM，那装完 ollama 大概率会撞上源文档里那个GLIBCXX3.4.25缺失的提示，提前知道总比事后救火强。
2.2 桌面版与服务器版：同一套流程，两种取舍
银河麒麟桌面操作系统和麒麟高级服务器操作系统的部署步骤是同一套，源文档也写明了“桌面环境步骤相同”。但两者的使用姿势差别不小，选错了场景，装完体验会很别扭。
| 维度 | 银河麒麟桌面操作系统 | 银河麒麟高级服务器操作系统 |
|---|---|---|
| 主要角色 | 交互终端，跑 Chatbox 等客户端 | 后台常驻，对外提供 11434 端口 |
| ollama 存活方式 | 手动启动，注销即断 | systemd 托管，开机自启 |
| 典型内存 | 8～16 GB | 32 GB 以上可扩 |
| 建议模型档位 | 1.5b、7b | 14b、32b、70b |
| 适用场景 | 单人验证、离线办公 | 多人共用、内网统一入口 |
源文档给出的建议很直白：为了提升 DeepSeek 的性能和算力，本地部署优先放在银河麒麟高级服务器操作系统上。所以典型形态是——服务器装 ollama、拉模型、开 11434 端口，桌面机从软件商店装 Chatbox 连过去。桌面机自己装一份也能跑，只是关个机模型就没了，适合临时验货。
2.3 模型档位与硬件对照：1.5b 只是验货，不是终点
源文档以deepseek-r1:1.5b为例，理由很实在：它小，装完立刻能验证整条链路通不通。但真拿去写代码、做推理，1.5b 的深度有限。模型标签里的数字是参数量，量化后占用的内存大约是参数量乘以位宽再除以 8，实际值可以对照下表估算。
| 模型标签 | 参数量 | 量化后体积 | 建议可用内存 | 适用场景 |
|---|---|---|---|---|
| deepseek-r1:1.5b | 15 亿 | 约 1.1 GB | 4 GB | 装完验货、轻量问答 |
| deepseek-r1:7b | 70 亿 | 约 4.7 GB | 8～16 GB | 日常对话、代码补全 |
| deepseek-r1:8b | 80 亿 | 约 4.9 GB | 8～16 GB | 同 7b，推理略稳 |
| deepseek-r1:14b | 140 亿 | 约 9 GB | 16～24 GB | 复杂推理、长文本 |
| deepseek-r1:32b | 320 亿 | 约 20 GB | 32 GB 以上 | 服务器主力档 |
| deepseek-r1:70b | 700 亿 | 约 43 GB | 64 GB 以上 | 高配服务器 |
源文档原话是“可根据机器配置选择模型大小，数字越大需求的配置越高”，这句话没有例外。我一般会先把 1.5b 跑通，确认 ollama、端口、客户端三层都没问题，再回头ollama pull正式档位，避免一开始就卡在几 GB 的下载上排查不出到底是网络还是模型的问题。模型文件默认落在/usr/share/ollama/.ollama/models（systemd 运行时）或当前用户的~/.ollama/models，装之前用df -h确认那块分区留够 50 GB 以上比较稳妥。
3. 安装 ollama：在线脚本、离线包与 ARM 补库
3.1 在线脚本安装：一条 curl 背后做了什么
能出外网的机器，源文档给的是最短路径：
curl -fsSL https://ollama.com/install.sh | sh这条命令里的四个参数各有用途：-f让 curl 在服务端返回 4xx/5xx 时直接失败而不会把错误页当脚本执行，-s静默进度条，-S保证真出错时仍然打印原因，-L跟随重定向。少了-f，你有可能把一段 HTML 错误页喂给 sh，报错信息会莫名其妙。
脚本本身做的动作不少：探测 CPU 架构、下载匹配的二进制、创建 ollama 系统用户、写/etc/systemd/system/ollama.service、启动服务。所以在线装完之后，ollama 是已经被 systemd 托管起来的，不需要再手动ollama serve。装完先确认版本和服务状态：
ollama --version systemctl status ollama --no-pager版本号能正常打印、服务状态是 active (running)，说明第一步过了。如果机器走内网、出不去外网，这条命令会卡在下载阶段，直接走下一节的离线包。
3.2 离线 tgz 安装：内网与架构必须匹配
内网环境的做法是提前把包下好带进去。源文档给的地址是 GitHub 的 latest 链接，注意按架构选文件名：
# x86_64 机器 wget https://github.com/ollama/ollama/releases/latest/download/ollama-linux-amd64.tgz # aarch64 机器 wget https://github.com/ollama/ollama/releases/latest/download/ollama-linux-arm64.tgz拷到目标机之后解压。源文档用的是tar -C /usr/local -zxvf，参数拆开看：-C /usr/local指定解压根目录，-z走 gzip，-x解包，-v打印过程，-f指定文件。这样解出来的结构是/usr/local/bin/ollama加/usr/local/lib/ollama/下的依赖库，正好放在系统默认 PATH 里。
sudo tar -C /usr/local -zxvf ollama-linux-amd64.tgz /usr/local/bin/ollama --version如果ollama --version提示 command not found，说明/usr/local/bin不在当前用户的 PATH 里，补一条软链更省事：
sudo ln -sf /usr/local/bin/ollama /usr/bin/ollama离线包方式装完不会自动生成 systemd 单元，需要自己起服务，这部分放到第 4 章。桌面版和服务器版在这一步完全一致，解压路径不用改。
3.3 ARM 架构上的 GLIBCXX 补库
源文档专门标注了这个坑：ARM（aarch64）架构服务器部署 ollama 时，可能提示/usr/lib64/libstdc++ 错误，GLIBCXX3.4.25 缺失。原因是 ollama 依赖的 libstdc++ 版本比系统自带的新，符号表里找不到对应版本，二进制加载就直接失败。
先确认现状，别急着动手：
strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX_3.4.25没有任何输出，就说明确实缺。解决思路是引入一个更高的libstdc++.so.6.0.28，把系统默认的那份备份掉，再重建软链：
# 1. 备份系统自带版本，留好后悔药 cd /usr/lib64/ sudo mv libstdc++.so.6 libstdc++.so.6.bak # 2. 放入 6.0.28（来源可以是系统安装镜像的 Packages 目录解包） sudo cp /path/to/libstdc++.so.6.0.28 /usr/lib64/ # 3. 重建软链接，指向新版本 sudo ln -s libstdc++.so.6.0.28 libstdc++.so.6 # 4. 刷新动态库缓存 sudo ldconfig # 5. 复核 strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX_3.4.25最后一条能打印出GLIBCXX_3.4.25就说明替换成功，这时候再回去执行ollama --version就不会报错了。源文档还给了另一个更省事的来源：直接在系统安装镜像里找 libstdc++ 的 rpm 包，用rpm2cpio解出 .so 文件，这样版本和发行版本身更对得上：
mkdir -p /tmp/libstdcpp && cd /tmp/libstdcpp rpm2cpio /path/to/libstdc++-*.rpm | cpio -idmv find . -name "libstdc++.so.6.0.*"注意：libstdc++ 是系统级共享库，替换会影响所有依赖它的程序。改之前一定要保留
.bak，并且在测试机上先跑一遍常用业务程序，确认没有别的程序死在新版本上。真出了连锁问题，把libstdc++.so.6的软链指回.bak就能回滚。
4. 起服务与拉模型：OLLAMA_HOST、systemd 托管和 Chatbox 接入
4.1 两个环境变量决定别人能不能连上你
ollama 默认只监听127.0.0.1:11434，本机 curl 得通，桌面机连过去就是拒绝连接。源文档给的两个 export 就是解决这件事的：
export OLLAMA_HOST=0.0.0.0 export OLLAMA_ORIGINS=* ollama serveOLLAMA_HOST=0.0.0.0的含义是监听所有网卡，端口默认 11434，写全了就是0.0.0.0:11434；只想绑某块内网网卡的话换成具体 IP 更安全。OLLAMA_ORIGINS=*是允许任意来源跨域，主要给浏览器里的客户端用，纯内网环境放开问题不大，但要意识到这是个宽松配置。
启动后开另一个终端验证监听状态：
ss -lntp | grep 11434看到0.0.0.0:11434而不是127.0.0.1:11434，才说明远端能接进来。这两个 export 只对当前 shell 生效，关掉窗口就没了，所以生产环境别这么干，往下看 systemd 托管。
4.2 用 systemd 托管，别再 nohup &
在线脚本装出来的 ollama 本身就带 systemd 单元，但环境变量不会自动进服务里。正确做法是用 drop-in 覆盖，不动原单元文件：
sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf > /dev/null <<'EOF' [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_ORIGINS=*" EOF sudo systemctl daemon-reload sudo systemctl restart ollama sudo systemctl status ollama --no-pagerdaemon-reload让 systemd 重新读取单元配置，restart应用新环境变量，status里能看到进程 PID 和监听信息。用 drop-in 的好处是以后 ollama 升级重装，原单元文件被覆盖，你这份 override.conf 还在，不用每次重配。
如果机器是离线包安装的，没有现成单元，补一份最小可用的：
sudo tee /etc/systemd/system/ollama.service > /dev/null <<'EOF' [Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve User=root Restart=always RestartSec=3 Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_ORIGINS=*" [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now ollama注意：如果 ollama 已经由 systemd 跑着，再手动
ollama serve会报bind: address already in use。这时候不是端口被占，是你自己起了两份。
4.3 拉取 deepseek-r1:1.5b 并跑通第一轮对话
服务起来之后就是拉模型。源文档用的命令是：
ollama run deepseek-r1:1.5brun会做两件事：本地没有就先 pull，有就直接进交互。单独ollama pull deepseek-r1:1.5b只下载不启动，适合提前把模型备好、等客户端连上来再跑。下载过程中会显示分层进度，1.5b 大约 1.1 GB，内网走本地源的话几十秒就完事。
进入交互后随便问一句，能正常回话就说明模型加载成功。退出用/bye。再补两条查看命令：
ollama list # 已下载的模型清单和体积 ollama ps # 当前加载在内存里的模型，看得到资源占用ollama ps这一条在排查“模型是不是真跑起来了”时特别有用——如果列表里有模型但 ps 是空的，说明只是下载了没加载，客户端连上来第一次请求会触发冷加载，大模型这时候会卡十几秒，别误判成服务挂了。
4.4 Chatbox 接入：模型提供方选 OLLAMA
桌面机这边，源文档推荐从麒麟软件商店装 Chatbox AI，商店里还有 NextChat、Cherry Studio 可选，配置逻辑大同小异。打开 Chatbox 进设置，按下面这张表填：
| 配置项 | 填写值 |
|---|---|
| 模型提供方 | OLLAMA |
| API 域名 | http://<服务器IP>:11434 |
| 端口 | 11434（默认） |
| 模型 | 自动识别deepseek-r1:1.5b，选中保存 |
“模型提供方”一定要选 OLLAMA 而不是 DeepSeek，前者走本地 11434，后者走官方 API 要 Key，选错了会一直提示鉴权失败。API 域名填服务器实际内网 IP，别填 localhost——在桌面机上 localhost 指的是桌面机自己。
服务器侧如果开了 firewalld，记得放行端口，否则客户端会表现为连接超时而不是拒绝连接：
sudo firewall-cmd --permanent --add-port=11434/tcp sudo firewall-cmd --reload sudo firewall-cmd --list-ports配完在 Chatbox 对话框发一句，能收到回复，整条链路就通了。这也正是源文档强调的“本场景支持内网环境使用”——服务器不出网、桌面机不出网，只要内网互通就能用。
5. 避坑记录：五条在麒麟上真实撞过的问题
5.1 现象：ollama 一执行就报 cannot execute binary file
原因：下载的是 amd64 包，机器是 aarch64，或者反过来。ELF 头对不上，内核直接拒绝加载，报错里不会告诉你“架构错了”这么直白。
解决：回到 2.1 节，uname -m确认架构后重新下对应包。已经解压错的，先rm -rf /usr/local/bin/ollama /usr/local/lib/ollama清干净再解压新的，别直接覆盖——旧文件残留会让人以为换包没生效。
5.2 现象：ARM 机器上提示 GLIBCXX_3.4.25 缺失
原因：ollama 编译时链接的 libstdc++ 比麒麟系统自带的版本新，符号表里找不到对应版本号。
解决：按 3.3 节替换libstdc++.so.6.0.28并重建软链，ldconfig之后复核符号。这条坑在 ARM 服务器上出现频率远高于 x86，桌面版基本不会撞上。
5.3 现象：本机 curl 11434 通，桌面机 Chatbox 连不上
原因：OLLAMA_HOST只在当前 shell export 过，systemd 托管的那个进程读不到；或者读到了但绑的是 127.0.0.1。
解决：用ss -lntp | grep 11434看监听地址，如果是 127.0.0.1 就走 4.2 节的 drop-in 配置，重启服务后再看。顺手确认防火墙放行了 11434，两个条件缺一不可。
5.4 现象：ollama pull 卡在某个百分比不动，或者报 no space left on device
原因：模型默认落在/usr/share/ollama/.ollama/models，如果/usr和/是同一块分区，根分区小的话几 GB 就撑满了；也可能是内网到外网的出口被限速。
解决：df -h /usr/share/ollama先看剩余空间，不够就通过OLLAMA_MODELS环境变量把模型目录指到大盘上，改完重启服务再 pull。网络问题就换内网镜像源，或者用能出网的机器下好整个models目录再拷进去。
5.5 现象：模型加载到一半进程消失，systemctl status 显示 killed
原因：内存不够，内核 OOM killer 把 ollama 进程杀了。32b 以上的模型在 16 GB 机器上基本必现，日志里能看到Out of memory: Killed process。
解决：journalctl -u ollama -n 100 --no-pager确认是 OOM 之后，降档到 7b/8b，或者加内存。别指望 swap 能救——模型推理走的是常驻内存，swap 一开速度掉得比降档还难看。
6. 装完怎么验证：三层检查，从端口到 VSCode
装完不等于跑通。我习惯按三层往下查，任何一层不过就停在那儿，不继续往上叠。
第一层看进程和端口。systemctl is-active ollama返回 active，ss -lntp | grep 11434看到0.0.0.0:11434，这一层才算过。返回 inactive 就去看journalctl -u ollama -n 50，日志里通常直接写着缺库还是端口冲突。
第二层打 API。ollama 自带 HTTP 接口，不依赖任何客户端就能验：
# 列表接口：能返回模型名，说明服务活着且模型已注册 curl -s http://127.0.0.1:11434/api/tags | head -c 400 # 生成接口：stream 设为 false，一次拿完整回复 curl -s http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-r1:1.5b", "prompt": "用一句话说明你是什么模型", "stream": false }'/api/tags返回 JSON 里能看到deepseek-r1:1.5b，/api/generate返回response字段有内容，说明模型加载、推理、返回整条链路都正常。这一步比开客户端更直接——客户端报错你还要分辨是网络还是配置，curl 报错就是服务本身的问题。远端验证把 127.0.0.1 换成服务器内网 IP 再打一遍，能通才说明 Chatbox 那边有戏。
第三层才是客户端。Chatbox 发一句能回，说明 OLLAMA 提供方、API 域名、模型选择三个配置项都对了。再到开发者场景，从麒麟软件商店装 Visual Studio Code，扩展里搜 cline 装上，打开后 API Provider 有两个选择：走官方 API 就选 DeepSeek、填平台创建的 API Key（注意 Key 只展示一次，创建完立刻存好）；走本地部署就选 Ollama，Base URL 填http://127.0.0.1:11434，模型名手动填deepseek-r1:1.5b。cline 里发一句需求能生成代码、点执行能跑通，这套环境才算真正交付。
| 检查层 | 命令或操作 | 通过标准 |
|---|---|---|
| 进程端口 | systemctl is-active ollama、ss -lntp | active，监听 0.0.0.0:11434 |
| HTTP API | curl /api/tags、curl /api/generate | 返回模型名与 response 内容 |
| 客户端 | Chatbox 对话、VSCode cline 生成代码 | 有正常回复、代码可执行 |
从那以后我每次在麒麟上装完 ollama，不管多急，都强制把这三层走一遍再交出去——尤其是远端 curl 那一步，太多“客户端连不上”最后查出来是监听地址没改对。希望帮到你。
本文还有配套的精品资源，点击获取
