El precio por 1M de tokens no significa nada

Límites de “precio por 1M de tokens”

• Muchos consideran que el precio por token, por sí solo, resulta engañoso: los modelos difieren en verbosidad, en los ajustes de “pensamiento”/esfuerzo requeridos, en el uso de herramientas y en el comportamiento de caché, todo lo cual cambia el coste real.
• Las suscripciones distorsionan aún más la fijación de precios: los planes mensuales fijos pueden ofrecer descuentos enormes frente a los tokens bajo demanda, pero los límites de uso suelen ser opacos.
• Otros sostienen que el precio por token sigue siendo una métrica base útil, análoga al precio del combustible o al salario por hora: incompleta, pero hace falta alguna unidad estándar.

Coste por tarea y relevancia de los benchmarks

• Varios comentaristas prefieren “coste por tarea de benchmark” o “coste por prompt” como medidas mejores del coste real.
• Advertencia: los benchmarks deben coincidir con tu carga de trabajo.
  • Si tus tareas son más difíciles que el benchmark, un modelo “barato por tarea” que falla en tu tarea no sirve.
  • Si tus tareas son mucho más fáciles, podrías sobreestimar lo caro que es un modelo más potente.
• Algunos sugieren enrutar tareas a distintos modelos según su complejidad y usar un harness para abstraer la elección del modelo.

Velocidad, UX y verbosidad

• La velocidad y la latencia importan tanto como el coste bruto en tokens, especialmente en tareas interactivas como la generación de mensajes de commit.
• Los modelos verbosos pueden ser más lentos y caros en conjunto, incluso si tienen más tokens por segundo o un precio por token más bajo.
• Para los LLM locales, la velocidad de procesamiento del prompt puede dominar en flujos de trabajo de múltiples turnos o agentivos.

Caché, uso de herramientas y orquestadores

• La caché puede reducir drásticamente los costes efectivos (algunos informes hablan de ~0,1x o de tasas de acierto de caché muy altas), pero la eficiencia varía mucho según el proveedor.
• Las llamadas a herramientas y los marcos de agentes suelen reenviar grandes contextos, multiplicando el uso de tokens; una mala gestión del contexto puede inflar los costes.
• Algunos describen orquestadores estilo Kanban y canalizaciones de agentes en las que modelos más pequeños/más baratos hacen la mayoría de las tareas de trabajo, y los modelos más grandes se usan solo para la planificación.

Modelos abiertos vs. frontera y decisiones de despliegue

• Hay desacuerdo sobre si los modelos abiertos son “suficientemente buenos” para flujos de trabajo agentivos de extremo a extremo; algunos afirman que los modelos de frontera son esenciales, mientras que otros reportan resultados sólidos con modelos abiertos a una fracción del coste.
• Debate sobre infraestructura propia vs. nube: un bando insta a comprar GPUs y optimizar localmente para explorar casos de uso con un coste predecible; otro señala que muchos no tienen hardware ni habilidades y dependen de modelos abiertos alojados.

Escepticismo más amplio y preocupaciones sobre la “burbuja de la IA”

• Algunos subrayan que los LLM no son más que predictores de texto y que el valor real proviene del harness y del diseño del flujo de trabajo, no del modelo en bruto.
• Hay preocupación por sobreoptimizar métricas manipulables y la creencia de que la eficiencia (coste por tarea, tareas por kWh) será lo que más importe si/cuando se desinfle una burbuja de la IA.