OnFinality

Posted on Sep 22 Originally published at onfinality.io

Bittensor Mining Rig: Hardware That Actually Matters

#web3 #blockchain #devops #tutorial

Most people searching for a "Bittensor mining rig" are picturing an ASIC or a multi-GPU Ethereum-style miner. That mental model breaks immediately on Bittensor. There is no hash puzzle to solve and no block reward for raw compute. A miner on Bittensor runs a software process that produces a useful output — an inference response, a trained model update, a prediction — and gets scored against other miners in the same subnet. Your rig is a server for that process, and the hardware that matters is whatever your target subnet's scoring function rewards.

That reframing is the whole article. If you buy hardware before you pick a subnet, you are guessing. If you pick a subnet first, the rig spec mostly falls out of it.

Start here: match the rig to the subnet, not the other way around

Before you compare CPUs or GPUs, answer three questions. They determine almost everything else.

Which subnet are you mining? Subnets define their own task. Some are text-generation or embedding services, some are forecasting or data pipelines, some are training-oriented. Each has a different bottleneck.
Is the task inference-bound or training-bound? Inference miners usually care about GPU memory bandwidth and VRAM capacity. Training miners care about sustained FLOPS, interconnect, and how long a round takes.
How is your score computed? If the subnet rewards low latency, your network and host CPU matter as much as the GPU. If it rewards model quality, VRAM and precision support dominate.

A practical way to decide: run the miner in a low-cost configuration first, watch where it stalls, then spend on the component that is actually limiting your score. Buying a top-tier GPU for a subnet that is CPU- or bandwidth-bound wastes money, and buying a cheap GPU for a VRAM-hungry model means you never finish a round.

Subnet workload shape	Primary bottleneck	Component to prioritize	Where teams overspend
Small-model inference	Latency and request throughput	CPU single-core speed, network path	Oversized GPUs
Large-model inference	VRAM capacity and memory bandwidth	GPU VRAM, PCIe bandwidth	Extra CPU cores
Training / fine-tuning	Sustained FLOPS and round time	GPU compute, cooling, power headroom	Fast local storage
Data / forecasting pipelines	I/O and preprocessing	RAM, NVMe, CPU cores	Multiple GPUs
Multi-subnet operation	Isolation and scheduling	Containerization, per-process limits	One giant machine

The parts of a Bittensor miner, and what each one does

A miner host is not exotic. It is a Linux server with a GPU, a wallet, and a chain connection. Break it into layers:

Chain client / RPC connection. Your miner reads subnet state, registers, and submits weights or commitments through the chain. This is where a managed RPC endpoint removes a lot of operational drag.
Wallet and hotkey. Your miner identity. Registration cost and key security live here, not in the GPU.
Miner process. The subnet-specific code that does the real work. This is the part that consumes GPU and CPU.
Host OS and container runtime. Most subnets ship Docker or a Python environment. Reproducibility matters more than raw speed.
Storage. Model weights, datasets, and logs. Weights can be tens of gigabytes per model.
Network. Both the chain RPC path and the subnet's own peer or API traffic.

If you are still deciding whether to run the chain client yourself at all, the tradeoffs are covered in What Is a Bittensor Node and How Do You Choose the Right Setup?. For most miners, the chain client is overhead, not the product.

CPU, GPU, VRAM, and storage: sizing guidance per layer

There is no single official rig spec, so treat the following as sizing logic rather than a shopping list.

CPU. You need enough cores to feed the GPU and run the miner's Python or Rust process without starving it. Single-core performance matters for subnets that score latency. A modern 8-16 core desktop or server CPU is a reasonable starting band for single-GPU miners; scale cores with GPU count.

GPU. This is the main variable. VRAM capacity decides which models you can load at all. Memory bandwidth decides how fast you can serve them. Compute throughput decides how quickly training rounds finish. Pick the GPU after you know the model size your subnet expects.

System RAM. Underestimated. Model loading, dataset preprocessing, and container overhead all consume host RAM. If you run multiple miners on one host, budget RAM per process, not per machine.

Storage. NVMe for model weights and any dataset that is read repeatedly. Model files are large and slow to load from spinning disks or network storage. Keep logs on a separate volume so a full disk does not kill a running miner.

Power and cooling. A single high-end GPU can pull several hundred watts under sustained load. Sustained inference is a different thermal profile from bursty gaming. Plan for continuous draw, not peak.

Network. Two distinct paths: the chain RPC connection and the subnet's own traffic. The chain path is low-bandwidth but should be reliable. The subnet path can be heavy if you serve requests or exchange model updates.

Where the chain connection fits — and why it should not run on your rig

Your miner needs chain access to register, read subnet state, and submit results. You can run a full Bittensor node locally, but that adds disk, sync time, and upgrade maintenance to a machine whose job is compute. A managed RPC endpoint keeps the chain path off your rig entirely.

OnFinality provides RPC API and dedicated node infrastructure for Bittensor, so a miner can point at a hosted endpoint instead of syncing Finney locally. The public endpoint for Bittensor Finney is:

curl -s https://bittensor-finney.api.onfinality.io/public \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"chain_getHeader","params":[]}'

A WebSocket endpoint is also available for subscriptions:

