简介面向需要自行安装配置DeepSeek工具的开发人员这份PDF教程围绕部署全流程展开从硬件配置与操作系统选择到Python 3.6以上环境及requests、beautifulsoup等依赖库的安装再到通过官方安装包或Git源码编译完成部署均有清晰说明。教程重点讲解配置文件中的User-Agent、请求头、抓取深度与代理IP池设置并介绍测试抓取、结果查看以及数据清洗等实际用法同时提醒遵守Robots协议适合有爬虫基础、希望快速上手的读者对照操作。资源为1个PDF文件压缩包约823KB内容组织紧凑便于离线阅读和按步骤查阅教程还附带常见问题与社区支持说明可帮助减少部署中的排错成本。目前已有327人学习下载是一份轻量实用的DeepSeek部署入门指南。1. 本地部署 DeepSeek为什么 Ollama 与 vLLM 是两条主流路线把 DeepSeek 这类大模型跑在自己机器上最反直觉的一点是显存不是唯一瓶颈你的推理框架选错了哪怕显存够用吞吐量也会惨到没法用。我见过不少人在 4090 上跑 DeepSeek-R1 蒸馏版用默认的 transformers 脚本一次性生成结果每秒只能吐几个 token还得手动处理请求排队连一个简单的前端页面都喂不饱。换个思路用 Ollama 做轻量接入、用 vLLM 做生产服务同样的显存能撑起倍数级的并发这才是本地部署的核心价值。这篇文章不打算泛泛讲「安装 Python、装依赖」这种入门内容而是直接把两条主路线拆开先讲清楚选型依据再给可复现的部署命令、参数表、API 对接方式和排错经验。适合两类人一是想在单机上快速跑起交互式 AI 应用的开发者二是要把它接进 Codex、VSCode 或 Dify 这类工具链、需要稳定服务的运维工程师。你不一定需要顶级显卡但得知道量化、上下文长度和并发这三个变量是怎么共同影响最终体验的。2. 部署前的选型硬件基线、模型量化与运行时取舍2.1 显存与吞吐量的权衡多少 G 显存能跑什么模型DeepSeek 官方开源的主要是 7B、16B 级别的稠密模型以及更早版本的 MoE 结构社区里最常见的两个版本是 deepseek-llm-7b 和 deepseek-r1 系列的蒸馏版。无论哪个显存占用都可以用一条粗略公式预估模型参数量乘以每个参数占用的字节数再乘以量化系数。FP16 下7B 模型大约占 14GB如果量化到 Q4_K_M参数占用降到 4-5GB加上 KV Cache 和激活值12GB 显存的显卡勉强能跑16GB 以上才舒服。这里容易踩的坑是只看参数量不看序列长度。就算模型权重只占 6GB上下文窗口开到 32K 后KV Cache 会把显存占用推到接近翻倍。实测中4090 24GB 跑 Q4 量化的 7B 模型max 上下文设为 8192 时余量充足一旦调到 32768并发超过 2 个请求就开始报 CUDA OOM。所以选型时先把上下文长度想清楚你是做代码补全、长文档分析还是闲聊这直接决定显存预算。2.2 量化等级怎么选Q4_K_M、Q8_0 与 FP16 的实际差距量化是把 FP16 权重压缩成更低位数的整数表示换取更小的显存占用和更快的加载速度代价是精度损失。社区实践里Q4_K_M 是性价比最高的档位它在 MMLU 这类基准上相对 FP16 的掉点通常在 1-2% 以内但显存减半以上Q8_0 更保守损失几乎为零需要多约 30% 显存FP16 则适合你没显存压力、且对输出质量有极强要求的场景。我的建议是单机 24GB 以下统一用 Q4_K_M32GB 以上可以考虑 Q8_0。有个容易忽略的细节是量化粒度K_M 是较新的 k-quant 方法它对注意力层的量化更精细而 Q4_0 是旧版同位数下质量明显差一截。所以下载模型时不要只看 4bit 就以为都一样后缀带 K_M 和 K_S 的优先选 K_M。在 Ollama 里拉模型时命令比如ollama run deepseek-r1:7b-q4_K_M就是在拉取预量化版本。2.3 运行时选型Ollama 的易用性与 vLLM 的吞吐优势同样是加载同一个 GGUF 或 SafeTensors 格式的模型跑起来的效果差别很大。Ollama 本质上是 llama.cpp 的封装优势是零配置、自带模型仓库和 OpenAI 兼容 API适合个人电脑和轻量服务。vLLM 则是为生产环境设计的推理引擎核心创新是 PagedAttention 和 Continuous Batching能把多个请求的动态 KV Cache 塞进显存碎片里GPU 利用率远高于朴素实现。同样的 4090vLLM 做并发推理时吞吐量往往是 Ollama 的 2-3 倍。选型原则并不复杂你是自己用、接一个编辑器插件Ollama 足够你要开放 HTTP 接口给多个应用同时调用或者需要每秒处理几十个请求直接上 vLLM。两者都支持 OpenAI 格式的/v1/chat/completions接口这意味着上层应用不需要为切换运行时改代码换一个 base_url 就行这也给后续迁移留了余地。3. Ollama 快速部署从拉取模型到 REST API 接入3.1 安装与模型拉取Ollama 的安装比大多数人想象的简单Linux 上一行命令搞定Windows 和 macOS 去官网下载安装包就行。这里我以 Linux 服务器为例完整流程如下# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 启动服务默认监听 127.0.0.1:11434 systemctl start ollama systemctl status ollama # 拉取 DeepSeek-R1 7B 的 Q4_K_M 量化版本 ollama pull deepseek-r1:7b-q4_K_M # 验证模型是否可用 ollama run deepseek-r1:7b-q4_K_M 你好简单介绍一下你自己拉取命令中的deepseek-r1:7b-q4_K_M冒号前是模型名冒号后是标签。标签格式通常由参数量、量化方式组成Ollama 仓库里还提供8b、14b、32b等不同尺寸。ollama run会进入交互式对话输入问题后能看到流式输出这个过程同时验证了模型文件是否完整、CUDA 是否被正确识别。如果发现生成速度很慢首先确认 GPU 是否生效。在ollama run里输入/gpu查看当前设备信息或者直接执行nvidia-smi看显存占用。常见问题是 Ollama 默认没有读到 GPU需要在环境变量里指定# 指定使用 GPU并限制显存使用率为 80% OLLAMA_MAX_LOADED_MODELS1 CUDA_VISIBLE_DEVICES03.2 自定义 Modelfile 调整上下文与参数Ollama 的默认参数偏保守直接用来接应用会出现两个问题上下文长度短模型记不住前面对话温度固定代码生成场景容易跑偏。通过 Modelfile 可以精确控制这些参数。我一般会在项目根目录建一个Modelfile内容如下# 基于已有的量化模型构建自定义版本 FROM deepseek-r1:7b-q4_K_M # 设置上下文窗口大小为 8192 PARAMETER num_ctx 8192 # 设置温度代码场景偏低对话场景可以到 0.7 PARAMETER temperature 0.6 # 设置重复惩罚避免长文本生成时出现死循环 PARAMETER repeat_penalty 1.1 # 设置生成的最大 token 数 PARAMETER num_predict 2048 # 追加系统提示词约束输出格式 SYSTEM 你是一个严谨的编程助手回答代码问题时先给结论再给可运行的代码示例。写好后执行ollama create my-deepseek -f Modelfile生成一个新的本地模型名字为my-deepseek。之后运行或调用 API 时指定这个名字即可。num_ctx是最关键的参数它决定模型能「看到」多少历史 token一般取 4096 或 8192 即可太大不仅占显存而且推理耗时明显增长。3.3 验证 API 与常见报错Ollama 自带 OpenAI 兼容接口启动服务后默认在http://localhost:11434上监听。可以用 curl 快速验证curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: my-deepseek, messages: [ {role: user, content: 用 Python 写一个快速排序要求自带注释} ], stream: false }响应里会包含choices[0].message.content和usage字段。stream参数设为false时接口会等完整生成后一次性返回适合测试实际生产建议设为true走流式前端可以逐字展示。如果请求时返回404 model not found说明模型名打错了返回500多半是显存不足或者上下文参数过大把num_ctx调小再试。另外注意ollama run用的命令行接口和 HTTP API 是两套东西调试 API 时不用打开交互式会话。4. vLLM 生产部署OpenAI 兼容服务、并发与连续批处理4.1 安装与启动服务vLLM 对硬件有更明确的要求需要 NVIDIA GPU并且驱动版本要支持 CUDA 11.8 或 12.1。推荐直接用 Docker 跑省去编译 CUDA 算子的大量时间。以下是一个经过验证的启动流程# 拉取 vLLM 官方镜像 docker pull vllm/vllm-openai:latest # 启动 OpenAI 兼容服务加载 DeepSeek-R1 7B docker run --runtime nvidia --gpus all \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/deepseek-ai/deepseek-r1-7b \ --served-model-name deepseek-r1 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9这里解释一下关键参数。--served-model-name是暴露给调用方的模型名可以随意起但要与客户端配置保持一致。--tensor-parallel-size在多卡环境下设为显卡数量单卡保持 1--max-model-len控制上下文长度24GB 显存下 8192 比较稳妥设到 16384 也不是不行但并发能力会下降--gpu-memory-utilization告诉 vLLM 最多吃满多少比例的显存留一点余量给 CUDA 上下文和其他进程0.9 是个稳妥值。启动后日志里会出现Uvicorn running on http://0.0.0.0:8000说明服务已经就绪。vLLM 同时会输出一段配置摘要包括模型加载时间、显存分配和最大并发数值得仔细看一眼后面排查性能瓶颈全靠它。4.2 核心参数间的关系并发、吞吐与显存vLLM 的并发能力并不由某个参数直接决定而是由max-model-len、gpu-memory-utilization和推理时的请求长度共同决定。PagedAttention 会把 KV Cache 分页存放请求来了就分配页面走了就释放所以显存利用率高但并不是无上限。为了摸清服务的真实吞吐我一般用一段脚本压测import json import time from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) payload { model: deepseek-r1, messages: [{role: user, content: 模拟一段 500 字的数据库设计说明}], max_tokens: 1024, temperature: 0.6 } start time.time() resp client.chat.completions.create(**payload) elapsed time.time() - start output_tokens resp.usage.completion_tokens print(f耗时 {elapsed:.2f}s生成 {output_tokens} tokens吞吐 {output_tokens / elapsed:.2f} tokens/s)这段脚本用 OpenAI Python SDK 发请求关键是确认base_url指向 vLLM 服务的/v1路径api_key随便填一个非空字符串即可。如果吞吐数字明显偏低检查三点模型是否真的在跑 GPU 推理nvidia-smi看功耗max-model-len是否设得过大导致 KV Cache 预留过多并发请求是否超过了服务能承受的极限。想要提高并发上限有两个方向。一是调低--max-model-len因为 KV Cache 是预分配的窗口越小能同时服务的请求越多二是打开 vLLM 的自动分页特性它在较新版本里默认开启无需额外参数但日志里的Maximum concurrency数字会告诉你当前配置的上限。4.3 对接 Codex、VSCode 与 Dify 工具链vLLM 暴露的是 OpenAI 兼容接口所以任何支持自定义base_url的工具都可以直接接入。最典型的是 VSCode 里的 Continue 插件和 Cline 插件只需要在配置里改两行。以 Continue 为例在config.json里添加{ models: [ { title: DeepSeek-Local, provider: openai, model: deepseek-r1, apiBase: http://localhost:8000/v1, apiKey: EMPTY } ] }apiBase指向 vLLM 或 Ollama 的地址model必须与服务端--served-model-name保持一致。Codex 的命令行接入更简单设置环境变量OPENAI_BASE_URLhttp://localhost:8000/v1作为基础地址后就可以把本地模型当作后端使用。Dify 这类 RAG 平台则是在「模型供应商」里添加 OpenAI-API-compatible 类型填入同样的地址、模型名和密钥推荐在 Dify 侧把「上下文长度」设为与 vLLM 的max-model-len一致否则 Dify 会自动截断超出部分造成对话历史丢失。接入后如果对话出现乱码或空响应通常是 Dify 与模型之间的max_tokens设置不一致导致的截断把它调到 512-1024 即可。还有一点容易被忽略这些工具默认会带很长的 system prompt加上多轮历史token 消耗比单测时快得多对接前先把 QPS 和 token 配额想清楚。5. 上线前必做的三项优化上下文窗口、并发队列与显存碎片5.1 用max-models与上下文窗口管理对话长度Ollama 和 vLLM 对超长上下文的报错方式不同但成因一样前端应用不断追加历史消息最终超过了模型的num_ctx或max-model-len。Ollama 会直接报request entity too largevLLM 则返回400 maximum context length。这些都属于预期内的错误不要盲目调大窗口更务实的做法是做消息裁剪。在应用层加一个 token 估算函数超出阈值时丢弃最旧的消息def trim_messages(messages, max_tokens6000, modeldeepseek): # 简化估算中英文字符平均约 0.6 token/字 total sum(len(m[content]) * 0.6 for m in messages) while total max_tokens and len(messages) 1: messages.pop(0) # 丢弃最早的消息保留系统提示 total sum(len(m[content]) * 0.6 for m in messages) return messages这个函数按内容长度估算 token 数超出阈值就移除最早的非系统消息。核心思路是保证请求永远不会超过模型上下文上限比纯靠模型报错后重试优雅得多。对 DeepSeek 这类中文友好的模型字符数乘 0.6 的估算误差在 10% 以内够用。5.2 并发队列与超时控制Ollama 默认串行处理请求vLLM 内部有调度器但外层应用仍需做排队。我见过最典型的失败案例是前端一次性发 10 个请求Ollama 全部带上前几个生成完后几个直接 GPU OOM。解决办法是在网关层控制并发数用简单的信号量或消息队列# 使用 Nginx 做反向代理限制到后端的并发连接数 upstream deepseek_backend { server 127.0.0.1:8000; keepalive 16; } limit_conn_zone $binary_remote_addr zonellm_conn:10m; server { listen 80; location / { limit_conn llm_conn 2; # 每个 IP 最多 2 个并发 proxy_pass http://deepseek_backend; proxy_read_timeout 300s; # 生成任务可能超过 2 分钟 } }limit_conn强行限制同一来源的并发连接数proxy_read_timeout设到 300 秒以上否则长文本生成到一半会被 Nginx 掐断。这里的逻辑是宁可让请求排队也不能让两个长任务同时挤爆显存。vLLM 场景下这个限制可以放宽一些因为它本身具备连续批处理能力但依然建议保留外层的超时兜底防止客户端挂死。5.3 释放显存碎片与冷热模型切换的实践经验长跑推理服务最常见的隐性故障是显存碎片化。vLLM 内部的 PagedAttention 已经很大程度缓解了碎片问题但 Ollama 频繁加载/卸载不同模型后显存容易出现「可用显存充足但分配失败」的情况。遇到这种问题重启进程通常能解决但更重要的是避免频繁切换模型。Ollama 提供了环境变量来控制模型驻留策略# 始终保留模型在显存中不自动卸载 OLLAMA_KEEP_ALIVE30m # 限制同时加载的模型数量 OLLAMA_MAX_LOADED_MODELS1OLLAMA_KEEP_ALIVE30m表示模型在 30 分钟内无请求也不卸载避免多个模型来回加载造成的显存颠簸。OLLAMA_MAX_LOADED_MODELS1则保证同一时间只有一个模型占显存适合单模型长时间运行的场景。对于 vLLM建议直接给容器设置固定的--gpu-memory-utilization不要不停手调参数vLLM 的显存管理在初始化时就已划好运行时改参数只会增加风险。最后提一个冷门但实用的验证方法部署完成后用watch -n 1 nvidia-smi观察显存使用的稳定性。如果显存使用是一条平滑直线说明服务健康如果呈现锯齿状波峰波谷说明 KV Cache 频繁分配释放需要检查并发是否过猛。真正的生产运维不是靠肉眼观察而是把指标接入 Prometheus 这类监控系统但本地部署阶段nvidia-smi加日志里的吞吐数字足够你判断当前配置是否合理。本文还有配套的精品资源点击获取