Llama-Factory 是否支持 Transformer-XL 架构

当前大模型迭代飞快，微调成了把通用预训练模型适配到垂直场景的核心手段。LoRA、QLoRA 这些参数高效微调技术普及后，开发者不用从零搭流水线，像 LLama-Factory 这种'一站式'框架就能让模型定制变得低门槛又高效。

这类工具之所以火，是因为它对主流架构做了高度抽象和统一支持——不管是 LLaMA、Qwen 还是 ChatGLM，指定模型路径和配置参数就能跑通微调流程。但遇到早期或非典型结构时，比如 Transformer-XL，情况就复杂了：这些模型能不能无缝接入？设计特性会不会打破框架假设？

光看官方文档有没有列名字不够，得深挖 LLama-Factory 的底层机制和 Transformer-XL 本身的架构特点。

底层机制决定支持边界

LLama-Factory 不是独立的模型库，本质是建立在 Hugging Face Transformers 和 PEFT 生态之上的上层集成系统。核心能力来自对 AutoModelForCausalLM、AutoTokenizer 等标准化接口的封装与调度。换句话说，只要模型能被 HF 的 AutoClasses 正确加载，且符合因果语言建模（CAUSAL_LM）范式，理论上就有机会被支持。

这意味着，模型能否被支持，首先取决于它是否满足'标准 decoder-only 流水线'的设计假设。

看看这段模拟后台逻辑的代码：

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model

model_name = "meta-llama/Llama-2-7b-hf"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name, 
    torch_dtype=torch.bfloat16, 
    device_map="auto"
)

lora_config = LoraConfig(
    r=8,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    task_type="CAUSAL_LM"
)
model = get_peft_model(model, lora_config)

这段代码模拟了关键步骤：自动加载、注入 LoRA、初始化训练器。这里有两个隐含前提很关键：

模型必须能通过 AutoModelForCausalLM 加载；
内部要有明确的线性投影层（如 q_proj, v_proj），LoRA 才能挂载。

这两点恰恰是 Transformer-XL 的软肋。

Transformer-XL 的架构冲突

Transformer-XL 是 Dai 等人在 2019 年提出的长序列建模方案，突破传统 Transformer 的上下文限制。它靠两个核心技术实现跨片段长期记忆：

片段级递归机制：每个注意力层缓存前一片段隐藏状态，处理新片段时作为额外输入，延续数千 token 上下文。
相对位置编码：无法用全局绝对位置索引，采用基于距离的相对偏置维持位置感知。

这带来了优势，但也引入了根本变化：模型不再是无状态的前馈网络，而是有状态的循环结构。

这直接挑战了现代微调框架的基本假设。HF 生态中，默认要求标准生成接口（）、可并行化注意力、清晰模块命名。而 Transformer-XL 用自定义模块，没有统一命名空间，也不完全兼容 GenerationMixin。更严重的是，状态缓存机制破坏了批量训练中样本独立性——batch 里混合不同序列历史状态，梯度传播可能不稳定。

Llama-Factory 是否支持 Transformer-XL 架构