Read the scoring function
Each subnet defines its scoring logic in code, and that code is your optimization target. Most functions combine output quality with response latency, and many also gate on availability — an unreachable miner scores zero for the epoch regardless of quality. What matters is the weighting: a subnet at 80/20 quality-to-speed rewards a completely different strategy from one at 50/50.
If the scoring code uses a specific benchmark or evaluation model, run it locally. Being able to score a candidate change on your own machine before deploying it is the single biggest difference between miners who improve and miners who guess.
Model quality
On inference subnets the model you run is the highest-leverage choice. Moving from the template’s baseline to a stronger open-weight model, or to a fine-tune of the baseline on data matching the subnet’s evaluation distribution, can move you from median to top quartile in a single epoch. Fine-tuning against the subnet’s actual criteria is what the highest-earning miners on competitive subnets are doing; treat the scores you receive as a training signal.
Quantization is the recurring trade-off. FP16 gives better quality; INT8 and INT4 are faster and fit in less VRAM. Which wins is decided by the scoring weights, not by principle — measure both on your own hardware rather than assuming.
Latency
Response time is measured end to end: network round trip, queueing, inference, and post-processing. Most miners find more latency in infrastructure than in the model. Use a serving framework built for it — vLLM with continuous batching for LLM subnets, TensorRT-optimized models on NVIDIA hardware — keep GPU memory warm between requests to avoid cold starts, and put the server somewhere with low network latency to the validators that are actually querying you.
Iterate with discipline
Track trust score, rank and emission per epoch over time. A sudden drop is almost always one of three things: your miner went offline, the subnet changed its scoring parameters, or a strong new miner raised the bar. Telling them apart quickly is what lets you respond with the right fix instead of the first one.
Change one thing at a time and observe it over at least three epochs before judging it. Model, serving framework and configuration interact in ways that make simultaneous changes uninterpretable. The discipline is boring and it compounds.
Running more than one
Once one miner is stable and profitable, a second subnet diversifies your emission exposure. Each needs its own hotkey registration and its own process, but one machine can often carry two if the workloads do not compete: an LLM miner on the GPU alongside a lighter data miner on the CPU is the common pairing. Two LLM miners on one GPU is not.
Judge the second subnet on earnings per GPU-hour rather than on emissions. A miner producing three times the TAO for five times the resources is worse than it looks. At more than a handful of processes, operational overhead becomes the binding constraint: provision with infrastructure-as-code, keep processes under systemd or Docker Compose so they restart themselves, and alert on dropped scores rather than discovering them a week later.
The other lever is entry timing. Finding a subnet early — few miners, rising emission share — buys you rank before the competition arrives, and specialising where your own domain expertise or hardware is unusual beats out-spending generalists. Both come from watching new registrations and emission trends, which is subnet research, not tuning.