get_peft_model 参数详解：用 TaoToken 让 Codex 走通 LoRA 配置

get_peft_model参数配错先备好 TaoToken https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 这把 Key。PEFT 这几个参数单独的文档都写得清清楚楚麻烦的是它们凑在一起model传的是基座还是已经包装过的模型peft_config里target_modules写成q_proj还是model.layers.0.self_attn.q_projadapter_name在新版里到底还带不带默认值mixedTrue之后返回的类为什么isinstance(model, PeftModel)变成 False。这篇的走法是把 Codex 的 Base URL 指到https://taotoken.net/api让它在对话里对照参数含义产出一段调用代码然后你在本地跑起来只看模型有没有变成 PeftModel、LoRA 适配器有没有真正挂到目标层上。Codex 只负责写和解释代码脚本执行在你自己的机器上完成。1. get_peft_model 四个参数到底谁在管谁参数列表短但每一项都对应一个真实的分工。把它们当成一次函数调用里的四个角色来记比死背签名省事得多。1.1 model 与 peft_config位置参数决定顺序别写反model是你已经实例化好的torch.nn.Module大多数场景下就是AutoModelForCausalLM.from_pretrained(...)或AutoModelForSequenceClassification.from_pretrained(...)的返回值。这里最常见的误解是“先包一层再说”——有人先手动把模型 freeze、先套 DataParallel再传给get_peft_model结果 PEFT 在注入 LoRA 层时找不到预期的模块名。基座保持原样传进去冻结和可训练参数的处理交给 PEFT 自己做。peft_config是LoraConfig一类的配置对象也可能是「适配器名到配置」的字典。它的字段里最容易翻车的是三项r决定秩lora_alpha决定缩放系数target_modules决定把 LoRA 挂到哪些线性层上。target_modules可以给字符串、字符串列表也可以给正则给的全名和短名要对得上你所用架构的实际模块名写错了不会立刻报错而是安静地一个适配器都不注入训练照样能跑只是最后什么都没学到。顺序上前两个是位置参数get_peft_model(base_model, lora_config)这么写最稳。如果你用关键字传参那更安全因为在部分版本里第三个参数是必填的位置传参很容易把配置塞错位置。1.2 adapter_name不是可选装饰新版里常常是必填adapter_name给这次注入的适配器起名字同时决定它在model.peft_config里的键。早期版本给了默认值default所以很多人写代码时干脆不传但在较新的 PEFT 里它变成了必填位置参数升级之后老脚本直接抛TypeError: get_peft_model() missing 1 required positional argument: adapter_name。遇到这个报错不用怀疑环境把名字补上就行。名字本身是有语义的。多适配器场景下你会同时挂task_a和task_b两套 LoRA训练时用set_adapter()切换激活哪一个保存时按名字分别落盘。所以起名要能对应任务别一路default到底否则后面切适配器时你得靠猜。1.3 mixed返回的类会从 PeftModel 变成 PeftMixedModelmixed是最容易被忽略的一个布尔开关。默认False返回PeftModel传True时返回的是PeftMixedModel用途是把 LoRA 和其他类型的适配器混在一个模型里。它只有在peft_config传入的是「多个适配器配置的字典」时才有意义单个LoraConfig配mixedTrue没什么收益。这个开关直接影响验证代码。如果训练流程里有一段assert isinstance(model, PeftModel)而你刚把mixed打开断言会失败报错信息还不会告诉你原因。做类型检查时要把两种可能都覆盖isinstance(model, (PeftModel, PeftMixedModel))。1.4 四个参数配错之后暴露出来的三种现象秩配错表现为 loss 曲线平得像一条直线或者刚降一点就反弹target_modules配错表现为print_trainable_parameters()显示可训练参数占比极低、LoRA 模块数为零adapter_name与mixed配错表现为脚本在调用阶段就崩或者后续save_pretrained找不到你指定的适配器名。三种现象对应三条排查线索比漫无目的地调学习率高效得多。2. 把 Codex 的 base_url 指到 TaoToken先让它读得懂 peft 文档写配置之前得先有一个能稳定对话的模型入口。Codex 本身只是执行工具它背后连哪个通道由配置文件决定这里把入口统一到 TaoToken。2.1 在模型广场确认模型 ID顺手创建一把 Key打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册登录进控制台创建一把 API Key。Key 通常只在创建时完整显示一次复制下来后面统一用YOUR_API_KEY这个占位符代替实际填写时换成你自己的那串。同时去模型广场看一眼当时可用的模型 ID配置里就写列表里的那一个——不同批次的可用模型会有调整自己拼日期后缀或者照着旧文章抄一个 ID基本都会以 404 收场。顺手把工具也确认一下本地已经能跑codex命令~/.codex/config.toml存在或者可以新建。Windows 下路径是%USERPROFILE%\.codex\config.toml内容格式一样。2.2 ~/.codex/config.toml 里写 model_provider 和 base_urlCodex 的供应商配置放在 TOML 里关键是model_provider指向自定义供应商供应商段落里写base_url。注意这里填的是接口地址不是官网地址两者别混# ~/.codex/config.toml model 以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场为准 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chatbase_url末尾不要带/v1路径拼接由 Codex 自己完成。多写一段后缀请求会打到不存在的路径上返回 404而你盯着 URL 看半天也看不出问题。Key 通过环境变量注入避免把明文写进配置文件export TAOTOKEN_API_KEYYOUR_API_KEYmacOS 与 Linux 放进~/.zshrc或~/.bashrcWindows PowerShell 用setx TAOTOKEN_API_KEY YOUR_API_KEY重开终端生效。改完之后用echo $TAOTOKEN_API_KEY确认变量真的被读到了空值是最常见的“配了但没生效”。2.3 先用一句最小提问确认 Codex 通路在项目目录下启动codex问一个范围很小的问题比如「LoraConfig的target_modules接受字符串还是列表」。能正常返回就说明模型 ID、Base URL、Key 三件事都对上了。这一步别急着让它写完整脚本先把通路验证掉后面真出问题时才能确定是代码问题还是通道问题。如果这里就报 401八成是 Key 没读到或者复制时漏了字符报 404回头检查base_url有没有多写/v1报模型不存在去模型广场对一遍 ID 拼写。3. 让 Codex 按参数含义写出 get_peft_model 调用通道通了之后重点变成怎么问。模型不会读心你把参数含义讲清楚它写出来的代码才不需要大改。3.1 提示词里把四个参数点名别让它自由发挥一个可用的提问模板长这样说明基座是AutoModelForCausalLM加载的因果语言模型任务类型是CAUSAL_LM需要注入 LoRA明确要求使用get_peft_model并逐个说明model传基座实例、peft_config传LoraConfig、adapter_name传default、mixed先保持False最后要求附带一段类型检查代码打印可训练参数和 LoRA 模块名。把诉求拆到这种颗粒度返回的代码基本可以直接跑。提问里顺手贴一段你自己基座的模块名比如先跑一遍下面这段把前若干个线性层名字贴给 Codexfrom transformers import AutoModelForCausalLM base AutoModelForCausalLM.from_pretrained(你的基座模型路径或 HF ID) for name, module in base.named_modules(): if isinstance(module, __import__(torch).nn.Linear): print(name)有了真实层名target_modules就不会写飞。3.2 生成的 LoraConfig 与 target_modules 对照典型产出会是这样一段from transformers import AutoModelForCausalLM from peft import LoraConfig, get_peft_model base_model AutoModelForCausalLM.from_pretrained(你的基座模型路径或 HF ID) lora_config LoraConfig( r8, lora_alpha16, lora_dropout0.05, target_modules[q_proj, v_proj], biasnone, task_typeCAUSAL_LM, ) model get_peft_model(base_model, lora_config, adapter_namedefault, mixedFalse)拿到之后先别运行做一次人工对照target_modules里的名字是否出现在你上一步打印的层名中task_type是否和基座匹配因果语言模型用CAUSAL_LM序列分类用SEQ_CLSr与lora_alpha的比例是否合理。这三项里任何一项不对后面跑出来的结果都不可信。3.3 adapter_name 与 mixed 在代码里的落点adapter_name写进调用之后会在model.peft_config里生成一个同名键后续model.set_adapter(default)、model.save_pretrained(./lora_out)都基于这个名字。想试多任务就让 Codex 再写一段字典形式from peft import LoraConfig, get_peft_model configs { task_a: LoraConfig(r8, lora_alpha16, target_modules[q_proj, v_proj], task_typeCAUSAL_LM), task_b: LoraConfig(r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj], task_typeCAUSAL_LM), } model get_peft_model(base_model, configs, adapter_nametask_a, mixedTrue)字典加mixedTrue返回的就是PeftMixedModel验证代码要跟着调整。这段代码 Codex 能写但执行必须发生在你这边的 Python 环境里把运行输出的类型信息贴回对话让它判断是否符合预期比让它凭空断言靠谱。4. 本地跑一遍确认 PeftModel 和 LoRA 层都到位代码写完验证才是这条链路的重点。三个检查点依次过一遍能筛掉绝大多数配置错误。4.1 验类型isinstance 与 print_trainable_parametersimport torch from peft import PeftModel, PeftMixedModel print(返回类型:, type(model).__name__) print(是 PeftModel:, isinstance(model, PeftModel)) print(是 PeftMixedModel:, isinstance(model, PeftMixedModel)) model.print_trainable_parameters()print_trainable_parameters()会输出可训练参数量和它在总参数量里的占比。具体数值取决于你的基座规模和target_modules覆盖范围别去背某个百分比看趋势即可如果可训练参数几乎等于零说明适配器没挂上问题在target_modules或peft_config。4.2 验层名与秩扫 named_modules 里的 lora_lora_modules [name for name, _ in model.named_modules() if lora_ in name] print(LoRA 模块数量:, len(lora_modules)) print(前几个:, lora_modules[:6])数量为 0直接回到target_modules那一节重查数量符合预期再抽一个模块看看秩target dict(model.named_modules())[lora_modules[0]] print(r:, getattr(target, r, None)) print(lora_alpha:, getattr(target, lora_alpha, None))打印出来的r要和LoraConfig里写的一致不一致说明你运行的脚本和你看的代码不是同一份这种低级错误在实验目录乱的时候非常常见。4.3 验适配器名保存、重载、切回 defaultprint(适配器列表:, list(model.peft_config.keys())) print(当前激活:, getattr(model, active_adapters, 该版本无此属性)) model.save_pretrained(./lora_out) print(已保存到 ./lora_out)save_pretrained落盘的是适配器权重和配置不是整个基座所以./lora_out通常只有几十兆体积异常大说明保存的对象不对。多适配器场景下再补一次model.set_adapter(task_b)并重新打印激活项确认切换生效。检查目录里有没有适配器配置文件有它就说明这次注入是完整闭环。5. 报错对照target_modules、401、base_url 多了 /v1排障阶段只盯本篇会遇到的错误其它历史的坑不必提前焦虑。5.1 target_modules 名字对不上时怎么查现象是脚本不报错、训练能跑、可训练参数占比极低、LoRA 模块数为 0。根因是target_modules里的名字在基座里不存在PEFT 匹配不到就什么都不做。排查动作很简单把 4.2 那段扫描脚本挪到get_peft_model之前先在基座上打印所有线性层名再对照配置。不同架构的命名差异很大有的用q_proj有的用query拿不准就给正则或者列全名。5.2 401 与 Base URL 末尾多了 /v1401 对应钥匙问题echo $TAOTOKEN_API_KEY是空的说明环境变量没导出或者终端没重开变量有值但依然 401就是 Key 复制时缺字符回控制台重新创建一把。请求路径不对应模型不存在或 404先看base_url是不是写成了https://taotoken.net/api/v1这类带后缀的形式再去模型广场核对模型 ID 的拼写。两类错误在 Codex 会话里表现相似但看一眼状态码就能分开。5.3 代码不执行、把报错贴回 Codex 的循环需要说清楚的一点Codex 不会替你在本地或任何服务器上跑训练脚本。它做的是生成代码、解释参数含义、根据你贴回的报错给出修改建议。真实流程是你本地执行 → 复制完整 traceback → 贴回对话 → 让它定位到具体参数。贴报错的时候把最后几行的File路径和异常类型一起带上只贴一句「报错了」它也没法判断是adapter_name缺参还是target_modules匹配失败。6. 跑通之后去控制台对一下这次调用PeftModel类型检查通过、LoRA 模块数非零、peft_config里有你指定的适配器名这条链路就算走通了Codex 负责写代码TaoToken 负责把请求接住本地环境负责执行和验证。既然中间的问答消耗都走的是同一把 Key顺手对一次账比较踏实。先在 TaoToken 模型对话 里用同一把 Key 发一条消息确认模型 ID 和 Base URL 在交互场景下也正常想长期用来写代码可以打开 Coding Plan 看套餐是否够用Key 的统一创建入口在 控制台 API Keys。用量记录、模型列表和 Key 管理都在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台里下次换基座或者改target_modules先来这里确认模型 ID 还在列表里再动手改脚本。