简介：这是基于Google Research远程竞技场（LRA）基准测试的Python实现，面向从事长序列建模研究的深度学习科研人员。它用PyTorch和HuggingFace Transformers重写了原始Jax/Flax代码，使基准测试更易理解、便于二次扩展。压缩包包含7个文件，主要是4个Python脚本、1个Shell脚本和1份Markdown说明，总大小仅5KB，轻量精练。运行sh ./get_data.sh即可自动下载所需数据集，再通过python run_model.py快速跑通简单模型，lra_datasets.py与lra_config.py则分别负责数据加载和模型配置。目前已有174人学习下载，这份代码可帮助PyTorch用户跳过Jax门槛，在标准长序列任务上快速评估模型、获取基线结果。

1. LRA 不是又一个跑分刷榜，而是长序列模型翻车的第一现场

LRA（Long Range Arena）是一组把序列长度从 1000 推到 16000 token 的跨任务 benchmark。很多人第一次跑 LRA 是因为看到某模型宣传“在 Long Range Arena 上达到新高度”，但真正上手后会发现，它测的不是花哨的榜单，而是模型在长序列下能不能活下来：显存会不会爆、注意力会不会退化、准确率会不会掉回随机水平。我实际测过一个在短文本分类上表现正常的模型，到了 LRA 的 Pathfinder 任务上只有 55% 左右。它适合两类人：一类是要评估 transformer 变体、线性注意力、稀疏注意力方案的算法工程师；另一类是准备把模型放到长文档、多轮对话这类生产场景，想先探明边界的人。它不是一个展示台，是一台压力测试机。

2. LRA 的五个任务分别卡住哪类能力：任务构成与选型理由

2.1 五个任务测的不只是长度：复杂度与依赖类型

LRA 之所以叫 Arena，是因为它由五个差异很大的子任务组成，在数据形态、序列长度和考察能力上几乎不重叠。第一次跑的时候我甚至怀疑它们是不是同一套基准：ListOps 给出一串嵌套表达式，目标是算出结果，考的是层级结构和括号匹配；Document Retrieval 把查询和文档拼成一个长序列，考的是从大段文本中定位关键片段；Text 任务是拿 IMDB 评论文本的原始字节序列做情感分类，不切词不做词嵌入，要求模型从字符依赖中学到语义；Image 任务把 CIFAR-10 的 32x32 图片按像素展开成 1024 长度的序列，考空间局部依赖；Pathfinder 把 128x128 灰度图展平成 16384 长度，判断两个点是否在同一条曲线上，是五个任务序列最长、也最容易暴露注意力退化的一个。

梳理成表格之后会更直观：

ListOps 和 Pathfinder 是两个极端：前者序列不长但规则复杂，模型容易在小表达式上过拟合，却无法泛化到更长输入；后者序列极长，很多高效注意力在 8K 以上会失效。一个能在所有任务上不掉点的模型，才说明它真正具备长序列建模能力，而不是只在某个特定长度上“看起来不错”。

2.2 序列长度从 1K 到 16K 设下的复杂度门槛

LRA 的设计不是简单地把任务做长，而是把长序列可能踩到的坑按梯度铺开。1K 到 16K 的跨度意味着：模型在 1K 上还能用全局注意力勉强跑通，到 4K 就得认真考虑复杂度，到 16K 基本迫使你换架构。标准 transformer 的完整 attention 矩阵大小随序列长度平方增长，1K token 时单层单头约百万级元素，16K 时直接超过两亿，乘上多个头和 batch，显存和算力都会失控。

这带来一个实际问题：很多自称“高效 transformer”的模型在 LRA 上精度崩掉，往往不是实现问题，而是位置编码和依赖建模在长距离上退化。LRA 的每个任务都有独立训练集和测试集，测试长度分布与训练一致，所以你测的不是外推能力，而是模型在数据本身就很长的情况下能学到多少。这给选型提供了关键判断：如果模型只在 ListOps 上刷高，说明它对局部结构敏感，不足以证明能处理长程检索；如果只在 Pathfinder 上能过，可能更贴近视觉类长序列场景。因此做对比时不要只盯平均分，要看模型在不同长度段上的表现趋势。

我在实验中会额外把每个任务的实际长度分布打出来，而不是看官方给的典型长度。ListOps 在 2000 左右但方差很大，有些样本接近 4000；Retrieval 会因为文档拼接出现很长的尾部。直接用平均长度做 padding 策略，会导致一批样本里 80% 的 token 都是 padding，训练速度被拖慢，注意力分布也被污染。按长度排序分桶是更稳妥的做法。

