Más IA por dólar: la curva sigue bajando

Si tu equipo está evaluando modelos de IA para producción, hay una pregunta que ya no puedes esquivar: cuánto rendimiento compras por cada dólar que gastas. Hace dos años, muchas decisiones se tomaban por pura disponibilidad. Hoy, la conversación cambió. Ya no solo importa qué modelo responde mejor, sino cuánto cuesta servirlo, cuánta latencia deja, qué tan fácil es moverlo a tu propio hardware y cuánto te cobra la nube por cada millón de tokens.

La tendencia es clara: la curva de performance per dollar sigue bajando. Eso significa que, con el mismo presupuesto, puedes procesar más solicitudes, desplegar modelos más grandes o reducir dependencia de APIs externas. Para equipos en LatAm, donde el costo de infraestructura suele sentirse más duro por tipo de cambio, impuestos y menos margen de error, este cambio no es teórico. Afecta decisiones reales de compra, arquitectura y operación.

Qué significa realmente performance per dollar

Cuando hablamos de performance per dollar, no hablamos solo de benchmarks. Hablamos de una relación práctica entre capacidad útil y costo total. Ese costo incluye hardware, energía, refrigeración, licencias, mantenimiento, tiempo del equipo y, si usas nube, el precio por hora o por token. La métrica útil depende de tu caso: tokens por segundo, solicitudes por minuto, precisión aceptable, latencia p95 o throughput por GPU.

En IA, el error común es comparar modelos solo por calidad. Sí, la calidad importa. Pero si dos modelos cumplen tu umbral de precisión y uno cuesta 40% menos de operar, el segundo puede ser mejor negocio aunque no gane en un benchmark aislado. Esto se vuelve todavía más visible en inferencia, donde el gasto es continuo y no una compra única.

La mejora en performance per dollar viene de varias capas al mismo tiempo: modelos más eficientes, kernels mejor optimizados, hardware con mejor relación costo-rendimiento y mejores estrategias de cuantización. No es una sola causa. Es una suma de pequeños avances que, juntos, cambian el punto de equilibrio.

La métrica que sí te sirve para decidir

Si estás evaluando opciones para producción, te conviene mirar al menos estas variables:

1. Costo por 1 millón de tokens de entrada y salida.
2. Latencia p50 y p95 bajo tu carga real.
3. Throughput por GPU o por servidor.
4. Consumo eléctrico estimado por día o por mes.
5. Costo de ingeniería para operar la solución.

No necesitas un laboratorio para medir esto. Con una prueba controlada de 24 a 72 horas, ya puedes ver diferencias claras entre dos stacks. Lo que importa es comparar con tu tráfico real, no con una demo idealizada.

Si quieres una referencia técnica de cómo se exponen estas capacidades en hardware y software, puedes revisar la documentación oficial de NVIDIA sobre TensorRT-LLM y la de AMD sobre ROCm. También vale la pena leer la documentación de vLLM para entender cómo se optimiza serving en modelos grandes: https://docs.vllm.ai/

Por qué la curva está bajando ahora

La razón principal es que la industria dejó de optimizar solo por tamaño de modelo y empezó a optimizar por eficiencia completa. Ya no basta con lanzar un modelo más grande. Ahora hay presión por hacerlo correr mejor, más barato y con menos infraestructura especializada. Eso empuja mejoras en compiladores, cuantización, batching y kernels de atención.

También hay un efecto de madurez. Los modelos open source han mejorado bastante en relación costo-calidad, y eso permitió que más equipos experimenten sin pagar tarifas altas por API desde el día uno. Cuando más gente prueba, más rápido aparecen patrones de optimización. Y cuando aparecen esos patrones, los proveedores de hardware y software los incorporan.

Otro punto clave es que el hardware ya no se vende solo como “más TFLOPs”. Se vende como mejor rendimiento real en inferencia, mejor soporte para tipos de dato reducidos y mejor encaje con stacks de producción. Eso incluye GPUs, aceleradores y toolchains que ayudan a exprimir cada watt.

El peso de la cuantización y el batching

Dos técnicas explican buena parte de la caída en costo: cuantización y batching. La cuantización reduce el tamaño numérico de los pesos y, en muchos casos, baja el consumo de memoria sin destruir la utilidad del modelo. El batching agrupa solicitudes para usar mejor la GPU y subir el throughput.

