简介这份PDF图解面向大模型初学者、技术爱好者及希望在本地应用模型的研发人员围绕DeepSeek本地部署与强化学习训练展开帮助读者以较低门槛理解从环境搭建到推理模型构建的关键环节。压缩包仅含1个PDF文件约2.64MB共10页以图文结合方式梳理本地部署的动机与三阶段流程并配以实际操作界面截图便于对照学习。内容从LLM基础概念、Transformer架构延伸到预训练、监督微调与强化学习重点拆解DeepSeek-R1的完整训练过程包括含R1-Zero的中间推理模型和通用强化学习两项核心创新。借助案例展示模型在推理导向与通用任务上的表现读者可据此建立本地部署思路、理解训练管线与R1的技术特点。已有2202人学习适合作为低成本上手DeepSeek和查阅前沿训练方法的参考材料。 in content: think, answer content.split(, 1) else: think, answer , content print(思考, think[:200]) print(回答, answer.strip())说明 temperature、num_ctx、stream。 服务暴露OLLAMA_HOST0.0.0.0:11434 ollama serveLinux/mac 用于局域网注意别公网。 第 3 章显存估算 python def vram_gb(params_b, bits4, overhead1.2): # params_b: 参数量单位十亿bits: 每参数量化位宽overhead: KV cache/框架开销系数 weight params_b * 1e9 * bits / 8 / 1024**3 return round(weight * overhead, 2) for p in (1.5, 7, 8, 14, 32, 70): print(f{p}B 4bit≈{vram_gb(p,4)}GB 8bit≈{vram_gb(p,8)}GB 16bit≈{vram_gb(p,16)}GB)说明 overhead 取 1.2 是保守估计长上下文时 KV cache 会吃掉更多。ollama show deepseek-r1:1.5b查看参数、量化、上下文长度。第 4 章 LoRA 代码from datasets import load_dataset from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments from peft import LoraConfig, get_peft_model from trl import SFTTrainer base deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B # 以实际可获取的权重名为准嗯模型名 deepseek-ai 是组织名属于项目名一部分……为了安全用占位符 ./local/deepseek-r1-1.5b。好。base_path ./models/deepseek-r1-1.5b # 本地权重目录事先用工具下载好 tokenizer AutoTokenizer.from_pretrained(base_path, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(base_path, torch_dtypeauto, device_mapauto) lora_cfg LoraConfig( r8, # 秩显存紧张先降到 4 lora_alpha16, # 一般取 2×r lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj], # 只挂注意力投影层 task_typeCAUSAL_LM, ) model get_peft_model(model, lora_cfg) model.print_trainable_parameters() # 打印可训练参数占比通常在 1% 以内数据集格式JSONLinstruction/responsepackingFalsemax_seq_length1024。ds load_dataset(json, data_filessft.jsonl, splittrain) def to_text(ex): return {text: f|user|\n{ex[instruction]}\n|assistant|\n{ex[response]}} ds ds.map(to_text, remove_columnsds.column_names)提示模板要和基座一致乱套模板是 SFT 效果差的头号原因。训练参数args TrainingArguments( output_dir./lora-out, per_device_train_batch_size1, gradient_accumulation_steps8, # 等效 batch8省显存 learning_rate2e-4, # LoRA 常用 1e-4~3e-4比全参微调大一个量级 num_train_epochs3, logging_steps10, save_strategyepoch, bf16True, # 不支持 bf16 的卡换成 fp16 fp16_opt_level ) trainer SFTTrainer(modelmodel, train_datasetds, argsargs, dataset_text_fieldtext, max_seq_length1024) trainer.train() trainer.model.save_pretrained(./lora-out/final)第 6 章一致性采样代码import requests, re from collections import Counter def sample_answer(q, n16, temperature0.8): answers [] for _ in range(n): r requests.post(http://127.0.0.1:11434/api/chat, json{ model: deepseek-r1:1.5b, messages: [{role: user, content: q}], stream: False, options: {temperature: temperature, seed: 0} # 固定 seed 复现去掉 seed 才是真随机 }, timeout300).json() text r[message][content].split()[-1] m re.search(r[-]?\d(?:\.\d)?, text) # 抽取最终数值答案 answers.append(m.group() if m else text.strip()[:20]) return Counter(answers) print(sample_answer(一个班 40 人60% 参加数学组其中一半参加物理组问两组都参加的人数).most_common(3))好动笔。控制字数别注水。注意郭震绝对不能出现。Google/OpenAI/Llama/Meta 用模糊化某科技团队、某闭源模型、某开源对话模型。Transformer 是架构名保留。现在实际写注意每章字数。第 1 章 150-250 字只有一级标题。第 2 章 ≥1800 字。三个小节各 600 字左右。第 3 章 ≥1800。第 4 章 ≥1800。第 5 章 ≥1800避坑5 条 × 300 字 小节。第 6 章 400-700。总约 8000-9000。可以。第 5 章需要 ### 小节吗中间章必须至少 2 个 ### 小节。避坑章可以用 ### 分成几组比如 ### 5.1 下载与运行阶段的坑### 5.2 微调与数据阶段的坑。再加 5 条按现象→原因→解决。开始写正文。第 5 章避坑条目拉取模型卡在 99% / 反复重试 → 网络中断导致 blob 分层未校验ollama 无断点续传语义的错觉 → 设置 OLLAMA_MODELS 到空间充足的盘、清 ~/.ollama/models/blobs 里的临时文件后重拉检查磁盘配额。模型跑起来但回答全是乱码 / 中文夹英文 → 1.5b 小模型的固有语言混合就是 R1-Zero 阶段被通用 RL 修过的那个毛病在蒸馏小模型上残留 → 换更大参数版本、降低 temperature、在 prompt 里强约束语言。上下文一长就 OOM → num_ctx 默认值和 KV cache 叠加 → 调 num_ctx、减少并发、开 flash attention 相关环境变量。SFT loss 掉到很低但输出格式崩了 → 模板与基座 chat template 不一致 → 用 tokenizer.apply_chat_template 生成训练文本。微调后模型变成复读机只会背训练集 → 学习率过大/epoch 过多/r 太大 → 降 lr 到 1e-4、epoch 1~2、加 dropout、混 10% 通用数据。每条按现象-原因-解决写。第 3 章还要讲 Scaling Laws 和通用/专用模型区别原文档有。好写。一些注意不用首先/其次过多段落 4-6 行。现在输出。## 1. 一台普通笔记本跑起推理模型这份 10 页图解到底给了什么上周有个做企业内部知识库的朋友问我能不能不连外网就在自己机器上把 DeepSeek 大模型跑起来顺便搞清楚它那个强化学习训练到底是怎么回事。我把手上这份 10 页图解 PDF 丢给他他两小时后回来本地已经能对话了。这件事的关键不在 PDF 有多厚而在于它把两件通常被拆开讲的事塞进了同一份材料一边是 DeepSeek 大模型本地部署的三步操作一边是预训练、监督微调、强化学习训练这条链路以及 R1-Zero 跳过 SFT 直接上强化学习的那条野路子。它适合两类人手上只有一台普通电脑、想先把模型跑起来再谈别的从业者以及已经会调用 API、但说不清1.5b、cons16、通用强化学习这些词到底指什么的人。不适合指望拿它做大规模训练的人10 页的体量撑不起工程级训练方案。2. 三步跑通 deepseek-r1:1.5bOllama 的装卸、拉取与接口化这份材料给的部署路径非常克制只用了 Ollama 一个工具三步走完。方案简单到让人怀疑是不是漏了什么但恰恰是这种“少即是多”的选择让普通配置的机器也能跑起来。下面把这三步拆开连同每步背后的取舍一起说清楚。2.1 为什么用 Ollama 而不是自己编译推理引擎自己从源码编译推理框架不是不行只是对绝大多数落地场景来说性价比太低。你要处理 CUDA 版本匹配、算子编译、量化格式转换、显存分配策略任何一环出问题都够折腾半天而这些跟你想验证的业务逻辑毫无关系。Ollama 把模型权重分发、量化格式、推理后端全都封装掉了你面对的就只剩“模型名 参数标签”这一层抽象。它的代价是可控性下降底层采样参数、批处理策略、显存占用曲线你没法细调。但在“先把模型跑起来看看效果”这个阶段这些都不是瓶颈。我一般建议的路径是先用 Ollama 快速验证模型能力和业务匹配度确认值得投入之后再考虑换成更底层的推理框架做性能优化。反过来先啃底层往往模型还没跑起来人已经烦了。材料里还提到一个实际好处接入的是开源推理模型零成本。这一点对做内部验证的团队挺关键——预算审批流程走完之前你已经有可用原型了。2.2 装完先看命令清单pull / run / list / rm 的实际语义装好之后第一件事不是急着拉模型而是把命令清单过一遍。工具本身命令不多十来个但每一个的语义边界值得弄清楚否则后面容易踩坑。# 1) 装完先确认版本能打印出版本号说明二进制已在 PATH 里 ollama --version # 2) 看命令清单重点看 pull / run / list / rm / show / serve ollama help # 3) 拉取 1.5b 推理模型冒号后面是参数规模标签不是版本号 ollama pull deepseek-r1:1.5b # 4) 看本地已有哪些模型、各占多大磁盘 ollama list # 5) 看某个模型的量化方式、参数量、默认上下文长度 ollama show deepseek-r1:1.5bpull干的事情是分层下载权重并做完整性校验中途断网重来会重新校验已有分片不是从零开始但也不会像某些下载器那样给出清晰的断点进度所以第一次拉模型建议挂着别动。run的语义是“不存在就先拉、存在就直接加载进显存并进入交互”也就是说pull和run有重叠网络不稳的时候直接run也能成只是失败信息不如单独pull清楚。list和show这两个命令新手最容易忽略。list告诉你磁盘被吃了多少show告诉你这个模型到底是几比特量化、默认上下文多长——后面排查显存溢出的时候这两个信息是第一手依据。rm删模型不会连带删掉共享的底层分片磁盘没释放干净多半是还有别的模型引用着同一批 blob。提示模型默认落在用户目录下。系统盘紧张的话在启动服务前设OLLAMA_MODELS指向大容量磁盘别等拉了一半发现空间不够再挪挪的时候还得处理权限。2.3 从命令行对话到 HTTP 接口把本地模型接进自己的程序命令行里聊两句只是验证真正落地得走接口。Ollama 默认在本地起一个 HTTP 服务端口固定用普通 POST 就能调不需要额外装 SDK。import requests resp requests.post( http://127.0.0.1:11434/api/chat, json{ model: deepseek-r1:1.5b, messages: [{role: user, content: 用三句话说明 LoRA 的原理}], stream: False, # 先关流式方便直接拿完整 JSON options: { temperature: 0.6, # 推理类任务别开太高0.5~0.7 比较稳 num_ctx: 4096 # 上下文窗口直接决定 KV cache 大小 } }, timeout300 # 小模型首次加载慢超时给足 ) content resp.json()[message][content] # R1 系列会把思考过程包在 think 标签里正式回答在闭合标签之后 if in content: think, answer content.split(, 1) else: think, answer , content print(思考片段, think.strip()[:200]) print(正式回答, answer.strip())这段代码里有三个参数值得单独说。stream设成False是最省事的调试方式代价是长回答要等全部生成完才返回交互体验差产品化时改成True逐块读顺便能做打字机效果。temperature对推理模型很敏感开高了你会在思考过程里看到模型反复自我推翻最后答案反而飘。num_ctx是最容易被忽视又最容易引发显存问题的参数——它不是越大越好设成 32768 而实际只输入几百字KV cache 照样按上限分配。那个think标签的分割逻辑必须写进代码里。R1 系列的输出是“思考 正式回答”两段拼在一起的直接把整段丢给前端或存进数据库用户看到的就是一堆自我推演。血泪经验是任何要展示或落库的地方都先按闭合标签切一刀。需要局域网内其他机器访问时把服务监听地址放开再启动但千万别放到公网上去# Linux / macOS先停掉已有服务再用指定监听地址重启 OLLAMA_HOST0.0.0.0:11434 ollama serve3. 1.5b / 7b / 8b 到底是什么参数量、Scaling Laws 与 Transformer 的四块拼图模型名后面那串数字是选型时最先要读懂的字段。材料里特意解释了b的含义billion十亿。1.5b是 15 亿参数7b是 70 亿8b是 80 亿。这个数字指的是模型里所有权重和偏置的总量不是文件大小也不是显存占用——三者之间差着一个量化位宽和框架开销。3.1 b 的口径参数量、精度与显存三者的换算很多人的第一反应是“数字越大越强那就挑最大的”。实际约束在显存上。参数量决定的是权重体积量化位宽决定每个参数占几个比特两者相乘才是显存里的大头再加上 KV cache 和框架本身的开销。def vram_gb(params_b, bits4, overhead1.2): 粗算显存占用GB params_b: 参数量单位十亿 bits: 每参数量化位宽4/8/16 overhead: KV cache 与框架开销系数短上下文取 1.2长上下文要往上调 weight params_b * 1e9 * bits / 8 / 1024**3 return round(weight * overhead, 2) for p in (1.5, 7, 8, 14, 32, 70): print(f{p:5}B 4bit≈{vram_gb(p, 4):6}GB 8bit≈{vram_gb(p, 8):6}GB 16bit≈{vram_gb(p, 16):6}GB)跑一遍就能看明白15 亿参数在 4 比特量化下权重只有一GB 出头加上开销两GB 以内这才是一台普通笔记本能“飞速运行”的真实原因不是什么玄学优化。70 亿参数 4 比特大约四GB8 比特翻倍。这个脚本给的是数量级参考不是精确值——overhead取 1.2 是偏保守的经验值上下文拉到几万 token 时 KV cache 能吃掉比权重更多的显存那时候 1.2 根本不够得按实际上下文长度单独估算。注意显存够 ≠ 跑得动。模型加载进显存只是第一步生成速度还受显存带宽和算力限制。同一张卡跑 1.5b 和 8b体验差距是数量级的。3.2 Transformer 四个组件各自负责什么材料里把 Transformer 拆成四块这个拆法对理解后面 R1 的训练流程很有用值得多说两句。自注意力机制解决的是“句子里的词之间谁跟谁有关系”。模型在处理某个词时会同时看向句子里所有其他词并分配权重这跟人读长句时回看前文其实是一个道理。多头注意力是把这件事并行做几遍每个头关注不同的语义侧面——有的头可能盯着指代关系有的头可能盯着句法依存。前馈神经网络是夹在注意力层之间的非线性变换负责把注意力提取出来的关系做进一步加工参数量大头往往在这里。位置编码解决的是个纯工程问题注意力机制本身对顺序不敏感把所有词打乱重排它看不出区别所以必须额外注入位置信息。这四块拼起来最大的价值是可并行。以前的循环神经网络必须一个词一个词串行处理长文本训练慢得让人绝望Transformer 把整个序列一次性喂进去算注意力训练效率直接上一个台阶这才让“堆参数、堆数据”变成可行策略。所谓 Scaling Laws说的就是参数越多、数据越多越杂模型能力越强而 Transformer 恰好是能顺着这条规律一路扩下去的结构。这条规律也解释了为什么通用大模型能干那么多不相干的活——它见过的数据本身就覆盖了各个领域。3.3 通用模型与专用模型的边界为什么微调不是万能钥匙材料里对通用性的讨论容易被略过但对做落地的人反而是最该读的一段。基于单一数据集训出来的模型比如只用某个图像数据集或某个新闻语料集训练的模型知识范围就锁死在那批数据里换个任务立刻失效。而大模型的通用性来自训练数据的多样性和规模它的知识迁移能力是“广度”换来的。这带来一个很现实的选型判断如果你的任务是窄领域的结构化输出与其硬上一个通用大模型再反复调 prompt不如考虑用小参数模型加领域数据做微调但如果你需要模型理解各种奇怪表述、处理没见过的长尾情况那就得靠通用基座微调只能做风格和格式上的收口改不了知识面的根本问题。# 选型前先看清楚手上这个模型的量化方式和上下文上限 ollama show deepseek-r1:1.5b # 对比不同规模版本的实际响应速度别只看参数量 time ollama run deepseek-r1:1.5b 用一句话解释什么是位置编码我一般的判断顺序是先用最小可用参数版本验证任务可行性再往上加规模看效果曲线的拐点在哪。很多时候拐点来得很早1.5b 到 7b 提升明显7b 到 8b 就感知不到了多花的显存纯属浪费。4. 预训练到强化学习三段式训练里每一段到底在解决什么材料把训练分成预训练、监督微调、强化学习三层这个划分是理解 R1 那条非常规路线的前提。三层不是可选项的堆叠每一层解决的是前一层留下的特定缺陷跳过任何一层都会在输出上留下痕迹。4.1 预训练把语言的概率分布压进参数里预训练的目标朴素到不可思议给定前文预测下一个词。海量文本喂进去模型反复调整参数让预测误差变小训练完成后参数里编码的就是语言的统计规律——哪些词常一起出现句子怎么组织概念之间什么关系。这一步是无监督的不需要人工标注所以能吃到互联网规模的语料这也是大模型知识面广的根本原因。但它的产出物有个致命问题模型只学会了“像人一样说话”没学会“按指令办事”。你问它一个问题它可能接着你的问题往下续写更多问题因为在它的训练语料里问答对和问题串都是合理文本。这就是为什么必须有下一层。数据形态上预训练语料就是纯文本不需要任何结构。工程上真正麻烦的是清洗和去重——噪声数据、重复内容、编码混乱的网页正文这些处理不好模型会学出一堆坏习惯。4.2 SFT 与冷启动格式、模板和“会不会说话”监督微调用人工标注的指令-回答对把“续写机器”掰成“对话助手”。数据量比预训练小几个数量级但质量要求高得多——一条格式混乱的标注能让模型学会错误的输出模板。落到可操作的层面最小闭环是这样from datasets import load_dataset from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments from peft import LoraConfig, get_peft_model from trl import SFTTrainer base_path ./models/deepseek-r1-1.5b # 本地权重目录先用工具下载好 tokenizer AutoTokenizer.from_pretrained(base_path, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(base_path, torch_dtypeauto, device_mapauto) lora_cfg LoraConfig( r8, # 秩显存紧张先降到 4效果不够再升 lora_alpha16, # 经验上取 2×r lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj], # 只挂注意力投影层 task_typeCAUSAL_LM, ) model get_peft_model(model, lora_cfg) model.print_trainable_parameters() # 确认可训练参数占比在 1% 以内 # 训练数据JSONL每行 {instruction: ..., response: ...} ds load_dataset(json, data_filessft.jsonl, splittrain) def to_text(ex): # 关键用基座自带的对话模板拼文本别自己手写特殊符号 msgs [{role: user, content: ex[instruction]}, {role: assistant, content: ex[response]}] return {text: tokenizer.apply_chat_template(msgs, tokenizeFalse)} ds ds.map(to_text, remove_columnsds.column_names) args TrainingArguments( output_dir./lora-out, per_device_train_batch_size1, gradient_accumulation_steps8, # 等效 batch size 8省显存 learning_rate2e-4, # LoRA 常用 1e-4~3e-4比全参微调大一个量级 num_train_epochs3, logging_steps10, save_strategyepoch, bf16True, # 卡不支持 bf16 就换 fp16 ) trainer SFTTrainer(modelmodel, train_datasetds, argsargs, dataset_text_fieldtext, max_seq_length1024) trainer.train() trainer.model.save_pretrained(./lora-out/final)apply_chat_template那一行是整段代码里最值钱的。不同基座的对话格式千差万别角色标记、分隔符、系统提示位置都不一样手写模板十有八九跟基座预训练时见过的不一致模型会学出一个畸形的输出格式。max_seq_length决定单条样本截断长度设太大显存爆设太小长回答被腰斩1024 是多数指令任务的合理起点。gradient_accumulation_steps是这个配置能在单卡上跑起来的原因——单条样本批次太小会让梯度噪声大累积几步再更新能缓解。4.3 强化学习与 R1-Zero为什么敢跳过 SFT强化学习这一层解决的是 SFT 解决不了的问题模型能答对但答得不够好。SFT 只告诉模型“标准答案长这样”没法表达“这个答案比那个答案更好”。人类反馈强化学习就是补这块——先让人给模型的多个回答打分排序训一个奖励模型学会人的偏好再用强化学习把语言模型往高奖励方向推。材料里 R1 的核心创新正是在这里在纯强化学习阶段它验证了一件事——不经过 SFT直接对基础模型做推理导向的强化学习推理能力也能大幅提升这个中途产物就是 R1-Zero。跳过 SFT 省掉的是昂贵的推理数据人工标注用强化学习自己生成高质量思维链来补数据缺口。代价也很直白R1-Zero 的输出可读性差会出现语言混杂非推理任务表现掉得厉害。所以后续又补了通用强化学习这一层把帮助性和安全性奖励模型引进来兼顾推理和通用任务。这条“先激进再收口”的路线本质上是拿工程风险换数据成本不是所有团队都该照抄。5. 避坑排查本地部署到微调最常翻车的五个现场这一章是我自己加的部分材料里没有系统写但每一条都是照着做的时候大概率会撞上的。按“现象 → 原因 → 解决”记下来方便对照。5.1 下载与运行阶段现象一拉模型卡在最后几个百分点反复重试磁盘空间还在一点点变少。原因权重按分片下载中断后残留的临时分片不会被立刻清掉同时系统盘剩余空间不足会让校验阶段直接失败。解决先把OLLAMA_MODELS指到大容量磁盘再重拉清理旧目录下的临时分片拉之前用ollama list确认没有同名的半成品记录必要时ollama rm清掉再重来。现象二模型能对话但回答里中英文混杂格式也散。原因这不是你的配置错了是小参数推理模型的固有毛病。R1-Zero 阶段那个“语言混合”的问题在蒸馏出来的小模型上会以更弱的形式残留。解决在 prompt 里硬性约束输出语言把temperature压到 0.5 附近如果业务对语言一致性要求高直接换更大参数的版本别在小模型上死磕。现象三短问题正常一贴长文档就崩进程直接被杀。原因num_ctx调大后 KV cache 按上限预分配加上权重本身占用显存瞬间打满操作系统直接 OOM kill 进程。解决先ollama show看默认上下文按实际输入长度设num_ctx别一步给到上限长文档场景改成切片加检索而不是把全文塞进上下文同时把并发请求数压到 1并发会成倍放大显存占用。5.2 微调与数据阶段现象四训练 loss 一路降到很低推理时输出格式全崩特殊符号乱飞。原因训练文本的对话模板跟基座预训练时用的不一致。loss 低只说明模型拟合了你的数据格式不代表它学会了正确格式。解决一律用tokenizer.apply_chat_template生成训练文本训练前后各取一条样本用同样的 tokenizer 解码看一遍肉眼确认格式和基座原生输出长得一样。现象五微调后模型变成复读机换个问法就背训练集原话。原因过拟合。学习率太大、epoch 太多、LoRA 的r给太高三个因素任何一个都可能触发。解决学习率退到 1e-4epoch 压到 1~2r从 8 降到 4lora_dropout提到 0.1训练集里混入一到两成通用对话数据防止模型把领域格式当成唯一正确输出。判断过拟合最直接的办法是留一条没进训练集的样本训练完专门测它。注意上面五条里前三条属于环境问题改配置就能过后两条属于数据问题改配置只能缓解。微调效果的上限由数据质量决定参数只决定你能不能摸到那个上限。6. 用一致性采样验证推理质量把 cons16 的思路搬到本地材料里提到 R1-Zero 的性能评估用了两个指标单次推理准确率和多次采样取一致性结果的准确率后者明显更高。这个思路在本地完全可复现而且比单看一次输出靠谱得多——小模型单次推理的偶然性太大一次答对说明不了什么。import re, requests from collections import Counter def sample_consistency(question, modeldeepseek-r1:1.5b, n16, temperature0.8): 同一问题采样 n 次抽取最终答案做多数投票模拟 consn 的评估思路 answers [] for _ in range(n): r requests.post(http://127.0.0.1:11434/api/chat, json{ model: model, messages: [{role: user, content: question}], stream: False, options: {temperature: temperature} # 要的就是随机性别固定 seed }, timeout300).json() text r[message][content].split()[-1] # 只取正式回答 m re.search(r[-]?\d(?:\.\d)?, text) # 数值题抽数字 answers.append(m.group() if m else text.strip()[:30]) return Counter(answers).most_common(3) q 一个班 40 人60% 参加数学组参加数学组的人里有一半同时参加物理组问两组都参加的有多少人 print(sample_consistency(q))这段代码的关键在temperature必须开高固定种子的话十六次采样结果完全一样投票毫无意义。抽取答案那一步的正则要按任务类型改数值题抽数字选择题抽选项字母开放题只能靠字符串相似度聚类。跑完看most_common的分布——如果第一名票数明显领先说明模型对这个题型的推理是稳的如果票数平均分散在四五个答案上那这个模型在你的任务上就是不可靠别拿单次输出去糊弄业务方。我用这套方法筛过一次内部评测集结论挺反直觉某个 7b 版本单次准确率比 1.5b 高但一致性分布反而更散说明它是在“蒙对”换一批题就露馅。从那以后我每次给模型做能力评估都强制走一遍一致性采样单次结果只当参考不当结论。希望帮到你。本文还有配套的精品资源点击获取
