简介DeepSeek 平台搭建往往卡在环境准备和细节配置上这份 Word 文档针对运维人员与开发者把从服务器硬件要求、操作系统与数据库选型到安装依赖、初始化数据库、配置 Web 服务器、启动服务的完整流程拆成了可照做的步骤。资源为单个 Word 文档压缩包约 35KB条目式书写查阅方便。文档不仅覆盖安装主流程还专门列出后续上线需要关注的内容用户账号与权限划分、索引规则配置、并发与缓存调优、防火墙和 SSL 安全设置以及监控和日志排错方法适合部署前厘清依赖关系也适合部署中随时对照检查。文档按部署前、部署中、上线后的顺序组织遇到问题可直接查阅对应章节。已有 1539 人浏览学习是新手快速落地 DeepSeek 服务的实用入门手册。1. DeepSeek 部署详细方式先分清你要部署的是模型还是服务我刚接了一个内部项目要在内网给业务部门部署一个文档搜索助手。对方点名要用 DeepSeek我以为把官网 API 接进来就行结果对接团队反问一句“模型是要跑在我们自己的服务器上还是你用云端接口”之后我才发现所谓 DeepSeek 部署详细方式其实可以拆成三条完全不同的路本地部署开源模型、企业私有化部署、官方在线 API 接入。选错路径轻则上线延期重则采购的 GPU 资源直接打水漂。本文按一线实施顺序把这三条路径的选型、最小部署命令、业务接入和排错一起讲完。凡是能直接抄的命令我都给全凡是自己踩过的坑会单独标注。你可以把这份笔记当成一份从零到上线的实际操作手册来读。2. 部署前先算账同样叫 DeepSeek三条路径的命不同2.1 三条路径的边界在线 API、Ollama 本地部署与 vLLM 服务化第一条是官方在线 API。它不需要你准备 GPU也不需要下载任何模型文件开通账号、拿到 key、把 base_url 填进应用就可以联调。这类方案适合原型团队、轻量级应用以及不方便维护 GPU 服务器的场景。但你要接受两个前提业务数据会经过第三方服务费用按 token 增长。我遇到过客户把内部合同全文直接丢进 API 做摘要后来合规一票否决整个项目推倒重做。所以凡是对数据敏感度高的场景我默认先谈私有化部署。第二条是 Ollama 本地部署。Ollama 把模型权重、推理后端和管理命令整合成一个极简工具是本地部署大语言模型的最短路径。执行两条命令就能跑ollama pull deepseek-r1:7b然后ollama run deepseek-r1:7b。它适合单机、小团队、原型验证和离线内网环境缺点是并发能力弱原生接口对排队、流控和指标监控支持得不够不适合直接对外暴露成正式业务。我一般把它定位成“试验台”而不是“生产服务”先把模型和效果跑通再决定要不要往下一层走。第三条是 vLLM 服务化。vLLM 是目前部署 DeepSeek 这类开源模型的主流生产方案PagedAttention 机制能把显存利用率做得比普通推理后端高不少还支持连续批处理、动态并发和 OpenAI 兼容接口。常见做法是用 Docker 拉起一个推理服务挂上模型权重目录就可以对外提供接口。相比 OllamavLLM 的学习门槛更高但换来的是吞吐和并发能力。企业大模型私有化部署想真正扛住几十人同时使用vLLM 基本是绕不开的基础设施。三条路径没有谁绝对优于谁错误的是在不对的阶段选了不匹配的方案。我自己经历过的教训是先图省事用 Ollama 挂了生产结果并发上来后频繁排队和超时最后不得不迁移到 vLLM代码里的模型名、超时参数、鉴权方式全部要跟着改额外多花了两天时间。选型这一关多花一小时思考后面就少熬两个夜。2.2 按硬件与业务状态选型显存估算与量化基本账先把三条路线放进一张表里对比后面所有决策都参照它部署路径典型硬件适用阶段并发能力主要代价官方 API无 GPU 要求原型、非敏感数据较高数据出域、token 费用Ollama 本地部署16GB~48GB 显存单机验证、小团队弱吞吐瓶颈、缺监控vLLM 服务化单卡或多卡生产私有化强学习与运维成本高硬件方面最关键的是估算模型显存占用。以目前 DeepSeek 常见的蒸馏模型为例7B 模型在 Q4 量化下大约占 5~6GB 显存14B 约 10~12GB32B 直接到 20GB 以上。这只是权重的部分推理过程中的 KV cache 还要再占一块上下文越长KV cache 越大。所以不要只看模型文件的体积。我个人的血泪经验是24GB 显存优先跑 7B 或 14B把上下文和并发留足24GB 单卡硬上 32B 属于“能跑但很难用”速度会让人怀疑机器是不是坏了真想上 70B 或原生大模型至少准备两张 48GB 卡否则就走 API。选择时还考虑业务阶段。可以在两个小时内跑通同时这块环境允许且数据敏感度低直接注册 API 花半天时间接线是最好的想要先验证效果又没有现成 GPU用 Colab 或云 GPU 实例租一张 24GB 的卡装 Ollama 试跑一旦确定要长期做知识库、文档检索这类内网工具建议直接上 vLLM 方案避免二次迁移。这里想说一句大模型部署很多人上手觉得是玄学其实变量就那么几个——显存、量化档位、上下文长度、并发数。把每个环节的物理限制算清楚按规则走踩坑次数会少一半。参数怎么定后面两章我会演示。3. 用 Ollama 在本地跑通 DeepSeek 的最小部署命令3.1 安装与拉取模型ollama pull 前需要准备的环境常见做法是在 Linux 服务器或 Windows 的 WSL2 里安装 Ollama。我最常用的一键安装命令是curl -fsSL https://ollama.com/install.sh | sh这条命令会下载官方安装脚本并自动安装。完成后先用两个命令确认基础状态ollama --version ollama listollama list列出的是本地已有的模型新装环境下为空是正常的不代表安装失败。接下来真正开始下载 DeepSeek 权重ollama pull deepseek-r1:7bdeepseek-r1:7b是模型标签可以换成 1.5b、14b、32b、70b 等。拉取速度取决于网络到模型仓库的实际带宽如果在内网或者跨网拉取慢需要提前准备离线导入方案。我一般是在外网机器拉好模型后把整个~/.ollama/models目录打包再拿到内网目标机器解压# 外网机器拉取模型并打包整个模型目录 ollama pull deepseek-r1:7b tar -czf deepseek_models.tar.gz -C ~/.ollama models # 内网目标机解压到默认目录 tar -xzf deepseek_models.tar.gz -C ~/.ollama ollama list这里必须强调打包时要连同manifests目录一起不能只拷blobs。blobs是权重二进制manifests是模型注册信息缺了后者Ollama 不会识别已有模型启动时会提示model not found。我见过同事只拷了 blobs 目录然后折腾了半天才发现 manifests 没同步。拉取前还要检查磁盘空间。7B Q4 模型解压后通常需要 5~8GB14B 至少留 12~15GB如果传输过程还保留了压缩包空间需求再翻倍。磁盘不足最常见的表现是进度条到 80% 左右中断并报received unexpected EOF重新拉取后会基于已有分块续传但磁盘不清理还是会卡在同一个地方。3.2 启动服务与接口验证OLLAMA_HOST 和 curl 的配合模型就位后启动服务只需要一条命令ollama serve默认监听127.0.0.1:11434只能本机访问。如果部署在内网服务器要给其他机器提供访问就设置环境变量后再启动export OLLAMA_HOST0.0.0.0:11434 ollama serve0.0.0.0表示监听所有网卡局域网内的机器就可以通过宿主机 IP 访问 11434 端口。先跑一个最简单的对话验证模型本身没坏ollama run deepseek-r1:7b 用一句话解释什么是检索增强生成能输出完整中文回答说明模型和推理链路都通了。接下来验证 HTTP 接口这是后面写业务代码的直接依据curl http://127.0.0.1:11434/api/generate \ -d {model: deepseek-r1:7b, prompt: 你好简单介绍一下你自己, stream: false}返回的 JSON 里有response、total_duration、eval_count等字段。字段解读很简单response是模型生成的文本total_duration是本次请求总耗时eval_count是生成的 token 数量。用eval_count除以生成阶段耗时可以粗略算出每秒生成 token 数这个值就是后续压测的基线。通常 7B Q4 模型在消费级显卡上能跑到每秒 20~40 token如果远低于这个范围检查是否跑在 CPU 上或者显存不足。提示OLLAMA_HOST0.0.0.0会把推理端口暴露给整个局域网企业内部务必放到防火墙后面不要直接映射到公网否则任何人都能调用你的模型接口。4. 把 DeepSeek 接入业务系统OpenAI 兼容接口与反向代理细节4.1 Python 调用 DeepSeek 接口本地与在线共用一套代码服务起来以后本地部署和官方 API 的调用方式几乎一致因为两者都提供 OpenAI 兼容接口。常见做法是用环境变量切换 base_url开发环境指向本地 Ollama 或 vLLM生产环境指向官方 API。一个可直接抄走的 Python 示例from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, # 本地 Ollama 的 OpenAI 兼容地址 api_keyollama # 本地推理不需要真实 keySDK 要求非空 ) resp client.chat.completions.create( modeldeepseek-r1:7b, messages[ {role: system, content: 你是一名数据搜索与分析助手只根据给定材料回答}, {role: user, content: 把下面这段内容压缩成三行摘要...}, ], temperature0.3, max_tokens1024, streamFalse, ) print(resp.choices[0].message.content)参数说明base_url换成http://你的服务器IP:11434/v1就能访问远程 Ollama换成官方 API 地址就能切到在线模式。temperature控制随机性做数据抽取和摘要时我习惯调到 0.1~0.4做开放问答再升到 0.7。max_tokens是单次输出上限如果回答经常被截断先检查这个值而不是怀疑模型出问题。streamTrue开启流式返回用于聊天类前端。如果不想引入openai库用标准库requests也能完成同样的事import requests payload { model: deepseek-r1:7b, prompt: 用 50 字概括这份会议纪要的结论, stream: False, } r requests.post( http://127.0.0.1:11434/api/generate, jsonpayload, timeout120, # 大模型推理可能超过 30 秒超时必须放宽 ) data r.json() print(data[response])timeout120不是随手写的。我见过太多把超时设成 10 秒的项目部署没问题请求一慢就被客户端掐断最后误判成服务端故障。另外如果你想实现多轮对话承接就把上一轮的用户消息和助手回复都放进messages数组再发一次请求本地接口和官方接口都按这个约定工作云端不会替你记住任何状态。关于应用集成再多说一句如果团队不想写底层调用可以用 Dify 这类开源平台做可视化工作流把 DeepSeek 的接口地址配置进去拖拽几个节点就能搭出问答机器人技术团队则可以把本地接口直接配给 Codex 等终端编程助手让工具链统一走你部署的模型服务而不是各自连外部渠道。4.2 用 Nginx 反向代理保护内网端口超时与缓冲两个配置点模型服务不应该一直裸奔在 11434 端口。常见做法是用 Nginx 做反向代理把内部推理端口收起来对外只暴露一个统一入口。我实际用过的配置骨架是这样的server { listen 80; server_name ai.internal.example.com; client_max_body_size 20m; location / { proxy_pass http://127.0.0.1:11434; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Connection ; proxy_read_timeout 300s; proxy_send_timeout 300s; proxy_buffering off; } }这里最容易被忽略的三个点第一proxy_read_timeout 300s。Nginx 默认 60 秒读超时长文本生成很容易超过改成 300 秒后偶发中断立刻减少。第二流式接口必须关闭缓冲proxy_buffering off确保用户前端的打字机效果是逐字出现的而不是等全部生成完一次性吐出来。第三proxy_set_header Connection 是为了清理默认的 keep-alive 头让上游连接更稳定。如果要上 HTTPS我的习惯是用 certbot 自动申请证书sudo certbot --nginx -d ai.internal.example.com三个月有效期到期自动续运维成本很低。内网环境没有域名时也可以自签证书但务必把根证书装进所有业务客户端的信任链这个步骤在 Android 和 Windows 环境经常被漏掉于是出现“curl 能通、业务系统报 SSL 错误”这种奇葩现象。排查时先用浏览器访问一次看证书警告类型就能迅速定位是中间证书缺失还是客户端不信任。5. DeepSeek 部署避坑显存、超时与半路翻车的五个排查记录5.1 显存与模型加载的两个典型问题记录记录一CUDA out of memory。现象并发请求一上来推理进程直接崩溃日志里出现torch.cuda.OutOfMemoryError业务侧表现为服务频繁中断。原因部署时只看了模型权重文件大小忽略 KV cache。7B 模型权重 6GB 左右但如果把上下文加长到 8192 或 16KKV cache 会显著增长显存压力比预期大得多。解决按这个顺序处理——先降低max-model-len或OLLAMA_CONTEXT_LENGTH限制上下文长度再把量化档位降一档最后才考虑加显存。顺序别反我为了在 24GB 单卡跑 14B 模型折腾了半小时最后发现只是上下文开太大。记录二模型反复加载响应时快时慢。现象同一个接口前一个请求 2 秒返回后一个请求要等 20 秒日志里反复出现loading model。原因显存刚好卡在模型大小附近Ollama 在显存不足时会踢掉空闲模型新请求进来再重新加载形成“换出换入”的抖动。解决通过环境变量限制并发和常驻模型数OLLAMA_NUM_PARALLEL控制并发请求数OLLAMA_MAX_LOADED_MODELS控制同时加载的模型实例数。显存偏紧时把这两个值调小优先保证响应稳定而不是追求更多并发。5.2 调用侧与模型拉取的三个排查记录记录三Python 服务每次请求报requests.exceptions.ConnectTimeout。现象在服务器本机 curl 完全正常换成业务应用访问就超时防火墙看起来也放行了端口。原因curl 走的是127.0.0.1回环地址业务应用走的是内网 IP 或容器网络两边网络路径不同。要么防火墙只放行了本机回环要么容器网络访问不到宿主机端口。解决先在业务所在的机器上用curl http://你的服务器IP:11434/api/version测一次。如果通检查代码里的 base_url 是否写成了宿主机 IP如果不通检查宿主机防火墙对 11434 端口的入站规则。Nginx 代理场景还要同步检查proxy_read_timeout超时可能出现在代理层而不是模型层。记录四输出到一半被截断截断位置看起来随机。现象对话经常戛然而止服务端日志没有明显报错。原因最常见是max_tokens设置太小输出达到上限。另一类是 Nginx 缓冲未关闭流式连接被缓冲后触发读超时。还有一类是上下文长度打满接口返回了done_reason: length。解决先在代码里打印finish_reasonstop表示正常结束length表示被长度截断后者就把max_tokens调大。同时检查 Nginx 的proxy_buffering配置两种因素一起排除。记录五ollama pull中途报received unexpected EOF。现象模型拉取到一半失败重试后ollama list仍然看不到模型。原因内网到模型仓库的网络不稳定或者本地磁盘空间不足导致分块数据写入失败。解决清理磁盘到模型文件两倍以上的空间后重新ollama pullOllama 会自动续传。如果网络长期不稳定改用离线导入在外网机器拉完整后打包 models 目录传入内网解压。这个方案我前面给过命令亲测比反复重试省时间。这五个坑覆盖了我实际部署 DeepSeek 时遇到的大部分故障场景。定位顺序很重要先看服务端日志再做客户端测试最后查网络链路不要一上来就重装环境。6. 部署完的验证与进阶用压测给 DeepSeek 服务做个体检服务部署完只是第一步。我习惯在交给业务前跑一轮压测把“通不通”从玄学变成数字。工具不用重型hey或wrk就够hey -n 200 -c 10 -m POST \ -H Content-Type: application/json \ -d {model:deepseek-r1:7b,prompt:写一段产品需求文档,stream:false} \ http://127.0.0.1:11434/api/generate看两个数错误率和平均响应时间。错误率不为零先回头查第五章的五个坑位平均响应时间大于 15 秒说明并发窗口太大或模型档位偏高。我的做法是先调到单并发测出一条基线再把并发从 1 逐步加到 5、10、20观察响应时间拐点在哪里。拐点附近的值就是这台机器合理的生产并发上限。如果生产环境换成 vLLM启动命令的典型形态是这样docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai \ --model /models/deepseek-r1-distill-qwen-7b \ --max-model-len 8192 \ --gpu-memory-utilization 0.90--gpu-memory-utilization 0.90表示允许 vLLM 使用 90% 显存做 KV cache这个值比默认激进适合 GPU 独占的推理机器。如果压测时 QPS 上不去优先调这个参数和并发数而不是怀疑模型本身。有些团队也会选择 GPUStack 这类开源管理工具来可视化分配 GPU 资源Windows 环境下的多卡管理会省力不少。上线以后我建议每周记录一次ollama ps的输出和日志里的eval_count对比前后两周的生成速度。这类基线数据比同事的“感觉变慢了”可靠得多。我还有一条自己的排障习惯服务长时间运行后显存碎片化会导致响应变慢定期重启推理进程能解决很多说不清的退化问题。这套体检和排障顺序帮我兜过好几次底希望也能帮到你。本文还有配套的精品资源点击获取