Inferencia en IA: qué ocurre cuando responde un LLM

La inferencia en IA, en el caso de los LLM, tiene 2 fases principales: procesar el prompt y generar la respuesta. Una función que tarda en empezar a responder necesita una solución distinta de otra que empieza rápido, pero tarda demasiado en terminar. Mide esas esperas por separado antes de cambiar de modelo, contratar un servicio más rápido o alquilar GPU.

Empieza con una API alojada, salvo que tengas un motivo concreto para gestionar por tu cuenta el sistema que ejecuta la inferencia. Puede ser la necesidad de controlar el despliegue, usar un modelo abierto específico o atender un tráfico sostenido que justifique gestionar tu propia capacidad. Una respuesta lenta, por sí sola, no basta: primero identifica qué parte de la solicitud causa la demora.

La documentación y el alcance de las versiones que se describen a continuación se verificaron en las páginas oficiales de sus creadores el 21 de octubre de 2026. El ejemplo desarrollado utiliza una respuesta de API publicada y muestra los cálculos. No es una prueba de rendimiento ni una afirmación sobre la velocidad que alcanzará tu aplicación.

¿Qué es la inferencia en IA cuando usamos un LLM?

La inferencia es el trabajo que realiza un modelo de lenguaje grande ya entrenado para producir una salida a partir de una entrada. En una solicitud típica de generación de texto, consiste en preparar el prompt, predecir una continuación y devolver el texto generado. El modelo procesa tokens: unidades de texto que pueden ser palabras, fragmentos de palabras o signos de puntuación. Explicación de NVIDIA sobre la inferencia.

Piensa en organizar tus notas antes de redactar una respuesta. Leer y ordenar el material recibido corresponde a la fase de preparación. Escribir la respuesta corresponde a la fase de continuación. Tener las notas listas evita repetir la preparación, pero la respuesta todavía hay que escribirla. En la implementación real se almacena un estado numérico, no notas legibles.

El prefill procesa la entrada que ya se conoce. Las instrucciones, los documentos recuperados, el historial de conversación y los resultados de las herramientas se convierten en tokens del prompt. Como esas posiciones ya existen, el sistema puede procesarlas conjuntamente, dentro de las reglas de atención del modelo. Así construye el estado que utilizará para producir el primer token de salida.

El decode genera la continuación. En la generación autorregresiva habitual, cada nuevo token depende de la continuación elegida hasta ese momento. El entorno de ejecución vuelve a ejecutar el modelo, elige el siguiente token, actualiza el estado y repite el proceso hasta que se cumple una condición de parada. NVIDIA describe ambas fases.

En un asistente de atención al cliente, un documento extenso de políticas puede hacer costosa la preparación aunque se pida una respuesta breve. En un generador de informes, un prompt corto puede dar paso a una larga espera mientras el modelo escribe. Son cargas de trabajo distintas, aunque utilicen el mismo endpoint.

Inferencia y entrenamiento: ¿en qué se diferencian?

El entrenamiento modifica los parámetros aprendidos del modelo; la inferencia los utiliza. Los parámetros, también llamados pesos, son los valores numéricos aprendidos durante el entrenamiento. Incluir un documento en el prompt aporta contexto para esa solicitud; no vuelve a entrenar esos pesos por sí solo. Explicación de IBM sobre inferencia y entrenamiento.

Esta distinción ayuda a diagnosticar problemas en un producto. Si la respuesta ignora una política, mejora el contexto proporcionado y evalúa el comportamiento del modelo. Si la respuesta es correcta, pero tarda demasiado, revisa los tiempos de inferencia. El entrenamiento, la calidad de la recuperación de información y el rendimiento del servicio son ámbitos de intervención distintos.

¿Por qué los tokens de salida suelen costar más?

Generar una continuación suele permitir menos trabajo en paralelo por solicitud que procesar un prompt ya conocido. Con lotes pequeños, el decode puede dedicar gran parte del tiempo a mover por la memoria los pesos del modelo y el estado de atención. Procesar conjuntamente más posiciones de una entrada conocida permite aprovechar el hardware de otra manera. Esto ayuda a explicar por qué muchas API cobran más por la salida. Cómo funcionan el prefill y el decode, según NVIDIA.