En la práctica, esto puede cambiar bastante el presupuesto. Un modelo que antes exigía una GPU de mayor memoria puede volverse viable en una tarjeta más barata si aceptas una pequeña pérdida de precisión. Y si además ajustas batching dinámico, puedes mover el cuello de botella desde la memoria hacia el cómputo, que suele ser más eficiente.

La mejora no siempre se ve en una sola cifra. A veces lo que ganas es margen operativo: más usuarios por servidor, menor tiempo de espera o menos necesidad de escalar horizontalmente. Eso también es performance per dollar.

El efecto de los modelos pequeños bien afinados

Durante mucho tiempo, la conversación estaba dominada por modelos gigantes. Hoy, muchos equipos resuelven tareas concretas con modelos más pequeños y mejor afinados. Para clasificación, extracción, soporte interno o copilots de dominio, un modelo compacto puede dar una relación costo-beneficio mucho mejor que uno enorme.

Esto es relevante porque no todas las cargas necesitan el mismo nivel de generalidad. Si tu caso es responder tickets, resumir documentos internos o buscar respuestas sobre una base de conocimiento, probablemente te convenga un modelo más liviano y una buena capa de retrieval. Ahí la eficiencia vale más que la escala bruta.

Qué cambia para tu costo de inferencia

La inferencia es donde la factura se vuelve real. Entrenar un modelo es caro, sí, pero la mayor parte de los equipos termina sintiendo el gasto en servirlo todos los días. Cada llamada, cada token y cada segundo de GPU suman. Si tu producto crece, el costo crece con él.

Por eso la caída en performance per dollar tiene un impacto directo. Si hoy puedes servir el mismo volumen con menos hardware o con instancias más baratas, tu margen mejora. Si puedes mantener el mismo gasto y absorber más tráfico, tu producto escala mejor. Y si puedes bajar latencia sin subir presupuesto, mejoras la experiencia sin reescribir todo.

En LatAm, además, hay una variable extra: los costos no se sienten lineales. Un aumento pequeño en dólares puede traducirse en un salto más fuerte al convertir a moneda local, sobre todo si tu facturación está en moneda doméstica. Por eso optimizar inferencia no es un lujo, es parte de la supervivencia operativa.

Nube, API o despliegue propio

La mejor opción depende de tu volumen y de tu tolerancia al control operativo. Si estás empezando, la API puede ser la vía más rápida. Si tu tráfico se vuelve predecible, el despliegue propio suele ganar por costo. Si tu caso tiene datos sensibles o requisitos de residencia, el despliegue local puede ser el único camino viable.

Una regla simple ayuda a ordenar la decisión:

• Si tu tráfico es bajo e irregular, la API sigue siendo práctica.
• Si tu tráfico es estable y alto, conviene modelar costo por token y evaluar autoservicio.
• Si necesitas control de datos, evalúa infraestructura propia desde el inicio.
• Si tu latencia objetivo es estricta, el despliegue cercano al usuario puede darte ventaja.

No se trata de “nube mala, on-prem bueno”. Se trata de encontrar el punto en el que el costo total y la complejidad operativa se cruzan. En muchos equipos, ese punto llega antes de lo que imaginaban.

Un ejemplo de cálculo simple

Supón que tu producto consume 50 millones de tokens al mes. Si tu costo efectivo baja de 18 dólares por millón a 11 dólares por millón gracias a mejor hardware o mejor serving, tu ahorro mensual sería de 350 dólares. Parece poco hasta que lo multiplicas por 12 meses y por varios servicios.

Ahora imagina que, además, reduces la necesidad de una segunda instancia para picos. El ahorro ya no es solo directo. También evitas sobreaprovisionamiento, simplificas monitoreo y reduces el tiempo que tu equipo dedica a apagar incendios.

Ese tipo de cálculo es el que debes hacer antes de elegir arquitectura. No mires solo el precio del servidor. Mira el costo por solicitud atendida.

Hardware: cómo elegir sin caer en el sticker price

Comprar hardware para IA no es comparar una ficha técnica y listo. El precio de lista engaña bastante. Lo que te interesa es cuánta carga real soporta ese equipo, cuánto consume, qué tan fácil se integra con tu stack y qué tan estable es el soporte de software.

