What a GPU actually earns on Sogni

The rate a running node earns

These are the headline answers: what one node of each class earned per hour it was connected and taking work, extended to a full month of continuous uptime. Uptime across the measured fleet varied from 27% to 76% by class, so this rate — not the observed monthly total — is the number that transfers to a differently-run node.

The RTX PRO 6000 band sits entirely above every other class: its worst node out-earned the best 5090 by 25%. The 4090 band is the widest, spanning 2.6× from bottom to top — and since those 48 nodes ran essentially the same model mix, that spread is not about hardware at all. We come back to why.

The full rate table, on two pool bases

One complication has to be said out loud. Pay-as-you-go work is priced per job, so it is simply what it is. The Unlimited subscription pool is not: it is a fixed monthly pot, funded by that month's subscriptions, divided across all subscription render spark on the network. During an open month that pot is still filling, so there are two honest ways to state a rate, and we give both.

• Funded basis — the pool as already paid for at the time of measurement, $37,257. That figure already covers the whole calendar month for the subscriptions collected so far.
• Forecast basis — the pool's own end-of-month projection, $63,568, which assumes sign-ups keep arriving at the pace observed in week one and the measured fleet holds its share of network work. It is a projection, not money in hand.

Read those two tables together and the most useful lesson on the page falls out. The RTX PRO 6000 is the best-earning silicon on the network by a wide margin, and it was busy 84% of every hour it was online — the highest of any class. It still finished the month in a dead heat with the 5090, because it was only online 40% of the time. The 5080s tell the same story more harshly: online 27%, and a $176/month rate became a $50/month result.

Nothing about that is a demand problem. It is a provisioning problem, and it is the one variable an operator controls completely.

Where the money comes from

Nine of every ten jobs the fleet completed were Unlimited subscription renders — 594,688 of 649,403 — and the subscription pool was the larger revenue line for every GPU class. Pay-as-you-go still matters, and it behaves very differently: it is paid per job at a fixed price rather than out of a shared pot, so it scales with volume instead of being diluted by it. At current volumes it is roughly a fifth of the total.

What actually drives the number

GPU class is a proxy. What really sets a node's earnings is the model tier it is eligible for, because heavier models carry far more render spark per job — and heavier models need VRAM only the newer cards have.

Look at the spark-per-job column and the whole ladder explains itself. The 5080s and 4090s carried Krea 2 image work at 5.7–8.0 spark per job and 76–89 jobs an hour. The 5090s and PRO 6000s ran video — the same MiniMax H3 family — at roughly ten times the spark per job. A card doing fourteen video jobs an hour out-earns a card doing eighty-eight stills, comfortably.

Even the gap between the two video classes is a routing difference rather than a silicon one. The PRO 6000 drew the heaviest H3 variants, reference-to-video at 237 spark a job; the 5090 drew more of the turbo and int8 variants at 50–183. That accounts for most of the 1.9× between them.

The VRAM ladder, and where the doors are

Since eligibility is what pays, here is the current one, read from the live worker config on 7 September 2026. Two rungs matter more than the rest.

The fleet's single RTX 3090 is a clean demonstration of that 23 GB rung. Across the week it served exactly three MiniMax H3 workflows — the FastVideo int8 turbo image-to-video, text-to-video and first/last-frame variants — plus MiniMax Music 3 and RTX VSR, and none of the twelve 32 GB H3 workflows. That is the ladder above, reproduced by one card with 24 GB.

Resolution adds its own gating on top of the video workflows — larger outputs need more headroom than the pack minimum — so treat the ladder as eligibility to be offered the work, not a guarantee of every job in the tier. The catalogue also moves; check the live config rather than trusting this table in six months.

Inside a class, it is simply how busy you were

The 48 RTX 4090s are the cleanest experiment on the network, because their model mix was effectively uniform — every node ran the Krea 2 identity-edit family in much the same proportions. And yet the per-connected-hour rate still spanned 2.6×, from $0.19 to $0.51.

We checked what that tracked. Against busy share — the fraction of connected time actually spent rendering — the correlation was r = 0.716. Against spark per job, only r = 0.589. The three lowest-earning nodes were busy 45–57% of their connected time; the three highest, 70–76%. Same card, same catalogue, same week: the difference was how much work the scheduler sent them.

So it is worth knowing exactly what the scheduler rewards. When jobs are waiting, idle workers are sorted and offered work in this order:

1. Speed vs baseline, highest first. Every completed job updates a rolling measurement of how fast you rendered compared with the expected time for that model on reference hardware. This single number is the primary sort key. Your hardware model is not used directly — what you actually deliver is.
2. Longest idle first among workers of equal speed, then longest connected as the final tiebreaker.

On top of that ordering, jobs go first to workers that already have the model hot-loaded in VRAM, and only then does the matcher ask others to switch models. Which gives a short, honest list of things that move your number, in rough order of impact:

• Stay online. It dwarfs everything else on this list. The two lowest-earning classes in our measurement were not short of demand; they were short of uptime.
• Use the CUDA 13 image if your card and driver qualify. It is meaningfully faster on Ada and Blackwell, and speed is the scheduler's primary sort key, so the gain compounds into more jobs.
• Keep the GPU free. Casual desktop use is fine; gaming or anything else that touches the GPU drags your measured speed down, and the scheduler deprioritises you for it. Stop the worker for heavy sessions.
• Hot-load the workflow that is busiest for your tier with DEFAULT_WORKFLOW_ID, so you are ready before the first job arrives rather than paying model-switch time you are not rendering during.
• Feed it. System RAM, a fast NVMe model cache and real upload bandwidth all show up in wall-clock time, and wall-clock time is what gets measured.
• Tune cooldowns to your cooling. Thermal throttling is a speed penalty the scheduler cannot tell apart from a slow card.
• More VRAM, more spark. If you are choosing hardware, 23 GB and 32 GB are the two lines that matter, for the reasons in the ladder above.

How to read these numbers

1. This is month three of a brand-new model. The Unlimited fair-use subscription plan and the worker revenue share that pays out of it are new, and September 2026 is only their third month. Subscriptions have grown steeply across all three, with subscription revenue rising sharply month over month. A pool growing that fast makes any single month a poor guide to the next one — in either direction. Treat these rates as a reading taken early, not as a settled rate for the network.
2. The Unlimited pool is a fixed pot, so per-node rates are not additive. Subscription revenue for the month is divided across all subscription render spark on the network. If every worker went to 24×7, total spark would rise while the pot stayed the same, and the per-spark rate would fall. The 24×7 columns answer “what does this node earn running full-time while the rest of the market holds steady” — they are not a projection for the network as a whole. Pay-as-you-go does scale, because it is priced per job.
3. Seven days, not a month. Every rate comes from 1–7 September 2026 UTC, from complete daily rollups, extrapolated at the observed rate. September had not finished when we measured. A short window is also more easily distorted by one bad week than a long one.
4. The pool was open, and it keeps moving until the month closes. At capture the month's status was open and the revenue basis estimated, with nothing claimed. Two things move it. Revenue keeps arriving, which grows the pot. And the pot is divided by subscription work measured in units of GPU time, so your share also depends on how much work every other worker on the network does for the rest of the month — a node that does exactly the same work in week four as in week one can still land on a different number. Nothing here is a settled amount owed.
5. The forecast assumes the fleet holds its share. It was made on day 8 of the month, by the pool's own recent-coverage-starts-weighted method, and it models the pool growing — it does not model new workers joining and diluting each existing worker's share. More capacity arriving is good for the network and reduces the per-node forecast at the same time. It is a projection made early in a fast-moving month, and it is not a commitment.
6. Earnings settle about 45 days after the month closes. The pool is funded by subscription payments taken across several payment providers, and each provider has its own settlement period. Those have to complete and be aggregated before a month's payout is final, which puts roughly 45 days between the end of a UTC month and money you can claim. The figures on this page are accrual, not cash in hand.
7. These are net figures. Everything above applies the 51% worker share. If you are comparing against a dashboard’s gross SOGNI row, that number is render value before the split — roughly double what a worker receives.
8. Uptime here is a hosting variable, not a demand signal. The 5080 cohort at 27% and the PRO 6000s at 40% reflect when those deployments happened to be running. The PRO 6000s were 84% busy whenever they were online — the busiest silicon in the fleet.
9. One fleet, one week, one hosting setup. These are 137 real nodes, not a model, which is the strength and the limit of the exercise. A differently-run node on the same card will land somewhere else in the range, and the ranges we publish are wide for exactly that reason. The RTX 3090 row is a single node and has no range at all — treat it as one observation, not a class.
10. No number here is a promise. Earnings depend on demand, your hardware, your speed score, which workflows you are eligible for, your uptime and the SOGNI price. Electricity, cooling and hardware are yours. Treat all of this as a dated measurement, not a rate card.

How we measured it

Per-node daily rollups for each of the seven UTC days, combined with the month's subscription pool ledger and its per-node breakdown, all read from the same public analytics endpoints that power the worker dashboard — any operator can reproduce this for their own wallet. Pay-as-you-go dollars follow the dashboard's own decomposition, computed per day and then summed, then multiplied by the 51% worker share. Unlimited dollars are each node's own row in the pool ledger.

Scope is ComfyUI workers only: 137 nodes. A handful of Stable Diffusion and LLM workers ran on the same account and are excluded, because they are a different product line and would blur the comparison. Per-node rows reconcile exactly against the ledger's account payout, and daily spark totals land within 0.25% of the pool's own counter.

• Worker revenue share — the full pool rules
• About the Sogni Fast Worker
• Live Comfy worker config — the current workflow catalogue and VRAM minimums
• Subscription Earnings — participation, estimates and claims
• Fast Worker FAQ