La relación exacta entre ambos precios es una decisión del proveedor, no una constante física. También influyen el tratamiento de la caché, el modelo elegido y las condiciones del servicio. No des por hecho que acortar la entrada y acortar la salida tienen el mismo efecto sobre la latencia o la factura.

La consecuencia práctica es sencilla: si tu función necesita una categoría y una explicación breve, pide ese resultado. Exigir un texto extenso añade trabajo de generación que incluso un servicio más rápido tendrá que realizar.

Separa el tiempo hasta el primer token de los tokens por segundo

El tiempo hasta el primer token indica cuánto tarda en empezar la respuesta; la velocidad de generación indica a qué ritmo continúa. Mide ambos con límites de medición consistentes.

• Tiempo hasta el primer token, o TTFT: desde el envío de la solicitud al modelo hasta la recepción del primer token de salida no vacío. Pueden influir la espera en cola, el procesamiento del prompt y el tránsito por la red.
• Latencia entre tokens: el intervalo entre los tokens de salida una vez iniciada la generación. Una respuesta en streaming puede comenzar pronto y aun así sentirse lenta si esos intervalos son largos.
• Latencia total de la solicitud: desde el envío de la solicitud hasta la recepción del último token de salida.
• Rendimiento total del sistema: la salida útil total del conjunto de solicitudes concurrentes. Puede aumentar mientras la experiencia de un usuario individual empeora.

Estas distinciones siguen las definiciones de métricas de NVIDIA. También explican por qué una cifra destacada de tokens por segundo no resuelve todas las dudas sobre rendimiento.

Revisa el denominador cada vez que compares tokens por segundo. Un proveedor puede dividir los tokens de salida entre el tiempo de generación, mientras que una medición del cliente incluye la espera inicial. Un resultado agregado del servidor puede combinar a muchos usuarios. Esas cifras describen cosas distintas.

En una respuesta en streaming con varios tokens, el intervalo medio entre tokens se puede calcular como (final-token time − first-token time) / (output-token count − 1). La fórmula excluye la espera inicial; la resta ajusta el cálculo al número de intervalos entre tokens. La definición de NVIDIA deja explícitos esos límites.

Mide por separado el tiempo de la aplicación desde la acción del usuario hasta que obtiene un resultado utilizable. Esa medición debe incluir la recuperación de documentos previa a la llamada al modelo, las llamadas a herramientas externas y la validación posterior. Cambiar de proveedor de inferencia no elimina el tiempo de espera de tu propia base de datos.

Una solicitud, con cada componente de su latencia

El ejemplo de respuesta publicado por Groq muestra por qué conviene examinar un campo llamado total_time. Groq, un proveedor de inferencia alojada, incluye campos de tiempo en los datos de uso de su API. Su referencia de la API Chat Completions ofrece un ejemplo con 18 tokens de prompt y 556 tokens de respuesta.

Estos son los valores publicados en el ejemplo, con los segundos convertidos a milisegundos y redondeados:

Fuente: objeto de uso del ejemplo de Groq. Son tiempos de un ejemplo de documentación, no latencias que deban esperarse en producción.

En este ejemplo, el total declarado incluye el procesamiento del prompt y la generación:

Prompt + respuesta = 0.000680594 + 0.463333333 = 0.464013927 segundos. Coincide exactamente con el total_time declarado. En este ejemplo, la cola queda fuera de ese total.

Cola + prompt + respuesta = 0.501507683 segundos, o aproximadamente 501.508 ms. Este es nuestro subtotal de los componentes identificados del lado del servidor. Aun así, no indica la espera completa de la aplicación, porque el ejemplo no aporta tiempos de red medidos en el cliente ni del trabajo de la aplicación que rodea la llamada.

Dividir los 556 tokens de salida del ejemplo entre sus 0.463333333 segundos de generación da aproximadamente 1,200 tokens de salida por segundo. Es un cálculo sobre una respuesta de ejemplo, no una prueba de rendimiento ni una promesa. Groq documenta este cálculo de cantidad de tokens dividida entre tiempo de generación en su guía de métricas de inferencia.

Para tu propia función, lo útil es este desglose. Una espera larga en cola apunta al control de admisión y la capacidad. Un tiempo elevado de procesamiento del prompt apunta al trabajo de entrada. Una generación prolongada apunta al trabajo de salida. Si la espera del cliente supera ampliamente los tiempos declarados por el servidor, conviene revisar la red y el recorrido de la solicitud dentro de la aplicación.

