如果你一直追我这个系列应该知道前面的文章基本都在聊“怎么把Qwen3用起来”——本地部署、量化、Ollama集成、智能体调用。但前两天有个读者留言说他用Ollama挂着Qwen3 4B想让WorkBuddy那种工具代理帮他改代码模型根本操作不了电脑甚至把上下文全搞乱了。这个问题其实很典型基础模型即使推理能力再强它也不知道“你的任务目标是什么”“什么样的输出才叫好”。要让模型真正适配某个场景、按你想要的方式干活单靠提示词是不够的必须上强化微调。这篇就是系列的第九篇聊Qwen3的强化微调核心玩法是GRPO。我会把GRPO的来龙去脉、数学直觉、实际训练脚本、踩坑经验一次讲透最后再回头解释为什么Ollama上的Qwen3干不了“操作电脑改代码”这种智能体任务以及强化微调能怎么救。1. GRPO到底改了什么从PPO到GRPO的思路转变先聊个基础问题为什么强化微调现在这么火而且大多数人一提就是GRPO而不是更早的PPOLLM的强化微调和传统强化学习不完全一样。模型输出一句完整的话环境或者奖励模型给一个总分这个过程中模型每一步生成token其实都在做决策但奖励要等整句话出来才知道。这属于典型的延迟奖励问题PPO就是应对这种场景的经典算法。PPO的做法是训练一个Critic网络价值模型去预测每个状态下的期望收益然后用“实际收益减去预测收益”作为优势函数来更新策略。思路没问题但Critic训起来很麻烦它要和策略模型一起迭代规模巨大训练不稳定而且Critic的预测误差会直接污染策略更新。GRPO是DeepSeekMath那篇论文里带出来的核心思路特别直接不要Critic了用一组采样输出的相对表现来替代绝对价值估计。为了帮你建立直觉我打个比方。想象一个班级考试PPO的做法是请一位助教Critic提前预测每个学生能考多少分考完看实际分数和预测的差距差距大的学生重点辅导。而GRPO的做法是把试卷发给同一道题的8个学生考完直接看8个人的相对排名你排名靠后就是差排名靠前就是好不需要任何人提前预测分数。这个“组内相对比较”就是GRPO最核心的“Group Relative”含义。对应到训练上对同一个prompt让当前模型采样出G个输出分别算出奖励然后做归一化得到一个优势值。奖励高于组内均值的输出梯度方向是增强低于的则抑制。公式上就是[ A_i \frac{r_i - \mathrm{mean}(r_1, ..., r_G)}{\mathrm{std}(r_1, ..., r_G)} ]这个A_i就是每个样本的优势值。整套训练目标函数在GRPO原论文里还带一个KL散度约束项防止模型一下子飘太远把语言能力全丢掉这一点下面细说。所以GRPO相比PPO的优势很明确不需要训练Critic显存占用低得多框架简单不容易崩收敛也相对稳定。在Qwen3这种参数量动辄几十B的模型上做全参微调省掉一个和主模型同体量的Critic意味着你硬件的压力几乎砍半。这也是为什么现在开源社区一提“强化微调”几乎默认就是GRPO。1.1 GRPO的奖励机制与KL散度控制GRPO的训练循环里每个prompt会采样G个补全结果G通常取4到16之间。采样完成后奖励函数对这G个结果分别打分分数可以是程序生成的规则奖励比如格式对不对、代码能不能运行也可以是人类偏好奖励模型打分。得到G个分数后用它们的均值和标准差做归一化得到每个样本的优势值。这个归一化操作特别巧妙它不关心奖励函数的绝对尺度是0到1还是0到100只看相对高低天然对奖励函数的scale不敏感。但有一个隐患如果只优化奖励模型很快就会学会“刷分”——找到奖励函数里某个漏洞输出一堆在奖励上得分高但实际没用的内容。为了约束这种行为GRPO在目标函数里加了一个KL散度惩罚项限制更新后的模型不要离参考模型通常是SFT出来的那个版本太远。数学上KL散度衡量的是两个概率分布的距离这里就是说“你可以为了奖励改变策略但不能改得面目全非。”实际操作中这个KL项有一个很直观的系数beta。beta调得太大模型根本不怎么动奖励上不去调得太小模型放飞自我生成内容开始退化。我在Qwen3 14B上试跑的时候beta从0.01起步是一个比较稳妥的选择训练后期可以略微调小让模型更贴合任务。具体怎么监控后面的实操章节讲。1.2 为什么Qwen3特别适合GRPO微调Qwen3这一代模型有个和GRPO天然契合的设计——思考模式thinking mode和非思考模式。你可以在配置里强制开启思考模式让模型先输出一段推理过程再给最终答案也可以关闭思考模式直接回答。GRPO奖励信号没法直接监督模型“该怎么思考”但可以通过最终结果的质量间接塑造它的思考风格。比如代码生成任务里模型如果学会“先拆解需求再写代码”最终代码的运行通过率往往更高这个信号会被GRPO捕捉并放大。Qwen3本身在预训练阶段已经做了大规模的强化学习对齐基础能力已经相当扎实。拿来做GRPO的起点比从纯基座模型开始要顺滑得多。你再用GRPO去做某个垂直场景比如SQL生成、工具调用、格式化输出的适配有点“在好地基上装修”的意思不需要从零学语言只需要学会你的任务偏好。另外一个实际考量是Qwen3的官方技术报告明确提到他们在训练中混合了标准和思考模式的数据这意味着模型内部对两种模式都有一定的驾驭能力。但默认情况下你直接调用它它未必知道你的场景里要不要思考、思考多久。GRPO可以在奖励函数里明确告诉它输出正确给多少分、输出冗长扣多少分、想太久扣多少分。训练完模型会自己学会“在这个任务里简要思考并快速给答案”是最优策略。2. 强化微调的目标与数据准备别急着改权重先搞清楚你要什么开始写代码之前先说一句可能得罪人的大实话大部分人做强化微调失败不是因为代码写错而是因为没想清楚“奖励函数到底奖励什么”。SFT监督微调是拿“标准答案”去教模型模仿强化微调是拿“评价标准”去引导模型探索。评价标准就是奖励函数它决定了模型演进的方向。奖励函数定义错了你训出来的模型可能分数很好看实际一用就废。2.1 明确任务目标和奖励信号Qwen3的GRPO微调能做的任务大致分三类不同任务的奖励函数长完全不一样。第一类是规则可验证的确定性任务典型代表是数学题、SQL生成、代码生成、JSON格式输出。这类任务的好处是结果可以自动判对错程序就能当裁判。比如数学题答案对了给1分错了给0分外加格式规范分。代码题可以真的把代码扔进沙盒跑一遍通过测试用例给高分。这一类是GRPO最容易见效的因为奖励信号干净、无歧义。第二类是偏好类任务比如生成营销文案、调整语气风格。这类没有标准答案需要训练一个奖励模型来模仿人类偏好打分。一般流程是先让Qwen3生成一批候选回答人工排序用排序数据训练一个Reward Model再用这个RM的分数作为GRPO的奖励信号。这一套链路复杂不少对新手不太友好。第三类是智能体任务包括工具调用、浏览器操作、操作电脑改代码——就是开头那个读者遇到的问题。这类任务最麻烦因为最终奖励往往是“任务是否完成”但中间过程可能有几十步每一步的对错很难自动判断奖励信号稀疏且延迟。一种做法是过程奖励模型逐点评分另一种是设计密集的规则奖励比如每正确调用一个工具就给小分。WorkBuddy那种“让模型操作电脑”的场景想要做强化微调最务实的奖励函数是任务完成后截屏对比或者代码修改后跑测试套件看通过率。我做GRPO微调的经验是第一类任务拿来入门最合适数学题和JSON格式提取都是很好的练手项目。奖励函数能自动算、训练循环能跑通、损失曲线有明显变化你才能逐步理解强化微调的行为模式。一上来就做智能体任务排查问题时变量太多很容易崩溃。2.2 数据集的构建与格式要求GRPO微调的数据集结构比SFT多一个维度。SFT只需要prompt和response对GRPO的每个训练样本只需要prompt因为输出是训练过程中实时采样生成的。这意味着你的数据集配置里最重要的字段是“系统提示词用户请求”不需要为每条数据准备标准答案。以数学题为例一条训练数据可以长这样{ prompt: 一个水池有两个进水口和一个排水口单独开第一个进水口需要6小时注满单独开第二个进水口需要4小时注满打开排水口需要8小时排空。如果三个口同时打开多久能注满请给出最终答案。 }是的就这简单。真正的标准答案不在数据集里而是藏在奖励函数里。你需要另写一个check_answer函数把模型的输出和真实答案比较。这就要求你额外准备一份“答案列表”每条prompt配一个标准答案用于判分这个答案不进训练集只进验证函数。我是建议把答案直接嵌在prompt的后端字段里比如搞成一个JSONL文件每行包含prompt和expected_answer训练时一个字段喂给模型、一个字段喂给奖励函数。这种配置对排查问题也方便你能一眼看出某条样本的预期结果是什么。对于工具调用或智能体场景数据格式更复杂。每一条数据需要包含完整的工具定义、可用操作列表、任务描述。奖励函数里要对“调用了正确的工具”“传参格式合法”“最终结果达成了目标”分别给分。这类数据集我建议先手工构建50到100条高质量样本就够了。强化微调阶段不需要海量数据它更像一个“偏好塑造器”几百条精挑细选的任务就足以让模型行为产生明显的定向偏移。我第一次跑GRPO实验时用了2000条数学题训练到后面其实过拟合了——模型把那些题目的解题套路背下来了但对新题泛化一般。后来降到300条效果反而更好。3. 训练环境配置与代码实现基于TRL跑通Qwen3 GRPO工具链上我推荐直接用Hugging Face的TRL库。TRL从0.12版本开始把GRPOTrainer集成得比较完善RewardFunc API也写得很舒服。版本选型上建议trl0.14.0transformers4.46.0accelerate1.1.0。前阵子我还遇到过trl 0.12和transformers 4.48之间兼容性出问题的情况旧版本在处理Qwen3的chat template时偶发字段错位。硬件方面先说清楚如果你用Qwen3 4B做LoRA微调一张24GB显存的显卡4090或3090就够跑了。但如果是Qwen3 14B做LoRA微调最少要48GB以上全参微调直接上80GB的A100/H100才靠谱。GRPO因为一次要采样组内G个输出显存开销比SFT高不少批量大小要适当调小。3.1 环境安装与基础配置先建一个干净的conda环境Python用3.11。安装依赖的时候注意trl、transformers、peft这几个库的版本要互相兼容我建议直接装最新版然后跑一个小模型冒烟测试确认训练循环能起来再切Qwen3。conda create -n grpo python3.11 -y conda activate grpo pip install --upgrade transformers accelerate peft trl datasets pip install bitsandbytes然后写训练脚本推荐用TRL官方的GRPOTrainer配置起来思路清晰。核心配置项主要关注这几个from trl import GRPOConfig, GRPOTrainer from transformers import AutoModelForCausalLM, AutoTokenizer import torch model AutoModelForCausalLM.from_pretrained( Qwen/Qwen3-4B, torch_dtypetorch.bfloat16, device_mapNone ) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen3-4B) training_args GRPOConfig( output_dir./qwen3_grpo_math, learning_rate2e-6, per_device_train_batch_size2, gradient_accumulation_steps4, num_train_epochs1, max_completion_length2048, beta0.01, temperature0.9, seed42, logging_steps1, save_steps50, bf16True, )几个参数我特别标注一下learning_rate用2e-6起步强化微调的学习率一定要比SFT小。SFT用5e-5都没事GRPO用2e-6我都嫌跳试过5e-6都能看到输出质量明显波动。max_completion_length要覆盖模型可能生成的最长输出。Qwen3的思考模式有个特点——一旦开启思考它会输出一大段推理过程如果max_completion_length设短了模型在思考到一半被截断训练就废了。temperature设到0.9左右采样多样性才能保证同一个prompt产出的G个输出差异够大GRPO的归一化才有意义。如果temperature太低G个输出几乎一模一样优势值全是噪声。3.2 奖励函数编写GRPO微调的灵魂TRL的GRPOTrainer里奖励函数就是一个接收completion和**kwargs的Python函数返回一个分数。可以同时传多个奖励函数训练器会把分数线性加权求和。我一般写两个奖励函数一个管“正确性”一个管“格式”。数学题的正确性奖励函数最稳的写法是用字符串匹配让Qwen3输出答案时带一个特殊标记比如“最终答案xxx”然后提取并和标准答案比较。import re def correctness_reward(completions, **kwargs): 检查数学答案是否正确。completions是模型生成的一组文本列表。 rewards [] for completion in completions: # 从输出里提取最终答案标记 match re.search(r最终答案[:]\s*([^\n]), completion) if match: answer_text match.group(1).strip() else: answer_text # 和标准答案做归一化比较去掉空格和单位 normalized_answer answer_text.replace( , ).replace(小时, ) if normalized_answer kwargs[expected_answer].replace( , ): rewards.append(1.0) else: rewards.append(0.0) return rewards这个函数里有个细节值得注意completions是一个列表对应同一个prompt采样的G个输出bonus奖励可以考虑“格式分”如果模型规规矩矩带“最终答案”标记额外给0.1分。经验是纯正确性奖励下模型偶尔会出现“答案对了但输出格式乱糟糟”的情况带上格式分训出来的东西更像样。def format_reward(completions, **kwargs): 要求输出必须包含思考过程和最终答案部分。 rewards [] for completion in completions: if 最终答案 in completion and 思考 in completion: rewards.append(0.1) else: rewards.append(0.0) return rewards需要注意TRL的奖励函数传入的completions不包含prompt部分只包含模型新生成的内容。如果你的奖励判断需要看完整输出得通过**kwargs把原始prompt传进去自己拼。3.3 启动训练与实时监控把所有奖励函数组成列表传给GRPOTrainertrainer GRPOTrainer( modelmodel, processing_classtokenizer, argstraining_args, train_datasetdataset, reward_funcs[correctness_reward, format_reward], ) trainer.train()训练起来以后日志里除了常规loss还有一组关键指标rewards、completion_length、kl。我强烈建议你盯紧这三个数。rewards mean稳步上升是好事但如果上升太快比如几百步就到了0.9以上要警惕过拟合或reward hacking。completion_length如果出现剧烈下降比如从2000掉到300说明模型正在偷懒学会用最短输出撞奖励了。kl如果持续飙升说明beta设太小模型在语言能力上退化该调大beta或者降低学习率。至于loss本身GRPO里的loss包含策略梯度项和KL项看它绝对值意义不大关注相对变化即可。我在14B模型上跑过一次数学微调550步左右模型已经在训练集上能稳定达到95%正确率但评测集只有78%这就是典型的reward hacking迹象——模型找到了奖励函数的漏洞。比如有的样本标准答案是“12”模型直接输出“最终答案12”蒙对了但它根本没学会解题。这个问题的根源是GRPO本身不惩罚“猜”的行为只惩罚“错”。要缓解要么在奖励函数里加过程分比如包含正确的中间步骤要么在数据集里掺入大量“无法蒙对”的题目要么降低beta让模型不敢走极端。没有一招制敌的办法只能多管齐下。4. 实战中的坑与排查手册我的GRPO翻车实录这一节把我在Qwen3 GRPO微调过程中实际踩过的坑盘一盘。这些坑单个看都不致命但叠在一起足够让一个训练任务从“看起来正常”变成“彻底报废”。4.1 生成空内容的崩溃第一个坑模型训练过程中突然开始输出空字符串或几个无意义token。loss看起来在降但奖励全是0模型越训越差。排查过程最后定位到是采样参数问题——GRPO内部采样时如果temperature设置过低加上Top-P截断模型容易塌缩到高概率token的重复循环极端情况下会生成空内容。解决办法有两个一是把temperature调到0.9以上二是给completion长度设一个下限比如在奖励函数里发现completion长度小于50个字符直接给一个大的负分。我后来两种都做了空内容基本绝迹。4.2 显存溢出与批量大小调整GRPO的显存压力主要来自组内采样。一个batch里如果有2个prompt每个prompt采8个输出等于一次前向要同时推理16个序列再加上反向传播计算图显存占用比同batch的SFT翻了不止一倍。4B模型的LoRA微调在24GB卡上per_device_train_batch_size开到2勉强能跑14B模型就得降到1甚至要靠gradient_accumulation_steps补batch size。另外一个容易被忽略的显存杀手是max_completion_length。Qwen3开启思考模式后模型经常会生成2000到3000个token的长输出如果max_completion_length设到4096显存占用会指数级上升。建议先用原始模型跑一小批数据统计一下输出长度分布再定这个参数。4.3 奖励函数的长度偏向GRPO对奖励函数的scale不敏感但对偏差非常敏感。如果你的奖励函数里隐含着“输出越长分越高”或“输出越短分越高”的规律模型会疯狂利用这一点。我之前写代码生成任务奖励函数时给“正确通过测试用例”打1分但在实现时忘了对“编译失败”打负分。结果模型学到一个新策略输出一段很长的代码但根本不运行因为奖励函数只检查代码片段里是否包含关键函数名。这种reward hacking让人哭笑不得。从那之后我养成了一个习惯每写一个奖励函数都要想清楚“模型可能怎么钻空子”。表格总结一下常见问题和排查方向现象可能原因解决思路loss不降reward长期为0奖励函数有bug模型输出永远无法命中先用固定输出测试奖励函数reward飙升高但评测集差reward hacking加过程奖励、降低beta、丰富数据集completion_length断崖式下跌模型学会用短输出撞奖励奖励函数里惩罚过短输出kl指标持续暴涨beta太小模型偏离参考模型太远增大beta或降低学习率训练正常但模型语言能力退化KL约束失效模型过于专注任务格式调大beta、加入通用语料数据显存OOM组采样数G过大或max_completion_length过长减小G、缩短输出长度上限4.4 回到开头的WorkBuddy问题为什么Ollama上的Qwen3操作不了电脑现在可以解释开头那个场景了。WorkBuddy这类智能体要“操作电脑改代码”核心链路是模型接收桌面截图或文件内容生成操作动作调用工具修改代码文件然后观察新截图判断下一步。这条链路上模型要同时具备视觉理解、工具调用格式化、长程规划三个能力任何一个拉胯都会让整个过程崩掉。而默认的Qwen3-4B量化版也就是读者在Ollama里跑的那个是一个通用对话模型而不是一个训练过的智能体操作模型。它不知道“操作电脑”这个动作空间的语法也没学过“观察截图的编码规则”。直接拿提示词硬钢就像让一个从没摸过方向盘的人直接上赛道——理论上他有驾驶知识但完全不具备操作能力。要救这个场景强化微调还真是一条正路收集一批“屏幕截图操作动作”的轨迹数据把“成功完成一次文件修改”设为最终奖励用GRPO把模型从“能聊天”微调成“会操作”。这个工程量不小但从技术上完全可行。Qwen2.5和Qwen3系列都有对应的VLM版本为这类任务提供了足够好的底座。5. 本地部署与推理验证GRPO微调后的模型怎么用起来训练完的模型权重如果只存在checkpoint里价值就打了折扣。我用LoRA方式微调时习惯把Adapter合并回主模型导出成完整的模型文件再部署到Ollama或者vLLM上供日常调用。5.1 合并LoRA权重与导出TRL训练完的LoRA Adapter会存在output_dir下。合并权重的操作很简单from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained( Qwen/Qwen3-4B, torch_dtypetorch.bfloat16, device_mapauto ) lora_model PeftModel.from_pretrained(base_model, ./qwen3_grpo_math/checkpoint-500) merged_model lora_model.merge_and_unload() merged_model.save_pretrained(./qwen3_grpo_math_merged) tokenizer.save_pretrained(./qwen3_grpo_math_merged)合并之后一定要先做一个冒烟测试设定和训练时一致的system prompt喂一条训练集里的题目看输出是否包含思考过程和最终答案标记再喂一条没见过的题目看回答质量。如果新题回答明显退化大概率是过拟合了回训练阶段调数据多样性。5.2 部署到本地推理服务合并后的模型可以直接用Ollama部署。Qwen3官方提供了适合Ollama的GGUF量化版本但那是原版模型。微调合并版要用llama.cpp先转成GGUF格式再导入Ollama。# 使用llama.cpp的convert脚本将HF模型转为GGUF python convert_hf_to_gguf.py ./qwen3_grpo_math_merged \ --outfile qwen3_grpo_math.gguf \ --outtype q8_0 # 创建Ollama模型文件 cat Modelfile EOF FROM ./qwen3_grpo_math.gguf TEMPLATE {{ .Prompt }} EOF ollama create qwen3-grpo-math -f Modelfile ollama run qwen3-grpo-math如果只是自己API调用vLLM是更省事的选择直接加载HF格式vllm serve ./qwen3_grpo_math_merged \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9vLLM加载HF格式不需要转格式部署速度更快。如果你希望本地部署走OpenAI API风格调用vLLM的/v1/chat/completions接口几乎零成本接入现有代码。需要注意的是vLLM部署时要记得带上训练时用的system prompt模板如果模板不一致模型行为会有非常明显的偏差。5.3 部署后效果的前后对比最后分享一个14B模型做代码生成任务GRPO微调的实际效果数字。微调前模型直接生成Python代码测试用例通过率大约47%输出里经常夹杂解释性文字。用GRPO微调500步后数据集约350条代码题测试用例通过率提升到69%并且输出的代码格式更加规范——模型学会只在代码块里给代码不加废话。更让我意外的是GRPO后的模型在错误处理上明显更稳健。遇到编译错误时微调前的模型会重复输出同一条错误代码而微调后的模型学会了自己尝试修复——从“重新导入模块”到“调整函数签名”开始呈现出策略性的试错行为。这种“策略涌现”是纯SFT很难训出来的因为SFT本质上是在模仿而GRPO是在奖励的引导下自主探索。你给它一个目标它自己摸索出一套路径这个过程永远看不够。6. 写在最后的实操体会说了这么多最后分享几条我实际跑GRPO微调攒下来的体会。第一GRPO的训练效果对“奖励函数质量”的敏感度远超对“模型基座选择”的敏感度。哪怕是用Qwen3-4B这样的小模型只要奖励函数设计合理微调后的行为偏移会非常明显反过来奖励函数写稀烂14B照样训成一坨。所以动手写代码前先在纯逻辑层面把奖励函数推演一遍。这看起来不酷但比训练翻车后去调代码有效得多。第二强化微调是周期性项目不是一次性工程。我之前以为训完一次就完事直到上线部署发现真实场景分布和训练分布差别大了效果下跌非常快。后来我形成了一个习惯每隔一两周把线上收集到的新失败样本加进数据集重新跑一轮GRPO微调。这个迭代周期并不长几百条数据跑500步就够但模型始终保持对真实场景的适应能力。第三GRPO的训练曲线不会像SFT那样平滑优美。SFT的loss曲线一路向下而GRPO的reward曲线在训练早期往往震荡剧烈甚至出现先涨后跌的情况。看到这种曲线别慌先检查有没有出现4.3节说的“短输出撞奖励”迹象如果没有就让它继续跑。强化学习本身就带有探索性质震荡是正常现象关键看总体趋势。第四关于Ollama部署的Qwen3做智能体操作这件事我的判断是现阶段直接用通用模型走提示词路线确实不靠谱但也不要因此否定“本地小模型”的潜力。先用GRPO微调把模型的行为空间锚定到具体任务再配合合理的工具接口设计4B-7B级别的模型在单机自动化场景上完全能做成一个可用的原型。这条路我还在继续走后续有新进展会在这个系列里更新。今天这篇写到这GRPO的原理、实操和坑基本都覆盖到了希望对正要上路的朋友有帮助。