Inférencia más allá del texto: Ajuste de VLMs, embeddings, voz, imagen y video
Cada modalidad tiene su propio cuello de botella. Aprenda cómo ajustar los VLM, los embeddings, la ASR, la TTS y los generadores de imágenes y videos mediante el uso adecuado de agrupamiento, kernels, caché y cuantización.
Acelerar un modelo de lenguaje basado únicamente en texto es un problema ya suficientemente resuelto, por lo que la gente considera sus técnicas como universales. Pero no lo son. Una vez que se lanza un producto real, la generación de texto se convierte en una sola etapa entre varias, y cada etapa tiene su propio cuello de botella. Una estrategia de ajuste que duplica la velocidad de servicio de un LLM puede resultar inútil para un modelo de embeddings, y la generación de imágenes o videos plantea sus propios problemas de cálculo y atención. Aquí conocerá modelos visión-lenguaje, generadores de embeddings, sistemas ASR y TTS, así como generadores de imágenes y videos; comenzaremos con dos patrones básicos de ejecución y luego analizaremos las métricas, las opciones de hardware, el caché, la cuantización, el agrupamiento por lotes y los compromisos de calidad para cada uno. El hilo conductor es el siguiente: la ingeniería de inferencia depende de la carga de trabajo.
Por qué un único plan de acción falla
Las aplicaciones reales concatenan modelos entre sí. Un asistente de voz podría tomar audio, ejecutar reconocimiento de voz, razonar sobre el texto y luego sintetizar habla. Un sistema de documentos podría pasar un PDF por OCR, un modelo de visión y embeddings antes de la recuperación de información, y finalmente por un LLM. Una herramienta de video podría pasar de texto a un clip generado mediante denoising iterativo y, finalmente, decodificar el medio.
Cada paso tiene su propio perfil de costo, por lo que lo que se optimiza cambia con él. Lo que hace rápido a un modelo de lenguaje autoregresivo no puede simplemente aplicarse a un pipeline de imágenes o videos.
Dos patrones cubren la mayor parte de los casos
Casi todos los sistemas generativos siguen uno de estos dos modelos.
El primero es la generación autoregresiva. El modelo produce salida paso a paso, con cada token condicionado por lo que vino antes:
Input
↓
Token 1
↓
Token 2
↓
Token 3
↓
...
Ese es el conocido ciclo de los LLM. Los modelos de visión y lenguaje, los sistemas de embedding basados en estructuras de modelos de lenguaje, los decodificadores ASR y muchos modelos TTS pueden tomar prestadas muchas ideas relacionadas con el funcionamiento de los transformadores.
El segundo es la desenfoque iterativa, el enfoque de difusión, en el que un punto de partida ruidoso se refina paso a paso:
Random / noisy latent
↓
Step 1
↓
Step 2
↓
Step 3
↓
...
↓
Final image/video
La generación de imágenes y videos se desarrolla principalmente aquí.
Esto es importante porque no se puede utilizar una misma definición de latencia, ancho de banda o eficiencia para todos ellos. En el caso de un chatbot, el tiempo hasta obtener el primer token suele ser la métrica clave. En la síntesis de voz, lo que importa es el tiempo hasta obtener el primer audio significativo. En tareas de transcripción largas, el factor en tiempo real tiende a ser dominante. En la generación de imágenes, reducir los pasos de desenfoque puede ser más efectivo que disminuir la latencia del núcleo. En el caso de los videos, la atención y los tensores enormes pueden absorber toda la carga de trabajo.
Los modelos visión-lenguaje convierten imágenes en tokens
Un VLM combina un codificador de visión con un modelo de lenguaje. El codificador convierte píxeles en representaciones que el modelo de lenguaje puede procesar junto con el texto:
Image / Video
│
▼
Vision Encoder
│
▼
Visual Tokens
│
▼
Language Model
│
▼
Text Response
La consecuencia interesante es que una imagen alarga la secuencia de entrada. Una sola imagen de alta resolución puede aportar alrededor de mil tokens visuales. Cuantos más detalles visuales haya, más tokens habrá, lo que implica más contexto y un caché KV más grande.
Por lo tanto, ajustar un VLM se parece mucho a ajustar un LLM de contexto largo. Se pueden utilizar cachés KV cuantizados, decodificación especulativa, caché de prefijos, paralelismo de tensores, descarga del caché o separación de la carga previa de la decodificación. La reutilización de prefijos es especialmente útil para imágenes repetidas y chats de varias turnos, y a medida que las entradas se alargan, la gestión de la memoria cobra cada vez más importancia.
La comprensión de video se vuelve costosa rápidamente
Las imágenes cuestan algo. El video multiplica ese costo. A 24 fotogramas por segundo, incluso un clip breve genera una gran cantidad de tokens visuales. Un clip de alta definición de cuatro segundos podría, en principio, llegar a los 100,000 tokens de entrada antes de cualquier proceso práctico de reducción de resolución.
Eso hace que la reducción de resolución sea un equilibrio entre calidad y velocidad en las operaciones de trading. Puedes disminuir la resolución, la tasa de fotogramas, la cantidad de fotogramas o el número de tokens visuales, aunque cada ajuste elimina información. Así que olvida la pregunta sobre cómo acelerar la inferencia de video. Pregúntate cuál es la representación visual más pequeña que aún cumpla con los estándares de calidad de la aplicación. Esa es la verdadera mentalidad en ingeniería de inferencia: ajustar la carga de trabajo, no solo el kernel.
Los modelos omni-modales no siempre son la solución
La industria se dirige hacia modelos que aceptan y emiten varias modalidades al mismo tiempo:
Text ─────┐
Image ────┤
Audio ────┼──► Omni Model ──► Text / Audio / Image
Video ────┘
Eso suena ideal, pero la generalidad tiene un precio. Un modelo OCR dedicado puede superar en rendimiento a la capacidad de OCR integrada dentro de un gran VLM, y un modelo de voz diseñado específicamente puede funcionar con mayor eficiencia que uno multimodal general. Por lo tanto, los sistemas de producción tienden a convertirse en cadenas de especialistas:
┌──► OCR
PDF/Image ───┤
├──► Vision Model
└──► Embedding Model
│
▼
LLM
La regla de ingeniería que se sigue es hacer que cada componente sea independientemente optimizable y escalable.
Los modelos de embedding necesitan un alto rendimiento
Los modelos de embedding difieren fundamentalmente de los LLM generativos. Ellos convierten el contenido en un vector de tamaño fijo:
Document / Image
↓
Embedding Model
↓
[0.12, -0.43, 0.87, ...]
Esos vectores impulsan RAG, la búsqueda semántica, las recomendaciones, la memoria de los agentes y la recuperación de documentos. Lo que más importa es la forma del trabajo a realizar, y dos formas son muy diferentes.
Un ejemplo de ello es el embedding masivo, como cargar diez millones de documentos en una base de datos vectorial:
10 million documents
↓
Embedding pipeline
↓
Vector database
Allí, ganan el rendimiento y el costo. La recuperación en línea es el otro método, en el que una consulta del usuario se incluye y se busca de inmediato:
User query
↓
Embedding
↓
Vector search
Allí, los milisegundos marcan la diferencia. Cuando ambos son lo suficientemente grandes, las implementaciones separadas suelen ser ventajosas, ya que cada una puede ajustarse según su propio objetivo.
Dimensionalidad y compatibilidad
Los embeddings añaden otro parámetro de equilibrio entre calidad y velocidad: el tamaño del vector. Los vectores pueden contener cientos o miles de valores. Los más grandes almacenan más información, pero aumentan los costos de almacenamiento, recuperación y cálculo de similitud. Algunos métodos modernos de embeddings permiten una dimensionalidad efectiva variable, diseñados precisamente teniendo en cuenta este equilibrio.
También existe un malentendido común. Dos vectores con la misma longitud no son automáticamente comparables, porque cada modelo de embedding construye su propio espacio semántico. Cambiar de modelo no es lo mismo que reemplazar una API por otra. Por lo general, hay que rediseñar todo el sistema de recuperación en torno a él.
El procesamiento por lotes es la herramienta principal para los embeddings
A diferencia de la decodificación autoregresiva, los modelos de embedding procesan los tokens en gran medida de forma paralela, lo que cambia la estrategia. El caché de prefijos y la desagregación de prefill/decode no son elementos centrales aquí. Hay que concentrarse en lotes grandes, tokenización rápida, colas de espera, escalado horizontal, núcleos optimizados y cuantización. Los modelos de embedding pueden manejar lotes mucho más grandes que los generativos, a veces decenas o cientos de entradas al mismo tiempo.
Una configuración razonable para producción consiste en colocar una cola de espera y un gestor de lotes delante de varias réplicas:
Requests
↓
Queue
↓
Batch Manager
↓
GPU Replica 1
GPU Replica 2
GPU Replica 3
GPU Replica 4
Para el incrustado a gran escala, una GPU por réplica escalada horizontalmente suele ser más eficaz que un complejo sistema paralelo de modelos con múltiples GPUs.
Reconocimiento de voz: el decodificador domina
El ASR convierte el audio en texto. Un flujo típico incluye un proceso de preprocesamiento, un codificador y luego un decodificador:
Audio
↓
Audio preprocessing
↓
Encoder
↓
Autoregressive Decoder
↓
Transcript
ASR no es un LLM, pero su decodificador funciona como tal y consume la mayor parte del tiempo de inferencia. Eso hace que las optimizaciones al estilo LLM sean especialmente efectivas. En la transcripción en tiempo real, el rendimiento bruto no es el objetivo principal; el sistema debe parecer instantáneo, y un objetivo razonable es de unos 200 ms de ida y vuelta para cada bloque de audio en vivo.
La transmisión en streaming transforma la experiencia
Uno de los mayores beneficios de ASR no requiere ningún cambio en el modelo, solo un diseño diferente de distribución. En lugar del patrón de subir, esperar y recibir:
Upload audio
↓
Wait
↓
Receive transcript
pasar a un flujo continuo:
Continuous Audio
↓
VAD
↓
Audio Chunks
↓
ASR GPU
↓
Streaming Transcript
Un WebSocket mantiene la conexión abierta mientras un modelo de detección de actividad vocal identifica las secciones que contienen audio significativo. La lección es que el rendimiento de la inferencia no siempre es un problema relacionado con el tiempo de ejecución; a veces, la orquestación brinda los mayores beneficios.
Las grabaciones largas requieren paralelismo
Los archivos largos son algo distinto a la dictado interactivo. En lugar de procesarlos en orden:
Chunk 1 → Chunk 2 → Chunk 3 → Chunk 4
puedes crear una tubería paralela:
┌──► GPU 1 ──► Chunk 1
Audio → VAD ─────┼──► GPU 2 ──► Chunk 2
├──► GPU 3 ──► Chunk 3
└──► GPU 4 ──► Chunk 4
↓
Stitch by time
Se pierde algo de reutilización del contexto secuencial, pero se gana una gran cantidad de rendimiento. El factor en tiempo real es la métrica útil para la transcripción de texto extenso, y el procesamiento paralelo de bloques es adecuado para tareas de alto rendimiento. Para proteger la calidad, añada un procesamiento posterior que detecte repeticiones sospechosas y vuelva a procesar solo los bloques problemáticos.
TTS: el objetivo no es tener más tokens por segundo
La conversión de texto a voz funciona en la dirección opuesta a la ASR:
Text
↓
TTS Model
↓
Audio Tokens
↓
Audio Decoder
↓
Waveform
Los modelos de TTS modernos suelen utilizar arquitecturas similares a las de los LLM, por lo que los núcleos optimizados, el procesamiento en lotes y la inferencia de baja precisión provienen del servicio de LLM. Sin embargo, la métrica difiere de manera sutil: generar 500 tokens de audio por segundo no es mejor que 100 si el decodificador de audio solo necesita una salida aproximadamente en tiempo real. Una vez que la generación alcanza el ritmo del tiempo real, la pregunta pasa a ser cuántos usuarios concurrentes puede soportar una GPU. Eso se trata de optimizar según los requisitos del producto, no según el número del benchmark.
Generación de imágenes: olvídate de los instintos de los LLM
Los generadores de imágenes son en su mayoría desenrarecedores iterativos, no generadores token por token:
Noise
↓
Denoising Step 1
↓
Denoising Step 2
↓
...
↓
Image
A diferencia de la decodificación de LLM, esta tarea suele estar limitada por el poder de cálculo, por lo que el ancho de banda de la memoria deja de ser el principal obstáculo. La gama de herramientas se centra entonces en la selección de kernels, la fusión de kernels, la atención eficiente, el ajuste de operaciones GEMM, la compilación con Torch, el uso de menor precisión y la realización de menos operaciones de desenfoque.
Los kernels son muy importantes
Los kernels de atención son especialmente significativos en la generación de imágenes. Dependiendo de la arquitectura y la implementación de la GPU, se pueden evaluar opciones optimizadas como FlashAttention, DeepGEMM, CuTe y CUTLASS. Las operaciones de normalización como RMSNorm también son buenas candidatas para la fusión.
La lección más importante es que el mejor motor de inferencia depende tanto del trabajo a realizar como del hardware. PyTorch ofrece flexibilidad, las implementaciones especializadas incluyen núcleos ajustados previamente, y la compilación puede combinar operaciones en un camino específico para la GPU. La respuesta adecuada se obtiene al realizar pruebas de rendimiento con su modelo real en su hardware real.
Un truco efectivo para la difusión
Los modelos de difusión ejecutan muchas etapas: las primeras establecen la estructura general y las posteriores perfeccionan los detalles. Esto abre una oportunidad: reducir el costoso proceso de guía en las etapas finales. Un enfoque consiste en omitir la guía sin clasificador en las etapas avanzadas manteniendo el mismo número de pasos. En un ejemplo con 50 pasos, la tasa de rechazo del modelo disminuye de 100 a 80, y la calidad generalmente se mantiene.
El truco específico importa menos que el principio. No toda iteración aporta lo mismo al resultado final, y la optimización de inferencia puede aprovechar ese desequilibrio.
La generación de video es otra escala
La generación de video es la generación de imágenes con una dimensión temporal adicional. Mientras que en el caso de una imagen latente:
Height × Width
Un video latente se convierte en:
Height × Width × Time
Eso hace que el problema de cálculo sea mucho mayor. El video está limitado por los cálculos necesarios, y los sistemas suelen ocupar nodos completos con múltiples GPUs con tamaños de lotes muy pequeños, incluso un lote de uno solo, ya que todas las GPUs colaboran en un único clip.
Eso marca una clara diferencia con la generación de texto. Con el texto, un lote más grande puede aumentar el rendimiento. En el caso del video, el agrupamiento en lotes suele ser de poca ayuda, ya que una sola generación puede consumir ya la mayor parte de los recursos de cálculo. Por lo tanto, la forma más rápida de obtener videos a menor costo suele ser utilizar un modelo más rápido.
La atención domina en el video
En la generación de video, la atención puede absorber una gran parte de los cálculos necesarios; se estima que entre el 70 y el 80 por ciento en algunas tareas. Esto cambia las prioridades. En lugar de cuantificar principalmente los pesos, los ingenieros se centran en los núcleos de atención, la cuantización de la atención, el caché, el paralelismo contextual y la ejecución paralela a nivel de GPU.
El caché en el video funciona de manera diferente
La generación de video no utiliza el enfoque de caché KV autoregresivo. En su lugar, los sistemas reutilizan partes de cálculos anteriores de dos maneras principales. El caché por pasos temporales reutiliza los resultados de las etapas de desenfoque seleccionadas. El caché del Transformer reutiliza los estados ocultos y omite ciertas operaciones dentro de la estructura del Transformer. Ambos métodos pueden lograr grandes aceleraciones, pero también pueden degradar seriamente la calidad dependiendo del algoritmo. Por lo tanto, considere cada optimización como un bucle:
Optimization
↓
Speed ↑
↓
Quality ?
↓
Evaluate
↓
Production
Nunca asuma que una optimización de caché es segura solo porque el video sigue viéndose aceptable.
La cuantización sigue el cuello de botella
En los LLM, la cuantización suele dirigirse a las capas lineales grandes y a sus pesos, ya que la inferencia de estos modelos suele verse limitada por el ancho de banda de memoria. La generación de video, en cambio, está limitada por los recursos de cómputo, especialmente en lo que respecta a la atención, por lo que esta última se convierte en un objetivo tentador para la cuantización. Sin embargo, la atención también es muy sensible al error numérico.
Existen dos opciones: puede cuantizar por bloques utilizando formatos de microescalamiento como MXFP8, o bien puede cuantizar de forma selectiva, variando la precisión paso a paso:
Early steps → FP16
Middle steps → Lower precision
Late steps → Lower precision
o por capas:
Input layer → FP16
Hidden layers → Lower precision
Output layer → FP16
Mantenga la precisión donde el modelo es frágil, y optimice al máximo donde no lo sea.
No existe una optimización universal
En estas distintas modalidades, las estrategias exitosas no se parecen en nada:
| Modality | Dominant Concern | High-Value Techniques |
| ---------------- | --------------------------- | ----------------------------------------------------- |
| VLM | Long visual context | KV optimization, caching, parallelism |
| Embeddings | High request volume | Batching, queueing, horizontal scaling |
| ASR | Decoder latency | Optimized decoder, streaming, parallel chunks |
| TTS | Real-time concurrency | Streaming, batching, efficient decoding |
| Image generation | Compute | Kernel fusion, compilation, fewer expensive passes |
| Video generation | Massive compute + attention | Attention kernels, caching, quantization, parallelism |
Por eso, la ingeniería de inferencia está más relacionada con el trabajo en sistemas que con simplemente acelerar un LLM.
Conclusiones
- La inferencia multimodal depende de la carga de trabajo. La mejor arquitectura sigue el patrón de ejecución y los requisitos del producto.
- Los modelos autoregresivos y de difusión tienen cuellos de botella fundamentalmente diferentes.
- Los VLM convierten la entrada visual en contexto adicional, por lo que el cache KV y el ajuste del contexto largo son más importantes.
- Los sistemas de embeddings se tratan principalmente de problemas de agrupamiento y rendimiento, no de latencia en la decodificación.
- Las mejoras en la ASR provienen en gran medida de la orquestación y el streaming, no solo de núcleos más rápidos.
- En el caso de la TTS, una vez que la generación supera el tiempo real, el ajuste se convierte en una cuestión relacionada con los usuarios concurrentes.
- La generación de imágenes está limitada por los recursos de cómputo, lo que hace críticos los núcleos, la fusión, la compilación y la reducción de pasos de desenfoque.
A dónde conduce esto
Los productos de IA se están volviendo multimodales por defecto. El texto, las imágenes, el audio, el video y los embeddings se integran cada vez más en la misma aplicación, por lo que la tarea pasa de ajustar un modelo a ajustar todo un pipeline. La pregunta ya no es qué técnica de optimización utilizar, sino dónde se encuentra el cuello de botella en esa carga de trabajo específica y qué compromisos se pueden asumir sin riesgo para eliminarlo.
Esa mentalidad se aplica desde una GPU que sirve a un modelo de embedding hasta un clúster multi-GPU que genera video en tiempo real. Conozca la carga de trabajo, localice los cuellos de botella, pruebe los compromisos que está dispuesto a asumir y ajuste todo el sistema en lugar de solo el modelo.