What internet you need to rent out a GPU: bandwidth, symmetry, DPI

For a host in Russia the network is the second bottleneck after power. A slow, asymmetric or unstable link means low utilization, a failed bandwidth test and lost rentals: in the catalogue a client sees a speed number, not your good intentions. Power and the site are covered separately (how much power a server draws?lang=en); this piece is only about the network. Everything below comes from six machines: TVT (4×RTX 4090), tv5080v (2×RTX 5080), tv50 (RTX 5090), tv80, test and a client-owned machine. Every one has lost rentals to the network, and almost never for the reason common sense suggested.

How many Mbit/s vast.ai actually requires

• The requirement scales with video memory: ≈2.6 Mbit/s per 1 GiB of TOTAL machine VRAM (all cards combined), but never below 100 Mbit/s, with no upper limit — separately for download and upload
• Symmetry matters: clients push datasets and weights in and pull checkpoints out, so upload is as critical as download
• Low packet loss. High loss is not "a bit slower" — it is the client's session dropping mid-training and a support ticket
• Latency is not critical for batch ML: 40 ms and 8 ms to the client give the same result on a long training run
• The measurement is taken by your own host, not by the marketplace: send_mach_info.py runs Ookla and reports the result. So anything that spoils it on your side — an image pull, a live client, a neighbour on the uplink — lands straight in the listing

The table shows an uncomfortable thing: the formal requirement almost never matches the real problem. Five machines out of six pass on a home 100 Mbit line — and all five will sit idle if the catalogue has the same cards on a symmetric gigabit. The 100 Mbit floor buys a place in the listing, not a rental.

What really decides it: the catalogue filter and a moving average

A client picks a card with a filter, not by eye: offer search has inet_down and inet_up fields, and someone who has to upload a 300 GB dataset sets their own threshold. Anything below it they never see — your machine did not lose a comparison, it was never in the results. The second effect is subtler: the listing shows not your last measurement but a smoothed one — a moving average of the form "0.9 × old + 0.1 × new" — and the cron speedtest fires by lottery, roughly one hour in nine.

The main problems in Russia

• Tariff asymmetry: often 1000 down / 100–300 up. Such an upload usually passes the formal requirement (the floor is 100 Mbit), but you lose to symmetric nodes in catalogue filters and when clients pull results back
• Blocking: Docker Hub and the bandwidth test are throttled by DPI → a VPN tunnel via a foreign VPS is needed. And separate the two diagnoses from the start: protocol-level DPI is cured by tunnel settings, throttling by the VPS host's AS only by moving to another AS (see below)
• Network hardware or the driver can underperform even on a good tariff — and asymmetrically, only on upload or only behind the tunnel
• An ISP can silently cut your bandwidth with no warning and no incident showing in the control panel
• No public IP — behind the ISP's NAT the machine runs, but client ports are unreachable and rentals will not come
• One physical uplink shared by several rigs: a neighbour on the switch turns your 700 Mbit into 200 at measurement time, and the marketplace will remember the 200

Roskomnadzor throttles download by the VPS host's AS, and your tunnel config has nothing to do with it

This is the most time-expensive story in our log, and hardly anyone has taken it apart. The symptom: the tunnel comes up, the handshake succeeds, ping to the VPS is steady, upload through the same tunnel runs at full speed — and download starts, delivers tens of kilobytes and stalls. Not "slow" — stalls: the connection is alive, the data does not move.

The first reflex is to fiddle with the tunnel: change the port, the SNI, toggle flow, rebuild the client. We went through all of it and got nothing. The answer came when we brought the same config up from the same rig against three VPS boxes at three different providers: the results differed. So what is throttled is not the protocol and not our config but the address, and the filter's granularity is the VPS host's autonomous system (AS).

It is also clear why these AS numbers: the first to be filtered are providers used en masse by VPN resellers — their blocks have long been on lists, and they are throttled with a broad brush by AS, not per IP. A small niche provider lasts longer, but not forever: today's clean AS will be dirty tomorrow. That is exactly what happened: in October 2026 inbound traffic from abroad started being cut from VEESP too, and all of it — Reality, Hysteria and even plain SSH; who cuts it, the ISP or a filter, cannot be told from an apartment. So the measurement from your own line is repeated, and a fallback provider is lined up in advance and checked for real (the backup tunnel?lang=en).

# 1. Скорость по шагам. Если byte-rate падает в нуль на середине файла — дело не в протоколе
curl -o /dev/null -w 'speed=%{speed_download} B/s, code=%{http_code}, total=%{time_total}s\n' \
     --max-time 60 https://speed.cloudflare.com/__down?bytes=200000000

# 2. Очередь на отправку. Send-Q, который растёт и не расходится, = пакеты не уходят
watch -n1 "ss -tin state established '( dport = :443 )' | head -40"

# 3. Чистая полоса до своего VPS, без TLS и без HTTP-эвристик DPI
iperf3 -c ВАШ_VPS -p 5201 -P 4 -t 30        # к VPS
iperf3 -c ВАШ_VPS -p 5201 -P 4 -t 30 -R     # от VPS (это и есть download)

# 4. Решающий тест: ТОТ ЖЕ конфиг на VPS другого хостера.
#    Разный результат = троттлинг по AS. Одинаковый = ищите причину у себя.

NIC and offloads: judge by measurement only

