P2P распределение моделей решает проблему загрузки больших артефактов в Kubernetes. Разбираем, как Dragonfly снижает нагрузку на origin и ускоряет доставку.
Проблема проявляется не сразу — до момента, когда размер моделей и масштаб кластера начинают умножаться. Типичный сценарий: 200 GPU-нод в Kubernetes и модель порядка 130 GB. Каждая нода тянет копию из общего хаба. В сумме это около 26 TB исходящего трафика с origin, упирающегося в (bandwidth) и (rate limiting). Даже если использовать NFS, готовые образы или зеркала object storage, система платит другой ценой: операционная сложность, риск устаревших версий и избыточное хранение. Вопрос становится архитектурным: как сделать так, чтобы загрузка на 200-ю ноду не отличалась по скорости от первой.
Решение — перенести распределение на уровень инфраструктуры и сделать его P2P. Dragonfly реализует это через сетку пиров: каждая нода, скачивая модель, одновременно становится источником для других. Ключевой компромисс — отказ от централизованного fan-out в пользу управляемой P2P-топологии. Это снижает давление на origin до O(1) загрузки и перекладывает распространение на кластер (O(log N) по мере распространения кусков). Цена — необходимость планирования топологии и координации через scheduler, но выигрыш в (throughput) и времени доставки критичен для больших моделей.
В реализации Dragonfly разбивает файл на мелкие части и раздаёт их как микрозадачи. Seed peer обращается к origin один раз и начинает делиться частями сразу после их получения — без ожидания полной загрузки. Это потоковая модель (streaming), где распределение стартует параллельно с первичной загрузкой. Scheduler вычисляет P2P-топологию, а GPU-ноды обмениваются кусками напрямую. В результате для модели 130 GB суммарный трафик к origin падает примерно с 26 TB до ~130 GB. Это не оптимизация, а устранение узкого места.
До недавнего времени оставалась практическая шероховатость: основные хабы моделей требовали преобразования URL в сырой HTTPS. Это ломало аутентификацию, pinning ревизий и семантику репозиториев. Новые схемы hf:// и modelscope:// в клиенте dfget решают это на уровне бэкендов. Каждая схема мапится на реализацию Backend с единым интерфейсом, регистрируется в фабрике и становится доступной без дополнительной конфигурации. Важная деталь — рекурсивные загрузки продолжают оперировать исходными схемами, а не преобразованными ссылками. Это сохраняет токены, контекст и единообразие пайплайна.
Поведение хабов различается, и это отражено в бэкендах. Hugging Face использует resolve-паттерн с возможными редиректами на Git LFS; HTTP-клиент прозрачно их обрабатывает. ModelScope предоставляет REST API для листинга с рекурсией и структурированными метаданными. В обоих случаях поддерживается token-based аутентификация, которая прокидывается через операции stat, get и exists. Это важно для приватных репозиториев и gated-моделей.
С точки зрения эксплуатации эффект наиболее заметен в трёх сценариях. Первый — массовое развёртывание в Kubernetes: вместо N независимых загрузок одна загрузка на seed и дальнейшее P2P-распространение. Второй — CI/CD и оценка моделей: при фиксировании ревизий (revision pinning) и наличии кэша Dragonfly повторные прогоны читают данные из P2P-слоя, уменьшая флаки из-за нестабильных загрузок. Третий — изолированные среды: seed может быть предзагружен в периметре с доступом к интернету, после чего кластер работает без внешней сети.
Отдельный плюс — унификация источников. Команды часто используют разные хабы одновременно. С нативной поддержкой hf:// и modelscope:// получается единый слой доставки: одна P2P-сеть, один кэш, одинаковая операционная модель. Добавление новых хабов укладывается в ту же архитектуру: реализовать Backend и зарегистрировать схему.
Метрики в источнике ограничены примером с сокращением трафика к origin до ~130 GB для 200 нод и модели 130 GB. Данных по latency или ускорению end-to-end не приводится, но причинно-следственная связь очевидна: параллельная раздача частей и снятие bottleneck с origin уменьшают общее время доставки.
Итог — прагматичное решение системной проблемы. Модели растут, кластеры растут, количество хабов растёт. P2P-распределение на уровне инфраструктуры с нативным пониманием источников убирает класс узких мест без усложнения пользовательского интерфейса. Для highload AI-платформ это становится базовой возможностью, а не опцией.