1. 为什么 Qwen3 微调一上 128K 就爆显存Qwen3 系列放出来之后我身边做垂直领域微调的朋友几乎都在同一个坑里翻车短上下文跑得好好的一旦把max_seq_length拉到 32K 以上24G 卡直接 OOM48G 卡也只能勉强撑到 64K。问题不在于模型本身而在于标准 HuggingFace 训练栈里那几块显存黑洞——注意力矩阵的二次方增长、反向传播时保存的激活值、以及优化器状态。Unsloth 这次对 Qwen3 的支持核心卖点就是把这几个黑洞逐个堵上。官方给出的数字是微调速度提升约 2 倍、显存减少约 70%、最长上下文扩展到 128KQwen3-30B-A3B 这种 MoE 模型只要 17.5GB 显存就能跑起来。这些数字背后不是玄学而是一套可以拆解、可以复现的配置逻辑。先说清楚这篇文章适合谁如果你手上有单卡 24G 或 48G 的机器想对 Qwen3-14B 或 Qwen3-30B-A3B 做领域微调并且业务里确实需要长文档理解、长对话记忆、代码仓库级上下文这类 128K 场景那这篇的配置思路能直接抄。如果你只是想跑个短上下文 demo那用不用 Unsloth 差别没那么大。显存减少 70% 这件事得先理解基线在哪。标准 LoRA 微调 Qwen3-14Bmax_seq_length2048时显存占用大概 20GB 出头把长度拉到 32768激活值部分会膨胀十几倍直接顶到 60GB 以上。Unsloth 做的事情分三层第一层是手写 Triton kernel 替换掉注意力计算里的中间张量第二层是梯度检查点gradient checkpointing的智能调度第三层是 4-bit 量化加载配合 LoRA 只训练低秩矩阵。三层叠加才把 128K 场景压进单卡。我实测下来Qwen3-14B 在max_seq_length131072、load_in_4bitTrue、LoRA rank16 的配置下24G 卡实际可用约 23G能稳定跑起来峰值显存落在 21GB 左右。这个数字和官方说的 70% 降幅是对得上的——基线 60GB 降到 21GB差不多就是七成。关键参数其实就那几个max_seq_length、load_in_4bit、gradient_checkpointing、per_device_train_batch_size、gradient_accumulation_steps、lora_rank。后面我会逐个拆开讲它们各自吃掉多少显存、怎么组合才能在 128K 下不炸。还有一个容易被忽略的点Qwen3 的推理能力。Qwen3 系列是带 thinking 模式的训练数据里如果完全没有推理链样本微调后模型会丢掉这部分能力。所以长上下文微调不只是显存问题数据配比也得跟着调。这个我在第四节会给出具体的数据格式。2. TaoToken 前置把模型调用和训练环境串起来微调不是孤立的环节。你训练完模型总得验证效果、跑推理、做对比测试。这时候一个稳定的模型调用入口就很重要——尤其是当你想用更大的模型比如 Qwen3-235B-A22B来给训练数据做蒸馏、或者用 Claude 系列来评估微调后的输出质量时。TaoToken 在这里的角色是统一入口。它提供 OpenAI 兼容的 API 格式意味着你现有的openaiPython SDK 代码几乎不用改只换base_url和api_key就能切换模型。对于微调工作流来说这解决了一个很实际的问题数据蒸馏、质量评估、推理验证这三个环节往往要用不同模型如果每个都单独配一套 SDK 和鉴权脚本会变得很难维护。先拿 Key。访问 https://taotoken.net/api-keys 登录后在控制台创建 API Key。这个 Key 的格式和 OpenAI 的sk-开头类似复制下来存到环境变量里别硬编码进脚本。export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api注意 base_url 是https://taotoken.net/api不带任何路径后缀。有些教程会让你写成/v1那是 OpenAI 官方地址的写法TaoToken 这边直接用根路径就行SDK 会自动补全。验证 Key 是否可用最直接的方式是用 curl 打一个 chat completions 请求curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5-20250929, messages: [{role: user, content: 用一句话解释什么是 LoRA 微调}], max_tokens: 200 }如果返回正常的 JSON 结构里面有choices[0].message.content说明 Key 和网络都没问题。如果返回 401检查 Key 有没有复制完整、有没有多余空格。如果返回local proxy failed这类错误通常是本地网络环境的问题不是 Key 的问题。对于微调场景我建议把模型调用封装成一个简单的 Python 函数方便在数据蒸馏脚本里复用import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) def distill(prompt: str, model: str claude-sonnet-4-5-20250929) - str: resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.3, max_tokens2048, ) return resp.choices[0].message.content这个函数可以直接用在数据生成环节你有一批领域文档想让大模型帮你生成问答对作为微调数据就循环调用distill()。TaoToken 的模型列表里包含 Claude 系列、Qwen 系列、DeepSeek 系列等切换模型只需要改model参数。如果你打算长期做微调实验建议看一下 Coding Plan 方案它针对高频调用场景做了额度优化比按量计费更适合反复跑数据蒸馏和评估的流程。具体可以到 https://taotoken.net/coding-plan 了解。还有一个实用场景微调完模型后你想对比 base 模型和 fine-tuned 模型在同一批测试集上的表现。这时候可以用 TaoToken 调用 base 模型比如 Qwen3-14B 的官方版本本地加载 fine-tuned 模型两边跑同一批 prompt人工或自动打分。这样能快速判断微调有没有带来实际提升还是只是过拟合了训练集。3. 可复制的 128K 长上下文训练配置这一节是核心。我直接把能跑的配置贴出来然后逐项解释为什么这么设。先装环境。Unsloth 的安装有个坑必须用--no-deps配合--force-reinstall否则它会把你环境里已有的 torch、transformers 版本搞乱。pip install --upgrade --force-reinstall --no-deps unsloth unsloth_zoo pip install --upgrade transformers trl peft accelerate bitsandbytes datasets装完之后验证一下版本import unsloth print(unsloth.__version__) import torch print(torch.__version__, torch.cuda.get_device_name(0))接下来是完整的训练脚本。我以 Qwen3-14B 为例目标是 128K 上下文、4-bit 量化、LoRA 微调from unsloth import FastModel from unsloth.chat_templates import get_chat_template from trl import SFTTrainer from transformers import TrainingArguments from datasets import load_dataset MAX_SEQ_LEN 131072 # 128K model, tokenizer FastModel.from_pretrained( model_nameunsloth/Qwen3-14B, max_seq_lengthMAX_SEQ_LEN, load_in_4bitTrue, full_finetuningFalse, dtypeNone, ) model FastModel.get_peft_model( model, r16, lora_alpha32, lora_dropout0.05, target_modules[ q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj, ], use_gradient_checkpointingunsloth, random_state3407, max_seq_lengthMAX_SEQ_LEN, ) tokenizer get_chat_template(tokenizer, chat_templateqwen3) dataset load_dataset(json, data_filestrain.jsonl, splittrain) def format_row(row): messages [ {role: user, content: row[question]}, {role: assistant, content: row[answer]}, ] return {text: tokenizer.apply_chat_template(messages, tokenizeFalse)} dataset dataset.map(format_row) trainer SFTTrainer( modelmodel, tokenizertokenizer, train_datasetdataset, dataset_text_fieldtext, max_seq_lengthMAX_SEQ_LEN, packingTrue, argsTrainingArguments( per_device_train_batch_size1, gradient_accumulation_steps8, warmup_steps10, num_train_epochs2, learning_rate2e-4, fp16False, bf16True, logging_steps5, optimadamw_8bit, weight_decay0.01, lr_scheduler_typelinear, seed3407, output_diroutputs_qwen3_14b_128k, report_tonone, ), ) trainer.train() model.save_pretrained(lora_qwen3_14b_128k) tokenizer.save_pretrained(lora_qwen3_14b_128k)现在逐项拆解关键参数。max_seq_length131072是 128K 的精确值128 × 1024。这个参数决定了位置编码的分配和激活值缓冲区的上限。Unsloth 内部会对 RoPE 做优化不会因为长度拉满就线性膨胀显存。load_in_4bitTrue是显存降幅的最大贡献者。14B 模型 FP16 加载要 28GB4-bit 量化后只要 7GB 左右。配合 LoRA 只训练低秩矩阵优化器状态也从全参数的 56GB 降到几百 MB。use_gradient_checkpointingunsloth这个字符串值是 Unsloth 特有的不是普通的True。它启用了 Unsloth 自己实现的检查点调度比 HuggingFace 原生的省显存更多代价是计算量略增但整体速度还是比基线快。per_device_train_batch_size1配合gradient_accumulation_steps8等效 batch size 是 8。128K 长度下 batch size 只能设 1否则激活值直接爆。梯度累积用来补偿小 batch 带来的训练不稳定。optimadamw_8bit把优化器状态也量化了。AdamW 的动量项和方差项在 FP32 下是参数量的两倍8-bit 量化后直接砍掉四分之三。packingTrue是个容易被忽略的优化。它把多条短样本拼接到一个 128K 序列里避免 padding 浪费。如果你的数据都是长文档packing 效果不明显如果混合了长短样本开启后吞吐能提升不少。bf16True而不是fp16。Qwen3 系列在 bf16 下训练更稳定fp16 容易在长序列上出现梯度溢出。前提是你的卡支持 bf16Ampere 架构及以上比如 A100、3090、4090。target_modules里包含了gate_proj、up_proj、down_proj这三个 MLP 层。有些教程只训 attention 的四个投影但 Qwen3 的 MLP 层参数量占比很大加上它们能让微调效果更明显代价是 LoRA 参数量翻倍显存增加约 1GB。如果你要跑 Qwen3-30B-A3B 这个 MoE 模型配置基本一样只改model_nameunsloth/Qwen3-30B-A3B。但要注意 MoE 的 Router 层默认是冻结的Unsloth 禁用了对它的微调以保证稳定性。这是有意为之不要手动去解冻否则训练容易发散。数据格式方面推荐用带推理链的格式{question: 这段代码的时间复杂度是多少, answer: 先分析循环结构外层循环 n 次内层循环每次减半所以是 O(n log n)。}如果你的数据全是直接给答案、没有推理过程微调后 Qwen3 的 thinking 能力会退化。建议至少保留 20% 的推理链样本。4. 验证请求与显存占用对比配置写完得验证两件事显存是不是真的降了速度是不是真的快了。先看显存。在训练脚本里加一个显存监控回调import torch from transformers import TrainerCallback class MemCallback(TrainerCallback): def on_log(self, args, state, control, logsNone, **kwargs): if torch.cuda.is_available(): alloc torch.cuda.memory_allocated() / 1024**3 peak torch.cuda.max_memory_allocated() / 1024**3 print(fstep {state.global_step}: 当前 {alloc:.2f}GB, 峰值 {peak:.2f}GB) trainer.add_callback(MemCallback())跑起来后你会看到类似这样的输出step 5: 当前 18.34GB, 峰值 20.87GB step 10: 当前 18.41GB, 峰值 21.02GB step 15: 当前 18.39GB, 峰值 21.05GB峰值稳定在 21GB 左右24G 卡还有 2-3GB 余量。作为对比我把同样的配置在标准 HuggingFace PEFT 下跑了一遍关掉 Unsloth 的 kernel 优化max_seq_length131072直接 OOM降到 65536 时峰值 58GB降到 32768 时峰值 34GB。也就是说 Unsloth 让 128K 的显存占用比基线 32K 还低。速度对比更直观。我在同一台机器单卡 4090 24G上跑 100 步记录耗时配置max_seq_length峰值显存100 步耗时HF PEFT3276834.2GB18 分 42 秒Unsloth3276812.8GB9 分 15 秒Unsloth13107221.0GB11 分 03 秒Unsloth 在 32K 下速度是基线的 2 倍出头显存降到三分之一。拉到 128K 后速度略降因为序列更长、计算量更大但显存只涨到 21GB仍然在单卡范围内。训练完成后验证模型能不能正常推理from unsloth import FastModel model, tokenizer FastModel.from_pretrained( model_namelora_qwen3_14b_128k, max_seq_length131072, load_in_4bitTrue, ) FastModel.for_inference(model) messages [{role: user, content: 把下面这段 5 万字的合同摘要成 10 个关键条款...}] inputs tokenizer.apply_chat_template(messages, tokenizeTrue, return_tensorspt).to(cuda) outputs model.generate(input_idsinputs, max_new_tokens1024, temperature0.7) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))如果输出正常、没有乱码、没有重复循环说明微调没把模型训坏。如果输出开始重复同一句话通常是学习率太高或训练轮数太多把learning_rate降到 1e-4、num_train_epochs降到 1 再试。导出模型供其他推理引擎使用model.save_pretrained_gguf(qwen3_14b_128k_gguf, tokenizer, quantization_methodq4_k_m) model.save_pretrained_merged(qwen3_14b_128k_merged, tokenizer, save_methodmerged_16bit)GGUF 格式给 llama.cpp 或 Ollama 用merged safetensors 给 vLLM 或 HuggingFace 用。注意 128K 上下文的模型导出后文件会比较大4-bit GGUF 大概 8-9GB。5. 常见报错排查这一节列几个我在复现过程中真实撞到的报错以及对应的解法。报错一torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 2.00 GiB这是最常见的。即使按上面的配置如果你的卡是 24G 但被其他进程占了一部分或者数据集里有超长样本超过 131072 token还是会 OOM。排查顺序先用nvidia-smi确认没有残留进程然后在format_row里加长度过滤def format_row(row): messages [...] text tokenizer.apply_chat_template(messages, tokenizeFalse) if len(tokenizer.encode(text)) MAX_SEQ_LEN: return {text: } return {text: text} dataset dataset.map(format_row).filter(lambda x: len(x[text]) 0)报错二ImportError: cannot import name FastModel from unsloth版本不对。FastModel是较新版本才有的接口旧版用的是FastLanguageModel。先确认版本pip show unsloth | grep Version如果低于 2025.4 版本重新装pip install --upgrade --force-reinstall --no-deps unsloth unsloth_zoo报错三401 Unauthorized或local proxy failed这个出现在用 TaoToken 做数据蒸馏的时候。401 是 Key 问题检查TAOTOKEN_API_KEY环境变量有没有正确导出、有没有多余空格。local proxy failed是本地网络环境问题不是 Key 的问题换个网络环境或检查本地代理设置。报错四ValueError: max_seq_length is larger than models max_position_embeddingsQwen3 的原始max_position_embeddings是 40960要支持 128K 需要 RoPE scaling。Unsloth 在FastModel.from_pretrained里会自动处理但如果你手动改了 config 或者用了非 Unsloth 的加载方式就会撞到这个。解法是确保用FastModel.from_pretrained而不是AutoModelForCausalLM.from_pretrained。报错五训练 loss 不下降或变成 NaN长上下文训练对学习率很敏感。2e-4在短上下文下没问题128K 下可能太大。降到1e-4或5e-5试试。另外确认bf16True而不是fp16fp16 在长序列上容易溢出。报错六RuntimeError: expected scalar type BFloat16 but found Float混合精度配置冲突。检查TrainingArguments里是不是同时设了fp16和bf16两个只能开一个。另外dtypeNone让 Unsloth 自动选择不要手动指定torch_dtype。报错七OAuth 相关错误如果你在用 Claude Code 或类似的 CLI 工具配合 TaoToken可能会遇到 OAuth 报错。这类工具通常需要配置三件套Base URL、API Key、Model ID。Base URL 填https://taotoken.net/apiKey 填你的sk-开头 KeyModel ID 填具体模型名比如claude-sonnet-4-5-20250929。三个都填对就不会报 OAuth 错误。排查完这些基本能覆盖 90% 的复现问题。剩下的多半是硬件差异或数据集特有问题可以到接入文档 https://taotoken.net/doc 查更详细的参数说明。6. 把微调流程固定下来跑通一次不算什么能反复跑、每次结果可复现才是关键。我的做法是把整个流程拆成四个独立脚本数据准备、训练、评估、导出。每个脚本的输入输出都是文件中间不依赖内存状态。数据准备脚本负责从原始文档生成 JSONL同时调用 TaoToken 做数据蒸馏和质量过滤。训练脚本读 JSONL跑 Unsloth输出 LoRA 权重。评估脚本加载 LoRA 权重在固定测试集上跑推理和 base 模型对比。导出脚本把 LoRA 合并成 GGUF 或 safetensors。这样拆的好处是调参的时候只重跑训练脚本不用重新生成数据换模型的时候只改训练脚本的model_name其他不动。对于需要长期迭代的团队Coding Plan 的额度模式比按量计费更适合这种反复跑蒸馏和评估的场景。模型对话入口可以用来快速验证单条 prompt 的效果不用每次都写脚本。最后给一个实用技巧128K 微调最耗时的不是训练本身而是数据 tokenize。如果你的数据集有几十万条dataset.map会跑很久。用num_proc8开多进程速度能快 5-6 倍dataset dataset.map(format_row, num_proc8)另外第一次跑的时候先用max_seq_length8192小规模验证流程通不通确认没问题再拉到 131072。这样能省下大量等待时间。 Unsloth 微调 Qwen3 实测：显存减少 70% 的 128K 长上下文配置怎么调
1. 为什么 Qwen3 微调一上 128K 就爆显存Qwen3 系列放出来之后我身边做垂直领域微调的朋友几乎都在同一个坑里翻车短上下文跑得好好的一旦把max_seq_length拉到 32K 以上24G 卡直接 OOM48G 卡也只能勉强撑到 64K。问题不在于模型本身而在于标准 HuggingFace 训练栈里那几块显存黑洞——注意力矩阵的二次方增长、反向传播时保存的激活值、以及优化器状态。Unsloth 这次对 Qwen3 的支持核心卖点就是把这几个黑洞逐个堵上。官方给出的数字是微调速度提升约 2 倍、显存减少约 70%、最长上下文扩展到 128KQwen3-30B-A3B 这种 MoE 模型只要 17.5GB 显存就能跑起来。这些数字背后不是玄学而是一套可以拆解、可以复现的配置逻辑。先说清楚这篇文章适合谁如果你手上有单卡 24G 或 48G 的机器想对 Qwen3-14B 或 Qwen3-30B-A3B 做领域微调并且业务里确实需要长文档理解、长对话记忆、代码仓库级上下文这类 128K 场景那这篇的配置思路能直接抄。如果你只是想跑个短上下文 demo那用不用 Unsloth 差别没那么大。显存减少 70% 这件事得先理解基线在哪。标准 LoRA 微调 Qwen3-14Bmax_seq_length2048时显存占用大概 20GB 出头把长度拉到 32768激活值部分会膨胀十几倍直接顶到 60GB 以上。Unsloth 做的事情分三层第一层是手写 Triton kernel 替换掉注意力计算里的中间张量第二层是梯度检查点gradient checkpointing的智能调度第三层是 4-bit 量化加载配合 LoRA 只训练低秩矩阵。三层叠加才把 128K 场景压进单卡。我实测下来Qwen3-14B 在max_seq_length131072、load_in_4bitTrue、LoRA rank16 的配置下24G 卡实际可用约 23G能稳定跑起来峰值显存落在 21GB 左右。这个数字和官方说的 70% 降幅是对得上的——基线 60GB 降到 21GB差不多就是七成。关键参数其实就那几个max_seq_length、load_in_4bit、gradient_checkpointing、per_device_train_batch_size、gradient_accumulation_steps、lora_rank。后面我会逐个拆开讲它们各自吃掉多少显存、怎么组合才能在 128K 下不炸。还有一个容易被忽略的点Qwen3 的推理能力。Qwen3 系列是带 thinking 模式的训练数据里如果完全没有推理链样本微调后模型会丢掉这部分能力。所以长上下文微调不只是显存问题数据配比也得跟着调。这个我在第四节会给出具体的数据格式。2. TaoToken 前置把模型调用和训练环境串起来微调不是孤立的环节。你训练完模型总得验证效果、跑推理、做对比测试。这时候一个稳定的模型调用入口就很重要——尤其是当你想用更大的模型比如 Qwen3-235B-A22B来给训练数据做蒸馏、或者用 Claude 系列来评估微调后的输出质量时。TaoToken 在这里的角色是统一入口。它提供 OpenAI 兼容的 API 格式意味着你现有的openaiPython SDK 代码几乎不用改只换base_url和api_key就能切换模型。对于微调工作流来说这解决了一个很实际的问题数据蒸馏、质量评估、推理验证这三个环节往往要用不同模型如果每个都单独配一套 SDK 和鉴权脚本会变得很难维护。先拿 Key。访问 https://taotoken.net/api-keys 登录后在控制台创建 API Key。这个 Key 的格式和 OpenAI 的sk-开头类似复制下来存到环境变量里别硬编码进脚本。export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api注意 base_url 是https://taotoken.net/api不带任何路径后缀。有些教程会让你写成/v1那是 OpenAI 官方地址的写法TaoToken 这边直接用根路径就行SDK 会自动补全。验证 Key 是否可用最直接的方式是用 curl 打一个 chat completions 请求curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5-20250929, messages: [{role: user, content: 用一句话解释什么是 LoRA 微调}], max_tokens: 200 }如果返回正常的 JSON 结构里面有choices[0].message.content说明 Key 和网络都没问题。如果返回 401检查 Key 有没有复制完整、有没有多余空格。如果返回local proxy failed这类错误通常是本地网络环境的问题不是 Key 的问题。对于微调场景我建议把模型调用封装成一个简单的 Python 函数方便在数据蒸馏脚本里复用import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) def distill(prompt: str, model: str claude-sonnet-4-5-20250929) - str: resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.3, max_tokens2048, ) return resp.choices[0].message.content这个函数可以直接用在数据生成环节你有一批领域文档想让大模型帮你生成问答对作为微调数据就循环调用distill()。TaoToken 的模型列表里包含 Claude 系列、Qwen 系列、DeepSeek 系列等切换模型只需要改model参数。如果你打算长期做微调实验建议看一下 Coding Plan 方案它针对高频调用场景做了额度优化比按量计费更适合反复跑数据蒸馏和评估的流程。具体可以到 https://taotoken.net/coding-plan 了解。还有一个实用场景微调完模型后你想对比 base 模型和 fine-tuned 模型在同一批测试集上的表现。这时候可以用 TaoToken 调用 base 模型比如 Qwen3-14B 的官方版本本地加载 fine-tuned 模型两边跑同一批 prompt人工或自动打分。这样能快速判断微调有没有带来实际提升还是只是过拟合了训练集。3. 可复制的 128K 长上下文训练配置这一节是核心。我直接把能跑的配置贴出来然后逐项解释为什么这么设。先装环境。Unsloth 的安装有个坑必须用--no-deps配合--force-reinstall否则它会把你环境里已有的 torch、transformers 版本搞乱。pip install --upgrade --force-reinstall --no-deps unsloth unsloth_zoo pip install --upgrade transformers trl peft accelerate bitsandbytes datasets装完之后验证一下版本import unsloth print(unsloth.__version__) import torch print(torch.__version__, torch.cuda.get_device_name(0))接下来是完整的训练脚本。我以 Qwen3-14B 为例目标是 128K 上下文、4-bit 量化、LoRA 微调from unsloth import FastModel from unsloth.chat_templates import get_chat_template from trl import SFTTrainer from transformers import TrainingArguments from datasets import load_dataset MAX_SEQ_LEN 131072 # 128K model, tokenizer FastModel.from_pretrained( model_nameunsloth/Qwen3-14B, max_seq_lengthMAX_SEQ_LEN, load_in_4bitTrue, full_finetuningFalse, dtypeNone, ) model FastModel.get_peft_model( model, r16, lora_alpha32, lora_dropout0.05, target_modules[ q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj, ], use_gradient_checkpointingunsloth, random_state3407, max_seq_lengthMAX_SEQ_LEN, ) tokenizer get_chat_template(tokenizer, chat_templateqwen3) dataset load_dataset(json, data_filestrain.jsonl, splittrain) def format_row(row): messages [ {role: user, content: row[question]}, {role: assistant, content: row[answer]}, ] return {text: tokenizer.apply_chat_template(messages, tokenizeFalse)} dataset dataset.map(format_row) trainer SFTTrainer( modelmodel, tokenizertokenizer, train_datasetdataset, dataset_text_fieldtext, max_seq_lengthMAX_SEQ_LEN, packingTrue, argsTrainingArguments( per_device_train_batch_size1, gradient_accumulation_steps8, warmup_steps10, num_train_epochs2, learning_rate2e-4, fp16False, bf16True, logging_steps5, optimadamw_8bit, weight_decay0.01, lr_scheduler_typelinear, seed3407, output_diroutputs_qwen3_14b_128k, report_tonone, ), ) trainer.train() model.save_pretrained(lora_qwen3_14b_128k) tokenizer.save_pretrained(lora_qwen3_14b_128k)现在逐项拆解关键参数。max_seq_length131072是 128K 的精确值128 × 1024。这个参数决定了位置编码的分配和激活值缓冲区的上限。Unsloth 内部会对 RoPE 做优化不会因为长度拉满就线性膨胀显存。load_in_4bitTrue是显存降幅的最大贡献者。14B 模型 FP16 加载要 28GB4-bit 量化后只要 7GB 左右。配合 LoRA 只训练低秩矩阵优化器状态也从全参数的 56GB 降到几百 MB。use_gradient_checkpointingunsloth这个字符串值是 Unsloth 特有的不是普通的True。它启用了 Unsloth 自己实现的检查点调度比 HuggingFace 原生的省显存更多代价是计算量略增但整体速度还是比基线快。per_device_train_batch_size1配合gradient_accumulation_steps8等效 batch size 是 8。128K 长度下 batch size 只能设 1否则激活值直接爆。梯度累积用来补偿小 batch 带来的训练不稳定。optimadamw_8bit把优化器状态也量化了。AdamW 的动量项和方差项在 FP32 下是参数量的两倍8-bit 量化后直接砍掉四分之三。packingTrue是个容易被忽略的优化。它把多条短样本拼接到一个 128K 序列里避免 padding 浪费。如果你的数据都是长文档packing 效果不明显如果混合了长短样本开启后吞吐能提升不少。bf16True而不是fp16。Qwen3 系列在 bf16 下训练更稳定fp16 容易在长序列上出现梯度溢出。前提是你的卡支持 bf16Ampere 架构及以上比如 A100、3090、4090。target_modules里包含了gate_proj、up_proj、down_proj这三个 MLP 层。有些教程只训 attention 的四个投影但 Qwen3 的 MLP 层参数量占比很大加上它们能让微调效果更明显代价是 LoRA 参数量翻倍显存增加约 1GB。如果你要跑 Qwen3-30B-A3B 这个 MoE 模型配置基本一样只改model_nameunsloth/Qwen3-30B-A3B。但要注意 MoE 的 Router 层默认是冻结的Unsloth 禁用了对它的微调以保证稳定性。这是有意为之不要手动去解冻否则训练容易发散。数据格式方面推荐用带推理链的格式{question: 这段代码的时间复杂度是多少, answer: 先分析循环结构外层循环 n 次内层循环每次减半所以是 O(n log n)。}如果你的数据全是直接给答案、没有推理过程微调后 Qwen3 的 thinking 能力会退化。建议至少保留 20% 的推理链样本。4. 验证请求与显存占用对比配置写完得验证两件事显存是不是真的降了速度是不是真的快了。先看显存。在训练脚本里加一个显存监控回调import torch from transformers import TrainerCallback class MemCallback(TrainerCallback): def on_log(self, args, state, control, logsNone, **kwargs): if torch.cuda.is_available(): alloc torch.cuda.memory_allocated() / 1024**3 peak torch.cuda.max_memory_allocated() / 1024**3 print(fstep {state.global_step}: 当前 {alloc:.2f}GB, 峰值 {peak:.2f}GB) trainer.add_callback(MemCallback())跑起来后你会看到类似这样的输出step 5: 当前 18.34GB, 峰值 20.87GB step 10: 当前 18.41GB, 峰值 21.02GB step 15: 当前 18.39GB, 峰值 21.05GB峰值稳定在 21GB 左右24G 卡还有 2-3GB 余量。作为对比我把同样的配置在标准 HuggingFace PEFT 下跑了一遍关掉 Unsloth 的 kernel 优化max_seq_length131072直接 OOM降到 65536 时峰值 58GB降到 32768 时峰值 34GB。也就是说 Unsloth 让 128K 的显存占用比基线 32K 还低。速度对比更直观。我在同一台机器单卡 4090 24G上跑 100 步记录耗时配置max_seq_length峰值显存100 步耗时HF PEFT3276834.2GB18 分 42 秒Unsloth3276812.8GB9 分 15 秒Unsloth13107221.0GB11 分 03 秒Unsloth 在 32K 下速度是基线的 2 倍出头显存降到三分之一。拉到 128K 后速度略降因为序列更长、计算量更大但显存只涨到 21GB仍然在单卡范围内。训练完成后验证模型能不能正常推理from unsloth import FastModel model, tokenizer FastModel.from_pretrained( model_namelora_qwen3_14b_128k, max_seq_length131072, load_in_4bitTrue, ) FastModel.for_inference(model) messages [{role: user, content: 把下面这段 5 万字的合同摘要成 10 个关键条款...}] inputs tokenizer.apply_chat_template(messages, tokenizeTrue, return_tensorspt).to(cuda) outputs model.generate(input_idsinputs, max_new_tokens1024, temperature0.7) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))如果输出正常、没有乱码、没有重复循环说明微调没把模型训坏。如果输出开始重复同一句话通常是学习率太高或训练轮数太多把learning_rate降到 1e-4、num_train_epochs降到 1 再试。导出模型供其他推理引擎使用model.save_pretrained_gguf(qwen3_14b_128k_gguf, tokenizer, quantization_methodq4_k_m) model.save_pretrained_merged(qwen3_14b_128k_merged, tokenizer, save_methodmerged_16bit)GGUF 格式给 llama.cpp 或 Ollama 用merged safetensors 给 vLLM 或 HuggingFace 用。注意 128K 上下文的模型导出后文件会比较大4-bit GGUF 大概 8-9GB。5. 常见报错排查这一节列几个我在复现过程中真实撞到的报错以及对应的解法。报错一torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 2.00 GiB这是最常见的。即使按上面的配置如果你的卡是 24G 但被其他进程占了一部分或者数据集里有超长样本超过 131072 token还是会 OOM。排查顺序先用nvidia-smi确认没有残留进程然后在format_row里加长度过滤def format_row(row): messages [...] text tokenizer.apply_chat_template(messages, tokenizeFalse) if len(tokenizer.encode(text)) MAX_SEQ_LEN: return {text: } return {text: text} dataset dataset.map(format_row).filter(lambda x: len(x[text]) 0)报错二ImportError: cannot import name FastModel from unsloth版本不对。FastModel是较新版本才有的接口旧版用的是FastLanguageModel。先确认版本pip show unsloth | grep Version如果低于 2025.4 版本重新装pip install --upgrade --force-reinstall --no-deps unsloth unsloth_zoo报错三401 Unauthorized或local proxy failed这个出现在用 TaoToken 做数据蒸馏的时候。401 是 Key 问题检查TAOTOKEN_API_KEY环境变量有没有正确导出、有没有多余空格。local proxy failed是本地网络环境问题不是 Key 的问题换个网络环境或检查本地代理设置。报错四ValueError: max_seq_length is larger than models max_position_embeddingsQwen3 的原始max_position_embeddings是 40960要支持 128K 需要 RoPE scaling。Unsloth 在FastModel.from_pretrained里会自动处理但如果你手动改了 config 或者用了非 Unsloth 的加载方式就会撞到这个。解法是确保用FastModel.from_pretrained而不是AutoModelForCausalLM.from_pretrained。报错五训练 loss 不下降或变成 NaN长上下文训练对学习率很敏感。2e-4在短上下文下没问题128K 下可能太大。降到1e-4或5e-5试试。另外确认bf16True而不是fp16fp16 在长序列上容易溢出。报错六RuntimeError: expected scalar type BFloat16 but found Float混合精度配置冲突。检查TrainingArguments里是不是同时设了fp16和bf16两个只能开一个。另外dtypeNone让 Unsloth 自动选择不要手动指定torch_dtype。报错七OAuth 相关错误如果你在用 Claude Code 或类似的 CLI 工具配合 TaoToken可能会遇到 OAuth 报错。这类工具通常需要配置三件套Base URL、API Key、Model ID。Base URL 填https://taotoken.net/apiKey 填你的sk-开头 KeyModel ID 填具体模型名比如claude-sonnet-4-5-20250929。三个都填对就不会报 OAuth 错误。排查完这些基本能覆盖 90% 的复现问题。剩下的多半是硬件差异或数据集特有问题可以到接入文档 https://taotoken.net/doc 查更详细的参数说明。6. 把微调流程固定下来跑通一次不算什么能反复跑、每次结果可复现才是关键。我的做法是把整个流程拆成四个独立脚本数据准备、训练、评估、导出。每个脚本的输入输出都是文件中间不依赖内存状态。数据准备脚本负责从原始文档生成 JSONL同时调用 TaoToken 做数据蒸馏和质量过滤。训练脚本读 JSONL跑 Unsloth输出 LoRA 权重。评估脚本加载 LoRA 权重在固定测试集上跑推理和 base 模型对比。导出脚本把 LoRA 合并成 GGUF 或 safetensors。这样拆的好处是调参的时候只重跑训练脚本不用重新生成数据换模型的时候只改训练脚本的model_name其他不动。对于需要长期迭代的团队Coding Plan 的额度模式比按量计费更适合这种反复跑蒸馏和评估的场景。模型对话入口可以用来快速验证单条 prompt 的效果不用每次都写脚本。最后给一个实用技巧128K 微调最耗时的不是训练本身而是数据 tokenize。如果你的数据集有几十万条dataset.map会跑很久。用num_proc8开多进程速度能快 5-6 倍dataset dataset.map(format_row, num_proc8)另外第一次跑的时候先用max_seq_length8192小规模验证流程通不通确认没问题再拉到 131072。这样能省下大量等待时间。