简介这份PDF面向在国产Linux发行版上尝试AI模型本地部署的开发者和运维人员围绕银河麒麟桌面与服务器操作系统梳理DeepSeek的四种使用路径并给出从网页版、桌面客户端到服务器本地部署及代码编辑器集成辅助编程的完整说明。文档结合具体场景讲解DeepSeek接口密钥的获取与客户端接入、Ollama服务安装与启动、DeepSeek-R1模型规格选择以及内网环境下的客户端连接方式同时收录ARM架构下运行库版本缺失等常见问题的处理思路和桌面端部署过程截图便于读者对照排查环境差异。压缩包共1个PDF文件大小约1.98MB适合单机查阅或在内部网络传阅。已有513人学习适合需要快速理解银河麒麟平台上DeepSeek部署路径、评估客户端与本地部署方案或为国产化环境AI应用落地做技术选型的读者参考。1. 模型跑起来了却连不上一个把我卡了整个下午的 11434 端口在银河麒麟上做 DeepSeek 本地化部署最容易翻车的不是模型本身而是「服务端明明跑着客户端死活连不上」。我见过太多次这样的场景ollama serve 起来了终端里 ollama run deepseek-r1:1.5b 也能正常对话转头在桌面端 Chatbox 里填上服务器 IP点保存就卡在转圈。这类故障在国产 Linux 发行版上尤其密集——GLIBCXX 缺符号、监听地址被钉在 127.0.0.1、防火墙没放行、模型目录跟着服务用户走丢单拎一个都不难凑在一起就是一整天。这篇笔记按「现象 → 根因 → 命令」的顺序把从装到通的全链路故障拆开适合手里正卡着一条报错、想直接照着敲的人。2. ollama 装不上aarch64 上 GLIBCXX_3.4.25 缺失怎么补2.1 先把报错读全缺的到底是哪个符号典型现场是这样的在 ARM 架构的服务器上按官方脚本装完 ollama敲ollama --version终端直接吐一行ollama: /usr/lib64/libstdc.so.6: version GLIBCXX_3.4.25 not found (required by /usr/local/bin/ollama)有时换个写法是CXXABI_1.3.11 not found。第一次见这行容易懵它既不说清哪个库缺也不告诉你该怎么装回去。其实信息已经给全了/usr/local/bin/ollama这个可执行文件在加载时向/usr/lib64/libstdc.so.6索要一个叫GLIBCXX_3.4.25的符号版本而当前这个库最高只提供到GLIBCXX_3.4.22不同系统版本数字有差异。先确认两件事别急着动手# 1. 确认 CPU 架构后面取库文件要用 uname -m # 2. 看系统当前 libstdc 支持到哪个 GLIBCXX 版本 strings /usr/lib64/libstdc.so.6 | grep -E ^GLIBCXX_ | sort -V | tail -5第一条在 ARM 服务器上返回aarch64x86 上返回x86_64。这个值必须记下来后面拷错架构的库是新手最常犯的错症状比原报错还迷惑——程序不再报缺符号而是直接Segmentation fault或者wrong ELF class: ELFCLASS64。第二条的输出形如GLIBCXX_3.4.19到GLIBCXX_3.4.22这样一列最后一行就是天花板。低于 3.4.25就必须换库没有别的路。命令逻辑说明strings把二进制里的可打印字符串全扒出来grep -E ^GLIBCXX_只留符号版本行sort -V按版本号数值排序不能省纯字典序会把 3.4.9 排到 3.4.25 后面tail -5取最高的五个。这条命令还有第二个用途——修完之后再跑一遍看到 3.4.25 出现在列表尾部就说明库已经换对了。2.2 根因符号版本是单向兼容的GLIBCXX_*和CXXABI_*是 GCC 给 libstdc 打的符号版本标签。每个版本的 GCC 编译 C 程序时会往二进制里写入「我至少需要 GLIBCXX_X.Y.Z」运行时动态链接器拿着这张需求表去 libstdc.so.6 里核对查不到对应版本号就拒绝加载进程。所以这不是路径问题也不是权限问题是版本契约没满足。关键点在于兼容方向只有一个新库能跑旧程序旧库跑不了新程序。ollama 官方发布的二进制是用较新的工具链编出来的依赖 GLIBCXX_3.4.25 以上而部分麒麟系统版本出厂自带的 libstdc对应的是 GCC 8 之前的工具链顶格只到 3.4.22 或 3.4.24。两边对不上就是那一行报错。明白这一点解法就唯一了把 libstdc.so.6 换成更新的、且架构必须一致的版本。别去改 ollama 的二进制也别指望ldd能自动治好。2.3 一次做对的替换流程含回滚替换前先找到库的真实路径不同发行版和架构下它未必在/usr/lib64ldconfig -p | grep libstdc.so.6输出会给你完整路径常见的是/usr/lib64/libstdc.so.6或/usr/lib/aarch64-linux-gnu/libstdc.so.6。下面按/usr/lib64写路径不同的自行替换。拿到一份libstdc.so.6.0.28这份部署手册里随附了对应架构的库文件也可以从一台 GCC 版本更高、架构相同的机器上拷一份按顺序执行# 1. 先看清原始软链接指向回滚的唯一线索 ls -l /usr/lib64/libstdc.so.6 # 2. 把新库放进系统库目录 cp libstdc.so.6.0.28 /usr/lib64/ # 3. 进目录再操作避免手滑路径写错 cd /usr/lib64/ # 4. 原软链接改名保留不删 mv libstdc.so.6 libstdc.so.6.bak # 5. 建立指向新库的软链接 ln -s libstdc.so.6.0.28 libstdc.so.6 # 6. 刷新动态链接器缓存 ldconfig # 7. 双重验证 strings /usr/lib64/libstdc.so.6 | grep GLIBCXX_3.4.25 ollama --version参数和逻辑说明第 1 步的ls -l不是仪式它会告诉你原来的libstdc.so.6指向libstdc.so.6.0.19还是6.0.24这是回滚时唯一的依据。第 4 步用mv而不是rm因为软链接本身只是个路径指针改名保留零成本删掉就得凭记忆重建。第 5 步ln -s的两个参数顺序别写反第一个是目标文件第二个是链接名反了会造出一条指向不存在文件的死链。第 6 步ldconfig刷新/etc/ld.so.cache跳过它的话某些程序仍会命中旧缓存表现出来就是「明明换了库还是报同样的错」。第 7 步两条验证缺一不可strings证明库里确实有这个符号ollama --version证明程序真的能加载起来。只做前者容易撞上假象——符号有了但程序照旧报错那基本是路径不对或缓存没刷。回滚就是把第 4、5 步倒过来cd /usr/lib64/ rm libstdc.so.6 mv libstdc.so.6.bak libstdc.so.6 ldconfig2.4 三个会让你二次翻车的细节第一个是架构。ARM 服务器上千万别拿 x86_64 的库文件症状是wrong ELF class: ELFCLASS64或者干脆段错误。取库前用uname -m确认一次拷进去之后再确认一次file /usr/lib64/libstdc.so.6.0.28 # 期望输出末尾出现 ARM aarch64而不是 x86-64第二个是覆盖式拷贝。有人图省事直接把新库cp成libstdc.so.6把软链接结构冲掉了。当时能用但系统里其他依赖旧版本号路径的脚本会开始出怪毛病而且回滚时你已经不知道原始指向是谁。软链接切换是唯一稳妥的姿势多敲两行命令换来的是可回退。第三个是临时方案骗人。用export LD_LIBRARY_PATH/opt/lib64把新库路径塞进环境变量确实能让 ollama 当场跑起来但只要你改用systemctl start ollamasystemd 并不继承你 shell 里的环境变量服务又挂回原来那条错。要么把库装进系统目录要么在 unit 文件里写死EnvironmentLD_LIBRARY_PATH...二选一别指望 export 能扛过重启。3. ollama serve 起不来、外部连不上监听地址与 systemd 的坑3.1 先分清「起不来」和「起得来但连不上」这两种现象的处理路径完全不同第一步必须分清。起不来的典型表现是进程直接退出终端留下bind: address already in use或者Error: listen tcp 127.0.0.1:11434: bind: permission denied。这类属于端口层面的事去看ss -lntp就够了。起得来但连不上更隐蔽服务好好地跑着本机能聊别的机器连不进去。这时候别去猜先看启动日志里那行Listening onollama serve # time2025-... levelINFO msgListening on 127.0.0.1:11434 (version 0.x.x)这行就是答案本身。127.0.0.1意味着只有本机回环能连任何跨机器的请求都会被内核直接丢掉——注意是丢掉不是拒绝。所以客户端看到的是超时转圈而不是干脆利落的 connection refused。这个差别在排查时很值钱连接被拒绝说明包到了机器但没有进程接超时说明包压根没到或者被静默丢弃两者指向的环节不同。3.2 OLLAMA_HOST 怎么设才真的生效临时验证用下面这套开两个终端# 终端 A带环境变量启动 export OLLAMA_HOST0.0.0.0 export OLLAMA_ORIGINS* ollama serve# 终端 B确认监听地址变了 ss -lntp | grep 11434期望看到LISTEN 0 4096 0.0.0.0:11434 0.0.0.0:*。如果还是127.0.0.1:11434基本就是变量没吃到——检查是不是在同一个终端里、是不是先 export 再启动。参数说明OLLAMA_HOST0.0.0.0让 ollama 监听所有网卡也可以写成0.0.0.0:11434显式指定端口。别写成http://0.0.0.0:11434部分版本解析不了带协议头的值会静默退回默认地址排查时就变成了玄学。OLLAMA_ORIGINS*是给浏览器跨域用的纯 API 调用可以不设但只要有网页前端直连不设就撞 CORS。要长期生效必须落到 systemd否则关掉终端就失效systemctl edit ollama.service编辑框里填[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_ORIGINS*保存后执行systemctl daemon-reload systemctl restart ollama systemctl show ollama -p Environmentsystemctl edit生成的是/etc/systemd/system/ollama.service.d/override.conf这样一个 drop-in 文件不会覆盖原 unit升级 ollama 时也不会被冲掉。最后那条systemctl show -p Environment是关键一步它直接打印进程实际拿到的环境变量——太多「我明明改了配置」的案子最后都发现改的是另一个路径下的 unit 文件。3.3 端口冲突与防火墙这两个外部因素端口冲突最常见的来源是之前手动ollama serve过没关又启了 systemd 服务。systemd 版以 ollama 用户身份运行手动版以当前登录用户运行两个进程抢同一个端口后起的那个直接报address already in use。# 看谁占着 11434 ss -lntp | grep 11434 # 清干净再起 systemctl stop ollama pkill -f ollama serve sleep 2 systemctl start ollamasleep 2不是凑数端口释放到内核回收有个短暂窗口立刻重启有一定概率还抢不到。防火墙更隐蔽因为它完全不报错。麒麟服务器版默认开着 firewalldsystemctl status firewalld firewall-cmd --list-ports firewall-cmd --permanent --add-port11434/tcp firewall-cmd --reload firewall-cmd --list-ports注意--permanent和--reload必须成对出现。只敲前面那条规则写进了配置文件但没加载到运行时--list-ports里看得见、实际不通重启之后才生效。这个时间差骗过不少人症状就是「我明明加了端口怎么还是连不上」。3.4 四步验证链把「连不上」切成四段从内到外一条条打通每一步失败指向的环节都不一样# 第 1 步服务在不在监听监听在哪 ss -lntp | grep 11434 # 第 2 步本机回环能不能拿到响应 curl -s http://127.0.0.1:11434/api/tags | head -c 200 # 第 3 步用本机的业务 IP 请求自己验证绑定地址 curl -s http://192.168.1.100:11434/api/tags --max-time 5 # 第 4 步从客户端机器发起验证网络与防火墙 curl -sv http://192.168.1.100:11434/api/tags --max-time 5/api/tags比根路径有用得多它返回的是模型清单 JSON一次能同时验证「服务活着」和「模型在不在」。第 2 步通、第 3 步不通问题在监听地址第 3 步通、第 4 步不通问题在网络或防火墙第 4 步返回 200 而客户端还是连不上问题就在客户端的填写方式——域名有没有带http://、端口有没有写、末尾有没有多打一个/api。参数说明-s静默进度条让输出干净-v打印请求和响应头排查 4xx/5xx 时必加--max-time 5强制超时否则网络不通时 curl 会吊很久很容易让人误判成「程序卡死」。4. 模型拉不下来、拉下来跑不动尺寸选择和离线搬运4.1 卡在 pulling manifest 的三种可能ollama run deepseek-r1:1.5b第一次执行会先拉模型终端上滚出一行pulling manifest然后就没了动静。卡在这一步先分清是三种情况中的哪一种。第一种是网络慢但没断。耐心等几分钟或者按 CtrlC 重来一次——ollama 的拉取是支持断点续传的重复执行不会从头下载。判断依据是看终端有没有小进度条在动。第二种是出网受限。内网机器、白名单环境、镜像源不通日志里会出现dial tcp ... i/o timeout或者net/http: TLS handshake timeout。这种别硬等直接走 4.3 的离线搬运。第三种是磁盘满了。这个最容易被误判成网络问题因为报错经常出现在拉取末尾df -h df -h /usr/share/ollama du -sh /usr/share/ollama/.ollama/modelsollama 的模型默认落在服务用户的 home 下systemd 启动时是/usr/share/ollama/.ollama/models。一个 7b 模型解压后光 blobs 目录就能吃掉好几个 G系统盘留得紧的话很容易在拉取到最后一步时写失败回滚又把空间还回来看起来就像「怎么也拉不下来」。4.2 尺寸怎么选先把内存账算清楚deepseek-r1后面那个数字是参数量不是文件大小但两者强相关。选模型的唯一标准是机器扛不扛得住先看内存和显存再看 CPU 核数。模型标签下载体积量级运行内存建议适用场景deepseek-r1:1.5b1 GB 出头4 GB 以上验证链路、轻量问答、桌面机试水deepseek-r1:7b / 8b5 GB 左右16 GB 起单机自用、代码补全、内部知识问答deepseek-r1:14b9 GB 左右24 GB 起多人共享的小型推理服务deepseek-r1:32b20 GB 左右32 GB 以上需要较好推理质量的团队场景deepseek-r1:70b40 GB 以上64 GB 以上服务器级部署纯 CPU 基本不可用表里的体积是量级参考不同量化版本会有出入。实践中的判断口径是内存至少给到模型体积的两倍再留 20% 给系统和 ollama 自身。服务器上如果是国产 GPUollama 未必能识别会自动回落 CPU真实可用的上下文长度和并发都会明显下降这属于预期之内。# 看系统内存和 swap free -h # 看 ollama 实际把模型放在哪个设备上跑 ollama psollama ps输出的 PROCESSOR 列很关键显示100% CPU就说明没吃到 GPU后面觉得「跑得慢」时第一个要看的就是这个。4.3 内网机器怎么把模型搬进去完全不出网的环境里最省事的做法是在一台能出网的机器上把模型拉好然后把整个 models 目录搬过去。ollama 的模型是 blobs 加 manifests 的结构整目录拷贝即可识别不需要额外注册。# 出网机器拉好模型确认存在 ollama pull deepseek-r1:1.5b ollama list # 打包路径以 systemd 服务用户为准 sudo tar -czf ollama-models.tar.gz -C /usr/share/ollama .ollama/models # 拷到内网机器后解包 sudo mkdir -p /usr/share/ollama/.ollama sudo tar -xzf ollama-models.tar.gz -C /usr/share/ollama # 权限必须还给 ollama 用户否则服务读不到 sudo chown -R ollama:ollama /usr/share/ollama/.ollama sudo systemctl restart ollama ollama list逻辑说明打包时-C /usr/share/ollama指定根目录后面写相对路径.ollama/models解包时对应-C /usr/share/ollama两端路径要对齐否则会多套一层目录服务找不到模型。chown那一步千万不能省——tar 默认保留原机器的属主到了新机器上 ollama 用户没权限读 blobs症状是ollama list空的、ollama run又开始重新下载。这里有个高频坑手动跑ollama serve时模型放在当前用户的~/.ollama/models换成 systemd 服务模型目录变成/usr/share/ollama/.ollama/models。所以你手动 pull 的模型切到服务后ollama list是空的。判断方法很直接ls -lh ~/.ollama/models 2/dev/null ls -lh /usr/share/ollama/.ollama/models 2/dev/null哪边有 blobs 目录模型就在哪边。要么挪过去要么改服务用户的 HOME别指望它会自己找。4.4 跑起来但慢得离谱先看 ollama ps 再谈优化模型能跑只是慢这种情况比报错更难判断。第一件事是ollama ps看 PROCESSOR 列第二件事是看上下文长度。两者占了慢的大头。ollama 默认上下文窗口不大deepseek-r1这类模型处理长文档时会不断截断和重算表现就是「前面几句很快越到后面越慢」。如果真的需要长上下文通过 Modelfile 显式指定# 新建一个 Modelfile把上下文调大 cat Modelfile EOF FROM deepseek-r1:1.5b PARAMETER num_ctx 8192 EOF # 用自定义配置创建新标签 ollama create deepseek-r1:1.5b-8k -f Modelfile ollama run deepseek-r1:1.5b-8k参数说明FROM指定基础模型num_ctx是上下文窗口的 token 数数字越大内存占用越高翻倍是常态。1.5b 这种小模型在 CPU 上把 num_ctx 拉到 8k单轮响应可能要十几秒所以别一味往上加先按实际文档长度取一个够用的值。改完用ollama ps复核输出里会显示当前上下文和处理器占用。纯 CPU 推理要建立合理预期1.5b 在普通服务器 CPU 上能到每秒十几到几十个 token7b 掉到个位数再大就基本只能离线批处理了。指望在纯 CPU 上跑 32b 做实时对话是注定会失望的选择这跟配置调优无关是算力账。5. 常见问题五个让我返工过的配置细节5.1 客户端模型列表空白现象Chatbox 里「模型提供方」选了 OLLAMAAPI 域名填了服务器 IP 和 11434 端口下面「模型」下拉框空空如也保存按钮点下去也没反应。原因有两个层面。服务端层面是模型压根不在服务用户目录下或者 ollama 服务没起来客户端层面是域名写法不对缺http://前缀或者末尾多打了/api。ollama 的接口根路径本身就是/api客户端会自己拼手填上去就变成了/api/api/tags返回 404界面表现出来就是一片空白。解决顺序是先验服务端再改客户端# 服务端先自证清白 curl -s http://127.0.0.1:11434/api/tags # 应返回 {models:[{name:deepseek-r1:1.5b,...}]}如果这里返回的是空 models 数组问题在服务端回去查模型目录和ollama list。如果这里正常把客户端域名改成http://192.168.1.100:11434这种形式——协议头带上、端口带上、后面什么都不加保存后重开设置页让它重新拉取列表。5.2 API Key 明明是对的却报 401现象VSCode 里装了 Cline 插件Provider 选 DeepSeek把 API Key 粘进去点确认返回 401 Unauthorized 或者「认证失败」。原因通常是三类。一是 Key 复制时带了首尾空格或换行粘贴进去肉眼看不出来二是 Key 复制不全这类 Key 在创建页只完整展示一次后面再进来看就是打码的很多人复制了打码后的那一段三是 Provider 选错了选成 OpenAI Compatible 却只在 Key 栏填了 DeepSeek 的 KeyBase URL 还是 OpenAI 的自然对不上。# 检查 Key 长度和首尾字符DeepSeek 的 Key 形如 sk- 开头的一长串 printf %s sk-你的key | wc -c printf %s sk-你的key | od -c | head -2printf %s而不是echo是因为echo会自动补一个换行让长度校验失真。od -c看首尾有没有多余的空格或\r——从网页复制到终端时Windows 风格的换行残留很常见肉眼完全看不出来。确认无误后重新在控制台创建一把新 Key旧的那把直接作废比反复试错快得多。5.3 浏览器直连接口被 CORS 拦下现象自己写了个简单页面调http://192.168.1.100:11434/api/generate浏览器控制台红字一片提示has been blocked by CORS policy: No Access-Control-Allow-Origin header is present。用 curl 一模一样的地址却能通。原因CORS 是浏览器单方面的限制curl 不受约束所以「curl 通」不代表浏览器能通。ollama 默认只允许来自127.0.0.1和localhost的 Origin你的页面部署在别的地址上就被拦了。解决是给服务端加白名单然后重启# 临时验证 export OLLAMA_ORIGINS* ollama serve # 永久生效写进 systemd systemctl edit ollama.service在 drop-in 里加EnvironmentOLLAMA_ORIGINS*daemon-reload后重启。生产环境别图省事一直用*写成具体的来源地址更稳妥OLLAMA_ORIGINShttp://192.168.1.50:8080这种形式多个来源用逗号分隔。加完记得刷新浏览器缓存住的预检结果会让你以为配置没生效。5.4 换了模型客户端还显示旧的现象服务器上把 1.5b 删了换成 7bollama list确认已经切换但桌面客户端里模型下拉还是显示deepseek-r1:1.5b选中后对话直接报模型不存在。原因客户端把上一次拉到的模型列表缓存住了切设置页不会自动重拉。另外ollama rm删模型和ollama pull拉新模型之间如果没重启服务个别版本的服务端内存里还留着旧索引。解决是两头都刷新# 服务端确认实际状态 ollama list systemctl restart ollama客户端那边退出应用重进或者把 API 域名改成一个错的地址保存、再改回来保存强制它重新请求一次/api/tags。这个操作看着土但比重装客户端快得多。5.5 磁盘被模型撑爆报 no space left on device现象拉取模型到最后一步失败终端刷出no space left on device或者ollama run中途进程被杀。原因每个模型标签在 blobs 目录里是一份独立的大文件同一模型的多个量化版本会各存一份不共享。频繁试不同尺寸的机器几个月下来吃掉几十 G 很常见。# 看谁在占地方 du -sh /usr/share/ollama/.ollama/models ollama list # 删掉不用的 ollama rm deepseek-r1:32b # 确认空间回来了 df -h /usr/share/ollamaollama rm只删标签引用如果某个 blob 还被别的标签共享着它不会被清掉这是设计如此别去手动删 blobs 目录里的文件——删错一个剩下的模型全部失效只能重新下载。真要腾空间先ollama list看清有哪些一个一个rm再用du -sh复核。6. 快速定位五段式排查链从客户端倒推到服务端这套问题排查久了会发现报错五花八门但真正卡住的环节就那么几个。我的习惯是准备一张对照表先按现象定位到段再去那一段里找具体原因比漫无目的地试快得多。现象最可能卡在哪先敲这条期望结果敲 ollama 直接报 GLIBCXX not found系统库版本strings /usr/lib64/libstdc.so.6 | grep GLIBCXX_3.4.25有版本号输出客户端填 IP 后一直转圈监听地址ss -lntp | grep 114340.0.0.0:11434 而非 127.0.0.1本机 curl 通、客户端不通防火墙firewall-cmd --list-ports列表里有 11434/tcp模型下拉框空白域名写法或服务端无模型curl -s http://IP:11434/api/tags返回带 name 字段的 JSON拉模型卡在 pulling manifest出网能力或磁盘空间df -h /usr/share/ollama剩余空间大于模型体积两倍能跑但慢到没法用回落 CPU 或上下文过大ollama psPROCESSOR 列不是 100% CPU用这张表有个前提从服务端往外推而不是从客户端往里猜。服务端只有一条链路监听地址、模型目录、防火墙查完就完了客户端那边写法千奇百怪域名带不带协议、端口写没写、有没有多打后缀可能性是发散的。先把服务端钉死客户端的嫌疑范围立刻收窄到写法问题。日志是最后一个黑匣子很多人跳过了它直接看现象。systemd 起的 ollama日志全在 journald 里p a hrefhttps://download.csdn.net/download/che2014/90405259 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p