Subnet 24: Quasar
Quasar is Bittensor Subnet 24. The Quasar subnet README source describes it as SILX Labs’ competitive small-model subnet on Bittensor, with an objective centered on long-context language models. The Quasar-3B-A1B-Preview model card describes the base model line as designed for long-context reasoning, agentic systems, and persistent memory-based intelligence.
What Quasar Provides
Quasar organizes competition around model artifacts rather than a hosted inference endpoint. The subnet README says miners train Quasar-compatible language models, publish them as public Hugging Face repositories, and commit pinned model revisions on-chain. That makes the committed model revision the durable item validators can retrieve, verify, and compare.
The same README places Quasar within Bittensor’s miner and validator pattern, but its task is specific to model quality. Miners contribute candidate models. Validators check valid commitments, score the committed models, and set weights toward the current winning model under the subnet’s evaluation rule.
Model Context
The Quasar model card identifies Quasar-3B-A1B-Preview as a base pretraining model for distributed knowledge distillation on Bittensor Subnet 24. It describes the preview as part of a Quasar foundation-model line, not as a finished benchmark model. That distinction helps explain why the subnet centers on iterative model improvement instead of one-time task responses.
The model card also describes the preview model as a 3B-parameter mixture-of-experts design with about 1B active parameters. For Taopedia readers, the important point is not the exact architecture recipe; it is that the subnet’s public materials tie the competition to a shared Quasar-compatible model family and a long-context training objective.
Evaluation Context
Quasar’s README describes validator scoring as a comparison process for committed models. It says validators use paired KL duels together with a composite evaluator, and that replacing the current winner requires both a valid paired-KL win and a composite quality pass.
That framing keeps Quasar distinct from a simple leaderboard based on one score. The README describes evaluation coverage across distribution match, model capability, conversational quality, generation discipline, and robustness. In article terms, the subnet is trying to reward models that remain useful under long-context and robustness checks, not merely models that match one narrow answer set.
The README also says the strongest valid model becomes the current winner and validators set the winner’s weight. This gives the subnet a clear incentive loop: public model commitment, validator retrieval and scoring, and weight assignment toward the current best validated Quasar model.
Miner and Validator Roles
Subnet 24 operates under the standard Bittensor two-role structure, with a model-specific task. Miners contribute Quasar-compatible model revisions. Validators evaluate those public commitments and set weights according to the subnet’s winner-selection process. The Quasar-specific evidence comes from the model commitment and evaluation path described in the subnet README.
Source and Live Data
Live subnet data is available on TaoStats. The mechanism details in this article are tied to the Quasar subnet README and the Quasar model card rather than to live identity fields.
Relationship to Yuma Consensus
Subnet 24 uses Yuma Consensus to convert the model-quality weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Quasar’s context, validators retrieve public model commitments from on-chain, run paired KL duels and composite evaluations against them, and set weight toward the current winning Quasar model. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Quasar (SN24), that sequence changes how readers should interpret model evaluation examples and on-chain commitment outcomes.
In localnet, Quasar-compatible miners and validators can be developed and tested in an isolated environment. Localnet model evaluation scores and emission outcomes do not represent production subnet performance.
On testnet, Quasar-compatible model commitments can be exercised in a shared, non-production network. Testnet KL-duel results and validator scores are separate from mainnet subnet state.
On mainnet, Quasar (SN24) is the live production subnet where miners commit long-context model revisions on-chain and validators evaluate those commitments to determine real Bittensor emissions. The Quasar README describes the winner-selection mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A model evaluation result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 24 Quasar should not be read as generic Bittensor subnet documentation, a finished benchmark leaderboard, or proof that one narrow answer set defines the winner. It names one subnet’s long-context Quasar model competition on netuid 24 (Understanding Subnets, Glossary: Netuid).
On-Chain Commits Bind Model Revisions
The Quasar README describes miners publishing model commitments on chain for validators to retrieve and score (Quasar README).
The competition therefore tracks public model revisions rather than private offline checkpoints.
Paired KL Duels and Composite Checks Gate the Winner
The README states that displacing the current winner requires both a valid paired-KL win and a composite quality pass (Quasar README).
Winner selection depends on multiple evaluation layers instead of a single scalar score.
Validator Weights Still Flow Through Yuma Consensus
Subnet 24 uses Yuma Consensus to convert validator weight submissions into emission shares each tempo (Yuma Consensus, Emission).