简介这份DeepSeek入门与应用指南面向对AI、NLP和推理模型感兴趣的研发工程师与技术爱好者系统讲解开源推理模型DeepSeek-R1的核心能力、技术定位与实际应用场景。资源包含1个PDF文档压缩包大小4.83MB内容按“是什么—能做什么—如何使用”层层展开结构清晰适合随时查阅与按需定位。文档深入梳理了智能对话、文本生成、语义理解、知识推理、代码生成补全等用法并对比推理模型与非推理模型的特点引入链式思维CoT、快慢思考等概念帮助读者理解任务类型与模型选择的匹配逻辑。同时提供了提示语设计策略与常见误区规避方法覆盖数学证明、创意写作、代码生成等任务示例能有效提升数据处理效率与交互质量。目前已有590人学习/下载适合作为模型应用与研究学习的实用参考资料。1. DeepSeek不是又一个“大号ChatGPT”开源权重才是通用人工智能的入场券把DeepSeek叫成“清华DeepSeek”开发圈里基本默认知道指的是什么一群敢把技术细节掰开揉碎讲出来的研究者做的通用人工智能开源项目。我第一次用DeepSeek-R1时最意外的不是数学能力而是它会把自己的完整推理过程先打出来再给结论——这在开源模型里是头一回。反直觉的结论是大部分人不需要部署671B满血版一台16G显存的消费级显卡跑7B或14B蒸馏版已经能在代码生成、文档处理、数据分析里干活。这篇文章不打算复述新闻稿只讲两件事怎么在自己机器上把DeepSeek跑起来以及怎么把它接进Codex、VSCode、API调用这些日常开发流。2. 本地部署DeepSeek先算显存账从R1蒸馏模型到671B MoE的硬件选型2.1 分清模型家族V3、R1、Coder和蒸馏版别被版本号绕晕DeepSeek在GitHub上放出的开源项目不止一个术语又时时更新很多人在第一步就卡在“该下哪个模型”。我按实际用途把模型家族分成四条线。第一条线是DeepSeek-V3通用对话与代码主力采用MoE混合专家架构总参数量671B但每次推理只激活约37B参数。它适合绝大多数日常问答、写作、代码生成任务。第二条线是DeepSeek-R1专门针对推理强化过的模型用GRPO这类强化学习算法训练回答复杂数学题、逻辑题时会把思考过程完整输出这是它区别于一众闭源模型的最大特征。第三条线是R1蒸馏系列也就是官方把R1的能力蒸馏到Qwen、Llama等小模型上得到的版本参数量从7B到70B都有这是本地部署性价比最高的选择。第四条线是DeepSeek-Coder-V2老一代代码专用模型现在很多场景已被V3覆盖但16B的Lite版在低显存设备上依然能打。对于本地部署我的建议非常直接想体验推理能力就选R1蒸馏版想稳定的通用对话就选V3蒸馏版或Coder-V2-Lite。别一上来盯着671B的满血版除非你有四张A100或八张H20闲置。模型参数量架构本地部署可行度适合干什么DeepSeek-V3671B MoE激活37BMoE MLA基本不可行走API通用对话、代码、写作DeepSeek-R1671B MoEMoE RL推理基本不可行走API数学、逻辑、复杂分析R1-Distill-Qwen-7B/14B/32B7B/14B/32B Dense稠密Transformer消费级显卡可跑本地推理、隐私场景R1-Distill-Llama-70B70B Dense稠密Transformer需多卡或大显存高精度推理、离线批处理DeepSeek-Coder-V2-Lite16B MoE激活2.4BMoE8G显存可跑代码补全、轻量编程2.2 量化档位与显存估算Q4、Q8、AWQ怎么选才不翻车模型下载下来通常是FP16或BF16的safetensors格式直接加载显存占用是参数量乘以2字节。14B模型就要约28GB30系列显卡基本没戏。所以本地部署绕不开量化也就是把权重从16位压到8位、4位用精度换显存。量化格式常见三种。GGUF的Q4_K_M和Q8_0适合Ollama、llama.cpp这类CPU/GPU混合推理工具AWQ和GPTQ适合vLLM这类GPU推理框架推理速度更快。选档位的经验是7B模型直接上Q816G显存完全没问题14B模型Q8大约占16GB权重显存刚好卡在消费级显卡边缘建议优先Q4_K_M或AWQ-4bit32B以上模型本地跑只能Q4显存需求量约20GB起70B想本地跑Q4也要40GB权重显存基本告别单卡。估算显存有个粗公式权重显存 ≈ 参数量GB× 量化位数 / 8 × 1.2。1.2倍是给KV cache和框架开销留的余量。比如14B模型Q414 × 4 / 8 × 1.2 ≈ 8.4GB一张8G显卡勉强能跑16G显卡舒服很多。这里特别提醒MoE模型的量化亏损比Dense模型小因为每次只激活一小部分专家但R1蒸馏系列是Dense模型Q4之后数学能力会肉眼可见地下降能上Q8就上Q8。2.3 推理框架选型Ollama、vLLM、llama.cpp和SGLang的边界框架选择直接影响你后面踩坑的深度。我按使用场景分类说明不罗列全部功能。Ollama是最省事的方案适合个人测试和局域网内小范围使用。它把模型打包成GGUF格式一条命令下载、一条命令启动几分钟就能跑起来。代价是参数暴露少显存管理不精细并发一高就明显变慢。vLLM是生产环境的默认选择。它实现了PagedAttention、连续批处理、前缀缓存官方还开源了OpenAI兼容接口你本地起的服务可以被任何能调OpenAI接口的客户端直接使用。我自己的实践是只要是打算长期跑、多人用的服务一律用vLLM它比Ollama稳定一个量级。SGLang是DeepSeek社区里被提及最多的框架对DeepSeek的MLA注意力机制做了专门优化长上下文场景吞吐更高适合已经跑过vLLM、想再压性能的进阶用户。llama.cpp则是兜底方案纯CPU也能跑把内存当显存用。没有NVIDIA显卡的机器可以用它跑7B Q4模型速度大约每秒几个token做离线批量任务完全够用。框架格式对DeepSeek适配适合场景不适合场景OllamaGGUF简单粗暴个人测试、快速体验高并发、精细控制vLLMsafetensors/AWQ好OpenAI兼容生产部署、多人服务显存小于8G的设备SGLangsafetensors官方社区推荐长上下文、高吞吐需要快速上手的人llama.cppGGUF可用CPU机器、低显存兜底追求速度的场景选型时记住一句话显存决定你能跑什么框架决定你跑得顺不顺。显存不够再好的框架也白搭。3. 用Ollama和vLLM跑通DeepSeek本地推理最小命令与三个关键参数3.1 Ollama三分钟部署pull、run和上下文窗口调整Ollama的部署流程没什么可讲的花活三步装Ollama拉模型跑模型。但“能跑起来”和“能正常干活”之间隔着一个关键参数上下文窗口长度。先看最小命令ollama pull deepseek-r1:14b ollama run deepseek-r1:14bollama pull从模型仓库拉取的是已量化打包的GGUF文件14B版本对应Q4量化。ollama run会进入交互式对话界面直接回车提问就能用。如果只想验证模型能不能出结果把对话界面的第一条消息发出去就够。问题在于Ollama默认的num_ctx也就是上下文窗口通常只有4096甚至2048。DeepSeek-R1这类推理模型的特点是生成回答前会先输出大段思考过程一个稍复杂的问题动辄三四千token默认窗口根本装不下结果就是回答到一半突然断掉。解决办法是启动服务时用环境变量把上下文拉长OLLAMA_HOST0.0.0.0:11434 OLLAMA_CONTEXT_LENGTH8192 OLLAMA_KEEP_ALIVE30m ollama serve三个参数分别解释OLLAMA_HOST0.0.0.0:11434让局域网内其他机器也能访问这个服务适合放在一台服务器上给团队共用OLLAMA_CONTEXT_LENGTH8192把上下文窗口提到8KR1这类推理模型建议至少这个值有条件直接上16384OLLAMA_KEEP_ALIVE30m控制模型在显存里的驻留时间设为0则每次请求完都卸载模型省显存但响应变慢30m是个人使用比较均衡的值。如果你已经在交互界面里跑起来了也可以在对话中输入/set parameter num_ctx 8192临时调整。但我更推荐用环境变量统一管理因为一劳永逸不会出现换个终端进去又回到默认值的情况。3.2 用vLLM跑生产级部署gpu-memory-utilization与max-model-len怎么调Ollama解决的是“能跑”vLLM解决的是“跑得稳、跑得快”。同样是14B的R1蒸馏模型Ollama单并发可能响应还可以一旦多人同时用vLLM的优势就体现出来了。先装依赖和下载模型。国内网络环境从HuggingFace拉模型经常失败我一般用ModelScopepip install vllm0.6 pip install modelscope modelscope download --model deepseek-ai/DeepSeek-R1-Distill-Qwen-14B --local_dir ./deepseek-r1-14bmodelscope download会把模型权重完整拉到本地目录--local_dir指定存放路径。下载完成后用本地路径启动vLLM服务比让vLLM临时去远程拉文件可靠得多vllm serve ./deepseek-r1-14b \ --served-model-name deepseek-r1-14b \ --tensor-parallel-size 1 \ --max-model-len 16384 \ --gpu-memory-utilization 0.90 \ --enable-prefix-caching逐项说明参数。--served-model-name是服务对外暴露的模型名调用接口时要填这个名字取什么无所谓跟客户端约好就行。--tensor-parallel-size表示张量并行度单卡填1多卡按卡数填它会自动把模型切分到多张显卡上。--max-model-len是最长上下文长度这个值越大KV cache预留的显存越多14B模型在24G显卡上可以撑到16384甚至32768但8G显卡建议老老实实设8192。--gpu-memory-utilization 0.90是我每次都要强调的参数。它表示vLLM最多占用90%显存剩下10%留给驱动、显示进程和其他任务。很多人不设这个参数vLLM会把空闲显存全吃光等你再想跑第二个模型或起别的服务直接OOM。--enable-prefix-caching开启前缀缓存多轮对话或批量请求共享相同前缀时计算量能省一半以上强烈建议打开。启动成功的标志是日志里出现Uvicorn running on http://0.0.0.0:8000默认端口8000后面冒烟测试就用这个地址。3.3 冒烟测试本地服务用curl验证OpenAI兼容接口服务起来后第一步不是急着写代码而是用curl发一条最简单的请求验证链路curl -s http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1-14b, messages: [{role: user, content: 列出1到100之间的所有质数}], max_tokens: 2048, temperature: 0.6 } | python3 -m json.tool这条命令做了三件事向vLLM的OpenAI兼容接口发起对话请求指定模型名是启动服务时取的deepseek-r1-14b然后用python3 -m json.tool把返回的JSON格式化显示。返回结构里重点看choices[0].message.content字段。这里有个容易误判的点本地跑的R1蒸馏模型返回的content字段里会直接包含大段“好的我需要先分析质数的定义……”这类思考过程然后才是最终答案。这不是故障蒸馏版不像API版那样把思考过程单独放在reasoning_content字段里两者是合并输出的。所以看到一大串推理文字别慌拉到末尾看最终答案对不对就行。如果返回的是404或model not found优先检查两处--served-model-name设的名字和请求体里model字段是否一致请求路径是不是/v1/chat/completions。如果curl直接超时回头看vLLM启动日志大概率是显存不足导致模型加载失败。4. 接入DeepSeek API与开发工具链Codex、VSCode和直调接口的配置细节4.1 调用DeepSeek官方APIbase_url、模型名与reasoning_content很多人的需求是既不想买昂贵的显卡又不想用本地小模型应付复杂任务那官方API就是最平滑的入口。DeepSeek API兼容OpenAI的接口格式这意味着你不需要引入新的SDK直接用OpenAI的Python包改一个base_url就能跑。先看最小调用示例export DEEPSEEK_API_KEYsk-你的key curl -s https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -d { model: deepseek-chat, messages: [ {role: system, content: 你是嵌入式C语言专家回答要简洁直接。}, {role: user, content: 解释HAL库中DMA中断回调的常见坑} ], temperature: 0.6, stream: false }两个模型名要记牢deepseek-chat对应通用模型适合日常对话和代码生成deepseek-reasoner对应推理增强模型适合数学、逻辑、复杂分析。用途上日常开发我用deepseek-chat需要推导算法或排查复杂问题时切到deepseek-reasoner。Python端用OpenAI SDK接入的写法更简洁from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-reasoner, messages[{role: user, content: 用动态规划求最长递增子序列}], temperature0.6, max_tokens4096, ) reasoning getattr(resp.choices[0].message, reasoning_content, None) print(思考过程, reasoning) print(最终答案, resp.choices[0].message.content)关键差异在reasoning_content字段。官方API的deepseek-reasoner会把思考过程单独放在这个字段里content只放最终答案。注意用getattr加默认值因为deepseek-chat的返回里没有这个字段直接访问会报错。另外max_tokens要舍得给推理模型的思考过程可能长达两三千token设小了答案会被截断。4.2 Codex接入DeepSeekconfig.toml配置与Agent行为适配Codex是OpenAI出的命令行编程Agent现在支持配置第三方模型提供商。把DeepSeek接进Codex后你就有了一个跑在终端里的免费编程助手它能在你的仓库里读写文件、执行命令、提交代码。这是目前把DeepSeek融入开发流性价比最高的方式。配置文件在~/.codex/config.toml内容如下model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chatmodel指定默认模型我填的是deepseek-chat因为Codex这类Agent任务需要频繁工具调用推理模型的思考过程会消耗大量token却没有额外收益。base_url填https://api.deepseek.com/v1这里必须带/v1因为Codex会在base_url后面拼/chat/completions不带会404。env_key告诉Codex从环境变量里读API key启动前执行export DEEPSEEK_API_KEYsk-xxx。配置完成后在项目目录里运行codex就能开始对话。但有一点必须调整预期Codex默认是针对特定模型调教过的换成DeepSeek后它的任务拆解能力和工具调用步数会弱一些。我的做法是在会话开始时先给一句约束比如“先列出改动方案再动手改每次只改一个文件”能明显减少它改到一半迷路的情况。这个现象跟模型无关是Agent本身的设计差异造成的熟悉之后反而觉得DeepSeek的方案更直白、更容易审查。4.3 Cline与Continue在VSCode里接本地或云端DeepSeek除了命令行AgentVSCode里的AI插件同样可以接DeepSeek。我用得最多的是Cline和Continue两个插件都支持OpenAI兼容接口区别在于Cline更偏Agent式操作能自己改文件Continue更偏对话式补全。Cline的配置没有YAML文件可改全部在UI里完成打开Cline设置需要配置的字段是这几个——API Provider选“OpenAI Compatible”Base URL填你的服务地址Model ID填模型名API Key填密钥。API Provider: OpenAI Compatible Base URL: http://localhost:8000/v1 API Key: sk-any (本地vLLM不校验随便填) Model ID: deepseek-r1-14b注意如果接的是本地vLLM服务API Key随便填一个非空字符串就行因为本地服务的鉴权通常是关闭的。但这也意味着局域网内任何人都能调用你的服务生产环境一定要加反向代理或防火墙别把端口直接暴露到公网。如果你想同时保留本地和云端两个入口Continue的配置更灵活改~/.continue/config.json{ models: [ { title: DeepSeek Local 14B, provider: openai, model: deepseek-r1-14b, apiBase: http://localhost:8000/v1 }, { title: DeepSeek Cloud, provider: openai, model: deepseek-chat, apiBase: https://api.deepseek.com/v1, apiKey: sk-你的key } ] }配好后在插件面板里一键切换模型本地跑量大的任务云端跑需要满血R1的复杂推理互补使用。4.4 API还是本地价格、延迟和隐私的取舍这是个绕不开的问题。我的结论是API和本地部署不是二选一而是按任务分配。API的优势是满血模型能力、零维护成本、按量付费不用管显存。DeepSeek官方的定价比闭源大厂低一个数量级我日常高频使用一个月也就几十块钱比电费还便宜。缺点是数据要经过第三方服务敏感代码和内部文档不适合直接丢进去。本地部署的优势是数据完全不出内网、延迟低、没有按量费用一次性投入硬件钱就能无限用。缺点是模型版本落后于官方API14B蒸馏版的能力和671B满血版有差距复杂任务还是得切回云端。我的分配习惯是这样日常代码补全、格式化、简单问答走本地14B需要深度推理、长文分析、代码审查走云端deepseek-reasoner涉及客户数据或未公开项目的代码只走本地。这个组合既控制成本又不牺牲能力普通开发者的显卡预算也能轻松承担。维度官方API本地部署模型能力满血671B最强蒸馏版7B-70B有差距数据隐私依赖服务商完全本地单次成本按token计费仅电费但硬件已投入维护成本零显存、版本、并发都要管适合场景复杂推理、临时任务持续使用、隐私数据、离线5. 本地部署与微调DeepSeek的5个避坑记录从输出截断到显存溢出5.1 三种部署常见的显存与速度问题现象一Ollama跑R1模型回答到一半突然停住只留下“嗯……让我再想想”之类的半截话没有最终答案。原因是上下文窗口太小。R1系列推理模型在生成最终答案前会输出大量思考过程默认的4096窗口很容易被思考过程占满模型没有剩余空间生成答案只能中断。解决方法是把上下文窗口拉到8192以上。Ollama在启动服务时设置OLLAMA_CONTEXT_LENGTH16384vLLM在启动参数里设置--max-model-len 16384。这不是模型坏了是窗口不够大。现象二vLLM启动时报CUDA out of memory但nvidia-smi看显存明明还有空闲。原因通常是两个一是你给vLLM设了过高的--gpu-memory-utilization它会把显存里的空闲部分都预留给自己其他进程就申请不到二是上一次运行的服务没有完全退出显存还残留着旧进程nvidia-smi里能看到多个进程占着显存。解决方法是把gpu-memory-utilization降到0.85以下启动前用nvidia-smi检查残留进程必要时kill -9掉僵尸进程。另外如果启用了OLLAMA_KEEP_ALIVE且值很大Ollama的模型会一直驻留显存再启动vLLM自然就会撞车。现象三多轮对话后响应速度越来越慢最后直接卡死无响应。原因是KV cache随着对话轮次持续增长上下文越长每生成一个token的耗时越长。当上下文长度逼近max-model-len时计算量陡增服务看起来就像死了一样。解决思路有两个方向程序端做历史裁剪超过一定轮数就把更早的对话压缩成摘要塞回system prompt而不是全部保留服务端开启前缀缓存vLLM的--enable-prefix-caching让重复前缀不再重复计算。这两个方法配合使用长对话的体验会好很多。5.2 两个微调与接口兼容性问题现象四用OpenAI SDK调DeepSeek API报404或路径不存在。原因是base_url填错了。DeepSeek兼容OpenAI接口但base_url不是所有SDK都能直接识别。OpenAI官方的Python SDK接收的base_url应该填https://api.deepseek.comSDK会自动拼上/chat/completions。而很多Agent工具如Codex、Cline不会自动拼路径所以填https://api.deepseek.com/v1。判断标准很简单看工具本身会不会追加/v1或/chat/completions会就填不带路径的裸域名不会就填/v1版本。这个错误极其常见我在两个不同工具上各踩过一次。现象五用常规SFT数据集微调R1蒸馏模型loss能降但生成质量反而变差回复变得模板化、冗长、逻辑混乱。原因要从R1的训练方式说起。R1是经过强化学习训练的推理模型回答带有强烈的思考前缀和长推理风格。普通SFT数据集的格式、长度、分布和它原生分布差异太大微调会把模型带偏学到一堆新模板却破坏了原有的推理能力。解决方法是微调推理模型时优先选DPO或GRPO这类偏好优化方法而不是SFT如果非要用SFT数据必须包含完整的思考过程和最终答案两部分且格式要和原始训练保持一致。另一个更省事的方案是直接微调通用模型V3或Coder而不是在推理模型上做文章。提示R1蒸馏模型开箱即可用不要一上来就想着微调。绝大多数场景调prompt比微调有效得多也便宜得多。6. 推理参数调优与输出清理把同一套DeepSeek发挥出两倍效果6.1 temperature、top_p和max_tokens的搭配代码任务把temperature设在0.2到0.5之间DeepSeek这类模型在低温下代码更稳创意写作可以拉到0.8但要接受偶尔的胡编。deepseek-reasoner是个例外官方建议0.6别高于这个值否则强化学习学到的稳定推理节奏会被采样随机性打乱。6.2 清理reasoning输出只留最终答案本地蒸馏版把思考过程和答案混在同一个content里拿到结果后需要做一次清洗import re def extract_final_answer(text: str) - str: # 优先匹配老版本常见的结构化结尾 patterns [ r最终答案[:]\s*(.*?)$, rfinal_answer(.*?)/final_answer, ] for pattern in patterns: m re.search(pattern, text, re.S) if m: return m.group(1).strip() # 兜底去掉开头所有思考段取最后一个换行后的内容 lines text.strip().split(\n) for line in reversed(lines): if len(line.strip()) 10: return line.strip() return text.strip()extract_final_answer先尝试匹配“最终答案”和final_answer这类显式边界匹配不到就取最后一行有意义的内容。有次我把这个函数加进自动化流水线后原本要人工删一大段思考记录的活直接省了这也是我调整参数之外最满意的一个小改动。我现在的习惯是无论是本地还是云端统一在代码层做一次输出清洗再进下游系统。这个习惯帮我避开了很多次“模型答对了但程序读不懂”的尴尬也希望帮到你。本文还有配套的精品资源点击获取
