GPT-6.1 Sol「泄露」疑云：循环与嵌套模型架构浮出水面

一位 Reddit 用户基于公开的推理速度数据，对 OpenAI 下一代模型 GPT-6 系列的底层架构进行了一番「侦探式」推演。尽管这些模型是闭源的，但其中涉及的**循环 Transformer（looped transformer）与嵌套模型（nested models）**两大技术思路，对整个本地 AI 社区都有参考价值——如果这类架构真能在工业规模落地，开源阵营也可能会跟进实验。

循环架构：用更多前向传播换取「有效深度」

讨论的起点是坊间对 GPT-6 Astra 的猜测：它被认为采用了循环 Transformer 架构，即在输出一个 token 之前执行多次前向传播，而非传统的单次传播。

这种做法的核心逻辑在于「以计算换深度」。通过递归复用同一组权重，模型可以获得更大的有效深度（effective depth），让每一份参数被反复利用，代价则是单位 token 的推理算力显著上升。

据原帖引用的 Azure Foundry「泄露」信息，出现了相当具体的数字：GPT-6-Sol 曾以每 token 3 次推理传播运行，而 GPT-6.1-Sol 只需 2 次。不过不少人认为，真正跑 3 次传播的可能是 Astra，而非 6-Sol——6.1-Sol 本质上是同一个模型，只是把传播次数降到了 2 次。

循环 Transformer（Looped Transformer） 并非全新概念，学术界已有多篇论文探讨其理论基础。其核心思想是将 Transformer 的层堆叠改为「同一组层反复执行 N 次」，理论上等价于一个深度更大的网络，但参数量不变。这与递归神经网络（RNN）的精神有相似之处，区别在于每次循环使用的是完全相同的权重副本，而非不同时间步的独立参数。

这种架构在推理时面临一个根本性的工程权衡：循环次数越多，单 token 延迟越高，但模型「思考」的深度也越大。这与当前流行的「思维链（Chain-of-Thought）」或「推理模型」在外部生成更多 token 的做法不同——循环架构把额外计算内化到模型的前向传播内部，对用户来说输出看起来是一步完成的。对于需要深度推理但对延迟有一定容忍度的任务（如代码生成、数学），这种权衡可能更为合算。

从推理速度反推架构

由于无法直接验证闭源模型，发帖者转而借助 Artificial Analysis 上的**推理速度（tok/s）**作为间接线索。他明确指出这并不能构成证明，但数据呈现出耐人寻味的规律：

• GPT-6-Sol 与 5.6-Sol：约 100 tok/s
• GPT-6.1-Sol：约 60 tok/s
• GPT-6-Astra：约 60 tok/s

如果 6.1-Sol 和 Astra 共享同一套权重并运行在批量推理（batched inference）环境下，那么 Sol 的请求可能需要额外等待一个周期，直到 Astra 的请求完成 token 生成，从而把两者的速度都压到了相近的水平。发帖者进一步推测，服务端可能通过交错请求（interleaved requests），在 Sol 等待周期中榨取被闲置的算力利用率。

另一个被注意到的现象是 Luna 系列的速度变化：5.6-Luna 在 126–137 tok/s 之间，而 6.0-Luna 掉到了 110–115 tok/s。考虑到样本横跨多个基准和推理档位，这个下滑在作者看来相当显著。

批量推理（Batched Inference） 是大规模语言模型服务的核心优化手段：推理服务器会将多个用户请求合并为一个批次（batch），在同一次 GPU 前向传播中同时处理，从而摊薄显存带宽和计算启动的固定开销，大幅提升硬件利用率。然而，当同一套权重需要为循环次数不同的请求提供服务时（例如 Astra 跑 3 次、Sol 跑 2 次），不同请求的完成时间会出现错位，造成部分请求必须「等待」其他请求完成整个循环周期才能出队。这种现象会拉平不同档位模型的表观吞吐速度，正是发帖者观察到 6.1-Sol 与 Astra 速度趋近的潜在解释之一。交错请求（Interleaved Requests） 则是在等待间隙插入新请求的调度策略，可将因同步等待造成的算力空闲转化为有效计算。

嵌套模型：一套权重，多个「身份」

真正把推演串起来的，是作者想起 NVIDIA 此前展示过的一个「怪异」模型——在一个大模型内部嵌套多个小模型，它们可以在统一的部署足迹（footprint）下运行。

由此引出一个大胆假设：Astra、Sol、Luna 可能本就是同一套权重。

• Luna 或许是 Astra/Sol 的「精简版」，只激活一半参数，或每 token 只跑一次传播，以极低成本服务免费用户；
• Sol 这类几乎无人使用、不产生营收的模型，就不必单独部署一套集群；
• 整体上，循环架构与嵌套架构同时使用，可以在规模化部署时大幅压低成本。

换句话说，不同的产品名可能只是同一基座在传播次数和激活参数量两个维度上的不同配置档位。这既解释了速度差异，也符合商业上「让付费场景拿更多算力、免费场景用更省配置」的直觉。

NVIDIA 展示的嵌套模型技术与学术界的 Matryoshka（套娃）表示学习 思路一脉相承。其关键在于训练时就让模型的子集（更少的层、更少的注意力头或更低的激活维度）具备独立可用的能力，而不是事后剪枝。这样一来，同一组权重可以按需「切片」：旗舰场景使用全部参数与全部循环次数，轻量场景只激活部分结构并减少传播次数，两者共用同一份模型文件和同一套推理集群。

从部署工程角度看，这意味着运营商无需为每个产品档位维护独立的模型副本和对应的 GPU 显存占用。尤其在数据中心级别，将多个「虚拟模型」合并到同一物理权重上，可以显著提升 GPU 利用率、降低冷启动开销，并简化版本更新的运维复杂度。

对开源社区意味着什么

发帖者坦言这一切「无法证明」，只是强烈的暗示（strongly hints）。但他认为，如果循环架构确实能在工业规模稳定工作，那将是一个重要信号：DeepSeek^广告、Qwen、GLM 等开源模型团队或许会开始认真实验这类架构。

嵌套模型本身也带来独特收益——用一套权重覆盖从旗舰到入门的多个档位，部署与运维成本都能大幅摊薄，这对资源有限的开源团队尤其有吸引力。

需要强调的是，本文内容来源于单一的社区推测帖，所引数据与型号命名均属未经官方证实的「泄露」与反推，读者应将其视为一种架构思路的探讨，而非确凿事实。即便如此，循环与嵌套这两条技术路线本身的工程价值，仍值得本地 AI 社区持续关注。