The offload finding is counter-intuitive, so briefly on the mechanics. On a direct link TSO/GSO/GRO offload the CPU and help. Behind a tunnel the NIC first assembles a large segment and only then the packet is encapsulated — the result exceeds the tunnel's MTU, and fragmentation and retransmits follow. From outside this looks like "a bad link", although the link is fine. So we disable offloads strictly on the interface that goes into the tunnel, and re-measure: no gain, roll it back.

# Что включено сейчас
ethtool -k enp4s0 | grep -E 'tcp-segmentation|generic-segmentation|generic-receive'

# Выключаем ТОЛЬКО на интерфейсе, который ходит в туннель
ethtool -K enp4s0 tso off gso off gro off

# Ошибки и потери на самом интерфейсе
ip -s link show enp4s0
ethtool -S enp4s0 | grep -Ei 'err|drop|miss|fifo'

# Закрепить после перезагрузки: drop-in для systemd-networkd,
# и ОБЯЗАТЕЛЬНО перемерить серией send_mach_info.py --speedtest

A separate trap: systemd-networkd considers itself the owner of foreign addresses and routes and cleans them up after an upgrade. Because of that our egress went directly to Russian networks instead of the tunnel — fixed with a drop-in setting ManageForeignRoutes=no and ManageForeignRoutingPolicyRules=no. The commands for this diagnosis are collected in our Linux command cheat sheet?lang=en, a from-scratch OS install in installing Ubuntu for Vast.ai?lang=en.

How much traffic rentals actually move

The 8.32 TB in 37 hours figure is worth unpacking: it changes your tariff requirements more than the VRAM formula does. That is about 225 GB per hour, roughly 500 Mbit/s on average, continuously, for all 37 hours — one rental on one machine. Per day, 5.4 TB. If that load held for a month (a projection, not a measurement), it would be on the order of 160 TB per machine.

• A 10–20 TB monthly cap is burned through in two to four days, and then it is a throttled line or an overage bill
• "Unlimited" is a contract clause, not a wish: look for fair use, "up to N TB at plan speed", and the provider's right to throttle
• Ask about the cap in both directions: unlimited download with metered upload is common
• You do not sign a residential plan for this load: 160 TB a month from one address guarantees a conversation with your ISP

A public IP and ports

The machine needs externally reachable ports: the marketplace assigns the host a slot (a thousand ports per machine), and client containers publish SSH and their services inside it. Behind the ISP's NAT none of it is reachable, and the node sits in the listing without rentals. A static public IP is a mandatory line in the plan, not an extra for "some day later". Your own access works without a public IP: server access without a public IP?lang=en.

Where we got it wrong

• We missed that xray starts before DHCP completes. The packet to the VPS went into a not-yet-ready xray0, the connection never established, the client retried — and within minutes about 28 thousand sockets had piled up, the whole port range. Keepalive waves flooded the home router's conntrack table, and drops hit every rig at once, including ones the loop had nothing to do with. The fix is a safety-net unreachable route at its own priority: the packet dies at once instead of going into an unusable tunnel
• We automated failover to a standby VPS and got the opposite effect. The threshold was three failed checks — right on the edge: that same loop plus interference on the home link triggered a false failover on four rigs on 20 September. Worse, the "is the VPS we move to alive" check was a fiction: the TUN interface answered locally in 1–8 ms, so any address counted as alive. Fixed: threshold nine, a pause with no default route, a confirming re-check and a real probe of the remote VPS — it honestly returns 36–46 ms
• We looked for a network problem where there was none. Machines went offline with every sign of a network failure, and the cause was a blocking HTTP call from the vast agent to the web API with no timeout: the last log line is "VerifySendMachInfo calling web server", keepalives stop, the last-message counter sits at zero. The link is perfect
• We treated the link and the controller as one problem. A stuck vast controller (25 August — four rigs) is indistinguishable from a network failure, and is cured by resetting /var/lib/vastai_kaalia/controller_connection. Until we separated the two, every episode was filed under "probably the ISP". Write-up — the stuck controller write-up?lang=en
• We set a traffic price and never checked whether it accrues. In VM mode it does not accrue at all: 8.32 TB earned $0.00 against the stated $3/TB. The price has to be verified on a live rental, not in the settings page
• We learned about a speed drop from the marketplace, not from our own monitoring: the ISP reflected the 680 → 19 Mbit case nowhere

A checklist before signing with an ISP

• Symmetry: not "up to 1000", but equal download and upload. Aim for ≥500/500, ideally a symmetric gigabit
• Unlimited both ways, in writing, with the fair-use clauses actually read. The benchmark is 5.4 TB per day per machine under load
• A static public IPv4 and an externally reachable port range for the marketplace slot
• How many subscribers share the node and whether it is oversubscribed — that is what turns 700 Mbit into 200 at measurement time
• Who answers, and how fast, at three in the morning while a client's training run is going
• The option of a second physical uplink from a different provider — at least for heartbeat
• And before buying: pick the NIC by measurements, not by vendor (the rest of the hardware — what hardware to buy?lang=en)

To start, get a symmetric ≥ 500/500 plan (ideally gigabit symmetry) with unlimited traffic and a static IP, and plan from the outset for the link to run through a VPN tunnel. Take VPS boxes with headroom: one primary in a clean AS and one standby at another provider.

We can measure your link to the marketplace during a free consultation — without risking a live machine's listing. What that link is worth in money for a given card configuration is computed by the income calculator, and live measurements and per-machine income across our fleet are open at our live fleet page. If you have no time to work through it yourself, a server can be delivered turnkey with the tunnel and monitoring: our services, the first consultation is free.