De pipelines en cascada a multimodalidad nativa

¿Cómo funcionaban los asistentes de voz antes de 2024? La respuesta es una cascada de tres etapas: un modelo de habla a texto (STT) transcribe el audio del usuario a texto, un gran modelo de lenguaje (LLM) razona sobre ese texto y produce una respuesta textual, y un modelo de texto a habla (TTS) sintetiza la respuesta de vuelta a audio. Tres modelos separados, tres pasos de latencia y tres fronteras donde se pierde información. El modelo STT elimina prosodia, emoción, vacilación, risa y tono cuando convierte habla a una cadena plana de texto. El LLM nunca ve ninguna de esa señal paralingüística. Y el modelo TTS debe inventar una entrega plausible desde cero, sin conocimiento de cómo sonaba el usuario o qué registro emocional sería apropiado. El resultado es funcional pero robótico: un sistema que puede responder preguntas pero no puede verdaderamente conversar.

Consideremos un ejemplo concreto. Un usuario dice «Estoy bien» en un tono tembloroso y sarcástico. El modelo STT produce fielmente el texto Estoy bien . El LLM ve esas dos palabras, las toma al pie de la letra y responde con algo alegre. El sarcasmo, el temblor, el subtexto emocional — todo perdido en la primera frontera. Un oyente humano detectaría inmediatamente la discrepancia entre palabras y entrega. Un sistema en cascada no puede, porque el cuello de botella de texto descarta todo lo que hace expresivo al habla.

El nuevo paradigma es el modelo omni (a veces llamado modelo nativamente multimodal ): una sola red neuronal que procesa audio, texto y frecuentemente visión como secuencias de tokens intercaladas. En lugar de traducir entre modalidades en cada frontera, el modelo opera sobre una representación unificada donde características acústicas, contenido lingüístico e información visual coexisten en el mismo espacio de embeddings. El sarcástico «Estoy bien» llega como tokens de audio que llevan tanto las palabras como el tono, y el modelo razona sobre ambos simultáneamente.

¿Por qué importa esto más allá de la conveniencia? Porque el matiz emocional, la identidad del hablante, el ruido de fondo, el cambio de código entre idiomas y la dinámica conversacional como interrupciones y retroalimentación están todos codificados en la señal acústica. Una transcripción de texto es una compresión con pérdida que descarta la mayoría de esto. La multimodalidad nativa lo preserva. La idea clave es que la comprensión multimodal requiere representación unificada, no traducción secuencial entre modalidades . Tal como los modelos visión-lenguaje demostraron que proyectar características de imagen a un espacio de embeddings compartido con texto produce comprensión más rica que describir imágenes y alimentar las descripciones a un LLM, los modelos omni demuestran el mismo principio para audio: mantener la señal cruda intacta permite al modelo aprender correlaciones cross-modales que ninguna cascada puede capturar.

💡 El argumento de latencia es igualmente importante. Un pipeline en cascada añade la latencia de los tres modelos secuencialmente: STT (200-500ms) + generación LLM (500-2000ms) + TTS (200-500ms) = aproximadamente 1-3 segundos antes de que el primer token de audio llegue al usuario. Un modelo omni de extremo a extremo puede comenzar a transmitir audio de salida mientras aún procesa la entrada, reduciendo la latencia del primer token a 200-320ms — cercano a la pausa de ~200ms en la conversación humana natural.

GPT-4o y GPT-5: La frontera comercial

Cuando OpenAI lanzó GPT-4o en mayo de 2024, marcó la primera vez que un modelo comercial importante procesaba nativamente texto, audio y visión dentro de una sola red neuronal (OpenAI, 2024) . Las iteraciones anteriores de ChatGPT voice usaban el enfoque en cascada: Whisper para STT, GPT-4 para razonamiento, y un modelo TTS separado para la salida. GPT-4o colapsó los tres en un modelo autorregresivo que opera sobre flujos de tokens intercalados de texto, audio e imagen. La diferencia más inmediatamente notable fue la latencia — GPT-4o promediaba 320 milisegundos de tiempo de respuesta, comparable a una pausa conversacional humana, versus el retraso de varios segundos del pipeline en cascada.

