银河麒麟本地部署DeepSeek：Ollama安装与ARM架构避坑指南

简介：这份PDF面向银河麒麟桌面与服务器操作系统的使用者、运维人员及AI开发者，系统讲解DeepSeek在国产Linux环境中的本地化部署与使用路径。文档从四种典型场景切入：网页版访问、麒麟软件商店客户端安装、基于Ollama的本地模型部署，以及客户端对接本地服务的组合方案，并给出DeepSeek官方API Key创建与Chatbox、NextChat、Cherry Studio等AI客户端的配置方法。针对开发者，还介绍了在Visual Studio Code中通过Cline插件集成DeepSeek辅助编程的完整流程。内容兼顾入门与实操，包含部署命令、模型选型建议和ARM架构服务器常见依赖问题的排错思路，并附有银河麒麟桌面系统部署过程截图。资源为1个PDF文件，大小约1.98MB，已有512人学习，适合需要在内网环境完成DeepSeek落地部署的初学者和工程人员参考。

1. 银河麒麟本地部署DeepSeek：从下载文档到跑通模型，中间隔着这些坑

拿到一份写好的《基于银河麒麟桌面&服务器操作系统的DeepSeek本地化部署方法》时，多数人的第一反应是把命令复制进去就完事。真正动手才发现，网页版、客户端、本地部署其实是三条完全不同的路：本地部署要从Ollama装起，而ARM架构（aarch64）机器大概率会先撞上GLIBCXX_3.4.25缺失这个报错，服务起来之后客户端连不上的问题也排着队。这个场景在国产化内网环境里非常典型：机器用的是银河麒麟这类国产Linux发行版，网络受限，又想用DeepSeek做本地AI模型推理，同时保留官方API接入的能力。我会按自己在银河麒麟桌面和高级服务器两套环境里实际走过的路径来写，适合需要在内网完成深度学习模型本地部署的开发者，也适合刚拿到国产化机器、准备把AI模型落地到应用里的读者。

2. 环境确认与选型：先看清系统再动手

2.1 桌面版还是服务器版：先确定这台机器在方案里的角色

银河麒麟桌面操作系统和银河麒麟高级服务器操作系统都支持DeepSeek本地部署，官方手册里也明确写了这一点，而且部署步骤几乎一样。但我在实际部署时体会最大的差异不是命令，而是这两类系统对“常驻服务”的态度差异。Ollama一旦启动，就是一个持续监听11434端口的服务进程；服务器版在内核参数、内存管理、多核调度上更偏向服务化运行，适合扛模型推理这种长期占用资源的任务。桌面版的优势是图形界面齐全、软件商店直接可用，适合做模型验证和开发调试。

如果你只是想把DeepSeek跑起来看看效果，桌面版完全够用，一条命令就能把1.5b模型拉起来。如果是团队内网使用，有多人通过Chatbox远程接入，或者打算把模型能力集成进业务系统，我会把部署目标放在服务器版上，桌面版只做客户端接入端。这样做的好处是模型服务不占日常桌面资源，也不会因为桌面会话退出而中断服务。

确定角色之后要做的第一件事不是安装，而是把机器底细摸清楚。这一步省略的话，后面选错安装包、选错模型档位，全都是在白费功夫。

2.2 查看系统版本、CPU架构与内存：四个命令确定安装包

动手之前，我习惯先把这几条命令跑一遍：

cat /etc/os-release uname -m nproc free -h

/etc/os-release查看发行版名称和版本号，确认是不是银河麒麟以及具体的V10 SP几版本；uname -m返回机器架构，x86_64 和 aarch64 在下载Ollama安装包时对应完全不同的文件；nproc和free -h给出核心数与内存大小，直接决定后面DeepSeek模型选哪个档位。

架构这一项是后面所有步骤的分岔口。官方手册里演示的是ollama-linux-amd64.tgz，这个安装包只对应x86_64架构。如果uname -m返回的是 aarch64，那就不能照抄命令，得去Ollama的release页面找带arm64标识的压缩包。很多人在这一步翻车，就是直接拿了amd64包往ARM机器上放，解压能成功，一ollama serve就报Exec format error，这是最典型的架构不匹配信号。

内存信息则用来约束模型选型，第三章会给出对照表。这里有一条血泪经验：机器只有8G内存，还开着桌面环境、浏览器、日常软件，就不要挑战7b以上的模型档位。1.5b入门，把链路走通再考虑升级硬件，是最稳妥的节奏。

