简介这是一份DeepSeek平台部署全程指南针对需要自行搭建智能数据搜索与分析系统的开发者、运维人员及技术爱好者。文档以实际部署顺序为主线从硬件、软件、数据库、Python环境、域名与SSL证书等前置条件讲起逐步覆盖安装包下载、数据库连接配置、依赖包安装、初始化脚本执行、Web服务器反代设置以及服务启动与功能验证同时补充用户权限管理、数据导入、性能调优、安全防护和日志监控等后续事项帮助读者避开常见问题并完成可用部署。无论是首次部署还是环境迁移都可以按文档顺序逐步推进对关键配置项形成清晰认知。资源封装为单个doc文档压缩包约35KB打开即可对照章节操作。已有1539人学习对正在准备DeepSeek环境的人来说是一份结构清晰、可落地的排错式操作参考。1. DeepSeek 部署到底在部署什么三条路线先选对再动手DeepSeek 部署这个操作本质上不是把某个安装包双击一下而是把一个开源大语言模型的权重落到你自己的机器、内网或云主机上让它对外提供对话和数据搜索分析能力。它适合有数据合规要求的企业、做私有化大模型落地的工程师以及想摆脱按 token 计费约束的独立开发者。部署方式通常分三条路线消费级显卡跑量化模型、多卡服务器跑高精度版本、以及自建一个服务网关对接外部算力。动手之前只有一个问题需要先回答你的需求是“能对话”还是“能并发服务”这决定了后面所有参数怎么设也决定了你该用直觉选引擎还是按产量选引擎。2. 本地部署与 API 部署的选型硬件门槛、模型量化与推理引擎2.1 模型大小的选择deepseek 各尺寸的显存账DeepSeek 权重仓库里运维场景经常见到的是 deepseek-r1 系列和 deepseek-llm 系列r1 的蒸馏版本从 1.5B、7B、8B 一直到 70B。显存账要这样算半精度下每个参数占 2 字节7B 模型权重约 14GB加上 KV cache 和激活值16GB 显存会非常紧换成 4bit 量化权重降到不足 5GB8GB 显卡也能跑只是速度慢。选型判断我一般用这组经验值8GB 显存选 1.5B 或 7B 量化版16GB 显存选 7B/8B 的量化或半精度24GB 以上再考虑 14B 或 32B 的 AWQ/GPTQ 量化而 A100、A800 这类 80GB 设备才适合碰 70B。很多部署翻车都翻在“权重装得下上下文装不下”上因为长文本对话时 KV cache 会随轮次线性增长这部分开销在选型阶段被普遍低估。除了显存还要注意内存带宽和磁盘读取速度。CPU 推理时内存带宽直接决定 token 生成速度GPU 推理时 PCIe 带宽影响模型加载和显存换入换出。同一个模型在两台看起来配置相同的服务器上首 token 延迟差 3 倍多半是磁盘从 SATA 换成了 NVMe。条件允许的话把模型权重放到 NVMe 盘加载速度的改善比换一张显卡还明显。2.2 推理引擎选型Ollama、vLLM、SGLang 各自在什么场景下占优Ollama 适合单机、低并发、快速验证。一条命令拉模型一条命令起服务自带 OpenAI 兼容接口对新手最友好也是本地部署 DeepSeek 最容易上手的选择。vLLM 的目标场景是生产服务化。它用 PagedAttention 管理 KV cache显存利用率高并发吞吐量好适合企业内网多个业务系统同时调用。启动时能直接看到吞吐指标方便做压测对比。SGLang 在多轮对话和结构化输出上有额外优化但资料和案例相对少我一般只在特殊业务场景才引入它。还有一种常见做法用 Flask 或 FastAPI 自己包一层 HTTP 接口。这种方式适合团队里已经有业务服务端不想引入新引擎直接用 Python 加载模型权重然后对外暴露接口。它的优点是代码完全可控能按业务定制缺点是并发一高显存管理和请求排队都得自己写OOM 了没人帮你兜底。我的建议是个人开发者和验证环境直接用 Ollama正式的内网服务用 vLLM想折腾性能调优再去看 SGLang。选型决定后续参数在哪个文件里改——Ollama 走环境变量vLLM 走启动参数两套配置不要混着记。3. 用 Ollama 跑通 DeepSeek 的最小部署命令从拉模型到调参3.1 安装 Ollama 与拉取 DeepSeek 模型常见做法是在 Linux 服务器上先安装 Ollama。一条命令搞定二进制和 systemd 服务curl -fsSL https://ollama.com/install.sh | sh这条命令把 Ollama 可执行文件和开机自启服务一并配好。装完先确认服务状态systemctl status ollama状态显示 active (running) 就继续。然后拉取 DeepSeek 模型比如 7B 量化版ollama pull deepseek-r1:7b模型体积约 4.7GB具体大小和下载时间取决于网络环境。拉完先做一次离线对话验证确保推理链路是通的ollama run deepseek-r1:7b进入交互界面后输入“你好”能看到回复说明本地推理已经跑通。这一步不要跳过很多后续问题都是从这里开始暴露的比如显存不够、模型标签记错、加载时间异常偏长。3.2 修改默认端口、并发数与显存占用的三种方式Ollama 默认监听 127.0.0.1:11434只允许本机访问内网其他机器调不了。要对外提供服务先改监听地址export OLLAMA_HOST0.0.0.0:11434临时环境变量只在当前终端生效重启或开机后会丢。systemd 方式是在服务配置文件里加 Environment 变量这样更持久。执行sudo systemctl edit ollama在打开的编辑窗口里填[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_NUM_PARALLEL4 EnvironmentOLLAMA_MAX_LOADED_MODELS1OLLAMA_NUM_PARALLEL 控制同时处理的请求数。设得太大显存容易被打满设得太小多用户同时访问时排队严重。OLLAMA_MAX_LOADED_MODELS 控制同时驻留内存的模型数量只有一台机器上部署多个模型时才需要调大单模型部署保持默认即可。改完配置执行sudo systemctl daemon-reload sudo systemctl restart ollama验证是否生效看日志journalctl -u ollama -n 30 --no-pager日志里能看到监听地址的变化。如果只改了环境变量却没重启服务端口依然监听在回环地址上这是最常见的无效修改。3.3 用 OpenAI 兼容接口做一次调用验证Ollama 自带 /v1/chat/completions 接口业务系统可以直接按 OpenAI 的调用方式来对接。验证命令curl http://服务器IP:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [ {role: user, content: 用一句话解释什么是数据库索引} ], stream: false }返回值里 usage 字段包含 prompt_tokens、completion_tokens 和 total_tokens这三个值后续做成本核算和限流都要用。注意 model 字段必须填你 pull 下来的确切标签填错会报 model not found。至于 codex 这类外部工具接入 DeepSeek做法本质相同在客户端里把 api_base 指向本地服务的地址其他调用逻辑不变这就是 deepseek api 如何调用这类问题最常见的答案。4. 用 vLLM 部署 DeepSeek 到生产OpenAI 兼容 API 与服务化参数4.1 vLLM 安装与启动参数说明vLLM 需要 Python 3.9 或更高版本建议用虚拟环境隔离避免污染系统 Python。安装命令python -m venv vllm-env source vllm-env/bin/activate pip install vllm启动服务前先确认模型的来源路径。如果你是从 Hugging Face 直接拉权重用仓库名如果是内网离线环境把权重下载到本地目录然后用目录路径加载vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 8 \ --enforce-eager几个关键参数解释。--max-model-len 控制最长上下文长度设太大会撑爆显存设太小长文档被截断按业务实际输入长度加 20% 余量来设。--gpu-memory-utilization 控制显存使用上限默认 0.9生产环境留 0.8 到 0.85 更安全因为并发上来之后 KV cache 会动态占显存。--max-num-seqs 控制并发序列数8 是起步值显存足够再往上加。--enforce-eager 是关闭 CUDA Graph 优化虽然略降吞吐但能减少动态形状和首次加载时的报错适合先跑通再优化。多卡服务器需要按 GPU 数量启用张量并行vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.85--tensor-parallel-size 设为 4模型会切分到 4 张卡上并行推理。设小了显存放不下设大了卡间通信开销反超计算收益一般原则是卡间通信走 NVLink 再考虑加大并行度。4.2 用 curl 调用 OpenAI 兼容 API 验证服务启动成功后日志中会显示 Uvicorn running on http://0.0.0.0:8000。用 curl 验证服务是否真的可调用curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, messages: [{role: user, content: 推荐三本适合运维读的技术书}], max_tokens: 512, temperature: 0.7 }response 里的 model、created、usage 字段和 Ollama 基本一致区别主要在元数据细节vLLM 会返回更完整的 token 统计。业务系统接入时两种服务可以共用同一套 OpenAI SDK 配置只需替换 base_url。这个特性让企业内网把模型从 Ollama 迁移到 vLLM 时上层代码几乎不用改。还要验证健康检查端口curl http://localhost:8000/health返回 OK 说明探活通过。这一步关系到后续配置负载均衡和容器编排时的存活检查规则很多人漏了它结果服务没起来上层一直报 503。5. 部署避坑显存不足、上下文失效与并发打满的排查5.1 现象启动时直接报 CUDA out of memory进程退出原因模型权重、KV cache、临时激活值三者叠加后超过显存上限。部署者通常只看权重体积忽视了 KV cache 会随上下文长度膨胀。解决先把 --gpu-memory-utilization 降到 0.7再把 --max-model-len 从 8192 降到 4096如果还溢就换更小尺寸的量化模型。vLLM 报错时会打印显存分配明细不要只看最后一行红色输出重点看 KV cache 预留了多大。顺手在 nvidia-smi 里确认有没有别的进程占着显存多卡机器上这个问题很常见。5.2 现象curl 调用时报 model not found原因请求里的 model 字符串和启动参数或服务端的模型名不一致。Ollama 场景常见因为本机拉过多个模型默认模型和请求模型不是同一个。解决先执行 ollama list 看准确标签再用该标签发起请求。vLLM 场景则要检查是否用了 --served-model-name 自定义服务名称如果指定了客户端必须用这个名称调用不能用权重目录名或 Hugging Face 仓库名。5.3 现象内网其他机器访问不到但本机 curl 正常原因服务监听在 127.0.0.1 回环地址上只接受本机连接。Ollama 默认如此未显式指定 --host 的自建服务也如此。解决Ollama 按 3.2 节改 OLLAMA_HOST0.0.0.0:11434 并重启服务vLLM 启动命令必须带 --host 0.0.0.0。同时检查服务器防火墙放行端口云主机还要确认安全组规则。一个典型的翻车点服务绑定没问题但容器环境里端口映射写错宿主机 8000 没映射到容器 8000。5.4 现象多用户同时使用时单请求时延从 1 秒涨到 20 秒原因并发请求数超过引擎的 max-num-seqs请求进入排队。也可能连续对话的上下文过长每次请求都重复处理历史 token显存和计算加倍消耗。解决vLLM 把 --max-num-seqs 从 8 调到 16 到 32同时重新观察显存峰值Ollama 则调大 OLLAMA_NUM_PARALLEL。上下文过长导致的时延问题需要从业务侧做对话裁剪不能只靠服务端调参解决。先压测再调参不加验证地盲目加大并发只会把排队位置往前挪。5.5 现象长文档输入时输出截断上下文信息丢失原因默认上下文长度小于实际输入。Ollama 的 num_ctx 默认只有 2048超出部分被截断模型只能看到文稿开头一小段。解决启动时指定上下文长度ollama run deepseek-r1:7b --num-ctx 8192或在 Modelfile 里写 num_ctx 字段并重新创建模型。vLLM 则在启动时把 --max-model-len 设置为业务真实需要的长度上限。上下文长度直接影响显存占用设长了并发能力下降设短了输出质量崩这个参数必须拿真实业务数据去标定。6. 验证部署是否合格的五个检查项与一个压测技巧部署完成后不建议直接接业务我每次都用一套固定流程验收五个检查项缺一不可。第一单请求延迟固定问题连续询问 5 次观察首 token 延迟和总延迟波动波动超过 30% 说明服务状态存在抖动需要看显存和 CPU 占用。第二并发压测用压测工具打 /v1/chat/completions观察吞吐和错误率。第三显存水位压测过程中持续看 nvidia-smi 输出显存占用超过 90% 就要降低并发。第四日志与探活确认 /health 返回 OK日志中无 OOM 关键字。第五数据验证用一组带业务预期的提示词验证输出质量模型能跑通不代表回答符合业务要求。压测有个值得一试的技巧不用等业务接入先把 body 文件准备好压测命令几秒钟就能出结果cat body.json EOF {model: deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, messages: [{role: user, content: ping}], max_tokens: 16} EOF ab -n 200 -c 10 -p body.json -T application/json http://localhost:8000/v1/chat/completions把 max_tokens 压到 16压力集中在调度和显存分配上而不是生成阶段这样测出的并发上限更接近系统真实承载能力。看结果时重点盯四个数字Requests per second、Time per request、Failed requests、Transfer rate。失败率超过 1% 就先降并发别急着加卡。这组流程是我不止一次把“能跑”误判成“能上线”之后攒出来的教训。早期我在内网部署过一台单卡 7B 机器单路调用一切正常第二天三十几个人同时用直接把卡打满触发进程重启。后来每次部署后我都先做一轮最小压测再谈接入。希望帮到你。本文还有配套的精品资源点击获取