Google вывела в общий доступ AI-функции для AlloyDB и добавила схему, которая выглядит куда практичнее привычного «давайте дергать LLM на каждую строку». Proxy-модели AlloyDB позволяют один раз обучить легковесную локальную модель на ответах большой модели и потом выполнять часть запросов прямо внутри базы. Для команд, которые уже считали стоимость и задержки на массовых LLM-вызовах, новость вполне предметная: речь идет не о косметике, а о попытке убрать внешний inference с горячего пути SQL.
Об этом сообщает InfoQ. Google одновременно объявила общую доступность AlloyDB AI functions и две техники ускорения: smart batching и proxy model architecture. Первая уже доступна для функций ai.if и ai.rank, вторая пока работает в preview для ai.if. По внутренним тестам Google, smart batching дает прирост пропускной способности до 2400 раз по сравнению с обработкой «по одной строке», а оптимизированные proxy-модели поднимают этот показатель до 23 000 раз и снижают стоимость в 6000 раз. Красивые цифры, но компания сама уточняет: они относятся к внутренним тестам и не описывают производительность всех AI-функций в целом.
Что именно стало GA. Теперь в AlloyDB можно вызывать модели из обычного SQL через набор функций: ai.generate для генерации текста, ai.if для семантической фильтрации, ai.rank для семантического reranking, ai.forecast для прогнозирования временных рядов, а также новые ai.summarize, ai.agg_summarize и ai.analyze_sentiment. Идея понятна: разработчик пишет запрос, который фильтрует или ранжирует данные по смыслу, а не только по точному совпадению ключевых слов. На демо-слайдах это всегда выглядит бодро. На проде обычно всплывает другой вопрос: сколько стоит прогнать так 100 тысяч строк и сколько это будет ехать.
Именно в эту точку бьет smart batching. Если раньше таблица на 100 тысяч товаров теоретически означала 100 тысяч отдельных походов во внешнюю модель через Vertex AI, то теперь AlloyDB может собирать несколько строк в один вызов. Системный промпт отправляется один раз, данные батчатся, количество сетевых обращений падает. Google утверждает, что в такой схеме можно получить до 10 тысяч строк в секунду в тех же внутренних тестах. Для сценариев, где payload на строку относительно небольшой, а основной overhead сидит в повторной отправке промпта и ожидании inference, это звучит вполне правдоподобно. Чуда здесь нет: просто кто-то наконец перестал делать дорогое и медленное действие 100 тысяч раз подряд.
LLM как учитель, а не зависимость на каждый запрос
Куда интереснее вторая часть истории. Proxy-модели AlloyDB меняют саму механику работы с LLM внутри базы. Вместо того чтобы дергать большую модель на каждую проверку, AlloyDB предлагает двухфазный сценарий. На первом этапе выполняется PREPARE: база берет выборку данных, отправляет ее во frontier-модель и на основе полученных ответов обучает маленькую локальную модель внутри себя. На втором этапе обычный SQL-запрос уже использует этот локальный proxy для выполнения условия через USING proxy(...). Если уверенность модели низкая или подходящий proxy еще не обучен, система может откатиться к внешней frontier-модели.
Это важный архитектурный сдвиг. В привычной схеме база остается клиентом внешней LLM и платит за каждое решение задержкой, токенами и сетевыми round trip. В схеме Google большая модель становится скорее преподавателем, который один раз размечает образцы, а дальше локальная модель воспроизводит нужное суждение на скорости базы данных. По данным компании, в preview для ai.if такой подход дает до 100 тысяч строк в секунду. Для русскоязычной аудитории здесь главный смысл не в красивом PR-коэффициенте, а в том, что Google пытается превратить LLM-функции из дорогого внешнего сервиса в почти нативный оператор SQL для части задач.
При этом важные оговорки лучше не терять. Во-первых, самые громкие цифры про 23 000 раз быстрее и 6000 раз дешевле относятся именно к оптимизированной proxy-модели для ai.if, которая пока не находится в GA. Во-вторых, речь идет о внутренних тестах Google, а не о независимых публичных бенчмарках на чужих данных. В-третьих, ускорение AI-функций нужно отдельно включать через флаг базы google_ml_integration.enable_ai_function_acceleration, по умолчанию оно не активировано. Для инженерной команды это не повод спорить о маркетинге в комментариях, а повод запускать свои тесты на собственных распределениях данных, длинах текстов и типах фильтров.
Что это меняет для разработчиков и рынка
InfoQ приводит и внешнюю реакцию. Архитектор Starburst Раймундас Юодвалкис предложил смотреть на эти функции как на управляемые расширения базы данных, а не как на «магические WHERE-условия». Его практический совет звучит здраво: начинать с read-heavy сценариев, например обзора отзывов или семантической фильтрации каталогов, а не сразу писать модельные выводы обратно в критичные бизнес-системы. Еще одна здравая мысль: стоимость модели стоит учитывать отдельно от стоимости запроса. Иначе SQL внезапно начнет выглядеть дешевым только на бумаге.
На уровне рынка Google делает ставку на то, что база данных станет не просто хранилищем, а местом, где вместе живут структурированные запросы, векторный поиск и прикладные AI-операции. В релизе также упомянут managed MCP server для AlloyDB, чтобы AI-агенты могли ходить к данным через Model Context Protocol без собственной обвязки и инфраструктуры, и уже существующий векторный поиск на базе индекса ScaNN с масштабом до 10 миллиардов векторов. Иначе говоря, Google собирает вокруг PostgreSQL-совместимой СУБД слой, в котором разработчику предлагают не выносить семантическую логику в приложение, а оставлять ее рядом с данными. Для части команд это удобно. Для части команд это еще и опасно, потому что соблазн спрятать сложную бизнес-логику в SQL обычно заканчивается долгими разговорами с теми, кто потом это сопровождает.
Главный вопрос теперь не в том, можно ли встроить LLM-поведение в базу, а кто первым сделает это без лишней магии и с понятной экономикой на реальных нагрузках. Если подход с локальным proxy после обучения на выборке окажется жизнеспособным за пределами внутреннего бенчмарка Google, конкурентам вроде Aurora, Azure SQL, CockroachDB и PlanetScale придется отвечать не только маркетингом про AI-ready, но и собственной версией дешевого inference рядом с данными. Первоисточник с деталями и оговорками доступен в .