简介:这份PDF面向银河麒麟操作系统的运维人员、AI应用开发者及入门用户,重点解决国产操作系统上部署DeepSeek大模型时环境配置复杂、依赖易出错、缺少交互界面等痛点,系统讲解桌面与服务器两种环境下的本地化部署路径。资源共1个文件,格式为PDF,包体大小1.98MB,内容涵盖网页版、客户端应用、本地部署及客户端与本地部署结合四种使用场景。书中不仅给出安装ollama、启动服务、选择DeepSeek-R1模型等完整流程,还针对ARM架构服务器可能出现的GLIBCXX缺失问题提供具体解决办法,并演示了通过Chatbox客户端接入API、在VS Code中集成DeepSeek辅助编程的操作。另有银河麒麟桌面操作系统部署全过程截图,便于对照实践。文档由麒麟软件生态技术服务中心编写,截至当前已有509人学习下载,适合希望在内网环境或国产化平台上快速落地DeepSeek的读者。
1. DeepSeek 本地化部署,难的不是模型而是系统环境
一台只有 8GB 内存、没有独立显卡的旧台式机,装上麒麟桌面系统后想跑 DeepSeek 的本地问答模型,大多数人第一反应是“不现实”。但拆开《基于银河麒麟桌面&服务器操作系统的DeepSeek本地化部署方法》这个标题来看,它真正要解决的核心并不是模型有多聪明,而是在国产操作系统上把模型稳定跑起来这条链路:软件源通不通、GPU 驱动能不能被识别、模型量化选哪个档位、服务怎样常驻、端口怎样对内网开放。这个方向的现实价值非常明确:数据不出内网、调用不依赖外部接口、断网也能用,适合内网办公、数据敏感或对模型自主可控有要求的运维和算法团队。下面按我实际部署时的顺序,从硬件盘点到服务调优逐步拆开讲。
2. 先盘资源再谈模型:麒麟系统上的硬件识别与驱动适配
2.1 部署前必须跑完的一套诊断命令
拿到一台要装 DeepSeek 的麒麟机器,别急着往环境里灌依赖。我一般会先花五分钟把家底盘清楚,再决定用哪套方案。下面这组命令在任何麒麟 V10 桌面版或服务器版上都通用:
uname -a # 内核版本,决定驱动包配套 lspci | grep -i vga # 看显卡型号和总线信息 nvidia-smi # 若存在则输出 NVIDIA 驱动和显存信息 free -h # 物理内存总量和剩余 df -h / /tmp # 根分区和临时分区剩余空间 nproc # CPU 核数,影响并发能力这组命令的输出直接决定后续选型。uname -a看内核小版本,因为麒麟对内核头的依赖很敏感,装 GPU 驱动时必须让驱动包和内核头文件版本对齐,差一个小版本都可能编译失败。lspci | grep -i vga可以确认显卡型号是 N 卡还是 A 卡,如果输出为空,说明大概率是核显或纯 CPU 环境。nvidia-smi存在且能正常输出,说明驱动已经就位,可以直接走 GPU 推理路线;如果提示command not found,不是驱动没装就是装了没进 PATH,后面要补。df -h / /tmp是很多人忽略的一步,大模型下载和解压对磁盘空间的要求往往是模型体积的两倍,根分区只剩两三 GB 时,模型拉到一半会直接报文件校验失败。
2.2 驱动适配:N 卡、A 卡、纯 CPU 三条路线怎么选
硬件识别完以后,接下来是驱动适配。麒麟系统的驱动问题比普通 Ubuntu 更敏感,因为系统源里的内核头文件和 GPU 厂商驱动包的版本匹配不一定及时。我在这块吃过不少亏,总结下来三条路:
| 硬件场景 | 推荐部署路线 | 主要坑点 |
|---|---|---|
| N 卡,显存 ≥ 6GB | Ollama 直接调用 CUDA 推理,装好官方驱动后自动识别 | 驱动包和内核版本不匹配,安装时被 DKMS 编译失败 |
| A 卡,显存 ≥ 8GB | 尝试 ROCm 或 Vulkan 后端,稳定后再跑模型 | 麒麟源里的 ROCm 组件不完整,兼容性经常翻车 |
| 无独显 / 纯 CPU | 选 7B/8B 及以下参数量的 4bit 量化模型 | 并发和上下文窗口必须压得很小,否则响应极慢 |
N 卡环境驱动安装的标准步骤是,先把内核头文件装上再跑安装包:
sudo apt update sudo apt install -y linux-headers-$(uname -r) sudo bash NVIDIA-Linux-*.run --no-opengl-files这里--no-opengl-files很关键,麒麟桌面系统默认带有 OpenGL 桌面合成组件,驱动安装时不加这个参数容易把桌面搞崩。装完以后用nvidia-smi验证,能看到显卡型号和显存就说明驱动层没问题。A 卡用户我一般不建议在麒麟上死磕 ROCm,除非应用明确要求 GPU 加速;更稳的做法是先让模型在 CPU 上跑通业务,后续再评估硬件加速。麒麟的 CPU 推理能力没有想象中弱,7B 量化模型跑文本对话,响应速度能接受,只是并发别开太大。
2.3 软件源与基础依赖:先解决“apt 慢”和“缺包”两个问题
驱动准备好以后,下一步是让 apt 源可用且够快。麒麟系统的默认软件源在不同网络环境下差异很大,有的机器访问默认源极慢,有的甚至直接超时。我通常会先备份原始源文件,再把源地址替换为内网提供的镜像地址:
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i 's#http://archive.kylinos.cn#http://你的内网镜像地址#g' /etc/apt/sources.list sudo apt update sudo apt install -y curl wget git python3-pip python3-venvsed替换源地址时注意看原始源里的路径结构,不同版本的麒麟源路径前缀不完全一样,把前缀改成镜像站的根地址即可。基础依赖里python3-venv是必须装的,后面会单独讲为什么麒麟自带的 Python 环境里直接pip install会碰壁。装完以后顺手验证一下三个工具的版本,能输出版本号就说明基础层准备好了。这一步做完,环境准备才算真正结束。
3. 选对 DeepSeek 版本:从 R1 蒸馏系列到离线安装的完整链路
3.1 DeepSeek 的“三档”选型:先搞清楚本地能跑多大参数
DeepSeek 官方模型分推理导向的 R1 系列和通用对话导向的 V3 系列,原版模型体积对单机部署很不友好,动辄几百 GB 的权重文件,普通服务器根本吃不下。真正让单机本地化部署变得可行的是 R1 的蒸馏版本,它们用更大的教师模型蒸馏出小参数模型,部署体积和显存占用都降了一个数量级。我根据自己的部署经验,整理了一张选型对照表:
| 模型标签 | 4bit 量化后体积 | 推理所需显存(约) | 适合场景 |
|---|---|---|---|
| deepseek-r1:1.5b | 约 1.1GB | 2GB 以下 | 简单问答、文本摘要、分类 |
| deepseek-r1:7b / 8b | 约 4.7GB | 6GB 左右 | 日常对话、代码生成 |
| deepseek-r1:14b | 约 9.0GB | 11GB 左右 | 复杂推理、长文本理解 |
| deepseek-r1:32b | 约 20GB | 22GB 以上 | 接近完整能力的业务场景 |
| deepseek-r1:70b | 约 43GB | 48GB 以上 | 多卡或大显存专用服务器 |
蒸馏版模型的优势是体积小、部署快,代价是复杂推理能力相比完整版 R1 有明显衰减。比如 1.5B 模型做长链条数学推理会很吃力,而 14B 版本在代码生成和逻辑分析上明显更稳。选型时先看你手头机器的显存和内存,再反推模型档次,不要一上来就拉最大号的模型,那不是部署,是给自己挖坑。
3.2 在线、离线、断点续传:三种拉取模型的方式
模型运行框架我建议用 Ollama,它对麒麟系统的兼容性比直接跑 Python 推理框架省事得多。联网环境最简单,直接拉取模型:
ollama pull deepseek-r1:7b # 拉取 7B 蒸馏版,约 4.7GB ollama list # 查看本地已有模型 ollama rm deepseek-r1:1.5b # 删除不用的模型释放磁盘内网环境拉不了的场景更常见。这时候需要在一台能联网的机器上提前下载 GGUF 格式的权重文件,然后拷贝到麒麟机器上,用 Modelfile 手动创建模型:
# Modelfile 内容 FROM /data/models/deepseek-r1-7b.Q4_K_M.gguf # 然后用 ollama create 创建本地模型 cd /data/models ollama create deepseek-r1:7b -f ModelfileQ4_K_M是量化格式的名字,它表示 4bit 量化、K 均值划分、中间档大小,是体积和质量的折中档;想要更高精度可以用Q6_K,代价是体积和显存占用增加。断点续传方面,ollama pull会保留已下载的分片,网络中断后重新执行同一条命令会从断点继续,不用删掉重来。但前提是磁盘剩余空间充足,所以模型存放目录所在分区至少要留出模型体积两倍的空间。
3.3 Python 二次开发:调用 DeepSeek 服务的最小代码
部署不只是为了在终端里聊天,更多场景是要给内部系统提供接口。用 Python 的 ollama 客户端库可以快速接上服务:
from ollama import Client client = Client(host='http://127.0.0.1:11434') resp = client.chat( model='deepseek-r1:7b', messages=[ {'role': 'user', 'content': '写一个清理麒麟系统日志的 shell 脚本'} ], options={ 'num_ctx': 4096, # 上下文窗口长度,越大越占显存 'temperature': 0.6 # 低温度让输出更稳定,适合代码类任务 } ) print(resp['message']['content'])这里host参数指向 Ollama 服务的监听地址,如果服务部署在另一台机器,改成那台机器的 IP 即可。num_ctx是上下文窗口长度,决定了模型能“记住”多少输入内容;数值越大,可处理的输入越长,但显存开销也随之上升。temperature在代码生成和结构化输出场景建议调低到 0.6 以下,否则模型容易自由发挥。需要流式输出时,把client.chat换成client.chat的stream=True参数,适合对接前端打字机效果。
4. 从“跑通一次”到“服务常驻”:麒麟服务器版上的 systemd 管理与端口配置
4.1 用 systemd 把 Ollama 注册成守护进程
在终端里启动 Ollama 只能算“跑通了”,重启机器或断开终端后服务就没了。真正要拿出去给业务用,必须把服务交给 systemd 管理。麒麟服务器版默认使用 systemd,写一个服务单元文件即可:
sudo cat > /etc/systemd/system/deepseek-ollama.service << 'EOF' [Unit] Description=DeepSeek Ollama Service After=network-online.target Wants=network-online.target [Service] Type=simple User=deepseek-runner Group=deepseek-runner Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models" ExecStart=/usr/local/bin/ollama serve Restart=always RestartSec=10 [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now deepseek-ollama.service sudo systemctl status deepseek-ollama.service --no-pager -l几个关键点说明一下。User=deepseek-runner是建议单独创建的运行账号,不用root跑服务,避免模型目录权限过大。Environment="OLLAMA_MODELS=/data/ollama/models"把模型存放到数据盘而不是根分区,防止根分区被模型文件塞满。ExecStart的路径要用which ollama查一下实际安装位置,麒麟不同版本安装路径可能有差异。如果模型目录由别的用户创建过,要注意属主和权限问题,用chown -R deepseek-runner:deepseek-runner /data/ollama修正。
4.2 端口与防火墙:只让业务网段访问
服务监听0.0.0.0:11434后,任何能访问到这台机器 11434 端口的人都能调用模型接口。麒麟服务器版默认启用 firewalld,需要显式放行端口:
# 查看 firewalld 状态,没启动则先启动 sudo systemctl status firewalld # 放行 11434 端口,并限定只允许内网某个网段访问 sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 port port=11434 protocol=tcp accept' sudo firewall-cmd --reload sudo firewall-cmd --list-all这里用富规则而不是简单--add-port,目的是限制来源 IP 范围。如果你调用的机器可能分布在多个网段,可以把富规则复制几条,分别指定不同网段。注意麒麟桌面版默认可能没有启用 firewalld,此时用ufw status检查,没启用的话可以先用firewalld顶上,别裸奔。公网环境下这个端口绝不能直接暴露,必要的话前面加一层反向代理做鉴权。
4.3 资源监控与日志走查:服务挂掉前提前发现
服务常驻以后,我最担心的不是服务崩,而是显存被慢慢吃满后模型开始频繁换入换出,响应越来越慢。日常巡检我习惯用一行命令循环看状态:
# 每两秒刷新一次显存和内存状态 watch -n 2 nvidia-smi --query-gpu=utilization.gpu,memory.used --format=csv # 实时跟随 Ollama 服务日志 sudo journalctl -u deepseek-ollama.service -f显存使用率接近上限时,说明并发请求或上下文长度超过了当前模型的承载能力,这时候要考虑减小num_ctx或限制并发。日志方面,journald 默认会占用不少磁盘空间,建议设置日志上限,比如限制为 200MB,避免服务跑久了把根分区挤爆:
sudo journalctl --vacuum-size=200M这个清理命令可以配合 crontab 每周执行一次,属于运维上很小的习惯,但能避免很多“莫名其妙磁盘满”的问题。
5. 常见问题与避坑记录:在麒麟上部署 DeepSeek 的四个典型翻车
5.1 pip install 被系统环境拦住,提示 externally-managed-environment
麒麟自带的 Python 版本较新时,直接用pip3 install ollama大概率会看到一条名为externally-managed-environment的报错。现象是 pip 拒绝安装任何包,提示当前 Python 环境由系统管理,不能随意写入。原因不是权限问题,而是 Python 3.11 之后启用了 PEP 668 保护机制,麒麟的 Python 包被打上了外部管理标记,防止 pip 破坏系统组件。解决方法是优先使用虚拟环境:
python3 -m venv /opt/deepseek-env source /opt/deepseek-env/bin/activate pip install ollama虚拟环境隔离了系统 Python,后续装任何依赖都不会污染系统环境。如果非要直接装到系统环境里,也可以用pip install --break-system-packages强行绕过,但这只能作为应急手段,不建议长期依赖。
5.2 模型已经在跑,但 nvidia-smi 里看不到 GPU 进程
有 GPU 的机器部署后,用ollama ps查看模型运行状态,发现PROCESSOR列显示的是CPU,而nvidia-smi里也没有任何进程。原因通常有两个:一是安装的 Ollama 二进制是 CPU 版,官方一键脚本在部分麒麟版本上自动选择了不带 CUDA 的构建;二是驱动安装时没装好,ollama 找不到 CUDA 运行库。解决方法是先确认nvidia-smi能正常输出,再下载对应 GPU 版本的 Ollama 二进制替换/usr/local/bin/ollama,重启服务后再用ollama ps验证。这种问题不算玄学,多数是安装包的版本选择不对。
5.3 模型拉取到一半失败,重新执行还是卡在同一个进度
ollama pull下载到某个百分比后报错退出,再执行还是卡在同一位置。最常见的原因是磁盘空间不足,下载临时文件没法落盘;其次是把模型目录放在一个容量很小的分区上。特征是df -h一看,目标分区余量只剩几百 MB。解决方法是把模型目录迁移到数据盘:
sudo mkdir -p /data/ollama/models sudo chown -R deepseek-runner:deepseek-runner /data/ollama # 在 systemd 服务中修改 Environment 指向 /data/ollama/models # 然后重启服务,重新执行 ollama pull这里要注意,迁移目录后原来已下载的模型不会自动跟着走,需要重新拉取或手动拷贝。所以更稳的做法是一开始就把OLLAMA_MODELS指向数据盘,别等出了问题再搬。
5.4 模型输出到一半就停住,长回答总被截断
现象是让模型写一段较长的代码或文章,生成到一半突然停止,没有任何报错。原因和上下文长度有关:num_ctx设置得偏小,模型在生成时超过上下文窗口后,新内容无法继续写入,于是戛然而止;另一层原因是并发请求过多,显存中缓存被多个任务抢占。解决方法是把num_ctx调大,同时限制并行请求数,在 systemd 服务中添加环境变量:
Environment="OLLAMA_NUM_PARALLEL=1"OLLAMA_NUM_PARALLEL=1表示同一时间只处理一个请求,避免多个任务争抢显存。如果调大num_ctx后显存吃紧,那就反过来,用更小的模型或更低的量化位宽换取上下文长度。
6. 进阶参数细节:显存不够时的一组量化与上下文折中方案
部署 DeepSeek 时最常遇到的约束是“显存不够”。显存不够不是说模型跑不起来,而是上下文窗口和并发能力被严重压缩。我根据自己调试的经历,给三档典型显存配置整理了一组可直接抄的参数参考:
| 显存容量 | 推荐模型 | 量化位宽 | num_ctx | OLLAMA_NUM_PARALLEL |
|---|---|---|---|---|
| 16GB | deepseek-r1:14b | Q4_K_M | 8192 | 1 |
| 8GB | deepseek-r1:7b / 8b | Q4_K_M | 4096 | 1 |
| 6GB 以下 | deepseek-r1:1.5b 或 7b 的 Q3_K_S | Q3_K_S | 2048 | 1 |
如果想固定这些参数而不每次都在请求里写,可以创建一个自定义模型文件:
# Modelfile FROM deepseek-r1:7b PARAMETER num_ctx 4096 PARAMETER temperature 0.6然后用ollama create deepseek-r1-ctx4k -f Modelfile创建带固定参数的模型,之后调用时就用deepseek-r1-ctx4k这个标签。这种方式很适合团队内部统一调用配置,避免每个调用方各自传参导致显存控制混乱。另外,OLLAMA_KEEP_ALIVE这个环境变量控制模型在显存中的驻留时间,默认会保留一段时间,如果业务是低频调用,可以把驻留时间调短,让显存及时释放;高频调用则调长,减少冷启动延迟。量化也是有代价的,Q8 效果最好但体积大,Q2 极小但质量差明显,没有后悔药,只能重新拉取不同量化版本对比。我现在拿到新机器,第一件事就是跑诊断命令、查磁盘、看显存,再对照表格选档位,不再做一上来就拉最大模型的莽事。希望帮到你。
本文还有配套的精品资源,点击获取