Скрытая стоимость облака

Глава 5 — Скрытая стоимость облака

Основное утверждение последних пяти лет заключается в том, что облако экономично, масштабируемо и просто. Для многих рабочих нагрузок это совершенно верно. Но для корпоративных RAG (Retrieval-Augmented Generation) это все чаще не так. И вы обычно понимаете это в конце первого квартала, когда приходит счет.

Возьмем самую недооцененную статью расходов: API моделей компьютерного зрения. Когда компания загружает свой фотоархив в современную RAG-систему, каждое фото должно быть "описано" мультимодальной моделью, которая извлекает из него содержание, объекты, контекст, любые наложенные тексты, настроение, композицию. Крупный европейский поставщик моделей — пока без названия — предлагал в 2025 году отличную модель семейства Qwen с 32 миллиардами параметров по интересной цене за изображение. Проблема, обнаруженная только в процессе эксплуатации и после нескольких месяцев производства: под нагрузкой поставщик обрезал ответы. Не всегда, непредсказуемо, не когда перед ним была команда тестирования: случайно. Одна из десяти фотографий, иногда одна из пяти, возвращалась с обрезанным JSON, неправильно распарсенным, с частичными или нулевыми метаданными. Время обработки взлетало с десяти секунд до двухсот секунд на изображение, без какой-либо закономерности. Стоимость повторных попыток — потому что повторные попытки оплачиваются, каждый вызов, даже тот, который сервер обрезает — оказалась выше ожидаемой. База данных была неоднородной: некоторые фотографии были богаты метаданными, другие — усечены. И команда не могла воспроизвести проблему в тестовой среде, потому что в тестах нагрузка была низкой, и все работало.

Решение пришло в трех частях: более компактный запрос (более короткие ответы реже обрываются), интеллектуальная логика повторных попыток (если ответ занимает более пятидесяти секунд и возвращается пустым, попробуйте снова немедленно) и — когда объем это оправдывает — возможность вообще отказаться от облака и запускать модель машинного зрения на локальной GPU, более медленной, но детерминированной. Правильная архитектура, согласно этому опыту, — это не "облако всегда" и не "локально всегда". Это "выбирайте для каждого вызова, в зависимости от того, что нужно в данный момент".

Затем есть глава о запросах. Каждый пользовательский поиск в классическом облачном RAG запускает каскад платных API-вызовов. Один для встраивания вопроса. Один для классификации намерений (какого типа вопрос?). Один для переранжирования документов. Один для генерации окончательного ответа. Каждый стоит долю цента. Для внутреннего сервиса с пятьюдесятью пользователями и десятью тысячами запросов в день — что немного, но не огромное число для средней компании — ежемесячный счет достигает сумм, которые заставили бы поморщиться даже снисходительного финансового директора. И рост линейный: удвоите пользователей, удвоите счет. Экономии масштаба в потребленных токенах нет, не для вас.

Существует проблема, которая оставалась скрытой в 2025 году и стала центральной в 2026 году: каждый отдельный запрос отправляет фрагменты корпоративных документов — иногда конфиденциальных, иногда покрытых соглашением о неразглашении (NDA), иногда подпадающих под действие отраслевых норм — на серверы внешнего поставщика, в юрисдикции, которые не всегда совпадают с вашей, с политиками хранения журналов, которые не всегда прозрачны. Более одной европейской компании за последние восемнадцать месяцев обнаружила во время аудита — обычно инициированного обеспокоенным клиентом или проверкой ISO — что их контракты, прайс-листы и технические спецификации были обработаны (и потенциально зарегистрированы для "улучшения обслуживания") инфраструктурой за пределами ЕС. Удивление, как правило, обходится дороже, чем экономия на локальном оборудовании, которое они хотели избежать.

Альтернатива не заключается в противоположном догмате. "Облако нет, локально да" так же неверно, как "облако всегда да". Альтернатива — это архитектура, которая позволяет вам выбирать для каждого отдельного элемента конвейера — внедрения, классификации, переранжирования, зрения, финальной генерации — использовать облачную или локальную модель, и менять свое решение за день, а не за квартал. Это требует проектирования, в котором поставщики взаимозаменяемы, где ни один элемент не привязан к названию конкретной компании, где переход от Regolo к Ollama (или наоборот) — это строка конфигурации, а не переписывание. И этого, до недавнего времени, было мало. Популярные фреймворки, несмотря на фасад "независимости от поставщика", на самом деле были тесно связаны с кем-то.