OpenAI no ha publicado los detalles arquitectónicos de GPT-4o, pero su comportamiento revela varias propiedades. Puede cantar, reír, susurrar y modular el tono emocional en tiempo real, lo que requiere que el modelo tenga control directo sobre la generación acústica en lugar de delegar a un sistema TTS separado. Maneja cambio de código entre idiomas dentro de una sola expresión. Y razona sobre contenido de audio (identificando hablantes, describiendo sonidos, transcribiendo música) y contenido visual (describiendo imágenes, leyendo texto) dentro de la misma pasada. La «o» en GPT-4o significa «omni», y el modelo está a la altura del nombre: acepta cualquier combinación de entradas de texto, audio e imagen y puede producir salidas de texto y audio.

En septiembre de 2025, OpenAI introdujo gpt-realtime , un modelo dedicado de habla a habla de extremo a extremo optimizado para uso conversacional en tiempo real. A diferencia de un pipeline que une STT y TTS alrededor de un modelo de texto, gpt-realtime es un solo modelo de audio-entrada a audio-salida, construido específicamente para interacción por voz. Obtuvo 82.8% en Big Bench Audio, comparado con 65.6% del modelo anterior, demostrando comprensión de audio sustancialmente más fuerte. El modelo captura señales no verbales, cambia de código a mitad de oración, adapta el tono al registro emocional de la conversación y soporta sesiones de hasta 60 minutos — suficiente para una lección completa de tutoría o sesión de terapia.

Luego, en agosto de 2025, llegó GPT-5 como un modelo nativamente multimodal entrenado desde cero sobre texto, imagen, audio y video simultáneamente. Mientras GPT-4o añadió capacidades de audio y visión a lo que era fundamentalmente un modelo de texto, GPT-5 fue diseñado desde el principio con todas las modalidades como ciudadanos de primera clase. La distinción importa arquitectónicamente: en lugar de aprender texto primero y luego alinear otras modalidades a la representación de texto (el enfoque usado por la mayoría de los modelos multimodales de código abierto), las representaciones de GPT-5 son inherentemente cross-modales desde las capas más tempranas. OpenAI reportó que esto lleva a un razonamiento cross-modal más fuerte — el modelo puede, por ejemplo, escuchar una pregunta sobre una imagen mientras mira un video y producir una respuesta hablada que referencia las tres entradas coherentemente.

💡 La progresión de GPT-4o a GPT-5 ilustra una tendencia más amplia: los modelos omni están evolucionando de «modelo de texto con adaptadores multimodales» a «nativamente multimodal desde el primer token de pre-entrenamiento». Este cambio es paralelo a la evolución en modelos visión-lenguaje desde enfoques de codificador congelado hacia entrenamiento conjunto de extremo a extremo.

Gemini: El enfoque multimodal de Google

La familia Gemini de Google (Gemini Team, 2023) tomó un camino diferente hacia la multimodalidad nativa. Desde el artículo original de Gemini 1.0, la arquitectura era un transformer solo-decodificador entrenado conjuntamente en todas las modalidades desde el inicio . Los datos de texto, imagen, audio y video se intercalaron durante el pre-entrenamiento, por lo que el modelo aprendió asociaciones cross-modales desde sus primeros pasos de entrenamiento en lugar de adquirirlas mediante ajuste fino posterior. La entrada de audio se procesaba a través de características del Universal Speech Model (USM) de Google, que convertía audio crudo en una secuencia de tokens de características acústicas que podían intercalarse con tokens de texto e imagen en la misma ventana de contexto.

La fortaleza técnica definitoria de Gemini siempre ha sido su longitud de contexto. Gemini 1.5 Pro soportaba una ventana de contexto de 1 millón de tokens, y las versiones posteriores fueron aún más lejos. Para el procesamiento de audio, esto es transformador: un millón de tokens pueden acomodar horas de audio, lo que significa que el modelo puede procesar un podcast, conferencia o grabación de reunión completos en una sola pasada sin fragmentar. Esto elimina los problemas de recuperación y costura que afectan a los modelos de contexto más corto cuando manejan audio largo.

En 2025, Google lanzó Gemini 2.5 con salida de audio nativa , finalmente cerrando el circuito de audio-entrada a audio-salida dentro de un solo modelo de baja latencia — sin pipeline STT o TTS separado necesario. Las capacidades de audio nativas incluyen TTS multi-hablante (el modelo puede producir dos voces distintas en la misma respuesta, habilitando generación de diálogo), un modo de audio proactivo que filtra inteligentemente habla de fondo y ruido para enfocarse en el hablante principal, y soporte para más de 24 idiomas con cambio de código fluido — el modelo puede comenzar una oración en inglés y terminarla en mandarín sin ninguna señal de cambio de modo.