Cómo optimizar la inferencia de un LLM según la causa de la espera

Una optimización solo ayuda si modifica una parte relevante de tu carga de trabajo. La misma función puede ser valiosa para un asistente de documentos y casi irrelevante para prompts breves sin relación entre sí.

NVIDIA y las guías de los entornos de ejecución enlazadas más abajo documentan estos mecanismos. La última columna marca los límites que conviene tener presentes al decidir un despliegue.

Caché KV: conserva el trabajo ya realizado

La caché de claves y valores, o caché KV, conserva el estado de atención de los tokens anteriores. La atención es el mecanismo con el que un transformer incorpora el contexto previo a su predicción actual. Conservar las claves y los valores anteriores evita reconstruirlos cada vez que avanza el modelo. La caché crece o se gestiona según la arquitectura de atención del modelo y la política del servicio. Explicación de NVIDIA sobre la caché KV.

Esta reutilización consume memoria. Que los pesos de un modelo quepan en una GPU no significa que también quepan las conversaciones largas de muchos usuarios simultáneos. Incluye en el cálculo el estado de las solicitudes activas y la memoria de trabajo, además de los pesos.

La caché de prefijos permite reutilizar trabajo entre solicitudes que empiezan igual. Un asistente que recibe repetidamente las mismas instrucciones y el mismo documento de referencia puede reutilizar ese prefijo ya procesado. Aun así, debe procesar la parte final que cambia y generar una respuesta nueva.

vLLM, un motor de código abierto para ejecutar y servir inferencia, documenta explícitamente que su caché automática de prefijos ahorra trabajo de prefill, no de decode. Límites de la caché de vLLM.

Mantén el contexto compartido útil al principio de las solicitudes y revisa después el uso de caché que se declara. Si tus prompts tienen poco en común o la mayor parte de la espera se debe a respuestas largas, reutilizar prefijos resolverá poco del problema. La guía sobre la caché KV explica con más detalle el estado, su conservación y la reutilización según el proveedor.

Procesamiento por lotes: comparte la capacidad entre solicitudes

El procesamiento continuo por lotes, o continuous batching, permite aprovechar mejor el servidor. Las secuencias completadas pueden salir del lote y las nuevas solicitudes pueden entrar mientras otras secuencias siguen generándose. Así no hace falta mantener ocupado un grupo entero hasta que termine su respuesta más larga. Explicación de NVIDIA sobre el procesamiento continuo por lotes.

Para quien opera un servicio con muchos clientes, esto puede hacer más productiva la capacidad disponible. Para quien espera una sola respuesta, un mayor rendimiento agregado no supone automáticamente una mejora. Prueba la distribución de los tiempos de respuesta con el tráfico simultáneo que tu función debe atender.

No confundas el procesamiento continuo por lotes dentro de un motor de inferencia con una API de lotes asíncrona. Esta última permite enviar trabajo para que se complete más adelante y sirve para tareas como la clasificación nocturna. Elegir ese producto es una decisión distinta de programar de forma eficiente las solicitudes de un chat en vivo.

El prefill por fragmentos, o chunked prefill, reduce las interferencias entre los prompts nuevos y las respuestas en curso. Divide un prefill grande en partes más pequeñas que se pueden programar junto al trabajo de decode. vLLM documenta un equilibrio entre la latencia hasta el primer token y la latencia entre tokens al cambiar el presupuesto de tokens del planificador. Guía de ajuste de vLLM.

Esto importa cuando llega un documento nuevo mientras otros clientes ya están conversando. El objetivo es que esas respuestas en streaming mantengan un ritmo ágil mientras se admite el nuevo trabajo, en lugar de optimizar una solicitud aislada en un servidor vacío.

Cuantización: ocupa menos espacio por valor

La cuantización reduce la precisión utilizada para representar valores numéricos. Las representaciones más pequeñas pueden reducir las necesidades de memoria y favorecer una ejecución limitada por el ancho de banda. La cuantización de pesos y la cuantización de la caché KV afectan a asignaciones de memoria distintas. Documentación de vLLM sobre cuantización.