En este punto, AMD y NVIDIA suelen entrar en la conversación por razones distintas. NVIDIA tiene una madurez de ecosistema muy fuerte. AMD ha empujado mejor relación costo-capacidad en varios escenarios, especialmente cuando el software acompaña. La elección correcta depende menos de fanatismo y más de compatibilidad con tu caso de uso.

Si trabajas con modelos grandes, revisa memoria, ancho de banda, soporte de precisión reducida y compatibilidad con tus frameworks. Si tu carga es más moderada, quizá te convenga priorizar densidad, costo por servidor y facilidad de abastecimiento local. En LatAm, la disponibilidad real pesa tanto como la especificación.

Qué revisar antes de comprar

Antes de firmar una orden de compra, revisa estos puntos:

1. Memoria disponible por tarjeta y ancho de banda efectivo.
2. Compatibilidad con PyTorch, vLLM, TensorRT-LLM o el stack que uses.
3. Consumo eléctrico y requisitos de enfriamiento.
4. Soporte del proveedor en tu país o región.
5. Tiempo estimado de entrega y repuestos.
6. Costo total durante 24 meses, no solo el inicial.

Si el proveedor te vende solo “capacidad”, pide números de inferencia bajo cargas parecidas a las tuyas. Pregunta por batch size, contexto, cuantización y latencia. Sin eso, no estás comparando rendimiento real.

La importancia del software de serving

El hardware solo cuenta si el software lo aprovecha. Un servidor bien configurado puede rendir mucho mejor que uno más caro mal servido. Herramientas como vLLM, TensorRT-LLM o stacks basados en ROCm pueden cambiar bastante la ecuación, dependiendo del modelo y del formato de despliegue.

La documentación oficial de AMD sobre ROCm es un buen punto de partida si estás evaluando su ecosistema: https://rocm.docs.amd.com/. Si te interesa optimizar serving de modelos, también revisa la documentación de TensorRT-LLM: https://docs.nvidia.com/deeplearning/tensorrt-llm/. La diferencia entre una prueba de laboratorio y un entorno productivo suele estar ahí, en el software que realmente alimenta la GPU.

Qué deberían hacer los equipos en LatAm

Si lideras producto, infraestructura o data, no necesitas esperar a que el mercado “se estabilice”. Lo que necesitas es un proceso de evaluación simple y repetible. La mejora en performance per dollar no significa que todo sea automáticamente barato. Significa que tienes más opciones para construir con menos fricción.

Para equipos en Ecuador, Colombia, México, Perú o Chile, esto puede traducirse en algo concreto: menos dependencia de una sola nube, más capacidad de negociación con proveedores y más margen para desplegar cerca del usuario o dentro de tu propia red. También ayuda a reducir riesgo cambiario, porque no todo queda atado a facturas variables de API.

La clave es medir antes de escalar. Si no mides, terminas optimizando por intuición y pagando de más. Si mides bien, puedes decidir con datos si te conviene seguir en API, pasar a un modelo open source afinado o comprar hardware propio.

Un plan práctico de 30 días

Puedes ordenar el trabajo así:

1. Define una carga real de prueba con 1 o 2 casos de uso concretos.
2. Mide tokens por segundo, latencia p95 y costo por millón de tokens.
3. Compara al menos dos opciones: API y despliegue propio.
4. Prueba cuantización o un modelo más pequeño con el mismo flujo.
5. Calcula el costo mensual proyectado con tu tráfico esperado.
6. Decide con un umbral claro de calidad mínima aceptable.

Si haces esto bien, tu siguiente compra de infraestructura será mucho menos intuitiva y mucho más defendible frente a finanzas o dirección. Y eso importa, porque la discusión ya no es si usar IA, sino cómo usarla sin que el costo te coma el margen.

Tabla resumen

La tendencia de fondo no parece frenarse: cada generación de modelos, herramientas y hardware está empujando más rendimiento por dólar. Eso no significa que todo sea barato. Significa que el umbral para hacer IA útil se está moviendo hacia abajo, y eso abre espacio para más equipos, más productos y más despliegues locales.

Si hoy tu organización todavía compra IA como si fuera una caja negra costosa, probablemente estás dejando dinero sobre la mesa. Si empiezas a medir costo por token, latencia real y eficiencia del hardware, vas a notar rápido dónde se te está yendo el presupuesto.