# Сетевой трафик AI-сервиса: как учесть egress до размещения GPU

Как оценивать передачу данных при размещении моделей: веса, клиентские запросы, межрегиональные связи, резервные копии и расходы повторных запусков.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/cloud-egress-model-serving/
Language: ru

Сравнение размещения часто начинается с цены GPU и заканчивается ею. Но сервис также получает веса, принимает файлы, обращается к хранилищу и отправляет ответы. Для владельца площадки и финансового партнёра важно заранее понять, какие передачи включены в предложение и какие создают отдельные расходы.

## Нарисуйте направления трафика

Отметьте источник модели, хранилище данных, вычислительный узел, клиентов и резервные копии. Для каждой связи укажите направление, предполагаемый объём и расположение компонентов.

[Google документирует сетевые категории и цены](https://cloud.google.com/vpc/network-pricing) отдельно для разных направлений передачи. [Страница EC2 On-Demand](https://aws.amazon.com/ec2/pricing/on-demand/) также содержит условия начислений, которые нужно проверять вместе с вычислительным предложением.

Точные суммы зависят от региона, продукта и схемы. Нельзя объявлять входящий или исходящий трафик бесплатным для любой платформы по аналогии с одной таблицей.

## Разделите запуск и обычные запросы

Загрузка весов может происходить редко, а обращения пользователей — постоянно. При частых холодных стартах первоначальный сетевой этап повторяется. Это другой бюджет, чем у одной устойчивой реплики.

В условном пилоте измерьте получение артефактов, суточный тестовый поток и восстановление после согласованной остановки. Сохраняйте локальную копию или её отсутствие как явное условие.

Не выводите объём сети только из числа сгенерированных токенов. Входные документы, изображения и служебные обращения могут создавать отдельную передачу.

## Проверьте размещение компонентов

Если поиск, модель и хранилище расположены раздельно, запрос проходит несколько границ. Межрегиональная или внешняя связь может влиять одновременно на расходы и задержку.

Сравните один регион с разнесённым вариантом при одинаковой задаче. Зафиксируйте не только байты, но и время полного ответа. Более дешёвый вычислительный узел в другом месте не обязательно делает дешевле весь сервис.

Уточните требования к данным и допустимое расположение до переноса. Технически доступный маршрут не устанавливает автоматически подходящие организационные условия обработки.

## Добавьте обновления и резервные копии

Периодическое обновление весов, выгрузки журналов и восстановление данных тоже входят в жизненный цикл. Их легко забыть, если измеряется только короткий диалог на готовом сервере.

Составьте календарь обычных операций и отдельный сценарий неудачного обновления. Если большой артефакт приходится получать повторно, это должно быть видно в расходах испытания.

Для собственной площадки проверьте включённый объём, ограничения провайдера и возможность длительной передачи. Не путайте обещанную скорость подключения с отсутствием других условий обслуживания.

После пробного периода сверьте измеренные передачи с детализацией начислений выбранной платформы. Различие может указывать на пропущенный компонент, резервное копирование или неверную границу учёта. Уточнение этой карты полезнее простого умножения наблюдавшихся токенов на условную сетевую ставку.

## Как сравнить предложения

Полезна таблица «вычисления — хранение — передача — сопровождение». Для каждой строки укажите включённые услуги и источник актуальных условий. Не сравнивайте голую цену карты с предложением, где уже оплачена часть инфраструктуры.

Дальше прочитайте [доступность соединения](/ru/journal/network-and-uptime/) и [гибридную архитектуру](/ru/journal/cpu-gpu-hybrid-architecture/).