RoPE 融合到 Attention 前，先确认位置与频率的合同

RoPE 可以与 Q、K 的生产或读取融合，省去单独张量物化。但“融合”不应改变模型原本使用的旋转定义。不同模型的频率、通道配对、位置偏移和长上下文缩放配置可能不同；这些内容不能从另一个模型直接搬过来。

RoFormer 论文最初提交于 2021 年 4 月，使用旋转编码位置信息。这里先验证二维旋转的两个性质：长度不变，两个位置的点积只依赖相对旋转。它们能帮助检查实现，却不足以证明某个模型能直接替换位置编码。

RoPE 的成对旋转保持范数，并在点积中体现相对位置。

import math

def rotate(v,theta):
    x,y=v; c,s=math.cos(theta),math.sin(theta)
    return (x*c-y*s,x*s+y*c)

def dot(a,b): return sum(x*y for x,y in zip(a,b))
q=(2.,-1.); k=(3.,4.); a,b=.3,1.1
rq,rk=rotate(q,a),rotate(k,b)
assert math.isclose(dot(rq,rq),dot(q,q),rel_tol=1e-12)
assert math.isclose(dot(rq,rk),dot(q,rotate(k,b-a)),rel_tol=1e-12)
print("RoPE: norm and relative-angle identity passed")

分页缓存里位置仍然是逻辑位置

KV 存储被重新分配以后，物理块编号不是 token 位置。已经应用 RoPE 的 K 如果被复用，后续就不能再按新块地址旋转一次。前缀缓存的身份也需要包含模型与位置配置；相同 token 在不同位置策略下不一定有相同 K。

ALiBi 则通常体现为注意力分数上的位置偏置，不能与 RoPE 混称为同一种旋转，也不能假定两个模块叠加就更准确。如果希望改变已有模型的位置策略，需要训练或适配依据，并用任务评估验证。

融合收益取决于数据在哪里

若 Q、K 原本就在寄存器中，旋转后直接进入 Attention，可能避免额外写回。若读取缓存 K 时重复计算三角函数，节省一次 kernel 启动不一定划算。频率表预计算、内存布局与向量配对都需要按目标实现评估。

缓存恢复为什么要携带位置配置

假设一个请求已经在某套频率配置下生成 K，另一个请求使用相同 token 却采用另一套长上下文缩放。即使逻辑位置相同，旋转后的 K 也可能不同。缓存只按 token 列表查找，就会把一种计算状态交给另一种模型语义使用；这种错误通常不会表现成越界，而是输出逐渐偏离参考。

位置偏移也值得单独检查。增量解码的第一个新 token 应接在已有上下文之后，不能每次都从位置零开始。分页与前缀复用使数据在内存中移动，并不改变它的逻辑位置。若要保存旋转前的 K，再在读取时应用位置编码，就需要另一份明确的缓存协议，不能与已经旋转过的 K 混放。

通道配对则会影响每次加载。相邻两个通道成对，与把前半段和后半段对应通道配对，是不同布局约定。只用两个维度的测试可以验证旋转公式，却无法区分这些高维排列。接入真实模型时，应选各维度不同的输入，对照模型定义逐对检查。

融合的实施顺序可以很朴素：先用独立算子对齐参考，再在同一输入下改成融合版本，最后才去掉中间张量。若直接同时改频率表、通道次序和内核融合，一次误差就可能有三个来源。保留分步可回退的路径，会让性能优化的代价更容易控制。

本例中的 Python 三角函数与元组操作没有模拟 GPU 周期，也没有与真实模型比较。在 2026 年的服务后端中，支持多种模型配置已很常见；工程上有价值的融合，是保持合同的同时减少搬运，不能为了一个融合标签改变模型定义。