Как внедрить трехуровневую архитектуру LLM-инференса: шлюз, роутинг и инфраструктура. Часть 2

Когда экономика трехуровневой архитектуры становится понятна, возникает следующий вопрос: а как это всё развернуть в реальной инфраструктуре? Обычно к этому моменту в компании уже есть несколько подписок на LLM, команды подключаются к провайдерам каждая по-своему, единого учета расходов нет, а централизованного управления тем более. Для российских компаний, работающих с персональными данными и чувствительной корпоративной информацией, добавляются требования к локализации и защите данных. В таких сценариях важно, чтобы запросы к моделям, логи и результаты обработки оставались в контролируемом контуре. Если используются персональные данные, инфраструктура должна соответствовать требованиям 152-ФЗ.

В первой части мы разобрали, зачем разделять модели по уровням и сколько это экономит. Теперь рассмотрим, как это сделать технически: спроектировать шлюз, настроить маршрутизацию между быстрыми, универсальными и аналитическими моделями, подобрать GPU под каждый уровень и не откладывать безопасность на потом.

Инструменты и подходы: от прокси до AIaaS

Реализовать корпоративный шлюз можно по-разному: от легкого прокси до полноценной инфраструктурной платформы. Выбор зависит от профиля нагрузки, регуляторных требований, внутренней ИБ-политики и бюджета.

Программные шлюзы и прокси:

• LiteLLM дает единый API к десяткам провайдеров и встроенную логику резервного переключения. Разворачивается в частном облаке, хорошо ложится в существующие процессы ИБ.
• OpenRouter — маркетплейс моделей с единым API-ключом. Удобен для прототипирования, но весь трафик идёт через внешний сервис — для регулируемых отраслей это ограничение.
• Portkey добавляет развитую наблюдаемость (мониторинг, логирование, трассировку) и маршрутизацию поверх существующих интеграций с LLM. Позволяет анализировать стоимость, задержки и качество в разрезе каждой модели.

Инфраструктурные AIaaS-платформы:

ITGLOBAL.COM AIaaS сочетает мультимодельный роутинг с GPU-кластерами в частном облаке. Данные обрабатываются в изолированном контуре на территории РФ, инфраструктура соответствует 152-ФЗ, а поддержка и SLA снимают часть операционных рисков. Модели доступны через единый API, при этом чувствительные данные не передаются внешним LLM-провайдерам, если используется маскирование.

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

Как шлюз понимает, куда отправить запрос

• Корректная маршрутизация — основа экономии в трёхуровневой архитектуре. Если шлюз ошибается и направляет простые запросы на дорогую модель, весь смысл разделения теряется. Поэтому он использует несколько сигналов одновременно.
• Длина и структура промпта. Короткий, чётко сформулированный запрос вроде «извлеки поля» или «проверь на запрещённый контент» почти наверняка уходит на быстрый уровень, поскольку там нужна скорость и низкая цена, а не глубокие рассуждения.
• Формулировки и ключевые слова. Запросы «проанализируй», «оцени архитектуру», «найди компромисс», «докажи» чаще попадают на универсальный или аналитический уровень, потому что предполагают цепочки рассуждений.
• Тип задачи. Классификация, извлечение данных и модерация по умолчанию идут на быстрый уровень. Аналитические отчёты и генерация кода средней сложности — на универсальный. Архитектурный анализ, научные расчеты и сложные агентные сценарии — на аналитический.
• Историческая статистика. Если определенный тип запросов месяц за месяцем успешно обрабатывается на быстром уровне, повышать уровень нет смысла. Если же растёт число резервных переключений или жалоб, часть таких запросов переводят на модель посильнее.
• В продвинутых конфигурациях шлюз использует отдельную легкую модель-классификатор, которая добавляет небольшую задержку при принятии решения о маршруте. На общую задержку это практически не влияет, а точность распределения вырастает заметно.

Инфраструктура под каждый уровень: что и где ставить

Профиль нагрузки каждого уровня диктует свои требования к железу и размещению. Универсального решения нет — под каждый уровень подбирается свой набор GPU и своя модель развертывания.

1. Быстрый уровень: максимальная пропускная способность, минимальная задержка

Для быстрого уровня важны минимальная задержка, высокая пропускная способность и низкая стоимость обработки запроса. Здесь обычно размещают короткие операции: классификацию, модерацию, извлечение полей, маршрутизацию запросов и простые RAG-сценарии. Для таких задач целевая задержка может измеряться сотнями миллисекунд. Для генеративных сценариев отдельно контролируются time-to-first-token, скорость генерации и p95/p99 полной задержки ответа.

