Канал у хоста в РФ — второе по важности узкое место после электричества. Медленный, асимметричный или нестабильный канал = низкая загрузка, провал bandwidth-теста и потеря аренд: клиент в каталоге видит цифру скорости, а не ваши добрые намерения. Про питание и площадку мы разбирали отдельно сколько электричества ест сервер, здесь — только сеть. Всё ниже снято с шести машин: TVT (4×RTX 4090), tv5080v (2×RTX 5080), tv50 (RTX 5090), tv80, test и клиентская машина. Каждая теряла аренды из-за канала, и почти ни разу причина не была той, которую подсказывал здравый смысл.
Сколько Mbit/s требует vast.ai — точная формула
- Требование зависит от видеопамяти: ≈2,6 Mbit/s на каждый 1 ГиБ суммарной VRAM машины (всех карт вместе), но не ниже 100 и не выше 500 Mbit/s — отдельно на download и upload
- Симметрия важна: клиенты заливают датасеты и веса внутрь и вытягивают чекпойнты наружу, поэтому upload не менее критичен, чем download
- Низкий packet loss. Высокий loss — это не «чуть медленнее», а обрыв сессии клиента посреди обучения и жалоба в поддержку
- Латентность для batch-ML некритична: 40 мс и 8 мс до клиента дают одинаковый результат на длинном обучении
- Замер делает не биржа снаружи, а сам хост: send_mach_info.py гоняет Ookla и отправляет результат. Значит всё, что портит замер на вашей стороне — pull образа, живой клиент, сосед по каналу, — уезжает прямо в карточку
| Машина | Карты | VRAM всего | 2,6 × VRAM | Требование |
|---|---|---|---|---|
| клиентская машина | 1 × RTX 2060 Super | 8 ГиБ | 21 Mbit | 100 / 100 — порог |
| tv50 | 1 × RTX 5090 | 32 ГиБ | 83 Mbit | 100 / 100 — порог |
| tv5080v | 2 × RTX 5080 | 32 ГиБ | 83 Mbit | 100 / 100 — порог |
| TVT | 4 × RTX 4090 | 96 ГиБ | 250 Mbit | 250 / 250 — формула |
| 8 × 4090 (для иллюстрации) | 8 × RTX 4090 | 192 ГиБ | 499 Mbit | 500 / 500 — потолок |
Из таблицы видна неприятная вещь: формальное требование почти никогда не совпадает с реальной задачей. Пять машин из шести проходят с домашней сотней мегабит — и все пять будут стоять пустыми, если рядом в каталоге те же карты на симметричном гигабите. Порог 100 Mbit даёт право быть в листинге, а не право получить аренду.
Что решает на самом деле: фильтр каталога и скользящее среднее
Клиент ищет карту фильтром, а не глазами: в поиске офферов есть поля inet_down и inet_up, и человек, которому надо залить 300 ГБ датасета, ставит порог сам. Всё, что ниже, он не видит — машина не проиграла в сравнении, её не было в выдаче. Второй эффект тоньше: в карточке живёт не последний замер, а сглаженное значение — скользящее среднее вида «0,9 × старое + 0,1 × новый», а speedtest в кроне запускается по лотерее, примерно один раз из девяти в час.
Главные проблемы в РФ
- Асимметрия тарифа: часто 1000↓/100–300↑. Формальное требование такой upload обычно проходит (порог — 100 Mbit), но вы проигрываете симметричным нодам в фильтрах каталога и на отдаче результатов
- Блокировки: Docker Hub и bandwidth-тест режутся DPI → нужен VPN-туннель через зарубежный VPS. И сразу различайте два диагноза: DPI по протоколу лечится настройкой туннеля, троттлинг по AS хостера VPS — только переездом на другой AS (разбор ниже)
- Сетевое железо или драйвер может проседать даже при хорошем тарифе — и проседать несимметрично, только на upload или только за туннелем
- Провайдер может тихо срезать канал без предупреждения и без аварии в личном кабинете
- Нет белого IP — за NAT провайдера машина работает, но клиентские порты недоступны, и аренд не будет
- Один физический канал на несколько ригов: сосед по свитчу в момент замера превращает ваши 700 Mbit в 200, и биржа запомнит именно 200
РКН душит download по AS хостера, и конфиг туннеля тут ни при чём
Это самая дорогая по времени история в нашем журнале, и разобрана она мало кем. Симптом: туннель поднимается, handshake проходит, ping до VPS ровный, upload через тот же туннель идёт на полную полосу — а download стартует, отдаёт десятки килобайт и встаёт. Не «медленно», а встаёт: соединение живо, данные не идут.
Первый рефлекс — крутить туннель: сменить порт, поменять SNI, включить или выключить flow, пересобрать клиент. Мы прошли этот путь целиком и не получили ничего. Разгадка пришла, когда мы подняли один и тот же конфиг с того же рига к трём VPS у трёх разных хостеров: результаты оказались разными. Значит, режут не протокол и не наш конфиг, а адрес, и гранулярность фильтра — автономная система (AS) хостера VPS.
| Хостер VPS | Download через туннель | Upload | Вывод |
|---|---|---|---|
| OVH | обрывается на десятках килобайт и встаёт, Send-Q растёт и не расходится | полная полоса | AS задушен, настройками не лечится |
| M247 | та же картина, на любом порте и любом SNI | полная полоса | AS задушен |
| Private Layer | полная полоса канала | полная полоса | чисто — переехали сюда |
Понятно и почему именно эти AS: под фильтр первыми попадают хостеры, которых массово используют продавцы VPN — их блоки давно в списках, и режут широкой кистью по AS, а не точечно по IP. Мелкий нишевый провайдер живёт дольше, но не вечно: сегодняшний чистый AS завтра станет грязным, поэтому резервный VPS у другого хостера держим заранее резервный туннель.
# 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. Одинаковый = ищите причину у себя.Сетевая карта и оффлоады: судить только по замеру
Вывод про оффлоады контринтуитивный, поэтому коротко о механике. На прямом канале TSO/GSO/GRO разгружают процессор и помогают. За туннелем карта сначала собирает большой сегмент, и только потом пакет инкапсулируется — итог выходит за MTU туннеля, дальше фрагментация и повторы. Снаружи это выглядит как «плохой канал», хотя канал в порядке. Поэтому выключаем оффлоады строго на интерфейсе, который ходит в туннель, и перемеряем: прироста нет — возвращаем как было.
# Что включено сейчас
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Отдельная ловушка: systemd-networkd считает себя хозяином чужих адресов и маршрутов и подчищает их после апгрейда. У нас из-за этого egress пошёл напрямую в РФ вместо туннеля — лечится drop-in с ManageForeignRoutes=no и ManageForeignRoutingPolicyRules=no. Команды для такой диагностики собраны в шпаргалке шпаргалку по командам Linux, установка системы с нуля — установку Ubuntu под Vast.ai.
Сколько трафика реально льют аренды
Цифру 8,32 ТБ за 37 часов стоит развернуть: она меняет требования к тарифу сильнее формулы по VRAM. Это около 225 ГБ в час, то есть примерно 500 Mbit/s в среднем, непрерывно, все 37 часов — одна аренда на одной машине. В сутки 5,4 ТБ. Если такая загрузка продержится месяц (прогноз, а не замер), выйдет порядка 160 ТБ с машины.
- Лимит 10–20 ТБ в месяц такая аренда выжигает за двое-четверо суток, дальше срезанная полоса или счёт за перелимит
- Безлимит — строка договора, а не пожелание: ищите fair use, «до N ТБ на скорости тарифа» и право провайдера ограничить полосу
- Спрашивайте про лимит в обе стороны: бывает безлимитный download при квотированном upload
- Домашний тариф под такую нагрузку не подписывают: 160 ТБ в месяц с одного адреса — гарантированный разговор с провайдером
Белый IP и порты
Машине нужен диапазон портов, доступных снаружи: биржа выдаёт хосту слот (тысяча портов на машину), и внутри него клиентские контейнеры публикуют SSH и свои сервисы. За NAT провайдера всё это недоступно, и нода висит в листинге без аренд. Статический белый IP — обязательный пункт тарифа, а не опция «когда-нибудь потом». Свой доступ к серверу работает и без белого IP: доступ к серверу без белого IP.
Где мы ошиблись
- Не заметили, что xray стартует до получения DHCP. Пакет к VPS уходил в ещё не готовый xray0, соединение не устанавливалось, клиент повторял — и за минуты набралось около 28 тысяч сокетов, весь диапазон портов. Keepalive-волны забили conntrack домашнего роутера, и обрывы пошли у всех ригов сразу, включая те, к которым петля отношения не имела. Лечение — страховочный маршрут unreachable с отдельным приоритетом: пакет умирает сразу, а не уходит в недоступный туннель
- Автоматизировали переход на резервный VPS и получили обратный эффект. Порог стоял на трёх неудачных проверках — на самом краю: та же петля плюс помеха на домашнем канале дали ложный переход четырём ригам 20 сентября. Хуже того, проверка «жив ли VPS, на который уходим» была фикцией: TUN-интерфейс отвечал локально за 1–8 мс, живым считался любой адрес. Починили: порог девять, пауза без default route, контрольная перепроверка и настоящая проверка удалённого VPS — она честно даёт 36–46 мс
- Долго искали проблему в канале там, где её не было. Машины уходили в офлайн с признаками сетевого сбоя, а причиной был блокирующий HTTP-вызов агента vast к веб-API без таймаута: последняя строка в логе «VerifySendMachInfo calling web server», keepalive не уходят, счётчик последнего сообщения на нуле. Канал идеален
- Считали, что канал и контроллер — одна проблема. Залипший контроллер vast (25 августа — четыре рига, 5 сентября — все шесть за день) внешне неотличим от сетевого сбоя, а лечится сбросом /var/lib/vastai_kaalia/controller_connection. Пока не разделили, каждый эпизод уходил в «наверное, провайдер». Разбор — разбор залипшего контроллера
- Выставили цену за трафик и не проверили, начисляется ли она. В режиме VM не начисляется вообще: 8,32 ТБ принесли $0.00 при заявленных $3/ТБ. Цену надо проверять на живой аренде, а не в настройках
- Узнавали о падении скорости от биржи, а не от своего мониторинга: случай 680 → 19 Mbit провайдер не отразил нигде
Чек-лист до подписания договора с провайдером
- Симметрия: не «до 1000», а равные download и upload. Целимся в ≥500/500, оптимально — симметричный гигабит
- Безлимит в обе стороны, письменно, с проверкой пунктов про fair use. Ориентир — 5,4 ТБ в сутки на машину под нагрузкой
- Статический белый IPv4 и доступный снаружи диапазон портов под слот биржи
- Сколько абонентов на узле и есть ли переподписка — это превратит 700 Mbit в 200 в момент замера
- Кто и как быстро отвечает в три часа ночи, когда у клиента идёт обучение
- Возможность второго физического канала от другого провайдера — хотя бы под heartbeat
- И до закупки: NIC выбирать по замерам, а не по вендору (про остальное железо — какое железо брать под аренду)
Для старта подключите симметричный тариф ≥ 500/500 (лучше gigabit-симметрию) с безлимитом и статическим IP и сразу закладывайте, что канал пойдёт через VPN-туннель. VPS берите с запасом: один основной в чистом AS и один резервный у другого хостера.
Померить свой канал так, как его увидит биржа, можно на проверку канала — тот же порядок действий, что у send_mach_info.py, но без риска испортить карточку живой машины. Что канал даёт в деньгах на конкретной конфигурации карт, считает калькулятор дохода, а живые замеры и доход по каждой машине парка открыты на витрину нашего парка. Если разбираться самому некогда, сервер можно взять под ключ вместе с туннелем и мониторингом: наши услуги, первая консультация бесплатна.