Aprende
El glosario de la infraestructura de IA
Definiciones claras y técnicas de los conceptos detrás del costo de la infraestructura de IA, y lo que cada uno significa para tu factura, tu elección de GPU y tu arquitectura.
Empieza por aquí
LLM y API 11
API batchUn modo asíncrono que ofrecen la mayoría de los proveedores de LLM: envías un archivo de peticiones, obtienes los resultados dentro de un plazo (normalmente 24 h) y pagas aproximadamente el 50% del precio por token normal.Precio mixto de tokenUna cifra única por millón de tokens que combina los precios de entrada y salida a una proporción asumida, para poder ordenar los modelos en una sola columna. Obolith pondera la entrada 3× frente a la salida.Precio de entrada en cachéUn descuento sobre los tokens de entrada que se repiten entre llamadas: un prompt de sistema estable, ejemplos few-shot, un documento largo. El prefijo en caché se factura a aproximadamente el 10-25% de la tarifa de entrada normal.Ventana de contextoEl número máximo de tokens que un modelo puede considerar a la vez, prompt más respuesta combinados. Los tamaños habituales van de 8K a más de 1M de tokens.Costo por millón de tokensLa unidad estándar para el precio de las API de LLM. Se indica por separado para entrada y salida, en USD por cada 1.000.000 de tokens.EmbeddingUna lista de números (un vector) que representa el significado de un fragmento de texto, de modo que los significados parecidos quedan cerca unos de otros. La pieza básica de la búsqueda semántica y del RAG.Tokens de entradaLos tokens que envías al modelo: prompt de sistema, historial de la conversación, contexto recuperado y el mensaje del usuario. Normalmente la mitad más barata de la factura.Tokens de salidaLos tokens que un modelo genera en su respuesta. Normalmente la mitad cara de la factura (2 a 5 veces el precio de entrada) porque cada uno requiere una pasada hacia delante completa.Caché de promptReutilizar el estado ya calculado de un prefijo de prompt repetido en lugar de recalcularlo en cada llamada. En las API se traduce en una tarifa reducida de «lectura de caché»; en self-host es una función del servidor (prefix caching).RAG (generación aumentada por recuperación)Responder con un LLM recuperando primero fragmentos relevantes de tus propios datos y metiéndolos en el prompt. Más barato y más actual que meterlo todo en una ventana de contexto enorme.TokenLa unidad que un LLM lee y escribe. Aproximadamente 3-4 caracteres de inglés, o unas 0,75 palabras. Toda factura de API se cuenta en tokens.
Inferencia 17
Arranque en fríoEl retraso cuando un endpoint serverless o escalado a cero tiene que cargar un modelo en la memoria de la GPU antes de poder responder a la primera petición. Puede ser de segundos a minutos para modelos grandes.ConcurrenciaCuántas peticiones maneja un modelo a la vez. Más concurrencia sube el rendimiento y la eficiencia de costo, pero está topada por la VRAM porque cada petición en curso necesita su propio KV cache.Ventana de contextoEl número máximo de tokens que un modelo puede considerar a la vez, prompt más respuesta combinados. Los tamaños habituales van de 8K a más de 1M de tokens.Batching continuoUna técnica de servidor de inferencia que añade y quita peticiones del batch en curso token a token, en lugar de esperar a que termine un batch entero. Multiplica varias veces el rendimiento de la GPU con la misma latencia.InferenciaEjecutar un modelo ya entrenado para obtener una respuesta, en contraposición a entrenarlo. Se divide en una fase de prefill (leer el prompt) y una fase de decodificación (escribir la respuesta un token cada vez).KV cacheMemoria que guarda las claves y valores de atención de cada token ya procesado, para que el modelo no los recalcule en cada nuevo token de salida. Vive en la VRAM y crece con la longitud del contexto y la concurrencia.LatenciaTiempo total desde la petición hasta la respuesta completa. Para un LLM es aproximadamente TTFT más (tokens de salida / tokens por segundo), más la sobrecarga de red.Mezcla de expertos (MoE)Una arquitectura de modelo donde cada token se enruta solo a unos pocos de muchas subredes «expertas». El total de parámetros es enorme, pero el cómputo por token es pequeño, y por eso estos modelos son baratos de servir.Multi-GPURepartir un modelo entre varias GPU cuando no cabe en una. Añade costo y sobrecarga de comunicación, y necesita una interconexión rápida como NVLink para seguir siendo eficiente.CuantizaciónGuardar los pesos del modelo (y a veces las activaciones o el KV cache) a menor precisión numérica (8 bits, 4 bits) para reducir el uso de memoria y acelerar la generación, normalmente con un pequeño costo de calidad.Self-hosting (autoalojamiento)Ejecutar un modelo de pesos abiertos en GPU que alquilas o posees, en lugar de llamar a la API de un proveedor. Cambias una factura por token por una factura por hora más esfuerzo de ingeniería.Inferencia serverlessUn endpoint de GPU alojado que escala con tu tráfico, incluso hasta cero. Pagas por petición o por segundo de cómputo, no por una máquina siempre encendida, a cambio de arranques en frío.Decodificación especulativaUn truco de velocidad: un modelo pequeño y rápido propone varios tokens, el modelo grande los verifica todos en una sola pasada y conserva aquellos con los que coincide. Generación 2-3× más rápida, con salida idéntica.Rendimiento (throughput)Cuánto trabajo hace un sistema por unidad de tiempo: peticiones por segundo, o tokens totales por segundo entre todos los usuarios concurrentes. La cifra que decide la eficiencia de costo al hacer self-hosting.Tiempo hasta el primer token (TTFT)Cuánto espera un usuario entre que envía una petición y ve aparecer la primera palabra. Lo domina la fase de prefill, así que crece con la longitud del prompt.Tokens por segundoLa velocidad a la que un modelo genera salida una vez ha empezado. Fija cuánto tarda una respuesta completa y, en una GPU autoalojada, determina el costo por token.VRAMLa memoria dedicada de una GPU. Tiene que contener los pesos del modelo, el KV cache de cada petición en curso y las activaciones. Cuando se agota, necesitas una GPU más grande, más GPU o un modelo más pequeño.
GPU y hardware 9
FP16 / BF16Formatos de coma flotante de 16 bits. La precisión por defecto para servir modelos grandes: ~2 bytes por parámetro. BF16 cambia bits de mantisa por rango y es el estándar en la etapa de entrenamiento.FP8Coma flotante de 8 bits. Reduce a la mitad la memoria frente a 16 bits manteniendo un rango de coma flotante, así que la pérdida de calidad suele ser menor que con el INT8 entero. Necesita soporte de hardware (Hopper, Blackwell, MI300).GPUUn procesador con miles de núcleos en paralelo y memoria muy rápida en el mismo paquete. El caballo de batalla tanto del entrenamiento como de la inferencia de modelos grandes.GPU-horaLa unidad para alquilar cómputo de GPU: el costo de una GPU durante una hora. Obolith normaliza cada oferta a precio por GPU-hora para poder comparar de forma justa las instancias multi-GPU.HBMHigh Bandwidth Memory: la memoria apilada que se usa como VRAM en las GPU de centro de datos. Lo que fija la velocidad de generación de un LLM es su ancho de banda (TB/s), no su capacidad.KV cacheMemoria que guarda las claves y valores de atención de cada token ya procesado, para que el modelo no los recalcule en cada nuevo token de salida. Vive en la VRAM y crece con la longitud del contexto y la concurrencia.Multi-GPURepartir un modelo entre varias GPU cuando no cabe en una. Añade costo y sobrecarga de comunicación, y necesita una interconexión rápida como NVLink para seguir siendo eficiente.CuantizaciónGuardar los pesos del modelo (y a veces las activaciones o el KV cache) a menor precisión numérica (8 bits, 4 bits) para reducir el uso de memoria y acelerar la generación, normalmente con un pequeño costo de calidad.VRAMLa memoria dedicada de una GPU. Tiene que contener los pesos del modelo, el KV cache de cada petición en curso y las activaciones. Cuando se agota, necesitas una GPU más grande, más GPU o un modelo más pequeño.
Rendimiento 10
Arranque en fríoEl retraso cuando un endpoint serverless o escalado a cero tiene que cargar un modelo en la memoria de la GPU antes de poder responder a la primera petición. Puede ser de segundos a minutos para modelos grandes.ConcurrenciaCuántas peticiones maneja un modelo a la vez. Más concurrencia sube el rendimiento y la eficiencia de costo, pero está topada por la VRAM porque cada petición en curso necesita su propio KV cache.Ventana de contextoEl número máximo de tokens que un modelo puede considerar a la vez, prompt más respuesta combinados. Los tamaños habituales van de 8K a más de 1M de tokens.InferenciaEjecutar un modelo ya entrenado para obtener una respuesta, en contraposición a entrenarlo. Se divide en una fase de prefill (leer el prompt) y una fase de decodificación (escribir la respuesta un token cada vez).KV cacheMemoria que guarda las claves y valores de atención de cada token ya procesado, para que el modelo no los recalcule en cada nuevo token de salida. Vive en la VRAM y crece con la longitud del contexto y la concurrencia.LatenciaTiempo total desde la petición hasta la respuesta completa. Para un LLM es aproximadamente TTFT más (tokens de salida / tokens por segundo), más la sobrecarga de red.Tokens de salidaLos tokens que un modelo genera en su respuesta. Normalmente la mitad cara de la factura (2 a 5 veces el precio de entrada) porque cada uno requiere una pasada hacia delante completa.Rendimiento (throughput)Cuánto trabajo hace un sistema por unidad de tiempo: peticiones por segundo, o tokens totales por segundo entre todos los usuarios concurrentes. La cifra que decide la eficiencia de costo al hacer self-hosting.Tiempo hasta el primer token (TTFT)Cuánto espera un usuario entre que envía una petición y ve aparecer la primera palabra. Lo domina la fase de prefill, así que crece con la longitud del prompt.Tokens por segundoLa velocidad a la que un modelo genera salida una vez ha empezado. Fija cuánto tarda una respuesta completa y, en una GPU autoalojada, determina el costo por token.
Optimización 11
API batchUn modo asíncrono que ofrecen la mayoría de los proveedores de LLM: envías un archivo de peticiones, obtienes los resultados dentro de un plazo (normalmente 24 h) y pagas aproximadamente el 50% del precio por token normal.Precio de entrada en cachéUn descuento sobre los tokens de entrada que se repiten entre llamadas: un prompt de sistema estable, ejemplos few-shot, un documento largo. El prefijo en caché se factura a aproximadamente el 10-25% de la tarifa de entrada normal.Batching continuoUna técnica de servidor de inferencia que añade y quita peticiones del batch en curso token a token, en lugar de esperar a que termine un batch entero. Multiplica varias veces el rendimiento de la GPU con la misma latencia.FP16 / BF16Formatos de coma flotante de 16 bits. La precisión por defecto para servir modelos grandes: ~2 bytes por parámetro. BF16 cambia bits de mantisa por rango y es el estándar en la etapa de entrenamiento.FP8Coma flotante de 8 bits. Reduce a la mitad la memoria frente a 16 bits manteniendo un rango de coma flotante, así que la pérdida de calidad suele ser menor que con el INT8 entero. Necesita soporte de hardware (Hopper, Blackwell, MI300).INT4Cuantización entera de 4 bits. Reduce el tamaño del modelo a aproximadamente un cuarto del de 16 bits. Gran ahorro de costo, pero la pérdida de calidad es más notable y depende del modelo: pruébalo antes de confiar en ella.INT8Cuantización entera de 8 bits. Reduce aproximadamente a la mitad el tamaño del modelo frente a 16 bits, con una pérdida de calidad pequeña, a menudo despreciable para cargas de tipo chat. Muy soportada.Mezcla de expertos (MoE)Una arquitectura de modelo donde cada token se enruta solo a unos pocos de muchas subredes «expertas». El total de parámetros es enorme, pero el cómputo por token es pequeño, y por eso estos modelos son baratos de servir.Caché de promptReutilizar el estado ya calculado de un prefijo de prompt repetido en lugar de recalcularlo en cada llamada. En las API se traduce en una tarifa reducida de «lectura de caché»; en self-host es una función del servidor (prefix caching).CuantizaciónGuardar los pesos del modelo (y a veces las activaciones o el KV cache) a menor precisión numérica (8 bits, 4 bits) para reducir el uso de memoria y acelerar la generación, normalmente con un pequeño costo de calidad.Decodificación especulativaUn truco de velocidad: un modelo pequeño y rápido propone varios tokens, el modelo grande los verifica todos en una sola pasada y conserva aquellos con los que coincide. Generación 2-3× más rápida, con salida idéntica.
Infraestructura en la nube 9
API frente a self-hostingLa decisión de infraestructura central para quien ejecuta LLM a escala: pagar por token a un proveedor, o pagar por hora por GPU que tú operas. La respuesta depende del volumen, la utilización y cuánto control necesitas.Arranque en fríoEl retraso cuando un endpoint serverless o escalado a cero tiene que cargar un modelo en la memoria de la GPU antes de poder responder a la primera petición. Puede ser de segundos a minutos para modelos grandes.Egress (salida de datos)La tarifa que cobran las nubes por sacar datos de su red hacia internet. El almacenamiento es barato; sacar tus datos de vuelta es donde se dispara la factura del almacenamiento de objetos.GPU-horaLa unidad para alquilar cómputo de GPU: el costo de una GPU durante una hora. Obolith normaliza cada oferta a precio por GPU-hora para poder comparar de forma justa las instancias multi-GPU.Instancia on-demandUna GPU en la nube que alquilas por hora o por segundo sin compromiso, a la tarifa estándar. Disponible al instante, facturada solo mientras se ejecuta, pero la más cara por hora.Self-hosting (autoalojamiento)Ejecutar un modelo de pesos abiertos en GPU que alquilas o posees, en lugar de llamar a la API de un proveedor. Cambias una factura por token por una factura por hora más esfuerzo de ingeniería.Inferencia serverlessUn endpoint de GPU alojado que escala con tu tráfico, incluso hasta cero. Pagas por petición o por segundo de cómputo, no por una máquina siempre encendida, a cambio de arranques en frío.Instancia spotCapacidad sobrante de GPU en la nube vendida con un descuento fuerte (a menudo 50-80% sobre el on-demand) que el proveedor puede retirar con poco aviso. Buena para trabajo interrumpible, arriesgada para servicio en vivo.Tasa de utilizaciónLa parte del tiempo que una GPU alquilada hace trabajo útil en lugar de estar parada. La cifra que decide si el self-hosting supera a una API.
Entrenamiento y fine-tuning 7
Época (epoch)Una pasada completa del conjunto de entrenamiento por el modelo. Las ejecuciones de fine-tuning suelen ser de 1 a 4 épocas; cada época extra multiplica el costo de GPU de la ejecución y, pasado un punto, provoca sobreajuste.Fine-tuningSeguir entrenando un modelo existente con tus propios ejemplos para que se adapte a una tarea, un estilo o un formato. Más barato y rápido que entrenar desde cero; sigue siendo un costo de GPU que pagas una vez por ejecución.Fine-tuning completoUn fine-tuning que actualiza todos los pesos del modelo, no un pequeño adaptador. El techo de calidad más alto, pero necesita varias veces el tamaño del modelo en VRAM y normalmente un nodo multi-GPU.LoRALow-Rank Adaptation: un fine-tuning que congela el modelo base y en su lugar entrena un pequeño par de matrices por capa. ~0,1-1% de parámetros entrenables, así que cabe en una GPU y se ejecuta en minutos u horas.Multi-GPURepartir un modelo entre varias GPU cuando no cabe en una. Añade costo y sobrecarga de comunicación, y necesita una interconexión rápida como NVLink para seguir siendo eficiente.Ajuste por preferencias (RLHF, DPO)Una segunda etapa de entrenamiento que enseña al modelo cuál de dos respuestas prefiere la gente, en lugar de una única respuesta objetivo. RLHF usa un modelo de recompensa + aprendizaje por refuerzo; DPO lo hace de forma directa y barata.QLoRALoRA sobre un modelo base que se ha cuantizado a 4 bits. Reduce la VRAM necesaria para el fine-tuning en ~3-4×, así que un modelo de 70B se ajusta en una sola GPU de 48 GB en lugar de un nodo multi-GPU.
Embeddings y bases vectoriales 5
Fragmentación (chunking)Dividir los documentos en pasajes más pequeños antes de hacer sus embeddings para RAG. El tamaño del fragmento equilibra la precisión de recuperación frente a la completitud del contexto, y afecta directamente al número de vectores y al costo.EmbeddingUna lista de números (un vector) que representa el significado de un fragmento de texto, de modo que los significados parecidos quedan cerca unos de otros. La pieza básica de la búsqueda semántica y del RAG.Modelo de embeddingsUn modelo especializado en producir embeddings en lugar de generar texto. Se elige por la calidad de recuperación (puntuación MTEB), las dimensiones del vector, la longitud máxima de entrada y el precio.RAG (generación aumentada por recuperación)Responder con un LLM recuperando primero fragmentos relevantes de tus propios datos y metiéndolos en el prompt. Más barato y más actual que meterlo todo en una ventana de contexto enorme.Base de datos vectorialUna base de datos hecha para almacenar embeddings y encontrar rápido los más cercanos a un vector de consulta. El centro de costo recurrente de un sistema RAG.
Almacenamiento 2
Egress (salida de datos)La tarifa que cobran las nubes por sacar datos de su red hacia internet. El almacenamiento es barato; sacar tus datos de vuelta es donde se dispara la factura del almacenamiento de objetos.Base de datos vectorialUna base de datos hecha para almacenar embeddings y encontrar rápido los más cercanos a un vector de consulta. El centro de costo recurrente de un sistema RAG.
Economía y precios 22
API frente a self-hostingLa decisión de infraestructura central para quien ejecuta LLM a escala: pagar por token a un proveedor, o pagar por hora por GPU que tú operas. La respuesta depende del volumen, la utilización y cuánto control necesitas.API batchUn modo asíncrono que ofrecen la mayoría de los proveedores de LLM: envías un archivo de peticiones, obtienes los resultados dentro de un plazo (normalmente 24 h) y pagas aproximadamente el 50% del precio por token normal.Precio mixto de tokenUna cifra única por millón de tokens que combina los precios de entrada y salida a una proporción asumida, para poder ordenar los modelos en una sola columna. Obolith pondera la entrada 3× frente a la salida.Punto de equilibrioEl nivel de volumen o de utilización en el que dos opciones cuestan lo mismo, normalmente API frente a self-hosting, o alquilar frente a comprar una GPU. Por debajo gana una opción; por encima, la otra.Precio de entrada en cachéUn descuento sobre los tokens de entrada que se repiten entre llamadas: un prompt de sistema estable, ejemplos few-shot, un documento largo. El prefijo en caché se factura a aproximadamente el 10-25% de la tarifa de entrada normal.ConcurrenciaCuántas peticiones maneja un modelo a la vez. Más concurrencia sube el rendimiento y la eficiencia de costo, pero está topada por la VRAM porque cada petición en curso necesita su propio KV cache.Costo por millón de tokensLa unidad estándar para el precio de las API de LLM. Se indica por separado para entrada y salida, en USD por cada 1.000.000 de tokens.Egress (salida de datos)La tarifa que cobran las nubes por sacar datos de su red hacia internet. El almacenamiento es barato; sacar tus datos de vuelta es donde se dispara la factura del almacenamiento de objetos.GPU-horaLa unidad para alquilar cómputo de GPU: el costo de una GPU durante una hora. Obolith normaliza cada oferta a precio por GPU-hora para poder comparar de forma justa las instancias multi-GPU.Tokens de entradaLos tokens que envías al modelo: prompt de sistema, historial de la conversación, contexto recuperado y el mensaje del usuario. Normalmente la mitad más barata de la factura.Mezcla de expertos (MoE)Una arquitectura de modelo donde cada token se enruta solo a unos pocos de muchas subredes «expertas». El total de parámetros es enorme, pero el cómputo por token es pequeño, y por eso estos modelos son baratos de servir.Instancia on-demandUna GPU en la nube que alquilas por hora o por segundo sin compromiso, a la tarifa estándar. Disponible al instante, facturada solo mientras se ejecuta, pero la más cara por hora.Tokens de salidaLos tokens que un modelo genera en su respuesta. Normalmente la mitad cara de la factura (2 a 5 veces el precio de entrada) porque cada uno requiere una pasada hacia delante completa.Caché de promptReutilizar el estado ya calculado de un prefijo de prompt repetido en lugar de recalcularlo en cada llamada. En las API se traduce en una tarifa reducida de «lectura de caché»; en self-host es una función del servidor (prefix caching).RAG (generación aumentada por recuperación)Responder con un LLM recuperando primero fragmentos relevantes de tus propios datos y metiéndolos en el prompt. Más barato y más actual que meterlo todo en una ventana de contexto enorme.Self-hosting (autoalojamiento)Ejecutar un modelo de pesos abiertos en GPU que alquilas o posees, en lugar de llamar a la API de un proveedor. Cambias una factura por token por una factura por hora más esfuerzo de ingeniería.Inferencia serverlessUn endpoint de GPU alojado que escala con tu tráfico, incluso hasta cero. Pagas por petición o por segundo de cómputo, no por una máquina siempre encendida, a cambio de arranques en frío.Instancia spotCapacidad sobrante de GPU en la nube vendida con un descuento fuerte (a menudo 50-80% sobre el on-demand) que el proveedor puede retirar con poco aviso. Buena para trabajo interrumpible, arriesgada para servicio en vivo.Rendimiento (throughput)Cuánto trabajo hace un sistema por unidad de tiempo: peticiones por segundo, o tokens totales por segundo entre todos los usuarios concurrentes. La cifra que decide la eficiencia de costo al hacer self-hosting.TokenLa unidad que un LLM lee y escribe. Aproximadamente 3-4 caracteres de inglés, o unas 0,75 palabras. Toda factura de API se cuenta en tokens.Tokens por segundoLa velocidad a la que un modelo genera salida una vez ha empezado. Fija cuánto tarda una respuesta completa y, en una GPU autoalojada, determina el costo por token.Tasa de utilizaciónLa parte del tiempo que una GPU alquilada hace trabajo útil en lugar de estar parada. La cifra que decide si el self-hosting supera a una API.