El enfoque de Gemini hacia el audio difiere del de OpenAI principalmente en su énfasis en el procesamiento de contexto largo y la profundidad de su pre-entrenamiento conjunto. Mientras GPT-4o y GPT-5 optimizan fuertemente para latencia conversacional en tiempo real, la fortaleza de Gemini está en su capacidad de razonar sobre entradas de audio muy largas — un audiolibro completo, una reunión de varias horas — y producir respuestas coherentes que referencian momentos específicos a lo largo de toda la grabación.

Qwen2.5-Omni y Qwen3-Omni: El estado del arte de código abierto

Mientras GPT-4o y Gemini avanzaban la frontera comercial, la frontera de código abierto estaba siendo empujada con igual agresividad por el equipo Qwen de Alibaba. Qwen2.5-Omni (Xu et al., 2025) , lanzado en marzo de 2025, introdujo una novedosa arquitectura Thinker-Talker que separa limpiamente el razonamiento de la generación de habla. ¿Por qué la separación? Porque generar texto de alta calidad y habla de alta calidad simultáneamente desde un solo decodificador crea interferencia: el objetivo de generación de texto empuja al modelo hacia precisión lingüística, mientras que el objetivo de generación de habla empuja hacia naturalidad acústica, y optimizar para ambos a la vez degrada cada uno. La arquitectura Thinker-Talker permite que cada componente se enfoque en su fortaleza.

El Thinker es la columna vertebral LLM principal aumentada con codificadores específicos de modalidad para audio y visión. Recibe tokens de audio (de un codificador basado en Whisper), tokens de imagen (de un codificador de visión) y tokens de texto, los procesa a través de un transformer estándar y produce salida de razonamiento en texto — la parte de «pensar». El Talker es un decodificador separado y más pequeño que recibe las representaciones ocultas del Thinker como entrada de condicionamiento y genera tokens de audio en streaming, que luego se convierten en formas de onda por un vocoder Diffusion Transformer (DiT) . El Thinker razona; el Talker habla. La información fluye del Thinker al Talker pero no al revés, creando una dependencia direccional limpia.

Una contribución técnica clave de Qwen2.5-Omni es TMRoPE (Time-aligned Multimodal Rotary Position Embedding) . En los transformers estándar, las codificaciones posicionales simplemente cuentan tokens secuencialmente. Pero el audio y el video llegan a diferentes resoluciones temporales — el audio podría producir 25 tokens por segundo mientras el video produce 2 tramas por segundo. TMRoPE asigna codificaciones posicionales basadas en marcas temporales del mundo real en lugar de posición de token, asegurando que un token de audio en $t = 3.5$ segundos y una trama de video en $t = 3.5$ segundos reciban codificaciones posicionales similares. Este alineamiento temporal permite al modelo aprender correspondencias audio-visuales precisas: movimientos labiales sincronizados con fonemas, gestos temporizados con énfasis en el habla, y sonidos ambientales emparejados con eventos visuales.

En septiembre de 2025, el equipo Qwen lanzó Qwen3-Omni (Xu et al., 2025) , una actualización arquitectónica importante. Qwen3-Omni usa una arquitectura de Mezcla de Expertos (MoE) con 30 mil millones de parámetros totales pero solo 3 mil millones activos por token — una relación de dispersión de 10:1 que mantiene manejable el costo de inferencia mientras proporciona enorme capacidad del modelo. Este diseño MoE significa que diferentes sub-redes de expertos pueden especializarse en diferentes modalidades o tareas sin interferir entre sí, lo cual es particularmente valioso para un modelo omni que debe manejar entradas tan diversas.

Quizas el cambio más significativo en Qwen3-Omni es el reemplazo de Whisper con un nuevo codificador AuT (Audio Transformer) entrenado desde cero con 20 millones de horas de datos de audio. Whisper, aunque excelente para transcripción, fue entrenado principalmente con datos con predominancia de inglés y un objetivo de transcripción. AuT fue diseñado específicamente para las necesidades del modelo omni: comprensión de audio multilingual (no solo transcripción), reconocimiento de música y eventos sonoros, diarización de hablantes y detección de emociones. Los resultados hablan por sí mismos — Qwen3-Omni logró rendimiento de última generación en 32 de 36 benchmarks de audio, superando tanto a Gemini 2.5 Pro como a GPT-4o en tareas de comprensión de audio.