La decisión consiste en determinar si la representación elegida conserva el comportamiento que exige tu aplicación en un entorno de ejecución y un dispositivo compatibles. Evalúa la extracción de información de documentos, los argumentos de herramientas y las tareas de contexto largo que sean relevantes para tu función. Un archivo más pequeño y un modelo que carga correctamente no demuestran que el resultado sea aceptable.

No prometas más velocidad basándote solo en el nombre del formato. El resultado depende de los kernels compatibles, el hardware y la carga de trabajo. Consulta la guía de cuantización de LLM para elegir entre formatos y determinar qué consumo de memoria se reduce.

Decodificación especulativa: propone y después verifica

La decodificación especulativa intenta aceptar más trabajo de continuación por cada pasada de verificación. Un mecanismo de borrador menos costoso propone tokens y el modelo objetivo los verifica. Aceptar esos borradores puede ahorrar trabajo de generación secuencial; rechazarlos y verificarlos también tiene un costo. Documentación de vLLM sobre decodificación especulativa.

El borrador puede proceder de otro modelo o de un método de predicción compatible. El beneficio depende de la aceptación, el modelo objetivo, los ajustes de muestreo, el hardware y el tráfico. Conviene evaluarlo cuando la generación es el cuello de botella; no soluciona una recuperación de documentos lenta ni garantiza una cola inicial más corta.

Los métodos estándar de muestreo por rechazo buscan preservar la distribución objetivo dentro de los límites numéricos. No extiendas esa promesa a toda función que lleve la etiqueta de especulativa: en esa misma documentación, vLLM distingue sus garantías estándar de los métodos de verificación que admiten pérdidas de forma deliberada.

Cómo diseñar un sistema de inferencia: quién opera el servicio

Define qué responsabilidades asumirás antes de elegir el hardware. La API del creador del modelo, un proveedor de inferencia y tu propio entorno de ejecución pueden convertir prompts en respuestas. Cada opción deja tareas distintas en tus manos.

API del modelo: accede a los modelos de su creador

La API de Claude de Anthropic ofrece acceso programático alojado a los modelos Claude. Su API Messages recibe solicitudes y genera respuestas, con interfaces de streaming y uso de herramientas documentadas por su creador. Descripción general de la API de Claude.

Esta opción encaja cuando la prioridad es incorporar a un producto el comportamiento del modelo que necesitas. Tú eliges los prompts, el contexto, los requisitos de salida y los controles de la aplicación; el creador opera la infraestructura de inferencia.

El límite está en el control. Comprar acceso a un modelo no te da acceso al planificador del proveedor ni despliega ese modelo dentro de tu infraestructura. Elige esta opción si el modelo y el contrato del servicio cubren la necesidad. Antes de iniciar un proyecto con GPU porque una respuesta de API es lenta, mide dónde se produce la espera.

Proveedor de inferencia: elige por separado quién aloja el modelo

Groq ofrece una API alojada de chat completions con un catálogo de modelos documentado. Sus páginas detallan las capacidades y los límites de cada modelo; comprueba el endpoint concreto que piensas utilizar. Catálogo de modelos de Groq.

Esto permite evaluar un proveedor de alojamiento para un modelo disponible sin operar su hardware. El límite está en la combinación desplegada: disponibilidad de modelos, límites de las solicitudes y funciones compatibles. Que una familia de modelos aparezca en otro sitio no demuestra que el proveedor ofrezca el checkpoint que necesitas ni que admita todos los campos de una solicitud.

Cerebras ofrece una API y un SDK de inferencia alojada, incluida la generación en streaming. Su guía de inicio rápido muestra cómo configurar la clave de API y realizar las solicitudes. Guía de inicio rápido de inferencia de Cerebras.

Evalúa Cerebras como otro candidato con las longitudes de prompt, los requisitos de salida y el patrón de tráfico reales de tu aplicación. El límite sigue siendo la adecuación del servicio: confirma el modelo ofrecido, las funciones necesarias y las condiciones de capacidad. Una respuesta rápida en streaming con un ejemplo breve no basta para avalar una función en producción que trabaja con muchos documentos. La guía de precios de Cerebras y la guía de precios de Groq desarrollan esas decisiones comerciales.

Ejemplo de precio de un servicio alojado: Groq anuncia Qwen3.8-27B de Alibaba a $0.80 por millón de tokens de entrada y $4.00 por millón de tokens de salida; consulta el listado actual de modelos para comparar el uso de un servicio alojado con la capacidad y el trabajo operativo que tendrías que financiar por tu cuenta.

