Недавняя статья компании YADRO на Хабре, “Где живут LLM”, стала редким и ценным окном в реальную практику построения корпоративного инференс-кластера. Команда не только поделилась своей архитектурой, но и честно рассказала о проблемах, что делает их опыт вдвойне полезным. Спасибо им за это!

 🚀🚀🚀 https://habr.com/ru/companies/yadro/articles/930304/

Их кейс можно брать за основу, давайте разберем его и проведем небольшой анализ стека для работы с LLM — от низкоуровневых движков на GPU до low-code платформ для конечных пользователей. Этот разбор покажет, почему определенные технологические решения становятся стандартом и что необходимо для построения не просто работающей, а по-настоящему эффективной и масштабируемой AI-экосистемы.

Фундамент: Архитектура инференс-кластера

В основе кластера YADRO лежат проверенные и мощные компоненты, ставшие индустриальным стандартом:

• Оборудование: Серверы с NVIDIA H100.
• Оркестрация: Kubernetes.
• Движок инференса: vLLM.

Ключевым и очень показательным решением стал выбор vLLM вместо, казалось бы, более нативного для NVIDIA Triton Inference Server. Аргументация YADRO проста и прагматична: с vLLM «намного проще добавлять новые модели», и он «изначально предоставляет OpenAI-совместимые REST API».

Это идеально отражает главный тренд в LLM Serving. Triton — это универсальная рабочая лошадка, мощная, но требующая серьезной подготовки: конвертации моделей в форматы вроде TensorRT и часто создания дополнительной «обвязки» для предоставления удобного API. vLLM, напротив, это специализированный инструмент, заточенный именно под LLM. Благодаря своей ключевой инновации — PagedAttention, которая кардинально оптимизирует управление памятью для KV-кэша, — он обеспечивает высочайшую пропускную способность и простоту использования «из коробки».

Средний слой: Production-ready операции и масштабирование

Переход от тестов к эксплуатации всегда вскрывает «узкие места». Опыт YADRO — прекрасное тому подтверждение.

1. Проблема шлюза (Gateway): Команда обнаружила, что популярный прокси LiteLLM, хотя и удобен для старта, становится узким местом при нагрузке выше 50 одновременных запросов. Их решение — разработка собственного `LLM Gateway` на Go — является абсолютно верным шагом для высоконагруженных систем. Такой шлюз берет на себя аутентификацию, логирование, rate-limiting и, что самое главное, умную маршрутизацию запросов. Для тех, кто не готов к собственной разработке, в экосистеме появляются готовые решения, такие как vllm-router, специально созданные для балансировки нагрузки между фермами vLLM-инстансов. https://docs.vllm.ai/en/stable/deployment/integrations/production-stack.html

2. Продвинутое масштабирование в Kubernetes: В статье упоминается горизонтальное автомасштабирование (HPA) по CPU. Для GPU-сервисов это неэффективно. Современный подход требует более точных триггеров:
   • Масштабирование по GPU:** Использование `DCGM Exporter` от NVIDIA для сбора метрик утилизации GPU и настройка HPA или KEDA (Kubernetes Event-driven Autoscaling) по этим данным.
   • Масштабирование по очереди:** vLLM предоставляет метрику `vllm_requests_waiting` (количество запросов в очереди). Это лучший показатель реальной нагрузки: как только очередь растет, система добавляет новые поды с моделями.

3. Мониторинг (Production Metrics): Для стабильной работы 24/7 критически важно отслеживать специфичные метрики vLLM в реальном времени через Prometheus и Grafana:
   • Производительность:** Time to First Token (TTFT) и Time per Output Token (TPOT).
   • Нагрузка:** `vllm_requests_running` (в обработке) и `vllm_requests_waiting` (в очереди).
   • Состояние памяти:** `vllm_gpu_cache_usage_perc` (процент использования KV-кэша). Рост этой метрики — прямой предвестник ошибки нехватки памяти (OOM).

Верхний уровень: Платформы и интерфейсы для пользователей

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

• Dify: Low-code платформа для создания AI-приложений. Dify — это не просто чат, а открытая LLM Ops платформа, позволяющая быстро создавать и развертывать AI-приложения. С помощью визуального конструктора даже нетехнические специалисты могут собирать сложные воркфлоу, включая чат-ботов, RAG-системы (поиск по базам знаний) и AI-агентов. Dify подключается к инференс-кластеру по OpenAI API и служит мостом между мощным бэкендом и конечными бизнес-задачами.

• Open WebUI: Персональный и безопасный доступ к моделям. Если Dify — это конструктор приложений, то Open WebUI — это универсальный и безопасный «кабинет» для прямого взаимодействия с моделями. Как отмечается в документации, это «расширяемая, многофункциональная и удобная платформа для самостоятельного хостинга, предназначенная для работы полностью в автономном режиме» docs.vllm.ai). Open WebUI предоставляет привычный интерфейс в стиле ChatGPT, но с расширенными возможностями: работа с локальными документами (RAG), веб-браузинг в чатах и управление доступом для команд — всё это в защищенном контуре компании https://www.repocloud.io/details/?app_id=271.

Инструменты для разработчиков: Интеграция в рабочий процесс

Чтобы LLM стали повседневным инструментом, их нужно встроить в рабочую среду разработчиков. YADRO верно отмечают ключевые компоненты этого уровня:

• Continue.dev: Open-source расширение для VS Code/JetBrains, которое превращает внутренний инференс-кластер в полноценного AI-ассистента, работающего прямо в IDE.
• OpenAI SDK и LiteLLM: Использование этих библиотек на стороне клиентских приложений — золотой стандарт. Они позволяют разработчикам абстрагироваться от деталей реализации бэкенда и работать с унифицированным, удобным API.

Кстати у litellm.ai есть демка их прокси сервера заходим Username: admin Password: sk-1234
https://demo.litellm.ai/ui

Итоги и выводы

Опыт YADRO — это отличный срез современной инженерной практики в области LLM. Его комплексный анализ позволяет сформировать полную картину production-ready AI-экосистемы, которая состоит из нескольких ключевых слоев:

1. Бэкенд: Специализированные движки (vLLM) на Kubernetes стали де-факто стандартом для высокопроизводительного инференса.
2. API и Ops: OpenAI-совместимый API — это универсальный «язык» для всех компонентов системы. Для масштабирования необходим кастомный Gateway/Router (как у YADRO) и продвинутое автомасштабирование по метрикам GPU и длине очереди.
3. Приложения и GUI: Low-code платформы (Dify) позволяют быстро создавать бизнес-решения, а интерфейсы вроде Open WebUI или LibreChat предоставляют сотрудникам безопасный и многофункциональный доступ к моделям.
4. DevX (Developer Experience): Интеграция в IDE (Continue.dev) и использование стандартизированных SDK делают LLM по-настоящему удобным инструментом для разработчиков.

Таким образом, создание «дома для LLM» — это далеко не только развертывание моделей на GPU. Это выстраивание целостной, многоуровневой системы, где каждый слой решает свою задачу, обеспечивая производительность, надежность и, в конечном итоге, ценность для бизнеса.

Ссылки Основная: https://habr.com/ru/companies/yadro/articles/930304/

• https://docs.vllm.ai/en/latest/deployment/frameworks/open-webui.html
• https://www.repocloud.io/details/?app_id=271
• https://docs.digitalocean.com/products/marketplace/catalog/open-webui/
• https://www.pondhouse-data.com/blog/integrating-n8n-with-open-webui
• https://www.requesty.ai/blog/openwebui-vs-librechat-which-self-hosted-chatgpt-ui-is-right-for-you
• LibreChat