简介《DeepSeek 极简部署手册》面向希望绕开云端成本与复杂环境配置的研究者、开发者及 AI 技术爱好者提供一条在本地跑通大语言模型的低门槛路径。文档以 Ollama 这一开源工具为主线先说明它在简化大模型本地运行与管理上的作用与安装校验方式再指导读者对照机器配置从 7B、13B、33B 等版本中做出取舍——分别约需 8GB、16GB、32GB 内存并给出可复制粘贴的安装命令与成功回显示例若觉得命令行交互不便还可用 Cherry-Studio 实现界面化对话并搭建个人本地知识库。资源为单个 PDF 文件压缩包约 819KB篇幅精简但步骤连贯适合当作随查随用的操作清单。目前已有 533 人学习对想低成本接触前沿模型、又担心配置繁琐的入门者较为友好。1. 从「DeepSeek 极简部署手册.pdf」说起真正要部署的是什么很多人手里那份《DeepSeek 极简部署手册.pdf》其实是同事或社区整理的操作记录翻到第二页就断在「拉取模型」这一步——命令能抄参数不知道为什么这么设换一台机器就复现不了。DeepSeek 部署这件事本质上是三件独立的事拼在一起模型权重怎么落地、推理服务怎么对外暴露、客户端怎么接上。三件事的边界清楚了手册里那些看起来很杂的命令就串成了一条线。这份手册面向的是不想从零啃推理框架源码的 IT 从业者显卡从 8GB 到 80GB 都有对应方案或者在只有 API Key 的情况下先把业务跑通。下面按选型、本地跑通、容器化、接口接入到手册沉淀的顺序往下走。2. DeepSeek 部署路线选型ollama 本地部署与 API 调用怎么取舍选型这一步做错后面所有参数调整都是白费力气。判断标准其实只有三条显存有多少、数据能不能出内网、调用峰值有多高。把这三条量化之后路线基本自动确定。2.1 三条主流路线的硬件与成本对照路线典型硬件首次可用耗时适用场景主要代价官方 API 调用无分钟级验证业务、流量波动大按 token 计费数据出网ollama 本地部署单卡 8GB 起半小时级个人开发、内网小流量并发弱长上下文吃显存容器化自建推理服务单卡 24GB 起半天级多人共享、需监控运维成本高需调参三条路线不是互斥的常见做法是先用 API 调通业务逻辑再把 prompt 和参数一比一搬到本地模型上做回归最后才决定哪些请求留在本地。反直觉的一点是本地部署最大的收益往往不是省下的调用费而是可以把日志、原文、上下文完整留在自己机器上做调试这在调 prompt 阶段省的时间比钱值钱。2.2 用 ollama 拉通 DeepSeek 的最小命令序列ollama 是目前门槛最低的一条路它把权重下载、量化加载、HTTP 服务三件事打包成一条命令。# 确认版本旧版本对新模型的 manifest 支持不全 ollama --version # 拉取对话模型7B 量级适合 8GB 显存的起步配置 ollama pull deepseek-r1:7b # 前台交互式验证能正常对话说明权重和运行时就位 ollama run deepseek-r1:7b 用一句话说明你现在的运行设备 # 常驻服务模式默认监听 127.0.0.1:11434 ollama serve # 另开终端验证服务是否真的在监听 curl -s http://127.0.0.1:11434/api/tags | head -c 300pull的模型标签需要按显存反推7B 的 Q4 量化约占 5GB 显存14B 的 Q4 约占 10GB32B 以上基本要 24GB 卡起步。serve默认只绑本机要让同网段其他机器访问需要把监听地址改为0.0.0.0:11434这一步做完再考虑加访问控制不要先暴露再补。/api/tags返回的是本地已下载的模型清单如果这里为空说明拉取其实失败了只是终端输出被滚屏吞掉了。2.3 决定能不能跑起来的 3 个必调参数默认参数在长文本场景很容易翻车原因是 ollama 给新模型的默认上下文窗口偏小。# 保存为 Modelfile用 ollama create 生成定制模型 FROM deepseek-r1:7b # 上下文窗口默认值偏小处理长文档必须显式调大 PARAMETER num_ctx 8192 # 交给 GPU 的层数显存不够时下调会明显降速但不会 OOM PARAMETER num_gpu 28 # 生成随机性做代码和文档解析建议压到 0.2 以下 PARAMETER temperature 0.2# 用上面的 Modelfile 生成一个带固定参数的模型别名 ollama create deepseek-doc -f ./Modelfile # 确认新别名已注册 ollama listnum_ctx是最容易被忽略的一个。上下文窗口从 4096 提到 8192KV Cache 显存占用大约翻倍7B 模型在 8GB 卡上可能直接放不下。此时要么降到 6144要么把num_gpu调低让部分层走 CPU。num_gpu的实际可设值取决于模型层数7B 通常是 28 到 33 层之间写大了会被静默截断写小了性能损失很明显所以调完之后一定要看日志里的层分配信息。temperature在文档解析这类任务上给到 0.7 以上输出格式会不稳定结构化字段经常缺行。3. 用 Docker 把 DeepSeek 服务封成可迁移的推理节点ollama 解决的是单机可用Docker 解决的是换台机器还能一样跑。这一章的目标是产出一个别人docker compose up就能起来的配置顺带把监控埋点留好。3.1 docker 安装部署与 GPU 直通的前置检查容器里要用显卡宿主机需要先具备能被容器识别的运行时否则启动后会退回纯 CPU 模式速度差一个数量级。# 确认驱动可见 nvidia-smi # 确认 docker 插件层面能识别到 GPU没有输出说明 runtime 没配好 docker info | grep -i nvidia # 用官方镜像做一次直通验证能打印出显卡说明通了 docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi第三条命令是关键分界线。如果容器内看不到显卡先查nvidia-container-toolkit是否安装、docker daemon 是否重启过而不是去改模型参数。这一步没通后面所有显存调优都是空谈。3.2 一份可复现的 compose 配置services: deepseek: image: ollama/ollama:latest container_name: deepseek-serve restart: unless-stopped ports: - 11434:11434 volumes: # 模型权重单独挂卷重建容器不用重新下载 - ./ollama-models:/root/.ollama environment: # 控制并发加载的模型数量避免多模型挤爆显存 - OLLAMA_MAX_LOADED_MODELS1 - OLLAMA_NUM_PARALLEL2 - OLLAMA_KEEP_ALIVE10m deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]volumes那一行是整个配置里最值钱的权重目录挂出来之后容器升级、换镜像都不用重新拉几十 GB。OLLAMA_NUM_PARALLEL设成 2 是保守值它决定了单个模型能同时处理几个请求设大了每个请求分到的显存变少长上下文请求会开始排队甚至失败。OLLAMA_KEEP_ALIVE控制模型在空闲多久后从显存卸载闲着就卸可以让多个模型共享一张卡但代价是下一次请求要多等十几秒加载。3.3 健康检查与 prometheus 监控部署接入服务跑起来之后需要两个东西自动判断它是不是死了以及知道它在忙什么。healthcheck: test: [CMD-SHELL, curl -fsS http://127.0.0.1:11434/api/tags || exit 1] interval: 30s timeout: 5s retries: 3 start_period: 60sstart_period给 60 秒是因为容器内首次加载模型很慢不给足时间会被误判成不健康然后反复重启。健康检查只验证接口可达不代表模型已加载完成所以它还配不上业务层面的告警只适合做容器编排的存活判断。监控侧ollama 本身暴露的指标有限实践中更常用的是两个替代口径监控对象采集方式关注阈值进程存活健康检查接口连续 3 次失败GPU 使用率DCGM Exporter 拉取长期高于 90%显存占用DCGM Exporter 拉取接近卡容量上限推理延迟业务侧埋点P95 超过预设值把这些指标接进 prometheus 之后最重要的告警不是「挂了」而是「显存持续贴顶」——它通常意味着并发参数设大了或者某个调用方在传超长上下文等到 OOM 再处理就已经影响线上请求了。4. DeepSeek API 如何调用从 curl 到 vscode 接入服务对外暴露之后客户端侧的接入是最后一公里。这一段的核心认知是多数主流推理服务和云厂商接口都兼容 OpenAI 的请求结构所以客户端配置可以复用只需要改 base_url 和模型名。4.1 兼容协议的请求结构与参数含义先用最朴素的方式确认接口通不通再考虑接入工具。curl -s http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer not-needed-locally \ -d { model: deepseek-doc, messages: [ {role: system, content: 你是文档解析助手只输出结构化结果}, {role: user, content: 把这段配置里的端口和卷路径列出来} ], temperature: 0.2, max_tokens: 512, stream: false }model字段填的是本地注册的别名不是权重文件路径写错会直接返回模型不存在。Authorization在本地部署里通常无校验但很多客户端会强校验这个头存不存在所以随手填一个占位值最省事。max_tokens在推理模型上要留意部分模型会先输出一段思考过程再给答案额度给小了答案会被截断看起来像是模型「答了一半就停」。换成 Python 调用时结构完全一致用官方 SDK 改一个地址即可from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, # 指向本地服务不开源则换云端地址 api_keylocal-key, # 本地无鉴权占位即可 ) resp client.chat.completions.create( modeldeepseek-doc, messages[{role: user, content: 输出一份三点式部署检查清单}], temperature0.3, # 低温度更适合格式稳定的清单类输出 timeout120, # 长上下文首 token 慢超时要给足 ) print(resp.choices[0].message.content)timeout是本地部署最容易踩的坑。默认超时往往只有几十秒而长文档首次推理要等模型加载加 prefill很容易在客户端侧先断开服务端还在算日志里看到的是一堆中断请求。4.2 vscode 接入 deepseek 与 codex 类工具接入的配置差异在编辑器里接入本地模型配置项看起来各家不同拆开看只有三个变量接口地址、模型名、是否走流式。配置项本地 ollama 部署云端 APIbase_url指向本机或内网服务端口服务商提供的地址model本地注册的模型别名服务商公布的模型名api_key占位字符串真实密钥走环境变量流式输出建议开启体验更接近原生建议开启{ models: [ { name: deepseek-local, provider: openai-compatible, baseUrl: http://127.0.0.1:11434/v1, apiKey: local-key, model: deepseek-doc, contextLength: 8192 } ] }contextLength这一项必须和 Modelfile 里的num_ctx对齐。客户端以为有 32K 上下文、服务端只加载了 8K结果就是客户端把超长内容塞进去服务端静默截断前半段模型答非所问排查半天以为是模型能力问题。跨机器的场景下端口要写内网地址同时确认防火墙放行这类工具默认不会给出「连接被拒绝」之外的提示。4.3 流式输出、超时与重试的排错路径按现象分常见故障基本落在下面几类现象大概率原因处置方式连接被拒绝服务未启动或只绑了 127.0.0.1改监听地址并确认端口首 token 迟迟不来模型冷启动或 prompt 过长调大超时开 keep_alive输出中途截断max_tokens 偏小或上下文超限两者一起检查返回内容重复temperature 过低叠加重复惩罚缺失温度提到 0.3 以上显存溢出并发数或 num_ctx 过大先降并发再降窗口重试策略要小心推理类请求属于重计算盲目重试会放大负载。合理的做法是只对连接类错误重试对超时类错误做退避并且限制最大重试次数。流式输出场景下客户端断开会留下服务端仍在计算的请求本地部署里配合 keep_alive 短一些能减少这种浪费。5. 把部署结果沉淀成可检索 PDF 手册的进阶做法部署完的下一件事是把过程沉淀下来否则下次换机器又要重来一遍。这里有个有意思的闭环生成 PDF 手册的同时把 PDF 本身喂回 DeepSeek做成一个能问的部署知识库。最省事的采集方式是把命令、参数表和排错记录整理成 Markdown再用文档工具导出成 PDF。不要用截图拼的 PDF那种文件机器读不了。真正可检索的手册必须保留文本层字体里要包含中文字形否则抽取出来全是乱码表现为 PDF 图片中文设置没生效。接下来让 DeepSeek 读这份手册用文本抽取加问答的两段式结构from pypdf import PdfReader from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keylocal-key) def load_manual(path: str) - str: reader PdfReader(path) pages [] for i, page in enumerate(reader.pages): text page.extract_text() or # 页码标记保留下来方便回答时回溯到具体页 pages.append(f[page {i 1}]\n{text}) return \n.join(pages) manual load_manual(DeepSeek极简部署手册.pdf) # 手册通常超过单次上下文按段落切块后只把命中块送进模型 chunks [manual[i:i 2000] for i in range(0, len(manual), 2000)] question 7B 模型在 8GB 显存上跑长文档num_ctx 应该设多少 # 极简关键词召回生产环境换成向量检索 hits [c for c in chunks if num_ctx in c or 显存 in c][:2] context \n\n.join(hits) resp client.chat.completions.create( modeldeepseek-doc, messages[ {role: system, content: 只依据给定手册内容回答找不到就说未收录并标注页码}, {role: user, content: f手册内容\n{context}\n\n问题{question}}, ], temperature0.1, # 检索问答要的是忠实复述不是发挥 max_tokens800, ) print(resp.choices[0].message.content)extract_text()对扫描件返回空串这是判断 PDF 有没有文本层最直接的方法随机抽三页如果都是空就先做 OCR 再进流程。分块大小设 2000 字符是个折中块太小会切断参数表的上下文块太大一次召回就吃掉半个上下文窗口。temperature压到 0.1 并强制标注页码是为了在手册场景里优先保证可追溯——回答里带上页码人可以直接翻回去核对这比答案听起来多流畅重要得多。验证这套东西有没有真正跑通有个很硬的检查方式故意问一个手册里没写的问题比如「这份手册推荐了几种监控方案」如果模型开始编造具体数量说明系统提示里的约束没生效需要把「找不到就说未收录」这条前置到 system 里而不是 user 里。反过来如果它能稳定回答出未收录说明检索链路、上下文注入和指令遵循三环都到位了这份 PDF 才算从一份静态文档变成了可复用的部署资产。本文还有配套的精品资源点击获取
简介《DeepSeek 极简部署手册》面向希望绕开云端成本与复杂环境配置的研究者、开发者及 AI 技术爱好者提供一条在本地跑通大语言模型的低门槛路径。文档以 Ollama 这一开源工具为主线先说明它在简化大模型本地运行与管理上的作用与安装校验方式再指导读者对照机器配置从 7B、13B、33B 等版本中做出取舍——分别约需 8GB、16GB、32GB 内存并给出可复制粘贴的安装命令与成功回显示例若觉得命令行交互不便还可用 Cherry-Studio 实现界面化对话并搭建个人本地知识库。资源为单个 PDF 文件压缩包约 819KB篇幅精简但步骤连贯适合当作随查随用的操作清单。目前已有 533 人学习对想低成本接触前沿模型、又担心配置繁琐的入门者较为友好。1. 从「DeepSeek 极简部署手册.pdf」说起真正要部署的是什么很多人手里那份《DeepSeek 极简部署手册.pdf》其实是同事或社区整理的操作记录翻到第二页就断在「拉取模型」这一步——命令能抄参数不知道为什么这么设换一台机器就复现不了。DeepSeek 部署这件事本质上是三件独立的事拼在一起模型权重怎么落地、推理服务怎么对外暴露、客户端怎么接上。三件事的边界清楚了手册里那些看起来很杂的命令就串成了一条线。这份手册面向的是不想从零啃推理框架源码的 IT 从业者显卡从 8GB 到 80GB 都有对应方案或者在只有 API Key 的情况下先把业务跑通。下面按选型、本地跑通、容器化、接口接入到手册沉淀的顺序往下走。2. DeepSeek 部署路线选型ollama 本地部署与 API 调用怎么取舍选型这一步做错后面所有参数调整都是白费力气。判断标准其实只有三条显存有多少、数据能不能出内网、调用峰值有多高。把这三条量化之后路线基本自动确定。2.1 三条主流路线的硬件与成本对照路线典型硬件首次可用耗时适用场景主要代价官方 API 调用无分钟级验证业务、流量波动大按 token 计费数据出网ollama 本地部署单卡 8GB 起半小时级个人开发、内网小流量并发弱长上下文吃显存容器化自建推理服务单卡 24GB 起半天级多人共享、需监控运维成本高需调参三条路线不是互斥的常见做法是先用 API 调通业务逻辑再把 prompt 和参数一比一搬到本地模型上做回归最后才决定哪些请求留在本地。反直觉的一点是本地部署最大的收益往往不是省下的调用费而是可以把日志、原文、上下文完整留在自己机器上做调试这在调 prompt 阶段省的时间比钱值钱。2.2 用 ollama 拉通 DeepSeek 的最小命令序列ollama 是目前门槛最低的一条路它把权重下载、量化加载、HTTP 服务三件事打包成一条命令。# 确认版本旧版本对新模型的 manifest 支持不全 ollama --version # 拉取对话模型7B 量级适合 8GB 显存的起步配置 ollama pull deepseek-r1:7b # 前台交互式验证能正常对话说明权重和运行时就位 ollama run deepseek-r1:7b 用一句话说明你现在的运行设备 # 常驻服务模式默认监听 127.0.0.1:11434 ollama serve # 另开终端验证服务是否真的在监听 curl -s http://127.0.0.1:11434/api/tags | head -c 300pull的模型标签需要按显存反推7B 的 Q4 量化约占 5GB 显存14B 的 Q4 约占 10GB32B 以上基本要 24GB 卡起步。serve默认只绑本机要让同网段其他机器访问需要把监听地址改为0.0.0.0:11434这一步做完再考虑加访问控制不要先暴露再补。/api/tags返回的是本地已下载的模型清单如果这里为空说明拉取其实失败了只是终端输出被滚屏吞掉了。2.3 决定能不能跑起来的 3 个必调参数默认参数在长文本场景很容易翻车原因是 ollama 给新模型的默认上下文窗口偏小。# 保存为 Modelfile用 ollama create 生成定制模型 FROM deepseek-r1:7b # 上下文窗口默认值偏小处理长文档必须显式调大 PARAMETER num_ctx 8192 # 交给 GPU 的层数显存不够时下调会明显降速但不会 OOM PARAMETER num_gpu 28 # 生成随机性做代码和文档解析建议压到 0.2 以下 PARAMETER temperature 0.2# 用上面的 Modelfile 生成一个带固定参数的模型别名 ollama create deepseek-doc -f ./Modelfile # 确认新别名已注册 ollama listnum_ctx是最容易被忽略的一个。上下文窗口从 4096 提到 8192KV Cache 显存占用大约翻倍7B 模型在 8GB 卡上可能直接放不下。此时要么降到 6144要么把num_gpu调低让部分层走 CPU。num_gpu的实际可设值取决于模型层数7B 通常是 28 到 33 层之间写大了会被静默截断写小了性能损失很明显所以调完之后一定要看日志里的层分配信息。temperature在文档解析这类任务上给到 0.7 以上输出格式会不稳定结构化字段经常缺行。3. 用 Docker 把 DeepSeek 服务封成可迁移的推理节点ollama 解决的是单机可用Docker 解决的是换台机器还能一样跑。这一章的目标是产出一个别人docker compose up就能起来的配置顺带把监控埋点留好。3.1 docker 安装部署与 GPU 直通的前置检查容器里要用显卡宿主机需要先具备能被容器识别的运行时否则启动后会退回纯 CPU 模式速度差一个数量级。# 确认驱动可见 nvidia-smi # 确认 docker 插件层面能识别到 GPU没有输出说明 runtime 没配好 docker info | grep -i nvidia # 用官方镜像做一次直通验证能打印出显卡说明通了 docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi第三条命令是关键分界线。如果容器内看不到显卡先查nvidia-container-toolkit是否安装、docker daemon 是否重启过而不是去改模型参数。这一步没通后面所有显存调优都是空谈。3.2 一份可复现的 compose 配置services: deepseek: image: ollama/ollama:latest container_name: deepseek-serve restart: unless-stopped ports: - 11434:11434 volumes: # 模型权重单独挂卷重建容器不用重新下载 - ./ollama-models:/root/.ollama environment: # 控制并发加载的模型数量避免多模型挤爆显存 - OLLAMA_MAX_LOADED_MODELS1 - OLLAMA_NUM_PARALLEL2 - OLLAMA_KEEP_ALIVE10m deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]volumes那一行是整个配置里最值钱的权重目录挂出来之后容器升级、换镜像都不用重新拉几十 GB。OLLAMA_NUM_PARALLEL设成 2 是保守值它决定了单个模型能同时处理几个请求设大了每个请求分到的显存变少长上下文请求会开始排队甚至失败。OLLAMA_KEEP_ALIVE控制模型在空闲多久后从显存卸载闲着就卸可以让多个模型共享一张卡但代价是下一次请求要多等十几秒加载。3.3 健康检查与 prometheus 监控部署接入服务跑起来之后需要两个东西自动判断它是不是死了以及知道它在忙什么。healthcheck: test: [CMD-SHELL, curl -fsS http://127.0.0.1:11434/api/tags || exit 1] interval: 30s timeout: 5s retries: 3 start_period: 60sstart_period给 60 秒是因为容器内首次加载模型很慢不给足时间会被误判成不健康然后反复重启。健康检查只验证接口可达不代表模型已加载完成所以它还配不上业务层面的告警只适合做容器编排的存活判断。监控侧ollama 本身暴露的指标有限实践中更常用的是两个替代口径监控对象采集方式关注阈值进程存活健康检查接口连续 3 次失败GPU 使用率DCGM Exporter 拉取长期高于 90%显存占用DCGM Exporter 拉取接近卡容量上限推理延迟业务侧埋点P95 超过预设值把这些指标接进 prometheus 之后最重要的告警不是「挂了」而是「显存持续贴顶」——它通常意味着并发参数设大了或者某个调用方在传超长上下文等到 OOM 再处理就已经影响线上请求了。4. DeepSeek API 如何调用从 curl 到 vscode 接入服务对外暴露之后客户端侧的接入是最后一公里。这一段的核心认知是多数主流推理服务和云厂商接口都兼容 OpenAI 的请求结构所以客户端配置可以复用只需要改 base_url 和模型名。4.1 兼容协议的请求结构与参数含义先用最朴素的方式确认接口通不通再考虑接入工具。curl -s http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer not-needed-locally \ -d { model: deepseek-doc, messages: [ {role: system, content: 你是文档解析助手只输出结构化结果}, {role: user, content: 把这段配置里的端口和卷路径列出来} ], temperature: 0.2, max_tokens: 512, stream: false }model字段填的是本地注册的别名不是权重文件路径写错会直接返回模型不存在。Authorization在本地部署里通常无校验但很多客户端会强校验这个头存不存在所以随手填一个占位值最省事。max_tokens在推理模型上要留意部分模型会先输出一段思考过程再给答案额度给小了答案会被截断看起来像是模型「答了一半就停」。换成 Python 调用时结构完全一致用官方 SDK 改一个地址即可from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, # 指向本地服务不开源则换云端地址 api_keylocal-key, # 本地无鉴权占位即可 ) resp client.chat.completions.create( modeldeepseek-doc, messages[{role: user, content: 输出一份三点式部署检查清单}], temperature0.3, # 低温度更适合格式稳定的清单类输出 timeout120, # 长上下文首 token 慢超时要给足 ) print(resp.choices[0].message.content)timeout是本地部署最容易踩的坑。默认超时往往只有几十秒而长文档首次推理要等模型加载加 prefill很容易在客户端侧先断开服务端还在算日志里看到的是一堆中断请求。4.2 vscode 接入 deepseek 与 codex 类工具接入的配置差异在编辑器里接入本地模型配置项看起来各家不同拆开看只有三个变量接口地址、模型名、是否走流式。配置项本地 ollama 部署云端 APIbase_url指向本机或内网服务端口服务商提供的地址model本地注册的模型别名服务商公布的模型名api_key占位字符串真实密钥走环境变量流式输出建议开启体验更接近原生建议开启{ models: [ { name: deepseek-local, provider: openai-compatible, baseUrl: http://127.0.0.1:11434/v1, apiKey: local-key, model: deepseek-doc, contextLength: 8192 } ] }contextLength这一项必须和 Modelfile 里的num_ctx对齐。客户端以为有 32K 上下文、服务端只加载了 8K结果就是客户端把超长内容塞进去服务端静默截断前半段模型答非所问排查半天以为是模型能力问题。跨机器的场景下端口要写内网地址同时确认防火墙放行这类工具默认不会给出「连接被拒绝」之外的提示。4.3 流式输出、超时与重试的排错路径按现象分常见故障基本落在下面几类现象大概率原因处置方式连接被拒绝服务未启动或只绑了 127.0.0.1改监听地址并确认端口首 token 迟迟不来模型冷启动或 prompt 过长调大超时开 keep_alive输出中途截断max_tokens 偏小或上下文超限两者一起检查返回内容重复temperature 过低叠加重复惩罚缺失温度提到 0.3 以上显存溢出并发数或 num_ctx 过大先降并发再降窗口重试策略要小心推理类请求属于重计算盲目重试会放大负载。合理的做法是只对连接类错误重试对超时类错误做退避并且限制最大重试次数。流式输出场景下客户端断开会留下服务端仍在计算的请求本地部署里配合 keep_alive 短一些能减少这种浪费。5. 把部署结果沉淀成可检索 PDF 手册的进阶做法部署完的下一件事是把过程沉淀下来否则下次换机器又要重来一遍。这里有个有意思的闭环生成 PDF 手册的同时把 PDF 本身喂回 DeepSeek做成一个能问的部署知识库。最省事的采集方式是把命令、参数表和排错记录整理成 Markdown再用文档工具导出成 PDF。不要用截图拼的 PDF那种文件机器读不了。真正可检索的手册必须保留文本层字体里要包含中文字形否则抽取出来全是乱码表现为 PDF 图片中文设置没生效。接下来让 DeepSeek 读这份手册用文本抽取加问答的两段式结构from pypdf import PdfReader from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keylocal-key) def load_manual(path: str) - str: reader PdfReader(path) pages [] for i, page in enumerate(reader.pages): text page.extract_text() or # 页码标记保留下来方便回答时回溯到具体页 pages.append(f[page {i 1}]\n{text}) return \n.join(pages) manual load_manual(DeepSeek极简部署手册.pdf) # 手册通常超过单次上下文按段落切块后只把命中块送进模型 chunks [manual[i:i 2000] for i in range(0, len(manual), 2000)] question 7B 模型在 8GB 显存上跑长文档num_ctx 应该设多少 # 极简关键词召回生产环境换成向量检索 hits [c for c in chunks if num_ctx in c or 显存 in c][:2] context \n\n.join(hits) resp client.chat.completions.create( modeldeepseek-doc, messages[ {role: system, content: 只依据给定手册内容回答找不到就说未收录并标注页码}, {role: user, content: f手册内容\n{context}\n\n问题{question}}, ], temperature0.1, # 检索问答要的是忠实复述不是发挥 max_tokens800, ) print(resp.choices[0].message.content)extract_text()对扫描件返回空串这是判断 PDF 有没有文本层最直接的方法随机抽三页如果都是空就先做 OCR 再进流程。分块大小设 2000 字符是个折中块太小会切断参数表的上下文块太大一次召回就吃掉半个上下文窗口。temperature压到 0.1 并强制标注页码是为了在手册场景里优先保证可追溯——回答里带上页码人可以直接翻回去核对这比答案听起来多流畅重要得多。验证这套东西有没有真正跑通有个很硬的检查方式故意问一个手册里没写的问题比如「这份手册推荐了几种监控方案」如果模型开始编造具体数量说明系统提示里的约束没生效需要把「找不到就说未收录」这条前置到 system 里而不是 user 里。反过来如果它能稳定回答出未收录说明检索链路、上下文注入和指令遵循三环都到位了这份 PDF 才算从一份静态文档变成了可复用的部署资产。本文还有配套的精品资源点击获取