En diciembre de 2025, se lanzó una variante ligera Qwen3-Omni-Flash , dirigida a escenarios de despliegue donde la capacidad completa del modelo no es necesaria. La variante Flash intercambia algo de rendimiento en benchmarks por latencia y requisitos de memoria sustancialmente menores, haciendo accesibles las capacidades del modelo omni en hardware más modesto.

💡 El patrón Thinker-Talker es una forma de separación arquitectónica de responsabilidades. Hace eco de la filosofía de diseño detrás de los modelos codificador-decodificador, donde el codificador construye una representación rica y el decodificador la traduce a la modalidad de salida. La diferencia es que tanto el Thinker como el Talker son decodificadores autorregresivos — el Thinker es un LLM que produce texto, y el Talker es un LLM más pequeño que produce tokens de habla — conectados por un puente de atención cruzada.

Moshi: Diálogo hablado full-duplex

Todos los modelos discutidos hasta ahora — GPT-4o, Gemini, Qwen-Omni — comparten una suposición fundamental: la conversación es por turnos. El usuario habla, el modelo escucha, el modelo responde y luego espera al usuario de nuevo. Pero la conversación humana real no es nada como esto. Los humanos se superponen, interrumpen, retroalimentan («ajá», «claro», «mm-hmm»), y las vocalizaciones del oyente no son ruido a filtrar — son una parte esencial de la dinámica conversacional. Moshi (Defossez et al., 2024) , desarrollado por Kyutai Labs, es el primer modelo fundacional de habla-texto diseñado desde cero para diálogo full-duplex en tiempo real — lo que significa que puede escuchar y hablar simultáneamente, tal como lo hacen los humanos.

La arquitectura de Moshi tiene tres componentes que trabajan juntos. El primero es Helium , un LLM de texto de 7 mil millones de parámetros que sirve como columna vertebral lingüística. Helium fue pre-entrenado con datos de texto y proporciona el conocimiento del mundo y las capacidades de razonamiento que el sistema necesita. El segundo componente es Mimi , un codec de audio neuronal streaming que comprime habla en tokens discretos a solo 12.5 Hz (12.5 tramas por segundo, cada trama abarcando 80ms de audio). Mimi produce tokens en dos niveles: tokens semánticos que capturan qué se está diciendo (contenido lingüístico, identidad del hablante, emoción) y tokens acústicos que capturan cómo suena (contorno de tono, acústica de la sala, timbre fino). Esta separación semántica-acústica se logra destilando un modelo de habla autosupervisado (como WavLM) en el primer codebook mientras los codebooks restantes aprenden residuales acústicos.

El tercer y más novedoso componente es el RQ-Transformer (Residual Quantization Transformer) , que consiste en dos transformers anidados. El Temporal Transformer procesa la secuencia de pasos temporales — ve una representación agregada por trama de 80ms y modela las dependencias temporales a lo largo de la conversación. El Depth Transformer opera dentro de cada paso temporal, generando autorregresivamente los múltiples niveles de codebook para esa trama. En cada paso temporal, el Temporal Transformer produce un vector de contexto, y el Depth Transformer lo usa para generar: primero un token de texto, luego el token de audio semántico, luego los tokens de audio acústicos a través de múltiples niveles de codebook. Este diseño de dos niveles evita el costo cuadrático de tratar todos los tokens de codebook como una secuencia plana (lo que multiplicaría la longitud de secuencia por el número de codebooks).

La innovación revolucionaria de Moshi es el Monólogo Interior : en cada paso temporal, el modelo predice una cadena de token de texto \to token de audio semántico \to tokens de audio acústicos . Los tokens de texto están alineados temporalmente con el habla usando marcas de tiempo a nivel de palabra — cuando Moshi está produciendo audio para la palabra «hola», el token de texto correspondiente «hola» se genera en el mismo paso temporal, con tokens PAD llenando los espacios entre palabras donde no se necesita un nuevo token de texto. Esta cadena sirve como un «monólogo interior» que mejora dramáticamente la calidad lingüística. Sin él, el modelo debe aprender lenguaje puramente de tokens de audio, lo cual es mucho más difícil que aprender de texto. Con él, el canal de texto actúa como un andamiaje que guía la generación de audio hacia lenguaje coherente y bien formado.