Подходящее оборудование: NVIDIA RTX PRO 6000 Blackwell Server Edition — один из самых рациональных вариантов для локального и облачного инференса, закрывает большинство сценариев в одиночной конфигурации. NVIDIA A100 относится к предыдущему поколению, но остается применимой в существующих GPU-парках; если уже есть — работает, но для новых закупок смысла мало. NVIDIA L40S — промежуточный вариант, уступает RTX 6000 PRO и по памяти, и по производительности.

Размещение: облако или собственная инфраструктура с GPU-кластерами. При стабильно высокой нагрузке такое решение окупается за несколько месяцев по сравнению с постоянной оплатой внешних API.

Типичный сценарий: массовый клиентский или внутренний ассистент, где большая часть запросов — короткие операции классификации, поиска, извлечения данных или маршрутизации. Такие задачи выгодно держать на быстром уровне, чтобы не отправлять типовые запросы на дорогие reasoning-модели.

2. Универсальный уровень: баланс производительности и стоимости

Здесь важны поддержка длинных контекстов (64–128K токенов) и предсказуемая производительность. Нагрузка обычно стабильна в рабочее время, но может резко возрасти при запуске нового продукта или маркетинговой акции.

Подходящее оборудование: RTX PRO 6000 может вмещать квантованные модели с достаточно тяжёлыми весами. Для многих сценариев универсального уровня этого достаточно. Если требуется работа без квантования — сервер с несколькими RTX PRO 6000 (если возможна параллелизация) или сервер с A100 80GB в multi-GPU-конфигурации с NVLink для относительно бюджетного решения.

Оптимальный подход — гибридный: базовая нагрузка обслуживается в облаке, а пиковые всплески покрываются через внешний API. Это уменьшает CAPEX и не заставляет держать избыточные мощности «на всякий случай».

3. Аналитический уровень: дорогие GPU под редкие, но сложные задачи

Аналитический уровень потребляет меньше всего запросов (5–15% трафика), но требует самых мощных GPU. Длинные цепочки рассуждения, контексты на сотни тысяч токенов — всё это требует значительного объема вычислительных ресурсов.

Подходящее оборудование: NVIDIA H200 141 ГБ HBM3e на архитектуре Hopper — один из профильных вариантов для тяжёлых inference-нагрузок и длинного контекста. Multi-GPU-конфигурации на H200 могут использоваться для крупных моделей, но конкретная емкость зависит от размера модели, точности весов, длины контекста и KV-cache. Пропускная способность HBM3e подходит для длинных цепочек рассуждения.

Для самых тяжёлых нагрузок применяются Blackwell HGX-платформы: B200 с большей производительностью и памятью по сравнению с Hopper, а также B300 Blackwell Ultra с 288 ГБ HBM3e на GPU. Но это уже совершенно другой уровень инфраструктуры, экономически оправданный не для каждого корпоративного сценария.

Держать выделенный GPU 24/7 для аналитического уровня обычно нерационально, так как утилизация редко превышает 20–30%. Поэтому здесь оптимальны выделенные инстансы в частном облаке или у AIaaS-провайдера.

Типичный сценарий: еженедельный аудит архитектурных решений — тысячи сложных запросов в неделю. Для такого объёма выделенный H200 у сервис-провайдера дешевле собственной инсталляции и при этом обеспечивает изоляцию данных и соответствие 152-ФЗ.

Сводная таблица по инфраструктурным уровням

Безопасность и соответствие требованиям

При внедрении корпоративного ИИ вопросы безопасности нельзя оставлять на этап «доработаем позже». Минимальный набор требований, который должен быть заложен в архитектуру с первого дня:

