Rotary GPU：在有限显存下探索大型MoE模型的本地执行

# 面向受限GPU内存下大规模混合专家模型的本地执行路径探索
来源: https://arxiv.org/html/2605.29135
\(2026年6月\)

###### 摘要

大规模语言模型通过参数扩展实现了卓越能力，本文并不对此提出质疑。相反，它探讨了一个不同的问题：当大型模型已经存在时，能否使其在硬件资源显著较小的环境中变得更为可及？其动机来自部署层面的关切，而非架构研究。许多组织受到硬件、预算、安全或封闭网络等限制，无法使用大型加速器集群。随着模型的不断改进，部署可及性可能变得与能力本身同等重要。

本文提出了旋转GPU，这是一种源自先前公开的基于旋转的加速器驻留概念的可探索性执行方法。我们使用Qwen3.6-35B-A3B类混合专家模型在配备8 GB VRAM的RTX 4060笔记本电脑GPU的消费者笔记本电脑上进行了公开验证。在主要配置下，系统生成了2048个输出令牌，同时保持约6.3 GB的VRAM使用量，并实现了21.06令牌/秒的解码吞吐量。目标并非取代数据中心基础设施，而是探索是否能够将大型模型的某些能力带到无法使用此类基础设施的环境中。结果应被视为探索性而非决定性，但表明随着这些模型的发展，部署可及性值得持续研究。

## 1 引言

自Transformer架构及随后的GPT系列成功以来，语言建模的进展一直与规模紧密相关。更大的数据集、更大的模型以及更强大的基础设施反复带来了更强的性能。现代系统已能在总结文档、生成软件、翻译和回答问题等方面达到几年前看似不切实际的水平。这种扩展范式的成功难以反驳，本文的目的也并非反对它。

相反，它提出了一个不同的问题：当大型模型已经存在时，它们是否必须始终与同样大型的硬件绑定在一起？大多数关于部署的讨论都将额外内存、更大加速器和更大的服务集群视为更强大模型的自然结果。这种方法已取得显著成功。但部署现实与研究现实并不相同。许多组织在涉及安全、合规、硬件可用性、基础设施成本、物理空间和运营复杂性的实际约束下运作。政府机构、金融机构、制造设施、医疗机构和国防相关环境通常维护着封闭或部分隔离的网络，在这些环境中，即使真正渴求先进的模型能力，访问大规模云基础设施也可能受到限制。

这一观察激发了本文的核心问题。如果模型的某个子集在特定时刻仅与特定上下文相关，那么整个模型是否必须始终驻留在加速器内存中？一个简单的类比捕捉了其中的直觉：即使客户只要求一件物品，仓库仍然有价值。真正的问题不在于仓库是否应该存在，而在于每一次配送是否都需要将整个仓库连同包裹一起移动。大多数配送系统将仓库留在原地，只移动可能需要的物品。大型模型推理远比包裹配送复杂，不应字面理解这个类比，但正是这种直觉启动了这项研究。

同样的理念出现在许多大型信息系统中。在任何给定时刻，只有可用信息的子集是主动相关的，检索系统、内存系统和路由系统都利用了这一点。本研究探讨加速器驻留管理是否也能受益于类似的视角。这个想法源于作者对基于旋转的结构在检索、内存组织、路由和执行管理方面的一系列独立调查，并在此扩展到本地大型模型执行领域。本文不披露实现细节，而是聚焦于公开验证和外部可观察行为。

目标并非建立最先进的性能或取代现有的部署架构。它要简单得多：调查在传统上被认为不足以支持如此规模模型的硬件条件下，能否仍然可能对大型混合专家模型进行有意义的执行。因此，结果应被解释为探索性的。在得出更广泛的结论之前，仍然需要额外的硬件平台、操作系统、工作负载和独立复现，但观察表明，部署可及性作为一个部分独立于模型扩展本身的问题，值得研究。

## 2 动机与部署现实

旋转GPU的动机源于部署关切，而非试图重新设计语言模型架构。我的专业背景是组织运营与人力资源管理，其中大部分工作涉及信息访问、重复性任务、流程效率、文档处理和运营决策。随着语言模型能力的增强，一个自然的问题浮现：这些能力如何能够进入普通组织内部？

答案并不明显。许多组织没有专门的AI基础设施，即使先进模型可能带来明确价值，部署仍面临硬件预算、采购流程、安全要求、维护责任和网络限制等实际约束。大型云托管模型可能提供卓越性能，但如果组织政策禁止敏感信息离开内部基础设施，则可能不切实际。同时，为这类组织构建大型加速器集群通常不可行，因为硬件采购、电力要求、冷却、维护成本和运营专业知识都是真正的障碍。结果是，即使更大型模型更可取，许多组织仍将部署较小的系统。

这重新定义了问题。与其问如何不断增加可用硬件，不如问部署策略本身能否变得更高效：大型模型能否在更小的硬件范围内变得可用，并且本地执行能否对无法维护大型AI基础设施的组织成为现实？旋转GPU源于这些问题。目标不是取代云系统——云系统对于训练前沿模型和支持大规模服务仍然不可或缺。可及性而非取代，是动机所在。

## 3 相关工作

现代语言建模的基础由Transformer架构奠定，它引入了基于注意力的序列建模，并实现了可扩展性的显著提升。随后的GPT系列系统表明，增加模型大小、数据集大小和训练计算量可以在广泛任务上带来持续改进。随着规模扩大，推理效率成为越来越重要的研究领域，目前存在多种减少内存消耗或提高吞吐量的方法，包括量化、激活稀疏性、内存压缩、推测解码、KV缓存优化、加速器感知调度和参数卸载。其中，量化已成为本地部署最实用的技术之一，并广泛用于消费级硬件。