Ese ejemplo corresponde a un modelo concreto. No es una cotización para el ejemplo de tiempos anterior ni permite clasificar a Groq frente a otro modelo o despliegue.

Motor de inferencia propio: gestiona la ejecución y la capacidad

vLLM ofrece un entorno para servir modelos con procesamiento continuo por lotes, streaming, caché de prefijos y un servidor de API. Son componentes útiles cuando te corresponde atender solicitudes concurrentes. Aun así, debes comprobar la compatibilidad de modelos, hardware y opciones de optimización para tu despliegue. Capacidades documentadas de vLLM.

El límite está en el servicio que hay que construir alrededor del motor: provisionar capacidad, desplegar cambios, admitir tráfico, observar fallos y mantener margen suficiente para los periodos de mayor demanda. Un entorno de ejecución puede programar el trabajo en los dispositivos disponibles; no puede decidir los requisitos de fiabilidad de tu aplicación.

Ollama es un entorno para ejecutar modelos en tu equipo o servidor, con opciones de ejecución en CPU y GPU. Sus preguntas frecuentes documentan el procesamiento concurrente, las colas y la memoria adicional que requieren las solicitudes paralelas. Guía de concurrencia de Ollama.

Ollama es un punto de partida razonable para el desarrollo local o una carga interna controlada. Su límite está en la memoria y la capacidad operativa que sostienen esa interfaz práctica. Consulta la comparación entre Ollama y vLLM para decidir entre Ollama y un despliegue orientado al servicio, y después valida la decisión con solicitudes concurrentes, no solo con un chat que haya funcionado.

DeepInfer, de DeepSeek, es un framework especializado en inferencia cuyo repositorio público se inició el 20 de octubre de 2026. El README describe la versión abierta como un sistema de inferencia offline con componentes para servir modelos a escala, compatible con DeepSeek-V4.1-Flash, GPU NVIDIA SM100 y NPU Huawei Ascend 950. Historial del repositorio, README de su creador.

La versión publicada no constituye un servicio completo de inferencia. DeepSeek enumera explícitamente un sistema de caché KV, la separación de codificación/prefill/decode y el balanceo de carga entre réplicas como componentes necesarios que no están incluidos. Son piezas ausentes del servicio; esto no debe interpretarse como que el motor de inferencia no almacena ningún estado de atención en caché. Omisiones declaradas de DeepInfer.

Para un equipo de infraestructura que necesite ese modelo y ese hardware, merece la pena evaluar el código. Para quien quiere mejorar una aplicación convencional esta semana, no es un atajo que evite operar un servicio. Separa la decisión sobre el modelo DeepSeek V4 de la decisión de construir su infraestructura de inferencia.

Opta por el alojamiento propio cuando ese control resuelva un requisito concreto y tengas un equipo capaz de asumir la responsabilidad. Una demanda sostenida puede justificar su evaluación; una demanda irregular puede dejar inactiva capacidad por la que ya pagas. Incluye en la decisión el contexto activo, la concurrencia, los fallos y los periodos de máxima demanda. No existe un umbral universal de tráfico defendible a partir del cual tus propias GPU sean la mejor opción.

Qué se exagera al hablar de una inferencia más rápida

Una mayor velocidad de generación solo es útil si mejora el resultado que el usuario está esperando. El streaming muestra el avance antes, pero no elimina la generación pendiente. Un flujo de trabajo que deba validar una respuesta estructurada completa puede seguir necesitando esperar hasta el final.

La inferencia más rápida depende de la carga de trabajo

Una comparación útil hace explícitos el comportamiento del modelo, la longitud del prompt, la longitud de la salida, las condiciones de caché y la concurrencia. De lo contrario, un resultado más rápido puede deberse simplemente a una solicitud más sencilla o a un denominador de tiempo distinto. El rendimiento agregado de un proveedor no promete nada sobre el primer token de un cliente individual.

El mismo rigor se aplica a las promesas de optimización. Un acierto de caché ahorra la preparación repetida que pueda reutilizarse, no todas las partes de una tarea. Las representaciones numéricas más pequeñas no demuestran que la calidad de la tarea se mantenga. Un framework abierto de inferencia no proporciona un servicio operativo completo.

