Two figures are enough to expose the problem: roughly 100 tokens/s for GPT-6-Sol and 5.6-Sol, while GPT-6.1-Sol and GPT-6-Astra sit around 60 tokens/s. The data, collected by a Reddit user on artificialanalysis.com and linked to leaks from Azure Foundry, prove nothing on their own. But they put a hidden question back at the center of LLM serving benchmarks: how many inference passes does it actually take to emit one token?

The technical speculation starts with a recurrent architecture, sometimes called a looped transformer. Instead of producing a token with a single forward pass, the model would traverse the same weights multiple times. According to the leaks, GPT-6-Sol would run with three inference passes per token, while GPT-6.1-Sol would need two. Some readers suggest the Astra name points to the three-pass model and that 6.1-Sol shares the same weights with one fewer iteration.

If those multiple passes are real, token/s becomes a misleading unit. A model can cut its apparent throughput in half not because it is less efficient, but because it does more work per token. Anyone planning a self-hosted deployment and comparing models only on token/s risks underestimating VRAM occupancy, GPU compute time and overall TCO. The gap between 100 and 60 token/s is not simply a performance drop: it can be a doubling of the required passes.

There is a second layer. QuackerEnte's post notes that Luna's numbers tell a different story: 5.6 Luna ranged between 126 and 137 tokens/s, while 6.0 Luna drops to around 110-115 tokens/s. From there comes the hypothesis of a nested model, similar to what NVIDIA has shown in the past: smaller models inside a unified footprint, with reduced active parameters or a single pass per token. If Astra, Sol and Luna really shared the same set of weights, a cloud provider could serve different user tiers without multiplying clusters. Sol, used by few and generating no direct revenue, would not need separate hardware: it would be enough to adjust passes and batching on the GPU fleet already running.

For the local and open-source ecosystem, the signal works in two directions. The hope expressed in the post is that DeepSeek, Qwen and GLM will start exploring multi-pass architectures, driven by the possibility of getting more use out of weights at the same memory footprint. But architectures are not enough: serving frameworks and benchmarking tools need to separate pass count from token emission speed. Today an aggregate figure like tokens/s does not allow models with different computational costs to be compared. In self-hosted settings, where the marginal cost is electricity and already purchased hardware, that transparency matters even more.

There are no official confirmations. The figures come from an independent platform and from screenshots without certain attribution. But that is exactly why the post is interesting: more than a leak, it is an indirect reverse-engineering exercise on serving costs. The author writes that he cannot prove anything and closes with a personal note: 0.7 tokens per second for a biological model of about 100T parameters, powered by two coffees and a muesli bar. The detail is deliberately ironic, but the point remains: when the unit of measurement is opaque, even community speculation becomes a way to bring real compute back into focus.