简介这份由山东大学经济学院李铁岗教授团队出品的《DeepSeek应用与部署》演示文稿共80页面向希望系统了解大模型技术演进、部署思路与业务落地的开发者、企业技术负责人及高校研究者。内容从AIGC与语言模型发展脉络切入梳理DeepSeek V2的Multi-Head Latent Attention、V3推理模型以及PPO、GRPO强化学习优化路径并按基础、中级、高级、终极四个能力层级展开多模态融合、动态数据治理、因果推理、多目标优化、数字孪生仿真、多智能体协同与自编程等应用场景兼顾API调用与医疗、教育、金融等垂直行业落地。资源包为单个pptx文件约16.01MB结构清晰适合按章节查阅。目前已有459人学习。读者可借助它快速建立从模型架构到部署方案的完整认知获取可复用的能力分层框架与业务决策参考。1. 从一份 80 页课件说起DeepSeek 部署到底卡在哪很多人拿到这份山东大学经济学院的 80 页课件第一眼看到的是 AIGC 十年时间线、LLM 六年演进、DeepSeek 的能力四层分级觉得是一份科普材料。但真动手把 DeepSeek 接进业务的人会发现课件里真正值钱的只有两处V2 的 Multi-Head Latent Attention 和 V3 那一代的推理模型加 PPO/GRPO 强化学习。前者决定你能不能把模型塞进有限的显存里跑起来后者决定你该不该做 Agent、该按什么粒度去拆业务。这也是「DeepSeek 应用与部署」这类需求最容易被讲偏的地方一上来就贴 API 调用示例跑通了 demo 就算完工。真实项目里卡人的是显存怎么算、量化选哪档、并发上不去是谁的锅、思维链输出把 max_tokens 吃光了怎么办。后面几章按架构约束、本地化部署、API 调用与密钥治理、业务应用、效果验证的顺序展开每一步都给可复现的命令和参数。2. DeepSeek 架构与推理范式MLA、V3 推理模型与 GRPO 的工程含义2.1 MLA 为什么能把 KV Cache 压成可控项标准 MHA 的 KV Cache 形状是[B, H_kv, S, D]层数一多、上下文一长这部分显存能超过模型权重本身。DeepSeek V2 引入的 Multi-Head Latent Attention 换了个思路不直接缓存完整的 K 和 V而是先把它们投影到一个低维 latent 向量c_t用时再上投影还原同时把携带位置信息的那一小段分量单独保存避免压缩过程把位置编码搅坏。工程上的后果很直接同样一张卡能开的并发数和上下文长度都上去了。下面这段脚本用来估算 KV Cache 量级把 MLA 的压缩比调成 1.0 就是标准 MHA 的算法方便对比。def kv_cache_gb(layers, kv_heads, head_dim, seq_len, batch, bytes_per2, compress_ratio1.0): layers : Transformer 层数 kv_heads : KV 头数GQA/MQA 时小于 attention 头数 head_dim : 每个头的维度 seq_len : 上下文长度 batch : 并发序列数vLLM 里约等于同时活跃的请求数 bytes_per : FP16/BF16 取 2FP8/INT8 取 1 compress_ratio: MLA 的 latent 压缩比1.0 表示标准 MHA per_token 2 * layers * kv_heads * head_dim * bytes_per # K 和 V 各一份 total per_token * seq_len * batch * compress_ratio return total / 1024 ** 3 print(kv_cache_gb(61, 8, 128, 32768, 8)) # 标准 GQA print(kv_cache_gb(61, 8, 128, 32768, 8, 2, 0.08)) # 近似的 MLA 量级逻辑说明系数 2 代表 K、V 两份缓存头数乘头维度得到每层每 token 的存储宽度再乘层数、序列长度和并发数。参数说明compress_ratio不是官方数字而是给你做容量规划用的上界估计实际值取决于模型配置建议先按 0.1 左右预留再用真实压测结果修正。注意MoE 结构下权重的显存占用和激活参数量不是一个数量级别拿总参数量直接乘字节数会把自己吓退。2.2 V3 推理模型与 PPO、GRPO 的差异课件里把强化学习的要素写得比较清楚智能体在环境中不断尝试优化策略最终拿到最大化奖励。落到算法实现上PPO 和 GRPO 的差别会直接影响你训练侧的资源规划。PPO 需要额外维护一个 value model 来估计基线显存占用和调参成本都高优势估计的偏差要靠 critic 去压。GRPO 的做法是去掉 value model对同一个 prompt 采样一组回答用组内相对得分做基线组内归一化后算优势。省掉了一个和策略模型同量级的网络训练显存降下来代价是采样并行度要求更高rollout 吞吐成了新瓶颈。维度PPOGRPO是否需要 value model需要显存约等于策略模型不需要优势估计方式GAE critic 预测组内奖励归一化采样并行度要求中等高组越大方差越低主要调参项clip 系数、critic 学习率组大小、KL 惩罚系数部署侧影响训练集群并行策略复杂推理集群吞吐压力大2.3 从训练范式反推部署侧的三条约束第一条是显存约束。推理模型输出的是思维链一次请求的实际生成长度可能是普通对话的三到五倍KV Cache 随生成长度线性增长估算容量时不能只按输入长度算。第二条是吞吐约束。MoE 结构要做专家并行专家分布在多卡上通信开销随并行度上升小 batch 场景下 GPU 利用率会很差所以本地部署要么攒 batch要么直接接受低并发。第三条是上下文约束。长思维链叠上 RAG 检索回来的文档块很容易顶到上下文上限表现为对话突然被截断或者报长度超限这块的处理方式在 4.2 节展开。3. 本地化部署方案Ollama、llama.cpp 与 vLLM 的选型与参数3.1 四条路线的适用边界选型不需要纠结先看并发和显存两个数。路线典型场景并发能力量化支持主要坑Ollama个人开发机、内网小工具低个位数GGUFQ4 到 Q8默认上下文偏小需手动调llama.cppCPU 或混合推理、边缘设备很低GGUF全档位CPU 上首 token 延迟高vLLM生产服务、多卡高连续批处理AWQ/GPTQ/FP8显存预分配激进需调占用率托管 API快速验证、峰值弹性取决于配额不涉及数据出域、成本不可控常见做法是验证阶段用托管 API 和 Ollama 各跑一遍确认提示词和输出格式稳定后再把量大的那条链路迁到 vLLM 上自建。3.2 显存测算与量化档位权重占显存的算法很朴素参数量乘以每参数字节数。FP16/BF16 是 2 字节FP8/INT8 是 1 字节Q4 大约 0.5 字节再加一点量化元数据开销。加上 2.1 节算出来的 KV Cache再留 10% 到 15% 给激活值和框架开销就是你的卡能不能装下的判断依据。量化档位每参数字节精度损失适用判断BF162.0无多卡、对精度敏感FP81.0很小支持 FP8 的新卡首选INT8 / Q81.0小单卡想跑大一点的模型Q40.5可感知显存紧张、任务偏生成提示量化档位别只看显存省了多少先拿自己的业务测试集跑一遍。分类、抽取类任务对量化比较敏感摘要和润色类任务通常无感。3.3 Ollama 快速起一个本地服务先装 Ollama拉一个中等尺寸的模型直接用它内置的 OpenAI 兼容接口验证链路。# 启动服务默认监听 11434 ollama serve # 拉取模型以 14B 档为例 ollama pull deepseek-r1:14b # 关键默认上下文窗口偏小显存够就把 num_ctx 调大 curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:14b, messages: [{role: user, content: 用三句话解释 MoE 路由}], temperature: 0.6, max_tokens: 512, stream: false }逻辑说明ollama serve之后/v1/chat/completions就是 OpenAI 兼容端点现有代码只要改 base_url 就能切过来。参数说明num_ctx需要在模型参数里配Ollama 默认值对长文档场景不够用temperature在推理模型上别调太低低于 0.5 时思维链容易塌缩成短回答。排查思路如果返回内容为空先看是不是被max_tokens截断在思维链里了。3.4 vLLM 生产部署的关键参数多卡场景我一般直接用 vLLM 的 serve 模式参数一屏配完。python -m vllm.entrypoints.openai.api_server \ --model /models/deepseek-chat \ --served-model-name deepseek-chat \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --enable-prefix-caching \ --swap-space 16 \ --trust-remote-code \ --port 8000逻辑说明--tensor-parallel-size要和可见 GPU 数一致张量并行能切开权重但每层都有两次 all-reduce卡数越多通信占比越高。参数说明--max-model-len要和你真实的最长上下文匹配设太大等于把 KV Cache 池子提前占掉--gpu-memory-utilization从 0.9 起调遇到 OOM 就往下压到 0.85--enable-prefix-caching对系统提示词固定的业务非常值命中后首 token 延迟能明显下降。注意启动阶段报显存不足先降--max-model-len再降--gpu-memory-utilization最后才考虑换量化版本。顺序反了会白折腾一晚上。4. DeepSeek API 调用协议、流式、工具调用与密钥治理4.1 最小可用调用接口是 OpenAI 兼容协议客户端不用换。import os from openai import OpenAI client OpenAI( api_keyos.environ[DEEPSEEK_API_KEY], # 从环境变量读别写死在代码里 base_urlhttps://api.deepseek.com/v1, # 官方兼容端点 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是金融合规助手回答必须给条款依据}, {role: user, content: 客户风险等级上调需要哪些留痕材料}, ], temperature0.3, # 合规类任务压低随机性 top_p0.9, max_tokens1024, streamFalse, timeout60, ) print(resp.choices[0].message.content) print(resp.usage) # 看 prompt/completion token做成本核算逻辑说明messages里 system 承载角色和约束比塞在 user 里更稳。参数说明temperature控制采样随机性抽取和分类任务设 0.1 到 0.3max_tokens在推理模型上要留够思维链本身也是 tokentimeout必须显式设置长思维链请求超过默认超时会让上层重试重试再把额度打满。4.2 流式输出与超长对话截断交互式界面一定要开流式否则用户盯着空白等十几秒。stream client.chat.completions.create( modeldeepseek-chat, messageshistory, streamTrue, max_tokens2048, ) buf [] for chunk in stream: delta chunk.choices[0].delta.content or if delta: buf.append(delta) print(delta, end, flushTrue) # 边收边渲染 full_text .join(buf)逻辑说明流式只改变传输方式不改模型行为但要注意delta.content可能是空字符串直接拼接会报错。参数说明流式下usage字段不一定会返回成本统计要单独兜底。超长对话的处理策略是分层最近 N 轮原样保留更早的轮次用一次摘要请求压成一段话检索到的文档块只保留命中的片段而不是整篇。常见踩坑是把整个知识库塞进 system结果第二次对话就撞上长度上限表现为「达到对话长度上限请开启新对话」这类提示。4.3 Function Calling 与结构化输出要让模型调你的接口用工具声明而不是在提示词里描述格式。tools [{ type: function, function: { name: query_order, description: 按订单号查询物流状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号纯数字}, with_detail: {type: boolean, default: False}, }, required: [order_id], }, }, }] resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 帮我查下 20250312 这个单到哪了}], toolstools, tool_choiceauto, ) call resp.choices[0].message.tool_calls if call: import json args json.loads(call[0].function.arguments) # 到这里再真正去调内部服务不要相信模型给的任何业务数据 print(call[0].function.name, args)逻辑说明模型只负责把自然语言映射成结构化参数真正的查询由你的服务执行返回结果后用roletool的消息追加回对话再请求一次。参数说明tool_choiceauto让模型自己判断要不要调强约束场景可以指定具体函数名description写得越具体参数抽取越准。要 JSON 输出但不涉及工具时用response_format{type: json_object}并在提示词里给一个字段示例。4.4 API 密钥权限分层与额度控制密钥管理是落地阶段最容易出事的一环。我一般按四层来管密钥只进环境变量或密钥管理服务禁止写进代码仓库、前端和日志。按业务线分发子密钥一条业务线一把出事能单独吊销。中间加一层 OpenAI 兼容网关统一限流、计费、审计和模型别名映射。编辑器插件和 CLI 工具接入时统一填网关地址和模型别名避免每换一个客户端就改一次配置。日志脱敏prompt 和 completion 落库前先过滤身份证、手机号、账号这类字段。注意接入编辑器或 CLI 插件时报request extension preparation failed一类错误九成是 base_url 和模型名不匹配别急着怀疑网络。5. 业务应用落地能力层级、RAG 链路与低代码编排5.1 用能力层级倒推业务选型课件把 DeepSeek 的能力分成基础、中级、高级、终极四层这个划分拿来当选型表比当宣传语有用得多。能力层级课件中的关键能力落到业务上的形态基础层多模态融合、动态数据治理文档解析、格式归一、脏数据清洗中级层领域自适应、因果推理、多目标优化垂直知识问答、风控规则推理、排产寻优高级层数字孪生、多智能体协同、元认知调控仿真推演、跨部门 Agent 协作终极层概念空间探索、自编程研发辅助、自动化测试用例生成多数企业的第一个项目应该压在基础层和中级层之间把散落在 PDF、扫描件、Excel 里的数据统一成结构化字段再接一个领域问答。直接冲着高级层去通常会在数据治理这一步就停住。5.2 RAG 检索增强的最小可用链路from sentence_transformers import SentenceTransformer import faiss, numpy as np encoder SentenceTransformer(BAAI/bge-m3) # 中文检索效果较稳的向量模型 def build_index(chunks): vecs encoder.encode(chunks, normalize_embeddingsTrue) # 归一化后用内积余弦 index faiss.IndexFlatIP(vecs.shape[1]) index.add(np.asarray(vecs, dtypefloat32)) return index def retrieve(index, chunks, query, top_k5): q encoder.encode([query], normalize_embeddingsTrue) scores, idx index.search(np.asarray(q, dtypefloat32), top_k) return [(chunks[i], float(s)) for s, i in zip(scores[0], idx[0])]逻辑说明归一化之后内积等价于余弦相似度省掉一次除法。参数说明top_k别贪大召回五到八块就够块与块之间留 10% 到 20% 的重叠避免切断语义召回分数低于阈值时宁可返回「未找到依据」也别让模型自由发挥。切片粒度按业务走条款类文档按条切技术手册按小节切。提示词模板要把检索结果和问题隔开prompt f根据以下资料回答问题资料中没有的内容直接回答未收录。 资料 {chr(10).join(f[{i1}] {c} for i, (c, _) in enumerate(hits))} 问题{user_query} 要求每个结论后标注引用的资料编号。5.3 低代码编排与流程集成不是所有场景都值得写代码。审批流、消息推送、定时报表这类链路用 n8n 或 FastGPT 这类编排工具串起来更快模型节点直接指向你的网关地址即可。docker run -d --name n8n \ -p 5678:5678 \ -e N8N_ENCRYPTION_KEY$(openssl rand -hex 16) \ -e EXECUTIONS_MODEqueue \ -e QUEUE_BULL_REDIS_HOSTredis \ -v n8n_data:/home/node/.n8n \ n8nio/n8n逻辑说明EXECUTIONS_MODEqueue把执行进程和主进程拆开配合 Redis 做任务队列多实例部署时不会重复触发。参数说明N8N_ENCRYPTION_KEY一旦设定就不能改否则已存的凭据全部解不开上线前先写进密钥管理。并发量再往上走记得给队列加 worker 实例单靠加机器不解决问题。5.4 验收指标与常见失败模式上线前至少要看四个数首 token 延迟、端到端 P95 延迟、单位请求 token 成本、人工兜底率。前两个决定体验后两个决定这个项目能不能长期活着。常见失败模式有三类检索召回不准导致答非所问这时先看切片和向量模型别急着换大模型输出不稳定导致结构化解析失败改用工具调用或 JSON 模式成本失控多半是 system 提示词太长或者思维链没做截断。6. 效果验证与调优把主观感受换成可复现的数字调优最怕凭感觉。我一般先固化一个 100 到 200 条的小评测集每条包含问题、标准答案要点和是否可回答的标记每次改提示词或换模型都跑一遍。import json, statistics def evaluate(client, cases, modeldeepseek-chat): hit, latencies 0, [] for c in cases: t0 time.time() r client.chat.completions.create( modelmodel, messages[{role: user, content: c[q]}], temperature0.2, max_tokens512, ) latencies.append(time.time() - t0) ans r.choices[0].message.content # 要点覆盖式打分比整句匹配鲁棒 hit all(k in ans for k in c[keys]) return { accuracy: hit / len(cases), p95_latency: statistics.quantiles(latencies, n20)[18], }逻辑说明用要点覆盖率代替字符串完全匹配避免模型换个说法就被判错。参数说明评测时固定temperature否则同一条数据两次结果不可比p95_latency取 20 分位的第 19 个值样本量太小时改用max()更稳妥。延迟分解也值得做一次把请求耗时拆成排队、首 token、生成三段。排队时间长说明并发配额或--gpu-memory-utilization需要调首 token 慢通常是提示词太长开前缀缓存能缓解生成阶段慢则和输出长度正相关考虑限制思维链长度或者在业务侧做答案裁剪。一个容易被忽略的技巧是缓存。把(模型, 提示词模板, 问题)哈希后写入 Redis命中直接返回对报表生成、固定问答这类重复率高的场景能省掉相当一部分调用量。缓存要设过期时间模型或提示词一变就整体失效否则会拿旧答案糊弄用户。本文还有配套的精品资源点击获取 DeepSeek应用部署指南：MLA显存优化、vLLM服务与RAG实践
简介这份由山东大学经济学院李铁岗教授团队出品的《DeepSeek应用与部署》演示文稿共80页面向希望系统了解大模型技术演进、部署思路与业务落地的开发者、企业技术负责人及高校研究者。内容从AIGC与语言模型发展脉络切入梳理DeepSeek V2的Multi-Head Latent Attention、V3推理模型以及PPO、GRPO强化学习优化路径并按基础、中级、高级、终极四个能力层级展开多模态融合、动态数据治理、因果推理、多目标优化、数字孪生仿真、多智能体协同与自编程等应用场景兼顾API调用与医疗、教育、金融等垂直行业落地。资源包为单个pptx文件约16.01MB结构清晰适合按章节查阅。目前已有459人学习。读者可借助它快速建立从模型架构到部署方案的完整认知获取可复用的能力分层框架与业务决策参考。1. 从一份 80 页课件说起DeepSeek 部署到底卡在哪很多人拿到这份山东大学经济学院的 80 页课件第一眼看到的是 AIGC 十年时间线、LLM 六年演进、DeepSeek 的能力四层分级觉得是一份科普材料。但真动手把 DeepSeek 接进业务的人会发现课件里真正值钱的只有两处V2 的 Multi-Head Latent Attention 和 V3 那一代的推理模型加 PPO/GRPO 强化学习。前者决定你能不能把模型塞进有限的显存里跑起来后者决定你该不该做 Agent、该按什么粒度去拆业务。这也是「DeepSeek 应用与部署」这类需求最容易被讲偏的地方一上来就贴 API 调用示例跑通了 demo 就算完工。真实项目里卡人的是显存怎么算、量化选哪档、并发上不去是谁的锅、思维链输出把 max_tokens 吃光了怎么办。后面几章按架构约束、本地化部署、API 调用与密钥治理、业务应用、效果验证的顺序展开每一步都给可复现的命令和参数。2. DeepSeek 架构与推理范式MLA、V3 推理模型与 GRPO 的工程含义2.1 MLA 为什么能把 KV Cache 压成可控项标准 MHA 的 KV Cache 形状是[B, H_kv, S, D]层数一多、上下文一长这部分显存能超过模型权重本身。DeepSeek V2 引入的 Multi-Head Latent Attention 换了个思路不直接缓存完整的 K 和 V而是先把它们投影到一个低维 latent 向量c_t用时再上投影还原同时把携带位置信息的那一小段分量单独保存避免压缩过程把位置编码搅坏。工程上的后果很直接同样一张卡能开的并发数和上下文长度都上去了。下面这段脚本用来估算 KV Cache 量级把 MLA 的压缩比调成 1.0 就是标准 MHA 的算法方便对比。def kv_cache_gb(layers, kv_heads, head_dim, seq_len, batch, bytes_per2, compress_ratio1.0): layers : Transformer 层数 kv_heads : KV 头数GQA/MQA 时小于 attention 头数 head_dim : 每个头的维度 seq_len : 上下文长度 batch : 并发序列数vLLM 里约等于同时活跃的请求数 bytes_per : FP16/BF16 取 2FP8/INT8 取 1 compress_ratio: MLA 的 latent 压缩比1.0 表示标准 MHA per_token 2 * layers * kv_heads * head_dim * bytes_per # K 和 V 各一份 total per_token * seq_len * batch * compress_ratio return total / 1024 ** 3 print(kv_cache_gb(61, 8, 128, 32768, 8)) # 标准 GQA print(kv_cache_gb(61, 8, 128, 32768, 8, 2, 0.08)) # 近似的 MLA 量级逻辑说明系数 2 代表 K、V 两份缓存头数乘头维度得到每层每 token 的存储宽度再乘层数、序列长度和并发数。参数说明compress_ratio不是官方数字而是给你做容量规划用的上界估计实际值取决于模型配置建议先按 0.1 左右预留再用真实压测结果修正。注意MoE 结构下权重的显存占用和激活参数量不是一个数量级别拿总参数量直接乘字节数会把自己吓退。2.2 V3 推理模型与 PPO、GRPO 的差异课件里把强化学习的要素写得比较清楚智能体在环境中不断尝试优化策略最终拿到最大化奖励。落到算法实现上PPO 和 GRPO 的差别会直接影响你训练侧的资源规划。PPO 需要额外维护一个 value model 来估计基线显存占用和调参成本都高优势估计的偏差要靠 critic 去压。GRPO 的做法是去掉 value model对同一个 prompt 采样一组回答用组内相对得分做基线组内归一化后算优势。省掉了一个和策略模型同量级的网络训练显存降下来代价是采样并行度要求更高rollout 吞吐成了新瓶颈。维度PPOGRPO是否需要 value model需要显存约等于策略模型不需要优势估计方式GAE critic 预测组内奖励归一化采样并行度要求中等高组越大方差越低主要调参项clip 系数、critic 学习率组大小、KL 惩罚系数部署侧影响训练集群并行策略复杂推理集群吞吐压力大2.3 从训练范式反推部署侧的三条约束第一条是显存约束。推理模型输出的是思维链一次请求的实际生成长度可能是普通对话的三到五倍KV Cache 随生成长度线性增长估算容量时不能只按输入长度算。第二条是吞吐约束。MoE 结构要做专家并行专家分布在多卡上通信开销随并行度上升小 batch 场景下 GPU 利用率会很差所以本地部署要么攒 batch要么直接接受低并发。第三条是上下文约束。长思维链叠上 RAG 检索回来的文档块很容易顶到上下文上限表现为对话突然被截断或者报长度超限这块的处理方式在 4.2 节展开。3. 本地化部署方案Ollama、llama.cpp 与 vLLM 的选型与参数3.1 四条路线的适用边界选型不需要纠结先看并发和显存两个数。路线典型场景并发能力量化支持主要坑Ollama个人开发机、内网小工具低个位数GGUFQ4 到 Q8默认上下文偏小需手动调llama.cppCPU 或混合推理、边缘设备很低GGUF全档位CPU 上首 token 延迟高vLLM生产服务、多卡高连续批处理AWQ/GPTQ/FP8显存预分配激进需调占用率托管 API快速验证、峰值弹性取决于配额不涉及数据出域、成本不可控常见做法是验证阶段用托管 API 和 Ollama 各跑一遍确认提示词和输出格式稳定后再把量大的那条链路迁到 vLLM 上自建。3.2 显存测算与量化档位权重占显存的算法很朴素参数量乘以每参数字节数。FP16/BF16 是 2 字节FP8/INT8 是 1 字节Q4 大约 0.5 字节再加一点量化元数据开销。加上 2.1 节算出来的 KV Cache再留 10% 到 15% 给激活值和框架开销就是你的卡能不能装下的判断依据。量化档位每参数字节精度损失适用判断BF162.0无多卡、对精度敏感FP81.0很小支持 FP8 的新卡首选INT8 / Q81.0小单卡想跑大一点的模型Q40.5可感知显存紧张、任务偏生成提示量化档位别只看显存省了多少先拿自己的业务测试集跑一遍。分类、抽取类任务对量化比较敏感摘要和润色类任务通常无感。3.3 Ollama 快速起一个本地服务先装 Ollama拉一个中等尺寸的模型直接用它内置的 OpenAI 兼容接口验证链路。# 启动服务默认监听 11434 ollama serve # 拉取模型以 14B 档为例 ollama pull deepseek-r1:14b # 关键默认上下文窗口偏小显存够就把 num_ctx 调大 curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:14b, messages: [{role: user, content: 用三句话解释 MoE 路由}], temperature: 0.6, max_tokens: 512, stream: false }逻辑说明ollama serve之后/v1/chat/completions就是 OpenAI 兼容端点现有代码只要改 base_url 就能切过来。参数说明num_ctx需要在模型参数里配Ollama 默认值对长文档场景不够用temperature在推理模型上别调太低低于 0.5 时思维链容易塌缩成短回答。排查思路如果返回内容为空先看是不是被max_tokens截断在思维链里了。3.4 vLLM 生产部署的关键参数多卡场景我一般直接用 vLLM 的 serve 模式参数一屏配完。python -m vllm.entrypoints.openai.api_server \ --model /models/deepseek-chat \ --served-model-name deepseek-chat \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --enable-prefix-caching \ --swap-space 16 \ --trust-remote-code \ --port 8000逻辑说明--tensor-parallel-size要和可见 GPU 数一致张量并行能切开权重但每层都有两次 all-reduce卡数越多通信占比越高。参数说明--max-model-len要和你真实的最长上下文匹配设太大等于把 KV Cache 池子提前占掉--gpu-memory-utilization从 0.9 起调遇到 OOM 就往下压到 0.85--enable-prefix-caching对系统提示词固定的业务非常值命中后首 token 延迟能明显下降。注意启动阶段报显存不足先降--max-model-len再降--gpu-memory-utilization最后才考虑换量化版本。顺序反了会白折腾一晚上。4. DeepSeek API 调用协议、流式、工具调用与密钥治理4.1 最小可用调用接口是 OpenAI 兼容协议客户端不用换。import os from openai import OpenAI client OpenAI( api_keyos.environ[DEEPSEEK_API_KEY], # 从环境变量读别写死在代码里 base_urlhttps://api.deepseek.com/v1, # 官方兼容端点 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是金融合规助手回答必须给条款依据}, {role: user, content: 客户风险等级上调需要哪些留痕材料}, ], temperature0.3, # 合规类任务压低随机性 top_p0.9, max_tokens1024, streamFalse, timeout60, ) print(resp.choices[0].message.content) print(resp.usage) # 看 prompt/completion token做成本核算逻辑说明messages里 system 承载角色和约束比塞在 user 里更稳。参数说明temperature控制采样随机性抽取和分类任务设 0.1 到 0.3max_tokens在推理模型上要留够思维链本身也是 tokentimeout必须显式设置长思维链请求超过默认超时会让上层重试重试再把额度打满。4.2 流式输出与超长对话截断交互式界面一定要开流式否则用户盯着空白等十几秒。stream client.chat.completions.create( modeldeepseek-chat, messageshistory, streamTrue, max_tokens2048, ) buf [] for chunk in stream: delta chunk.choices[0].delta.content or if delta: buf.append(delta) print(delta, end, flushTrue) # 边收边渲染 full_text .join(buf)逻辑说明流式只改变传输方式不改模型行为但要注意delta.content可能是空字符串直接拼接会报错。参数说明流式下usage字段不一定会返回成本统计要单独兜底。超长对话的处理策略是分层最近 N 轮原样保留更早的轮次用一次摘要请求压成一段话检索到的文档块只保留命中的片段而不是整篇。常见踩坑是把整个知识库塞进 system结果第二次对话就撞上长度上限表现为「达到对话长度上限请开启新对话」这类提示。4.3 Function Calling 与结构化输出要让模型调你的接口用工具声明而不是在提示词里描述格式。tools [{ type: function, function: { name: query_order, description: 按订单号查询物流状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号纯数字}, with_detail: {type: boolean, default: False}, }, required: [order_id], }, }, }] resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 帮我查下 20250312 这个单到哪了}], toolstools, tool_choiceauto, ) call resp.choices[0].message.tool_calls if call: import json args json.loads(call[0].function.arguments) # 到这里再真正去调内部服务不要相信模型给的任何业务数据 print(call[0].function.name, args)逻辑说明模型只负责把自然语言映射成结构化参数真正的查询由你的服务执行返回结果后用roletool的消息追加回对话再请求一次。参数说明tool_choiceauto让模型自己判断要不要调强约束场景可以指定具体函数名description写得越具体参数抽取越准。要 JSON 输出但不涉及工具时用response_format{type: json_object}并在提示词里给一个字段示例。4.4 API 密钥权限分层与额度控制密钥管理是落地阶段最容易出事的一环。我一般按四层来管密钥只进环境变量或密钥管理服务禁止写进代码仓库、前端和日志。按业务线分发子密钥一条业务线一把出事能单独吊销。中间加一层 OpenAI 兼容网关统一限流、计费、审计和模型别名映射。编辑器插件和 CLI 工具接入时统一填网关地址和模型别名避免每换一个客户端就改一次配置。日志脱敏prompt 和 completion 落库前先过滤身份证、手机号、账号这类字段。注意接入编辑器或 CLI 插件时报request extension preparation failed一类错误九成是 base_url 和模型名不匹配别急着怀疑网络。5. 业务应用落地能力层级、RAG 链路与低代码编排5.1 用能力层级倒推业务选型课件把 DeepSeek 的能力分成基础、中级、高级、终极四层这个划分拿来当选型表比当宣传语有用得多。能力层级课件中的关键能力落到业务上的形态基础层多模态融合、动态数据治理文档解析、格式归一、脏数据清洗中级层领域自适应、因果推理、多目标优化垂直知识问答、风控规则推理、排产寻优高级层数字孪生、多智能体协同、元认知调控仿真推演、跨部门 Agent 协作终极层概念空间探索、自编程研发辅助、自动化测试用例生成多数企业的第一个项目应该压在基础层和中级层之间把散落在 PDF、扫描件、Excel 里的数据统一成结构化字段再接一个领域问答。直接冲着高级层去通常会在数据治理这一步就停住。5.2 RAG 检索增强的最小可用链路from sentence_transformers import SentenceTransformer import faiss, numpy as np encoder SentenceTransformer(BAAI/bge-m3) # 中文检索效果较稳的向量模型 def build_index(chunks): vecs encoder.encode(chunks, normalize_embeddingsTrue) # 归一化后用内积余弦 index faiss.IndexFlatIP(vecs.shape[1]) index.add(np.asarray(vecs, dtypefloat32)) return index def retrieve(index, chunks, query, top_k5): q encoder.encode([query], normalize_embeddingsTrue) scores, idx index.search(np.asarray(q, dtypefloat32), top_k) return [(chunks[i], float(s)) for s, i in zip(scores[0], idx[0])]逻辑说明归一化之后内积等价于余弦相似度省掉一次除法。参数说明top_k别贪大召回五到八块就够块与块之间留 10% 到 20% 的重叠避免切断语义召回分数低于阈值时宁可返回「未找到依据」也别让模型自由发挥。切片粒度按业务走条款类文档按条切技术手册按小节切。提示词模板要把检索结果和问题隔开prompt f根据以下资料回答问题资料中没有的内容直接回答未收录。 资料 {chr(10).join(f[{i1}] {c} for i, (c, _) in enumerate(hits))} 问题{user_query} 要求每个结论后标注引用的资料编号。5.3 低代码编排与流程集成不是所有场景都值得写代码。审批流、消息推送、定时报表这类链路用 n8n 或 FastGPT 这类编排工具串起来更快模型节点直接指向你的网关地址即可。docker run -d --name n8n \ -p 5678:5678 \ -e N8N_ENCRYPTION_KEY$(openssl rand -hex 16) \ -e EXECUTIONS_MODEqueue \ -e QUEUE_BULL_REDIS_HOSTredis \ -v n8n_data:/home/node/.n8n \ n8nio/n8n逻辑说明EXECUTIONS_MODEqueue把执行进程和主进程拆开配合 Redis 做任务队列多实例部署时不会重复触发。参数说明N8N_ENCRYPTION_KEY一旦设定就不能改否则已存的凭据全部解不开上线前先写进密钥管理。并发量再往上走记得给队列加 worker 实例单靠加机器不解决问题。5.4 验收指标与常见失败模式上线前至少要看四个数首 token 延迟、端到端 P95 延迟、单位请求 token 成本、人工兜底率。前两个决定体验后两个决定这个项目能不能长期活着。常见失败模式有三类检索召回不准导致答非所问这时先看切片和向量模型别急着换大模型输出不稳定导致结构化解析失败改用工具调用或 JSON 模式成本失控多半是 system 提示词太长或者思维链没做截断。6. 效果验证与调优把主观感受换成可复现的数字调优最怕凭感觉。我一般先固化一个 100 到 200 条的小评测集每条包含问题、标准答案要点和是否可回答的标记每次改提示词或换模型都跑一遍。import json, statistics def evaluate(client, cases, modeldeepseek-chat): hit, latencies 0, [] for c in cases: t0 time.time() r client.chat.completions.create( modelmodel, messages[{role: user, content: c[q]}], temperature0.2, max_tokens512, ) latencies.append(time.time() - t0) ans r.choices[0].message.content # 要点覆盖式打分比整句匹配鲁棒 hit all(k in ans for k in c[keys]) return { accuracy: hit / len(cases), p95_latency: statistics.quantiles(latencies, n20)[18], }逻辑说明用要点覆盖率代替字符串完全匹配避免模型换个说法就被判错。参数说明评测时固定temperature否则同一条数据两次结果不可比p95_latency取 20 分位的第 19 个值样本量太小时改用max()更稳妥。延迟分解也值得做一次把请求耗时拆成排队、首 token、生成三段。排队时间长说明并发配额或--gpu-memory-utilization需要调首 token 慢通常是提示词太长开前缀缓存能缓解生成阶段慢则和输出长度正相关考虑限制思维链长度或者在业务侧做答案裁剪。一个容易被忽略的技巧是缓存。把(模型, 提示词模板, 问题)哈希后写入 Redis命中直接返回对报表生成、固定问答这类重复率高的场景能省掉相当一部分调用量。缓存要设过期时间模型或提示词一变就整体失效否则会拿旧答案糊弄用户。本文还有配套的精品资源点击获取