Quien busca «precios de LangChain» suele esperar encontrar una tarifa unitaria. Pero LangChain es un framework de código abierto: lo que genera la factura son la API del modelo, el servicio de embeddings, la base de datos vectorial y la plataforma de observabilidad. Si se miran todos juntos, es fácil llegar a dos conclusiones inexactas: «como el framework es gratis, es barato» o «en cuanto añades un agente, el gasto se descontrola».

Este artículo no enumera tarifas que caducan, sino que propone un método para separar cuentas, estimar y controlar. Los precios de los modelos se rigen por la página de precios de modelos, y los planes comerciales, por la página de cada producto.

Nota: LangChain es una marca de LangChain, Inc. Este artículo solo discute costos y no tiene afiliación ni relación de cooperación con LangChain, Inc.; la licencia de código abierto, los productos comerciales y los precios pueden cambiar, así que consulta el repositorio oficial y las páginas de los productos.

1. El «precio de LangChain» se compone en realidad de cuatro partes

Si se desglosa la factura, suele haber framework y librerías, llamadas al modelo, recuperación y almacenamiento, y observabilidad y despliegue. Cada parte se factura de una forma distinta:

Costo Forma de facturación Cuándo ocurre Punto que se suele pasar por alto
Framework y librerías Código abierto, normalmente sin licencia Instalación y actualización Los productos comerciales de observabilidad, evaluación o despliegue se facturan aparte
Llamadas al modelo Por tokens de entrada y salida En cada solicitud Los reintentos y las llamadas de varios pasos se cobran de nuevo
Embeddings Normalmente por tokens de entrada Al crear el índice y en cada consulta Cambiar de modelo suele obligar a reconstruir el índice
Base vectorial y servidores Suscripción o consumo de recursos Ejecución continua Las instancias inactivas también pueden generar costos
Observabilidad y evaluación Plan, asientos o uso Tras activar la trazabilidad La muestra y la retención influyen en el costo

En la mayoría de los equipos predomina el costo de las llamadas al modelo, pero mirar solo la tarifa unitaria no basta. En proyectos con poco volumen pero con una base vectorial y servicios permanentemente activos, la infraestructura puede ser más visible en la factura.

2. Que el framework sea gratis no significa que el costo total sea bajo

El framework de código abierto de LangChain normalmente no cobra licencia, pero «gratis» describe la licencia, no el costo de ejecución. El gasto incluye también tokens del modelo, embeddings, base vectorial, servidores, plataforma de observabilidad y horas de mantenimiento; los dos primeros crecen con el volumen de llamadas.

Para decidir si sale más barato hay que comparar el costo total de completar la misma tarea, no el precio del framework. El desarrollo propio ahorra la cuota de plataforma pero añade tiempo de mantenimiento; una plataforma gestionada reduce la operación pero la factura varía con el uso.

3. Chain y Agent multiplican los tokens

El costo de una conversación normal se aproxima a «entrada más salida». Chain y Agent son distintos: cada paso puede volver a incluir el prompt del sistema, el historial, la descripción de las herramientas y el resultado del paso anterior.

Supón una entrada de 4000 tokens y una salida de 600 tokens por paso, con 6 pasos de media: la entrada se acerca a 6 copias del contexto, no a una. Si el historial crece con los pasos, los últimos serán aún más largos. Hay tres multiplicadores habituales:

  • Bucles de llamadas a herramientas: llamar a la herramienta, leer el resultado y volver a llamar al modelo; cuantas más vueltas, más contexto repetido.
  • Colaboración entre varios agentes: cada subagente tiene su propio prompt y contexto, y al resumir los resultados se copian otra vez.
  • Reintentos por fallo: los tiempos de espera, los límites de velocidad y los errores de formato provocan reintentos, y una solicitud fallida también puede facturarse.

El control no consiste en usar menos agentes, sino en poner límites al bucle: número máximo de pasos, tiempo de espera, recorte de la salida de las herramientas y colocación de las instrucciones estables al principio para aprovechar la caché. recursion_limit de LangGraph y el número máximo de iteraciones del ejecutor de agentes deben configurarse de forma explícita en producción.