Una consecuencia elegante del Monólogo Interior es que habilita capacidades emergentes sin ningún entrenamiento adicional. Si muestreas solo los tokens de texto de la salida de Moshi, obtienes reconocimiento automático de habla (ASR) en streaming. Si alimentas tokens de texto antes de los tokens de audio, obtienes texto a habla (TTS) en streaming. Estos no son modos separados — surgen naturalmente de la generación conjunta de tokens texto-audio del modelo.

La elección de diseño más radical de Moshi es la generación multi-flujo full-duplex . En cada paso temporal, el modelo produce tokens tanto para su propio habla como para el habla del usuario — simultáneamente. Concretamente, cada paso temporal involucra 17 sub-secuencias: 1 token de texto (Monólogo Interior) + 8 niveles de codebook para el audio propio de Moshi + 8 niveles de codebook para el audio del usuario. El modelo no solo genera su respuesta — también predice lo que el usuario está diciendo, lo que significa que mantiene un modelo interno de ambos lados de la conversación en todo momento. No hay mecanismo explícito de turnos. Si el usuario interrumpe, el modelo ve que los tokens de audio del usuario cambian de silencio a habla y puede reaccionar inmediatamente, ajustando o deteniendo su propia generación. Si el usuario retroalimenta («ajá»), el modelo lo reconoce como reconocimiento en lugar de interrupción y continúa hablando.

El resultado es latencia notablemente baja: 160ms teóricos (limitado por el tamaño de trama del codec de 80ms y una trama de anticipación) y aproximadamente 200ms en la práctica. Esto es más rápido que el tiempo de reacción conversacional humano (típicamente 200-300ms), haciendo que Moshi se sienta genuinamente responsivo en diálogo en tiempo real.

En marzo de 2025, MoshiVis extendió Moshi con un codificador de visión, añadiendo la capacidad de ver y discutir contenido visual mientras mantiene capacidades de habla en tiempo real. Los tokens de visión se intercalan con los tokens de audio y texto en la misma secuencia, y el modelo puede referenciar lo que ve en sus respuestas habladas — por ejemplo, describiendo objetos en una transmisión de cámara en vivo mientras mantiene una conversación fluida.

💡 Moshi es arquitectónicamente el modelo más interesante en este espacio. Mientras otros modelos omni tratan el audio como «otra modalidad a añadir», Moshi replantea fundamentalmente cómo un modelo debe participar en una conversación. El diseño de doble flujo (modelando ambos hablantes simultáneamente), el Monólogo Interior (texto como andamiaje para audio), y el RQ-Transformer (factorizando tiempo y profundidad) son cada uno individualmente novedosos, y su combinación produce un sistema que maneja habla superpuesta, interrupciones y retroalimentación de formas que ningún modelo por turnos puede.

LongCat y la frontera en expansión

Más allá de las principales familias de modelos descritas arriba, 2025 vio una explosión de modelos omni especializados empujando los límites en diferentes direcciones. Cada uno aborda una limitación específica de las arquitecturas anteriores, y juntos mapean la frontera en expansión de lo que los modelos omni pueden hacer.

El LongCat-Flash-Omni de Meituan (noviembre 2025) es un modelo omni de escala masiva con 560 mil millones de parámetros totales pero solo 27 mil millones activos por token, usando una arquitectura de Mezcla de Expertos Escalable (ScMoE) con expertos de computación cero — slots de expertos que existen en la tabla de enrutamiento pero no requieren FLOPs cuando son seleccionados, actuando como una forma de regularización implícita. LongCat-Flash-Omni usa Multi-Head Latent Attention (MLA) , la variante de atención introducida por DeepSeek que comprime la KV cache proyectando claves y valores a un espacio latente de baja dimensión antes de cachear. Esto es crítico a la escala de LongCat: con una ventana de contexto de 128K tokens que soporta más de 8 minutos de interacción audio-visual en tiempo real, una KV cache sin comprimir sería prohibitivamente grande. El modelo también emplea detokenización de audio multi-codebook a resolución temporal más gruesa — en lugar de generar tokens de audio a la tasa completa de 12.5 Hz usada por el codec Mimi de Moshi, LongCat genera tokens a una tasa más gruesa y hace upsampling, intercambiando una pequeña cantidad de fidelidad de audio por longitud de secuencia sustancialmente menor y por lo tanto generación más rápida.

