Cómo Databricks despliega modelos de frontera para 12.000 empleados el primer día

Ofrecer a nuestros empleados acceso a capacidades de AI de vanguardia es una prioridad absoluta en Databricks y, por lo tanto, es importante para nosotros que puedan usar los nuevos modelos de forma instantánea en cuanto estén disponibles. Al mismo tiempo, no es una tarea sencilla dar acceso rápido a un nuevo modelo a más de 12 000 personas porque:

1. Los modelos que se comercializan como de vanguardia a menudo no lo son. Por ejemplo, Opus 5.0 era más costoso y obtuvo una puntuación más baja tanto en las evaluaciones de calidad cuantitativas como cualitativas de nuestros ingenieros en comparación con Opus 4.8. Migrar a un modelo que supone un retroceso en la vanguardia puede perjudicar significativamente a una empresa, en lugar de ayudarla. Según nuestra experiencia, se requiere un cuidado sustancial al evaluar los modelos antes de migrar cargas de trabajo en masa a nuevos modelos.
2. El uso ingenuo de un nuevo modelo puede disparar los costos. Cuando lanzamos GPT Astra para un grupo de control sin mitigaciones de costos asociadas, el desarrollador promedio gastó un 60 % más que antes de tener acceso a Astra. Un aumento repentino del 60 % en los costos de la noche a la mañana con una población de usuarios de más de 10 000 personas es muy difícil de planificar para una empresa. Una vez que entendimos mejor en qué tareas Astra es excepcionalmente bueno, pudimos orientar el uso para reducir sustancialmente los costos generales.

Este artículo analiza un conjunto de técnicas que hemos empleado para dar a la mayoría de los empleados de Databricks acceso desde el primer día a los nuevos modelos, al tiempo que nos permite evaluar si los modelos son realmente herramientas de trabajo fiables a largo plazo. Estas técnicas se basan en gran medida en Unity Gateway para lanzar, evaluar e incorporar nuevos modelos de forma adaptativa. La semana del 21 de septiembre fue una prueba crítica de estas capacidades cuando se lanzaron Opus 5, GPT-6 Sol y GPT-Luna en rápida sucesión. Durante esa semana, Databricks proporcionó a todos los empleados acceso desde el primer día y, para el tercer día, ya habíamos recopilado suficientes datos para confirmar que estos modelos estaban en la frontera de eficiencia, lo que llevó a su incorporación a nuestra infraestructura más amplia.

El ciclo de vida de lanzamiento de modelos

 A grandes rasgos, los lanzamientos de nuevos modelos en Databricks pasan por un proceso que se estructura de la siguiente manera:

1. Poner los nuevos modelos a disposición de todos los empleados de inmediato, de forma "experimental".
2. Limitar el uso de los nuevos modelos en función de un presupuesto por usuario.
3. Después de recopilar suficientes datos, decidir si se promociona el modelo a producción (o incluso si se establece como predeterminado).

Paso 1: Poner los nuevos modelos a disposición de inmediato

Para facilitar la gestión de modelos entre proveedores de modelos abiertos y cerrados, utilizamos nuestro propio Databricks Unity Gateway para todo el uso interno. Este es nuestro centro neurálgico para la gobernanza de AI, la gestión de costos y la observabilidad, por lo que es natural que empecemos aquí.

El Gateway es donde permitimos que todos los empleados accedan al modelo recién lanzado. Sin embargo, la configuración del lado del servidor no es suficiente. Nuestros empleados utilizan Claude Code, Codex y el meta-harness Omnigent en sus computadoras portátiles, y necesitamos distribuirles la configuración del nuevo modelo.

Ahí es donde entra en juego Unity Gateway CLI (UG CLI). UG CLI ya se está ejecutando en la computadora portátil de todos, implementado a través de nuestra gestión de dispositivos móviles. Cada vez que alguien inicia Claude Code, Codex o Omnigent, UG CLI se ejecuta para buscar nuevos modelos, herramientas y habilidades, y actualiza la configuración del harness local. UG también nos permite designar de forma centralizada modelos predeterminados frente a experimentales, preparar modelos para el enrutamiento inteligente y recopilar trazas para evaluar el despliegue de cada modelo.

Configuramos Unity Gateway para enviar configuraciones experimentales para Opus 5.5 y Sol 6. Estos modelos ahora aparecen con esta etiqueta, de modo que los empleados pueden seleccionarlos pero entienden que se trata de un modelo nuevo que puede o no ser el mejor de su clase o permanecer para siempre:

La salida del modelo / Claude Code designa claramente a Ous 5.5 como Experimental

Paso 2: Limitar el uso mediante un presupuesto por usuario

Anteriormente hemos escrito sobre cómo configuramos los presupuestos por usuario para el gasto en AI. Desde entonces, hemos ampliado nuestra arquitectura de presupuesto total para incluir cuatro presupuestos principales, cada uno definido por usuario:

1. Máximo mensual: cada usuario tiene un límite de gasto mensual general para todos los modelos.
2. Límite diario por descontrol: cada usuario tiene un máximo diario, que se puede aumentar directamente en Slack para evitar gastos accidentales debido a una sesión descontrolada.
3. ¡Nuevo! Presupuesto para la frontera de calidad: asignamos una cierta fracción del presupuesto mensual a los modelos más premium en la frontera de calidad, como GPT Astra y Claude Fable. (Fable no está implementado internamente en este momento debido a las políticas de retención de datos de Anthropic, pero estamos trabajando estrechamente para implementar su nueva política). Esto refleja la intención de que estos modelos no se utilicen como herramientas de uso diario, sino que se seleccionen para tareas especializadas para las que son excepcionalmente adecuados, a fin de justificar el aumento de costo de 2 a 3 veces con respecto al siguiente nivel de calidad.
4. ¡Nuevo! Presupuesto experimental: se asigna otra fracción del presupuesto mensual para el uso de modelos nuevos y no probados. Aquí, nuestro objetivo es equilibrar la velocidad de adopción con el riesgo de exponer ampliamente un modelo que no está en la frontera de eficiencia.

