A developer opens a model card, scrolls to the parameter count, and finds two of them. One is the number the launch post will quote. The other is the number the GPUs actually have to survive. Both are true, and the distance between them is the release.
SenseTime (商汤) published SenseNova-Loop-9B-Preview on 30 October under Apache 2.0, with open weights (开源权重) on Hugging Face and code on GitHub. It takes text and images, returns text, and is built for long documents and tool-using workflows. What makes it worth an hour of your time is not its size. It is the accounting.
Key takeaways
- SenseNova-Loop-9B-Preview stores 32 decoder layers but executes 56 of them per forward pass, reusing one 24-layer block twice.
- Its card lists about 9B total parameters and about 14.6B "inference parameters" — memory versus compute, not a contradiction.
- It buys depth without buying weights, which matters when a model has to fit fixed GPUs.
- Quality claims compare it to 27B-class models, but the benchmarks are vendor-run and at least one is named after the company's own product.
- Apache 2.0, plus open pull requests against vLLM and SGLang, make it easy to test rather than argue about.
What the loop actually does
The backbone is a 32-layer multimodal decoder. Input passes through layers 0 to 3. Then the block spanning layers 4 to 27 — twenty-four layers — runs twice in sequence with shared weights. Layers 28 to 31 and the output head finish the job.
If you call the repeated block B and its input h, the repo writes the whole thing as B(B(h)). Two passes over the same weights, 56 layer computations, 32 sets of weights in memory.
The rest of the card explains how the two passes stay stable. Attention alternates three linear-attention layers with one full-attention layer, and the loop boundaries align to those groups so the pattern survives the second pass. Inside the loop, a mechanism the team calls mHC — manifold-constrained hyper-connections — carries two residual streams and uses learned mappings to decide what each layer reads, how streams mix, and how the output writes back. Sinkhorn normalisation, run for 20 iterations, constrains that mixing.
None of this is new mathematics; weight-tied recurrent depth goes back to the Universal Transformer. What is new is a downloadable checkpoint with serving support, rather than a paper with a Colab notebook.
Why the two numbers matter
"Total parameters" is a memory question. "Inference parameters" is a compute question. A dense 27B model needs roughly three times the weight memory of this one, but this one does about as much arithmetic per token as a much deeper network.
The trade only pays off when:
- When memory is the binding constraint. One node, fixed VRAM, a document that will not fit alongside a bigger model.
- When throughput is not. More FLOPs per token means tokens per second will not flatter it against a dense model of the same stored size.
- When the task rewards depth over breadth. Multi-step tool use leans on sequential computation, which is what extra layer passes buy. For short prompts at high volume, you are paying for depth you never use.
The benchmark claim, and what is missing
SenseTime's announcement says the model is comparable to 27B-parameter models on code generation, office work and agent tasks. The repository carries a benchmark chart and names results on AutomationBench and RaccoonPPT Bench — the second shares its name with the company's own office app, which the repo also credits for the demo assets.
Vendor benchmarks are how most models launch now, and testing on your own product's workload is a reasonable choice. But three things are absent:
- No third-party replication. The results were published on 30 October; nobody outside SenseTime has re-run them in public.
- No harness disclosure. Agent benchmarks are unusually sensitive to scaffolding — retry logic, tool schemas, step budgets. A score without the harness is hard to compare.
- No ablations beyond one. The team reports that mHC routing alone lifted scores on a multi-step agent benchmark, but the table lives in the release material, not in an independent evaluation.
The honest reading: the architecture is documented in unusual detail, and the quality claims are the least documented part.
The engineering details that decide adoption
First, serving support arrived early: open pull requests against vLLM and SGLang implement the looped execution, and the repo ships a LightLLM deployment example with a four-GPU tensor-parallel setup.
Second, the execution configuration travels with the checkpoint. Loop range, pass count and mHC routing parameters are part of the model's configuration, so an inference stack that ignores them will load the weights and produce wrong output. The repo says so plainly.
Third, the speed path is only half finished. Multi-token prediction is available. Two speculative-decoding draft models, Dspark and Dflash2, are listed as training in progress. On a compute-heavy architecture, speculative decoding is how you get latency back.
Honest limitations
This piece reads one model card and one repository closely. I have not run the model or reproduced a single benchmark, so every performance claim here is quoted rather than tested. The 14.6B "inference parameters" figure is the vendor's own convention, and labs define such numbers differently, which makes cross-vendor comparison unreliable.
The benchmarks are vendor-run, and the repository's chart is published as an image rather than a table with per-task settings. Nothing here establishes that looped depth generalises beyond this checkpoint; it is a preview, and the name says so.
Finally, this is a 9B-class model, not a frontier system; whether the memory-for-compute trade holds at larger scales is open.
What readers can do now
- If you have a memory-bound deployment, pull the checkpoint and measure tokens per second against a dense model of similar stored size. The trade only pays off on your workload, not on the card.
- Read the execution configuration before wiring up serving. A stack that ignores the loop settings will run and give you plausible, wrong answers.
- When a card lists two parameter counts, ask which one your hardware actually has to hold, and which one your bill actually pays for.