LoRA 与 QLoRA 微调配方实战从 LoRA Without Regret 参考配方到 Unsloth/TRL 配置落地【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本篇文章以 agents24 仓库中llm-finetuning插件的 lora-qlora-recipes 技能 为骨架系统性讲解面向 SFT监督微调的 LoRA 与 QLoRA 适配器配置如何选择 target modules、如何按任务确定 rank 与 alpha、LoRA/QLoRA/全参微调如何抉择、有效 batch size 的边界以及 Unsloth 快路径与 plain TRL 逃生通道的完整映射。读完你将能独立产出一份可被llm-finetuning-training-engineer直接消费的校验过的适配器配置并规避 fp16 发散、rank 过高过拟合、删减 target modules 等高频失败模式。该技能在插件工作流中处于承上启下的位置finetuning-method-selection已经完成路由判定数据形状是 demonstrations 而非偏好对或可验证奖励信号因此走 SFT本技能负责产出适配器本身的最佳实践配置数据集的准备与质量校验属于 dataset-curation 的范畴而最终消费这份配置、生成可运行脚本的是 llm-finetuning-training-engineer。前置路由为什么你会走到 LoRA/QLoRA 配方本技能明确假设路由判定已经发生。finetuning-method-selection的决策树SKILL.md会先排查off-ramp——事实易变价格、文档、新闻走 RAG行为尚未定型走 prompt engineering稳定稠密领域知识且文本量在 500MB–10GB 之间才考虑 CPT 后接 SFT只有当手上数据形状是input/output demonstrations时路由才会指向本技能数据形状路由事实频繁变化价格、文档、新闻RAG而非微调期望行为仍在摸索Prompt engineering稳定的领域知识≥500MB 文本CPT 后接 SFT有 input/output demonstrationsSFT —— 见 lora-qlora-recipes本文有偏好对或 /DPO/ORPO/KTO —— 见 preference-optimization有可验证的 pass/fail 信号GRPORLVR —— 见 grpo-rlvr-training还没有 eval harness停下 —— 见 eval-harness-first也就是说本技能的输入是一条 SFT via LoRA/QLoRA 的路由决策 目标模型的尺寸等级输出是一份校验过的适配器配置即下面各小节的 kwarg 具体取值而不是自由式建议由llm-finetuning-training-engineer在 Phase 4 生成train/config.yaml与train/train.py时直接消费见 finetune.md 的 Phase 4 描述按 brief 的方法、基础模型与内存预算生成训练脚本且两份文件必须先提交再启动。参考配方LoRA Without Regret本技能的全部配置基准都来自 LoRA Without RegretThinking Machines / Schulman2025-09如今已成为 LoRA/QLoRA SFT 的既定惯例。参考配方的四个支柱是target modules 全线性、lora_alpha 2 * r、学习率约为等效全参微调的 10 倍、有效 batch size 小于 32。下面逐一展开。Target Modules全线性层而非仅注意力参考配方要求全线性模块不能只盯注意力头target_modules [ q_proj, k_proj, v_proj, o_proj, # attention gate_proj, up_proj, down_proj, # MLP —— 最关键 ]其中MLP 层gate_proj、up_proj、down_proj最值得打——只打注意力层是更早、更弱的旧惯例。为了省内存而删减模块属于下文 Failure Modes 中的失败模式不是合法优化适配器参数只占模型总参数的一小部分砍掉 MLP 三件套几乎不动内存却会实打实损伤质量。若内存真的吃紧正确顺序是转 QLoRA、降 rank、降 batch、缩短 packing 长度而不是修剪 target modules。Alpha 与学习率lora_alpha 2 * r是既定惯例依据 NeurIPS 2025 的 intruder dimensions 结果。不要脱离 rank 单独手工调 alpha——每次都由 rank 推导而来。例如r32时lora_alpha64。LoRA 学习率 ≈ 等效全参微调学习率的 10 倍。具体到 QLoRA2e-4 是标准起点。这一点也是从全参微调配置移植到 LoRA 时最常见的单一错误来源——LR 原样照搬会导致适配器欠训练。完整的超参表与工作示例见 references/hyperparameters.md。Rank 按任务决定而非全局默认rank 是任务形状决定的不存在单一全局默认值任务RankRLGRPO/RLVR 适配器1–32通用默认16–32规模化 SFT最高约 256更高 rank 并不自动等于更好——它提升记忆能力的速度与提升泛化能力的速度一样快。应该从任务对应的那一行起步只有当较低 rank 在 held-out eval 上可测量地欠拟合时才上调一行而不是把更高 rank 当默认对冲。references/hyperparameters.md 提供了更细的 rank/alpha 对照表注意每一行都满足lora_alpha 2 * r任务类型Rankrlora_alpha说明RL 适配器GRPO/RLVR1–322–64对于已具备能力的底座模型低位1–8很常见通用 SFT 默认16–3232–64没有特定理由升高/降低时的起点规模化 SFT大而多样的指令集最高约 256最高约 512只有数据集足够大且多样、用得上额外容量时才合理——参考下方 rsLoRA 注记有效 Batch Size控制在 32 以下保持有效 batch size 小于 32。本配方正是在这个规模上完成验证的——把有效 batch 推得更高是未经测试的外推不是免费的吞吐量收益。references/hyperparameters.md补充了关键细节有效 batch 的计算公式是per_device_batch_size * gradient_accumulation_steps * num_devices。多卡或高累积步数的配置可能单卡 batch 看着不大、乘积却已越过 32所以必须算乘积不能只看单卡数字。例如下面工作配置中的4 * 4 16单卡就稳定压在 32 上限之内。Unsloth 默认值与get_peft_model完整调用Unsloth 是本插件假定的默认快路径参考实现——唯一例外是messages 形状的对话式 SFT assistant_only_lossTrue这一组合Unsloth 2026.7.x 的编译版 trainer 根本没有 messages 形状路径此时 plain-TRL 逃生通道references/unsloth-trl-mapping.md是默认路径而非罕见回退。这一点下文展开。Unsloth 的开箱默认值及其设置原因lora_dropout0—— 优化后的内核路径假设零 dropout设置非零值会放弃融合内核加速。biasnone—— 偏置项在当前 rank 区间只增加适配器参数质量收益可忽略。use_gradient_checkpointingunsloth—— 这是 Unsloth 自有的 checkpointing 变体而非原生 HF checkpointing相对不开 checkpointing 大约节省30% VRAM对应 memory-math.md 中激活项约 30% 的节省口径。optimadamw_8bit—— 8-bit AdamW 在 LoRA/QLoRA 适配器规模下以可忽略的质量影响削减优化器状态内存memory-math.md 的估算为fp32 状态 8 字节/参数8-bit 约 2 字节/参数约四分之一。random_state固定—— 钉住 LoRA 初始化以保证跨运行可复现把它当种子对待而不是可调超参。它们会一起出现在get_peft_model调用上model FastLanguageModel.get_peft_model( model, r32, target_modulestarget_modules, lora_alpha64, # 2 * r lora_dropout0, biasnone, use_gradient_checkpointingunsloth, random_state3407, )每个 kwarg 的精确名称及其 plain-TRL/PEFT 等价物以及含SFTConfig的完整工作配置分别见 references/unsloth-trl-mapping.md 与 references/hyperparameters.md。LoRA vs QLoRA vs 全参微调什么时候选什么场景默认选择在 demonstrations 上适配行为LoRA基础模型在目标 rank 下装不进 bf16QLoRA注入稠密的新领域知识全参微调见 finetuning-method-selection不确定选哪个LoRA——仅在内存逼迫时才升级到 QLoRA要点拆解QLoRA NF4 量化冻结基座权重 BF16 适配器。这正是 65B 级模型能在 48GB 显存上训练的原因——量化基座才是内存收益来源适配器本身不是。memory-math.md 给出了量级锚点8B 级 bf16 LoRA 权重约 16GB8B 级 QLoRAint4 NF4约 4GB约 4 倍缩减70B 级 QLoRA 理想公式约 35GB、计入量化元数据与运行时开销后以≈40GB作为真实锚点——这解释了70B 级走 QLoRA 而非 bf16后者仅权重就约 140GB。全参微调不是默认。把它留给在权重层面改变模型知识的稠密知识注入场景本技能范围内的一切其他场景LoRA 或 QLoRA 才是起点假设。DGX Spark 上 QLoRA 可能比等效 bf16 LoRA 先 OOM即便 QLoRA 的稳态占用更小——bitsandbytes 的反量化缓冲区是训练加载期间尖峰的瞬态 CUDA 侧分配。因此一个 QLoRA OOM 并不证明模型装不下dgx-spark-ops插件的 spark-memory-thermal-ops 技能覆盖完整的 OOM 补救阶梯下一步该试的是 bf16 LoRA而不是进一步缩小 QLoRA。这也与 llm-finetuning-training-engineer 的失败分级一致UMA OOM 按其 OOM Ladder 固定顺序处置——先 flush再降 batch 或 packing 长度然后降级方法bf16 LoRA 在 QLoRA 之前且降 batch 永远不是第一步。完整工作配置UnslothFastLanguageModelSFTConfig以下为r32通用默认 rank、QLoRA、标准 LR 的完整自洽配置来自 references/hyperparameters.md该文件避免指名任何具体基础模型一律按尺寸等级标注具体用哪个模型查finetuning-method-selection的references/model-catalog.mdfrom unsloth import FastLanguageModel from trl import SFTConfig, SFTTrainer BASE_MODEL from model catalog # 由尺寸等级 任务决定不由本文件决定 model, tokenizer FastLanguageModel.from_pretrained( model_nameBASE_MODEL, max_seq_length2048, dtypeNone, # 按硬件自动检测 bf16/fp16 load_in_4bitTrue, # QLoRA 路径 —— bf16 LoRA 时置 False ) target_modules [ q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj, ] model FastLanguageModel.get_peft_model( model, r32, target_modulestarget_modules, lora_alpha64, # 2 * r lora_dropout0, biasnone, use_gradient_checkpointingunsloth, random_state3407, use_rsloraFalse, # r32 阈值 —— 此处保持关闭除非观察到不稳定 ) import torch # 强制 bf16 前先检查硬件 BF16 支持 —— 见 SKILL.md 失败模式。 # 在 BF16 支持不佳的硬件上用 fp16 训练是 loss 尖峰与静默发散的已知来源 # 因此这是硬性前置条件不是配置风格选择。 if not torch.cuda.is_bf16_supported(): raise RuntimeError( This GPU does not support BF16 — do not fall back to fp16True as if it were equivalent; pick hardware with BF16 support instead (see SKILL.md Failure Modes). ) training_args SFTConfig( output_dir./outputs, max_length2048, dataset_text_fieldtext, per_device_train_batch_size4, gradient_accumulation_steps4, # 有效 batch 16单卡—— 保持在 32 以下 learning_rate2e-4, # QLoRA 标准 bf16True, # 上方已设门禁 —— 绝不 fp16见 SKILL.md 失败模式 optimadamw_8bit, num_train_epochs3, logging_steps10, seed3407, ) trainer SFTTrainer( modelmodel, processing_classtokenizer, # 当前 TRL —— 不是 tokenizer train_datasettrain_dataset, argstraining_args, ) trainer.train()这个块是内部自洽的r32→lora_alpha642x 规则load_in_4bitTrue→learning_rate2e-4QLoRA 标准 LRbf16True绝不 fp16有效 batch4 * 4 16低于 32 上限。改动其中任何一项——rank、量化或 batch 形状——都应触发对照上表复查其他项而不是孤立地编辑。学习率细表从哪起步、何时保守references/hyperparameters.md 的学习率表明确LoRA/QLoRA 学习率约为等效全参微调 LR 的10 倍这是移植全参配置到 LoRA 时最常踩的坑——LR 原样照搬会让适配器欠训练。方法LR 区间使用时机QLoRA标准2e-4QLoRA SFT 的默认起点LoRA保守1e-4更大的基础模型、更高 rank或 2e-4 下已出现不稳定LoRA非常保守5e-5续跑、细粒度行为调整或基座已接近目标行为这些是围绕其做 sweep 的起点而非固定常数——但要从这里起步而不是把全参微调的 LR 原样搬过来。rsLoRA何时值得打开Rank-stabilized LoRArsLoRA把适配器更新缩放从alpha / r改为alpha / sqrt(r)。它是可选的且只在r ≥ 32时才值得开启——低于该 rank标准缩放已足够稳定rsLoRA 不会实质改变结果。如果规模化 SFT 那一行rank 最高约 256生效请打开 rsLoRA通用默认或 RL 行保持关闭除非观察到特定不稳定。在 PEFT 中对应LoraConfig(use_rsloraTrue/False)kwarg 名称相同见 unsloth-trl-mapping.md。Unsloth ↔ TRL/PEFT 配置映射逃生通道的基础Unsloth 是 PEFT 与 TRL 之上的快速内核封装不是替代 API——Unsloth 的每个 kwarg 都有对应的 plain TRL/PEFT 等价物。映射表使回退到 plain TRL变成机械操作而不是从零重写Unsloth kwargTRL/PEFT 等价物说明FastLanguageModel.from_pretrained(model_name...)AutoModelForCausalLM.from_pretrained(...)AutoTokenizer.from_pretrained(...)Unsloth 将模型分词器加载与内核打补丁融合为一次调用load_in_4bitTrueBitsAndBytesConfig(load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16)传入from_pretrained两边都是 QLoRA 路径FastLanguageModel.get_peft_model(r..., target_modules..., lora_alpha..., lora_dropout..., bias..., random_state...)peft.LoraConfig(r..., target_modules..., lora_alpha..., lora_dropout..., bias...)peft.get_peft_model(model, config)random_state→ 在get_peft_model前设置种子Unsloth 的调用是生成同一份LoraConfig的薄封装use_gradient_checkpointingunslothSFTConfig/TrainingArguments中的gradient_checkpointingTrueUnsloth 变体是同一想法的更快/更低内存实现——不是不同功能。plain TRL 的gradient_checkpointingTrue是正确回退只是 VRAM 节省更少约少 30%optimadamw_8bitSFTConfig(optimadamw_8bit)相同字符串、相同 bitsandbytes 优化器无需翻译use_rsloraTrue/FalseLoraConfig(use_rsloraTrue/False)在 PEFT 中同名同 flagmax_seq_length传给FastLanguageModel.from_pretrainedSFTConfig(max_length...)当前 TRL字段是SFTConfig上的max_length由max_seq_length更名不在 trainer 调用或 plain TRL 的from_pretrained上dataset_text_fieldUnsloth 示例常在 trainer 上设置SFTConfig(dataset_text_field...)当前 TRL同样位于SFTConfig上random_state3407数据/适配器初始化种子SFTConfig(seed3407)做 trainer 级播种两者都设——Unsloth 的random_state专门播种 LoRA 初始化SFTConfig.seed播种 trainer 自身的 RNG 使用当前 TRL API 的两个注意点两个近期变更过的 API 面过时示例包括部分 Unsloth cookbook 片段仍在使用旧写法是processing_class不是tokenizer。SFTTrainer(tokenizertokenizer, ...)是旧的、已移除或废弃的形式。当前 TRL 接受SFTTrainer(processing_classtokenizer, ...)。配置或示例若仍传tokenizer运行前必须更新——这是把旧配方向前移植时最常见的 stale-API 错误。max_length由max_seq_length更名与dataset_text_field位于SFTConfig上而不是散落在 trainer 调用或模型加载器各处。在SFTConfig实例上一次设置好不要在流水线其他地方重复。已知的 Unsloth 2026.7.x 限制真实复现过的四个坑references/unsloth-trl-mapping.md 记录了在 Unsloth 2026.7.2transformers 5.13.1trl 1.8.0上训练真实 messages 形状 SFT 时确认的四个缺口——每个都在真实 load/train 中复现过均非假设1.assistant_only_lossTrue时没有 messages 形状路径Unsloth 的编译版SFTTrainer从unsloth被导入的那一刻起就进程级 monkeypatch 到trl.SFTTrainer上进程内不可逆且不因是否实际使用FastLanguageModel而门控自带手写_prepare_dataset只按列名识别四种数据集形状预分词input_ids/labels、promptcompletion、扁平dataset_text_field、或返回预渲染字符串的formatting_func。messages 形状的对话式数据集路径完全不存在。formatting_func只能返回扁平文本这迫使在 trainer 看到每轮边界之前就预渲染聊天模板——正是 dataset-curation 的references/formats-and-templates.md所警告的扁平文本反模式对整个序列计算 loss使assistant_only_loss失效。修复使用下方 plain TRL PEFT 逃生通道——这不是可以等待的罕见 point-release 回归而是 Unsloth 2026.7.x 对该组合messages 数据集 assistant_only_lossTrue 不打包的当前状态。经两次独立运行确认Unsloth 路径在 trainer 构造时立即报错同样超参在从不 importunsloth、改用 plaintransformers.AutoModelForCausalLMpeft.LoraConfig/get_peft_modeltrl.SFTTrainer后干净地端到端跑通。2.attn_implementationkwarg 被静默丢弃FastLanguageModel.from_pretrained(..., attn_implementationsdpa)不能可靠地强制 SDPA。Unsloth 的加载器调用自己的注意力解析辅助函数不转发调用者的attn_implementation随后干脆丢弃该 kwarg——因此只要可导入的 flash-attn 构建存在无论请求什么都会被自动选中。已确认显式传attn_implementationsdpa仍解析为model.config._attn_implementation flash_attention_2。唯一可用的覆写是在调用from_pretrained前 monkeypatch——要严格限定作用域因为HAS_FLASH_ATTENTION是模块级全局还会影响同一进程后续的任何其他from_pretrained调用同一脚本或 notebook 单元中的第二次模型加载会静默继承该 flag 上次的值import unsloth.models._utils as unsloth_utils _original unsloth_utils.HAS_FLASH_ATTENTION try: unsloth_utils.HAS_FLASH_ATTENTION False model, tokenizer FastLanguageModel.from_pretrained(...) assert model.config._attn_implementation sdpa, ( fexpected sdpa, got {model.config._attn_implementation} ) finally: unsloth_utils.HAS_FLASH_ATTENTION _original这仅在try块期间把解析器逼到 SDPA 分支即使from_pretrained抛错也会在finally中恢复原值并断言解析器确实落在 SDPA 而非静默穿透。在 plain TRL/PEFT上面的逃生通道中传给AutoModelForCausalLM.from_pretrained的attn_implementationsdpa会被正确遵守——这是 Unsloth 专属缺口不是 TRL 的通用问题。3.padding_free与 plain-TRLSFTConfig的冲突把 plaintrl.SFTConfig(max_length1024, packingFalse, ...)即不碰padding_free、与 TRL 文档默认padding_freeFalse一致传入 Unsloth 的编译版 trainer仍可能抛出ValueError: When padding_freeTrue without packing, max_length is not enforced...。Unsloth 自带的编译版SFTConfig等价 dataclass 默认padding_free None其解析路径中的某处即使对由 plaintrl.SFTConfig构建的args实例也会把它变成真值。修复无论走哪条路径只要经过 Unsloth 训练就显式传padding_freeFalse——廉价保险。4. TRL 的聊天模板自动打补丁是精确字符串匹配在抛出 dataset-curation SKILL.md 所述template lacks{% generation %}错误之前TRL 1.8.0 的SFTTrainer.__init__会调用内部get_training_chat_template()尝试用约 18 个硬编码的已知模型训练模板之一trl.chat_template_utils按 tokenizerchat_template的精确字符串相等做替换。若模型自带的模板与表项不逐字匹配——即便几乎相同——自动打补丁会静默失败TRL 抛错。修复模式手工给 tokenizer 实际模板的副本打补丁——在助手轮内容区间外包上{% generation %}...{% endgeneration %}标记角色标记在区间外、turn 结束 token 在区间内与 TRL 的is_chat_template_stop_token_trained检查一致保留真实模板的每个分支工具调用、逐轮特例处理——通用回退常量不会有这些。将打补丁后的模板仅内存写入tokenizer.chat_template绝不覆写基础模型目录自带的模板文件。逃生通道何时回退到 plain TRL对 messages 形状 SFT assistant_only_lossTrue这是上文 Known Limitations 部分规定的默认路径而非最后手段的回退。对其他所有训练模式Unsloth 发布快速 point release某个 point release 偶尔会在特定模式collator、chunked-loss 路径、特定模型架构上回归直到下个补丁修复。无论哪种情况流程一致窄范围复现——确认问题出在 Unsloth 封装而非底层配置rank、alpha、LR、target modules 仍原样适用。直接回退到 plain TRL PEFT——用上方映射表把每个 Unsloth kwarg 翻译成 TRL/PEFT 等价物。超参不变——只是由哪个库来设置它们。补丁落地后重新钉回 Unsloth——仅针对真正的回归所覆盖的模式先查 Known Limitations 一节——结构性缺口如 messages 形状路径不会在下一个 point release 自动解决除非 changelog 条目确认。llm-finetuning-training-engineer的方法部分agent 定义正是这样执行默认按 Unsloth 快路径生成脚本当 point-release 回归迫使回退时走lora-qlora-recipes的references/unsloth-trl-mapping.md中的逃生通道流程而不是凭记忆手工翻译配置。失败模式三个看起来像训练 bug、实则是配置问题的坑本技能总结了三个高频失败模式且它们共享同一模式表面看像训练循环 bugloss 尖峰、平台期、记忆化实际都是违背了上文参考配方的配置选择。在调试训练循环本身之前先对照本技能检查配置1. 非 BF16 GPU 上的 fp16 发散在不具备扎实 BF16 支持的硬件上用 fp16 训练是 loss 尖峰与静默发散的已知来源。凡硬件支持处强制bf16True不要把回退到 fp16 当成等价方案。选 dtype 前先检查硬件支持python -c import torch; print(torch.cuda.is_bf16_supported())这与llm-finetuning-training-engineer的失败分级第一类Divergence完全对应先确认bf16True与硬件 BF16 支持fp16 在不支持 BF16 的硬件上是已知的静默发散源。references/hyperparameters.md的工作配置甚至把该检查做成了硬门禁——不支持 BF16 就直接抛RuntimeError绝不静默回退 fp16。2. 小数据集上 rank 过高导致过拟合为规模化 SFT最高约 256挑选的 rank用在背后没有规模的 dataset 上是记忆化而非泛化。rank 要对照上文的 Rank by Task 表匹配任务而不是挑最大可用数字。3. 删减 target modules 省内存质量受损、节省可忽略gate_proj/up_proj/down_proj上的适配器参数只占模型总尺寸的一小部分——砍掉它们几乎不动内存却可测量地损害质量。内存吃紧时先转 QLoRA、降 rank/batch/pack 长度最后才考虑修剪 target modules。与数据集侧的分工模板、masking 与 packing本技能明确不管数据集准备——那是 dataset-curation 的职责。但配置 LoRA/QLoRA 的人需要理解两个直接影响本配置质量的交叉点模板先于拼接任何拼接或 packing 之前应用目标模型的聊天模板先 pack 原始文本再对打包后的 blob 做模板会破坏轮次边界使角色标记错位。会话数据保持messages形状、由 trainer 负责模板化与 masking当前 TRL 的assistant_only_lossTrue——预渲染成扁平文本字段会毁掉 masking 所需的轮次边界。packing 的强制检查packing 可消除 40–70% 的 padding 计算浪费但会改变 batch 语义与 LR schedule 里程碑应按 packed-sequence 数量重算。启用 packing 前必须解码并人工检查 5–10 条 packed 序列确认示例边界、模板标记与 assistant-only loss mask 都完好——packing bug 是静默的loss 曲线看似正常数小时后才在 eval 质量上暴露。dataset-curation的 Phase 2 Exit Checklist 六项格式匹配方法、模板先于拼接、loss 仅 assistant 轮、5–10 条 packed 序列已解码检查、≥25% 真实数据、数据集卡六字段齐全正是/finetune命令在启动训练前检查的关卡。结语这份配置在整个微调生命周期中的位置在llm-finetuning插件与/finetune命令的七阶段生命周期finetune.md中本技能产出的是 Phase 4 训练阶段的核心输入一份校验过的 LoRA/QLoRA 适配器配置。路由由finetuning-method-selection完成Phase 1数据集卡与验证报告由dataset-curation交付Phase 2环境预检Phase 3DGX Spark 走dgx-spark-ops的 preflight 与 G1–G10 检查其他硬件走 generic-nvidia 检查先于脚本生成而 Phase 5 的 checkpoint 门禁与 Phase 6 的导出则分别属于checkpoint-promotion与quantized-export。理解了本文的 target modules、rank/alpha、LR、batch、Unsloth 默认值与逃生通道你就能在任何一步出问题时把看起来像训练 bug的现象快速定位回配置层面——这正是本技能存在的意义。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LoRA 与 QLoRA 微调配方实战：从 LoRA Without Regret 参考配方到 Unsloth/TRL 配置落地
LoRA 与 QLoRA 微调配方实战从 LoRA Without Regret 参考配方到 Unsloth/TRL 配置落地【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本篇文章以 agents24 仓库中llm-finetuning插件的 lora-qlora-recipes 技能 为骨架系统性讲解面向 SFT监督微调的 LoRA 与 QLoRA 适配器配置如何选择 target modules、如何按任务确定 rank 与 alpha、LoRA/QLoRA/全参微调如何抉择、有效 batch size 的边界以及 Unsloth 快路径与 plain TRL 逃生通道的完整映射。读完你将能独立产出一份可被llm-finetuning-training-engineer直接消费的校验过的适配器配置并规避 fp16 发散、rank 过高过拟合、删减 target modules 等高频失败模式。该技能在插件工作流中处于承上启下的位置finetuning-method-selection已经完成路由判定数据形状是 demonstrations 而非偏好对或可验证奖励信号因此走 SFT本技能负责产出适配器本身的最佳实践配置数据集的准备与质量校验属于 dataset-curation 的范畴而最终消费这份配置、生成可运行脚本的是 llm-finetuning-training-engineer。前置路由为什么你会走到 LoRA/QLoRA 配方本技能明确假设路由判定已经发生。finetuning-method-selection的决策树SKILL.md会先排查off-ramp——事实易变价格、文档、新闻走 RAG行为尚未定型走 prompt engineering稳定稠密领域知识且文本量在 500MB–10GB 之间才考虑 CPT 后接 SFT只有当手上数据形状是input/output demonstrations时路由才会指向本技能数据形状路由事实频繁变化价格、文档、新闻RAG而非微调期望行为仍在摸索Prompt engineering稳定的领域知识≥500MB 文本CPT 后接 SFT有 input/output demonstrationsSFT —— 见 lora-qlora-recipes本文有偏好对或 /DPO/ORPO/KTO —— 见 preference-optimization有可验证的 pass/fail 信号GRPORLVR —— 见 grpo-rlvr-training还没有 eval harness停下 —— 见 eval-harness-first也就是说本技能的输入是一条 SFT via LoRA/QLoRA 的路由决策 目标模型的尺寸等级输出是一份校验过的适配器配置即下面各小节的 kwarg 具体取值而不是自由式建议由llm-finetuning-training-engineer在 Phase 4 生成train/config.yaml与train/train.py时直接消费见 finetune.md 的 Phase 4 描述按 brief 的方法、基础模型与内存预算生成训练脚本且两份文件必须先提交再启动。参考配方LoRA Without Regret本技能的全部配置基准都来自 LoRA Without RegretThinking Machines / Schulman2025-09如今已成为 LoRA/QLoRA SFT 的既定惯例。参考配方的四个支柱是target modules 全线性、lora_alpha 2 * r、学习率约为等效全参微调的 10 倍、有效 batch size 小于 32。下面逐一展开。Target Modules全线性层而非仅注意力参考配方要求全线性模块不能只盯注意力头target_modules [ q_proj, k_proj, v_proj, o_proj, # attention gate_proj, up_proj, down_proj, # MLP —— 最关键 ]其中MLP 层gate_proj、up_proj、down_proj最值得打——只打注意力层是更早、更弱的旧惯例。为了省内存而删减模块属于下文 Failure Modes 中的失败模式不是合法优化适配器参数只占模型总参数的一小部分砍掉 MLP 三件套几乎不动内存却会实打实损伤质量。若内存真的吃紧正确顺序是转 QLoRA、降 rank、降 batch、缩短 packing 长度而不是修剪 target modules。Alpha 与学习率lora_alpha 2 * r是既定惯例依据 NeurIPS 2025 的 intruder dimensions 结果。不要脱离 rank 单独手工调 alpha——每次都由 rank 推导而来。例如r32时lora_alpha64。LoRA 学习率 ≈ 等效全参微调学习率的 10 倍。具体到 QLoRA2e-4 是标准起点。这一点也是从全参微调配置移植到 LoRA 时最常见的单一错误来源——LR 原样照搬会导致适配器欠训练。完整的超参表与工作示例见 references/hyperparameters.md。Rank 按任务决定而非全局默认rank 是任务形状决定的不存在单一全局默认值任务RankRLGRPO/RLVR 适配器1–32通用默认16–32规模化 SFT最高约 256更高 rank 并不自动等于更好——它提升记忆能力的速度与提升泛化能力的速度一样快。应该从任务对应的那一行起步只有当较低 rank 在 held-out eval 上可测量地欠拟合时才上调一行而不是把更高 rank 当默认对冲。references/hyperparameters.md 提供了更细的 rank/alpha 对照表注意每一行都满足lora_alpha 2 * r任务类型Rankrlora_alpha说明RL 适配器GRPO/RLVR1–322–64对于已具备能力的底座模型低位1–8很常见通用 SFT 默认16–3232–64没有特定理由升高/降低时的起点规模化 SFT大而多样的指令集最高约 256最高约 512只有数据集足够大且多样、用得上额外容量时才合理——参考下方 rsLoRA 注记有效 Batch Size控制在 32 以下保持有效 batch size 小于 32。本配方正是在这个规模上完成验证的——把有效 batch 推得更高是未经测试的外推不是免费的吞吐量收益。references/hyperparameters.md补充了关键细节有效 batch 的计算公式是per_device_batch_size * gradient_accumulation_steps * num_devices。多卡或高累积步数的配置可能单卡 batch 看着不大、乘积却已越过 32所以必须算乘积不能只看单卡数字。例如下面工作配置中的4 * 4 16单卡就稳定压在 32 上限之内。Unsloth 默认值与get_peft_model完整调用Unsloth 是本插件假定的默认快路径参考实现——唯一例外是messages 形状的对话式 SFT assistant_only_lossTrue这一组合Unsloth 2026.7.x 的编译版 trainer 根本没有 messages 形状路径此时 plain-TRL 逃生通道references/unsloth-trl-mapping.md是默认路径而非罕见回退。这一点下文展开。Unsloth 的开箱默认值及其设置原因lora_dropout0—— 优化后的内核路径假设零 dropout设置非零值会放弃融合内核加速。biasnone—— 偏置项在当前 rank 区间只增加适配器参数质量收益可忽略。use_gradient_checkpointingunsloth—— 这是 Unsloth 自有的 checkpointing 变体而非原生 HF checkpointing相对不开 checkpointing 大约节省30% VRAM对应 memory-math.md 中激活项约 30% 的节省口径。optimadamw_8bit—— 8-bit AdamW 在 LoRA/QLoRA 适配器规模下以可忽略的质量影响削减优化器状态内存memory-math.md 的估算为fp32 状态 8 字节/参数8-bit 约 2 字节/参数约四分之一。random_state固定—— 钉住 LoRA 初始化以保证跨运行可复现把它当种子对待而不是可调超参。它们会一起出现在get_peft_model调用上model FastLanguageModel.get_peft_model( model, r32, target_modulestarget_modules, lora_alpha64, # 2 * r lora_dropout0, biasnone, use_gradient_checkpointingunsloth, random_state3407, )每个 kwarg 的精确名称及其 plain-TRL/PEFT 等价物以及含SFTConfig的完整工作配置分别见 references/unsloth-trl-mapping.md 与 references/hyperparameters.md。LoRA vs QLoRA vs 全参微调什么时候选什么场景默认选择在 demonstrations 上适配行为LoRA基础模型在目标 rank 下装不进 bf16QLoRA注入稠密的新领域知识全参微调见 finetuning-method-selection不确定选哪个LoRA——仅在内存逼迫时才升级到 QLoRA要点拆解QLoRA NF4 量化冻结基座权重 BF16 适配器。这正是 65B 级模型能在 48GB 显存上训练的原因——量化基座才是内存收益来源适配器本身不是。memory-math.md 给出了量级锚点8B 级 bf16 LoRA 权重约 16GB8B 级 QLoRAint4 NF4约 4GB约 4 倍缩减70B 级 QLoRA 理想公式约 35GB、计入量化元数据与运行时开销后以≈40GB作为真实锚点——这解释了70B 级走 QLoRA 而非 bf16后者仅权重就约 140GB。全参微调不是默认。把它留给在权重层面改变模型知识的稠密知识注入场景本技能范围内的一切其他场景LoRA 或 QLoRA 才是起点假设。DGX Spark 上 QLoRA 可能比等效 bf16 LoRA 先 OOM即便 QLoRA 的稳态占用更小——bitsandbytes 的反量化缓冲区是训练加载期间尖峰的瞬态 CUDA 侧分配。因此一个 QLoRA OOM 并不证明模型装不下dgx-spark-ops插件的 spark-memory-thermal-ops 技能覆盖完整的 OOM 补救阶梯下一步该试的是 bf16 LoRA而不是进一步缩小 QLoRA。这也与 llm-finetuning-training-engineer 的失败分级一致UMA OOM 按其 OOM Ladder 固定顺序处置——先 flush再降 batch 或 packing 长度然后降级方法bf16 LoRA 在 QLoRA 之前且降 batch 永远不是第一步。完整工作配置UnslothFastLanguageModelSFTConfig以下为r32通用默认 rank、QLoRA、标准 LR 的完整自洽配置来自 references/hyperparameters.md该文件避免指名任何具体基础模型一律按尺寸等级标注具体用哪个模型查finetuning-method-selection的references/model-catalog.mdfrom unsloth import FastLanguageModel from trl import SFTConfig, SFTTrainer BASE_MODEL from model catalog # 由尺寸等级 任务决定不由本文件决定 model, tokenizer FastLanguageModel.from_pretrained( model_nameBASE_MODEL, max_seq_length2048, dtypeNone, # 按硬件自动检测 bf16/fp16 load_in_4bitTrue, # QLoRA 路径 —— bf16 LoRA 时置 False ) target_modules [ q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj, ] model FastLanguageModel.get_peft_model( model, r32, target_modulestarget_modules, lora_alpha64, # 2 * r lora_dropout0, biasnone, use_gradient_checkpointingunsloth, random_state3407, use_rsloraFalse, # r32 阈值 —— 此处保持关闭除非观察到不稳定 ) import torch # 强制 bf16 前先检查硬件 BF16 支持 —— 见 SKILL.md 失败模式。 # 在 BF16 支持不佳的硬件上用 fp16 训练是 loss 尖峰与静默发散的已知来源 # 因此这是硬性前置条件不是配置风格选择。 if not torch.cuda.is_bf16_supported(): raise RuntimeError( This GPU does not support BF16 — do not fall back to fp16True as if it were equivalent; pick hardware with BF16 support instead (see SKILL.md Failure Modes). ) training_args SFTConfig( output_dir./outputs, max_length2048, dataset_text_fieldtext, per_device_train_batch_size4, gradient_accumulation_steps4, # 有效 batch 16单卡—— 保持在 32 以下 learning_rate2e-4, # QLoRA 标准 bf16True, # 上方已设门禁 —— 绝不 fp16见 SKILL.md 失败模式 optimadamw_8bit, num_train_epochs3, logging_steps10, seed3407, ) trainer SFTTrainer( modelmodel, processing_classtokenizer, # 当前 TRL —— 不是 tokenizer train_datasettrain_dataset, argstraining_args, ) trainer.train()这个块是内部自洽的r32→lora_alpha642x 规则load_in_4bitTrue→learning_rate2e-4QLoRA 标准 LRbf16True绝不 fp16有效 batch4 * 4 16低于 32 上限。改动其中任何一项——rank、量化或 batch 形状——都应触发对照上表复查其他项而不是孤立地编辑。学习率细表从哪起步、何时保守references/hyperparameters.md 的学习率表明确LoRA/QLoRA 学习率约为等效全参微调 LR 的10 倍这是移植全参配置到 LoRA 时最常踩的坑——LR 原样照搬会让适配器欠训练。方法LR 区间使用时机QLoRA标准2e-4QLoRA SFT 的默认起点LoRA保守1e-4更大的基础模型、更高 rank或 2e-4 下已出现不稳定LoRA非常保守5e-5续跑、细粒度行为调整或基座已接近目标行为这些是围绕其做 sweep 的起点而非固定常数——但要从这里起步而不是把全参微调的 LR 原样搬过来。rsLoRA何时值得打开Rank-stabilized LoRArsLoRA把适配器更新缩放从alpha / r改为alpha / sqrt(r)。它是可选的且只在r ≥ 32时才值得开启——低于该 rank标准缩放已足够稳定rsLoRA 不会实质改变结果。如果规模化 SFT 那一行rank 最高约 256生效请打开 rsLoRA通用默认或 RL 行保持关闭除非观察到特定不稳定。在 PEFT 中对应LoraConfig(use_rsloraTrue/False)kwarg 名称相同见 unsloth-trl-mapping.md。Unsloth ↔ TRL/PEFT 配置映射逃生通道的基础Unsloth 是 PEFT 与 TRL 之上的快速内核封装不是替代 API——Unsloth 的每个 kwarg 都有对应的 plain TRL/PEFT 等价物。映射表使回退到 plain TRL变成机械操作而不是从零重写Unsloth kwargTRL/PEFT 等价物说明FastLanguageModel.from_pretrained(model_name...)AutoModelForCausalLM.from_pretrained(...)AutoTokenizer.from_pretrained(...)Unsloth 将模型分词器加载与内核打补丁融合为一次调用load_in_4bitTrueBitsAndBytesConfig(load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16)传入from_pretrained两边都是 QLoRA 路径FastLanguageModel.get_peft_model(r..., target_modules..., lora_alpha..., lora_dropout..., bias..., random_state...)peft.LoraConfig(r..., target_modules..., lora_alpha..., lora_dropout..., bias...)peft.get_peft_model(model, config)random_state→ 在get_peft_model前设置种子Unsloth 的调用是生成同一份LoraConfig的薄封装use_gradient_checkpointingunslothSFTConfig/TrainingArguments中的gradient_checkpointingTrueUnsloth 变体是同一想法的更快/更低内存实现——不是不同功能。plain TRL 的gradient_checkpointingTrue是正确回退只是 VRAM 节省更少约少 30%optimadamw_8bitSFTConfig(optimadamw_8bit)相同字符串、相同 bitsandbytes 优化器无需翻译use_rsloraTrue/FalseLoraConfig(use_rsloraTrue/False)在 PEFT 中同名同 flagmax_seq_length传给FastLanguageModel.from_pretrainedSFTConfig(max_length...)当前 TRL字段是SFTConfig上的max_length由max_seq_length更名不在 trainer 调用或 plain TRL 的from_pretrained上dataset_text_fieldUnsloth 示例常在 trainer 上设置SFTConfig(dataset_text_field...)当前 TRL同样位于SFTConfig上random_state3407数据/适配器初始化种子SFTConfig(seed3407)做 trainer 级播种两者都设——Unsloth 的random_state专门播种 LoRA 初始化SFTConfig.seed播种 trainer 自身的 RNG 使用当前 TRL API 的两个注意点两个近期变更过的 API 面过时示例包括部分 Unsloth cookbook 片段仍在使用旧写法是processing_class不是tokenizer。SFTTrainer(tokenizertokenizer, ...)是旧的、已移除或废弃的形式。当前 TRL 接受SFTTrainer(processing_classtokenizer, ...)。配置或示例若仍传tokenizer运行前必须更新——这是把旧配方向前移植时最常见的 stale-API 错误。max_length由max_seq_length更名与dataset_text_field位于SFTConfig上而不是散落在 trainer 调用或模型加载器各处。在SFTConfig实例上一次设置好不要在流水线其他地方重复。已知的 Unsloth 2026.7.x 限制真实复现过的四个坑references/unsloth-trl-mapping.md 记录了在 Unsloth 2026.7.2transformers 5.13.1trl 1.8.0上训练真实 messages 形状 SFT 时确认的四个缺口——每个都在真实 load/train 中复现过均非假设1.assistant_only_lossTrue时没有 messages 形状路径Unsloth 的编译版SFTTrainer从unsloth被导入的那一刻起就进程级 monkeypatch 到trl.SFTTrainer上进程内不可逆且不因是否实际使用FastLanguageModel而门控自带手写_prepare_dataset只按列名识别四种数据集形状预分词input_ids/labels、promptcompletion、扁平dataset_text_field、或返回预渲染字符串的formatting_func。messages 形状的对话式数据集路径完全不存在。formatting_func只能返回扁平文本这迫使在 trainer 看到每轮边界之前就预渲染聊天模板——正是 dataset-curation 的references/formats-and-templates.md所警告的扁平文本反模式对整个序列计算 loss使assistant_only_loss失效。修复使用下方 plain TRL PEFT 逃生通道——这不是可以等待的罕见 point-release 回归而是 Unsloth 2026.7.x 对该组合messages 数据集 assistant_only_lossTrue 不打包的当前状态。经两次独立运行确认Unsloth 路径在 trainer 构造时立即报错同样超参在从不 importunsloth、改用 plaintransformers.AutoModelForCausalLMpeft.LoraConfig/get_peft_modeltrl.SFTTrainer后干净地端到端跑通。2.attn_implementationkwarg 被静默丢弃FastLanguageModel.from_pretrained(..., attn_implementationsdpa)不能可靠地强制 SDPA。Unsloth 的加载器调用自己的注意力解析辅助函数不转发调用者的attn_implementation随后干脆丢弃该 kwarg——因此只要可导入的 flash-attn 构建存在无论请求什么都会被自动选中。已确认显式传attn_implementationsdpa仍解析为model.config._attn_implementation flash_attention_2。唯一可用的覆写是在调用from_pretrained前 monkeypatch——要严格限定作用域因为HAS_FLASH_ATTENTION是模块级全局还会影响同一进程后续的任何其他from_pretrained调用同一脚本或 notebook 单元中的第二次模型加载会静默继承该 flag 上次的值import unsloth.models._utils as unsloth_utils _original unsloth_utils.HAS_FLASH_ATTENTION try: unsloth_utils.HAS_FLASH_ATTENTION False model, tokenizer FastLanguageModel.from_pretrained(...) assert model.config._attn_implementation sdpa, ( fexpected sdpa, got {model.config._attn_implementation} ) finally: unsloth_utils.HAS_FLASH_ATTENTION _original这仅在try块期间把解析器逼到 SDPA 分支即使from_pretrained抛错也会在finally中恢复原值并断言解析器确实落在 SDPA 而非静默穿透。在 plain TRL/PEFT上面的逃生通道中传给AutoModelForCausalLM.from_pretrained的attn_implementationsdpa会被正确遵守——这是 Unsloth 专属缺口不是 TRL 的通用问题。3.padding_free与 plain-TRLSFTConfig的冲突把 plaintrl.SFTConfig(max_length1024, packingFalse, ...)即不碰padding_free、与 TRL 文档默认padding_freeFalse一致传入 Unsloth 的编译版 trainer仍可能抛出ValueError: When padding_freeTrue without packing, max_length is not enforced...。Unsloth 自带的编译版SFTConfig等价 dataclass 默认padding_free None其解析路径中的某处即使对由 plaintrl.SFTConfig构建的args实例也会把它变成真值。修复无论走哪条路径只要经过 Unsloth 训练就显式传padding_freeFalse——廉价保险。4. TRL 的聊天模板自动打补丁是精确字符串匹配在抛出 dataset-curation SKILL.md 所述template lacks{% generation %}错误之前TRL 1.8.0 的SFTTrainer.__init__会调用内部get_training_chat_template()尝试用约 18 个硬编码的已知模型训练模板之一trl.chat_template_utils按 tokenizerchat_template的精确字符串相等做替换。若模型自带的模板与表项不逐字匹配——即便几乎相同——自动打补丁会静默失败TRL 抛错。修复模式手工给 tokenizer 实际模板的副本打补丁——在助手轮内容区间外包上{% generation %}...{% endgeneration %}标记角色标记在区间外、turn 结束 token 在区间内与 TRL 的is_chat_template_stop_token_trained检查一致保留真实模板的每个分支工具调用、逐轮特例处理——通用回退常量不会有这些。将打补丁后的模板仅内存写入tokenizer.chat_template绝不覆写基础模型目录自带的模板文件。逃生通道何时回退到 plain TRL对 messages 形状 SFT assistant_only_lossTrue这是上文 Known Limitations 部分规定的默认路径而非最后手段的回退。对其他所有训练模式Unsloth 发布快速 point release某个 point release 偶尔会在特定模式collator、chunked-loss 路径、特定模型架构上回归直到下个补丁修复。无论哪种情况流程一致窄范围复现——确认问题出在 Unsloth 封装而非底层配置rank、alpha、LR、target modules 仍原样适用。直接回退到 plain TRL PEFT——用上方映射表把每个 Unsloth kwarg 翻译成 TRL/PEFT 等价物。超参不变——只是由哪个库来设置它们。补丁落地后重新钉回 Unsloth——仅针对真正的回归所覆盖的模式先查 Known Limitations 一节——结构性缺口如 messages 形状路径不会在下一个 point release 自动解决除非 changelog 条目确认。llm-finetuning-training-engineer的方法部分agent 定义正是这样执行默认按 Unsloth 快路径生成脚本当 point-release 回归迫使回退时走lora-qlora-recipes的references/unsloth-trl-mapping.md中的逃生通道流程而不是凭记忆手工翻译配置。失败模式三个看起来像训练 bug、实则是配置问题的坑本技能总结了三个高频失败模式且它们共享同一模式表面看像训练循环 bugloss 尖峰、平台期、记忆化实际都是违背了上文参考配方的配置选择。在调试训练循环本身之前先对照本技能检查配置1. 非 BF16 GPU 上的 fp16 发散在不具备扎实 BF16 支持的硬件上用 fp16 训练是 loss 尖峰与静默发散的已知来源。凡硬件支持处强制bf16True不要把回退到 fp16 当成等价方案。选 dtype 前先检查硬件支持python -c import torch; print(torch.cuda.is_bf16_supported())这与llm-finetuning-training-engineer的失败分级第一类Divergence完全对应先确认bf16True与硬件 BF16 支持fp16 在不支持 BF16 的硬件上是已知的静默发散源。references/hyperparameters.md的工作配置甚至把该检查做成了硬门禁——不支持 BF16 就直接抛RuntimeError绝不静默回退 fp16。2. 小数据集上 rank 过高导致过拟合为规模化 SFT最高约 256挑选的 rank用在背后没有规模的 dataset 上是记忆化而非泛化。rank 要对照上文的 Rank by Task 表匹配任务而不是挑最大可用数字。3. 删减 target modules 省内存质量受损、节省可忽略gate_proj/up_proj/down_proj上的适配器参数只占模型总尺寸的一小部分——砍掉它们几乎不动内存却可测量地损害质量。内存吃紧时先转 QLoRA、降 rank/batch/pack 长度最后才考虑修剪 target modules。与数据集侧的分工模板、masking 与 packing本技能明确不管数据集准备——那是 dataset-curation 的职责。但配置 LoRA/QLoRA 的人需要理解两个直接影响本配置质量的交叉点模板先于拼接任何拼接或 packing 之前应用目标模型的聊天模板先 pack 原始文本再对打包后的 blob 做模板会破坏轮次边界使角色标记错位。会话数据保持messages形状、由 trainer 负责模板化与 masking当前 TRL 的assistant_only_lossTrue——预渲染成扁平文本字段会毁掉 masking 所需的轮次边界。packing 的强制检查packing 可消除 40–70% 的 padding 计算浪费但会改变 batch 语义与 LR schedule 里程碑应按 packed-sequence 数量重算。启用 packing 前必须解码并人工检查 5–10 条 packed 序列确认示例边界、模板标记与 assistant-only loss mask 都完好——packing bug 是静默的loss 曲线看似正常数小时后才在 eval 质量上暴露。dataset-curation的 Phase 2 Exit Checklist 六项格式匹配方法、模板先于拼接、loss 仅 assistant 轮、5–10 条 packed 序列已解码检查、≥25% 真实数据、数据集卡六字段齐全正是/finetune命令在启动训练前检查的关卡。结语这份配置在整个微调生命周期中的位置在llm-finetuning插件与/finetune命令的七阶段生命周期finetune.md中本技能产出的是 Phase 4 训练阶段的核心输入一份校验过的 LoRA/QLoRA 适配器配置。路由由finetuning-method-selection完成Phase 1数据集卡与验证报告由dataset-curation交付Phase 2环境预检Phase 3DGX Spark 走dgx-spark-ops的 preflight 与 G1–G10 检查其他硬件走 generic-nvidia 检查先于脚本生成而 Phase 5 的 checkpoint 门禁与 Phase 6 的导出则分别属于checkpoint-promotion与quantized-export。理解了本文的 target modules、rank/alpha、LR、batch、Unsloth 默认值与逃生通道你就能在任何一步出问题时把看起来像训练 bug的现象快速定位回配置层面——这正是本技能存在的意义。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