2.3 从麒麟软件商店准备客户端：省掉自己解决依赖的工夫

网页版DeepSeek、Chatbox AI、NextChat、Cherry Studio这些入口，银河麒麟软件商店里都有，官方手册也明确提到可以从商店获取。我在桌面版上装Chatbox时就直接走商店安装，好处是依赖库和系统架构适配都已经处理过，不需要像手动装deb包那样去解决缺库问题。

商店装不上的场景也有，比如机器没联网、或者商店里的版本偏旧。这种情况我会去Chatbox官网下载Linux安装包，注意区分是AppImage还是deb：AppImage不需要安装，直接赋权后就能执行；deb则要用sudo dpkg -i安装。但这些都是基于网络可达的前提，纯内网环境还是要找管理员要安装包，或者用有网的机器下载后拷贝进去。

需要先搞清楚的是，客户端工具只是“入口”，不是“模型本身”。网页版和官方API模式走的是DeepSeek云端服务，本地部署模式走的是自己机器上的Ollama服务，客户端的作用是把这两类后端统一成一个对话框。所以确认完客户端来源之后，下一步不是急着填配置，而是先把服务端部署好。

3. 安装Ollama并拉取DeepSeek-R1：两种方式、三个参数

3.1 方式一：官方脚本安装，适合能联网的x86机器

Ollama官方提供了一键安装脚本，官方手册里的安装方式也是它：

curl -fsSL https://ollama.com/install.sh | sh

这条命令把安装脚本拉下来之后直接交给sh执行，脚本会检测系统架构、下载对应压缩包并完成安装。先讲一个安全习惯：curl | sh这种管道执行用在官方源上问题不大，但在内网或非官方源环境里，我一般会先curl -fsSL -O把脚本下载下来，翻一遍里面的下载地址和安装路径，确认没有异常再手动执行，避免脚本被替换的风险。

脚本安装对x86_64架构的银河麒麟系统兼容性最好，装完直接就有ollama命令可用。如果你执行这条命令时发现速度极慢或者直接连接失败，多半是网络到ollama.com不通，这不代表方案不可行，直接切到下面第二种方式走离线包。

3.2 方式二：tgz离线安装包，内网和ARM机器首选

官方手册提供的第二种方式是从GitHub release下载压缩包后解压：

wget https://github.com/ollama/ollama/releases/latest/download/ollama-linux-amd64.tgz tar -C /usr/local -zxvf ollama-linux-amd64.tgz

把下载好的ollama-linux-amd64.tgz解压到/usr/local目录。选择这个路径是刻意的：/usr/local/bin默认在PATH环境变量里，解压之后不需要额外配置就能直接执行ollama命令；同时/usr/local是系统管理员手动安装软件的惯例位置，不会和发行版自带的包管理文件混在一起。

如果机器是ARM架构，就把包名换成release页面里对应的arm64/aarch64版本，解压命令完全一致。两种方式不需要都执行，选一种即可：脚本安装适合有外网、能够顺利拉取官方源的机器；tgz离线包适合内网环境，也适合需要精确控制文件来源的场景。ARM机器我一般直接走tgz路线，官方脚本里的自动检测逻辑在国产系统上行为不固定，离线包反而更可控。

3.3 启动服务：OLLAMA_HOST与OLLAMA_ORIGINS的含义

解压或安装完成后，启动Ollama服务：

export OLLAMA_HOST=0.0.0.0 export OLLAMA_ORIGINS=* ollama serve

OLLAMA_HOST=0.0.0.0表示监听所有网卡地址，让局域网内其他机器可以通过服务器IP访问11434端口；如果不设置，Ollama默认只监听127.0.0.1，那客户端只能在本机用，Chatbox远程对接就会完全连不上。OLLAMA_ORIGINS=*是跨域来源白名单，允许浏览器和各类客户端从任意来源调用API，本地内网环境这样设置最简洁，但要注意生产环境不要盲目放开，最好限定具体来源域名。

提示：OLLAMA_ORIGINS 设为 * 只建议在可信内网使用。跨部门或对外开放时，把它改成实际访问的来源地址会更安全。

设置完这两个环境变量后运行ollama serve启动服务，这个终端窗口会一直保持服务日志，不要关掉。另开一个终端窗口执行ollama --version或ollama list，能正常输出版本号和模型列表，就说明服务进程已经跑起来了。