混合专家架构引入了另一个重要观察。混合专家系统不是为每个令牌激活每个参数，而是通过可用专家的子集路由计算，从而能够在不成比例增加每令牌成本的情况下访问更大的参数空间。这种选择性计算自然引发了一个关于选择性驻留的问题：如果只有部分专家在某一时刻参与计算，那么每个专家是否必须持续驻留在加速器内存中？有几个现有系统通过内存卸载、分层存储、预取、主机-设备协调和混合执行来研究相关理念，表明驻留可以被视为一个动态资源管理问题而非静态分配问题。

本研究探索了一个不同的角度。旋转GPU不是将驻留仅仅视为缓存管理，而是研究驻留决策是否可能通过受执行上下文影响的结构化旋转转换而演变。目的不是声称优于现有方法，而是呈现一个探索性验证，表明在显著受限的硬件下，大型模型执行仍然可能。

## 4 旋转GPU概念

旋转GPU基于一个简单的观察：在推理过程中，大型模型的每个组成部分并非在每一刻都同等贡献。某些专家、路由路径、执行区域或参数组在特定上下文中变得高度相关，而其他则保持不活跃。完整模型整体上仍然重要，但即时计算需求往往集中在较小的资源子集中。这激发了一种驻留管理视角：不是假设每个组件必须永久驻留，而是系统优先考虑在近期可能变得相关的组件。

在概念上，旋转GPU将加速器驻留视为一个旋转式的资源管理问题。驻留位置被视为插槽而非固定分配，并且不是假设每个组件持续驻留，而是允许驻留候选者根据结构化的旋转调度决策在插槽之间移动。这个概念可以通过三个原则来理解：驻留是动态而非永久的；驻留决策可能受执行过程中生成的信息而非仅由静态配置影响；驻留转换可能遵循结构化的循环模式，而非纯粹的反应式替换策略。这与传统的最近最少使用（LRU）驱逐形成对比，后者仅根据使用的新近度单向推进，且没有提供结构化方式在早期上下文重现时返回到先前驻留的集合。

库存管理提供了一个直观的平行。一个包含数千件物品的仓库不需要每件物品同时出现在装卸平台；库存根据预期需求在存储位置之间移动。旋转GPU的观点不在于决定模型的哪些部分重要——因为完整模型仍然重要。问题在于每个组件是否必须始终同等可访问。

图1（https://arxiv.org/html/2605.29135#S4.F1）显示整体结构，图2（https://arxiv.org/html/2605.29135#S4.F2）说明了插槽组的循环更新。本文不披露实现细节、调度算法、保护机制或内部执行逻辑；其目的是评估更广泛的架构方向能否在受约束的硬件下产生有意义的执行结果，这对于可用加速器内存远小于目标模型表面大小的部署场景至关重要。

主机内存/存储层全模型权重 \(占用空间>>VRAM\)子模块\(专家/层\)SM1SM2SM3⋯SMn-1SMn路由结果隐藏状态h、路由向量r旋转插槽组插槽1插槽2⋯插槽N循环旋转查找表子模块ID→插槽位置旋转控制器旋转变换→旋转投影选择性加载驱逐仅子模块子集驻留在加速器上；通过旋转而非简单LRU驱逐更新驻留。图1：旋转GPU驻留系统。全模型权重保留在主机内存中，仅子模块的旋转子集驻留在加速器上。摘自韩国专利公开号10-2026-0070380，图1。插槽t插槽t+1插槽t+2插槽t+3插槽t+4插槽t-3插槽t-2插槽t-1前进后退插槽内容通过旋转变换按循环顺序更新；重复出现的语义上下文允许循环返回到先前的插槽集合。图2：插槽组的循环向前和向后旋转。与单向LRU驱逐不同，驻留沿旋转变换驱动的循环前进（并可返回）。摘自韩国专利公开号10-2026-0070380，图2。

## 5 与已公开专利的关系

此处研究的架构方向与先前的韩国专利公开相关，该专利涉及基于旋转的加速器驻留管理和执行调度。该专利描述的概念包括旋转插槽组、循环向前和向后旋转、隐藏状态引导的驻留决策、查找表映射结构、加速器加载控制以及内存受限的执行机制。

本文不应被解读为专利说明书的复现或完整的实现披露。其目的是记录一项公开验证工作，旨在确定更广泛的架构方向能否在实际硬件约束下产生有用的执行行为。仅讨论外部可观察行为、实验条件和验证结果；内部过程不在其范围内。这种区分是有意为之，因为专利描述的是知识产权主张和受保护的技术方向，而研究报告描述的是观察结果。

## 6 实验设置

主要目标很简单：一个大型混合专家模型能否在仅8 GB GPU内存的消费者笔记本电脑上本地执行？验证特意使用了普通硬件而非专门的加速器基础设施，因为目的是研究实际可行性而非最大化基准性能。

表1：验证硬件表2：模型配置验证包不分发模型权重；用户提供自己兼容的文件。这样可以在避免重新分发第三方模型资产的同时，允许对执行行为进行公开验证。主要的操作配置使用了4096的上下文长度、32的n-cpu-moe、启用Flash Attention、本地推理且不依赖云。该配方的目的是在目标硬件的内存限制内最大化实际可用性。

## 7 开发时间线

所报告的验证并非单一实验的结果，而是源于一系列关于执行稳定性、路由行为、内存驻留、吞吐量、量化策略和部署约束的调查。在最终操作配方选择之前，评估并放弃了几个中间配置。表3（https://arxiv.org/html/2605.29135#S7.T3）总结了主要里程碑。

表3：导致最终操作配方的开发里程碑。

## 8 结果

### 8.1 长输出验证

主要配置成功初始化并执行了目标模型。