Running a SolanaLM node: real numbers from week one
Field notes from running an inference node for a week. Hardware, hours, payouts, and the operational reality that nobody puts in marketing copy.
We get asked “what is it actually like to run a node?” more than any other question. The marketing answer is “earn passive income on your GPU.” The honest answer is more nuanced and includes the things that broke. Here is one week of running a single inference node on commodity hardware, with the actual numbers.
The hardware
I ran the node on a workstation I already owned:
- AMD Ryzen 9 5900X
- 64 GB DDR4
- RTX 3090 (24 GB VRAM)
- 1 TB NVMe
- Symmetric 1 Gbps fiber
Total hardware cost: about $2,400 in 2024 when I built it. Power draw under load: ~350W. Electricity here: $0.14/kWh.
The node ran Llama-3.1-8B-Instruct and Mistral-7B-Instruct simultaneously, with llama.cpp Q4 quantization. Both fit in VRAM with headroom for context.
The setup time
From git clone to first served request: 47 minutes. Breakdown:
- Poetry install: 12 minutes (mostly torch and CUDA wheels).
- Wallet generation and registry registration: 4 minutes.
- Model downloads (Llama-3.1-8B and Mistral-7B): 21 minutes on my connection.
- Config file editing (declaring models, setting payout wallet, picking a region tag): 5 minutes.
- First heartbeat to registry, first request served: 5 minutes.
The quick-start script (scripts/quick_start.py) does most of the work. The friction was almost entirely the model downloads and the CUDA wheel cycle.
Week one operational notes
Day 1: First production traffic
Requests started arriving about 90 minutes after the node went green in the registry. Reputation starts at zero, so the routing tier sent low-stakes traffic first — short prompts, quick completions, the kind of work that does not punish a new operator if it goes badly.
I served 412 requests in the first 24 hours. Average prompt length: 187 tokens. Average completion: 94 tokens. Per-request payout averaged 0.00027 SOL.
Day 2: First reliability hit
The llama.cpp Q4 build crashed once after about 6 hours of continuous use, on a request with a 4k token context. The node process died cleanly; systemd restarted it. The registry marked the node down for the 18 seconds it took to come back up. Reputation dropped slightly.
The crash was a known llama.cpp issue with long contexts on RTX 30xx series. Fixed by upgrading the underlying library. The fact that this happened, that the registry caught it, and that reputation reflected it is the system working as designed. It is not the system being polite about it.
Day 3: Federated learning round
A training round opened for a 350M-parameter language model fine-tune. I had the node configured to opt into training rounds with a min_payout_sol floor of 0.5. This round paid 1.2 SOL for participating clients, so the node joined.
Training round duration: 4 hours of GPU time. SCAFFOLD algorithm. Round completed successfully; payout landed about 8 seconds after the final aggregation. The 3090 was fully utilized for the 4-hour window; I could not serve high-throughput inference during the round, but the registry handled this — it routes traffic away from training nodes for the duration.
Day 4: Privacy circuit work
I noticed about 8% of inference requests were arriving via 3-hop circuits. The exit-node role pays a small premium (about 1.4x the standard rate) because the operator carries the traffic-analysis risk. Set up my node to advertise as a willing exit; payouts on those requests averaged 0.00038 SOL.
Day 5: First slashing event
Not me — but I watched a slashing event happen on a sibling node in the registry. An operator was serving outputs that failed the gateway’s quality validator (a small classifier that checks for obviously broken responses). After three failed checks in a 10-minute window, the gateway slashed 0.3 SOL of their stake and routed traffic away from them.
The slashing event was visible in the public registry dashboard. The reason was logged on-chain. This is exactly the accountability pattern decentralized networks promise but rarely deliver. Seeing it work on a sibling operator was reassuring.
Day 6: A bad request
A client sent a request that hit my node and triggered an OOM. The model loaded a much-larger-than-expected KV cache because the request had a 16k context I had not anticipated. The node OOM’d, the request failed, the gateway retried on a sibling node.
I had to update my node config to declare maximum context length per model. Should have been default behavior; we filed an issue to make it default. Lesson: declare your limits explicitly.
Day 7: First weekly tally
Final numbers for the week:
| Metric | Value |
|---|---|
| Inference requests served | 2,847 |
| Average payout per request | 0.00031 SOL |
| Total inference revenue | 0.882 SOL |
| Training rounds participated | 1 |
| Training revenue | 1.200 SOL |
| Privacy circuit (exit) revenue | 0.187 SOL |
| Gross revenue | 2.269 SOL |
| Protocol fee (2.5%) | 0.057 SOL |
| Net revenue | 2.212 SOL |
At ~$160 per SOL during the week, that is about $354 net revenue.
The honest costs
The number that matters is net revenue minus operating cost.
- Electricity: 350W average * 24 hours * 7 days * $0.14/kWh = $8.23
- Bandwidth: $0 (already paid)
- Hardware amortization: $2,400 / 36 months = $66.67/month, or ~$15.55/week
- My time: maybe 3 hours of monitoring and config work this week
Net of cash costs (electricity, amortization): $354 - $8.23 - $15.55 = $330.22.
That is real money for a workstation I already owned. It is not a livable income; it is meaningful supplemental revenue. Whether it scales is a function of network demand. Right now demand is high relative to supply because the network is new.
What I would tell someone considering it
Do it if you already have the hardware. The marginal cost of running a node on idle GPU capacity is electricity. Even at terrible payouts, that is positive ROI.
Do not buy hardware specifically for this. Decentralized inference markets are competitive. The day a major operator brings 1000 H100s online, your 3090 economics will get worse. Build a node on hardware you would own anyway.
Set up monitoring before you need it. Prometheus dashboards on the node, alerts on the gateway. The first time something breaks at 3am, you want to know before the registry de-prioritizes you.
Read the slashing rules. Know what behavior gets you slashed. Most slashing is for things that should not happen if your node is healthy, but knowing the rules lets you defend yourself when there is a dispute.
Talk to other operators. The Discord operator channel surfaces issues weeks before they get documented. People who run nodes know more about running nodes than the documentation does.
I will probably run the node for another month and write a follow-up. The current question I am trying to answer is whether the federated learning revenue scales linearly with hardware (it should, but training-round availability is not constant). The week-one numbers say: yes, this works, and the protocol behaves as documented. That is the main thing.