HomeBecome a HostRequirements

Requirements: does your machine make the list?

The list is short and measurable. Card and VRAM, the CPU/RAM/disk ratio per card, network, power and uptime. Its most important item is a "not needed": you do not have to open an inbound port.

The thresholds are a design decision and take effect in Phase 1 together with the registration flow; there is no system verifying them today.

Host section

Hardware

Card list and the VRAM floor.

NVIDIA, x86_64 and driver 535+. The floor is 8 GB of VRAM; but clearing the floor does not mean "work will come" — only small inference and image jobs land on cards in the 8–12 GB band. The main demand is at 24 GB and above.

GPUVRAMClassTypical jobExample list price
RTX 306012 GBAccepted — narrow poolSmall image jobs, light inference$0.09/hr
RTX 4080 / 4080 SUPER16 GBAcceptedImage generation, LoRA$0.30/hr
RTX 3090 / 3090 Ti24 GBMain poolStable Diffusion, small LLMs$0.21/hr
RTX 409024 GBMain pool — most requestedFine-tuning, image generation$0.42/hr
L40S48 GBMain poolInference, video$0.79/hr
RTX A6000 / A6000 Ada48 GBMain poolLong context, render$0.88/hr
A100 PCIe / SXM80 GBEnterpriseTraining, 70B inference$1.32/hr
H100 PCIe / SXM80 GBEnterpriseSerious training runs$2.19/hr

The prices are examples and illustrative: you set your real list price, and it moves with supply and demand in the marketplace. If you have an NVIDIA card that is not on the list, hardware verification decides during registration; cards below 8 GB are not accepted.

Floor 8 GB, practical limit 12 GB: 8 GB cards make the list but the number of jobs they receive is low. If you expect earnings, the conversation starts at 24 GB and above.
No mixed cards: the cards in one machine must be the same model. Different models in the same machine break both placement and benchmark consistency.
PCIe lanes matter on multi-card machines: the x1 risers common in mining rigs are not a problem for single-card jobs, but they rule the machine out for multi-card training.
Keep overclocking off: unstable memory clocks produce benchmark variance, and variance lowers the second-heaviest component of your scorecard.

Ratio

CPU, RAM and disk per card.

A card does no work on its own: the data loader wants CPU, the container image and the model cache want disk. If these ratios don't hold, you lose money while the card waits — and a slow machine also falls behind on benchmark consistency.

ItemFloorRecommendedWhy
CPU (per card)4 physical cores6–8 physical coresData loading and preprocessing; too little CPU starves the card
System RAM (per card)VRAM × 1.5VRAM × 2Dataset cache and container working space
Disk (per card, dedicated)150 GB NVMe250 GB+ NVMeImage and model cache; NVMe directly cuts cold start time
System disk60 GB free120 GB freeSeparate space for the operating system, the agent and logs

Example: on a machine with 4× RTX 4090 (24 GB), the floor means 16 physical cores, 144 GB of RAM and 600 GB of dedicated NVMe. These values are measured during registration and shown in the panel; below them the machine still makes the list but falls into a narrower job pool.

Network

Download speed starts the job, upload speed delivers it.

The customer's first experience starts with downloading the model and the dataset; the end of the job is the checkpoint, the output file and the artifact upload. Both go through your line, which is why the network is a quarter-weight component of your scorecard.

Download: at least 100 Mbit/s

The weights of a 70B model run to tens of gigabytes. A slow download is dead time in which the customer waits for the pod — and because those seconds are not billed, the loss is directly yours.

Upload: at least 20 Mbit/s

On asymmetric home lines this is the bottleneck. Training checkpoints, generated images and the log stream all go upward. If upload is slow the job is "finished" but not delivered; the customer sees that as latency.

CGNAT is not a problem

The agent always establishes the connection outbound. No static IP, port forwarding, DDNS or firewall hole is needed. If your operator has put you behind CGNAT, nothing changes.

A metered line is risky

If you have a monthly data cap, do the math before becoming a host: a busy month can mean terabytes of traffic. Overage is on your bill, and if your line is throttled your scorecard drops. Where the line is not unlimited, start with a measured price.

Bandwidth is measured during registration and re-measured regularly; the median value is shown in the panel. A wired connection is expected — hosting over Wi-Fi is technically possible, but measurement variance keeps your network component low.

Power and uptime

An outage lowers the heaviest item on the scorecard.

Stable power

If you are somewhere with frequent outages, hosting is hard: every unplanned shutdown is written to the uptime metric, and that metric is 35% of the scorecard. A UPS is not mandatory, but by absorbing regular short outages it protects your score.

Power capacity

Make sure your circuit and power supply can carry the total draw of the cards. A machine with 4× RTX 4090 pulls roughly 2 kW under load; in a home installation that is a serious item. Electricity cost math: Earnings page.

Uptime expectation

The target is 95% or above over a 30-day window. Machines that fall below 90% place noticeably worse and are taken out of long jobs. This is not a punishment: on a machine that goes down, a long job means starting over.

Cooling and noise

Under load the cards stay at 100% for hours. Thermal throttling produces benchmark variance and lowers the consistency component. In a home, noise is a cost too; listen to the machine at full load for a day before deciding.

While you use the machine yourself

The card is yours. There are three ways to take it back.

Being a host is not handing the machine over. When your own work comes up you take the machine back; the difference is how you do it. The only thing that separates the three ways is their effect on your scorecard.

Maintenance mode — the clean way

You run kaldera-agent drain: the machine stops accepting new jobs, frees up when the pod on it finishes and drops off the list. Because you interrupt no running job, nothing is written to your scorecard. The time you wait is the remaining time of the job on it.

A no-jobs window — the planned way

You define a weekly schedule: for example, on weekdays the machine takes no jobs between 19:00 and 24:00. The scheduler knows this and never places a job that would run into that window. A planned window does not lower the uptime metric — because it is declared capacity, not an outage.

Emergency reclaim — the costly way

If you pull the machine out from under a running job, the job moves from its checkpoint to another host and the customer is not billed for those seconds. The system works, but it isn't free: an emergency cut is written to the uptime and job-acceptance metrics. Once a month makes no difference; as a habit it lowers your scorecard.

There is no commitment period, exit penalty or lock-in. If you want to remove your machine entirely, you uninstall the agent; what you have accrued is paid in the next payout period. Details: FAQ.

Next step

If the hardware holds, the numbers are next.

If the card list and the ratios fit your machine, move on to the earnings calculation: a net figure from three configurations, three utilization scenarios and an electricity cost input. Then look at the scorecard page to see how the score drives placement.

The thresholds take effect in Phase 1. ; prices and values are illustrative.