F5 ADSP | 20 октября 2026 г.

Попросите сетевого архитектора телекоммуникационной компании нарисовать кластер ИИ, и вы увидите стойки, графические процессоры (GPU), коммутационную матрицу, системы хранения — всё целиком. Попросите его изобразить, как запрос попадает в этот кластер, и ручка останавливается. Трафик просто поступает. Он появляется на пороге, и кластер берет обработку на себя.

Это «слепое пятно» скоро станет слишком дорогим. При распределенном инференсе такой пробел может означать простаивающие GPU на одной площадке и перегруженные очереди на другой. Провайдер услуг, имеющий 50 объектов по всей стране, обладает тем, чего не могут купить гиerscalers (крупнейшие облачные провайдеры) с двумя дата-центрами: близостью к пользователям, диверсификацией энергоснабжения, суверенным присутствием и уже проложенным оптоволокном.

Это самый веский аргумент в пользу распределенного инференса, когда модели обслуживаются из сети площадок, а не из одной. Но 50 площадок становятся единым сервисом инференса только тогда, когда для каждого запроса принимается решение о том, какая именно из 50 должна на него ответить. На сегодняшний день ничто этого не делает. Именно этот пробел F5 устраняет совместно с NVIDIA, AMD и другими поставщиками инфраструктуры ИИ, чтобы решения принимались на основе телеметрии от ускорителей и стеков инференса, которые сервис-провайдеры развертывают на практике.

Трафик не появляется по мановению волшебства

Вот что происходит на самом деле. DNS-запрос выбирает площадку. Глобальный балансировщик нагрузки серверов оценивает близость, доступность и емкость, после чего возвращает адрес. Внутри площадки прокси-сервер завершает соединение, проверяет, кто делает запрос, применяет политики, а балансировщик нагрузки выбирает сервер. Эта цепочка называется маршрутизацией с учетом особенностей приложений. Она незаметно обслуживала каждый веб- и мобильный сервис на протяжении двух десятилетий, и значительную ее часть создала компания F5.

Эта цепочка по-прежнему работает для ИИ. Просто она принимает решения по неверным причинам. Глобальный балансировщик нагрузки серверов (GSLB) знает, какая площадка ближе и какая работает. Он не знает, на какой площадке загружена модель, перенасыщены ли GPU этой площадки, и является ли данный запрос голосовым вызовом, который не может пересекать всю страну, или долгой задачей агента, которую можно отправить туда, где вычислительные мощности стоят дешево. Поэтому он выбирает ближайшую работающую площадку, которая может оказаться той самой, что работает на пределе возможностей, в то время как идентичный кластер в 200 километрах от нее простаивает наполовину.

От маршрутизации с учетом приложений к маршрутизации с учетом ИИ

Суть перехода заключается в следующем: маршрутизация с учетом приложений должна стать маршрутизацией с учетом ИИ-приложений. Та же цепочка, те же DNS, те же прокси. Два новых источника данных.

Первый — это телеметрия изнутри инфраструктуры ИИ. Каждый кластер знает, какие модели он обслуживает, насколько глубоки его очереди, какой объем KV-кэша используется, сколько запросов находится в обработке и сколько времени новый запрос будет ожидать своего первого токена. F5 BIG-IP Next for Kubernetes уже располагается на фронтенде таких кластеров и видит всё это, вплоть до количества токенов на запрос. Передайте эти данные наверх, и решения F5 DNS перестанут просто хранить карту расположения площадок, а начнут показывать актуальную картину того, на что способна каждая площадка прямо сейчас.

Решения F5 DNS объединяют оперативную телеметрию инференса с каждой площадки с сутью самого запроса, чтобы направить его на ту площадку, которая может выполнить SLA прямо сейчас.

Второй — это характер (цель) запроса. Маршрутизатор с поддержкой LLM может классифицировать запрос до его размещения: какая модель ему нужна, насколько он чувствителен к задержкам, какой примерно объем работы он представляет и для какого уровня SLA арендатор платит. Этот контекст становится вводными данными для DNS-ответа вместо того, чтобы выяснять это уже после того, как запрос попал не по адресу.

Объедините эти два фактора, и соглашение об уровне обслуживания (SLA) перестанет быть абзацем в договоре и превратится в правило маршрутизации. SLA по задержке направляет запрос на ближайшую площадку с загруженной моделью и достаточным запасом производительности. SLA по стоимости направляет запрос к наименее дорогим доступным ресурсам. Требование о суверенитете гарантирует, что данные не покидают страну. GSLB принимает решение, которое мог принимать всегда, но теперь обладая информацией, которой у него никогда не было.

Три уровня принятия решений, один ответ

Размещение — это не одно решение, а три, вложенные друг в друга.

На глобальном уровне решения F5 DNS выбирают площадку или ИИ-фабрику, основываясь теперь не только на близости, работоспособности и суверенитете, но и на телеметрии инференса в реальном времени и характере запроса.
На региональном уровне запрос направляется в кластер с нужной моделью и доступной емкостью, пересекая специфичную для арендатора границу безопасности, которая обеспечивает изоляцию до того, как будет задействован какой-либо GPU.
На локальном уровне, внутри кластера, BIG-IP Next for Kubernetes применяет политики идентификации, доступа и трафика, а компонент Endpoint Picker выбирает рабочий узел (worker).

Этот последний уровень — точка, где маршрутизация перестает быть просто путем к GPU и становится частью производительности инференса. Когда движок обрабатывает промпт, этап префилла (prefill) заполняет KV-кэш графического процессора. Если следующий запрос разделяет этот префикс и попадает на рабочий узел, у которого он все еще сохраняется, работа используется повторно. При попадании в любое другое место GPU производит перерасчет заново. При небольшой нагрузке этого никто не замечает. В условиях производственной конкуренции рабочий набор превышает размеры кэша, и выбор места размещения начинает определять, будет ли работа переиспользована или выполнена заново.

В BIG-IP Next for Kubernetes 2.4 компонент Endpoint Picker оценивает префикс кэша, глубину очереди, выполняемые запросы, использование KV-кэша и ожидаемое время до появления первого токена перед выбором рабочего узла. Он поддерживает разделение этапов префилла и декодирования (prefill/decode disaggregation), а также открытые технологии инференса, такие как llm-d и расширение Kubernetes Gateway API Inference Extension. Важно то, что все три уровня разделяют общий контекст. Площадка, выбранная по критерию емкости, не передает задачу перегруженному кластеру. Кластер, выбранный под конкретную модель, не отправляет запрос на рабочий узел, которому придется воссоздавать свой контекст с нуля.

Сеть, которая знает то, что знают GPU

Ничто из этого не требует создания новой платформы в дополнение к инфраструктуре ИИ. Глобальный уровень маршрутизации уже существует. Интеллектуальные возможности на уровне кластера уже существуют и сегодня используются в рабочей среде клиентами F5. Соединяющий элемент — телеметрия кластера и контекст запроса, поступающие для принятия единого решения DNS — это работа, которая ведется в настоящее время.

Итак, возвращаясь к архитектору с ручкой. Пятьдесят дата-центров действительно превосходят два с точки зрения инференса ИИ, но только в том случае, если сеть между ними знает то же, что знают GPU. Тогда 50 площадок перестают быть 50 изолированными островами вычислительных мощностей и начинают работать как единый сервис инференса, способный соблюдать SLA, уважать государственные границы и использовать каждый уже оплаченный графический процессор.

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

Узнайте больше о том, как F5 помогает организациям улучшать распределенный инференс, управление ИИ-трафиком и использование GPU в современной инфраструктуре ИИ.