¿Qué es una calculadora de precios por consulta? Guía de costes de API LLM

Una calculadora de precios por consulta es una herramienta que estima el coste de API de una sola llamada a un modelo de lenguaje grande (LLM). Le indicas el número de tokens de entrada (tu prompt, el contexto y los documentos recuperados), el número esperado de tokens de salida (la respuesta del modelo) y el modelo objetivo. La calculadora multiplica cada uno por la tarifa publicada por token del proveedor y devuelve un coste por consulta, además de un total mensual proyectado según el volumen de llamadas previsto.

Su propósito principal es hacer predecibles los costes de IA. Sin una calculadora de precios es fácil subestimar la rapidez con la que se acumulan los tokens al escalar. Una consulta de 0,012 $ parece insignificante, pero con 10.000 llamadas al día son 120 $ diarios, o 3.600 $ al mes, desde un solo endpoint. Las calculadoras de precios por consulta revelan esto antes de desplegar, no después.

Qué muestra una calculadora de precios por consulta

• Coste por consulta - el importe exacto de una llamada a la API con tus recuentos de tokens y tu modelo.
• Proyecciones diarias y mensuales - escala el coste por consulta a tu volumen de llamadas previsto.
• Desglose de coste de entrada y salida - muestra cuánto del coste viene del prompt y cuánto de la respuesta, ya que los tokens de salida son más caros.
• Comparación de modelos - algunas calculadoras permiten comparar a la vez el coste de la misma consulta en varios modelos.

Los proveedores de LLM cobran por token, una unidad de texto equivalente aproximadamente a 0,75 palabras en inglés (o unos 4 caracteres). Los precios se expresan por millón de tokens ($/M), por separado para entrada y salida. Los tokens de entrada incluyen todo lo que envías: el prompt de sistema, el historial de conversación, el mensaje del usuario, los fragmentos de documentos recuperados de canalizaciones RAG y los esquemas de funciones o herramientas. Los tokens de salida son la respuesta generada por el modelo.

Los tokens de entrada y de salida se facturan por separado. Los de salida cuestan entre 3 y 5 veces más que los de entrada porque generar texto es computacionalmente más caro que procesar contexto.

Por qué los tokens de salida cuestan más

Durante la inferencia, procesar los tokens de entrada requiere una única pasada hacia delante por el modelo. Generar tokens de salida requiere un bucle autorregresivo: el modelo produce un token cada vez y cada paso depende del anterior. Este proceso secuencial consume mucha más GPU por token, y por eso los proveedores aplican un sobreprecio notable a la salida. Con los precios de GPT-4o, los tokens de entrada cuestan 2,50 $/M y los de salida 10,00 $/M, un múltiplo de 4. Esto tiene una implicación práctica directa: las respuestas largas y verbosas cuestan desproporcionadamente más que las concisas.

Cómo se traducen los tokens a longitudes reales de prompt

• Prompt corto + respuesta corta (p. ej. "Clasifica este texto"): ~50-200 tokens en total.
• Mensaje de sistema + consulta con contexto: ~500-2.000 tokens de entrada, 100-500 de salida.
• Consulta RAG con fragmentos de documentos: ~2.000-8.000 tokens de entrada, 300-1.000 de salida.
• Flujo agéntico con resultados de herramientas e historial: ~8.000-32.000 tokens de entrada por llamada.
• Generación extensa (artículo, código): ~1.000-4.000 tokens de entrada, 1.000-4.000 de salida.

Estimar bien los costes por consulta exige conocer tres cifras: el número medio de tokens de entrada por llamada, el número medio de tokens de salida por llamada y tu volumen diario de llamadas. Las dos primeras es mejor medirlas empíricamente con el contador de tokens del proveedor o con el campo `usage` de las respuestas de la API, no estimarlas por número de palabras.

Paso 1: mide el uso real de tokens en desarrollo

Toda respuesta de API de un LLM incluye un objeto `usage` con `prompt_tokens`, `completion_tokens` y `total_tokens`. Registra estos datos durante el desarrollo en una muestra representativa de 50-100 consultas reales. Calcula la media y el percentil 95 tanto de entrada como de salida. Para planificar costes usa el percentil 95 de entrada y la media de salida: así tienes en cuenta contextos grandes atípicos sin sobreestimar la llamada típica.

Paso 2: estima el volumen mensual

Para aplicaciones en producción, estima usuarios activos diarios × consultas medias por sesión × llamadas a la API por consulta. Un chatbot con 1.000 usuarios diarios, 5 mensajes por sesión y 1 llamada a la API por mensaje genera 5.000 llamadas al día. Multiplica tu coste por llamada por el volumen diario y luego por 30 para la proyección mensual. Añade un margen del 30-50 % para picos de tráfico e iteraciones de ingeniería de prompts.

Paso 3: compara entre niveles de modelo

Prueba los mismos recuentos de tokens en varios niveles de modelo para identificar dónde los requisitos de calidad permiten usar uno más barato. Muchas tareas -clasificación, extracción de entidades, resúmenes simples, respuestas de FAQ- alcanzan una calidad aceptable con un modelo más pequeño y barato. Reservar los modelos de frontera (clase GPT-4, clase Claude 3.5 Sonnet) para el subconjunto de tareas que realmente los necesita y enrutar las tareas simples a modelos más baratos suele ser la reducción de costes más rentable.