如果希望Ollama开机自启，而不是每次手动开终端，可以用systemd托管：

cat > /etc/systemd/system/ollama.service <<EOF [Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve Environment="OLLAMA_HOST=0.0.0.0" Environment="OLLAMA_ORIGINS=*" Restart=always [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable ollama systemctl start ollama

这个服务文件把环境变量固化在systemd里，就不用担心终端关闭、服务随会话退出。Restart=always让Ollama在异常退出后自动拉起，这是服务器上长期运行的基本配置。后续改了端口或模型目录，改服务文件里的Environment行再systemctl restart ollama即可。

3.4 拉取并运行DeepSeek-R1：模型选型的取舍

服务启动后，安装运行DeepSeek-R1模型：

ollama run deepseek-r1:1.5b

这条命令会先从Ollama仓库拉取deepseek-r1:1.5b模型文件，拉取完成后自动进入模型对话界面，可以直接输入中文提问来验证。1.5b是R1系列里比较小的档位，模型文件不算大，适合第一次部署时先把链路跑通。

模型档位选择是最值得斟酌的一步。官方手册里说得很明白：数字越大需求越高。1.5b之后还有众多更大参数量的模型标签，它们推理质量更好，但对内存和算力要求成倍上升。以下是我常用的经验对照：

没有独立显卡的情况下，模型完全依赖CPU和内存运行，1.5b在8G内存的桌面机上仍然有明显响应延迟，但能稳住不崩；7b在8G内存上就属于勉强，一旦同时开着桌面环境，系统很可能直接OOM。我一般部署前会用free -h看可用内存，把模型档位控制在系统内存的四分之一到三分之一以内，给操作系统和日常工作留余量。

第一次拉取时终端会显示进度条，速度取决于网络情况。模型下载完成并进入对话后，输入“你好”能收到回复，本地推理链路就算通了。

4. 避坑排查：ARM架构libstdc++、模型下载慢与端口连不上

4.1 ARM架构报错：GLIBCXX_3.4.25缺失

现象：在aarch64架构的银河麒麟系统上执行ollama serve或ollama run，报错信息里出现/usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.25' not found，模型对话功能完全不可用，命令直接终止。

原因：Ollama的Linux运行时依赖较高版本的GNU C++标准库，而ARM架构的银河麒麟系统自带的libstdc++.so.6版本偏旧，符号表里没有GLIBCXX_3.4.25这个版本节点。这是依赖库版本与系统自带版本不一致导致的，不是Ollama安装包损坏，也不是模型下载出了问题。

解决：从官方手册的ARM部署注意事项里找到配套网盘链接，下载libstdc++.so.6.0.28库文件，然后执行：

cp libstdc++.so.6.0.28 /usr/lib64/ cd /usr/lib64/ mv libstdc++.so.6 libstdc++.so.6.bak ln -s libstdc++.so.6.0.28 libstdc++.so.6

先把新库拷贝到/usr/lib64，再把系统原来的libstdc++.so.6备份成.bak后缀文件，最后用软链接把新库指到系统默认文件名上。这里的备份操作就是后悔药，一旦新库和系统里其他软件冲突，一条mv libstdc++.so.6.bak libstdc++.so.6就能切回去，这一步不要省。软链接而不是直接覆盖，也是为了让系统库目录保持干净、可回退。

替换完成后重新执行ollama run deepseek-r1:1.5b，如果不再报GLIBCXX错误，就说明库版本匹配了。需要提醒的是，这个替换动的是系统级C++库，会影响依赖它的其他程序，所以我会先确认这台机器是专用部署机再操作，不要在正在跑业务的机器上贸然替换。

4.2 模型下载慢或中断：离线拷贝模型目录

现象：ollama run deepseek-r1:1.5b执行后进度条长时间不动，或者下载到一半报错退出，重新执行又是从头开始。

原因：模型文件托管在境外下载源，受限网络环境下速度不稳定，中断后没有断点续传机制，这在无外网或出口受限的内网里很常见。

解决：在有网络环境的机器上先拉取完整模型，然后找到模型目录整体拷贝到离线机器。模型目录默认在~/.ollama/models，也可以用环境变量显式指定：

export OLLAMA_MODELS=/data/ollama/models

设置OLLAMA_MODELS可以把模型存储目录放到空间足够的磁盘上，避免默认目录所在的系统盘被模型文件塞满。迁移时把整个目录打包，拷贝到目标机器的相同路径，再启动Ollama，ollama list能看到模型就说明迁移完成。这一步比反复重试下载省太多时间，是我在内网部署时的默认做法。

4.3 客户端连不上11434端口：环境变量和防火墙各占一半

现象：桌面版Chatbox配置好Ollama地址后点发送，客户端立刻报连接失败或Failed to fetch。

原因：常见两类。其一是Ollama启动时没有设置OLLAMA_HOST=0.0.0.0，服务只监听了回环地址，局域网客户端自然无法访问；其二是服务监听正常，但系统防火墙拦截了11434端口。

解决：分两步排查。先确认服务监听地址：

ss -lntp | grep 11434

输出里有0.0.0.0:11434说明监听正常；如果显示127.0.0.1:11434，就需要回到第三章，设置OLLAMA_HOST后重启服务。监听正常但客户端仍连不上，再检查防火墙放行，如果系统启用的是firewalld，执行：

firewall-cmd --permanent --add-port=11434/tcp firewall-cmd --reload

端口通了之后，用curl http://服务器IP:11434能返回Ollama版本信息，客户端基本就没问题了。排查这类问题我从来不看客户端报错里的详细描述，直接看监听地址和端口状态，两步定位最快。

4.4 Ollama进程被系统杀掉：模型档位超出内存余量

现象：对话几次之后终端里Ollama进程消失，或者Chatbox长时间无响应，系统日志里出现OOM相关记录。

原因：模型推理时占用的内存超过机器可用内存，操作系统触发了OOM Killer。1.5b模型计算量虽小，但推理请求并发时也会撑满小内存机器，尤其是桌面环境同时占用内存的情况。

解决：先free -h看真实剩余内存，把当前模型降到低一档试试。临时救急可以加交换分区：

fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile

这是临时扩容手段，尽量不要把swap放在U盘或机械盘上，性能会很难看。长期使用还是加物理内存或者换小模型。部署AI模型不是只算模型文件大小，推理时的临时激活值和并发请求都得算进内存预算，这是最容易被忽略的隐性坑。

4.5 软件商店找不到Cline扩展：先装好VSCode再搜扩展

现象：在银河麒麟软件商店搜索“Cline”没有结果，或者装了一个同名插件，打开后找不到AI配置入口。

原因：软件商店主要上架的是应用程序，VSCode扩展由扩展市场托管，商店不一定同步收录；同名插件可能是旧版本，配置入口和现在的Cline完全不一样。

解决：先从软件商店安装VSCode本体，打开后在扩展面板搜索Cline，安装对应该插件的版本。商店缺插件属于正常现象，不影响使用，扩展面板里能搜到就够。插件装好后左侧会出现Cline图标，所有配置入口都在里面。

5. 客户端接入与API集成：Chatbox、DeepSeek官方API与Cline

5.1 网页版与API Key获取：先拿到访问凭证再谈集成

网页版的使用门槛最低，浏览器打开DeepSeek官网就能对话；银河麒麟软件商店里也上架了「DeepSeek网页版」入口，本质上是把官网地址封装成了桌面快捷方式。官网对话适合直接体验，但要在Chatbox这类客户端里接入，或者把DeepSeek集成到自己的应用里，就需要创建API Key。

访问DeepSeek官方API平台，注册登录后进入API keys页面，点击“创建API key”按钮，输入名称并创建，页面会展示一组key。这个key只展示一次，复制后必须妥善保存到密码管理器里，刷新页面就再也看不到了。我在部署脚本里一般这样引用：

export DEEPSEEK_API_KEY="sk-这里填你创建的key"

把API Key放在环境变量里，而不是直接写死在Chatbox配置文件的明文里，是防止配置文件被同步或误分享时泄露。如果Chatbox只在本地个人环境运行，直接粘贴进设置界面也可以，看使用习惯。

5.2 Chatbox接入本地Ollama：把对话框指向内网模型服务

Chatbox从软件商店安装后，运行起来默认是空配置。接入本地Ollama的路径如下：打开设置界面，「模型提供方」选择OLLAMA；「API域名」填写部署DeepSeek模型的服务器地址，格式为http://服务器IP:11434，端口就是Ollama默认监听端口；填完之后「模型」一栏会自动识别出deepseek-r1:1.5b，选中保存即可。如果模型没有自动出现，检查一下API域名有没有漏端口，或者Ollama服务是否还活着。

这里要强调为什么填IP而不是127.0.0.1：本地部署的典型架构是模型跑在服务器上，Chatbox跑在桌面机上，两边通过网络通信。填127.0.0.1只适用于模型和客户端在同一台机器、并且桌面打开的场景；服务器部署场景里，填目标服务器的局域网IP才能走到真实模型服务。

配置完成后的验证动作很简单：在对话框输入“你好”，Chatbox会把这个请求发给Ollama服务，Ollama把deepseek-r1:1.5b的推理结果返回。能正常收到回答，本地部署的交互链路就通了，全程不经过外部网络，这就是内网部署的核心价值。

5.3 Chatbox接入DeepSeek官方API：本地客户端调用云端模型

如果不做本地部署，也可以让Chatbox直接调用DeepSeek官方API。设置界面里「模型提供方」选择DeepSeek，API域名填DeepSeek官方接口地址，模型填deepseek-chat，再把上一步创建的API Key粘贴进来。这套配置本质是让Chatbox充当官方网页版的桌面外壳，效果与网页版一致，但多了一个本地客户端的历史记录和自定义界面。

两种接入方式各有取舍：

如果机器配置跑不动本地模型，或者需要更强推理效果，官方API是合理选择；如果对数据安全敏感，业务数据不能出内网，本地Ollama是唯一解。官方手册里两种方式都覆盖了，我在实际项目里通常会先用官方API做功能验证，确认需求后再把底座切到本地模型。

5.4 在VSCode中通过Cline集成DeepSeek：开发者怎么用AI辅助编码

开发者场景下，DeepSeek也可以直接集成进VSCode辅助编程。从麒麟软件商店安装VSCode，打开扩展面板搜索并安装Cline插件。点击左侧Cline图标打开面板，在API Provider下拉框里选择DeepSeek，填入之前创建的API Key，点击Let's go!按钮完成连接。

配置完成后，在Cline面板输入自然语言需求，比如“写一个读取csv文件并统计每列平均值的Python脚本”，Cline会调用DeepSeek生成代码，并提供执行代码的能力。代码会在当前工程目录里直接运行，如果跑通就能看到输出结果，这比普通聊天工具多了“执行验证”这一步，对开发者来说非常直接。

Cline默认集成的是DeepSeek官方API，不是本地Ollama，所以开发机需要能访问API平台，API用量按token计费。想把Cline指向本地Ollama模型也可以，原理和Chatbox一样，但Cline对API格式的要求更接近OpenAI兼容规范，需要额外做模型映射，前期用官方API最省事。

6. 验证跑通：终端、API与辅助编程三重确认

6.1 终端对话与curl接口验证：确认服务真的活着

部署完成后的第一层验证，是在Ollama服务所在机器上直接对话：

ollama run deepseek-r1:1.5b

进入对话界面输入一个问题，能正常回复，说明模型文件完整、推理可用。但这个验证只覆盖了本机终端，没覆盖网络链路。我每次都会再加一个curl接口验证，模拟客户端发起HTTP请求：

curl http://127.0.0.1:11434/api/generate \ -d '{"model": "deepseek-r1:1.5b", "prompt": "用一句话介绍你自己", "stream": false}'

这条命令直接调用Ollama的generate接口，返回的JSON里包含response字段，就是模型回答内容。接口通了、返回正常，说明服务进程、模型加载、API路由全链路健康。远程验证时把127.0.0.1换成服务器IP，能在目标机器上执行成功，就可以确认11434端口的网络路径也畅通。从那以后我每次部署完，不管时间多紧，都会强制走一遍「ollama run对话 + curl接口调用」的流程，一分钟时间换后面省掉几小时的排查。

6.2 Cline辅助编程验证：把代码生成作为最后确认

第三层验证落在开发者工具上。打开VSCode的Cline面板，输入一个明确的小需求，比如“生成一个Python函数计算斐波那契数列前20项并打印”，确认Cline返回代码，然后点击执行，终端输出对应的数列结果。这里的关键不是看代码写得多好，而是确认API Key有效、插件鉴权通过、网络访问正常，并且代码确实在系统里被执行了。

三个验证都过，这套银河麒麟上的DeepSeek环境才算真正交付：终端验证证明模型和服务在，HTTP接口验证证明网络通道在，Cline执行验证证明开发者工具链在。之后不管是网页端接入还是业务系统调API，都只是在这三条链路上加一层壳而已。希望帮到你。

本文还有配套的精品资源，点击获取