AlloyDB Entrena Modelos Locales Dentro de PostgreSQL para Ganancias de Velocidad de 23,000×

AlloyDB ha integrado la inferencia generalizada de LLM dentro de la base de datos en PostgreSQL 17, convirtiendo su conjunto de funciones de IA en disponibilidad general con una capa de inteligencia en lotes lista para producción que Google mide como 2,400 veces más rápida que las llamadas de API fila por fila. La aceleración de vista previa más profunda, un modelo proxy local optimizado para `ai.if`, puede evaluar filtros semánticos a 100,000 filas por segundo—23,000 veces más rápido que llamadas remotas por fila y 6,000× más barato en las pruebas internas de Google—al destilar un modelo de vanguardia Vertex AI en un sustituto ultraligero que se ejecuta a la velocidad de la base de datos.

La versión GA de las funciones de IA de AlloyDB en PostgreSQL 17 introduce funciones SQL como `ai.generate`, `ai.summarize`, `ai.agg_summarize`, `ai.analyze_sentiment`, `ai.if`, `ai.rank`, y `ai.forecast`. Se atribuye la mejora en el rendimiento a dos capas de aceleración. El lote inteligente, disponible para `ai.if` y `ai.rank`, agrupa filas en una sola llamada, reduciendo el número de avisos del sistema de por fila a una vez; Google informa que esto es de 10,000 filas por segundo. El cambio arquitectónico más profundo es el modelo proxy optimizado, en vista previa para `ai.if`, que utiliza una declaración `PREPARE` para muestrear datos de la tabla, se lo envía a un modelo de vanguardia en Vertex AI y entrena un modelo local ultraligero dentro de la base de datos. Las consultas se ejecutan entonces contra este proxy a la velocidad de la base de datos, con AlloyDB revirtiendo al LLM remoto cuando la confianza del proxy cae por debajo de un umbral establecido.

AlloyDB complementa estas funciones con su índice vectorial ScaNN, que escala más allá de 10 mil millones de vectores y afirma ser 6× más rápido en consultas puras de vector y 10× más rápido en búsquedas filtradas que el estándar PostgreSQL HNSW. También incluye un servidor MCP completamente administrado, permitiendo que los agentes consulten contenido sobre el Protocolo de Contexto del Modelo sin la necesidad de que los equipos administren su propia infraestructura. Estas características no están habilitadas de forma predeterminada; se debe activar la bandera `google_ml_integration.enable_ai_function_acceleration`.

Los beneficios operativos son significativos para el filtrado de alta cardinalidad, ya que la base de datos se convierte en la superficie de inferencia, reduciendo la necesidad de 100,000 viajes de ida y vuelta a Vertex AI para una tabla de productos. Sin embargo, no hay cargas de trabajo de producción independientes que hayan validado estas cifras; los múltiplos titulares—23,000× de rendimiento y reducción de costos de 6,000×—provienen de las pruebas internas de Google en comparación con una línea de base fila por fila y se aplican solo a `ai.if` en vista previa, no al catálogo de funciones de IA más amplio. Google no ha divulgado costos absolutos por token, latencias p50 o p99 para la ruta de retroceso, horas de GPU necesarias durante `PREPARE`, o la arquitectura del modelo proxy subyacente, describiéndolo solo como "optimizado en costos" y "ultraligero".

Los riesgos de despliegue incluyen gobernanza y latencia, además de precisión. El arquitecto de Starburst Raimundas Juodvalkis sugiere tratar estas funciones como extensiones de base de datos gobernadas y aconseja a los equipos que comiencen con flujos de trabajo de revisión pesados en lectura antes de integrar campos derivados del modelo de vuelta en sistemas centrales, y que rastreen el costo del modelo por separado del costo de la consulta. El mecanismo de retroceso significa que la latencia p99 sigue vinculada a la llamada más lenta a Vertex AI en cualquier lote. También falta la medición de las pistas de proxy versus maestro por dominio, lo que requiere la construcción de paquetes de regresión personalizados por parte de los arquitectos. Competidores como Aurora, Azure SQL, CockroachDB y PlanetScale aún no han enviado capacidades comparables de destilación en tiempo de consulta, lo que hace que este sea un ciclo de entrenamiento y servicio específico de Google con portabilidad limitada.

El mensaje clave es la posibilidad de destilar predicados semánticos de gran volumen en un modelo sustituto local que opera a la velocidad de la base de datos, evitando tarifas de API por fila—previa la medición de la deriva de precisión del modelo.