La inferencia es la ejecución de un modelo ya entrenado para producir una predicción, clasificación o respuesta a partir de una entrada. En un modelo de lenguaje, la entrada se convierte en tokens, se procesa junto con el contexto y la salida se genera paso a paso.
La inferencia no vuelve a entrenar el modelo ni garantiza que la respuesta sea correcta.
Del texto a los tokens
La aplicación construye una solicitud con instrucciones, contenido del usuario y, cuando procede, herramientas o documentos. El tokenizador convierte esa secuencia en unidades que el modelo procesa. El idioma, los símbolos y la forma del texto influyen en la cantidad de tokens.
Ejecutar y generar
El runtime carga pesos y calcula capas del modelo. En generación autoregresiva, cada token nuevo depende del contexto anterior y se incorpora a la siguiente iteración. La caché de atención evita repetir parte del trabajo, pero crece con el contexto y la concurrencia.
Medidas de rendimiento
El tiempo hasta el primer token refleja entrada, carga, red y primera ejecución. Los tokens por segundo reflejan la generación posterior. El throughput mide cuántas solicitudes procesa el sistema en un periodo. Una aplicación interactiva puede priorizar latencia aunque un lote obtenga mayor throughput.
CPU, GPU y memoria
La CPU puede ejecutar modelos pequeños o cargas con poca concurrencia. La GPU suele ayudar con operaciones paralelas, siempre que el modelo y la caché quepan en VRAM. Más hardware no garantiza respuestas mejores: cambia capacidad y velocidad, no la información aprendida por el modelo.
Qué limita una respuesta
La inferencia puede ser rápida y aun así producir una salida incorrecta, incompleta o sensible al contexto. Valida formatos, aplica límites y evalúa casos representativos. Si la aplicación necesita datos actuales, debe proporcionar una fuente o una integración adecuada; el modelo no los obtiene automáticamente.
Medir antes de optimizar
Registra tamaño de entrada y salida, contexto, latencia, errores, uso de memoria y coste. Después prueba batching, cuantización o un hardware distinto. Cada cambio tiene efectos distintos y debe compararse con el objetivo real.
Entrada, contexto y salida
La aplicación puede incluir instrucciones del sistema, mensaje del usuario, historial, documentos recuperados y resultados de herramientas. Todo ello consume contexto y puede afectar a la salida. Ordenar la información y eliminar contenido redundante suele ser más útil que añadir texto indiscriminadamente.
Generación secuencial
En modelos generativos, los tokens de salida se producen uno detrás de otro. La primera respuesta requiere preparar entrada y cachés; los siguientes tokens dependen del estado construido. Por eso tiempo hasta el primer token y velocidad de generación deben medirse por separado.
Recursos y límites
El modelo, precisión, contexto y concurrencia determinan memoria y cálculo. Una GPU puede acelerar operaciones paralelas, pero el servidor también necesita CPU, RAM, almacenamiento y red. Una petición puede fallar por límite de contexto aunque el hardware tenga memoria libre.
Aplicar la salida con cuidado
Trata la respuesta como resultado del modelo, no como una fuente verificada. Valida JSON, permisos y acciones antes de guardar o ejecutar. Para información cambiante, proporciona fuentes o una herramienta que la aplicación pueda comprobar.
Un ciclo de medición
Registra entrada y salida, latencia, errores, memoria, coste y versión. Cambia una variable cada vez y compara con ejemplos conocidos. Optimizar la velocidad no demuestra que haya mejorado la exactitud o la utilidad.
Interpretar las métricas
Tiempo hasta el primer token incluye preparación, carga, red y primer cálculo. Tokens por segundo describe la generación posterior. Throughput mide volumen atendido y puede mejorar con batching aunque una petición espere más. Elige la métrica según la experiencia que quieras ofrecer.
Errores y validación
Controla contexto excesivo, respuestas con formato inválido, timeouts y falta de datos. La aplicación debe validar antes de ejecutar una acción o guardar información. La inferencia produce una salida probable, no una garantía de verdad.
Documenta modelo, hardware, precisión y ejemplos utilizados para medir.
La infraestructura no aporta exactitud
Un dispositivo más rápido reduce tiempos de cálculo, pero no corrige datos incorrectos, contexto incompleto ni una instrucción ambigua. La evaluación de calidad debe acompañar a cualquier optimización.
Una prueba útil
Conserva ejemplos, versión del modelo, hardware y métricas. Repite la prueba tras cambiar precisión, contexto o runtime para saber qué efecto tuvo cada decisión.
Una inferencia útil combina modelo, entrada, contexto, hardware y validación. Cambiar cualquiera de esas piezas puede alterar la salida.
Documenta el conjunto completo.
La salida requiere validación
Trata la respuesta como resultado del modelo, no como una fuente verificada. Comprueba formato, permisos y acciones antes de guardar o ejecutar. Para información cambiante, proporciona fuentes o herramientas que la aplicación pueda comprobar.
Documenta modelo, hardware, precisión, contexto y ejemplos utilizados para medir. Cambiar cualquiera de esas piezas puede alterar la salida.
La aplicación debe registrar errores de contexto, timeouts y formatos inválidos. La inferencia es una etapa de cálculo que necesita controles alrededor.
Un cambio en modelo, contexto, precisión o runtime puede alterar la latencia y la salida. Guarda esos datos junto con la métrica para interpretar correctamente una comparación.
La validación debe acompañar al rendimiento.
Una métrica aislada puede ocultar una regresión de calidad. Conserva ejemplos y resultados para comparar cambios.