2.3 快速验证选哪几个任务：三件套与压力测试

如果你是第一次接 LRA，我不建议一上来就把五路训练全部跑完。ListOps 序列约 2K，数据规模适中，单卡通常几十到几百步就能看到上升趋势，适合作为冒烟测试。Text 任务数据量大，但实现简单，序列 4K 左右，是验证模型能否从字节级信息里稳定收敛的好选择。Image 任务只有一个维度是长度，且数据来自 CIFAR-10，比较容易对照图像分类的常识判断训练是否正常。这三个任务合起来可以当作常规“三件套”，先确认模型在基础长序列场景下不翻车。

最难啃的是 Retrieval 和 Pathfinder：Retrieval 需要拼接查询和文档，容易引入大量不相关信息，对位置编码和池化方式非常敏感；Pathfinder 的 16K 序列会让绝大多数非稀疏注意力模型显存吃力。我一般把这两个任务放在算法稳定之后才跑，作为最终压力测试。如果算力有限，我建议用“ListOps + Text + Image”三件套做常规对比，再用 Pathfinder 验证长程依赖极限。这样既能看到长序列边界，又不会让 benchmark 变成一次性烧卡项目。

做这类对比时还要固定基线。常见做法是选一个参数规模相近的标准 transformer，保证优化器和训练步数一致。否则一个模型用调好的学习率，另一个用默认参数，最后把差距都归到架构上，就失去了评测意义。我会先给每个模型相同的 token 预算和训练步数，再允许每个任务单独调学习率和 dropout。LRA 评测的是“在同样预算下能收敛到什么程度”，而不是“显存不够就砍 batch”。

2.4 平均分不是金标准：LRA 的分数结构天生适合消融

LRA 的官方指标是五个任务准确率的算术平均，但这个平均分很容易掩盖问题。某个模型在 ListOps 上比基线高 4%，在 Pathfinder 上低 6%，平均分可能只差 0.4%。如果只看最后的总分，你会误判这个模型值得推广，实际上它在真实的长视觉依赖场景里已经退化到接近随机。所以我在内部报告里从来不看平均分排行，而是把每个任务的分数差单独列出来。

更推荐的做法是规定一个基线模型，然后对候选模型做逐任务差值分析。比如记录“关闭位置编码”“把窗口注意力换成全局注意力”“将 FFN 扩大一倍”这三个改动分别在五个任务上的正负贡献。这样能快速定位模型适合哪种依赖类型。LRA 的价值恰恰在于它不是一个可以靠单项优势带过的榜单，而是逼着你把每个任务的结果摊开，回答为什么涨、为什么跌。

3. 本地跑通 LRA 最小流程：从环境配置到出分数

3.1 数据预处理：npy 结构、padding 与 mask

LRA 数据通常以 npy 二进制格式发布，不是直接丢一堆文本给脚本。你需要先从公开渠道拿到数据生成或下载脚本，在本地生成train.npy、dev.npy、test.npy以及对应标签文件。对 ListOps 来说，文件里是整数 token id 序列；对 Image 和 Pathfinder 来说，则是图像数组。我一般会先写一段检查代码，确认样本数量、序列长度和标签范围，再进入训练流程。

import numpy as np data = np.load("listops/train.npy", allow_pickle=True) labels = np.load("listops/train_labels.npy", allow_pickle=True) assert data.shape[0] == labels.shape[0], "sample count mismatch" lengths = [len(seq) for seq in data] print(f"min={min(lengths)}, max={max(lengths)}, mean={np.mean(lengths):.1f}") print(f"label range: {labels.min()}..{labels.max()}")

逻辑说明：ListOps 每个表达式长度不同，直接堆成矩形 batch 需要 padding 到 batch 内最大长度。这里的断言先检查样本数一致，再打印序列长度分布和标签范围，能在训练前暴露数据错位。参数说明：allow_pickle=True是因为部分 npy 文件里存的是 object 数组，每个元素是整数列表；如果旧版 numpy 载入失败，优先查 Python 和 numpy 版本，而不是盲目改数据。

预处理还要统一三个细节：padding 方向、attention mask 构造、标签是否需要 one-hot。我推荐右侧 padding，并用布尔矩阵表示 mask；token 为 0 的位置在计算 loss 时也要移除。很多实现喜欢把 padding 塞到 0 位，但 LRA 不少任务里 0 是合法 token，减 1 之后会把标签空间也改掉，属于隐蔽坑。

