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

当前大模型微调领域，LoRA、QLoRA 等参数高效技术已非常普及。开发者借助 Llama-Factory 这类'一站式'框架，能低门槛地适配垂直场景。这类工具的核心优势在于对主流架构的高度抽象——无论是 LLaMA、Qwen 还是 ChatGLM，指定路径和配置即可启动流程。

但当面对早期或非典型结构如 Transformer-XL 时，问题就复杂了：它们能否无缝接入？设计特性是否会打破框架假设？要搞清楚这一点，光看文档不够，得深入理解底层机制。

核心依赖与限制

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

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

我们来看一段模拟后台执行的关键逻辑：

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

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)

这段代码隐含了两个关键前提：

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

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

Transformer-XL 的架构冲突

Transformer-XL 由 Dai 等人于 2019 年提出，旨在突破传统 Transformer 的上下文长度限制。它通过两个核心技术实现跨片段记忆：

片段级递归机制：每个注意力层缓存前一片段的隐藏状态，作为新片段的额外输入；
相对位置编码：采用基于距离的相对偏置维持位置感知。

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

这直接挑战了现代微调框架的基本假设。例如在 Hugging Face 生态中，AutoModelForCausalLM 默认要求标准的生成接口（.generate()）、可并行化的注意力实现及清晰的模块命名。而 Transformer-XL 使用自定义的 MultiHeadAttn 模块，没有统一的命名空间，也不完全兼容 GenerationMixin。

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