Actúa ya sobre la medición y el trabajo innecesario. Espera a que esas mediciones justifiquen una migración de infraestructura. Si una llamada breve a una API ya cumple tus requisitos de calidad y latencia, la aparición de un nuevo motor de inferencia no crea un problema que debas resolver.

Preguntas frecuentes sobre la inferencia

¿Qué es la inferencia en machine learning?

ML significa machine learning, o aprendizaje automático. La inferencia aplica un modelo entrenado a una entrada nueva para obtener una salida. La generación de texto con LLM es una aplicación de ese proceso más amplio.

¿Qué significa LLM en inteligencia artificial?

LLM son las siglas de large language model, o modelo de lenguaje grande. En la generación de texto que se aborda aquí, el modelo procesa el contexto y predice tokens para formar una continuación.

¿Qué significa lenguaje de inferencia?

En este contexto, la expresión suele referirse a la inferencia realizada por un modelo de lenguaje. No es el nombre de un lenguaje de programación obligatorio; una aplicación puede llamar al modelo mediante su API o su entorno de ejecución.

¿En qué se diferencian inferencia y predicción en aprendizaje automático?

La inferencia es el proceso de ejecutar el modelo entrenado. Una predicción es una salida de ese proceso. Durante la generación autorregresiva de lenguaje, las predicciones sucesivas del siguiente token construyen la respuesta.

¿Cuáles son los tres tipos de inferencia?

Cuando se habla de razonamiento, suelen ser la deducción, la inducción y la abducción. Son categorías lógicas. La API del creador de un modelo, un proveedor de inferencia alojada y un entorno de ejecución autogestionado son opciones de despliegue, no esos tres métodos de razonamiento.

¿Cuáles son cinco ejemplos de inferencia?

Algunos ejemplos de tareas con modelos de lenguaje son clasificar un correo, resumir un documento, traducir un pasaje, redactar una respuesta y generar código. Son ejemplos de tareas, no afirmaciones sobre el rendimiento de un modelo concreto.

¿Puedes dar un ejemplo de inferencia?

Una aplicación de atención al cliente envía la pregunta de un cliente y el texto de las políticas pertinentes a un modelo entrenado, que genera un borrador de respuesta. Preparar ese contexto y generar la respuesta son trabajo de inferencia.

¿Cómo se realiza una inferencia?

En una aplicación con LLM, elige un modelo entrenado, envía el prompt pertinente mediante una API o un entorno de ejecución y evalúa la salida recibida. Puedes utilizar un modelo ya entrenado sin entrenarlo por tu cuenta.

¿Qué es la inferencia en palabras sencillas?

Es utilizar lo que un modelo aprendió para producir una salida a partir de una entrada nueva. En un chatbot, es el trabajo que realiza el modelo entre recibir la conversación y producir la siguiente respuesta.

Qué cambiar la próxima semana

Quienes desarrollan deben instrumentar la solicitud; quienes operan el servicio, probarla bajo carga; y quienes compran, comparar los requisitos de servicio resultantes. Estas tareas están conectadas, pero no son intercambiables.

1. 1

   Registra el recorrido completo

   Para una tarea representativa, registra las cantidades de tokens de entrada y salida, la primera salida no vacía, la salida final y los campos de tiempo disponibles del proveedor. Conserva las mediciones de recuperación de información y de llamadas a herramientas junto a la del modelo. Identifica por separado las solicitudes con caché y sin caché.

2. 2

   Modifica la parte que más pesa

   Si predomina el procesamiento repetido del prompt, investiga la reutilización de prefijos y el contexto irrelevante. Si predomina la generación, recorta la salida innecesaria o evalúa un modelo o una configuración de decodificación adecuados. Si predomina la cola, revisa la capacidad y el control de admisión antes de reescribir el prompt.

3. 3

   Reproduce un tráfico realista

   Compara la calidad de la tarea y la latencia con las solicitudes simultáneas que esperas recibir, incluidas entradas y salidas largas. Usa esa evidencia para mantener la API actual, evaluar otro proveedor de alojamiento o justificar la gestión de tu propia capacidad. Antes de elegir esta última vía, asigna quién responderá ante los fallos.

Suscríbete al boletín para recibir explicaciones prácticas sobre los sistemas que hacen funcionar los productos de IA.