简介《DeepSeek从入门到精通》由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室团队编写以DeepSeek-R1开源推理模型为主线面向对自然语言处理、机器学习及开源AI工具感兴趣的研发工程师和技术爱好者。资料首先介绍DeepSeek是什么、能做什么覆盖智能对话、文本生成、语义理解、代码生成与补全、知识推理等典型场景随后重点对比推理模型与非推理模型在优势领域、决策能力、人机互动等方面的差异并给出数学证明、创意写作、代码生成等任务下的模型选择建议。提示语设计部分则从指令驱动、需求导向、混合模式到启发式提问逐层展开配合具体示例和误区提醒帮助读者根据任务类型快速调整提问策略避免常见使用陷阱。文档仅含1个PDF文件大小4.83MB内容结构清晰适合作为大模型应用研究、学术探索及日常开发的随身参考。已有590人学习下载对希望系统掌握DeepSeek使用技巧与开源大模型选型逻辑的人群具有不错的参考价值。1. DeepSeek 是什么一个能让中小团队绕开“闭源 API 高价”的通用 AI 开源选择DeepSeek 是深度求索公司开源的大模型系列也是这两年我最愿意推荐给工程团队试用的“通用 AI 开源项目”。因核心团队有大量成员来自清华技术圈习惯把它归到“清华系”。它最打动我的不是榜单分数而是把“能力通用”和“开源可用”同时做成了现实。对做产品的团队来说DeepSeek 意味着一条比“闭源 API”更便宜、比“从头训模型”更现实的路线先调用官方 API 快速验证再按业务量决定要不要本地部署蒸馏模型。代码、数学、写作、问答一个模型基本都接得住接入成本却低一个量级。这篇文章从架构原理讲到 API 接入、本地部署和常见坑位全程按一线落地视角写。看完你就能在自己的项目里把 DeepSeek 用起来而不是让它躺在收藏夹里。2. 把 DeepSeek 的底账算清MoE、推理链与开源许可能撑起多大场景2.1 671B 总参数只激活 37BMoE 和 MLA 到底省了什么传统 Dense 模型处理每个 token 时所有参数都要参与计算所以参数量越大单次推理成本越高。DeepSeek-V3 走的是 MoE混合专家路线整个模型有 671B 总参数但处理一个 token 时只激活其中约 37B 参数的专家子网络。你可以理解为“一个超大的团队每次只叫擅长的那个人上场”。这正是它能把推理价格压下来的核心原因。工程上这带来一个容易误判的点激活参数决定单次推理的算力成本总参数决定部署时的显存成本。671B 的权重文件在 FP8 精度下也要六百多 GB本地基本得靠多机集群但因为激活参数只有 37B官方 API 端的单 token 推理成本就能做到很低。所以“671B”这个数字吓退了不少人实际上你选型时应该分开看——用 API 还是自部署账完全不同。MLAMulti-head Latent Attention是另一个被低估的设计。它把 KV 缓存压缩成低维潜在向量长上下文场景下的显存占用和带宽消耗大幅下降。做工程的人都知道长上下文推理最先爆掉的就是 KV cacheMLA 就是冲着这个痛点去的。所以 DeepSeek API 能支撑大段文档处理不用像以前那样每加一轮对话就担心显存翻倍。2.2 R1 的推理链不是“提示词技巧”是强化学习练出来的很久以前我们用大模型做推理题得靠提示词教它“请一步步思考”。DeepSeek-R1 把这条路径彻底改写了模型内部自带推理链而且这个能力不是靠人工写提示词调出来的是用强化学习练出来的。它在训练时引入 GRPO 这类策略优化方法配合规则奖励——数学题答案对就是对、代码跑通就是跑通不用人工标注偏好模型在试错中自己学会了“先想清楚再回答”。和传统 RLHF 相比R1 的路线对可自动验证的任务更友好也便宜得多。这对工程落地的直接意义是复杂逻辑任务不用再靠 prompt 工程硬撑模型本身具备深度思考能力。更关键的是官方把 R1 的推理能力蒸馏到了 1.5B、7B、14B、32B、70B 这些小模型上让消费级显卡也能跑出不错的推理效果。本地部署 DeepSeek 成为现实靠的就是这一手。2.3 开源协议不等于随便用商用、分发与用户规模边界很多人一听到“开源”就默认可以随便用但在 DeepSeek 这里要分清权重开放不等于无限制。它的许可协议允许商业使用也允许基于模型做修改和再分发这对大多数中小团队已经完全够用但有几个边界条款需要留意——不能用于军事等敏感场景不能利用模型能力去伤害他人如果你的产品月活用户规模达到亿级需要向官方申请专项授权。实操层面我的建议是做私有化部署、接入自己的产品、二次开发后内部使用这些都没问题但如果你要做开放平台把 DeepSeek 作为底层服务开放给第三方调用就要仔细核对协议里对“再分发”和“多用户服务”的约定。另外“开源”在中文语境里常和 OSI 定义的 Open Source 混为一谈DeepSeek 的模型权重和代码仓库是开放的但许可证更像自定义协议别拿 Apache 2.0 的宽松标准去套。3. API 接入 DeepSeek从 curl 验证到企业微信群机器人的最小闭环3.1 先做连通性验证OpenAI 兼容接口的第一条 curl 命令DeepSeek API 的接口设计与 OpenAI 兼容这省去了大量适配成本。现有的 OpenAI SDK、LangChain、Dify、FastGPT 这类工具只需要改 base_url 和 api_key 就能切过来。官方平台注册后拿到 API Key把它写进环境变量先用一条 curl 命令验证连通性export DEEPSEEK_API_KEYsk-xxxxxxxx curl 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: 你是一名严谨的技术回答者。}, {role: user, content: 用一句话解释什么是 MoE 模型。} ], stream: false }model字段有两个常用值deepseek-chat对应通用对话模型适合写作、代码生成、知识问答deepseek-reasoner对应带推理链的模型适合数学、逻辑、复杂 Debug。messages数组按对话顺序排列system 角色负责设定行为边界。stream建议在调试阶段设为 false返回完整 JSON 方便看结构生产环境再改成 true 做流式输出。3.2 Python 封装多轮对话messages、temperature、stream 三个关键点验证连通性之后就该用代码封装了。我的习惯是直接用 OpenAI 官方 Python SDK把 base_url 指到 DeepSeek 即可import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) messages [ {role: system, content: 你是一名熟悉 Spring Cloud 微服务架构的技术顾问。}, {role: user, content: 服务间调用经常超时应该从哪几个方向排查}, {role: assistant, content: 建议先看三处网络连通性、服务线程池、调用超时配置。}, {role: user, content: 那怎么确认线程池是不是瓶颈} ] resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.6, max_tokens2048, streamFalse, ) print(resp.choices[0].message.content)这里三个参数要单独说。temperature0.6是代码和结构化任务比较稳的中间值偏低会让输出趋于保守适合写 SQL、生成配置偏高到 0.9 以上适合文案创意但代码类任务容易跑偏。max_tokens控制单次回复的最大长度不设的话一些长文档任务可能中途截断但设太小又会让复杂回答不完整。streamFalse适合调试和低成本场景生产环境建议开流式用户看到 token 一个个蹦出来心理等待时间能缩短一大半而且不会触发网关超时。3.3 落地到企业微信群机器人一个自动问答链路的完整骨架接入企业微信是团队内部落地最常见的需求但很多文章只讲了群机器人 webhook 单向推送。实际上企业微信群机器人的 webhook 只能往外发消息收不到成员提问。要做双向问答得用企业微信自建应用的消息回调。核心骨架长这样from flask import Flask, request import hashlib import time import requests app Flask(__name__) TOKEN your_corp_token # 自建应用回调配置里的 Token CORP_ID your_corp_id SECRET your_app_secret AGENT_ID 1000002 # 自建应用 AgentId def verify_signature(msg_signature, timestamp, nonce, echostr): s sorted([TOKEN, timestamp, nonce, echostr]) calc hashlib.sha1(.join(s).encode(utf-8)).hexdigest() return calc msg_signature def get_access_token(): url fhttps://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid{CORP_ID}corpsecret{SECRET} return requests.get(url).json()[access_token] def ask_deepseek(content): resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: content}], temperature0.7, max_tokens1024, ) return resp.choices[0].message.content app.route(/wecom/callback, methods[GET, POST]) def callback(): if request.method GET: params request.args if verify_signature(params[msg_signature], params[timestamp], params[nonce], params[echostr]): return params[echostr] return verify fail, 403 xml_body request.data.decode(utf-8) import xml.etree.ElementTree as ET root ET.fromstring(xml_body) from_user root.findtext(FromUserName) content root.findtext(Content) reply ask_deepseek(content) access_token get_access_token() requests.post( fhttps://qyapi.weixin.qq.com/cgi-bin/message/send?access_token{access_token}, json{ touser: from_user, msgtype: text, agentid: AGENT_ID, text: {content: reply}, } ) return success回调 URL 必须是一个公网可达的 HTTPS 端点msg_signature的 SHA1 校验只验证了请求来源生产环境还需要用官方 SDK 做 AES 解密因为企业微信默认对消息体加密。get_access_token返回的 token 有效期两小时生产要缓存复用否则每个请求都去拉一次 token 很容易触发接口限流。这一步跑通之后DeepSeek 就真正嵌入了团队的日常协作而不是只停留在 API 调试阶段。4. 本地部署 DeepSeek先算显存账再定 Ollama 还是 vLLM4.1 显存账怎么算蒸馏模型每一档分别要什么卡本地部署 DeepSeek第一个问题不是装什么框架而是你的显卡能背动多大的模型。显存占用可以粗算半精度 FP16 权重约占 2 字节/参数INT8 约 1 字节4bit 量化约 0.5 字节。再叠加 KV cache 和框架开销实际需要在这个基础上加 20%-30%。蒸馏模型各档位的现实需求如下模型档位FP16 权重占用4bit 量化后推荐硬件1.5B约 3GB约 1GB8GB 显卡可跑7B约 14GB约 4-5GB8GB-16GB 显卡14B约 28GB约 9-10GB16GB-24GB 显卡32B约 64GB约 19-22GB48GB 或双卡并联70B约 140GB约 40-45GB多卡服务器这里有个新手常犯的错误只看权重大小忽略了 KV cache。上下文长度设得越大、并发越高KV cache 增长越快。7B 模型 FP16 权重只要 14GB但你要是把上下文开到 32K 且同时处理 8 个请求显存很容易冲破 20GB。所以选显卡时至少留出权重占用 50% 的余量。4.2 一条命令跑通 7BOllama 的场景和参数边界如果你只想在本地体验或者给三五个人用Ollama 是最省事的路径。它对显卡要求低、安装简单模型量化格式现成不需要自己处理推理框架的配置。拉取并运行官方蒸馏版 7B 模型只需要两条命令ollama pull deepseek-r1:7b ollama run deepseek-r1:7b默认上下文只有 2048日常问答够用但要做代码补全或长文本分析就显得局促。可以在启动时设置环境变量也可以在交互界面里用/set parameter调OLLAMA_CONTEXT_LENGTH8192 ollama run deepseek-r1:7b/set parameter num_ctx 8192num_ctx设得越大显存和首 token 延迟都会上升。7B 模型在 16GB 显卡上开 8K 上下文体验还过得去开 32K 就可能需要等待较长时间。Ollama 的边界在于并发能力弱它默认是排队式逐 token 生成适合个人和研究场景到了多人同时用的阶段就得换 vLLM。4.3 vLLM 做服务化7B 模型的并发配置与验证命令生产环境需要并发和吞吐我一般把 vLLM 作为首选。它实现了 PagedAttention 显存管理能把 KV cache 利用率提上去不少。部署 7B 蒸馏模型的常用命令是这样vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --host 0.0.0.0 \ --port 8000 \ --served-model-name deepseek-r1-7b \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --dtype auto \ --enable-prefix-caching--max-model-len 8192是上下文长度上限它直接决定 KV cache 预留多大调小可以给并发腾出显存--gpu-memory-utilization 0.85让 vLLM 只用 85% 显存留出余量给 CUDA 和其他进程拉满容易在启动后触发 OOM--enable-prefix-caching开启共享前缀缓存企业里大量请求带相同的 system prompt这个开关能把重复算力直接省掉。服务起来之后验证两件事一是模型是否加载成功二是推理链路是否通。用 curl 快速确认curl http://localhost:8000/v1/models curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1-7b, messages: [{role: user, content: 用一段话解释 RAG}], max_tokens: 512 }vLLM 暴露的是 OpenAI 兼容接口所以 Codex 这类支持自定义模型地址的工具只要把 base_url 指到http://localhost:8000/v1模型名写成deepseek-r1-7b就能接入。这一步跑通后DeepSeek 才算真正成为团队内部可复用的推理服务。5. DeepSeek 避坑指南五条按“现象→原因→解决”写的实战排查5.1 现象一上下文一长模型开始丢信息还“装懂”连续对话到十几轮之后模型开始遗忘前面给过的关键信息更麻烦的是它不会承认自己忘了而是顺着当前语境编一个看似合理的回答。原因是多数调用方把历史消息全部塞进messages一旦总量超过模型上下文窗口远端就会静默截断最早的内容。解决办法是应用层自己做滑窗裁剪。我的惯例是保留 system prompt 不变只保留最近六轮对话再对总长度做一次字符级兜底def trim_messages(messages, max_rounds6): system [m for m in messages if m[role] system] history [m for m in messages if m[role] ! system] return system history[-max_rounds * 2:]如果业务需要超长上下文不要硬塞进 messages用 RAG 先把相关资料检索出来再拼接。DeepSeek 的长窗口是为了容纳一次性输入的大量文本而不是让你把整本操作手册都丢进去。5.2 现象二deepseek-reasoner 一直“转圈”太多调用deepseek-reasoner时请求长时间不返回日志没有任何报错最终被网关判定超时。原因是推理链模型会在返回正式回答前生成大量可见或不可见的思维链 token一篇复杂推理可能消耗数千 token默认 30 秒的客户端超时根本不够用。官方接口正常响应时间可以从十几秒到两分钟不等。解决方向有三个客户端超时调到 120 秒以上网关层同步调整proxy_read_timeout生产环境开启流式输出让用户看到思考过程在推进而不是干等。我用过的最稳配置是流式 120 秒超时再配合前端“正在分析”的状态提示体感问题基本就消失了。5.3 现象三同一份 prompt 换模型后输出质量断崖下跌在deepseek-chat上跑得好好的提示词切到deepseek-reasoner之后突然变得啰嗦甚至答非所问反过来逻辑题在 chat 模型上又容易出错。原因是两个模型定位完全不同chat 偏向直接回答reasoner 先做推理链它会把简单问题复杂化。不要全局只配一个模型。按任务类型做路由是性价比最高的做法代码生成、文案写作、日常对话走deepseek-chat数学证明、复杂排查、架构设计评审走deepseek-reasoner。我在生产里建议从 task 类型判断模型选择可以封装成一个简单的路由函数把不可控因素限定在提示词里而不是让模型选型变成“看这次运气”。5.4 现象四vLLM 部署后并发一高就 OOMvLLM 刚部署时单请求一切正常并发升到三四个之后进程直接崩掉查看显存发现已经打满。原因是--max-model-len设得过大vLLM 会按最大长度预分配 KV cache并发越高缓存翻倍越快--gpu-memory-utilization拉到 0.95 这种极端值又让框架没有一点缓冲余量。解决思路是压缩单请求显存占用把--max-model-len降到业务真实需要的 4096 或 8192用--gpu-memory-utilization 0.85留出安全垫如果并发仍不够再加--max-num-seqs限制同时处理的序列数宁可排队也不要 OOM。vLLM 的显存是按峰值请求预留的别拿单请求的占用去推算并发上限。5.5 现象五新对话不承接旧对话记忆说丢就丢在网页端聊到对话上限后新建对话继续发消息时模型完全不记得之前聊过什么。很多人的第一反应是模型记忆有问题但本质是产品层面就没有跨会话保存上下文——新会话的 messages 是空的模型当然不知道你之前说过什么。要在应用层自己实现“记忆”机制。我常用的做法是在对话结束时让模型生成一段摘要新对话把它注入 system prompt。那段摘要的有效做法是让模型负责提炼关键结论只把事实和决策浓缩成几行丢掉闲聊细节。实际执行可以顺手写个简单的摘要函数返回一段文本放进新会话的 system 里这样用户下次提问时模型就有了“前情提要”。6. 把 DeepSeek 武装成生产级能力输出评估、推理日志与结构化响应6.1 抓取 reasoning_content把“思考过程”变成可审计日志调用deepseek-reasoner时响应里除了content还有一个reasoning_content字段里面存放模型生成正式回答前的推理过程。很多人直接忽略它其实这是调试和审计的宝藏resp client.chat.completions.create( modeldeepseek-reasoner, messages[{role: user, content: 这段 SQL 为什么走不了索引}], streamFalse, ) answer resp.choices[0].message.content reasoning resp.choices[0].message.reasoning_content print(推理过程, reasoning) print(最终回答, answer)reasoning_content的典型用途有三个排查回答质量问题时判断模型是否走了正确推理路径把它落库做推理日志满足对结果可追溯的审计需求如果未来想蒸馏一个垂直领域模型这份推理过程就是高价值的训练语料。注意别把reasoning_content直接展示给最终用户产品里暴露给用户的应该只是干净的content。6.2 结构化输出与质量对拍让结果可验证而不是“看运气”生产环境最怕模型输出格式飘忽不定动不动给你一段 Markdown 而不是 JSON。DeepSeek 支持response_format强制 JSON 输出这个开关可以减少大量解析坑resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个严格的 JSON 输出器。}, {role: user, content: 分析这段日志的异常根因}, ], response_format{type: json_object} )拿到结构化回答之后还需要回答“质量行不行”这个问题。我的习惯是用另一个模型做对拍打分把准确性和可操作性量化为分数而不是凭感觉判断。这里可以写一个极简的评估函数在测试集上跑一轮回归效果好就保留不理想就调整提示词再战。这个流程看起来简单但能拦住绝大多数“看起来不错、一用就崩”的翻车。我把这套习惯坚持了大半年最深的教训是模型选型和超参配置都是可以快速试出来的真正的成本在上下文管理和输出验证上。本地部署之前先把显存账算清接入生产之前先把裁剪、路由、超时三件事做掉踩坑的概率至少降一半。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek开源大模型实战：从API接入到本地部署避坑指南
简介《DeepSeek从入门到精通》由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室团队编写以DeepSeek-R1开源推理模型为主线面向对自然语言处理、机器学习及开源AI工具感兴趣的研发工程师和技术爱好者。资料首先介绍DeepSeek是什么、能做什么覆盖智能对话、文本生成、语义理解、代码生成与补全、知识推理等典型场景随后重点对比推理模型与非推理模型在优势领域、决策能力、人机互动等方面的差异并给出数学证明、创意写作、代码生成等任务下的模型选择建议。提示语设计部分则从指令驱动、需求导向、混合模式到启发式提问逐层展开配合具体示例和误区提醒帮助读者根据任务类型快速调整提问策略避免常见使用陷阱。文档仅含1个PDF文件大小4.83MB内容结构清晰适合作为大模型应用研究、学术探索及日常开发的随身参考。已有590人学习下载对希望系统掌握DeepSeek使用技巧与开源大模型选型逻辑的人群具有不错的参考价值。1. DeepSeek 是什么一个能让中小团队绕开“闭源 API 高价”的通用 AI 开源选择DeepSeek 是深度求索公司开源的大模型系列也是这两年我最愿意推荐给工程团队试用的“通用 AI 开源项目”。因核心团队有大量成员来自清华技术圈习惯把它归到“清华系”。它最打动我的不是榜单分数而是把“能力通用”和“开源可用”同时做成了现实。对做产品的团队来说DeepSeek 意味着一条比“闭源 API”更便宜、比“从头训模型”更现实的路线先调用官方 API 快速验证再按业务量决定要不要本地部署蒸馏模型。代码、数学、写作、问答一个模型基本都接得住接入成本却低一个量级。这篇文章从架构原理讲到 API 接入、本地部署和常见坑位全程按一线落地视角写。看完你就能在自己的项目里把 DeepSeek 用起来而不是让它躺在收藏夹里。2. 把 DeepSeek 的底账算清MoE、推理链与开源许可能撑起多大场景2.1 671B 总参数只激活 37BMoE 和 MLA 到底省了什么传统 Dense 模型处理每个 token 时所有参数都要参与计算所以参数量越大单次推理成本越高。DeepSeek-V3 走的是 MoE混合专家路线整个模型有 671B 总参数但处理一个 token 时只激活其中约 37B 参数的专家子网络。你可以理解为“一个超大的团队每次只叫擅长的那个人上场”。这正是它能把推理价格压下来的核心原因。工程上这带来一个容易误判的点激活参数决定单次推理的算力成本总参数决定部署时的显存成本。671B 的权重文件在 FP8 精度下也要六百多 GB本地基本得靠多机集群但因为激活参数只有 37B官方 API 端的单 token 推理成本就能做到很低。所以“671B”这个数字吓退了不少人实际上你选型时应该分开看——用 API 还是自部署账完全不同。MLAMulti-head Latent Attention是另一个被低估的设计。它把 KV 缓存压缩成低维潜在向量长上下文场景下的显存占用和带宽消耗大幅下降。做工程的人都知道长上下文推理最先爆掉的就是 KV cacheMLA 就是冲着这个痛点去的。所以 DeepSeek API 能支撑大段文档处理不用像以前那样每加一轮对话就担心显存翻倍。2.2 R1 的推理链不是“提示词技巧”是强化学习练出来的很久以前我们用大模型做推理题得靠提示词教它“请一步步思考”。DeepSeek-R1 把这条路径彻底改写了模型内部自带推理链而且这个能力不是靠人工写提示词调出来的是用强化学习练出来的。它在训练时引入 GRPO 这类策略优化方法配合规则奖励——数学题答案对就是对、代码跑通就是跑通不用人工标注偏好模型在试错中自己学会了“先想清楚再回答”。和传统 RLHF 相比R1 的路线对可自动验证的任务更友好也便宜得多。这对工程落地的直接意义是复杂逻辑任务不用再靠 prompt 工程硬撑模型本身具备深度思考能力。更关键的是官方把 R1 的推理能力蒸馏到了 1.5B、7B、14B、32B、70B 这些小模型上让消费级显卡也能跑出不错的推理效果。本地部署 DeepSeek 成为现实靠的就是这一手。2.3 开源协议不等于随便用商用、分发与用户规模边界很多人一听到“开源”就默认可以随便用但在 DeepSeek 这里要分清权重开放不等于无限制。它的许可协议允许商业使用也允许基于模型做修改和再分发这对大多数中小团队已经完全够用但有几个边界条款需要留意——不能用于军事等敏感场景不能利用模型能力去伤害他人如果你的产品月活用户规模达到亿级需要向官方申请专项授权。实操层面我的建议是做私有化部署、接入自己的产品、二次开发后内部使用这些都没问题但如果你要做开放平台把 DeepSeek 作为底层服务开放给第三方调用就要仔细核对协议里对“再分发”和“多用户服务”的约定。另外“开源”在中文语境里常和 OSI 定义的 Open Source 混为一谈DeepSeek 的模型权重和代码仓库是开放的但许可证更像自定义协议别拿 Apache 2.0 的宽松标准去套。3. API 接入 DeepSeek从 curl 验证到企业微信群机器人的最小闭环3.1 先做连通性验证OpenAI 兼容接口的第一条 curl 命令DeepSeek API 的接口设计与 OpenAI 兼容这省去了大量适配成本。现有的 OpenAI SDK、LangChain、Dify、FastGPT 这类工具只需要改 base_url 和 api_key 就能切过来。官方平台注册后拿到 API Key把它写进环境变量先用一条 curl 命令验证连通性export DEEPSEEK_API_KEYsk-xxxxxxxx curl 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: 你是一名严谨的技术回答者。}, {role: user, content: 用一句话解释什么是 MoE 模型。} ], stream: false }model字段有两个常用值deepseek-chat对应通用对话模型适合写作、代码生成、知识问答deepseek-reasoner对应带推理链的模型适合数学、逻辑、复杂 Debug。messages数组按对话顺序排列system 角色负责设定行为边界。stream建议在调试阶段设为 false返回完整 JSON 方便看结构生产环境再改成 true 做流式输出。3.2 Python 封装多轮对话messages、temperature、stream 三个关键点验证连通性之后就该用代码封装了。我的习惯是直接用 OpenAI 官方 Python SDK把 base_url 指到 DeepSeek 即可import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) messages [ {role: system, content: 你是一名熟悉 Spring Cloud 微服务架构的技术顾问。}, {role: user, content: 服务间调用经常超时应该从哪几个方向排查}, {role: assistant, content: 建议先看三处网络连通性、服务线程池、调用超时配置。}, {role: user, content: 那怎么确认线程池是不是瓶颈} ] resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.6, max_tokens2048, streamFalse, ) print(resp.choices[0].message.content)这里三个参数要单独说。temperature0.6是代码和结构化任务比较稳的中间值偏低会让输出趋于保守适合写 SQL、生成配置偏高到 0.9 以上适合文案创意但代码类任务容易跑偏。max_tokens控制单次回复的最大长度不设的话一些长文档任务可能中途截断但设太小又会让复杂回答不完整。streamFalse适合调试和低成本场景生产环境建议开流式用户看到 token 一个个蹦出来心理等待时间能缩短一大半而且不会触发网关超时。3.3 落地到企业微信群机器人一个自动问答链路的完整骨架接入企业微信是团队内部落地最常见的需求但很多文章只讲了群机器人 webhook 单向推送。实际上企业微信群机器人的 webhook 只能往外发消息收不到成员提问。要做双向问答得用企业微信自建应用的消息回调。核心骨架长这样from flask import Flask, request import hashlib import time import requests app Flask(__name__) TOKEN your_corp_token # 自建应用回调配置里的 Token CORP_ID your_corp_id SECRET your_app_secret AGENT_ID 1000002 # 自建应用 AgentId def verify_signature(msg_signature, timestamp, nonce, echostr): s sorted([TOKEN, timestamp, nonce, echostr]) calc hashlib.sha1(.join(s).encode(utf-8)).hexdigest() return calc msg_signature def get_access_token(): url fhttps://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid{CORP_ID}corpsecret{SECRET} return requests.get(url).json()[access_token] def ask_deepseek(content): resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: content}], temperature0.7, max_tokens1024, ) return resp.choices[0].message.content app.route(/wecom/callback, methods[GET, POST]) def callback(): if request.method GET: params request.args if verify_signature(params[msg_signature], params[timestamp], params[nonce], params[echostr]): return params[echostr] return verify fail, 403 xml_body request.data.decode(utf-8) import xml.etree.ElementTree as ET root ET.fromstring(xml_body) from_user root.findtext(FromUserName) content root.findtext(Content) reply ask_deepseek(content) access_token get_access_token() requests.post( fhttps://qyapi.weixin.qq.com/cgi-bin/message/send?access_token{access_token}, json{ touser: from_user, msgtype: text, agentid: AGENT_ID, text: {content: reply}, } ) return success回调 URL 必须是一个公网可达的 HTTPS 端点msg_signature的 SHA1 校验只验证了请求来源生产环境还需要用官方 SDK 做 AES 解密因为企业微信默认对消息体加密。get_access_token返回的 token 有效期两小时生产要缓存复用否则每个请求都去拉一次 token 很容易触发接口限流。这一步跑通之后DeepSeek 就真正嵌入了团队的日常协作而不是只停留在 API 调试阶段。4. 本地部署 DeepSeek先算显存账再定 Ollama 还是 vLLM4.1 显存账怎么算蒸馏模型每一档分别要什么卡本地部署 DeepSeek第一个问题不是装什么框架而是你的显卡能背动多大的模型。显存占用可以粗算半精度 FP16 权重约占 2 字节/参数INT8 约 1 字节4bit 量化约 0.5 字节。再叠加 KV cache 和框架开销实际需要在这个基础上加 20%-30%。蒸馏模型各档位的现实需求如下模型档位FP16 权重占用4bit 量化后推荐硬件1.5B约 3GB约 1GB8GB 显卡可跑7B约 14GB约 4-5GB8GB-16GB 显卡14B约 28GB约 9-10GB16GB-24GB 显卡32B约 64GB约 19-22GB48GB 或双卡并联70B约 140GB约 40-45GB多卡服务器这里有个新手常犯的错误只看权重大小忽略了 KV cache。上下文长度设得越大、并发越高KV cache 增长越快。7B 模型 FP16 权重只要 14GB但你要是把上下文开到 32K 且同时处理 8 个请求显存很容易冲破 20GB。所以选显卡时至少留出权重占用 50% 的余量。4.2 一条命令跑通 7BOllama 的场景和参数边界如果你只想在本地体验或者给三五个人用Ollama 是最省事的路径。它对显卡要求低、安装简单模型量化格式现成不需要自己处理推理框架的配置。拉取并运行官方蒸馏版 7B 模型只需要两条命令ollama pull deepseek-r1:7b ollama run deepseek-r1:7b默认上下文只有 2048日常问答够用但要做代码补全或长文本分析就显得局促。可以在启动时设置环境变量也可以在交互界面里用/set parameter调OLLAMA_CONTEXT_LENGTH8192 ollama run deepseek-r1:7b/set parameter num_ctx 8192num_ctx设得越大显存和首 token 延迟都会上升。7B 模型在 16GB 显卡上开 8K 上下文体验还过得去开 32K 就可能需要等待较长时间。Ollama 的边界在于并发能力弱它默认是排队式逐 token 生成适合个人和研究场景到了多人同时用的阶段就得换 vLLM。4.3 vLLM 做服务化7B 模型的并发配置与验证命令生产环境需要并发和吞吐我一般把 vLLM 作为首选。它实现了 PagedAttention 显存管理能把 KV cache 利用率提上去不少。部署 7B 蒸馏模型的常用命令是这样vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --host 0.0.0.0 \ --port 8000 \ --served-model-name deepseek-r1-7b \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --dtype auto \ --enable-prefix-caching--max-model-len 8192是上下文长度上限它直接决定 KV cache 预留多大调小可以给并发腾出显存--gpu-memory-utilization 0.85让 vLLM 只用 85% 显存留出余量给 CUDA 和其他进程拉满容易在启动后触发 OOM--enable-prefix-caching开启共享前缀缓存企业里大量请求带相同的 system prompt这个开关能把重复算力直接省掉。服务起来之后验证两件事一是模型是否加载成功二是推理链路是否通。用 curl 快速确认curl http://localhost:8000/v1/models curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1-7b, messages: [{role: user, content: 用一段话解释 RAG}], max_tokens: 512 }vLLM 暴露的是 OpenAI 兼容接口所以 Codex 这类支持自定义模型地址的工具只要把 base_url 指到http://localhost:8000/v1模型名写成deepseek-r1-7b就能接入。这一步跑通后DeepSeek 才算真正成为团队内部可复用的推理服务。5. DeepSeek 避坑指南五条按“现象→原因→解决”写的实战排查5.1 现象一上下文一长模型开始丢信息还“装懂”连续对话到十几轮之后模型开始遗忘前面给过的关键信息更麻烦的是它不会承认自己忘了而是顺着当前语境编一个看似合理的回答。原因是多数调用方把历史消息全部塞进messages一旦总量超过模型上下文窗口远端就会静默截断最早的内容。解决办法是应用层自己做滑窗裁剪。我的惯例是保留 system prompt 不变只保留最近六轮对话再对总长度做一次字符级兜底def trim_messages(messages, max_rounds6): system [m for m in messages if m[role] system] history [m for m in messages if m[role] ! system] return system history[-max_rounds * 2:]如果业务需要超长上下文不要硬塞进 messages用 RAG 先把相关资料检索出来再拼接。DeepSeek 的长窗口是为了容纳一次性输入的大量文本而不是让你把整本操作手册都丢进去。5.2 现象二deepseek-reasoner 一直“转圈”太多调用deepseek-reasoner时请求长时间不返回日志没有任何报错最终被网关判定超时。原因是推理链模型会在返回正式回答前生成大量可见或不可见的思维链 token一篇复杂推理可能消耗数千 token默认 30 秒的客户端超时根本不够用。官方接口正常响应时间可以从十几秒到两分钟不等。解决方向有三个客户端超时调到 120 秒以上网关层同步调整proxy_read_timeout生产环境开启流式输出让用户看到思考过程在推进而不是干等。我用过的最稳配置是流式 120 秒超时再配合前端“正在分析”的状态提示体感问题基本就消失了。5.3 现象三同一份 prompt 换模型后输出质量断崖下跌在deepseek-chat上跑得好好的提示词切到deepseek-reasoner之后突然变得啰嗦甚至答非所问反过来逻辑题在 chat 模型上又容易出错。原因是两个模型定位完全不同chat 偏向直接回答reasoner 先做推理链它会把简单问题复杂化。不要全局只配一个模型。按任务类型做路由是性价比最高的做法代码生成、文案写作、日常对话走deepseek-chat数学证明、复杂排查、架构设计评审走deepseek-reasoner。我在生产里建议从 task 类型判断模型选择可以封装成一个简单的路由函数把不可控因素限定在提示词里而不是让模型选型变成“看这次运气”。5.4 现象四vLLM 部署后并发一高就 OOMvLLM 刚部署时单请求一切正常并发升到三四个之后进程直接崩掉查看显存发现已经打满。原因是--max-model-len设得过大vLLM 会按最大长度预分配 KV cache并发越高缓存翻倍越快--gpu-memory-utilization拉到 0.95 这种极端值又让框架没有一点缓冲余量。解决思路是压缩单请求显存占用把--max-model-len降到业务真实需要的 4096 或 8192用--gpu-memory-utilization 0.85留出安全垫如果并发仍不够再加--max-num-seqs限制同时处理的序列数宁可排队也不要 OOM。vLLM 的显存是按峰值请求预留的别拿单请求的占用去推算并发上限。5.5 现象五新对话不承接旧对话记忆说丢就丢在网页端聊到对话上限后新建对话继续发消息时模型完全不记得之前聊过什么。很多人的第一反应是模型记忆有问题但本质是产品层面就没有跨会话保存上下文——新会话的 messages 是空的模型当然不知道你之前说过什么。要在应用层自己实现“记忆”机制。我常用的做法是在对话结束时让模型生成一段摘要新对话把它注入 system prompt。那段摘要的有效做法是让模型负责提炼关键结论只把事实和决策浓缩成几行丢掉闲聊细节。实际执行可以顺手写个简单的摘要函数返回一段文本放进新会话的 system 里这样用户下次提问时模型就有了“前情提要”。6. 把 DeepSeek 武装成生产级能力输出评估、推理日志与结构化响应6.1 抓取 reasoning_content把“思考过程”变成可审计日志调用deepseek-reasoner时响应里除了content还有一个reasoning_content字段里面存放模型生成正式回答前的推理过程。很多人直接忽略它其实这是调试和审计的宝藏resp client.chat.completions.create( modeldeepseek-reasoner, messages[{role: user, content: 这段 SQL 为什么走不了索引}], streamFalse, ) answer resp.choices[0].message.content reasoning resp.choices[0].message.reasoning_content print(推理过程, reasoning) print(最终回答, answer)reasoning_content的典型用途有三个排查回答质量问题时判断模型是否走了正确推理路径把它落库做推理日志满足对结果可追溯的审计需求如果未来想蒸馏一个垂直领域模型这份推理过程就是高价值的训练语料。注意别把reasoning_content直接展示给最终用户产品里暴露给用户的应该只是干净的content。6.2 结构化输出与质量对拍让结果可验证而不是“看运气”生产环境最怕模型输出格式飘忽不定动不动给你一段 Markdown 而不是 JSON。DeepSeek 支持response_format强制 JSON 输出这个开关可以减少大量解析坑resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个严格的 JSON 输出器。}, {role: user, content: 分析这段日志的异常根因}, ], response_format{type: json_object} )拿到结构化回答之后还需要回答“质量行不行”这个问题。我的习惯是用另一个模型做对拍打分把准确性和可操作性量化为分数而不是凭感觉判断。这里可以写一个极简的评估函数在测试集上跑一轮回归效果好就保留不理想就调整提示词再战。这个流程看起来简单但能拦住绝大多数“看起来不错、一用就崩”的翻车。我把这套习惯坚持了大半年最深的教训是模型选型和超参配置都是可以快速试出来的真正的成本在上下文管理和输出验证上。本地部署之前先把显存账算清接入生产之前先把裁剪、路由、超时三件事做掉踩坑的概率至少降一半。希望帮到你。本文还有配套的精品资源点击获取