Мы отказались от Kubernetes и собрали self-hosted ИИ-сотрудников на одном сервисе: что это дало бизнесу
Мы строим AiHummer — платформу ИИ-сотрудников для бизнеса. Разработку версии 1.1.0 мы начали 8 марта 2026 года и завершили 10 июля. Одно из самых спорных решений приняли ещё до публичного коммерческого запуска: self-hosted-версия должна устанавливаться в инфраструктуре клиента без обязательных Docker и Kubernetes, а работа с ИИ не должна зависеть от обязательной оплаты внешнего LLM API.
У этой истории есть важное ограничение: на момент подготовки материала коммерческие продажи и платные пилоты ещё не начинались, поэтому здесь не будет выдуманных процентов роста и фальшивого «сократили внедрение в три раза». Вместо них — проверяемые цифры самой архитектуры, конфликт внутри команды, три неудачных решения и границы подхода. Это история не о том, как Kubernetes «проиграл», а о том, почему архитектура продукта должна соответствовать стадии бизнеса.
Пилот может остановиться ещё до первого запроса к модели
Когда команда показывает ИИ-агента, естественно обсуждать качество ответов: понимает ли он задачу, умеет ли работать с документами, вызывает ли инструменты, не теряет ли контекст. Но в корпоративном контуре до этих вопросов есть другой слой.
Где будут храниться переписка и документы? Какие данные уйдут провайдеру модели? Кто отвечает за обновления? Что произойдёт при недоступности внешнего API? Как остановить агента, отозвать права и восстановить систему? Наконец, кто в компании вообще должен согласовать новый инфраструктурный стек?
На этапе проектирования мы выписали путь, который потенциальному заказчику пришлось бы пройти до проверки одного бизнес-сценария. В варианте с обязательным Kubernetes к согласованию самого приложения добавлялись кластер, container runtime, registry, ingress, секреты, мониторинг образов и новая зона ответственности. Внешний LLM API добавлял договор с провайдером, правила передачи данных и переменный счёт за запросы.
Внутри команды возник вполне реальный конфликт. Инженерная логика подсказывала: корпоративный продукт нужно сразу проектировать под масштабирование, отказоустойчивость и несколько узлов. Продуктовая логика возражала: если ценность одной роли ещё не доказана, нельзя заставлять клиента сначала принять инфраструктуру для будущего масштаба. Первая позиция обещала техническую универсальность. Вторая сокращала путь до проверки гипотезы, но перекладывала на нас больше ответственности за упаковку, диагностику и обновления.
Мы выбрали вторую. Не потому, что Kubernetes плох, а потому, что он отвечал на вопрос о будущем масштабе раньше, чем продукт ответил на вопрос о текущей пользе.
Что именно мы называем ИИ-сотрудником
Термин «ИИ-сотрудник» легко превратить в обещание цифровой замены человека. Для нас это не электронный коллега «вообще», а программная роль с пятью явными границами: входящим запросом, ожидаемым результатом, набором знаний, разрешёнными инструментами и правилом передачи задачи человеку.
Такой агент может принять обращение, найти информацию в корпоративной базе знаний, подготовить проект ответа, заполнить разрешённые поля или запустить согласованное действие. Но результат становится полезным только тогда, когда операция повторяема, её можно проверить, а исключения не маскируются уверенным текстом.
За человеком остаются решения, которые нельзя делегировать вместе с ответственностью:
определение правил и критериев качества;
выдача и отзыв доступов;
утверждение действий с юридическими, финансовыми, кадровыми или репутационными последствиями;
разбор исключений и спорных случаев;
регулярная проверка результатов и изменение границ автономности.
Мы делим действия на три зоны. Поиск, классификацию и подготовку черновиков можно автоматизировать. Изменение данных или отправку сообщения от имени компании часто разумно проводить через подтверждение. Решения с высокой ценой ошибки остаются за человеком.
Поэтому «обучить ИИ-сотрудника» для нас обычно не означает дообучить нейросеть. Это значит описать роль, подключить источники, настроить права и инструменты, собрать тестовые сценарии, задать правила отказа и определить маршрут эскалации. Модель — важная часть системы, но не вся система.
Почему мы выбрали host-native-развёртывание
В финальной архитектуре AiHummer основное приложение — один gateway-сервис. Он одновременно выполняет функции control plane и turn engine: принимает входящие события, собирает контекст, обращается к модели, вызывает разрешённые инструменты и передаёт ответ в исходный канал. Обязательная внешняя зависимость у него одна — PostgreSQL, где хранится состояние платформы.
Поставка устанавливается на современный 64-битный Linux с systemd и поддерживает две архитектуры: x86_64 и arm64. Основной gateway, плагины и дополнительные функции работают как отдельные systemd-службы, а файлы находятся в одном корневом каталоге. Для базовой установки не нужны контейнерный runtime, Kubernetes и отдельный обязательный worker-слой.
Это не означает «один процесс без зависимостей». PostgreSQL остаётся критичным компонентом. Голос, видео, браузер, веб-поиск и семантический поиск могут подключаться как отдельные sidecar-сервисы. Их можно разместить на том же сервере, вынести на другой хост или заменить существующим сервисом по URL.
Отдельно мы отвязали место установки платформы от места выполнения модели. Клиент может подключить локальный OpenAI-compatible endpoint, внешнего провайдера или выстроить цепочку из основной и резервной моделей. Платный внешний API не является обязательным условием запуска. До подключения реальной модели каналы, маршрутизацию и агентов можно проверять на детерминированной заглушке.
Такой подход не делает систему автоматически безопасной. Он лишь убирает два обязательных слоя — контейнерную оркестрацию и внешний inference — и позволяет заказчику отдельно решить четыре вопроса: где работает платформа, где выполняется модель, какие данные выходят из контура и какие действия разрешены агенту.
Одна команда запускает сервис, но не завершает внедрение
Техническая установка начинается с одной команды из личного кабинета. Скрипт определяет архитектуру процессора, загружает подходящий пакет, проверяет контрольную сумму и подпись, раскладывает файлы и регистрирует systemd-службы. Ссылка на установку персональная и действует 30 дней; уже установленный экземпляр продолжает обновляться и после истечения исходного токена.
Работоспособность проверяется двумя отдельными endpoint: healthz подтверждает, что процесс жив, а readyz — что доступна PostgreSQL и сервис готов обслуживать запросы. Для минимальной оценки достаточно 2 vCPU, 2 ГБ оперативной памяти и 10 ГБ диска. Рекомендуемый односерверный профиль — 4 vCPU, 8 ГБ памяти и SSD на 40 ГБ. Голосовые функции и локальные модели требуют больше: ориентир начинается с 8 vCPU, 16 ГБ памяти и 80 ГБ SSD, а необходимость GPU зависит от выбранной модели и нагрузки.
Но эти цифры описывают запуск программного контура, а не готовое внедрение. Мы разделили путь до промышленной работы на четыре этапа.
Первый — техническая установка и readiness-проверка. Второй — подготовка к эксплуатации: TLS, резервные копии PostgreSQL, мастер-ключа и файлов, мониторинг, аутентификация, сетевые ограничения и план восстановления. Третий — интеграция с каналом, корпоративной системой, источниками знаний и разрешёнными инструментами. Четвёртый — настройка роли и приёмка на реальных или обезличенных сценариях.
У этих этапов разная природа. Первый можно ускорить установщиком. Второй зависит от ИТ и информационной безопасности. Третий — от качества API и доступов. Четвёртый — от владельца бизнес-процесса и того, насколько точно он способен описать хороший результат. Обещание «внедрение за пять минут» смешивает все четыре этапа и потому почти ничего не говорит руководителю проекта.
Три решения, которые пришлось пересмотреть
1. Мы проектировали будущий масштаб раньше текущей ценности
На старте хотелось сразу закрыть отказоустойчивость, горизонтальное масштабирование и универсальную эксплуатацию. Это звучало по-взрослому, но создавало архитектуру для нагрузки, которой ещё не существовало, и для сценария, полезность которого ещё не была доказана.
Мы изменили порядок решений. Сначала — одна узкая роль, её права и измеримый результат. Затем — реальный профиль нагрузки и требования к доступности. И только после этого — решение, нужен ли кластер. Односерверная схема стала не обещанием вечной простоты, а стартовой точкой с заранее признанным пределом.
2. Мы путали установку с внедрением
Когда служба запущена и readyz возвращает успешный ответ, инженеру легко считать задачу выполненной. Для бизнеса в этот момент работа только начинается: нужны данные, интеграции, правила, тесты, владельцы и реакция на ошибку.
Из-за этой ошибки мы пересобрали не только документацию, но и саму модель поставки. Установщик отвечает за программный контур. Production checklist — за безопасную эксплуатацию. Настройка роли и приёмка вынесены в отдельные этапы. Одна команда осталась преимуществом установки, но перестала быть обещанием мгновенного внедрения.
3. Мы воспринимали модель как часть инфраструктурной судьбы
Если продукт намертво связан с одним внешним API, выбор модели превращается в архитектурное ограничение. Если всё локально по умолчанию, можно получить обратную проблему: дорогое железо и более слабое качество там, где внешний сервис был бы рациональнее.
Мы заменили выбор «локально или в облаке навсегда» на цепочку провайдеров с приоритетами и резервированием. Локальная модель может быть основной, облачная — резервной, или наоборот. Это не отменяет различий в качестве, цене, tool calling, контекстном окне и политике данных, но позволяет сравнивать варианты на уровне конкретной операции, а не идеологии.
Когда облако и Kubernetes рациональнее
Self-hosted не является премиальной версией SaaS и не становится безопасным только из-за адреса сервера. Он даёт больше контроля, но вместе с ним передаёт клиенту эксплуатационную ответственность.
Облако рациональнее, когда гипотезу нужно проверить быстро, данные разрешено обрабатывать у провайдера, нагрузка непредсказуема, а собственной команды эксплуатации нет. Managed-сервис также выигрывает, если бизнесу важнее доступ к конкретной модели и готовый SLA, чем контроль над каждым компонентом.
Kubernetes рациональнее односерверной host-native-схемы, когда нужны несколько узлов, независимое масштабирование компонентов, rolling deployment и автоматическое перераспределение нагрузки. Особенно — если в компании уже есть зрелая кластерная платформа, наблюдаемость, registry, правила работы с секретами и команда, для которой новое приложение не создаёт отдельную технологическую зону.
Host-native-схема на одном Linux-хосте имеет смысл, когда нагрузка понятна, компания уже умеет сопровождать системные службы, требования к данным и сетям являются частью бизнес-процесса, а обязательный внешний inference неприемлем или даёт слишком непредсказуемую экономику.
Наконец, выбор необязательно бинарный. Платформа может работать в инфраструктуре клиента, а модель — локально или у разрешённого провайдера. Пилот и промышленная эксплуатация могут проходить в разных контурах. Важно лишь не считать перенос автоматическим: данные, секреты, интеграции и процедуры восстановления всё равно нужно проектировать отдельно.
Что это дало бизнесу — и чего пока не дало
Отказ от обязательного Kubernetes дал нам не доказанное снижение TCO и не волшебное ускорение внедрения. Он дал более чёткий продуктовый контракт.
Теперь можно независимо обсудить четыре решения: где работает платформа, где выполняется модель, какие действия разрешены агенту и где ответственность возвращается человеку. Минимальный runtime стал измеримым: один gateway, одна обязательная база данных, ноль обязательных контейнерных слоёв и ноль обязательных платных LLM API. Требования к оценочному серверу также перестали быть абстрактными: 2 vCPU, 2 ГБ памяти и 10 ГБ диска.
Цена этой простоты тоже понятна. Мы взяли на себя упаковку релизов, подпись и проверку артефактов, обновления, диагностику и совместимость с окружением заказчика. Если продукт дойдёт до нагрузки, при которой один хост станет ограничением, нам придётся либо предложить кластерный профиль, либо честно признать границу применения текущей схемы.
Следующий этап — не добавлять ещё один инфраструктурный слой «на всякий случай», а проверить подход в коммерческих внедрениях. Мы хотим узнать, где действительно заканчивается установка и начинается интеграция, сколько стоит принятый результат с учётом проверки человеком и в какой момент простота одного хоста перестаёт окупаться.
Наш вывод не в том, что Kubernetes не нужен ИИ-продуктам. Он в другом: архитектура должна соответствовать уровню доказанности сценария. Когда бизнес ещё выясняет, приносит ли ИИ-сотрудник пользу в одной конкретной операции, инфраструктура для будущего масштаба может оказаться самым дорогим способом получить ответ.