• Шифрование. Все соединения между приложениями, шлюзом и моделями — только TLS. Логи, метрики и кэш запросов шифруются при хранении. Это база, без которой ИБ-служба не согласует проект.
• Управление доступом (IAM). Ролевая модель с разделением на администраторов шлюза, разработчиков и пользователей API. Плюс аудит всех обращений к моделям: вы должны знать, кто и какие данные отправляет в ИИ-сервисы.
• Локализация данных. При использовании внешних API (OpenRouter, OpenAI, Anthropic) данные физически покидают инфраструктуру компании и могут обрабатываться в других юрисдикциях. Для компаний с отраслевыми регуляциями важно, чтобы чувствительные данные обрабатывались в изолированном контуре. ITGLOBAL.COM AIaaS разворачивается в облаке ITG с аттестатом УЗ-2 для обработки персональных данных в соответствии с требованиями 152-ФЗ. Это позволяет размещать LLM-инфраструктуру в защищённом российском контуре и не передавать чувствительные данные внешним LLM-провайдерам. Вычислительные мощности доступны без необходимости строить собственный дата-центр.
• Сегментация. Трафик быстрого, универсального и аналитического уровней логически разделяется, а в регулируемых отраслях и физически на разных GPU-нодах. Это упрощает контроль и позволяет задавать разные политики для разных классов задач.
• Логирование и аудит. Полный журнал запросов с привязкой к пользователю, модели и времени. Важный нюанс: сами журналы могут содержать чувствительные данные, поэтому к ним применяются те же меры защиты, что и к основной нагрузке.

Трёхуровневая архитектура упрощает соблюдение этих требований: политики и ограничения задаются по уровням, а шлюз становится естественной точкой, где реализуются шифрование, IAM и аудит.

Как внедрить трёхуровневую архитектуру: roadmap для руководителя

Переход к трёхуровневой архитектуре — не спринт выходного дня, но и не многолетний проект. Реалистичный план на несколько месяцев выглядит так.

Шаг 1. Аудит ИИ-нагрузки

Соберите данные по фактическим запросам за 1–3 месяца и разложите их на три группы: массовые, сбалансированные и требующие рассуждений. В большинстве компаний первая группа составляет 60–70% трафика. Если у вас этот показатель ниже 50% — либо классификация некорректна, либо архитектуру приложения пора пересмотреть.

Шаг 2. Подбор моделей под каждый уровень

Для каждой категории подбираете кандидатов и тестируете их на реальных запросах, а не на синтетических бенчмарках. Критерий: модель закрывает ≥95% задач в своём классе без заметной потери качества. На выходе: конкретный пул из 3–5 моделей для быстрого, универсального и аналитического уровней, завязанный на ваши сценарии.

Шаг 3. Проектирование и внедрение шлюза

Для пилота используете готовые решения — LiteLLM, Portkey. Развертывание базовой конфигурации LiteLLM силами опытной команды занимает пару дней. Затем отказоустойчивая конфигурация, ИБ-аудит (1–2 недели) и поэтапное подключение продуктивных систем (2–4 недели). Полная готовность к production-среде: 1–2 месяца.

Шаг 4. Инфраструктурная стратегия по уровням

Для каждого уровня определяете модель размещения:

• API-доступ: низкий порог входа, оплата по факту, зависимость от провайдера. Оптимален для прототипирования и аналитического уровня с нерегулярной нагрузкой.
• Собственная инфраструктура: полный контроль, требует компетенций по эксплуатации GPU-фермы. Окупается при высокой стабильной нагрузке в первую очередь для быстрого уровня.
• Частное облако / AIaaS — гибкость API-доступа плюс изоляция и контроль собственной инфраструктуры. Оптимально для регулируемых отраслей.

Шаг 5. Мониторинг и постоянная оптимизация

После запуска вводите метрики для еженедельного контроля:

• Стоимость на запрос — по каждому уровню и совокупная. Рост без увеличения нагрузки означает, что логика маршрутизации деградирует.
• Качество ответов: выборочная ручная проверка или автоматическая оценка по эталонным тестам. Падение на быстром уровне — сигнал перевести часть запросов на универсальный.
• Доля резервных переключений — процент запросов, которые шлюз перевёл на более дорогую модель. Рост показателя — повод пересмотреть классификацию или обновить модели.
• Задержка (p95/p99) — быстрый уровень не должен превышать 500 мс на коротких и простых запросах.

По этим данным корректируются правила маршрутизации, состав моделей, а при необходимости и инфраструктурная стратегия. Например, перенос части нагрузки из API в облако или наоборот.

Вывод

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

Результат: ниже расходы, прозрачнее бюджет, меньше риск нарушить регуляторные требования и больше пространства для масштабирования ИИ-инициатив без страха потерять контроль над расходами.

Начинать стоит не с выбора шлюза или GPU, а с аудита реальных запросов. Когда видно, что 60–70% трафика — это типовые задачи, которые не требуют рассуждений, ответ на вопрос «зачем мы платим за дорогую модель на каждом запросе» становится очевидным. А дальше шаги 2–5, последовательно и без спешки.