Capítulo 9 — Rendimiento, escalado y costos

Esta es la Parte 9 de una serie que recorre LLM Primer I: How Generative AI Works. Ayer recorrimos los patrones de aplicación. Hoy hablamos de cuánto cuesta operarlos realmente — las realidades operativas que determinan si una función de LLM llega a producción o muere silenciosamente en piloto.

Más grande no siempre es mejor

La intuición de que los modelos más grandes son siempre más capaces es mayormente correcta — y mayormente engañosa. Los modelos más grandes sí, en promedio, se desempeñan mejor en la mayoría de los benchmarks. Pero las ganancias se reducen a medida que crece el tamaño del modelo. Un modelo con el doble de parámetros rara vez es el doble de bueno. A menudo es solo marginalmente mejor, mientras cuesta varias veces más operar.

Para muchas aplicaciones reales, un modelo más pequeño con buen prompting, buena recuperación y buena evaluación supera a un modelo más grande dejado caer en una tubería menos ingenieril. Esta es la única información práctica más importante en el Capítulo 9, y el libro se toma el tiempo de defenderla porque va en contra de la narrativa de marketing de cada laboratorio de frontera.

Latencia y throughput tiran en direcciones opuestas

Dos métricas dominan las operaciones de LLM. La latencia es el tiempo desde la solicitud hasta la primera respuesta. El throughput es cuántas solicitudes por segundo puede manejar el sistema.

El compromiso entre ellas es estructural. Para obtener alto throughput, agrupas solicitudes en lotes — ejecutando muchas de ellas a través de la GPU en paralelo. Para obtener baja latencia, procesas cada solicitud individualmente tan pronto como llega. Elige una y sacrificas la otra.

La mayoría de los sistemas reales aterrizan en algún punto intermedio usando una técnica llamada batching continuo, que añade nuevas solicitudes a un lote ya en vuelo. La generación en streaming — devolver tokens al usuario a medida que se producen en lugar de esperar la respuesta completa — ayuda a la latencia percibida incluso cuando el tiempo real de generación no cambia. El libro recorre qué decisiones de diseño son apropiadas para qué tipos de productos.

La ecuación real del costo

Ejecutar un LLM no es como ejecutar software normal, y una de las lecciones más caras al desplegar IA es aprender esto por las malas. Con el software tradicional, una vez que has construido el sistema, los usuarios adicionales son casi gratis; el servidor funciona ya sea que uno o mil usuarios lo estén consultando. Con un LLM, cada solicitud cuesta poder de cómputo real. Los costos escalan linealmente con el uso.

Los principales impulsores de costos son fáciles de enumerar. Las entradas más largas cuestan más (el cálculo de atención escala con la longitud de la entrada). Las salidas más largas cuestan más (cada token de salida requiere otra pasada hacia adelante a través del modelo). Los modelos más grandes cuestan más (más parámetros significa más FLOPs por token). Los modelos de razonamiento cuestan más (generan muchos tokens intermedios antes de la respuesta final). Estos no suman; multiplican.

El libro incluye una tabla de ejemplo trabajado de costos que muestra cómo cambia la factura mensual de una aplicación entre escenarios realistas — chatbot pequeño, RAG de gama media, sistema agéntico con razonamiento. Los números exactos se mueven; la forma de la curva es duradera.

Cuantización, en lenguaje sencillo

Uno de los trucos de ingeniería más poderosos para reducir costos es la cuantización. Los parámetros del modelo normalmente se almacenan como números de punto flotante — a menudo con precisión de 16 bits o 32 bits. La cuantización los almacena con menos precisión, a menudo 8 bits o incluso 4 bits por número, con factores de escala cuidadosamente elegidos que limitan la pérdida de información.

El efecto es dramático. Un modelo cuantizado usa mucha menos memoria, lo que significa que cabe en hardware más pequeño y se ejecuta más rápido (porque el ancho de banda de memoria, no el cómputo crudo, suele ser el cuello de botella). La pérdida de calidad es pequeña si se hace bien — típicamente unos pocos puntos porcentuales en benchmarks, a veces imperceptible en la práctica.

Varias técnicas relacionadas — pruning, destilación, dispersión — empujan la eficiencia aún más allá. La destilación en particular es cómo obtienes un modelo pequeño que imita a uno mucho más grande. El libro cubre cada técnica y cuándo cada una es apropiada.

Despliegue en el borde y en el dispositivo

La mayoría de los LLM en producción se ejecutan en centros de datos en la nube. Algunas aplicaciones no pueden. Asistentes de voz en tiempo real, aplicaciones con restricciones de privacidad estrictas, dispositivos que necesitan funcionar sin conectividad de red — estos se benefician al ejecutar un modelo directamente en el hardware del usuario.

El despliegue en el borde es su propia disciplina de ingeniería. La memoria es limitada. La energía es preciosa. El cómputo disponible es mucho menor que el de un centro de datos. El libro recorre cómo la compresión pesada, la selección cuidadosa del modelo y las arquitecturas híbridas (modelo local pequeño para trabajo rutinario, modelo en la nube para casos difíciles) hacen esto posible.

Lo que prepara el Capítulo 9

Al final del Capítulo 9, puedes modelar el costo y el rendimiento de cualquier aplicación LLM propuesta antes de construirla. Sabes qué decisiones de diseño importan más para el costo, cuáles para la latencia y qué compromisos son negociables frente a fundamentales. Puedes leer páginas de precios de proveedores y entender qué se está cobrando realmente.

Esto prepara la siguiente pregunta natural — una vez que puedes ejecutar un sistema a escala, ¿cómo te aseguras de que deberías hacerlo?

Próximamente — Capítulo 10: Seguridad, ética y confianza. Mañana miramos alucinaciones, sesgo, seguridad de prompts, explicabilidad y los marcos de gobernanza que convierten las aplicaciones de LLM en productos responsables. Incluyendo los controles que usan los despliegues de alto riesgo.