Los precios de los modelos cambian con frecuencia: los proveedores los han reducido mucho al intensificarse la competencia. La tabla siguiente muestra niveles de precio representativos de mediados de 2026 para ilustrar la estructura de costes. Verifica siempre los precios actuales en la página oficial de cada proveedor antes de construir proyecciones de coste para producción.

La diferencia de coste entre el nivel más barato y el más caro abarca dos órdenes de magnitud. Una aplicación con 10.000 consultas diarias usando un modelo de clase o1 cuesta unos 60-240 $ al día; la misma aplicación con GPT-4o Mini cuesta 1,50-20 $ al día. Las decisiones de enrutado basadas en la complejidad de la tarea -usar un clasificador de consultas para dirigir cada llamada al nivel de modelo adecuado- pueden reducir el gasto total en API un 60-80 % en canalizaciones con complejidad mixta.

Ventana de contexto frente a coste

Las ventanas de contexto grandes permiten incluir más información por consulta, pero más tokens en el prompt significa más coste de entrada. Solo vale la pena usar una ventana de 100.000 tokens si el contexto adicional mejora de verdad la calidad de la respuesta para esa tarea. En la mayoría de aplicaciones de generación aumentada por recuperación (RAG), 2.000-4.000 tokens de contexto recuperado producen resultados casi tan buenos como 20.000 tokens, con un coste de entrada 5-10 veces menor. Compara siempre calidad y longitud de contexto antes de fijar prompts grandes en producción.

La optimización de costes por consulta tiene dos palancas: reducir los tokens por consulta y reducir el precio por token. Las estrategias siguientes abordan ambas y están ordenadas de menor a mayor esfuerzo de implementación.

• Comprime los datos de entrada antes de inyectarlos - convierte payloads JSON, CSV o YAML a formato TOON antes de incluirlos en los prompts. El Conversor JSON a TOON reduce el número de tokens un 30-60 % sin pérdida de información.
• Usa el modelo más barato que cumpla los requisitos - prueba cada tipo de tarea en niveles de modelo menores antes de asumir que necesitas uno de frontera. Muchas tareas de extracción, clasificación y resumen funcionan bien con GPT-4o Mini o Gemini Flash.
• Acorta y depura los prompts de sistema - revisa tu prompt de sistema en busca de instrucciones redundantes, ejemplos de formato largos y advertencias repetidas. Cada token que elimines ahorra dinero en todas las llamadas a la API.
• Limita la longitud de salida con max_tokens - pide respuestas concisas y fija un techo estricto de max_tokens. Los tokens de salida cuestan 3-5 veces los de entrada, así que reducir respuestas verbosas recorta directamente la parte más cara de la factura.
• Activa el caché de prompts - usa el caché nativo del proveedor para prompts de sistema estáticos y ejemplos few-shot. Los tokens cacheados cuestan un 50-90 % menos que los no cacheados en OpenAI y Anthropic.
• Cachea respuestas de consultas frecuentes - para consultas deterministas o casi deterministas, guarda en caché la respuesta del LLM y sírvela ante entradas idénticas repetidas sin hacer llamada a la API.

Compresión de tokens: la vía más rápida al ahorro

En aplicaciones que envían datos estructurados a los LLM -catálogos de productos, registros de usuarios, exportaciones analíticas, respuestas de API-, la compresión de tokens de entrada ofrece la reducción de coste más rápida y constante. Convertir un payload JSON de 2.000 tokens a formato TOON lo reduce a unos 800-1.400 tokens. A 3,00 $/M de tokens de entrada y 50.000 consultas diarias, ese único cambio ahorra 0,09-0,18 $ al día: unos 33-66 $ al mes sin impacto en la calidad. Para datos CSV, el Conversor CSV a TOON logra un ahorro de tokens del 40-60 % en conjuntos tabulares, y el Conversor YAML a TOON cubre la configuración y los datos estructurados en formato YAML.

Para desarrolladores individuales y proyectos pequeños, los costes de tokens rara vez son significativos: 5-20 $ al mes para experimentación y desarrollo. El problema aparece cuando una función escala a volumen de producción, cuando los diseños de prompt incluyen payloads de contexto grandes o cuando una canalización encadena varias llamadas a la API por interacción de usuario. Estos son los escenarios concretos en los que los cálculos de precios por consulta se vuelven críticos.

Canalizaciones agénticas y de varios pasos

Los flujos agénticos que encadenan varias llamadas al LLM -planificación, uso de herramientas, reflexión, resumen- pueden acumular 10.000-100.000 tokens en una sola petición de usuario que parece una única interacción. Cada resultado de herramienta y turno de conversación se reinyecta como contexto para la siguiente llamada, lo que hace que el recuento de tokens crezca de forma cuadrática con el número de pasos. Para estas canalizaciones, estimar el coste por petición exige multiplicar el coste por consulta por el número medio de llamadas al LLM por ejecución.

Aplicaciones RAG con fragmentos de documento grandes

Las canalizaciones de generación aumentada por recuperación inyectan los fragmentos recuperados en cada prompt. Si la estrategia de fragmentación produce fragmentos grandes (1.000-4.000 tokens cada uno) y se recuperan tres a cinco fragmentos por consulta, los tokens de entrada pueden llegar a 5.000-20.000 por llamada antes incluso de incluir la pregunta del usuario. Comprimir los fragmentos recuperados con un formato como TOON -o recortar su tamaño en la canalización de embeddings- reduce directamente el coste por consulta sin cambiar la calidad de la recuperación. Para saber cómo encaja la validación de salidas estructuradas en este tipo de canalización, la guía de Guardrails AI cubre la capa de validación que va después de la recuperación.