Los costos de inferencia de IA, no el entrenamiento, están reconfigurando la economía de servir modelos

El costo de entrenar un modelo de frontera es una cifra que a los periodistas les encanta citar: cientos de millones de dólares, decenas de miles de GPU, meses de tiempo real. También es, para la mayoría de las empresas de IA, la cifra equivocada en la que preocuparse. El entrenamiento ocurre una vez (o unas pocas veces al año, para una actualización). La inferencia ocurre en cada solicitud de usuario, para siempre, y escala con el éxito: cuanto mejor le va a un producto, más cuesta operarlo. Esto invierte una parte de la economía que se mantuvo durante la mayor parte de la historia del software, donde el costo marginal de servir a un usuario más era cercano a cero.

Por eso la inferencia, no el entrenamiento, es la partida que realmente está reconfigurando cómo las empresas de IA construyen productos en 2026. Las empresas que ganan en economía unitaria no son necesariamente las que tienen el mejor modelo, sino las que han reducido al máximo el costo de responder una sola consulta, mediante un conjunto de técnicas ya suficientemente maduras para ser práctica estándar en lugar de curiosidades de investigación.

La aritmética que hace costosa la inferencia

Un paso hacia adelante (forward pass) de un transformer cuesta aproximadamente 2 × número de parámetros × tokens procesados en operaciones de punto flotante. El entrenamiento cuesta aproximadamente tres veces eso por token, porque también ejecuta un paso hacia atrás (backward pass) y una actualización de gradiente — pero el entrenamiento ocurre para un número fijo y acotado de tokens. La inferencia no tiene ese límite; escala con cada consulta de cada usuario, indefinidamente. Un modelo que atiende mil millones de consultas al día consume más cómputo acumulado en semanas que su entrenamiento en meses, una vez que un producto tiene uso real.

La longitud del contexto empeora esto. La caché de clave-valor (KV cache) que un transformer mantiene durante la generación crece con la longitud de la secuencia × número de capas × número de cabezas de atención × dimensión de cada cabeza × tamaño del lote. Si se amplían las ventanas de contexto de 8K a 128K o más — algo que los productos hacen ahora de forma rutinaria — la memoria requerida por solicitud concurrente crece en consecuencia, lo que limita cuántas solicitudes puede atender a la vez una GPU determinada. Ese límite es lo que realmente determina el costo por consulta, más que los FLOPs brutos.

Las técnicas que realmente reducen el costo

La cuantización es la palanca más directa: ejecutar la inferencia en FP8 o INT8 en lugar de FP16/BF16 reduce aproximadamente a la mitad los requisitos de ancho de banda de memoria y puede duplicar o más el rendimiento en el mismo hardware, con una pérdida de precisión cuidadosamente gestionada. INT4 va más allá para modelos donde la pérdida de precisión es tolerable.

Las arquitecturas Mixture-of-Experts (MoE) cambian lo que significa el "tamaño del modelo" a efectos de costo. DeepSeek-V3 tiene 671.000 millones de parámetros totales, pero activa solo unos 37.000 millones por token — se paga cómputo por el subconjunto activo, no por el modelo completo. Esa es la razón principal por la que los modelos MoE pueden ofrecer capacidad de nivel de frontera a una fracción del costo de inferencia de un modelo denso con un total de parámetros equivalente.

Las variantes de atención atacan directamente el problema de la KV-cache. La atención por consultas agrupadas (grouped-query attention, GQA), usada en Llama 3 y muchos modelos actuales, comparte proyecciones de clave/valor entre grupos de cabezas de atención en lugar de dar a cada cabeza su propia proyección, reduciendo el tamaño de la KV-cache varias veces con una pérdida de calidad mínima. La atención latente multi-cabeza (MLA) de DeepSeek comprime aún más la caché, proyectando claves y valores a un espacio latente más pequeño antes de almacenarlos.

La decodificación especulativa añade un modelo "borrador" pequeño y rápido que propone varios tokens por adelantado, los cuales el modelo completo verifica en paralelo en lugar de generar un token a la vez. Cuando el modelo borrador adivina correctamente — algo que ocurre con bastante frecuencia en texto cotidiano — esto reduce la latencia y el tiempo de GPU por token de salida en aproximadamente la mitad a dos tercios, sin pérdida en la calidad de salida (el modelo grande sigue teniendo la última palabra sobre cada token).

En el lado de la infraestructura de servicio, el batching continuo y la gestión paginada de la KV-cache — la técnica que vLLM popularizó como PagedAttention — permiten que un servidor empaquete muchas más solicitudes concurrentes en la misma memoria de GPU, gestionando la asignación de la caché como un sistema de memoria virtual en lugar de reservar un bloque fijo de peor caso por solicitud. Esto es una ganancia puramente de infraestructura: mismo modelo, mismo hardware, un rendimiento significativamente mayor.

Enrutamiento: usar el modelo caro solo cuando es necesario

Una estrategia separada renuncia a optimizar la inferencia de un único modelo y en su lugar optimiza qué modelo responde cada consulta. Una capa de enrutamiento envía consultas simples y de alta confianza a un modelo barato y rápido, y solo escala a un modelo de frontera caro las consultas genuinamente difíciles. Los productos construidos así reportan un costo promedio por consulta muy por debajo de lo que costaría pasar cada consulta por el modelo de gama alta, porque la mayoría de las consultas reales no necesitan el razonamiento de un modelo de frontera: necesitan una respuesta correcta y rápida.

Los problemas financieros de Character.AI — que se declaró en quiebra bajo el Capítulo 11 el 13 de octubre de 2026 — son un caso de estudio útil sobre lo que ocurre cuando esto no se resuelve. Un producto de chat genera un volumen de inferencia enorme por usuario (conversaciones largas, frecuentes y de ida y vuelta), y si el costo de inferencia por mensaje no se reduce agresivamente en relación con lo que pagan los usuarios o lo que generan los anuncios, la economía unitaria simplemente no cierra, sin importar cuán grande crezca la base de usuarios.

Hardware de inferencia especializado

Las GPU de propósito general siguen siendo la opción predeterminada, pero el silicio de inferencia dedicado — el LPU de Groq, el motor a escala de oblea de Cerebras, la arquitectura de flujo de datos de SambaNova — intercambia flexibilidad de entrenamiento por menor latencia y menor costo por token en cargas de trabajo solo de inferencia. Esto importa más en aplicaciones de alto volumen y sensibles a la latencia (asistentes de voz, herramientas de codificación en tiempo real), donde ahorrar milisegundos y centavos por solicitud a gran escala supera la flexibilidad de un acelerador de propósito general.

Conclusiones prácticas

Si estás construyendo un producto sobre una API de LLM, rastrea el costo por 1.000 tokens de salida como tu métrica principal de economía unitaria, no el costo por consulta — el crecimiento silencioso de la longitud del contexto es el asesino silencioso de los márgenes. Fija un presupuesto estricto de longitud de contexto por función en lugar de dejarlo crecer sin control. Usa un modelo barato y rápido por defecto y escala a un modelo caro solo ante incertidumbre detectada o solicitud explícita del usuario de un razonamiento más profundo. Y si estás evaluando proveedores de API, pregunta directamente sobre su estrategia de cuantización, MoE y caché — un proveedor que ejecuta inferencia FP8 MoE con batching consciente de la KV-cache puede ser significativamente más barato que uno que no lo hace, para exactamente la misma calidad nominal de modelo.