InteractiveOmni (2025) toma un enfoque diferente, apuntando al rango de parámetros de 4B-8B con una arquitectura unificada para interacción audio-visual multi-turno. Donde LongCat va en grande con MoE, InteractiveOmni se mantiene pequeño y denso, optimizando para despliegue en dispositivos de consumo. El modelo procesa audio, video y texto en turnos intercalados y puede mantener diálogo coherente a través de múltiples intercambios, rastreando referentes entre modalidades («el auto rojo que mencionaste» + gesto señalando en video + clarificación hablada).

El EVI 3 de Hume AI (2025) empuja la frontera de inteligencia emocional. EVI 3 es un modelo de habla a habla específicamente optimizado para empatía y sintonía emocional. En evaluaciones humanas, fue calificado más alto que GPT-4o en empatía, comprensión emocional y naturalidad conversacional. El modelo modela explícitamente el estado emocional del usuario a partir de señales vocales — velocidad del habla, variación de tono, respiración, micro-pausas — y ajusta su propia entrega vocal en consecuencia. Si un usuario suena ansioso, EVI 3 reduce la velocidad, suaviza su tono y usa frases más tranquilizadoras. Si suenan emocionados, iguala su energía. Este reflejo emocional no es guionado — emerge del entrenamiento con datos de conversación humana a gran escala con anotaciones de emoción.

La tendencia a través de todos estos modelos es clara: los modelos omni simultáneamente se están volviendo más pequeños (arquitecturas MoE con altas relaciones de dispersión mantienen manejables los conteos de parámetros activos), más rápidos (arquitecturas streaming con latencia sub-200ms), y más conscientes emocionalmente (modelado explícito de prosodia, afecto y dinámica conversacional). El pipeline en cascada STT-LLM-TTS que dominó la IA de voz durante una década está siendo reemplazado no por una arquitectura sino por un ecosistema diverso de modelos multimodales nativos, cada uno explorando un punto diferente en el espacio de diseño.

El panorama arquitectónico

Con tantos modelos ahora en el espacio omni, vale la pena dar un paso atrás y mapear el panorama arquitectónico. La tabla a continuación resume los principales modelos omni a finales de 2025, comparando sus características clave. 

import json, js

rows = [
    ["GPT-4o",            "OpenAI",   "May 2024",  "Undisclosed",        "Text, Audio, Image",         "Text, Audio",         "Native autoregressive",      "~320ms",   "No"],
    ["gpt-realtime",      "OpenAI",   "Sep 2025",  "Undisclosed",        "Audio",                      "Audio, Text",         "End-to-end speech-to-speech", "~200ms",  "No"],
    ["GPT-5",             "OpenAI",   "Aug 2025",  "Undisclosed",        "Text, Audio, Image, Video",  "Text, Audio",         "Native joint pretraining",   "Undisclosed", "No"],
    ["Gemini 2.5",        "Google",   "2025",      "Undisclosed",        "Text, Audio, Image, Video",  "Text, Audio",         "Joint pretraining + USM",    "~300ms",   "No"],
    ["Qwen2.5-Omni",      "Alibaba",  "Mar 2025",  "~7B",               "Text, Audio, Image, Video",  "Text, Audio",         "Thinker-Talker + DiT",       "~300ms",   "Yes"],
    ["Qwen3-Omni",        "Alibaba",  "Sep 2025",  "30B total / 3B active", "Text, Audio, Image, Video", "Text, Audio",       "Thinker-Talker + MoE",       "~200ms",   "Yes"],
    ["Moshi",             "Kyutai",   "Oct 2024",  "7B",                 "Audio",                      "Audio, Text",         "RQ-Transformer + Mimi",      "~200ms",   "Yes"],
    ["MoshiVis",          "Kyutai",   "Mar 2025",  "~8B",               "Audio, Image",               "Audio, Text",         "RQ-Transformer + vision",    "~200ms",   "Yes"],
    ["LongCat-Flash-Omni","Meituan",  "Nov 2025",  "560B total / 27B active", "Text, Audio, Image, Video", "Text, Audio",    "ScMoE + MLA",                "~250ms",   "Partial"],
    ["EVI 3",             "Hume AI",  "2025",      "Undisclosed",        "Audio",                      "Audio",               "Speech-to-speech",           "~200ms",   "No"],
]

js.window.py_table_data = json.dumps({
    "headers": ["Model", "Org", "Date", "Params", "Input Modalities", "Output Modalities", "Audio Approach", "Latency", "Open Source"],
    "rows": rows
})