3.2 用 ListOps 跑通第一个模型：最小命令与训练循环

数据就绪后，我会先写一个只包含编码器的小模型跑 ListOps，因为它序列最短、数据量适中，最方便验证链路。下面是一个最简流程的命令骨架：

export CUDA_VISIBLE_DEVICES=0 export TOKENIZERS_PARALLELISM=false python train_lra.py \ --task listops \ --data_dir ./data/listops \ --model_type transformer \ --num_layers 4 \ --d_model 128 \ --num_heads 4 \ --ff_dim 512 \ --dropout 0.1 \ --batch_size 32 \ --learning_rate 3e-4 \ --warmup_steps 200 \ --max_steps 5000 \ --eval_steps 250 \ --checkpoint_dir ./ckpt/listops

逻辑说明：这份命令假设train_lra.py已经封装了数据加载、训练循环和评估逻辑，是社区里的常见形式。--task listops决定加载哪个数据目录；--model_type transformer用标准编码器作为基线；--num_layers/d_model/num_heads/ff_dim控制模型尺寸。参数说明：这里的模型约 1M 参数，足够在 ListOps 上达到有意义的分数，又不会让调试变慢；batch_size 32对应平均 2K token 时显存压力不大，如果你的卡只有 8G，可以先降到 16；warmup_steps建议设为总步数的 5%-10%，比例比绝对值更重要。

训练主循环也值得自己写一遍，后续换自定义模型时才不会被黑匣子卡住。核心逻辑如下：

for step, batch in enumerate(train_loader): input_ids = batch["input_ids"].to(device) mask = batch["attention_mask"].to(device) label = batch["label"].to(device) logits = model(input_ids, mask) loss = criterion(logits, label) optimizer.zero_grad() loss.backward() clip_grad_norm_(model.parameters(), 1.0) optimizer.step() if step % eval_steps == 0: acc = evaluate(model, dev_loader) print(f"step {step} | loss {loss:.3f} | acc {acc:.3f}")

逻辑说明：这版循环把 mask 同时用于 attention 和 loss 计算，模型内部自行处理 padding。clip_grad_norm_对长序列任务非常重要，16K token 下梯度范数很容易冲高。参数说明：input_ids是 batch 内 padding 到同一长度的 token 序列；label是标量索引；eval_steps控制验证频率，太大会漏掉最优 checkpoint，太小会增加无用开销。

3.3 日志解读：loss、acc、显存与平均分

LRA 的最终指标是各任务测试集准确率以及所有任务的平均分，但单次运行日志里有很多字段需要区分。我会把一个 step 的日志拆成四类：loss、accuracy、速度、内存。loss 是训练集上的滑动平均，只能看收敛趋势；accuracy 在 dev 集上评估，更接近泛化；速度以 samples/s 为单位，和显存一起决定模型有没有工程可行性。

下面是我常用的日志模板：

step 2500 | loss 1.83 | acc 0.64 | 4.2 samples/s | gpu_mem 3120MiB

字段含义：acc是最近一次 eval 的准确率，gpu_mem是当前进程占用显存。参数说明：我把--eval_steps设为 250，也就是每 250 步跑一次完整验证集；如果数据太大导致评估耗时比训练还长，可以抽样 1000 条做快速评估，但要固定随机种子。

出报告时，我会把五次运行的最佳或平均准确率整理出来。注意平均分计算前要确认五个任务都是准确率，直接算术平均即可。但总分不是终点，还需要记录每个任务的运行时间和显存峰值，用来评估模型在真实场景里的代价。

4. LRA 超参数调优：批次、学习率、FFN 占比与位置编码

4.1 对 LRA 分数影响最大的三个超参数

LRA 任务之间差异大，但大量实验后发现三个超参数对分数影响最明显：批次大小、学习率和 FFN 占比。批次大小直接影响 attention 矩阵显存占用，也会影响梯度稳定性。LRA 的标签分布方差大，如果 batch size 只有 8，梯度噪声会非常明显，模型可能完全不收敛。我通常先在 ListOps 上做小网格搜索，固定 batch size 为 32，学习率按 1e-4、3e-4、1e-3 三档试，选出最稳的一组再套到其他任务。

学习率在 LRA 上通常比短文本任务设得更保守，因为序列长，单个 batch 叠加的梯度信号更强。3e-4是 transformer 类模型的常用起点，但如果你的模型加了线性注意力或稀疏注意力，梯度分布会变化，需要重新扫。训练步数也要按任务单独设：ListOps 约 5 万步能到不错位置，Text 类似；Pathfinder 如果模型不大，1 万步就能看到边界。我习惯用 early stopping，连续 10 次 eval 没有提升就停，避免过拟合到 dev 集。

FFN 占比也很关键。标准的 feedforward 维度一般是4 * d_model，但在长序列任务里，增大 FFN 比增加注意力头数更有效，因为注意力在长距离上容易过度平滑，需要更多参数去拟合任务模式。反过来，FFN 过大又会在小数据集上过拟合。LRA 的五个任务数据量都不算大，我会把 FFN 比例暴露在配置里，分别试3x、4x、6x。经验是 Pathfinder 和 Retrieval 对 FFN 更敏感，ListOps 则相对稳定。

4.2 位置编码与归一化：长序列稳定性的关键

长序列任务里，位置编码往往比模型主体更影响结果。LRA 的五个任务中，绝对位置编码在 ListOps 和 Retrieval 上勉强可用，在 Pathfinder 的 16K 序列上会严重拖后腿。原因是绝对位置编码对未见过的绝对位置很敏感，而 Pathfinder 把二维像素平面展平后，位置关系并不自然。常见替代方案是旋转位置编码 RoPE 或相对位置编码，在长序列上更能保持平移不变性。

我跑 LRA 时会把位置编码做成可开关选项，同一个模型分别打开和关闭位置编码来对比。很多高效注意力模型在长任务上不收敛，不是核心机制有问题，而是位置编码没有跟着换。另一个容易被忽略的是归一化位置。Pre-Norm 通常在长序列下比 Post-Norm 稳定，因为梯度流更直接，但 Post-Norm 在某些任务上会意外更好。不要迷信某个机制天生适合 LRA，把norm_type和pos_enc_type都暴露到配置里，每个任务单独跑一组小矩阵实验。

还有一个细节：如果使用 AdamW，不要对位置编码参数施加和主体参数相同的 weight decay。位置参数被正则化过强，会让模型逐渐丢失位置信息。常见做法是按参数名分组，对位置编码和 bias 设置较小的 weight decay 甚至为 0。这个改动在短任务上差异不大，但在 Pathfinder 上经常能救回 2% 到 3% 的准确率。

4.3 用一张表管理多任务实验结果

当你在五个任务上分别跑三种模型时，实验记录会很快乱掉。我坚持用一个统一表格保存结果，每次试验一行，字段包括模型名、任务、参数量、序列长度、batch size、学习率、dev accuracy、测试准确率、训练时长。下面是一个简化示例：

这个表里最关键的不是总分，而是同一模型在不同任务上是否均衡。我遇到过某模型在 ListOps 上比基线高 3%，但 Text 任务低 2%，平均分几乎不变。这种模型如果上生产，很可能在长文档场景里暴露问题。LRA 迫使你把每个任务的结果并列出来，逼自己回答为什么涨、为什么跌。每次实验结束，我会在备注里写一句结论，例如“去掉相对位置编码后 Retrieval 掉 4 个点”，这是复盘时最有价值的部分。

5. LRA 跑分的 5 个常见坑：现象、原因与排查

5.1 Accuracy 卡在随机水平：先查数据再查分类头

现象：训练 loss 在下降，但 eval accuracy 一直待在 10%（ListOps）或 50%（Text）附近不动。原因：最常见是标签映射错位。LRA 的标签不是标准 0~N-1 顺序，有的从 1 开始，或者分类头输出维度设错。其次，attention mask 没有在池化层生效，padding token 参与了最终分类。解决：打印一个 batch 的input_ids、label 和模型输出 shape，人工核对；再把 mask 画出来确认非 padding 区域是连续的。我遇到过一次典型事故：np.load后数组元素是 object 类型，结果把整个序列当成一个 token 输入，模型当然只能随机猜。检查办法就是打印len(seq)是否合理。

5.2 显存不够：减 batch 不如换注意力实现

现象：跑 Pathfinder 时，batch size 降到 1 仍然 OOM。原因：Pathfinder 序列长度 16K，标准全注意力单层单头 attention 矩阵就有 16384 乘 16384 个元素，约 1GB 内存，多层叠加后很快溢出。解决：不要继续减 batch，而是换稀疏注意力或线性注意力变体；如果一定要跑全注意力，可以对序列做 block 切分或使用梯度检查点。梯度检查点会牺牲约 30% 训练时间，但能把中间激活显存压下来。另一个务实做法是先用 128x128 分辨率的 Pathfinder，不要一上来就挑战 Pathfinder-X 的 256 或 512 分辨率。我的判断是，8G 显存跑 16K 全注意力几乎不可能，别跟物理规律较劲。

5.3 训练不收敛：NaN、梯度爆炸与 fp16 的锅

现象：前几百步 loss 在 2.0 附近反复震荡，或者直接变 NaN。原因：长序列下梯度范数很容易超过 10，尤其是在 fp16 混合精度下；此外学习率过大、warmup 过短也会导致不收敛。解决：先切回 fp32 跑 500 步，确认模型本身能收敛；如果能，再开混合精度并检查 loss scaler。梯度裁剪设到 1.0 是安全默认值，LRA 上不要省这一行。如果 fp32 也 NaN，检查数据里是否有无穷值；Image 任务中像素处理不当也可能产生超大中间量。另一个隐蔽原因：AdamW 的 weight decay 没有排除位置编码，导致位置信息越训越弱，loss 降到一定程度后不再下降。

5.4 平均分被单个任务拖垮：弱任务才是突破口

现象：模型在四个任务上分数正常，Retrieval 或 Pathfinder 只有 51% 左右，平均分被拉低三到五个点。原因：LRA 平均分对弱任务高度敏感，尤其是 Pathfinder，很多高效注意力在这里会退化为只看局部。解决：单独看弱任务，不要先优化平均分。先检查该任务的序列长度是否超过模型设计上限，再看位置编码是不是绝对位置。我遇到过一个典型情况：模型使用窗口注意力，窗口 256，在 ListOps 和 Text 上都很棒，但 Pathfinder 需要跨 5000 像素的依赖，窗口外信息完全丢失，准确率只有 52%。此时需要加入全局 token 或可学习的查询 token 来补充长程信息。这类改动往往只影响弱任务，但比刷总分更有意义。

5.5 复现不出论文分数：随机性、划分与 dropout

现象：用同样超参，跑出来的分数比公开数值低 5 个百分点，重跑还每次不一样。原因：LRA 任务本身方差大，尤其 Retrieval 和 Pathfinder；数据加载线程、GPU 以及 cuDNN 的 benchmark 开关都会引入随机性。解决：固定三个 seed（训练、数据 shuffle、dropout），并在同一卡型、同一 CUDA 版本下对比；报告时用多次运行平均值而非最大值。另一个实践是确认 dev 和 test 划分与原作者一致，有的实现把验证集和测试集用反，结果完全不可比。最后别小看 dropout：0.1 和 0.2 在长任务上可能造成 2% 的差异，论文表格里没写清 dropout 时，复现不出是正常的。

6. 进阶：用 LRA 画模型的长序列“心电图”

跑通 LRA 不是结束，而是开始。我最推荐的做法是把 LRA 拆成消融实验，而不是只看总分。比如对同一个模型，分别关闭位置编码、把全局注意力换成窗口注意力、把 FFN 扩一倍，记录五个任务分数变化。很多改动只在某个任务上生效，其他任务不变甚至下降；只看平均分，这些信息会被完全淹没。我会以全注意力 transformer 为基线，画出候选模型在每个任务上的分数差，正负一目了然。

另一个进阶技巧是构造“序列长度-准确率”曲线。LRA 默认任务长度不足以回答“我的模型到底能撑多长”。我会把 Pathfinder 的分辨率缩小或放大，得到 4K、8K、16K 三档，观察精度下降的拐点。很多模型 4K 时还稳定，8K 开始明显下滑，16K 直接崩。这条曲线能告诉你模型的安全工作范围，比单报一个 16K 分数有工程价值。扩展实验时，注意保持每个长度下的训练步数一致，否则长度变长后训练不充分，精度下滑会被误读成架构缺陷。

最后一个习惯是记录显存和吞吐量。LRA 在学术语境里常被用来刷分，但真实落地时，一个在 16K 上跑得快、精度低 2% 的模型往往比精度最高但显存爆炸的模型更实用。我会在选型时画一条“预算线”：同等显存和训练时长下，谁在 LRA 上平均分高，谁胜出。

我最早跑 LRA 时只盯总分，花了三周调出来的模型平均分涨了 1%，实际丢到长文档场景却比基线还差。后来才明白，LRA 的价值是帮我们把长序列问题拆成一个个可定位的失败模式，而不是给我们一个可以挂在墙上的分数。现在每接一个新任务，我都会先跑一遍 ListOps 和 Pathfinder，用 20 分钟确认模型方向对不对，再决定要不要全量训练。这个习惯帮我避开了很多盲目试错，希望帮到你。

本文还有配套的精品资源，点击获取