Привет! Меня зовут Артём, я руковожу группой цифровой трансформации в Sminex. Последние два года моя команда занимается внедрением AI в компанию. В реальности это куда менее гламурная история, чем звучит: про прокси-слои, отладку промптов в Langfuse и бесконечные «Почему модель опять ответила не то?».
В этой статье расскажу, как мы с самого начала пошли в LLM-платформу — а не в «одного бота», почему это было правильным решением и какие грабли мы всё равно собрали по дороге.
Почему мы сразу пошли в платформу
Типичный сценарий внедрения AI в компании выглядит так: команда собирает одного ассистента, показывает руководству, получает аплодисменты. Потом второго, третьего. У каждого свои ключи, свои доступы, своя модель данных. В какой-то момент это превращается в зоопарк, а стоимость поддержки и развития начинает полёт в стратосферу.
Мы решили не идти этим путём. Сразу настаивали на том, что сначала нужно построить платформу — и только потом делать кейсы на ней. Да, это медленнее на старте. Да, первый результат виден не сразу. Зато когда платформа готова, каждый следующий ассистент собирается за часы, а не за недели и сразу живёт в контролируемой среде.
Главный риск корпоративного AI — не качество модели, а управляемость внедрения. Это тезис, с которого мы стартовали и к которому возвращаемся каждый раз.
LLM-платформа в цифрах
Платформа запущена для всех сотрудников в октябре 2025 года. До этого были несколько месяцев закрытой беты, 99 заявок в листе ожидания, сбор обратной связи и переезд на более быстрое железо. Рост с момента запуска органический, без директив и обязательных внедрений: мы проводили вебинары, публиковали обучающие материалы на основе анализа реальных запросов и запустили канал в мессенджере, где коллеги делятся кейсами и предлагают фичи.
Отдельно покажу динамику потребления. Здесь график только по внешним моделям и только по провайдеру OpenAI, но он хорошо иллюстрирует общий паттерн: медленный старт в первые два месяца, затем резкий рост после появления первых полезных ассистентов и обучающих мероприятий. По локальным моделям картина аналогичная, но масштаб скромнее - 219 млн токенов.
Архитектура: из чего состоит LLM-платформа
Давайте разберём, из каких компонентов состоит наша платформа. Ниже представлена схема её архитектуры, а дальше мы последовательно пройдёмся по каждому слою:
UI: единое окно для сотрудников
В качестве пользовательского интерфейса мы выбрали Open WebUI — open-source-платформу для работы с LLM, которая разворачивается на собственной инфраструктуре. Для наших сотрудников это выглядит как привычный ChatGPT-подобный интерфейс: открыл браузер, выбрал ассистента, задал вопрос. Но под капотом — совсем другая история.
Почему именно Open WebUI, а не, скажем, собственная разработка или другой фронтенд?
Провайдер-агностичность. Open WebUI подключается к любому OpenAI-совместимому API — а значит, через наш LiteLLM-шлюз работает сразу со всеми моделями: локальными на vLLM и внешними через провайдеров. Пользователь переключается между моделями в одном интерфейсе, не задумываясь, где они крутятся.
Корпоративные функции из коробки. LDAP/SSO-аутентификация, ролевая модель доступа (RBAC), гранулярные разрешения на уровне групп пользователей — всё это уже встроено. Нам не пришлось писать систему доступов с нуля, мы подключили корпоративный SSO и получили централизованное управление: сотрудник уволился — доступ закрылся автоматически.
Собственные ассистенты. Через встроенный конструктор Model Builder можно создавать кастомных ассистентов с преднастроенными промптами, привязкой к конкретным моделям и инструментам — без единой строчки кода. Именно так мы собрали первых ассистентов по базам знаний.
Встроенный RAG. Open WebUI умеет загружать документы, индексировать их и использовать как контекст для ответов — с цитированием источников. Для простых сценариев этого хватает (мы так начинали), а для сложных — подключаем внешние pipeline через MCP.
Маркетплейс инструментов. На openwebui.com есть каталог community-расширений: functions, tools, pipelines. Оттуда мы, например, взяли компонент Confluence Search для первых RAG-ассистентов.
Расширяемость через MCP. Open WebUI поддерживает подключение внешних MCP-серверов — именно так мы связали его с Langflow (об этом ниже).
При этом Open WebUI — это именно интерфейс, а не вся платформа. Основная работа: gateway, лимиты, наблюдаемость, оркестрация — живёт на других слоях. Open WebUI не решает задачу контроля сам по себе, но даёт пользователям удобное единое окно для работы со всем, что мы построили под ним.
API-шлюз: LiteLLM
Это, пожалуй, самый важный архитектурный выбор. LiteLLM — open source AI Gateway, который даёт единый OpenAI-совместимый endpoint для 100+ LLM-провайдеров. По сути это прокси-сервер: любой сервис обращается к нему так, как будто говорит с OpenAI API, а LiteLLM маршрутизирует запрос на нужную модель — будь то локальный vLLM, внешний провайдер или что-то ещё.
Почему это критично для корпоративной платформы?
Единый интерфейс для всего. Все потребители: Open WebUI, Langflow, внутренние сервисы, скрипты разработчиков — ходят в один endpoint. Подключение новой модели — это изменение конфига в LiteLLM, а не правка десяти сервисов.
Виртуальные ключи и бюджеты. Каждая команда или проект получает свой виртуальный API-ключ с лимитом расходов. Мы видим, кто сколько потребляет, и можем вносить ограничения — без этого бюджет утекает незаметно.
Балансировка и fallback. Если один провайдер лежит или перегружен, LiteLLM автоматически перенаправляет на резервный. Для пользователя это бесшовно — он просто не замечает переключения.
MCP-шлюз. Через LiteLLM мы также централизуем подключение MCP-инструментов к корпоративным системам — с allowlist и ограничениями. Изначально мы пробовали MetaMCP как отдельный хаб для интеграций, но в итоге пришли к тому, что удобнее управлять всем через LiteLLM.
У нас строгое правило: все сервисы обращаются к моделям только через LiteLLM. Никаких прямых вызовов. Это та точка контроля, без которой платформа превращается в хаос.
Оркестрация сценариев: Langflow + Open WebUI через MCP
Для сборки сценариев мы используем Langflow — визуальный конструктор цепочек «LLM + retrieval + tools + постобработка». Langflow отлично подходит для быстрого прототипирования: можно за день собрать рабочий flow, подключить к данным и начать тестировать.
У визуальных конструкторов есть объективные ограничения: повышенная латентность под нагрузкой, сложность отладки крупных графов. Но при этом Langflow даёт гибкость, которую сложно получить иначе. Когда стандартных нодов не хватает, мы пишем кастомные компоненты с кодом внутри — вся логика по-прежнему живёт в Langflow, просто конкретные ноды содержат Python-код вместо визуальной конфигурации.
Отдельная история — как мы связали Langflow с Open WebUI. Сначала пробовали делать доработки через встроенные pipelines Open WebUI (functions, actions, filters), но тестировать и дебажить это было крайне неудобно. Тогда мы нашли другой подход: каждый инструмент собираем как отдельный flow в Langflow, а Langflow позволяет опубликовать проект как MCP-сервер. Каждый flow становится tool, доступным по протоколу MCP. Дальше мы добавляем этот MCP-сервер в Open WebUI — и ассистенты в Open WebUI получают доступ к инструментам из Langflow.
Получается удобный гибрид: разрабатываем и тестируем инструменты в Langflow (с его playground, логами и нодовым дебагом), публикуем как MCP, а используем уже в ассистентах Open WebUI — там, где пользователи реально работают. Это позволяет держать разработку инструментов и пользовательский интерфейс разделёнными, но связанными через стандартный протокол.
Inference: от RTX 5000 до H200
Эволюция, через которую, думаю, проходят многие:
Этап 1: эксперимент. RTX 5000 (16 GB) — модели класса 3B–8B, понять, что вообще возможно.
Этап 2: рост. Узел 2 × H100 (160 GB) — уже серьёзные модели, но мощностей быстро не хватает.
Этап 3: масштабирование. Прод-кластер 2 × H200 (282 GB) + отдельный тестовый 1 × H200 (141 GB).
По inference-движку прошли путь от Ollama (удобна на старте) к vLLM как промышленному стандарту в Kubernetes. vLLM сейчас основной прод-контур. Внешний контур — через OpenRouter — для моделей, которые невыгодно крутить локально.
Инфраструктура: Deckhouse и Kubernetes
Этот слой редко попадает в «AI-презентации», но на практике определяет, будет ли система жить. Нам нужен был не голый Kubernetes, а управляемый жизненный цикл кластера.
Deckhouse Kubernetes Platform даёт стандартизированную раскатку, политики безопасности, CI/CD. CPU workloads (UI, оркестратор, gateway) разнесены с GPU NodeGroups для inference, изоляция через taints/tolerations.
Наблюдаемость: два слоя и зачем это нужно
Два слоя наблюдаемости позволяют одновременно видеть состояние самой платформы и поведение LLM-приложений внутри неё.
Инфраструктурная телеметрия
Prometheus/Grafana поверх Deckhouse Kubernetes Platform. У нас настроены отдельные дашборды для каждого компонента, и каждый решает свою задачу.
Ingress-дашборд (Open WebUI, LiteLLM) отвечает на вопрос: платформа жива?
Здесь мы смотрим RPS и распределение кодов ответов: если полезли 4xx/5xx, значит, что-то сломалось на уровне маршрутизации или авторизации.
Upstream Response Time показывает, сколько бэкенд реально думает над запросом (у нас средний ~53 секунды — это нормально для LLM-запросов с длинной генерацией).
Avg Request Time (~28 секунд) — это то, что видит пользователь. Разница между ними — время на сеть и прокси. Если эта разница растёт — проблема не в модели, а в инфраструктуре.
vLLM-дашборд отвечает на вопрос: где именно тормозит inference? Это самый полезный дашборд для оптимизации.
Здесь видно:
● queue depth (сколько запросов стоит в очереди vs активно обрабатывается) — если очередь растёт, GPU не успевает;
● KV cache usage — если приближается к 100%, модель начнёт отбрасывать контекст;
● E2E latency в разрезе p50/p95/p99 — p50 может быть приемлемым, но если p99 улетает, значит, часть пользователей получает очень медленные ответы.
Отдельно мониторим time-to-first-token (TTFT) — время до первого токена, критично для UX: пользователь видит «модель думает» именно столько.
А inter-token latency показывает скорость «печати» — если она растёт, модель генерирует медленнее, чем обычно.
Prompt tokens rate и generation tokens rate дают общую картину нагрузки.
LLM-телеметрия: Langfuse
Второй слой — Langfuse, это open-source-LLM-engineering-платформа. Если Grafana показывает «железо работает / не работает», то Langfuse отвечает на вопрос: что происходит внутри LLM-приложения?
Что мы реально используем сейчас?
Трассировка запросов. Каждый запрос пользователя — это trace в Langfuse: видно всю цепочку от входного сообщения через LLM-вызов, retrieval, tool call и до финального ответа. Когда пользователь жалуется: «Бот ответил ерунду», — мы открываем конкретный trace и видим, какой промпт ушёл в модель, что вернул retrieval, сколько токенов потрачено, какая латентность на каждом шаге. Без этого дебаг LLM-приложений — гадание на кофейной гуще.
Стоимость по моделям. Langfuse автоматически считает cost per trace — и мы видим, сколько стоит каждый запрос, каждый ассистент, каждая модель. Это позволяет вовремя заметить, если какой-то сценарий начал жечь бюджет (например, из-за слишком длинного контекста или лишних итераций в цепочке).
Управление промптами и версионирование. Это то, что мы активно используем в повседневной работе. Все промпты для ассистентов живут в Langfuse, а не захардкожены в коде или в конфигурации Langflow. Каждое изменение — это новая версия с меткой (production, staging). Мы можем менять промпт без деплоя, через UI — и сразу видеть в трейсах, как изменение повлияло на ответы. Для ассистента по ГРП, например, промпты уже прошли через десятки итераций — и вся история изменений сохранена.
Playground. Встроенная песочница, где можно взять конкретный trace, поменять промпт или модель и сразу посмотреть, как изменится ответ. Ускоряет цикл итерации.
Куда мы хотим прийти, но пока не дошли?
Evaluations и датасеты. Langfuse поддерживает полноценные эксперименты: загружаешь датасет с ground truth, прогоняешь разные версии промптов, получаешь скоры и сравнение.
Для каждого нового ассистента заказчик обязан подготовить набор «вопрос → эталонный ответ → ссылка на источник». Мы написали внутренний гайд: минимум 15 пар для простого RAG-ассистента, 25–30 — для агента с несколькими инструментами. Распределение: 40% — базовые вопросы, 30% — пограничные случаи, 20% — нет ответа (проверяем, что модель не галлюцинирует), 10% — многошаговые.
Работа с корпоративными знаниями: от маркетплейса до собственных pipeline
Это ещё одна история эволюции, где мы прошли несколько стадий.
Стадия 1: готовый инструмент с маркетплейса. Начали с того, что взяли готовый компонент Confluence Search с маркетплейса Open WebUI. Он работает просто: через CQL (Confluence Query Language) ищет релевантные страницы, вырезает из них куски текста и подаёт модели как контекст. Для базовых вопросов по Confluence — работает. Мы на этом собрали первых ассистентов (по IT-инструкциям, по ВНД), и они до сих пор живут.
Стадия 2: ограничения готового решения. Проблемы начались, когда мы столкнулись с PDF-документами, презентациями и внутренними стандартами. CQL-поиск по Confluence не видит содержимое вложений. Разбиение на чанки не контролируется — инструмент режет текст, как ему удобно, а не как нужно для конкретной задачи. Качество ответов начало сильно зависеть от того, как именно информация лежит в Confluence, и повлиять на это было сложно.
Стадия 3: собственные pipeline в Langflow. Для более устойчивых и сложных задач мы стали вручную строить RAG pipeline в Langflow — контролируем извлечение текста, разбиение на чанки, формат метаданных. Это дороже в разработке, но даёт предсказуемый результат. Обязательное требование: ответ содержит ссылки на источники, а если информации нет — явный отказ вместо галлюцинации.
Стадия 4 (текущая): тестируем RAGFlow. Для упрощения этой работы сейчас пробуем RAGFlow — специализированный инструмент для knowledge workflow, который берёт на себя парсинг документов, чанкинг и индексацию. Сравниваем с нашими ручными pipeline по качеству и удобству сопровождения.
Выводы, которые я хотел бы прочитать сам год назад
Эксплуатация сложнее модели. Поднять модель — относительно просто. Сделать эксплуатацию предсказуемой: трейсинг, лимиты, доступы — тяжело. Именно здесь ломается большинство внедрений.
Open source — свобода и боль одновременно. На старте ускоряет, но боль проявляется на стыках: версии, совместимость, auth. Каждое обновление одного компонента может сломать другой.
Сначала датасет, потом промпт. Без эталонных ответов любая оптимизация — гадание. Мы пришли к тому, что датасет с ground truth — обязательный артефакт при запуске любого ассистента.
Готовые инструменты работают — до определённого предела. Маркетплейс Open WebUI, готовые компоненты Confluence-поиска — всё это позволяет запуститься быстро. Но как только задача усложняется (PDF, презентации, стандарты), приходится строить собственные pipeline. Важно понимать границу заранее.
Экономика платформы > экономика одного кейса. Единый gateway + observability + безопасность = снижение стоимости каждого следующего кейса. Первый ассистент на платформе дорогой, пятый — дешёвый.
Если коротко: управляемость важнее «самой крутой модели». А настоящая выгода от AI в корпорации приходит не от одного гениального бота, а от масштаба — когда сотрудники активно пользуются платформой каждый день, когда новый ассистент собирается за часы, а не за месяцы и когда вся эта конструкция стоит на предсказуемом фундаменте, а не на энтузиазме одного инженера.
Что дальше?
Платформа работает, пользователи есть, кейсы приносят пользу. Но мы только в начале пути — и вот куда смотрим дальше.
Автономные агенты. Сейчас наши ассистенты работают в режиме «вопрос — ответ». Следующий шаг — агенты, которые работают проактивно. Мы прорабатываем два направления: персональные Copilot-ассистенты (знают твой контекст, проекты, календарь — сами присылают утренний брифинг и напоминания о дедлайнах) и автономные агенты для рутинных процессов на базе OpenClaw/NemoClaw — с персистентной памятью, heartbeat-механизмом и cron-задачами. Ключевое отличие от простой автоматизации — агент не выполняет заскриптованный pipeline, а сам решает, что делать, в зависимости от контекста. Технология молодая, двигаемся аккуратно — сначала пилот на паре сценариев.
Улучшение RAG. Текущий подход с Confluence-поиском и ручными pipeline в Langflow работает, но плохо масштабируется. Мы тестируем RAGFlow и исследуем графовые базы знаний — чтобы ассистенты понимали не просто «где лежит ответ», а связи между документами, версии и актуальность. Отдельная задача — научиться нормально работать с неструктурированными данными: презентациями, чертежами, сканами.
Системные evaluations. Как я писал выше, мы понимаем, что без автоматической оценки качества масштабирование упрётся в потолок. В планах обязательный датасет с ground truth для каждого ассистента, автоматические прогоны при изменении промптов, интеграция eval-pipeline в процесс релиза.
Вместо заключения: о чём написать дальше?
Это первая статья из серии про нашу платформу. Мы можем копнуть глубже в любую из тем — и хотим рассказать о том, что вам действительно интересно.
Напишите в комментариях, что хотели бы прочитать в следующих статьях.
Экономика. Сколько реально стоит владение AI-платформой — железо, лицензии, команда, эксплуатация? Как считаем ROI и окупаемость?
Кейсы в деталях. Разбор конкретного ассистента от постановки задачи до прода — архитектура, промпты, грабли, метрики.
Стек и инфраструктура. Как устроен наш Kubernetes-кластер, как мониторим vLLM, как настроили сквозной трейсинг?
RAG и работа с документами. Как строим pipeline для корпоративных знаний, что работает, а что нет?
Процессы команды. Как устроена работа AI-команды в девелоперской компании — спринты, демо, взаимодействие с заказчиками?
Буду рад обсуждению в комментариях. Если строите что-то похожее — делитесь опытом, всегда интересно сравнить подходы.
