Subnet 14: Cacheon
Cacheon is Bittensor Subnet 14 (SN14), operated by latent-to. The subnet runs a live inference optimization competition: miners submit customized LLM inference servers that are benchmarked against a pinned baseline, and the fastest correct implementation earns the majority of subnet emissions. The competition currently focuses on serving large open-source models at scale, with scoring designed to reward meaningful speed improvements over commodity inference setups.
How the Mechanism Works
According to the Cacheon repository, Cacheon uses a challenger model with a seated winner. The current leading inference server holds the winner position and earns the top share of emissions. A new submission must exceed the winner’s performance score by a fixed margin to take the seat, preventing minor fluctuations from causing constant turnover.
Each submission is evaluated in two passes. The first measures raw speed — specifically time-to-first-token and overall throughput — against the same pinned baseline on identical hardware. The second pass verifies correctness by checking that the server’s outputs match expected values. Submissions that fail correctness verification score zero regardless of speed. Only servers that pass the correctness gate compete on performance.
The winner earns approximately 80% of the competition pool; the runner-up earns the remaining 20%. The total pool size scales with how much the winner improves over the baseline — larger improvements produce larger rewards, aligning incentives with substantial optimization progress. Weight vectors from validator scoring feed into Yuma Consensus, distributing emissions via Dynamic TAO.
Participating as a Miner
Miners on Cacheon build and submit optimized inference servers for the target open-source model. The Cacheon repository describes their economic role as finding inference optimizations — whether through memory management, batching strategies, or algorithmic improvements — that make their server measurably faster than the current winner while maintaining correct output. A miner whose submission passes correctness checks and beats the winner’s speed by the required margin takes the winning seat and begins earning the top emissions share.
The competition is open to any inference approach, and miners compete on the technical merit of their implementation. A submission that cannot dethrone the current winner still earns the runner-up share if it ranks second.
Participating as a Validator
Validators on Cacheon run the evaluation harness that scores each new challenger submission. The Cacheon repository describes validators pulling each submission, running it under controlled conditions on standard hardware, and executing both the speed measurement and the correctness verification pass. Results are compared against the pinned baseline, and validators submit weight vectors reflecting each submission’s relative performance to Yuma Consensus.
Because evaluations are triggered by new submissions rather than running continuously, validators operate infrastructure that can scale to run evaluations on demand when challengers arrive.
On-Chain Identity
Cacheon is registered at netuid 14 on Bittensor with 256 neurons, verifiable via
taostats.io/subnets/14. The subnet owner coldkey is
5CKhH8nKAhXLmqxwaXzFtVFgxqwwnyckXG8qLpmGtzVJH9Ri. The codebase is maintained at
latent-to/cacheon and the project site is
cacheon.ai.
Relationship to Yuma Consensus
Subnet 14 uses Yuma Consensus to convert the performance-based weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Cacheon’s context, validators run the evaluation harness against each submission, measuring time-to-first-token and overall throughput against the pinned baseline, and verifying output correctness before scoring. Submissions that fail correctness verification score zero; submissions that pass compete on measured speed improvement over the baseline. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
Bittensor’s subnet-development path moves from localnet to testnet and then mainnet (Introduction to Bittensor). For Cacheon (SN14), that sequence changes how readers should interpret examples of challenger submissions, baseline comparisons, correctness checks, and winner-seat outcomes.
In localnet, miners and validators can develop and test Cacheon-compatible inference evaluation in an isolated environment. Localnet examples can explain the challenger flow and scoring harness, but they do not represent production inference performance or emission outcomes.
On testnet, Cacheon-compatible implementations can be exercised in a shared, non-production network. Testnet examples can show realistic coordination between submission evaluation, speed measurement, and correctness checks, but they remain separate from mainnet competition results.
On mainnet, Cacheon (SN14) is the production subnet where optimized inference servers compete against a pinned baseline and the current winner (Cacheon repository). That makes the production context important for interpreting whether a speed score, correctness result, or winner-seat change reflects the subnet’s active inference-optimization competition.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A challenger example, validator score, or winner outcome from one environment should not be read as representing production subnet performance in another environment.
That distinction matters for Cacheon because scoring depends on the target model, pinned baseline, hardware conditions, and correctness harness used for the submission. A local or test example can explain the evaluation model, while a production example depends on the actual benchmark and validator-scoring context that produced it.
Miner and Validator Roles
Subnet 14 operates under the standard Bittensor two-role structure. Miners supply the subnet’s capability and validators evaluate those contributions and set weights. Reward distribution follows Yuma Consensus.
Reader Boundary
Subnet 14 Cacheon should not be read as generic Bittensor subnet documentation, a universal inference hosting service, or proof that one speed score applies to every model size. It names one subnet’s seated inference-optimization competition on netuid 14 (Understanding Subnets, Glossary: Netuid).
Winner Seat Concentrates the Competition Pool
The Cacheon repository describes a seated winner model in which the leading server earns roughly eighty percent of the competition pool until displaced (Cacheon repository).
The runner-up share compensates second-place performance rather than replacing the seated winner role.
Correctness Verification Precedes Speed Ranking
Each challenger submission must pass an output-correctness check before speed metrics count toward the score (Cacheon repository).
A fast but incorrect server therefore scores zero rather than trading accuracy for throughput.
Validator Weights Still Flow Through Yuma Consensus
Subnet 14 uses Yuma Consensus to convert validator weight submissions into emission shares each tempo (Yuma Consensus, Emission).