大语言模型的能力边界正随着参数量级不断扩展，但部署门槛也在同步攀升。当 Mixture-of-Experts（MoE）架构将模型规模推向数百亿甚至千亿参数时，显存需求与硬件成本成为制约本地部署的核心瓶颈。传统思路倾向于 "堆硬件"—— 更大的显存、更强的算力、更昂贵的集群 —— 但对于资源受限的组织或个人开发者而言，这种路径往往不可行。
Rotary GPU 提出了一种不同的视角：与其不断扩展硬件以容纳完整的模型，不如让模型的驻留状态随执行上下文动态旋转。这一思路的核心在于重新理解加速器内存的角色 —— 它不是静态仓库，而是可按需轮转的工作台。
从静态驻留到旋转调度
MoE 架构的稀疏激活特性为内存优化提供了天然契机。在任意时刻，只有部分专家（experts）参与实际计算，其余参数处于休眠状态。然而，传统推理框架通常选择将所有专家权重预加载至显存，以规避运行时加载的延迟。这种 "全量驻留" 策略在数据中心场景下无可厚非，但在消费级硬件上则寸步难行。
Rotary GPU 将加速器驻留重新定义为 "旋转资源管理问题"。系统维护一组固定数量的驻留槽位（slots），而非为每个专家分配永久地址。完整模型权重保留在主机内存或存储层，只有当前及近期可能调用的专家子集被加载至 GPU。关键在于，驻留槽位的更新遵循结构化循环模式 —— 当新的执行上下文出现时，系统按预定旋转策略替换槽位内容，而非简单的 LRU（最近最少使用）淘汰。
这种循环式调度与 LRU 的本质区别在于 "可逆性"。LRU 沿单一方向推进，一旦某个专家被逐出，重返驻留集需要重新经历完整的优先级累积过程；而旋转调度允许系统根据语义上下文的周期性特征，主动返回到先前的驻留配置。这种设计特别适合 MoE 模型中专家调用的局部性规律 —— 某些主题或任务模式可能在对话中反复出现，对应的专家集合可以被循环召回。
分层架构与调度机制
Rotary GPU 的架构可概括为三层：存储层（完整模型权重）、主机内存层（专家子模块缓存）、加速器驻留层（活跃专家槽位）。路由决策基于隐藏状态生成路由向量，通过查找表映射至槽位位置，旋转控制器则负责执行前向或反向的旋转变换。
在典型的配置中，系统同时驻留 32 个专家于 GPU（n-cpu-moe=32），其余专家由 CPU 管理。当路由决策指向非驻留专家时，触发专家切换流程：目标专家从主机内存加载至空闲槽位或按旋转策略替换现有槽位。这一过程与计算流水线重叠，以最小化延迟开销。
值得注意的是，Rotary GPU 的调度并非纯粹基于预测或启发式规则，而是与执行过程中生成的隐藏状态紧密耦合。路由结果直接影响下一轮驻留配置，形成反馈闭环。这种 "上下文感知" 的驻留管理使得系统能够适应动态变化的输入模式，而非依赖静态的预加载策略。
实验验证：消费级硬件上的可行性
论文作者在 RTX 4060 Laptop GPU（8GB 显存）上验证了 Rotary GPU 的可行性。测试模型为 Qwen3.6-35B-A3B-class MoE（Q4_K_M 量化），总参数量 35B，激活参数约 3B。这一配置在常规推理框架下远超 8GB 显存的承载能力。
在推荐配置（n-cpu-moe=32，上下文长度 4096，启用 Flash Attention）下，系统成功生成 2048 个输出 token，显存占用稳定在约 6.3GB，解码吞吐量达到 21.06 tokens / 秒。作为对比，当尝试将驻留专家数提升至 36（n-cpu-moe=36）并保持相同上下文长度时，系统初始化失败，无法进入就绪状态。这一失败案例揭示了内存预算与初始化稳定性之间的微妙平衡 —— 过度追求 GPU 驻留比例可能侵蚀必要的启动余量。
烟雾测试（smoke-set）包含 10 组不同 prompt，全部成功完成，无异常终止。虽然测试规模有限，但初步验证了系统在多样化输入下的稳定性。
可落地的配置参数与实践要点
基于验证结果，可提炼以下工程实践参数：
显存预算分配：在 8GB 显存设备上，建议将 GPU 驻留显存控制在 6-6.5GB 区间，保留 1.5-2GB 余量应对初始化峰值和运行时波动。
专家驻留比例：n-cpu-moe=32 是 RTX 4060 上的推荐值，对应约 80-85% 的专家由 CPU 管理。该参数需根据具体模型专家总数和单专家体积调整。
上下文长度权衡：4096 token 上下文在测试配置下可行，但增加上下文会线性增长 KV 缓存占用。若需更长上下文，应相应降低 n-cpu-moe 以释放显存。
量化策略：Q4_K_M 量化在保持可接受精度的同时，将单专家体积压缩至原始大小的约 25%，是本地部署的必要前提。
失败回退：当遭遇初始化失败时，优先尝试降低 n-cpu-moe 或缩短上下文长度，而非调整其他运行时参数。
局限与未来方向
当前验证存在明显局限：单一硬件平台（RTX 4060 Laptop）、有限的基准覆盖（仅 10 组 prompt）、未公开的实现细节。更广泛的硬件验证（桌面 GPU、工作站加速器、边缘 AI 设备）和更长上下文的评估是未来工作的重点。
多用户并发场景下的行为尚未探索 —— 企业环境通常需要同时服务多个会话，旋转调度策略在共享驻留池条件下的表现仍是开放问题。此外，Rotary GPU 与现有推理框架（如 llama.cpp、vLLM）的集成路径也有待厘清。
尽管如此，Rotary GPU 的核心洞察具有普适价值：大模型部署的瓶颈未必在于模型本身的大小，而在于我们假设 "必须同时访问所有参数" 的前提。当驻留管理从静态分配转向动态旋转，消费级硬件与大规模 MoE 模型之间的鸿沟或许并非不可逾越。
资料来源
- Jo, M. "Rotary GPU: Exploring Local Execution Paths for Large Mixture-of-Experts Models Under Limited GPU Memory." arXiv:2605.29135, 2026.
- Jo, M. "Large Language Model Rotary-Based Accelerator Loading and Execution System and Method." Korean Patent Publication KR 10-2026-0070380, 2026.
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。