// Minimal connectivity check against the Bittensor Finney WebSocket endpoint
const ws = new WebSocket('wss://bittensor-finney.api.onfinality.io/public-ws');

ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'chain_getBlockHash',
    params: [0]
  }));
};

ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  console.log('genesis hash:', msg.result);
  ws.close();
};

For production miners that submit frequently or run several subnets, a dedicated node gives you a private connection with predictable capacity. See Dedicated nodes and RPC pricing for how that is structured, and supported RPC networks for the full list.

A minimal miner host checklist before you register

Registration costs TAO and is not refundable if your miner cannot compete. Validate the host first.

[ ] GPU driver and CUDA (or ROCm) versions match what the subnet's miner expects.
[ ] The model or dataset the subnet requires fits in VRAM with headroom for batch size.
[ ] Container runtime installed and the subnet's image pulls cleanly.
[ ] Wallet and hotkey created, backed up, and funded for registration.
[ ] Chain RPC endpoint reachable and responding to a basic call.
[ ] Storage has room for weights plus log growth over a full round.
[ ] Power and cooling can sustain continuous load, not just a benchmark burst.
[ ] A rollback plan: snapshot the working config before you change anything.

Failure modes that look like hardware problems but are not

Many "my rig is too slow" reports are actually configuration or connectivity issues.

Symptom	Likely cause	First thing to check
Miner starts, then drops off the subnet	RPC connection unstable or rate-limited	Chain endpoint health and request volume
GPU idle while miner runs	Process not using the GPU, or wrong device index	`nvidia-smi` during a round
Round never completes	Model too large for VRAM, swapping to host RAM	VRAM usage and batch size
Score drops after a subnet update	Miner version behind the subnet's expected interface	Subnet repo release notes
Random restarts under load	Power supply or thermal limit	Sustained power draw and temperatures
Registration succeeds but no rewards	Scoring mismatch, not hardware	Subnet scoring rules and your output format

If the chain path is the problem, moving from a local node to a managed endpoint is often the fastest fix. If the GPU is genuinely the limit, that is a hardware decision, not a config one.

Cost model: what you are actually paying for

A Bittensor rig has three cost layers, and they scale differently.

Hardware (capex). GPU, CPU, RAM, storage, power supply. This is the largest upfront number and the one people over-index on.
Power and cooling (opex). Continuous draw, not peak. This is where a marginal GPU choice can quietly become expensive.
Chain access and registration (opex). RPC capacity plus TAO registration cost per subnet. Registration is per-subnet and per-hotkey, so running many subnets multiplies it.

A useful exercise: estimate reward per round, multiply by expected rounds, and compare against power plus chain access. If the margin depends on running the chain client on the same box to save a few dollars, the rig is probably undersized for the subnet.

Operating the rig after day one

Getting registered is the easy part. Keeping a miner competitive is an operations job.

Pin versions. Subnet code changes. Pin the miner image and upgrade deliberately, not automatically.
Monitor the GPU, not just the process. A running process can be doing nothing useful. Track utilization, VRAM, and temperature.
Watch the chain path separately. RPC latency and error rates are a different signal from GPU health. Alert on both.
Keep logs bounded. Long-running miners generate a lot of output. Rotate logs before they fill the disk.
Separate identities. One hotkey per subnet keeps failures isolated and makes scoring easier to reason about.

If you run several subnets, container isolation per miner is worth the setup cost. It prevents one subnet's dependency conflict from taking down the rest of the host.

Key Takeaways

A Bittensor mining rig is a server for a subnet's miner process, not a hashing machine. There is no universal spec.
Pick the subnet first; the CPU, GPU, VRAM, and storage requirements follow from its scoring function.
VRAM capacity decides which models you can run; memory bandwidth and compute decide how well you compete.
The chain connection is overhead on a miner host. A managed RPC endpoint or dedicated node keeps it off your rig.
Validate the host against a checklist before paying registration costs.
Most "slow rig" problems are configuration, version drift, or RPC instability rather than raw hardware limits.

FAQ

Do I need a GPU to mine on Bittensor?
It depends on the subnet. Inference and training subnets generally require a GPU, while some data or forecasting subnets are more CPU- and I/O-bound. Check the specific subnet's miner requirements before buying hardware.

How much VRAM do I need?
There is no single number. Size VRAM to the largest model your target subnet expects, plus headroom for batch size and framework overhead. Start with the subnet's reference miner and measure actual usage.

Can I run a miner on a cloud GPU instance instead of buying a rig?
Yes, and it is a reasonable way to test a subnet before committing to hardware. The tradeoff is hourly cost versus ownership, plus whether the instance type gives you the VRAM and sustained performance the subnet needs.

Should I run a full Bittensor node on the same machine as my miner?
You can, but it competes for disk, memory, and CPU with the miner process. Most miners are better served by a managed RPC endpoint and keeping the host focused on compute.

Why does my miner lose score even though the hardware is fine?
Usually version drift, output format mismatches, or an unstable chain connection. Confirm you are running the subnet's current miner version and that your RPC endpoint is responding reliably before replacing hardware.

Does OnFinality support Bittensor?
Yes. OnFinality offers RPC API and dedicated node infrastructure for Bittensor Finney, with HTTP and WebSocket transports. See the Bittensor network page for endpoint details.

Related resources

Originally published at OnFinality.

DEV Community