4. RAG: embeddings e inyección de contexto

El costo de RAG tiene dos tramos. En la creación del índice, los documentos se dividen en fragmentos y se genera un vector por fragmento; el costo depende del número de fragmentos, su tamaño y el solapamiento. En la consulta, la pregunta también se convierte en vector y varios fragmentos recuperados se insertan como contexto en el prompt.

Hay tres puntos que se subestiman con facilidad:

  • Reconstrucción del índice: cambiar el modelo de embeddings, ajustar la estrategia de fragmentación o limpiar datos puede obligar a recalcular todos los vectores.
  • Inflación del contexto: subir top_k para mejorar la recuperación añade más texto original en cada ronda y aumenta los tokens de entrada.
  • Modelo de reordenación: añadir una capa de reranking suele mejorar la relevancia, pero introduce llamadas y latencia adicionales.

Lo más económico es optimizar primero la calidad de la recuperación y después la cantidad: mejorar la fragmentación, deduplicar, añadir filtros por metadatos y usar el reranking para descartar fragmentos poco relevantes; solo al final plantearse un modelo más barato. La facturación de embeddings y RAG se trata en las lecturas relacionadas del final.

5. Caché: se ahorra en el prefijo repetido

Hay dos capas de caché con funciones distintas.

La primera es la caché de prefijo del proveedor del modelo. Cuando el inicio de la solicitud coincide, la lectura de caché suele ser más barata que la entrada nueva, pero el soporte, el descuento y el tiempo de retención varían según el proveedor. Lo importante: coloca delante el prompt del sistema, la definición de rol y los documentos fijos, y detrás la pregunta y los datos temporales; cambiar con frecuencia los primeros mensajes o de modelo invalida la caché.

La segunda es la caché a nivel de aplicación. LangChain ofrece mecanismos como set_llm_cache, que guardan el resultado de solicitudes idénticas en memoria, SQLite o Redis; el alcance depende de la integración y la versión, y en los modelos de chat conviene consultar la documentación. Es adecuada para respuestas estables y muy repetidas, no para solicitudes muy personalizadas o en tiempo real. La conveniencia depende de la tasa de aciertos, no de si está activada.

6. Convertir la estimación en una fórmula recalculable

No hagas el presupuesto a ojo. Construye el modelo de costos en seis pasos:

  1. Enumera todas las rutas de llamada al modelo de la aplicación, incluido el flujo principal, los reintentos, los resúmenes y la generación de títulos.
  2. Mide los tokens de entrada y salida de cada paso con los callbacks o el campo de uso de la respuesta.
  3. Calcula el número medio de pasos por tarea exitosa y la proporción de reintentos fallidos.
  4. Lee el precio unitario de la página de precios de modelos y conviértelo todo a una unidad común por millón de tokens.
  5. Suma los costos de embeddings, base vectorial, servidores y observabilidad.
  6. Ajusta el modelo con la factura real del primer mes tras el lanzamiento y corrige los supuestos de pasos y reintentos.

La siguiente función solo hace aritmética; los precios unitarios los completas tú:

import os

# El precio unitario se lee de la página de precios y se guarda en variables de entorno,
# en unidades monetarias por millón de tokens
IN = float(os.environ["PRICE_IN_PER_MTOK"])
OUT = float(os.environ["PRICE_OUT_PER_MTOK"])

def task_cost(input_per_step: int, output_per_step: int, steps: int,
              retry_rate: float = 0.1) -> float:
    calls = steps * (1 + retry_rate)
    return (input_per_step * calls * IN + output_per_step * calls * OUT) / 1_000_000

# Ejemplo: 4000 de entrada y 600 de salida por paso, 6 pasos de media, 10 % de reintentos
print(round(task_cost(4000, 600, 6), 4))

Cuidado con las unidades: la mayoría de las páginas de precios cotiza por millón de tokens, y el código multiplica por el precio unitario y divide entre un millón para no mezclarlo con «por mil tokens».

7. Límites de presupuesto: frenar el exceso antes de que ocurra

