拓冰网站定制 
简介这份173页演示文稿由厦门大学大数据教学团队出品是一份大模型工具实用手册围绕DeepSeek等主流生成式人工智能工具展开适合希望快速上手文本、图片、语音、视频生成以及辅助编程的初学者和职场人士。内容从生成式人工智能的核心概念与核心技术讲起逐步拆解文本、图片、语音、视频四类应用实践并专门介绍其在辅助编程和人工智能搜索中的落地方法结合大量案例页面结构清晰、章节递进合理。资源为单个PPTX文件共1个文件压缩包大小8.47MB可直接用办公软件打开便于按章节学习、做笔记或二次编辑。目前已有70人学习下载适合需要系统了解DeepSeek等大模型工具操作技巧的学习者收藏。1. 翻完173页DeepSeek等大模型工具使用手册从选型到微调的全链路拆解前阵子同事把这份173页的《DeepSeek等大模型工具使用手册》PPT丢给我问能不能照着给团队落地。我花了一个晚上翻完又拿周末把里面涉及的部署链路自己跑了一遍。结论很直接这不是那种“看完即会”的科普PPT而是一份能指导实操的施工图前提是你知道怎么读。它适合两类人一类是已经调过官网API、想搞清楚背后参数边界和成本逻辑的开发者另一类是准备私有化部署、需要快速给团队做出选型和技术方案的工程师。如果你只是顺手搜一下DeepSeek是什么这份手册对你可能偏长但如果你真要把它接进业务按我下面的顺序读能省掉不少试错时间。2. 选型与参数边界搞懂参数量、上下文和量化再动手2.1 参数量先看显存再看能力手册里大概率会有一张模型对比表。别跳过它直接往下翻因为后面所有部署命令都依赖你在这张表里做的选择。DeepSeek系列从轻量到重量级覆盖多个档位参数量直接决定显存门槛。7B做INT4量化后大约需要6到8GB显存13B需要12GB左右70B即使量化完也要40GB以上。单张3090还是双卡A100在这里就决定了你能跑哪个模型。我遇到过不止一个“模型下好了机器跑不动”的翻车案例问题都出在选型时没看显存。很多人觉得参数量越大越好实际工程里这个判断要反过来先看你手里有什么硬件再决定模型档位。业务是代码补全、摘要生成7B或13B完全够要处理复杂推理、长链路Agent任务才需要考虑70B。下表是通用参考按这个范围选一般不会出大错。参数量量化后显存参考适配场景7B6-8 GB代码补全、摘要、普通对话13B12-16 GB复杂指令、中等推理70B40-70 GB高难度推理、私有化生产选型时还有一个容易被忽略的点同尺寸模型的不同版本能力侧重可能完全不同。拿DeepSeek来说对话版和推理版在同样的7B规模下一个擅长多轮交互一个擅长分步思考。手册里如果区分了这两种角色务必按业务类型选不要只看参数量。我一般会把候选模型放进同一份测试集里跑一轮固定temperature和上下文看实际输出再定比对着benchmark数字猜靠谱得多。2.2 上下文长度最容易被忽略的显存杀手上下文长度是本地部署里最隐蔽的坑。很多人看到模型支持8192就直接拉满结果一启动就OOM还以为是显存不够。Transformer的显存开销随序列长度近似平方增长同样一个模型上下文从2048开到8192显存占用可能翻倍不止。手册里如果给了不同上下文长度对应的显存参考表那一页值得截图存下来。我给自己定过一条规矩上下文按业务实际峰值长度设定不按模型上限设定。比如做客服问答单轮输入输出加起来通常不会超过1500 token那就设2048留一点余量即可。处理私有文档时优先用RAG把长文切片再检索而不是把整篇文档塞进上下文。显存是一方面更重要的是模型在超长上下文里的注意力会涣散输出质量反而下降。RAG的思路是把100页PDF切成若干块每次只把和问题相关的片段拼进输入既控制token成本也避免模型“读着读着忘了前面”。日常估算token时可以按汉字约1.5到2个token来粗算。一段500字的商品说明大概需要800到1000 token。如果你用的是Python直接拿tokenizer库做精确统计更稳妥from transformers import AutoTokenizer tk AutoTokenizer.from_pretrained(deepseek-ai/DeepSeek-V2-Lite) text 这段文本用来估算实际token数量 print(len(tk.encode(text)))这段代码的作用很简单加载对应模型的tokenizer把一段真实业务文本转成token后数个数。注意这里用的是V2-Lite如果你的模型版本不同要改成对应的模型名否则tokenizer不一致会导致估算偏差。2.3 量化格式GGUF、GPTQ、AWQ怎么选量化是本地部署绕不开的环节。同一份模型权重不量化的FP16版本和量化后的INT4版本显存占用差出一倍多但在多数生成任务里效果差距小于百分之五。真正丢分的场景集中在数学计算和长文本推理上普通对话、摘要、信息抽取基本无感。量化格式的选择要和推理框架匹配这是很多人没注意到的。本地轻量跑用GGUF配Ollama最省事Q4_K_M是通用起步档要搭高并发服务端vLLM对GPTQ和AWQ支持更完整。经验是同一个模型不要反复换量化版本做评测。不同量化方式对结果的扰动很容易被误判成模型能力差异你花半天对比最后发现是量化格式不同导致的纯属浪费精力。真要做对比固定三个变量量化格式、上下文长度、测试用例集。只有这三项完全一致跑出来的差异才能归因到模型本身。手册里这部分可能被写成“模型导出”或“格式转换”实操时不要因为名字不起眼就跳过部署方案合不合理很大程度上取决于这里的格式选择。3. 本地部署实操Ollama跑通vLLM接生产3.1 环境准备与Ollama最小路径拿到手册先别急着上分布式部署。第一步永远是单机跑通。Ollama是本地启动大模型最省事的工具装好之后两个命令就能拉起一个能对话的模型服务# 拉取7B对话模型首次会下载数GB权重耗时取决于网络 ollama pull deepseek-r1:7b # 启动服务默认监听127.0.0.1:11434 ollama serve第一次执行ollama pull时如果进度条一直停在某个百分比不动先确认网络状态问一下自己是不是没有配置镜像源。Ollama默认从官方源拉取权重网络波动大时很容易中断。这个问题在第5章避坑部分我会展开说这里先记住ollama serve是前台阻塞进程窗口不要关另开一个终端执行ollama list查看已拉取的模型列表。服务起来之后可以用curl做一次最小验证确认接口真的通了curl http://127.0.0.1:11434/api/chat -d { model: deepseek-r1:7b, messages: [{role: user, content: 你好}], stream: false }这里stream: false表示等模型生成完整结果后一次性返回适合调试业务并发场景建议改成true走流式输出用户体验差别很大。Ollama做开发和单机演示足够但并发上来之后性能会成瓶颈生产环境我一般直接换vLLM。3.2 vLLM高并发部署与关键参数vLLM是目前生产环境最常见的部署框架核心优势是PagedAttention显存管理和高吞吐。装依赖时建议用Python 3.10以上版本避免一些兼容性问题pip install vllm启动服务的命令比Ollama多几个参数但每个参数都对应一类实际问题python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-V2-Lite \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000max-model-len决定了模型能接受的最大序列长度要和业务请求的输入输出总和匹配设置过大直接浪费显存gpu-memory-utilization表示显存利用率上限如果机器上还有别的进程建议调到0.7以下tensor-parallel-size是多卡并行时的张量并行度单卡就填1多卡时按GPU数量填。启动日志里出现Starting vLLM server并且没有报错说明进程起来了。这时在另一个窗口执行nvidia-smi确认显存占用正常情况下应该看到显存被加载的模型占据而不是满屏的0。3.3 OpenAI兼容接口一套代码跑本地和云端vLLM启动后默认监听8000端口对外暴露的是OpenAI兼容接口这意味着所有为OpenAI API写的代码改一下base_url和api_key就能切到本地模型。验证连通性时我习惯写个极简Python脚本from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY # 本地服务不校验key填任意非空字符串即可 ) resp client.chat.completions.create( modeldeepseek-ai/DeepSeek-V2-Lite, messages[{role: user, content: 用一句话说明大模型推理和训练的区别}], max_tokens256, temperature0.7 ) print(resp.choices[0].message.content)这段代码和调官方API唯一的区别就是第2行和第3行的地址与密钥。以后要切回云端只需要把base_url换成官方地址、api_key换成真实密钥业务代码一行都不用动。我所有的部署验证都走这套方式能最大限度降低切换成本。4. 接入业务链路API调用、微调数据与工具集成4.1 云端API调用温度、采样与超时的工程细节如果你不打算本地部署直接用云端API第一个要理解的是生成参数。temperature控制随机性调得越高输出越发散调得越低输出越发确定。做分类、实体抽取这类有标准答案的任务设0或0.1做文案生成、创意写作设0.7以上。还有一个容易踩的坑是max_tokens设太小比如设了128但回答需要200个token生成到一半被截断截断部分照样计费。一个规范的信息抽取调用长这样import os from openai import OpenAI client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com/v1 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是信息抽取助手只输出JSON不要多余解释。}, {role: user, content: 从这段话里抽取公司名称和所在行业输出JSON。} ], temperature0.1, max_tokens1024 ) print(resp.choices[0].message.content)注意api_key不要硬编码在代码里用环境变量读取否则一旦代码提交到公共仓库密钥就泄露了。系统提示词里明确约束输出格式能省掉不少后处理工作。这里我把temperature压到0.1就是为了让模型在抽取任务里少“发挥”。4.2 微调数据标注JSONL结构与样例质量手册里如果有数据标注章节核心无非是两种格式对话格式和纯文本补全格式。微调框架里最常见的对话格式是JSONL一行一个样本每个样本包含一组多轮对话。以LLaMA-Factory为例默认字段长这样{conversations: [{from: human, value: 请把这段产品文案压缩到20字以内}, {from: gpt, value: 轻便耐用性价比之选。}]} {conversations: [{from: human, value: 把这句话翻译成英文今天天气很好}, {from: gpt, value: The weather is nice today.}]}写标注样例时最忌讳只做模板复制。如果100条数据都是同一个句式微调出来的模型只会换词不会举一反三。覆盖边界情况比覆盖常见情况更重要遇到用户问“不知道”、用户给出非常规表述、用户要求多轮纠正这些都要单独标。数据质量差后面微调做得再精细也是白搭。不同框架对字段名的要求略有差异我一般会在动手前先确认目标框架识别的字段比如LLaMA-Factory用conversations有些框架用instruction和output。不确定时先在仓库的data目录里找一个官方示例比对着改字段名比翻文档快得多。4.3 工具链接入Dify、Codex一类工具的通用配置逻辑现在很多团队做RAG应用或Agent平台时用的都是Dify、Codex这类现成工具。接DeepSeek时很多人以为要装额外插件其实核心配置逻辑高度一致找到模型供应商配置页选“OpenAI-API-compatible”或类似选项填入Base URL和API Key然后测试连通性。本地部署模型时Base URL填http://localhost:11434/v1Ollama或http://localhost:8000/v1vLLM用云端API时填https://api.deepseek.com/v1。工具侧的模型名要和你部署时指定的模型名完全一致大小写和路径都不能错最常见的问题就是模型名填错导致报错模型不存在。这套逻辑在手册里通常被写在“第三方工具接入”那一节按图索骥十分钟就能配完。5. 避坑指南部署与调用里最常见的5个翻车现场5.1 模型拉不下来Ollama一直超时现象ollama pull跑到一半报错提示连接超时或下载失败重试几次依然卡在同一位置。 原因Ollama默认从境外源拉取权重网络不稳定或没有走加速时极易中断。 解决给Ollama配置国内可访问的镜像源或者从镜像站手动下载GGUF文件后导入本地库。导入命令是ollama import模型文件要放在指定目录具体路径在Ollama的models目录下找。5.2 并发一上来就OOM进程被杀现象单请求测试正常并发5到10个请求时服务进程直接退出日志或dmesg里出现CUDA out of memory。 原因vLLM的KV Cache把显存吃满了或者max-model-len设得过大给每个请求分配的缓存超出了显存承载。 解决把max-model-len从8192降到2048或4096并设置--gpu-memory-utilization为0.85以下给系统预留余量。另外在服务入口做并发限制超过阈值直接排队比让请求打到服务端再失败强。5.3 部署完成后第一个请求慢到怀疑机器坏了现象服务启动后第一次发请求等了十几秒才返回但后续请求速度恢复正常。 原因模型权重正在从磁盘加载到显存首次推理前需要完成显存分配和权重加载这一步无法避免。 解决部署完成后主动发一个短请求做预热让模型完成加载。预热请求的输入长度不要过长几十个token即可目的是把权重“焐热”在显存里而不是真的测试效果。5.4 中文输出偶尔出现乱码或替换符现象返回文本里出现形如的替换字符或者一段中文被拆成残缺片段。 原因线程或日志采集层按其他编码解析了UTF-8输出导致多字节字符被截断。 解决代码层面的print和日志写入规范为UTF-8编码如果用了json.dumps输出中文加ensure_asciiFalse否则中文会被转成\uXXXX再被某些日志系统截断。5.5 微调后模型效果反而不如基座现象用几百条业务数据微调后模型在原有通用能力上明显退化甚至原本会的数学题也答不对了。 原因学习率太高或训练轮数太多小数据上发生过拟合和灾难性遗忘。 解决微调学习率控制在1e-5到3e-5区间训练轮数从1到2轮起步不要一上来就多轮重复。评测时保留一组原始benchmark样例微调前后都跑一遍用数据确认是否发生遗忘。6. 最后一公里用100条数据完整跑一次微调验证手册看到这里大部分人会卡在同一个地方部署会了API会了但微调这一步迟迟不敢动手。其实验证整条链路根本不需要大工程更不需要几百上千条数据。我习惯的路径是用100条高质量样例在一个7B模型上跑一轮LoRA微调把“原始数据→训练→推理对比”整个闭环走通确认流程无误后再谈规模。LLaMA-Factory是目前最省心的微调工具安装和启动都比较直接git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .数据文件放到data目录后在data/dataset_info.json里注册数据集名然后执行训练llamafactory-cli train \ --model_name_or_path deepseek-ai/DeepSeek-V2-Lite \ --stage sft \ --dataset my_data.json \ --finetuning_type lora \ --learning_rate 2e-5 \ --num_train_epochs 1.0learning_rate设为2e-5是我想特别强调的。小批量数据上学习率超过5e-5很容易出现loss震荡训练完模型直接“失忆”。num_train_epochs设1.0意味着全部数据只过一遍避免重复训练导致过拟合。如果你的数据量超过500条可以适当把学习率往上提但不要超过5e-5的线。训练完成后用同样的提示词分别问基座模型和微调后的模型把输出放在一起对比。这一步才是微调验证的核心看它是否记住了你注入的业务规范是否破坏了原有的语言能力。如果业务规范有改进、通用能力没下降这条链路就算真正跑通了。从那以后我每次拿到新模型或新数据集都强制自己走一遍“选型→部署→数据准备→微调→评测”的最小闭环哪怕只花半天时间也要先把流程验证完再谈规模。这个习惯帮我避开了无数次“前面一切正常、最后模型效果稀碎”的尴尬。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek等大模型工具使用手册：从选型到微调的全链路部署指南
简介这份173页演示文稿由厦门大学大数据教学团队出品是一份大模型工具实用手册围绕DeepSeek等主流生成式人工智能工具展开适合希望快速上手文本、图片、语音、视频生成以及辅助编程的初学者和职场人士。内容从生成式人工智能的核心概念与核心技术讲起逐步拆解文本、图片、语音、视频四类应用实践并专门介绍其在辅助编程和人工智能搜索中的落地方法结合大量案例页面结构清晰、章节递进合理。资源为单个PPTX文件共1个文件压缩包大小8.47MB可直接用办公软件打开便于按章节学习、做笔记或二次编辑。目前已有70人学习下载适合需要系统了解DeepSeek等大模型工具操作技巧的学习者收藏。1. 翻完173页DeepSeek等大模型工具使用手册从选型到微调的全链路拆解前阵子同事把这份173页的《DeepSeek等大模型工具使用手册》PPT丢给我问能不能照着给团队落地。我花了一个晚上翻完又拿周末把里面涉及的部署链路自己跑了一遍。结论很直接这不是那种“看完即会”的科普PPT而是一份能指导实操的施工图前提是你知道怎么读。它适合两类人一类是已经调过官网API、想搞清楚背后参数边界和成本逻辑的开发者另一类是准备私有化部署、需要快速给团队做出选型和技术方案的工程师。如果你只是顺手搜一下DeepSeek是什么这份手册对你可能偏长但如果你真要把它接进业务按我下面的顺序读能省掉不少试错时间。2. 选型与参数边界搞懂参数量、上下文和量化再动手2.1 参数量先看显存再看能力手册里大概率会有一张模型对比表。别跳过它直接往下翻因为后面所有部署命令都依赖你在这张表里做的选择。DeepSeek系列从轻量到重量级覆盖多个档位参数量直接决定显存门槛。7B做INT4量化后大约需要6到8GB显存13B需要12GB左右70B即使量化完也要40GB以上。单张3090还是双卡A100在这里就决定了你能跑哪个模型。我遇到过不止一个“模型下好了机器跑不动”的翻车案例问题都出在选型时没看显存。很多人觉得参数量越大越好实际工程里这个判断要反过来先看你手里有什么硬件再决定模型档位。业务是代码补全、摘要生成7B或13B完全够要处理复杂推理、长链路Agent任务才需要考虑70B。下表是通用参考按这个范围选一般不会出大错。参数量量化后显存参考适配场景7B6-8 GB代码补全、摘要、普通对话13B12-16 GB复杂指令、中等推理70B40-70 GB高难度推理、私有化生产选型时还有一个容易被忽略的点同尺寸模型的不同版本能力侧重可能完全不同。拿DeepSeek来说对话版和推理版在同样的7B规模下一个擅长多轮交互一个擅长分步思考。手册里如果区分了这两种角色务必按业务类型选不要只看参数量。我一般会把候选模型放进同一份测试集里跑一轮固定temperature和上下文看实际输出再定比对着benchmark数字猜靠谱得多。2.2 上下文长度最容易被忽略的显存杀手上下文长度是本地部署里最隐蔽的坑。很多人看到模型支持8192就直接拉满结果一启动就OOM还以为是显存不够。Transformer的显存开销随序列长度近似平方增长同样一个模型上下文从2048开到8192显存占用可能翻倍不止。手册里如果给了不同上下文长度对应的显存参考表那一页值得截图存下来。我给自己定过一条规矩上下文按业务实际峰值长度设定不按模型上限设定。比如做客服问答单轮输入输出加起来通常不会超过1500 token那就设2048留一点余量即可。处理私有文档时优先用RAG把长文切片再检索而不是把整篇文档塞进上下文。显存是一方面更重要的是模型在超长上下文里的注意力会涣散输出质量反而下降。RAG的思路是把100页PDF切成若干块每次只把和问题相关的片段拼进输入既控制token成本也避免模型“读着读着忘了前面”。日常估算token时可以按汉字约1.5到2个token来粗算。一段500字的商品说明大概需要800到1000 token。如果你用的是Python直接拿tokenizer库做精确统计更稳妥from transformers import AutoTokenizer tk AutoTokenizer.from_pretrained(deepseek-ai/DeepSeek-V2-Lite) text 这段文本用来估算实际token数量 print(len(tk.encode(text)))这段代码的作用很简单加载对应模型的tokenizer把一段真实业务文本转成token后数个数。注意这里用的是V2-Lite如果你的模型版本不同要改成对应的模型名否则tokenizer不一致会导致估算偏差。2.3 量化格式GGUF、GPTQ、AWQ怎么选量化是本地部署绕不开的环节。同一份模型权重不量化的FP16版本和量化后的INT4版本显存占用差出一倍多但在多数生成任务里效果差距小于百分之五。真正丢分的场景集中在数学计算和长文本推理上普通对话、摘要、信息抽取基本无感。量化格式的选择要和推理框架匹配这是很多人没注意到的。本地轻量跑用GGUF配Ollama最省事Q4_K_M是通用起步档要搭高并发服务端vLLM对GPTQ和AWQ支持更完整。经验是同一个模型不要反复换量化版本做评测。不同量化方式对结果的扰动很容易被误判成模型能力差异你花半天对比最后发现是量化格式不同导致的纯属浪费精力。真要做对比固定三个变量量化格式、上下文长度、测试用例集。只有这三项完全一致跑出来的差异才能归因到模型本身。手册里这部分可能被写成“模型导出”或“格式转换”实操时不要因为名字不起眼就跳过部署方案合不合理很大程度上取决于这里的格式选择。3. 本地部署实操Ollama跑通vLLM接生产3.1 环境准备与Ollama最小路径拿到手册先别急着上分布式部署。第一步永远是单机跑通。Ollama是本地启动大模型最省事的工具装好之后两个命令就能拉起一个能对话的模型服务# 拉取7B对话模型首次会下载数GB权重耗时取决于网络 ollama pull deepseek-r1:7b # 启动服务默认监听127.0.0.1:11434 ollama serve第一次执行ollama pull时如果进度条一直停在某个百分比不动先确认网络状态问一下自己是不是没有配置镜像源。Ollama默认从官方源拉取权重网络波动大时很容易中断。这个问题在第5章避坑部分我会展开说这里先记住ollama serve是前台阻塞进程窗口不要关另开一个终端执行ollama list查看已拉取的模型列表。服务起来之后可以用curl做一次最小验证确认接口真的通了curl http://127.0.0.1:11434/api/chat -d { model: deepseek-r1:7b, messages: [{role: user, content: 你好}], stream: false }这里stream: false表示等模型生成完整结果后一次性返回适合调试业务并发场景建议改成true走流式输出用户体验差别很大。Ollama做开发和单机演示足够但并发上来之后性能会成瓶颈生产环境我一般直接换vLLM。3.2 vLLM高并发部署与关键参数vLLM是目前生产环境最常见的部署框架核心优势是PagedAttention显存管理和高吞吐。装依赖时建议用Python 3.10以上版本避免一些兼容性问题pip install vllm启动服务的命令比Ollama多几个参数但每个参数都对应一类实际问题python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-V2-Lite \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000max-model-len决定了模型能接受的最大序列长度要和业务请求的输入输出总和匹配设置过大直接浪费显存gpu-memory-utilization表示显存利用率上限如果机器上还有别的进程建议调到0.7以下tensor-parallel-size是多卡并行时的张量并行度单卡就填1多卡时按GPU数量填。启动日志里出现Starting vLLM server并且没有报错说明进程起来了。这时在另一个窗口执行nvidia-smi确认显存占用正常情况下应该看到显存被加载的模型占据而不是满屏的0。3.3 OpenAI兼容接口一套代码跑本地和云端vLLM启动后默认监听8000端口对外暴露的是OpenAI兼容接口这意味着所有为OpenAI API写的代码改一下base_url和api_key就能切到本地模型。验证连通性时我习惯写个极简Python脚本from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY # 本地服务不校验key填任意非空字符串即可 ) resp client.chat.completions.create( modeldeepseek-ai/DeepSeek-V2-Lite, messages[{role: user, content: 用一句话说明大模型推理和训练的区别}], max_tokens256, temperature0.7 ) print(resp.choices[0].message.content)这段代码和调官方API唯一的区别就是第2行和第3行的地址与密钥。以后要切回云端只需要把base_url换成官方地址、api_key换成真实密钥业务代码一行都不用动。我所有的部署验证都走这套方式能最大限度降低切换成本。4. 接入业务链路API调用、微调数据与工具集成4.1 云端API调用温度、采样与超时的工程细节如果你不打算本地部署直接用云端API第一个要理解的是生成参数。temperature控制随机性调得越高输出越发散调得越低输出越发确定。做分类、实体抽取这类有标准答案的任务设0或0.1做文案生成、创意写作设0.7以上。还有一个容易踩的坑是max_tokens设太小比如设了128但回答需要200个token生成到一半被截断截断部分照样计费。一个规范的信息抽取调用长这样import os from openai import OpenAI client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com/v1 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是信息抽取助手只输出JSON不要多余解释。}, {role: user, content: 从这段话里抽取公司名称和所在行业输出JSON。} ], temperature0.1, max_tokens1024 ) print(resp.choices[0].message.content)注意api_key不要硬编码在代码里用环境变量读取否则一旦代码提交到公共仓库密钥就泄露了。系统提示词里明确约束输出格式能省掉不少后处理工作。这里我把temperature压到0.1就是为了让模型在抽取任务里少“发挥”。4.2 微调数据标注JSONL结构与样例质量手册里如果有数据标注章节核心无非是两种格式对话格式和纯文本补全格式。微调框架里最常见的对话格式是JSONL一行一个样本每个样本包含一组多轮对话。以LLaMA-Factory为例默认字段长这样{conversations: [{from: human, value: 请把这段产品文案压缩到20字以内}, {from: gpt, value: 轻便耐用性价比之选。}]} {conversations: [{from: human, value: 把这句话翻译成英文今天天气很好}, {from: gpt, value: The weather is nice today.}]}写标注样例时最忌讳只做模板复制。如果100条数据都是同一个句式微调出来的模型只会换词不会举一反三。覆盖边界情况比覆盖常见情况更重要遇到用户问“不知道”、用户给出非常规表述、用户要求多轮纠正这些都要单独标。数据质量差后面微调做得再精细也是白搭。不同框架对字段名的要求略有差异我一般会在动手前先确认目标框架识别的字段比如LLaMA-Factory用conversations有些框架用instruction和output。不确定时先在仓库的data目录里找一个官方示例比对着改字段名比翻文档快得多。4.3 工具链接入Dify、Codex一类工具的通用配置逻辑现在很多团队做RAG应用或Agent平台时用的都是Dify、Codex这类现成工具。接DeepSeek时很多人以为要装额外插件其实核心配置逻辑高度一致找到模型供应商配置页选“OpenAI-API-compatible”或类似选项填入Base URL和API Key然后测试连通性。本地部署模型时Base URL填http://localhost:11434/v1Ollama或http://localhost:8000/v1vLLM用云端API时填https://api.deepseek.com/v1。工具侧的模型名要和你部署时指定的模型名完全一致大小写和路径都不能错最常见的问题就是模型名填错导致报错模型不存在。这套逻辑在手册里通常被写在“第三方工具接入”那一节按图索骥十分钟就能配完。5. 避坑指南部署与调用里最常见的5个翻车现场5.1 模型拉不下来Ollama一直超时现象ollama pull跑到一半报错提示连接超时或下载失败重试几次依然卡在同一位置。 原因Ollama默认从境外源拉取权重网络不稳定或没有走加速时极易中断。 解决给Ollama配置国内可访问的镜像源或者从镜像站手动下载GGUF文件后导入本地库。导入命令是ollama import模型文件要放在指定目录具体路径在Ollama的models目录下找。5.2 并发一上来就OOM进程被杀现象单请求测试正常并发5到10个请求时服务进程直接退出日志或dmesg里出现CUDA out of memory。 原因vLLM的KV Cache把显存吃满了或者max-model-len设得过大给每个请求分配的缓存超出了显存承载。 解决把max-model-len从8192降到2048或4096并设置--gpu-memory-utilization为0.85以下给系统预留余量。另外在服务入口做并发限制超过阈值直接排队比让请求打到服务端再失败强。5.3 部署完成后第一个请求慢到怀疑机器坏了现象服务启动后第一次发请求等了十几秒才返回但后续请求速度恢复正常。 原因模型权重正在从磁盘加载到显存首次推理前需要完成显存分配和权重加载这一步无法避免。 解决部署完成后主动发一个短请求做预热让模型完成加载。预热请求的输入长度不要过长几十个token即可目的是把权重“焐热”在显存里而不是真的测试效果。5.4 中文输出偶尔出现乱码或替换符现象返回文本里出现形如的替换字符或者一段中文被拆成残缺片段。 原因线程或日志采集层按其他编码解析了UTF-8输出导致多字节字符被截断。 解决代码层面的print和日志写入规范为UTF-8编码如果用了json.dumps输出中文加ensure_asciiFalse否则中文会被转成\uXXXX再被某些日志系统截断。5.5 微调后模型效果反而不如基座现象用几百条业务数据微调后模型在原有通用能力上明显退化甚至原本会的数学题也答不对了。 原因学习率太高或训练轮数太多小数据上发生过拟合和灾难性遗忘。 解决微调学习率控制在1e-5到3e-5区间训练轮数从1到2轮起步不要一上来就多轮重复。评测时保留一组原始benchmark样例微调前后都跑一遍用数据确认是否发生遗忘。6. 最后一公里用100条数据完整跑一次微调验证手册看到这里大部分人会卡在同一个地方部署会了API会了但微调这一步迟迟不敢动手。其实验证整条链路根本不需要大工程更不需要几百上千条数据。我习惯的路径是用100条高质量样例在一个7B模型上跑一轮LoRA微调把“原始数据→训练→推理对比”整个闭环走通确认流程无误后再谈规模。LLaMA-Factory是目前最省心的微调工具安装和启动都比较直接git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .数据文件放到data目录后在data/dataset_info.json里注册数据集名然后执行训练llamafactory-cli train \ --model_name_or_path deepseek-ai/DeepSeek-V2-Lite \ --stage sft \ --dataset my_data.json \ --finetuning_type lora \ --learning_rate 2e-5 \ --num_train_epochs 1.0learning_rate设为2e-5是我想特别强调的。小批量数据上学习率超过5e-5很容易出现loss震荡训练完模型直接“失忆”。num_train_epochs设1.0意味着全部数据只过一遍避免重复训练导致过拟合。如果你的数据量超过500条可以适当把学习率往上提但不要超过5e-5的线。训练完成后用同样的提示词分别问基座模型和微调后的模型把输出放在一起对比。这一步才是微调验证的核心看它是否记住了你注入的业务规范是否破坏了原有的语言能力。如果业务规范有改进、通用能力没下降这条链路就算真正跑通了。从那以后我每次拿到新模型或新数据集都强制自己走一遍“选型→部署→数据准备→微调→评测”的最小闭环哪怕只花半天时间也要先把流程验证完再谈规模。这个习惯帮我避开了无数次“前面一切正常、最后模型效果稀碎”的尴尬。希望帮到你。本文还有配套的精品资源点击获取