简介这份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/localollama 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.tgzaarch64 对应 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 托管开机自启典型内存816 GB32 GB 以上可扩建议模型档位1.5b、7b14b、32b、70b适用场景单人验证、离线办公多人共用、内网统一入口源文档给出的建议很直白为了提升 DeepSeek 的性能和算力本地部署优先放在银河麒麟高级服务器操作系统上。所以典型形态是——服务器装 ollama、拉模型、开 11434 端口桌面机从软件商店装 Chatbox 连过去。桌面机自己装一份也能跑只是关个机模型就没了适合临时验货。2.3 模型档位与硬件对照1.5b 只是验货不是终点源文档以deepseek-r1:1.5b为例理由很实在它小装完立刻能验证整条链路通不通。但真拿去写代码、做推理1.5b 的深度有限。模型标签里的数字是参数量量化后占用的内存大约是参数量乘以位宽再除以 8实际值可以对照下表估算。模型标签参数量量化后体积建议可用内存适用场景deepseek-r1:1.5b15 亿约 1.1 GB4 GB装完验货、轻量问答deepseek-r1:7b70 亿约 4.7 GB816 GB日常对话、代码补全deepseek-r1:8b80 亿约 4.9 GB816 GB同 7b推理略稳deepseek-r1:14b140 亿约 9 GB1624 GB复杂推理、长文本deepseek-r1:32b320 亿约 20 GB32 GB 以上服务器主力档deepseek-r1:70b700 亿约 43 GB64 GB 以上高配服务器源文档原话是“可根据机器配置选择模型大小数字越大需求的配置越高”这句话没有例外。我一般会先把 1.5b 跑通确认 ollama、端口、客户端三层都没问题再回头ollama pull正式档位避免一开始就卡在几 GB 的下载上排查不出到底是网络还是模型的问题。模型文件默认落在/usr/share/ollama/.ollama/modelssystemd 运行时或当前用户的~/.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 补库源文档专门标注了这个坑ARMaarch64架构服务器部署 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_HOST0.0.0.0 export OLLAMA_ORIGINS* ollama serveOLLAMA_HOST0.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] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_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] DescriptionOllama Service Afternetwork-online.target [Service] ExecStart/usr/local/bin/ollama serve Userroot Restartalways RestartSec3 EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_ORIGINS* [Install] WantedBymulti-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 进设置按下面这张表填配置项填写值模型提供方OLLAMAAPI 域名http://服务器IP:11434端口11434默认模型自动识别deepseek-r1:1.5b选中保存“模型提供方”一定要选 OLLAMA 而不是 DeepSeek前者走本地 11434后者走官方 API 要 Key选错了会一直提示鉴权失败。API 域名填服务器实际内网 IP别填 localhost——在桌面机上 localhost 指的是桌面机自己。服务器侧如果开了 firewalld记得放行端口否则客户端会表现为连接超时而不是拒绝连接sudo firewall-cmd --permanent --add-port11434/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返回 activess -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 只展示一次创建完立刻存好走本地部署就选 OllamaBase URL 填http://127.0.0.1:11434模型名手动填deepseek-r1:1.5b。cline 里发一句需求能生成代码、点执行能跑通这套环境才算真正交付。检查层命令或操作通过标准进程端口systemctl is-active ollama、ss -lntpactive监听 0.0.0.0:11434HTTP APIcurl /api/tags、curl /api/generate返回模型名与 response 内容客户端Chatbox 对话、VSCode cline 生成代码有正常回复、代码可执行从那以后我每次在麒麟上装完 ollama不管多急都强制把这三层走一遍再交出去——尤其是远端 curl 那一步太多“客户端连不上”最后查出来是监听地址没改对。希望帮到你。本文还有配套的精品资源点击获取