La estimación solo predice; el límite pone el respaldo. Configúralo en dos niveles, pasarela y aplicación:

  • En la pasarela, asigna presupuesto, lista de modelos permitidos y límite de velocidad a cada clave, separando claves por proyecto o entorno.
  • En la aplicación, define max_tokens, tiempo de espera de la solicitud y número máximo de reintentos; max_tokens solo limita la salida, y el contexto largo debe controlarse aparte.
  • Fija un número máximo de pasos y un límite de recursión para los agentes, y evita que las llamadas a herramientas entren en bucle.
  • Establece una cuota diaria por usuario o inquilino para que una solicitud anómala no arrastre el presupuesto completo.
  • Configura alertas de uso y avisa a la persona responsable al alcanzar el umbral.

Un límite de presupuesto no desconfía del equipo: convierte una factura impredecible en un borde predecible. Es especialmente necesario en claves de prueba y claves de CI.

8. Observabilidad y revisión: costo unitario por tarea

La factura total solo dice cuánto se gastó, no dónde. Desglosa por tarea, modelo y cadena de llamadas:

  • Los mensajes de respuesta de LangChain suelen incluir usage_metadata, con tokens de entrada, de salida y totales; los campos pueden variar entre proveedores.
  • Un manejador de callbacks puede registrar el tiempo, el nombre del modelo y el uso antes y después de cada llamada, y encaja bien con un sistema de logs existente.
  • Plataformas como LangSmith muestran la cadena completa de llamadas, pero si activarlas, cómo muestrear y cómo se factura el plan debe evaluarse según las necesidades del equipo.

Al revisar, fíjate en el «costo medio por tarea exitosa», no en el «costo por llamada». El primero incluye reintentos fallidos e intervención humana y se acerca más a la economía unitaria real. Con volumen alto, muestrea las trazas para que la observabilidad no se convierta en otra partida de costo.

Preguntas frecuentes

¿LangChain cobra por sí mismo?

El framework de código abierto normalmente no cobra licencia; se publica bajo licencia MIT. Los productos comerciales como LangSmith o las plataformas de despliegue se facturan aparte. La licencia y los planes concretos se rigen por el repositorio oficial y las páginas de los productos.

¿Por qué las pruebas locales son baratas y la factura sube rápido en producción?

En local hay poco volumen, contexto corto y pocos fallos. Al pasar a producción aumentan la concurrencia, los reintentos, las sesiones largas, los bucles de herramientas y el contexto recuperado, y todos ellos multiplican los tokens. Medir el uso real por tarea y multiplicarlo por el volumen de producción suele explicar la diferencia.

¿Cómo se estima el costo de un agente?

Mide primero la entrada y la salida de un paso y después calcula el número medio de pasos y la tasa de reintentos por tarea. Estima con «pasos × uso por paso». Con historial acumulado, la entrada real es mayor. Pon un límite al bucle y ajusta con datos reales de trazabilidad.

¿En qué se va principalmente el costo de RAG?

Normalmente en los tokens de contexto de la fase de generación y, en segundo lugar, en los embeddings de creación del índice. La recuperación y la base vectorial también cuestan, pero no suelen ser lo principal. Ajustar top_k, la fragmentación y el reranking suele dar resultados más rápido que cambiar de modelo.

¿Activar la caché siempre ahorra dinero?

No necesariamente. El beneficio depende de la proporción de solicitudes repetidas y de la estabilidad del prefijo. Con solicitudes dispersas, datos que cambian en tiempo real o mucha personalización, la tasa de aciertos será baja. Estima la tasa con los logs antes de introducir la caché.

Siguiente paso

El costo de LangChain se puede separar en cuatro cuentas: el framework suele ser gratuito, el modelo se factura por tokens, la recuperación y la infraestructura son continuas, y la observabilidad y el despliegue dependen del plan. El orden de control es medir, estimar, fijar límites y calibrar al final con la factura real. Si necesitas una entrada única para varios modelos, estadísticas de uso por clave y gestión de presupuesto, puedes registrarte en ZSQH AI Gateway; los modelos y precios se rigen por la página de precios de modelos.

Lecturas relacionadas: