Amazon ML：Transformer 与 RNN 的长序列和并行取舍

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 训练比较标准dense self-attention与标准RNN/LSTM，序列长T、宽d；不把所有高效attention/SSM变种混成一个模型。
• teacher forcing训练已知输入token；自回归生成下一个token依赖前一个输出，二者的并行度不同。

解题路线

1. 为何把项目当sequence问题，先解释顺序信息是否改变标签/预测、时间泄漏与是否能用无序baseline；再谈选RNN等模型。没有顺序依赖证据，架构比较也无法替目标假设背书。
2. RNN的h_t=f(x_t,h_{t-1})让同一序列跨t存在顺序依赖；仍可跨batch/矩阵操作并行，不能泛说RNN完全不能并行。Transformer在同一层的已知输入上同时构造QKV与attention，causal mask不阻止训练矩阵并行。
3. dense attention每层计算所有允许token对，主项O(T²d)；QKV/FFN还含O(Td²)。RNN约O(Td²)，状态维度固定不代表保留任意历史信息；长序列性能取决于压缩和训练。
4. attention让远端token一次层内直接交互，RNN需经多个时间步传递，路径长可能有梯度衰减/干扰；LSTM门有帮助，但不是保证任意长度记忆，attention也不是保证找对远端事实。
5. 生成时Transformer仍逐token，用KV cache复用历史投影，但当前query要读历史K/V，cache随上下文增长。RNN可只保留固定hidden state，因此小内存/流式场景可能更合适，质量要实测。
6. 长输入要看有效context、位置编码外推、训练长度、数据噪声和检索任务。FlashAttention能减少显式score内存/IO，不能将dense所有对算术成本神奇变线性；滑窗/检索会改变信息可达性。
7. 评估分别测训练吞吐、prefill、decode每token延迟、峰值内存和任务正确率，控制batch/精度/模型宽度，避免只拿一条大O宣称架构永远胜出。

手动走一遍

32k token输入中开头有订单号、末尾问订单状态：dense attention可直接连接相关位置，但需学会用该信号；RNN须把相关信息一直留在状态中。若将窗口截至最后4k，窗口attention根本看不到订单号，须保留摘要/检索，不能靠架构名称保证答案。

规模与取舍

每层dense attention O(BT²d+BTd²)，朴素score内存O(BhT²)；RNN约O(BTd²)，训练保存激活O(BTd)，推理状态O(Bd)。Transformer KV缓存约O(BLTdKV)，L为层数、dKV取决于KV头数。

易错点与追问

容易失分的边界

• causal训练和生成混淆。
• attention能关联远端就说永不遗忘。
• RNN状态固定就说完整历史免费存储。
• IO优化当线性算术。

继续深挖

• KV cache为何加速decode却不能并行未来token？
• 滑窗层叠的信息传播范围怎样估算？
• GQA怎样改变KV内存？
• 长context质量下降如何诊断？