print("Major omni models as of late 2025.")
print(f"Total models surveyed: {len(rows)}")
print(f"Open-source or partially open: {sum(1 for r in rows if r[-1] in ('Yes', 'Partial'))}")

Mirando a través de estos modelos, han emergido tres patrones arquitectónicos distintos para construir modelos omni, cada uno con diferentes compromisos:

Patrón 1: Codificador + LLM. Este es el enfoque más simple, usado por modelos anteriores como Qwen-Audio y Qwen2-Audio: un codificador de audio (típicamente Whisper) proyecta características de audio al espacio de embeddings del LLM a través de una proyección lineal o pequeña red adaptadora, y el LLM procesa los embeddings de audio junto con tokens de texto. Este es esencialmente el mismo enfoque usado por los modelos visión-lenguaje para entradas de imagen. La ventaja es la simplicidad — puedes tomar cualquier LLM pre-entrenado y cualquier codificador de audio pre-entrenado y conectarlos con mínimos parámetros nuevos. La limitación es que esta arquitectura es solo de entrada para audio : el modelo puede entender habla pero no puede generarla. Aún necesitas un modelo TTS separado para salida de audio, lo que significa que vuelves a una cascada parcial para aplicaciones habla a habla.

Patrón 2: Thinker-Talker. Usado por Qwen2.5-Omni y Qwen3-Omni, este patrón separa el modelo en un componente de razonamiento (el Thinker, un LLM completo que produce texto) y un componente de generación de habla (el Talker, un decodificador más pequeño que convierte las representaciones del Thinker en tokens de audio). La ventaja clave es la separación limpia de responsabilidades : el Thinker puede evaluarse y mejorarse usando benchmarks de texto estándar, y el Talker puede evaluarse con métricas de calidad de habla, sin que los dos objetivos interfieran. La desventaja es que el Talker añade latencia (debe esperar representaciones del Thinker antes de generar habla) y el flujo direccional del Thinker al Talker significa que el modelo no puede usar fácilmente características acústicas para informar su razonamiento — el pensamiento ocurre en el espacio del texto.

Patrón 3: Multi-Flujo Unificado. Usado por Moshi (y probablemente GPT-4o), este patrón trata todas las modalidades como tokens intercalados en un solo modelo autorregresivo sin separación entre comprensión y generación. El modelo simultáneamente lee audio de entrada, produce audio de salida y genera texto como un «monólogo interior». Esta es la arquitectura más elegante — no hay capas adaptadoras, no hay codificadores separados, no hay restricciones direccionales — pero también es la más difícil de entrenar . El modelo debe aprender lenguaje, acústica, dinámica conversacional y síntesis de audio todo a la vez, desde un objetivo de entrenamiento unificado. Lograr que esto funcione bien requirió las cuidadosas innovaciones de Moshi: el codec Mimi (para mantener manejable la tasa de tokens de audio), el RQ-Transformer (para factorizar tiempo y profundidad), y el Monólogo Interior (para andamiar la calidad lingüística con tokens de texto).

Varias preguntas abiertas permanecen. ¿Dominará un solo patrón, o coexistirán para diferentes casos de uso (Thinker-Talker para asistentes de alta precisión, Multi-Flujo Unificado para conversación en tiempo real)? ¿Podemos lograr conversación full-duplex con la calidad de Moshi a la escala de Qwen3-Omni? ¿Pueden los modelos omni de código abierto igualar o superar el razonamiento cross-modal de GPT-5? Y a medida que las ventanas de contexto crecen a millones de tokens, ¿seguirán siendo necesarios los codificadores de audio especializados, o los modelos de extremo a extremo aprenderán a procesar formas de onda crudas directamente? El espacio de los modelos omni está evolucionando más rápido que cualquier otra área en IA, y la cuestión arquitectónica está lejos de resolverse.

Quiz

Pon a prueba tu comprensión de las arquitecturas de modelos omni y sus compromisos de diseño.

¿Cuál es la principal limitación de un pipeline en cascada STT → LLM → TTS comparado con un modelo omni nativo?

¿Qué es el mecanismo de 'Monólogo Interior' de Moshi?

¿Por qué Qwen2.5-Omni usa una separación Thinker-Talker en lugar de un solo modelo unificado?

¿Qué hace fundamentalmente diferente al enfoque full-duplex de Moshi de otros modelos omni?