- Mercury es un nuevo modelo de lenguaje grande (LLM) comercial que utiliza un enfoque de difusión (Diffusion)
- Este modelo se basa en una arquitectura Transformer y se caracteriza por predecir múltiples tokens en paralelo
- Mercury Coder es el primer conjunto de LLMs de difusión, desarrollado para escritura de código, y está disponible en dos tamaños: Mini y Small
- En GPUs NVIDIA H100, registra un rendimiento de 1109 (Mini) y 737 (Small) tokens/segundo, mostrando un desempeño de hasta 10 veces más rápido que los modelos existentes enfocados en velocidad con la misma calidad
- En benchmarks de uso real y evaluaciones de desarrolladores como Copilot Arena, también logró el 2.º lugar en calidad y el mejor rendimiento en velocidad, y además ofrece una API pública y un playground
Descripción general
- Mercury es una nueva serie de modelos de lenguaje grandes basada en difusión (diffusion), una nueva generación de LLMs que operan a escala comercial
- Todos los modelos están parametrizados sobre una arquitectura Transformer y fueron entrenados para predecir varios tokens en paralelo
- Este informe presenta principalmente la primera línea de Mercury Coder, diseñada para aplicaciones de generación de código
- Actualmente, Mercury Coder está disponible en dos tamaños de modelo: Mini y Small
Contribuciones principales
- Mercury Coder alcanza un nuevo nivel state-of-the-art en el equilibrio entre velocidad y calidad
- Según la firma de evaluación externa Artificial Analysis:
- Mercury Coder Mini: 1109 tokens por segundo
- Mercury Coder Small: 737 tokens por segundo en una GPU NVIDIA H100
- Muestra una calidad similar con una velocidad promedio de hasta 10 veces más rápida frente a los modelos frontier más veloces
- También se presentan resultados de evaluación adicionales en benchmarks de código para diversos lenguajes de programación y casos de uso
- En entornos reales de desarrollo (Copilot Arena) también logró:
- 2.º lugar en calidad
- 1.er lugar absoluto en velocidad
- Ofrece una API pública ( platform.inceptionlabs.ai ) y un playground de chat gratuito ( chat.inceptionlabs.ai ) que cualquiera puede usar
Explicación de la estructura del índice
- Introduction (Introducción)
- Contribuciones principales (Contributions)
- Inception Mercury Model Family (explicación de la familia de modelos)
- Proceso de entrenamiento (Training)
- Método de inferencia (Inference)
- Capabilities (capacidades del modelo)
- Rendimiento base (Baselines)
- Capacidades de generación de código (Coding Capabilities)
- Benchmarks de evaluación (Evaluation Benchmarks)
Resumen
- Mercury combina un innovador diseño de LLM basado en difusión con una arquitectura de predicción paralela para lograr una velocidad abrumadora y alta calidad en el campo de la generación de código
- Con modelos de distintos tamaños, sólidos benchmarks en servicios reales y fácil accesibilidad, ofrece una opción competitiva tanto para entornos comerciales como de desarrollo
1 comentarios
Comentarios de Hacker News
Se enfatiza que, cuando se adopten agentes de LLM, el rendimiento de las pruebas llevará a cuellos de botella de CPU aún más graves, y que incluso ahora todos los equipos ya sufren cuellos de botella por la velocidad del CI
Aunque un agente escriba código 100 veces más rápido que una persona, no sirve de mucho si las pruebas tardan una hora
En muchos proyectos en los que trabajé, se desperdiciaba mucho tiempo de desarrolladores esperando a que se reflejaran los cambios, y muchas ejecuciones estaban limitadas por I/O o por falta de workers
Si los agentes de código convierten tickets simples en PR rápidamente y reaccionan en tiempo real a fallas en pruebas para corregirlas, el cuello de botella del CI empeorará aún más
La mayoría de los entornos de pruebas de los proyectos tienen mucho margen de mejora, pero en la práctica se ha normalizado durante años tener CI lento y costos altos sin avances importantes
A veces el CI incluso se vuelve más lento al desactivar el caché para aislar completamente los builds, o al migrar de on-premise a VMs lentas en la nube
La velocidad de Mercury es una locura y, por las veces que lo probé, la calidad y precisión del código fueron excelentes, pero ahora el reto es lograr que la ejecución de pruebas vaya al mismo ritmo
No me termina de convencer la idea de que en la mayoría de los proyectos donde trabajé se desperdicie tiempo de desarrolladores esperando la aprobación de PR
Desde la perspectiva de una empresa, el tiempo de desarrollo cuesta muchísimo más que el tiempo de máquina, así que si hay quejas de los desarrolladores, basta con duplicar los workers de CI
En Google, al depurar inestabilidad en pruebas, a veces se corría una prueba 10 mil veces en 10 mil máquinas para encontrar fallas poco frecuentes
Mi trabajo actual ofrece algo similar: con un solo comando, ejecutamos todas las pruebas en paralelo con 1,000 workers, con el objetivo de obtener feedback en menos de 5 minutos incluso en un proyecto de 1M LOC
Aislar completamente los builds y no usar caché son cosas distintas; la postura es que se debe aislar totalmente el build y al mismo tiempo aprovechar al máximo todos los cachés
Si la velocidad de implementación aumenta, se espera que el cuello de botella se mueva hacia PM, y en ese caso los cambios se procesarán de forma más serial, lo que reduciría mucho los conflictos
También podría darse un resurgimiento de los lenguajes de especificación (como TLA+), ya que los agentes podrían escribirlos y verificarlos rápidamente, reduciendo así la cantidad total de pruebas de integración
Si un agente en segundo plano limpia código duplicado, también podría limpiar pruebas duplicadas
A diferencia de los equipos de ingenieros humanos, la IA parece poder trabajar con más eficiencia en estructuras monolíticas, y eso aumentaría la cobertura de pruebas que se puede correr localmente, reduciendo la flakiness y la carga sobre CI
Aunque la IA aumente la eficiencia, también generará más código, código más rápido y ejecución más rápida, así que seguirán apareciendo nuevos problemas, y estoy seguro de que seguirán surgiendo problemas nuevos que los ingenieros humanos tendrán que resolver
Los LLM están bien para arreglos rápidos de menos de 100 líneas, o como rubber duck, pero meter un LLM directamente en el pipeline de CI de un proyecto grande podría provocar una caída de productividad de cientos de horas
No tiene sentido si, en vez de dedicar tiempo a mejorar la capacidad real de escribir código, uno termina solo ajustando prompts y contexto
Siento que hay demasiada confianza en el tooling de LLM, y creo que no aplica bien a sistemas complejos
Existe una desconfianza extrema hacia la idea de meter LLM sin supervisión en repositorios importantes; “ni apuntándome con un arma”
Al final uno termina rehaciendo a mano la mitad del resultado del LLM, y en ese caso es mejor hacerlo directamente
Antes del automóvil casi no se gastaba en gasolina, aceite o mantenimiento, pero conforme el sistema evoluciona, llega también la infraestructura complementaria y sus costos
Se forma un ciclo donde se resuelven cuellos de botella con IA o se crean más funciones para maximizar ingresos, y con esos ingresos extra se consiguen más recursos de CI
La IA no es muy distinta de contratar a 10 desarrolladores más, así que naturalmente aumentan los costos de soporte
Es una invitación a preguntarse si se puede argumentar lógicamente a favor de conseguir más recursos de CI o proponer una dirección de optimización basada en eficiencia
Me da curiosidad cuánto cuesta cada recurso individual de CI
En una app de Python, tuve la experiencia de acelerar mucho el CI usando el toolchain de astral.sh junto con instalación de paquetes con uv y aprovechando caché
Pronto planeo migrar de mypy al type checker de astral, así que debería ser aún más rápido
En apps con frontend, la parte más lenta probablemente serán las pruebas con Playwright, aunque en otras apps eso ni siquiera aplica
(PD: si Mike es quien creo, lo recuerdo como un SRE con quien trabajé en Google Maps a inicios de los 2000, así que su opinión me inspira confianza)
En el playground de Mercury le pedí un patrón de expresión regular, y el modelo empezó por su cuenta a hacer un plan, escribir el patrón y luego generar pruebas
Pero siguió agregando pruebas sin parar hasta llegar al límite de contexto y la respuesta se cortó
Después de unas 30, empezó a poner mal los comentarios de resultados de prueba, y pasando las 120 las entradas mismas ya eran raras, llenas de caracteres aleatorios
El patrón en sí tampoco era correcto, pero este fenómeno de “bucle infinito” me pareció un problema más interesante
Por cierto, recuerdo que hasta hace muy poco los LLM comunes también hacían este tipo de salidas repetitivas que parecían “casi un bucle infinito”
Quedaban atrapados en patrones donde la salida solo cambiaba un poco cada vez
Creo que este caso es una prueba representativa de que “solo con predicción de tokens no se puede producir código correcto”
La evaluación es que los LLM, desde su diseño, no están hechos para razonar código
Después de leer el informe técnico, confirmé que Mercury está basado en el paper Lou et al. 2023, SEDD
Yo fui el primero (probablemente) en reimplementar SEDD desde cero, código publicado
También implementé personalmente métodos complejos de denoising
Lo diseñé para que fuera más limpio y fácil de leer que el SEDD original, y puede correr en unas cuantas horas sobre un dataset de juguete en una sola GPU
Como referencia, DeepMind también tiene un modelo Gemini basado en diffusion (enlace)
Al probarlo personalmente, me pareció tan ridículamente rápido como Mercury, pero la calidad de las respuestas era bastante inferior frente a otros Gemini
Tras usarlo un poco, coincido en que la velocidad impresiona, pero la tasa de aciertos baja bastante
Me pregunto si el demo de Gemini Diffusion es gratuito
Llevo días en la lista de espera y me da lástima no haber tenido oportunidad de probarlo aún
En lo personal, este tipo de avances me entusiasma muchísimo
Hace poco, en una game jam, programé un juego sencillo con ayuda de IA, y más de la mitad del tiempo se me fue esperando resultados
Si en lugar de esperar 1 o 2 minutos por prompt solo hubiera que esperar 10 segundos, se podrían hacer cinco o diez experimentos en el tiempo que antes tomaba una sola prueba
Mercury todavía no está lo bastante maduro como para usarse de forma práctica, pero Claude 3.0 también era flojo hace un año, así que esto probablemente mejorará
De verdad emociona pensar en lo que viene
Probé el playground de Mercury y la velocidad sí es realmente impresionante
La visualización del diffusion mode también se siente novedosa, aunque en la práctica parece mostrar cómo se va refinando desde ruido lineal visualizado hacia un estado cada vez más preciso
En la práctica, lo veo como un proceso donde en un espacio vectorial arbitrario se converge gradualmente hacia tokens más definidos
Algunos modelos de diffusion para texto usan un latent space continuo, pero su rendimiento no suele ser muy bueno
Últimamente la mayoría se enfoca en predecir salidas de tokens reales y, paso a paso, corregir valores previos hasta converger al resultado final
Recomiendo este enlace donde explico cómo funciona la diffusion de texto
Enlace: https://chat.inceptionlabs.ai/
De verdad se siente absurdamente rápido
En la mayor parte del código cercano al GPU todavía hay muchísimo margen de optimización de rendimiento
Pero se cuestiona si el paper en arXiv es investigación real o más bien marketing
Se agradecen otras opiniones
Política de precios del modelo Mercury
1 dólar por cada millón de tokens de salida, 0.25 dólares por cada millón de tokens de entrada
Para más detalles de precios, ver aquí
En casos sensibles al rendimiento, al comparar Mercury con Groq (Llama 3.1 8b, Llama 4 Scout), el desempeño fue parecido pero el precio de Groq resultó mucho más favorable
Estoy atento con interés a la aparición de modelos de diffusion open source
En el código del playground y en la respuesta de la API aparecen
gpt-3.5-turboy"openai": true, así que surge la duda de si en realidad llaman a OpenAI en vez de usar su propio dLLMLa función de diffusion effect en la esquina superior derecha parece una simple animación
Todo suena muy bien, pero
si envías publicaciones de usuario al servicio, los términos le otorgan a Inception una licencia global, no exclusiva, perpetua, libre de regalías, gratuita y totalmente transferible
Es decir, pueden usar el contenido de los usuarios para entrenar modelos de IA
(Aunque hay una excepción: las solicitudes que entren por OpenRouter no se usan para entrenamiento)