El primer día del lanzamiento del modelo, pusimos Opus 5.5 y Sol 6 a disposición de todos los empleados a través de Unity Gateway y los etiquetamos para el presupuesto experimental. Luego, utilizamos los siguientes días para recopilar datos y decidir qué hacer a continuación: quitar la etiqueta de experimental o eliminar el modelo del catálogo que ven nuestros desarrolladores.

Resumen de la configuración del presupuesto, que refleja los cuatro presupuestos

Paso 3: Promocionar o descartar el modelo

Para determinar si el modelo se encuentra en la frontera de eficiencia, nos basamos en tres señales:

1. Datos de benchmark: contamos con un conjunto de benchmarks privados que prueban una serie de tareas, incluidos benchmarks sin conexión (offline) como el razonamiento de documentos, la búsqueda en el espacio de trabajo y nuestro propio producto Genie, así como benchmarks en línea (online) en los que ejecutamos dos modelos en paralelo y comparamos los resultados para la creación de pull requests. Continuamos ampliando y ajustando estos benchmarks; en un mundo ideal, nuestros benchmarks son suficientes para determinar rápidamente el costo y la calidad de cualquier nuevo lanzamiento de modelo.
    
2. Calidad reportada por el usuario: el lanzamiento del modelo experimental proporciona una gran cantidad de datos anecdóticos sobre cómo se sienten las personas con respecto al nuevo modelo. Descubrimos que un grupo de usuarios avanzados está ansioso por probar nuevos modelos y comparar sus experiencias a través de Slack y respuestas a encuestas.
    
3. Seguimiento de costos a través de trazas de OpenTelemetry: Unity Gateway registra todas las trazas en una ubicación central, junto con la información de costos. Podemos comparar cómo gastaron dinero los usuarios piloto en la generación anterior de modelos frente a los modelos más recientes por sesión.  Esto no necesariamente nos indica la calidad, pero nos da una buena medida del costo.

Para Opus 5.5 y Sol 6, las tres métricas nos muestran una historia bastante coherente.

Los benchmarks, como nuestro OfficeQA Pro V2, demuestran que Opus 5.5 se encuentra claramente en la frontera de costo/calidad, lo que representa un gran avance en ambos ejes en comparación con Opus 5. GPT-6 Sol obtiene una puntuación intermedia entre GPT-5.6 Sol y GPT-5.6 Terra tanto en costo como en calidad.

Los informes de los usuarios coinciden ampliamente en que, para las tareas de ingeniería y depuración (la gran mayoría de nuestros primeros usuarios son ingenieros), Opus 5.5 representa un gran salto de calidad con respecto a Opus 5 y Opus 4.8, y su estilo de redacción es muy preferido. Por el contrario, GPT-6 Sol es ocasionalmente inferior en calidad en comparación con GPT-5.6 Sol.

El seguimiento de costos nos permitió comparar el uso de los primeros usuarios con el de ese mismo grupo una semana antes. Mantener la misma cohorte resultó crucial, ya que los primeros usuarios suelen ser usuarios avanzados de IA en lugar de usuarios promedio.

Queríamos normalizar los costos sobre una base de $/sesión, ya que los usuarios que prueban un modelo nuevo a veces aumentan su uso en términos de cantidad de sesiones a medida que experimentan. Descubrimos que usar una comparación básica de $/sesión seguía siendo engañoso porque la distribución de las sesiones también estaba cambiando: los primeros usuarios estaban intentando resolver problemas más difíciles con los nuevos modelos en comparación con su sesión promedio.

Como resultado, estratificamos las sesiones en función de si eran de un solo turno o de varios turnos y de si realizaban alguna edición de archivos, y luego reponderamos la distribución en consecuencia. La siguiente tabla muestra los resultados de Opus 5.5 frente a Opus 4.8 y de GPT-6 Sol frente a GPT-5.6 Sol.

Las cifras de GPT no son muy sorprendentes dado que el precio se redujo en un 50%. Sin embargo, nos complació que Opus 5.5 también represente una reducción de precio significativa para nuestras cargas de trabajo reales, considerando nuestra experiencia previa con Opus 5.

Nuestra decisión

Pudimos ofrecer a los empleados acceso experimental a Opus 5 y GPT-6 Sol y Luna el primer día del lanzamiento del modelo. En un plazo de tres días, recopilamos suficientes datos para confirmar que estos modelos se encontraban en la frontera de eficiencia y decidimos retirarlos del presupuesto experimental para incorporarlos a la circulación estándar como modelos de disponibilidad general.

Durante la próxima semana, daremos un paso más con Opus 5.5 para convertirlo en el modelo predeterminado para Claude Code, dada su clara posición como una opción de mayor calidad y menor costo que sus predecesores.

Nuestra experiencia con GPT-6 Sol sugiere que no reemplazará a GPT-5.6 Sol como el modelo predeterminado para Codex. Sin embargo, incluiremos GPT-6 Sol en el conjunto de herramientas de nuestro enrutador inteligente, dada su ventaja de costo sobre 5.6 Sol. 

En general, descubrimos que esta guía práctica es eficaz para evaluar rápidamente la calidad y el costo de los modelos, lo que nos permite adoptar rápidamente los últimos modelos que demuestren su valor. Esta flexibilidad es más importante que nunca, ya que casi todos los días aparecen modelos nuevos.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original