简介这份PDF面向银河麒麟桌面与服务器操作系统的用户、运维人员及开发者围绕DeepSeek在国产Linux环境中的本地化部署与使用展开帮助读者在网页版、客户端、本地部署及API集成等场景中完成选型与落地。全文以1个PDF文件交付压缩包约1.98MB篇幅精炼便于随查随用。内容不仅梳理Ollama安装启动、DeepSeek-R1模型下载与规格选择、Chatbox接入和API Key配置还给出VSCode中借助Cline插件实现辅助编程的配置路径并附桌面系统部署过程截图与ARM架构下GLIBCXX缺失的排错思路。已有513人学习适合希望在麒麟系统内完成AI模型部署、内网使用和开发提效的初、中级读者参考。1. 内网服务器上跑一个能对话的模型难点从来不在模型本身一台放在机房里的国产 Linux 服务器CPU 是 ARM 架构桌面终端清一色国产 Linux 发行版整段网络不出外网。这种环境下想用上 DeepSeek三条路摆在面前浏览器打开网页版、装个客户端填官方 API Key、或者干脆把模型拉到本地跑。前两条五分钟能通第三条要动系统库、改环境变量、算内存翻车点全在细节里。这份部署文档把四条使用路线拆开写从网页版、Chatbox 客户端接入、Ollama 本地部署到 VSCode 集成辅助编程一路覆盖到 ARM 平台 GLIBCXX 版本冲突这种硬骨头。适合正在做信创环境 AI 落地的运维和开发也适合想在内网跑通 AI 模型 API 集成的新手照着复现。2. 四条使用路线的边界先想清楚数据出不出内网2.1 网页版、客户端、本地部署、IDE 集成各自解决什么问题很多人一上来就问「哪个方案最好」这个问题没有统一答案因为四条路线的成本结构和数据流向完全不同。先把这张表看明白后面的操作才有意义。路线是否需要外网算力归属数据是否出内网典型使用者浏览器访问网页版需要服务端是临时试用、非敏感问答客户端 官方 API Key需要服务端是日常办公问答、文档润色本地 Ollama 部署 客户端不需要本机/内网服务器否内网办公、涉密文档处理VSCode 插件接入视接入方式服务端或本地视接入方式开发者辅助编程第一条路线最省事浏览器输入网址就能用或者在软件商店里装一个网页版封装应用。它的价值在于零配置验证——先确认网络通不通、账号能不能登录把环境问题排除掉再谈其他。第二条路线是客户端接官方 API。Chatbox 这类客户端本身只是一个壳真正干活的是背后的 API。它的优势是交互体验比网页好支持多模型切换、会话管理、提示词预设。缺点同样明显请求要发到公网内网环境直接死路。第三条路线才是这份文档的重头戏。Ollama 把模型权重、推理引擎、HTTP 服务打包成一个二进制装完启动就能通过 11434 端口对外提供接口。数据全程不出内网代价是要自己承担算力成本和运维成本。第四条路线面向开发者。VSCode 装 Cline 插件把模型接到编辑器里让它在当前项目上下文中生成代码、解释报错、补全函数。这条路线的关键不在插件而在于你接的是官方 API 还是本地 Ollama——接官方 API 意味着你正在把项目源码片段发出去接本地模型则要考虑 1.5b 这种小参数的模型能不能扛住代码理解任务。选型的判断顺序我一般是这样走的先问数据能不能出内网。不能出直接砍掉前两条往第三条走。能出但预算有限第二条性价比最高因为本地部署一台能跑 32b 模型的机器硬件成本不是小数目。只有明确要在编辑器里做辅助编程才值得为第四条单独折腾一轮。还有一个容易被忽略的维度是并发。网页版和官方 API 的并发上限由服务方决定本地部署的并发上限由你的显存和内存决定。一台只有 CPU 的服务器跑 1.5b 模型单路对话勉强够用两三个人同时提问就会明显排队。这一点在选型阶段不写清楚上线后就是投诉。2.2 软件商店安装与官方渠道安装的差别麒麟系统的软件商店里已经上架了若干 AI 客户端Chatbox、NextChat、Cherry Studio 这类都在列VSCode 也能直接从商店装。对桌面用户来说这是最省事的路径双击安装权限、依赖、桌面图标全部由包管理器处理不用碰命令行。但商店安装有两个边界要清楚。第一是版本滞后。商店里的版本经过适配和审核通常比官方最新版晚若干个版本新模型、新接口协议支持得慢一些遇到「为什么我的客户端里找不到某个模型选项」这类问题先怀疑版本而不是配置。第二是安装位置和运行用户。商店装的图形应用一般以当前登录用户身份运行配置文件和会话数据落在用户家目录下如果你用 root 装、用普通用户开或者反过来可能出现配置读不到、模型列表为空的现象。官方渠道官网下载 deb 包、GitHub 下载压缩包的优势是版本新、可控缺点是要自己处理依赖和权限。服务器环境没有图形界面只能走命令行这条路绕不开。我的习惯是桌面终端一律走软件商店减少维护面服务器端只装命令行工具不装任何图形依赖避免拖进来一堆用不上的库。2.3 API Key 的创建流程与客户端参数配置走官方 API 这条路第一步是拿 Key。访问 DeepSeek 开放平台注册登录后在 API Keys 页面点创建输入一个能认出用途的名称比如「内网办公终端」确认后页面会展示一串以 sk- 开头的字符串。提示这串 Key 只在创建时完整展示一次页面关掉就再也看不到了。我见过有人创建完顺手刷新页面然后花半小时找客服。创建完立刻复制到密码管理器里别指望浏览器记住。拿到 Key 之后回到 Chatbox。打开设置找到模型配置区域几个关键项这样填配置项取值说明模型提供方DeepSeek API决定请求协议和默认域名API Keysk- 开头的字符串粘贴时注意别带首尾空格API 域名官方默认地址一般不用改除非走中转模型deepseek-chat / deepseek-reasoner按任务类型选配置完保存回到对话框发一句最简单的测试比如让它说明当前使用的模型名称。有回复就说明链路通了报 401 是 Key 错或过期报 404 多半是域名或路径填错报超时先查网络出口。这一步的价值不只在「能用」更在于它给了你一个对照基准。后面本地部署出问题时你可以用同一个客户端、同一个界面只把「模型提供方」从 DeepSeek 改成 OLLAMA就能立刻判断问题出在模型服务端还是客户端侧。这种对照排查方式比盯着日志猜要快得多。2.4 一个容易被跳过的动作把客户端当探针用多数人配完就走其实客户端还能当排错工具使。Chatbox 这类应用在设置页通常有一个「测试连接」或者模型拉取的按钮点击后它会真实发起一次请求并把原始错误码返回出来。我的做法是在正式交付前用客户端做三组验证第一组不填 Key 直接发消息确认它报的是鉴权错误而不是网络错误这说明域名解析和端口是通的第二组填一个错误的 Key确认它报 401第三组填正确的 Key确认能出字。三组下来链路、鉴权、模型调用三个环节的边界就清楚了。后面本地部署接 Ollama 时同样的三组测试换成「服务没启动」「端口不通」「模型没拉下来」三种故障排查思路完全一致。3. Ollama 部署 DeepSeek-R1从装包到能对话的完整命令链3.1 为什么选 Ollama 而不是自己编译推理框架本地跑模型的方案不止一个。直接用 transformers 加载权重需要自己处理量化、显存调度、批处理写几十行代码才能对外提供接口用 llama.cpp 要自己编译还要手动转模型格式上 vLLM 则对 GPU 和驱动版本有明确要求纯 CPU 环境基本劝退。Ollama 的定位介于两者之间单文件二进制内置模型下载和量化管理启动后监听 11434 端口提供一套简单的 HTTP 接口同时兼容 OpenAI 风格的 /v1 路径。对信创环境来说这几点特别关键不依赖 Python 运行时和一堆 pip 包减少与系统自带 Python 版本冲突的概率二进制静态链接程度高部署时只需拷一个目录模型以「名称:标签」的方式管理切换版本不用改代码客户端生态成熟Chatbox、Cline 这类工具原生支持 OLLAMA 提供方。代价是它对系统 C 运行库有版本要求这正是后面 ARM 平台上那个 GLIBCXX 报错的根源。3.2 两种安装方式在线脚本与离线压缩包文档给了两条路实际操作时要根据环境选。有外网的机器一条命令解决# 官方安装脚本自动识别架构、下载二进制、注册 systemd 服务 curl -fsSL https://ollama.com/install.sh | sh这条命令的含义拆开看-f让 curl 在 HTTP 错误时静默失败而不是输出错误页面-s静默模式不显示进度条-S在出错时仍然显示错误-L跟随重定向。管道到sh意味着脚本会以当前用户权限执行所以要么用 root要么确保有 sudo 权限。脚本内部会判断 CPU 架构x86_64 还是 aarch64、下载对应的二进制、创建 ollama 用户、写入 systemd unit 文件。内网机器只能走第二条路。先在能出网的机器上下载对应架构的压缩包拷进内网再解压# 把整个包解压到 /usr/local生成 /usr/local/bin/ollama 和 /usr/local/lib/ollama tar -C /usr/local -zxvf ollama-linux-amd64.tgz # 验证二进制能被执行能打印版本号说明动态库依赖满足 /usr/local/bin/ollama --version参数说明-C /usr/local表示切换目录后再解压这是官方推荐的安装位置因为可执行文件会落到/usr/local/bin这个路径默认在 PATH 里-z处理 gzip 压缩-x解压-v显示过程-f指定文件。ARM 服务器要把文件名换成 aarch64 对应的包别下错了架构否则执行时会直接报「无法执行二进制文件」。--version这一步别跳过。它能执行说明动态链接库全部找到了它报错说明系统库版本不匹配这时候去装模型是白费功夫先解决库的问题。这就是一个很实用的分界线版本号能打出来环境算过关。3.3 服务启动与两个必须改的环境变量Ollama 默认只监听 127.0.0.1:11434也就是只有本机能访问。如果你的使用场景是「服务器跑模型、桌面终端连过来用」必须改成监听所有网卡。# 允许其他主机访问本机的 11434 端口 export OLLAMA_HOST0.0.0.0 # 放开跨域来源限制浏览器端应用如网页版客户端才能发起请求 export OLLAMA_ORIGINS* # 前台启动服务日志直接打在终端上方便观察 ollama serve这三个动作各有含义。OLLAMA_HOST0.0.0.0是把绑定地址从回环地址改成全部网卡改完之后同网段的其他机器才能通过 IP 访问如果不改客户端会一直报连接被拒绝而你在服务器上用 curl 测又是通的这个现象非常容易让人误判成防火墙问题。OLLAMA_ORIGINS*处理的是浏览器同源策略纯命令行客户端用不上但网页版或者基于 Electron 的桌面客户端会做 CORS 检查不放开就会出现「请求被拦截」而服务端日志一片空白。注意OLLAMA_ORIGINS*等于允许任意来源调用只适合内网隔离环境。机器一旦有公网入口就要收窄成具体的来源地址。前台启动适合调试长期运行要落到 systemd 里否则 SSH 一断服务就没了# 写入 systemd 单元实现开机自启和崩溃重启 cat /etc/systemd/system/ollama.service EOF [Unit] DescriptionOllama Service Afternetwork-online.target [Service] ExecStart/usr/local/bin/ollama serve Restartalways RestartSec3 EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_ORIGINS* EnvironmentOLLAMA_MODELS/data/ollama/models [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable --now ollama systemctl status ollama --no-pagerRestartalways配合RestartSec3实现崩溃后 3 秒拉起这对模型加载失败或者内存不足导致的进程退出很关键。OLLAMA_MODELS单独拎出来说默认模型存在/usr/share/ollama/.ollama/models或者运行用户的家目录下一个 32b 模型量化后二三十 GB很容易把系统盘塞满。提前把模型目录指到大容量数据盘能省掉后面迁移数据的一堆麻烦。3.4 模型拉取与配置匹配别拿 1.5b 去干 32b 的活拉模型和跑模型是同一条命令# 拉取并进入交互式对话首次执行会自动下载权重 ollama run deepseek-r1:1.5b # 只下载不进入交互 ollama pull deepseek-r1:7b # 查看本地已有模型及体积 ollama list # 查看正在运行的模型和占用的资源 ollama psdeepseek-r1:1.5b这个写法里冒号前是模型名冒号后是参数规模标签。同一个模型有多个蒸馏版本标签就是区分依据。选哪个不取决于你希望它多聪明取决于机器有多少内存。参数规模量化后大致占用纯 CPU 环境体验适用硬件参考1.5b12 GB可交互响应秒级4 核 8G 起步7b / 8b5 GB 左右可用首字延迟明显8 核 16G14b910 GB偏慢适合离线批处理16 核 32G32b20 GB 左右纯 CPU 很吃力建议配 GPU70b40 GB 左右纯 CPU 基本不可用多卡或大内存服务器这些数字是量化后的粗略量级实际占用跟量化方式、上下文长度都有关系。判断标准很简单模型加载时如果系统开始大量换页说明内存不够换小一号的模型比调参数有效得多。文档里用 1.5b 做示例是有道理的——它是验证链路是否通的最快路径。权重小、下载快、加载快五分钟内能看到输出。但要注意1.5b 用来验证部署成功没问题拿它做实际业务问答就勉强了尤其是需要推理链条的任务小模型经常答非所问。我一般建议先用 1.5b 打通全链路确认端口、客户端、防火墙都正常再换成实际要用的规模重新拉一次。拉完做一次交互验证# 单次提问不进交互模式适合脚本化验证 ollama run deepseek-r1:1.5b 用一句话说明你能做什么 # 走 HTTP 接口验证模拟客户端调用 curl http://127.0.0.1:11434/api/generate -d { model: deepseek-r1:1.5b, prompt: 你好, stream: false }第一条验证的是模型能不能跑第二条验证的是 HTTP 服务能不能对外提供接口。两条都通才算服务端就绪。很多人只做第一条然后客户端连不上就开始怀疑网络实际上是服务监听地址的问题。3.5 桌面端 Chatbox 接入服务器上的模型服务端跑起来之后桌面终端打开 Chatbox在设置里改四处模型提供方选OLLAMAAPI 域名填http://服务器IP:11434端口默认就是 11434注意这里要写 http 前缀只写 IP 有些版本识别不了模型这一栏如果前后端网络通客户端会自动拉取到服务端的模型列表直接选中deepseek-r1:1.5b保存后回对话框发一句测试。这一步失败的典型表现有三种。一是模型下拉框是空的说明客户端请求/api/tags没拿到数据回头查OLLAMA_HOST和防火墙。二是能拉到列表但发消息转圈多半是模型正在加载第一次调用要把权重读进内存几 GB 的模型等十几秒正常。三是报跨域错误桌面客户端如果是 Electron 套壳本质上还是浏览器环境OLLAMA_ORIGINS没放开就会拦。4. VSCode 集成 DeepSeek把模型放进编辑器上下文4.1 插件选型与两种接入路径的取舍VSCode 里做 AI 辅助编程的插件不少文档里用的是 Cline。选它的理由是它把「读文件、改文件、执行命令」做成了显式的工具调用流程每一步都会在侧边栏展示出来比黑盒式的补全更容易判断模型到底干了什么。装完之后打开插件面板第一件事是选 API Provider。这里有两条岔路第一条Provider 选 DeepSeek填官方 API Key。配置最简单模型能力强代价是代码片段会发到公网。适合个人项目、开源代码。第二条Provider 选 OllamaBase URL 填http://服务器IP:11434/v1模型名填服务端已有的标签。数据不出内网但要注意/v1这个后缀——Cline 走的是 OpenAI 兼容协议Ollama 的兼容层挂在/v1下面少了这个后缀会一直 404。第二条路的现实问题是模型能力。1.5b 做代码补全经常出现生成的代码语法对但逻辑跑偏或者干脆把整个文件重写一遍。我的经验是至少上到 7b 以上再谈辅助编程14b 以上才比较稳。用 1.5b 验证插件配置是否通可以真拿来写业务代码会很痛苦。4.2 Cline 的配置步骤与参数含义从零到能对话按这个顺序走# 1. 确认 VSCode 已安装桌面系统可直接从软件商店获取 code --version # 2. 命令行安装 Cline 扩展适合批量部署场景 code --install-extension saoudrizwan.claude-dev--install-extension后面跟的是扩展的唯一标识批量给多台终端部署时这条命令比手动点安装快得多。图形界面下也可以在扩展面板搜关键词安装效果一样。装完打开插件配置项填法配置项接官方 API接本地 OllamaAPI ProviderDeepSeekOllamaAPI Keysk- 开头字符串留空Base URL默认http://IP:11434/v1Modeldeepseek-chat 等deepseek-r1:7b 等本地标签Context Window默认按实际模型能力填别虚标Context Window 这一项容易被忽略。填大了插件会把大量文件内容塞进请求本地小模型的处理速度会断崖式下降填小了模型看不到足够上下文改出来的代码和现有逻辑对不上。保守做法是先填 8192跑几个任务观察实际表现再调。4.3 上下文控制别让插件把整个仓库读一遍Cline 这类工具默认会主动读工作区文件来补上下文。一个几百个文件的项目第一次提问就可能触发十几轮文件读取每次都是一次完整的模型推理。本地部署环境下这个开销是实打实的。控制手段有两个。第一个是在项目根目录放一个忽略文件把不需要模型看的目录排除掉# .clineignore语法和 .gitignore 一致 node_modules/ dist/ build/ *.log *.lock data/第二个是在提示里显式限定范围。不要说「帮我看看这个项目有什么问题」要说「只看 src/service 目录下这三个文件找出空指针风险」。任务边界越清晰插件读的文件越少本地模型的响应速度差别非常明显。4.4 一个可复现的辅助编程示例验证插件是否真的可用别用「你好」这种测试直接给一个带明确约束的需求# 需求写一个函数读取指定目录下所有 .log 文件 # 按行统计包含 ERROR 的行数返回 {文件名: 错误行数} 的字典 # 要求目录不存在时抛 FileNotFoundError文件编码统一用 utf-8忽略解码失败的字节 import os def count_error_lines(directory: str) - dict: if not os.path.isdir(directory): raise FileNotFoundError(f目录不存在: {directory}) result {} for name in os.listdir(directory): if not name.endswith(.log): continue path os.path.join(directory, name) count 0 # errorsignore 保证遇到坏字节不会中断整个统计 with open(path, r, encodingutf-8, errorsignore) as f: for line in f: if ERROR in line: count 1 result[name] count return result这段代码的关键点在errorsignore和目录判空两处。让模型生成之后重点看它有没有保留这两个约束——小参数的模型经常把errors参数吃掉或者用os.path.exists判断文件而不是目录。执行一遍构造一个不存在的路径触发异常再构造一个正常目录看统计结果两个用例过掉才算插件真的能用。5. 避坑与排查五条踩过的记录5.1 ARM 服务器启动报 GLIBCXX 版本缺失现象在 ARM 架构服务器上解压完 Ollama执行ollama --version或者ollama serve终端直接抛出/usr/lib64/libstdc.so.6: version GLIBCXX_3.4.25 not found服务起不来。原因Ollama 二进制在编译时链接了较新版本的 GCC 运行库而系统自带的libstdc.so.6版本偏旧缺少二进制需要的符号版本。x86 平台上一般不会遇到ARM 发行版的软件源更新节奏慢一些这个坑出现频率高。解决拿到一个包含所需符号的新版库文件替换系统默认库的软链接。操作前先备份一定要留回滚路径。# 1. 先确认现有库里到底有没有目标符号 strings /usr/lib64/libstdc.so.6 | grep GLIBCXX_3.4.25 # 2. 备份原库文件别直接覆盖 cd /usr/lib64/ mv libstdc.so.6 libstdc.so.6.bak # 3. 放入新库并重建软链接 cp /path/to/libstdc.so.6.0.28 /usr/lib64/ ln -s libstdc.so.6.0.28 libstdc.so.6 # 4. 刷新动态链接缓存并验证 ldconfig ollama --version第一条命令是判断依据如果 grep 有输出说明符号存在问题不在库版本而在别的路径没输出才需要换库。第四步的ldconfig不能省不刷新缓存新软链接不会立即生效。注意libstdc.so.6是系统级 C 运行库替换它会影响所有依赖 C 的程序。生产环境务必先在测试机验证并保留.bak文件。万一出问题删掉软链接、把备份改回来、重新ldconfig即可恢复。5.2 服务器本机 curl 通桌面客户端连不上现象在服务器上curl http://127.0.0.1:11434/api/tags正常返回模型列表桌面端 Chatbox 填了服务器 IP 之后一直转圈最后报连接失败。原因Ollama 默认绑定 127.0.0.1只接受本机请求。本机 curl 走的是回环地址所以通外部请求打到网卡 IP 的 11434 端口服务根本没监听。解决设置OLLAMA_HOST0.0.0.0后重启服务用ss -lntp | grep 11434确认监听地址从127.0.0.1:11434变成了0.0.0.0:11434。如果改了还不行再查防火墙规则有没有放行该端口。排查顺序固定为监听地址 → 防火墙 → 网络可达性从近到远别一上来就抓包。5.3 模型加载到一半进程消失现象ollama run之后终端卡在加载阶段过一会儿进程直接退出systemctl status显示服务被 kill。原因内存不足。模型权重加载需要连续的大块内存加上推理时的 KV Cache峰值占用比ollama list显示的体积大不少。系统 OOM Killer 介入后直接终止进程日志里能看到out of memory字样。解决先用dmesg | tail -30或者journalctl -k | grep -i oom确认是不是被杀。确认后三条路选一条换小一号的模型、加内存、或者把量化等级调低。想省事就直接降参数规模1.5b 换成 0.5b 之类别在内存不够的机器上硬调参数那是玄学。5.4 客户端装了两份配置改的不是正在跑的那一份现象在 Chatbox 里改了 API 域名保存后依然连旧地址或者模型列表里有几个模型实际调用时报模型不存在。原因系统里存在两个版本的客户端一个是软件商店装的一个是之前手动下载的桌面图标指向的和实际启动的不是同一个或者配置写进了当前用户目录但应用以另一个用户身份运行读的是另一份配置。解决先用which或桌面图标的属性确认可执行文件路径卸载多余的那份。再确认运行用户图形应用一般以登录用户身份运行配置文件在~/.config/下面的对应目录。改完配置如果没生效彻底退出进程不是关窗口再重开很多客户端不做热加载。5.5 系统盘被模型权重撑满现象跑了几个模型之后系统频繁报「设备上没有空间」日志写不进去服务异常。原因模型默认存在系统盘的用户目录下一个 14b 模型接近 10 GB拉三四个就顶到上限。解决通过OLLAMA_MODELS环境变量把模型目录迁到大容量分区重启服务后重新拉模型。迁移前先看du -sh确认旧目录占用迁完把旧的删掉释放空间。这个动作建议在部署初期就做等到盘满了再迁系统可能已经因为写不进日志而出现其他故障。6. 验收与调优怎么判断这套部署真的能交付6.1 三层验收缺一层都不算完成部署完成不等于可交付。我习惯按三层验收每层都有明确的通过标准。第一层是服务层。systemctl is-active ollama返回 activess -lntp能看到 11434 在0.0.0.0上监听ollama list能列出目标模型。这一层过不了后面都是空谈。第二层是接口层。用 curl 直接打 HTTP 接口分别测/api/tags列表、/api/generate生成、/v1/modelsOpenAI 兼容层。第三个尤其容易漏很多客户端走的是兼容层只测前两个会在接 IDE 插件时才发现问题。第三层是应用层。桌面端 Chatbox 发一轮完整对话VSCode 里让插件生成一段代码并执行。这两步验证的是端到端体验包括首字延迟、流式输出是否正常、长对话会不会崩。下面这个脚本把前两层自动化了可以放进巡检流程#!/bin/bash # 部署健康检查返回非 0 表示存在失败项 HOST127.0.0.1 PORT11434 FAIL0 check() { local name$1 cmd$2 if eval $cmd /dev/null 21; then echo [OK] $name else echo [FAIL] $name FAIL1 fi } # 服务进程是否存在 check ollama 进程 pgrep -x ollama # 端口是否在监听不限定绑定地址兼容 0.0.0.0 与 127.0.0.1 check 11434 端口 ss -lnt | grep -q :$PORT # 模型列表接口 check 模型列表 API curl -sf http://$HOST:$PORT/api/tags # OpenAI 兼容层 check OpenAI 兼容层 curl -sf http://$HOST:$PORT/v1/models # 实际推理一次超时 60 秒 check 推理接口 curl -sf --max-time 60 http://$HOST:$PORT/api/generate \ -d {\model\:\deepseek-r1:1.5b\,\prompt\:\hi\,\stream\:false} exit $FAIL脚本里的check函数把「执行命令 判断退出码 打印结果」封装起来新增检查项只要加一行。--max-time 60是给推理接口留的余量模型首次加载慢超时设太短会误报。最后用退出码对外暴露结果方便接监控或者定时任务。把模型名换成实际部署的那个别照抄示例。6.2 参数调优的三个方向跑通之后想让它更好用调优集中在三处。一是上下文长度。Ollama 支持在 Modelfile 里改num_ctx默认值偏小长文档处理时会被截断。但调大意味着 KV Cache 占用上升纯 CPU 环境下响应时间会线性变长。我的做法是按实际任务定日常问答 4096 够用代码理解给到 8192再往上要考虑硬件能不能扛。二是并发。OLLAMA_NUM_PARALLEL控制同时处理的请求数默认值保守。多用户场景可以适度调高但每路并发都会占一份显存或内存调之前先算清楚余量。CPU 环境下这个值的收益很低不建议动。三是模型选择。同一台机器上7b 和 14b 的体验差距远大于参数调优带来的提升。与其在 1.5b 上反复调温度、调 top_p不如直接换个能跑得动的更大模型收益立竿见影。6.3 一个我坚持了很多年的习惯早年间在一台 ARM 服务器上换 libstdc图省事没备份直接覆盖了系统库结果整台机器上所有依赖 C 运行库的程序全部起不来包括几个跟这次部署毫无关系的业务进程最后靠救援模式才恢复。从那以后凡是动/usr/lib64下面的东西我都强制走一遍「grep 确认符号 → 备份原文件 → 软链接切换 → ldconfig → 验证」这五步一步不省。库文件替换这类操作后悔药很贵备份的成本几乎为零。另一个习惯是每次部署完先不急着交付用上面那个检查脚本跑一遍把输出贴到交付记录里。三个月后有人反馈「模型不能用了」翻出当时的基线输出一对比是服务没起来还是模型被删了一眼就能看出来不用再从零开始摸。这套流程在信创环境里尤其值钱因为很多机器不允许你随便重装排查只能靠证据。希望帮到你。本文还有配套的精品资源点击获取
