简介《DeepSeek大模型介绍与展望.pptx》是一份面向人工智能学习者、技术研发人员及产品决策者的主题演示文稿用于系统梳理DeepSeek大模型的技术脉络、落地场景与未来走向。内容围绕模型架构、多层神经网络与模块化设计、海量训练数据和自监督学习展开并延伸到自然语言处理、计算机视觉、多模态交互等典型应用。包体为1个pptx文件压缩包约24.07MB结构按引言、模型概述、应用场景、技术创新、挑战与解决方案、未来趋势、结论与展望组织便于按章节检索和二次引用。已有209人学习下载说明其在入门科普与团队分享中具有一定参考价值。通过这份演示文稿读者可快速建立从技术原理到行业应用的认知框架理解模型压缩与加速、可解释性与安全性、数据隐私保护等关键议题也可将其作为课程展示、技术汇报或方案讨论的素材节省资料搜集与结构整理时间。1. 从一份 DeepSeek 大模型介绍与展望.pptx 说起季度技术分享前一晚你把「DeepSeek大模型介绍与展望.pptx」的目录写成三行模型能力、落地方式、未来方向。评审时第一个问题往往不是「MoE 是什么意思」而是「我们自己的机器能不能跑起来跑起来之后怎么接进现有系统预算大概多少」。PPT 只是壳被追问的全是壳下面的工程细节。这个标题背后挂着三条不同的工作线一是模型家族怎么分、总参数与激活参数怎么换算成显存二是本地部署与 API 调用怎么选、命令和参数怎么写三是微调、评估和把这些结论压回一张幻灯片。只讲概念的分享会被追问到哑口只会敲命令的人讲不清取舍两头都要能对上。适合读这篇的人要在团队内部做 DeepSeek 技术分享的工程师、要给出 GPU 预算的架构角色、准备把大模型接进业务系统的后端开发。下面的顺序按「先能跑通、再能讲清」推进。2. DeepSeek 模型家族的选型逻辑架构图那一页怎么讲才站得住2.1 MoE 的稀疏激活是整页 PPT 里最值钱的一句话DeepSeek 系列里V3 这一类是典型的混合专家MoE结构总参数量很大但每个 token 在前向时只路由到少数几个专家其余专家不参与计算。公开资料里常见的量级是总参数 671B、单 token 激活约 37B具体数值以官方模型卡为准。这个结构带来一个非常反直觉的结论——显存看总参数算力看激活参数。把它翻译成分享时的说法权重必须全部放进显存或主存所以 671B 量级的模型按 FP8 存也要几百 GB单卡装不下但每生成一个 token 真正参与矩阵乘的只有激活的那部分所以在算力账上它更接近一个 30B 级稠密模型的表现。这一页讲清楚了后面「为什么要八卡」「为什么吞吐比想象中高」就都有了根。另一条线是推理模型。R1 这类模型会在正式回答前先输出一段较长的推理过程同样一个问题输出 token 数可能是通用对话模型的数倍。做容量规划时按「输出 2k4k token」估算用短问答的数字去推并发量上线后一定被打脸。2.2 参数量换算显存一张能直接抄进 PPT 的粗估表显存估算的起点是一个乘法权重显存 ≈ 参数量 × 每个参数的字节数。FP8 约 1 字节/参数BF16 约 2 字节4bit 量化约 0.5 字节。算完权重还要加 KV cache 和运行时开销通常再留 10%20% 余量。模型量级权重精度权重显存粗估典型硬件形态671B 级 MoEFP8≈ 670 GB8 卡及以上张量并行671B 级 MoEBF16≈ 1.3 TB一般不做全精度部署30B 级稠密/蒸馏BF16≈ 60 GB单机 24 卡7B14B 级4bit 量化≈ 510 GB单张消费级卡可试跑KV cache 的估算公式是2 × 层数 × KV 头数 × head_dim × 序列长度 × batch × 字节数。工程上不必手算到底抓住两个杠杆就够——序列长度和并发数它们和 KV cache 是线性关系。所以显存告急时先砍max-model-len再考虑降并发最后才动量化。注意上面这些数字是量级粗估用来做预算和排期的沟通不要当成采购依据。真实可用显存还受并行策略、CUDA graph、框架预留影响。2.3 本地部署还是 API 调用把决策写成一页以下是常见的判断顺序从第一条开始往下筛命中哪条基本就定了数据是否允许出内网。不允许出直接走本地部署后面的吞吐问题只能靠加卡或量化解决。峰值 QPS 是否可预测且不高比如低于每秒几次。可预测的小流量API 调用的总成本通常低于自建。是否需要长时间、大批量的离线处理数据清洗、批量知识抽取。这种场景对延迟不敏感本地部署的边际成本更低。是否需要频繁换模型、做 A/B。API 换模型只改一个字符串本地换模型要重新下权重、重新起服务。是否要做微调。微调必须拿到权重本地部署是前置条件。最常见的落地形态其实是混合生产主链路走 API评测、微调、批量任务走本地。PPT 里用一张两栏表格把这个结论摆出来比任何形容词都有说服力。3. 本地部署 DeepSeekvLLM 起服务与轻量试跑的最小命令3.1 上线前先把显存、磁盘和并发算清楚部署不是敲一条命令那么简单先回答三个问题。磁盘上要给权重留足空间FP8 的 671B 级权重加上 tokenizer、配置文件和临时文件几百 GB 是常态下载和加载都会拉长时间磁盘 IO 差会直接表现为「启动卡住」。显存方面按上一节的公式算出权重占用后剩余显存全部留给 KV cache这决定了能撑多长上下文、多少并发。并发要分两个口径看。一是吞吐即每秒能产出多少 token跟算力绑定二是并发请求数跟 KV cache 绑定。同一台机器上把max-model-len从 32768 提到 65536并发能力大致砍半。这个取舍在压测里必须先跑出来不然分享时给出的数字经不起问。3.2 用 vLLM 启动一个 OpenAI 兼容的 DeepSeek 服务vLLM 是当前最常见的本地推理方案优势是吞吐高、自带 OpenAI 兼容接口客户端代码几乎不用改。# 8 卡起 DeepSeek-V3对外暴露 OpenAI 兼容接口 vllm serve deepseek-ai/DeepSeek-V3 \ --served-model-name deepseek-chat \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --trust-remote-code \ --port 8000几个参数的含义和调整方向--served-model-name对外暴露的模型名。客户端请求体里的model字段必须和它一致否则会收到模型不存在的错误。--tensor-parallel-size张量并行度一般等于参与计算的 GPU 数量。671B 级 MoE 通常从 8 卡起步卡越多通信开销占比越高。--max-model-len单请求最大上下文长度。它直接决定 KV cache 的预留量是显存不足时第一个该动的参数。--gpu-memory-utilization允许框架占用的显存比例0.850.92 之间调。调得越满KV cache 越大但留给运行时其他开销的余量越小。--trust-remote-code加载模型自带的建模代码。用官方权重时通常需要打开。服务起来后先做一次接口自检确认模型名和路由都对curl -s http://localhost:8000/v1/models | head -c 400返回里能看到deepseek-chat就说明服务通了。接着用一条最普通的对话请求验证链路curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:deepseek-chat,messages:[{role:user,content:用一句话解释 MoE}],max_tokens:128}3.3 用轻量运行时做第一轮冒烟测试不是每次都要上集群。分享演示、功能联调这类场景用轻量运行时拉一个蒸馏版或量化版几分钟就能跑起来。# 拉一个 7B 量级的蒸馏版做功能验证 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b 用三句话说明稀疏激活具体 tag 以运行时仓库里实际提供的为准。这一步的目标不是测性能而是确认 prompt 模板、输出格式、解析逻辑能不能对上。演示环境用轻量版本正式压测必须回到和线上一致的权重与精度否则数字没有参考意义。3.4 部署失败的排查顺序按报错信息往回找比盲目重装快得多显存不足先降--max-model-len再降--gpu-memory-utilization还不行就加卡或换量化版本。加载权重长时间无进展查磁盘 IO 和权重文件完整性多卡并行加载时还要看网络带宽。建模代码相关异常运行时框架版本和模型要求不匹配换官方推荐的镜像版本比逐个打补丁省事。端口通但请求返回 404路径写错注意要带/v1前缀。单次响应很慢但吞吐正常多半是max_tokens给太大或者命中了长思维链模型这是预期行为不是故障。4. DeepSeek API 调用从 curl 到 VSCode 里的补全接入4.1 用 curl 打通 deepseek api 如何调用的最小请求先用最小的请求体把认证和路由跑通别一上来就写 SDK 封装。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: 你是一名后端工程师回答控制在 200 字内}, {role: user, content: 解释一下 MoE 的稀疏激活} ], temperature: 0.3, stream: false }请求体里几个字段值得单独说model决定走通用对话还是推理模型两者计费和输出长度特性不同temperature在结构化抽取场景建议压到 0.10.3写文案时再往上调stream打开后是逐块返回适合做打字机效果但客户端要处理分块拼接和异常中断。具体模型名和计费口径以控制台文档为准。4.2 OpenAI SDK 与 VSCode 插件的接入差异绝大多数工具链走的是 OpenAI 兼容协议所以同一份代码换个base_url就能在本地和云端之间切换。import os from openai import OpenAI client OpenAI( api_keyos.environ[DEEPSEEK_API_KEY], # 指向本地 vLLM 时改成 http://localhost:8000/v1 base_urlhttps://api.deepseek.com, ) resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 给这段 SQL 加索引建议}], max_tokens512, ) print(resp.choices[0].message.content)VSCode 里的编码助手接入走的是同一个思路只是配置项换成了界面表单协议选 OpenAI Compatible填 API 地址、密钥、模型名三项。容易踩的坑是地址结尾——有的工具要求带/v1有的会自动补两边都试一次比查文档快。本地部署时把地址指向本机端口就不需要密钥字段里填真值随便填一个非空字符串即可。4.3 大模型并发请求与上下文长度上限的处理方式并发请求最容易出的问题是限流返回和超时用信号量把并发压在可控范围内比写完再重试要省事。import asyncio from openai import AsyncOpenAI client AsyncOpenAI(api_key..., base_urlhttps://api.deepseek.com) sem asyncio.Semaphore(8) # 同时最多 8 个在途请求 async def ask(q: str) - str: async with sem: r await client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: q}], max_tokens512, # 限制输出防止个别长回答拖垮整体吞吐 ) return r.choices[0].message.content并发上限不是拍脑袋定的先从小并发往上压观察延迟曲线的拐点拐点之后再加并发只会让平均延迟变差。上下文长度上限则是另一个维度的坑多轮会话累积到窗口边界后要么被截断导致模型「忘记」前文要么直接拒绝。三种常见处理方式的取舍如下。策略实现成本适用场景主要代价滑动窗口截断低单轮问答、日志分析早期信息丢失历史摘要压缩中长会话助手多一次模型调用向量检索外挂高知识库问答需要维护索引与召回质量实际项目里更常见的是组合近期对话原样保留超出部分做摘要与业务知识相关的走检索注入。分享时把这张表放在「上下文管理」那一页比堆概念有用得多。5. 大模型微调实战用 Llama Factory 给 DeepSeek 蒸馏版加一层业务能力5.1 数据决定上限指令数据的三种构造方式微调的效果九成来自数据训练脚本反而是最容易复制的部分。LLaMA-Factory 支持 alpaca 和 sharegpt 两类格式alpaca 格式对新手最友好[ { instruction: 根据工单描述给出分类和优先级, input: 打印机连不上整个部门都无法打印, output: 分类硬件/打印优先级P2建议动作检查打印服务队列是否卡死 } ]数据来源通常是三条路一是把线上已有的工单、客服记录做清洗和脱敏直接转成指令对二是用强模型对原始文档批量生成问答再人工抽检三是针对模型当前的错误输出做定向补充也就是「错哪补哪」。第三条路见效最快也是迭代几轮之后唯一还有增量的一条。样本量上几百到几千条高质量数据在格式对齐类任务里的收益远大于几万条低质数据。5.2 LoRA 微调的训练命令与必调参数单卡、7B 量级蒸馏版的 LoRA 微调在 LLaMA-Factory 里用一份 YAML 加一条命令就能跑起来。# ds_lora.yaml model_name_or_path: deepseek-ai/DeepSeek-R1-Distill-Qwen-7B stage: sft do_train: true finetuning_type: lora lora_rank: 16 lora_target: all dataset: ticket_sft template: deepseek cutoff_len: 4096 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 1.0e-4 num_train_epochs: 3 output_dir: saves/ds_lorallamafactory-cli train ds_lora.yaml参数里最该关注的几个lora_rank决定可训练参数量格式对齐类任务 816 通常够用超过 32 收益递减还更容易过拟合lora_target设为all表示对所有线性层注入显存紧张时再收敛到注意力层cutoff_len要覆盖业务里最长的样本截断掉的往往是关键信息learning_rate在 1e-4 到 2e-4 之间是 LoRA 的常用区间比全参微调大一两个数量级num_train_epochs从 3 起步看验证集表现再增减。多卡时配合--deepspeed或 FSDP 配置批大小和梯度累积要按卡数重新算别直接照抄单卡参数。5.3 验收loss 降下来不等于能用训练日志里 loss 一路下降是最容易骗人的信号。有效的验收至少跑三件事。第一件是格式合规率把模型输出按业务解析器过一遍统计能被正确解析的比例这个指标比 loss 更接近线上体验。import json, re def parse_ok(text: str) - bool: 业务侧解析器要求输出里含 分类 和 优先级 两个键 return bool(re.search(r分类, text) and re.search(r优先级, text)) # 在固定测试集上跑一遍得到可比较的百分比 score sum(parse_ok(t) for t in outputs) / len(outputs) print(f格式合规率: {score:.2%})第二件是回归测试用微调前的那批固定题目再跑一遍确认通用能力没有明显退化。第三件是抽检几十条真实样本人工看输出是否符合业务口径。这三件事做完才有资格把模型放进线上灰度。注意微调只改行为、不改知识。想要模型掌握新的事实性知识检索增强的性价比通常高于继续堆训练数据。6. 把结论落回 pptx用 DeepSeek 生成大纲再自动排版的技巧6.1 用一次结构化请求产出可解析的大纲与其手敲目录不如让模型先出结构化大纲再用脚本渲染。关键是要求返回 JSON并在 prompt 里出现「JSON」字样同时给出字段约束和页数上限。import json from openai import OpenAI client OpenAI(api_key..., base_urlhttps://api.deepseek.com) PROMPT 你是资深架构师。为一次 30 分钟的技术分享生成大纲主题是 DeepSeek 大模型的介绍与展望。 要求总页数不超过 12 页每页 3~5 个要点每个要点不超过 24 个字必须包含模型架构、部署选型、调用接入、微调与评估四部分。 严格输出 JSON结构为 {title: str, subtitle: str, pages: [{heading: str, bullets: [str]}]} resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: PROMPT}], response_format{type: json_object}, ) outline json.loads(resp.choices[0].message.content)要点字数上限这一条不能省否则模型会写出长句落到幻灯片上直接溢出换行。生成一次不满意就改约束重跑比手工删改快。6.2 用 python-pptx 生成页面与图表占位拿到 JSON 之后渲染只剩十几行代码。下面的脚本把标题页和内容页都生成出来正文页统一走「标题 项目符号」版式。from pptx import Presentation from pptx.util import Pt prs Presentation() # 封面页 cover prs.slides.add_slide(prs.slide_layouts[0]) cover.shapes.title.text outline[title] cover.placeholders[1].text outline[subtitle] # 内容页 for page in outline[pages]: s prs.slides.add_slide(prs.slide_layouts[1]) s.shapes.title.text page[heading] tf s.placeholders[1].text_frame tf.text page[bullets][0] for b in page[bullets][1:]: p tf.add_paragraph() p.text b p.font.size Pt(18) # 统一缩到 18pt避免长要点溢出 prs.save(DeepSeek大模型介绍与展望.pptx)显存换算表、并发压测曲线这类图不适合让脚本画正确做法是在对应页留一个占位文本框标注「图显存估算对照表见第 2 章」导出后手工替换。这样脚本只负责结构和文字图形部分保留人工审美。6.3 交付前跑一遍自检生成完不等于能用。按顺序过三关先确认每一页的要点数与页数符合预期超出的删掉而不是缩小字号再检查专业名词的大小写和写法是否统一比如 MoE、KV cache、LoRA 这几个词前后写法要一致最后用放映模式从头翻一遍重点看长要点有没有撞到页面下沿。到这一步prs.save()产出的文件名和标题里的名字对上整份可交付的 pptx 就有了剩下的时间留给讲稿本身。本文还有配套的精品资源点击获取 DeepSeek大模型落地全链路：选型、部署、API调用与LoRA微调
简介《DeepSeek大模型介绍与展望.pptx》是一份面向人工智能学习者、技术研发人员及产品决策者的主题演示文稿用于系统梳理DeepSeek大模型的技术脉络、落地场景与未来走向。内容围绕模型架构、多层神经网络与模块化设计、海量训练数据和自监督学习展开并延伸到自然语言处理、计算机视觉、多模态交互等典型应用。包体为1个pptx文件压缩包约24.07MB结构按引言、模型概述、应用场景、技术创新、挑战与解决方案、未来趋势、结论与展望组织便于按章节检索和二次引用。已有209人学习下载说明其在入门科普与团队分享中具有一定参考价值。通过这份演示文稿读者可快速建立从技术原理到行业应用的认知框架理解模型压缩与加速、可解释性与安全性、数据隐私保护等关键议题也可将其作为课程展示、技术汇报或方案讨论的素材节省资料搜集与结构整理时间。1. 从一份 DeepSeek 大模型介绍与展望.pptx 说起季度技术分享前一晚你把「DeepSeek大模型介绍与展望.pptx」的目录写成三行模型能力、落地方式、未来方向。评审时第一个问题往往不是「MoE 是什么意思」而是「我们自己的机器能不能跑起来跑起来之后怎么接进现有系统预算大概多少」。PPT 只是壳被追问的全是壳下面的工程细节。这个标题背后挂着三条不同的工作线一是模型家族怎么分、总参数与激活参数怎么换算成显存二是本地部署与 API 调用怎么选、命令和参数怎么写三是微调、评估和把这些结论压回一张幻灯片。只讲概念的分享会被追问到哑口只会敲命令的人讲不清取舍两头都要能对上。适合读这篇的人要在团队内部做 DeepSeek 技术分享的工程师、要给出 GPU 预算的架构角色、准备把大模型接进业务系统的后端开发。下面的顺序按「先能跑通、再能讲清」推进。2. DeepSeek 模型家族的选型逻辑架构图那一页怎么讲才站得住2.1 MoE 的稀疏激活是整页 PPT 里最值钱的一句话DeepSeek 系列里V3 这一类是典型的混合专家MoE结构总参数量很大但每个 token 在前向时只路由到少数几个专家其余专家不参与计算。公开资料里常见的量级是总参数 671B、单 token 激活约 37B具体数值以官方模型卡为准。这个结构带来一个非常反直觉的结论——显存看总参数算力看激活参数。把它翻译成分享时的说法权重必须全部放进显存或主存所以 671B 量级的模型按 FP8 存也要几百 GB单卡装不下但每生成一个 token 真正参与矩阵乘的只有激活的那部分所以在算力账上它更接近一个 30B 级稠密模型的表现。这一页讲清楚了后面「为什么要八卡」「为什么吞吐比想象中高」就都有了根。另一条线是推理模型。R1 这类模型会在正式回答前先输出一段较长的推理过程同样一个问题输出 token 数可能是通用对话模型的数倍。做容量规划时按「输出 2k4k token」估算用短问答的数字去推并发量上线后一定被打脸。2.2 参数量换算显存一张能直接抄进 PPT 的粗估表显存估算的起点是一个乘法权重显存 ≈ 参数量 × 每个参数的字节数。FP8 约 1 字节/参数BF16 约 2 字节4bit 量化约 0.5 字节。算完权重还要加 KV cache 和运行时开销通常再留 10%20% 余量。模型量级权重精度权重显存粗估典型硬件形态671B 级 MoEFP8≈ 670 GB8 卡及以上张量并行671B 级 MoEBF16≈ 1.3 TB一般不做全精度部署30B 级稠密/蒸馏BF16≈ 60 GB单机 24 卡7B14B 级4bit 量化≈ 510 GB单张消费级卡可试跑KV cache 的估算公式是2 × 层数 × KV 头数 × head_dim × 序列长度 × batch × 字节数。工程上不必手算到底抓住两个杠杆就够——序列长度和并发数它们和 KV cache 是线性关系。所以显存告急时先砍max-model-len再考虑降并发最后才动量化。注意上面这些数字是量级粗估用来做预算和排期的沟通不要当成采购依据。真实可用显存还受并行策略、CUDA graph、框架预留影响。2.3 本地部署还是 API 调用把决策写成一页以下是常见的判断顺序从第一条开始往下筛命中哪条基本就定了数据是否允许出内网。不允许出直接走本地部署后面的吞吐问题只能靠加卡或量化解决。峰值 QPS 是否可预测且不高比如低于每秒几次。可预测的小流量API 调用的总成本通常低于自建。是否需要长时间、大批量的离线处理数据清洗、批量知识抽取。这种场景对延迟不敏感本地部署的边际成本更低。是否需要频繁换模型、做 A/B。API 换模型只改一个字符串本地换模型要重新下权重、重新起服务。是否要做微调。微调必须拿到权重本地部署是前置条件。最常见的落地形态其实是混合生产主链路走 API评测、微调、批量任务走本地。PPT 里用一张两栏表格把这个结论摆出来比任何形容词都有说服力。3. 本地部署 DeepSeekvLLM 起服务与轻量试跑的最小命令3.1 上线前先把显存、磁盘和并发算清楚部署不是敲一条命令那么简单先回答三个问题。磁盘上要给权重留足空间FP8 的 671B 级权重加上 tokenizer、配置文件和临时文件几百 GB 是常态下载和加载都会拉长时间磁盘 IO 差会直接表现为「启动卡住」。显存方面按上一节的公式算出权重占用后剩余显存全部留给 KV cache这决定了能撑多长上下文、多少并发。并发要分两个口径看。一是吞吐即每秒能产出多少 token跟算力绑定二是并发请求数跟 KV cache 绑定。同一台机器上把max-model-len从 32768 提到 65536并发能力大致砍半。这个取舍在压测里必须先跑出来不然分享时给出的数字经不起问。3.2 用 vLLM 启动一个 OpenAI 兼容的 DeepSeek 服务vLLM 是当前最常见的本地推理方案优势是吞吐高、自带 OpenAI 兼容接口客户端代码几乎不用改。# 8 卡起 DeepSeek-V3对外暴露 OpenAI 兼容接口 vllm serve deepseek-ai/DeepSeek-V3 \ --served-model-name deepseek-chat \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --trust-remote-code \ --port 8000几个参数的含义和调整方向--served-model-name对外暴露的模型名。客户端请求体里的model字段必须和它一致否则会收到模型不存在的错误。--tensor-parallel-size张量并行度一般等于参与计算的 GPU 数量。671B 级 MoE 通常从 8 卡起步卡越多通信开销占比越高。--max-model-len单请求最大上下文长度。它直接决定 KV cache 的预留量是显存不足时第一个该动的参数。--gpu-memory-utilization允许框架占用的显存比例0.850.92 之间调。调得越满KV cache 越大但留给运行时其他开销的余量越小。--trust-remote-code加载模型自带的建模代码。用官方权重时通常需要打开。服务起来后先做一次接口自检确认模型名和路由都对curl -s http://localhost:8000/v1/models | head -c 400返回里能看到deepseek-chat就说明服务通了。接着用一条最普通的对话请求验证链路curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:deepseek-chat,messages:[{role:user,content:用一句话解释 MoE}],max_tokens:128}3.3 用轻量运行时做第一轮冒烟测试不是每次都要上集群。分享演示、功能联调这类场景用轻量运行时拉一个蒸馏版或量化版几分钟就能跑起来。# 拉一个 7B 量级的蒸馏版做功能验证 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b 用三句话说明稀疏激活具体 tag 以运行时仓库里实际提供的为准。这一步的目标不是测性能而是确认 prompt 模板、输出格式、解析逻辑能不能对上。演示环境用轻量版本正式压测必须回到和线上一致的权重与精度否则数字没有参考意义。3.4 部署失败的排查顺序按报错信息往回找比盲目重装快得多显存不足先降--max-model-len再降--gpu-memory-utilization还不行就加卡或换量化版本。加载权重长时间无进展查磁盘 IO 和权重文件完整性多卡并行加载时还要看网络带宽。建模代码相关异常运行时框架版本和模型要求不匹配换官方推荐的镜像版本比逐个打补丁省事。端口通但请求返回 404路径写错注意要带/v1前缀。单次响应很慢但吞吐正常多半是max_tokens给太大或者命中了长思维链模型这是预期行为不是故障。4. DeepSeek API 调用从 curl 到 VSCode 里的补全接入4.1 用 curl 打通 deepseek api 如何调用的最小请求先用最小的请求体把认证和路由跑通别一上来就写 SDK 封装。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: 你是一名后端工程师回答控制在 200 字内}, {role: user, content: 解释一下 MoE 的稀疏激活} ], temperature: 0.3, stream: false }请求体里几个字段值得单独说model决定走通用对话还是推理模型两者计费和输出长度特性不同temperature在结构化抽取场景建议压到 0.10.3写文案时再往上调stream打开后是逐块返回适合做打字机效果但客户端要处理分块拼接和异常中断。具体模型名和计费口径以控制台文档为准。4.2 OpenAI SDK 与 VSCode 插件的接入差异绝大多数工具链走的是 OpenAI 兼容协议所以同一份代码换个base_url就能在本地和云端之间切换。import os from openai import OpenAI client OpenAI( api_keyos.environ[DEEPSEEK_API_KEY], # 指向本地 vLLM 时改成 http://localhost:8000/v1 base_urlhttps://api.deepseek.com, ) resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 给这段 SQL 加索引建议}], max_tokens512, ) print(resp.choices[0].message.content)VSCode 里的编码助手接入走的是同一个思路只是配置项换成了界面表单协议选 OpenAI Compatible填 API 地址、密钥、模型名三项。容易踩的坑是地址结尾——有的工具要求带/v1有的会自动补两边都试一次比查文档快。本地部署时把地址指向本机端口就不需要密钥字段里填真值随便填一个非空字符串即可。4.3 大模型并发请求与上下文长度上限的处理方式并发请求最容易出的问题是限流返回和超时用信号量把并发压在可控范围内比写完再重试要省事。import asyncio from openai import AsyncOpenAI client AsyncOpenAI(api_key..., base_urlhttps://api.deepseek.com) sem asyncio.Semaphore(8) # 同时最多 8 个在途请求 async def ask(q: str) - str: async with sem: r await client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: q}], max_tokens512, # 限制输出防止个别长回答拖垮整体吞吐 ) return r.choices[0].message.content并发上限不是拍脑袋定的先从小并发往上压观察延迟曲线的拐点拐点之后再加并发只会让平均延迟变差。上下文长度上限则是另一个维度的坑多轮会话累积到窗口边界后要么被截断导致模型「忘记」前文要么直接拒绝。三种常见处理方式的取舍如下。策略实现成本适用场景主要代价滑动窗口截断低单轮问答、日志分析早期信息丢失历史摘要压缩中长会话助手多一次模型调用向量检索外挂高知识库问答需要维护索引与召回质量实际项目里更常见的是组合近期对话原样保留超出部分做摘要与业务知识相关的走检索注入。分享时把这张表放在「上下文管理」那一页比堆概念有用得多。5. 大模型微调实战用 Llama Factory 给 DeepSeek 蒸馏版加一层业务能力5.1 数据决定上限指令数据的三种构造方式微调的效果九成来自数据训练脚本反而是最容易复制的部分。LLaMA-Factory 支持 alpaca 和 sharegpt 两类格式alpaca 格式对新手最友好[ { instruction: 根据工单描述给出分类和优先级, input: 打印机连不上整个部门都无法打印, output: 分类硬件/打印优先级P2建议动作检查打印服务队列是否卡死 } ]数据来源通常是三条路一是把线上已有的工单、客服记录做清洗和脱敏直接转成指令对二是用强模型对原始文档批量生成问答再人工抽检三是针对模型当前的错误输出做定向补充也就是「错哪补哪」。第三条路见效最快也是迭代几轮之后唯一还有增量的一条。样本量上几百到几千条高质量数据在格式对齐类任务里的收益远大于几万条低质数据。5.2 LoRA 微调的训练命令与必调参数单卡、7B 量级蒸馏版的 LoRA 微调在 LLaMA-Factory 里用一份 YAML 加一条命令就能跑起来。# ds_lora.yaml model_name_or_path: deepseek-ai/DeepSeek-R1-Distill-Qwen-7B stage: sft do_train: true finetuning_type: lora lora_rank: 16 lora_target: all dataset: ticket_sft template: deepseek cutoff_len: 4096 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 1.0e-4 num_train_epochs: 3 output_dir: saves/ds_lorallamafactory-cli train ds_lora.yaml参数里最该关注的几个lora_rank决定可训练参数量格式对齐类任务 816 通常够用超过 32 收益递减还更容易过拟合lora_target设为all表示对所有线性层注入显存紧张时再收敛到注意力层cutoff_len要覆盖业务里最长的样本截断掉的往往是关键信息learning_rate在 1e-4 到 2e-4 之间是 LoRA 的常用区间比全参微调大一两个数量级num_train_epochs从 3 起步看验证集表现再增减。多卡时配合--deepspeed或 FSDP 配置批大小和梯度累积要按卡数重新算别直接照抄单卡参数。5.3 验收loss 降下来不等于能用训练日志里 loss 一路下降是最容易骗人的信号。有效的验收至少跑三件事。第一件是格式合规率把模型输出按业务解析器过一遍统计能被正确解析的比例这个指标比 loss 更接近线上体验。import json, re def parse_ok(text: str) - bool: 业务侧解析器要求输出里含 分类 和 优先级 两个键 return bool(re.search(r分类, text) and re.search(r优先级, text)) # 在固定测试集上跑一遍得到可比较的百分比 score sum(parse_ok(t) for t in outputs) / len(outputs) print(f格式合规率: {score:.2%})第二件是回归测试用微调前的那批固定题目再跑一遍确认通用能力没有明显退化。第三件是抽检几十条真实样本人工看输出是否符合业务口径。这三件事做完才有资格把模型放进线上灰度。注意微调只改行为、不改知识。想要模型掌握新的事实性知识检索增强的性价比通常高于继续堆训练数据。6. 把结论落回 pptx用 DeepSeek 生成大纲再自动排版的技巧6.1 用一次结构化请求产出可解析的大纲与其手敲目录不如让模型先出结构化大纲再用脚本渲染。关键是要求返回 JSON并在 prompt 里出现「JSON」字样同时给出字段约束和页数上限。import json from openai import OpenAI client OpenAI(api_key..., base_urlhttps://api.deepseek.com) PROMPT 你是资深架构师。为一次 30 分钟的技术分享生成大纲主题是 DeepSeek 大模型的介绍与展望。 要求总页数不超过 12 页每页 3~5 个要点每个要点不超过 24 个字必须包含模型架构、部署选型、调用接入、微调与评估四部分。 严格输出 JSON结构为 {title: str, subtitle: str, pages: [{heading: str, bullets: [str]}]} resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: PROMPT}], response_format{type: json_object}, ) outline json.loads(resp.choices[0].message.content)要点字数上限这一条不能省否则模型会写出长句落到幻灯片上直接溢出换行。生成一次不满意就改约束重跑比手工删改快。6.2 用 python-pptx 生成页面与图表占位拿到 JSON 之后渲染只剩十几行代码。下面的脚本把标题页和内容页都生成出来正文页统一走「标题 项目符号」版式。from pptx import Presentation from pptx.util import Pt prs Presentation() # 封面页 cover prs.slides.add_slide(prs.slide_layouts[0]) cover.shapes.title.text outline[title] cover.placeholders[1].text outline[subtitle] # 内容页 for page in outline[pages]: s prs.slides.add_slide(prs.slide_layouts[1]) s.shapes.title.text page[heading] tf s.placeholders[1].text_frame tf.text page[bullets][0] for b in page[bullets][1:]: p tf.add_paragraph() p.text b p.font.size Pt(18) # 统一缩到 18pt避免长要点溢出 prs.save(DeepSeek大模型介绍与展望.pptx)显存换算表、并发压测曲线这类图不适合让脚本画正确做法是在对应页留一个占位文本框标注「图显存估算对照表见第 2 章」导出后手工替换。这样脚本只负责结构和文字图形部分保留人工审美。6.3 交付前跑一遍自检生成完不等于能用。按顺序过三关先确认每一页的要点数与页数符合预期超出的删掉而不是缩小字号再检查专业名词的大小写和写法是否统一比如 MoE、KV cache、LoRA 这几个词前后写法要一致最后用放映模式从头翻一遍重点看长要点有没有撞到页面下沿。到这一步prs.save()产出的文件名和标题里的名字对上整份可交付的 pptx 就有了剩下的时间留给讲稿本身。本文还有配套的精品资源点击获取