API con precio por token frente a un modelo local en Docker: cómo comparar costes de verdad

Por qué preguntarse ahora por el precio por token

La pregunta de si conviene pagar la IA a través de una API o ejecutar el modelo en infraestructura propia reaparece cada vez que un piloto se convierte en un servicio de producción. Al principio gana la API: no hay infraestructura, no hay que esperar hardware y la factura son unos pocos dólares. Pero a medida que crece el volumen, alguien empieza a leer la factura y aparece la tentación de lanzar el modelo en local, por ejemplo en Docker. Este artículo no ofrece un ganador universal. Muestra cómo comparar ambos enfoques con honestidad, qué variables deben entrar en el cálculo y cuándo cada opción es razonable. Los precios concretos y los datos técnicos proceden únicamente de la documentación oficial citada en el texto; en lo que cambia rápido (precios, modelos), verifique siempre el estado actual con el proveedor.

Cómo funciona la tarificación por token

La API de pago cobra por consumo: por separado los tokens de entrada y los de salida, normalmente en unidades por millón de tokens (MTok). La documentación de Anthropic expresa los precios en USD y subraya que los valores vigentes deben comprobarse en su sitio web (https://platform.claude.com/docs/en/about-claude/pricing). De la tabla se desprenden varios patrones fundamentales:

• La salida es bastante más cara que la entrada. En los modelos de esa documentación, el precio de los tokens de salida es varias veces el de los de entrada (por ejemplo, en la serie Sonnet 5.5 son 2 USD de entrada y 10 USD de salida por MTok). Las aplicaciones que generan respuestas largas pagan, por tanto, de forma distinta a las que sobre todo clasifican o extraen.
• El precio varía según la clase de modelo. La documentación ordena los modelos desde los más baratos, pensados para alto volumen y baja latencia (clasificación, extracción, enrutamiento), hasta los más caros, para razonamiento exigente y tareas agénticas largas. La diferencia entre la clase más barata y la más cara es, en la tabla, de órdenes de magnitud.
• El prompt caching cambia la ecuación. Leer de la caché cuesta una fracción del precio base de entrada, mientras que escribir en la caché cuesta más que una entrada normal. Si envía repetidamente el mismo prompt de sistema o el mismo contexto largo, el precio efectivo de la entrada puede ser mucho menor que el de lista.
• El precio puede depender de la longitud del prompt. En el modelo más barato de la tabla hay una tarifa para prompts de hasta 100 000 tokens y otra distinta por encima de ese umbral.
• Los endpoints regionales y multirregionales pueden tener recargo. La documentación indica un recargo del diez por ciento frente a los endpoints globales en algunas plataformas en la nube; si necesita residencia de datos, cuente con ello.

Una trampa importante para la planificación: la documentación advierte de que los modelos más nuevos usan un tokenizador distinto que produce aproximadamente un 30 % más de tokens para el mismo texto, y que el aumento exacto depende del contenido y del tipo de carga (https://platform.claude.com/docs/en/about-claude/pricing). Pasar a un modelo más reciente no implica, pues, solo un cambio en la tarifa de lista, sino también en el número de tokens por tarea. Por eso no base la estimación de costes en el número de caracteres ni en la experiencia con otro modelo.

Cómo medir el consumo antes de pagarlo

Una comparación honesta empieza por medir, no por estimar. La API ofrece un endpoint de conteo de tokens que acepta la misma estructura de entrada que la creación de un mensaje, incluidos prompts de sistema, herramientas, imágenes y PDF, y devuelve el total de tokens de entrada (https://platform.claude.com/docs/en/build-with-claude/token-counting). La documentación lo recomienda para controlar límites y costes, para decidir el enrutamiento entre modelos y para ajustar los prompts a una longitud objetivo.

Procedimiento práctico:

1. Tome una muestra representativa de peticiones reales (no ejemplos sintéticos). 2. Cuente los tokens de entrada para cada modelo que esté considerando, porque, al haber tokenizadores distintos, las cifras no son transferibles. 3. Mida la longitud real de las salidas, ya que en una API suelen ser la mayor parte de la factura y el contador de entrada no la refleja. 4. Multiplique por el volumen mensual y desglose según cuánta entrada se puede cachear.

Con esto obtiene la base de la variante API. Para la variante local hace falta otro conjunto de cifras, como se explica a continuación.

Modelo local en Docker: qué implica realmente

Docker ofrece Docker Model Runner, una herramienta para ejecutar modelos dentro del ecosistema Docker (https://docs.docker.com/ai/model-runner/). Para los servicios que necesitan aceleración, la documentación de Docker describe cómo lanzar en Compose servicios con acceso a la GPU (https://docs.docker.com/compose/gpu-support/). Las páginas, en los extractos disponibles, no contienen detalles sobre rendimiento ni sobre modelos concretos admitidos, por lo que aquí no afirmo nada sobre el rendimiento, la latencia o la calidad de modelos locales concretos. Esos parámetros hay que medirlos en el propio hardware.

Lo importante es entender que el despliegue local cambia la naturaleza de los costes. De costes variables (pago por cada token) se pasa a costes mayoritariamente fijos (pago el hardware y la operación aunque no lo use). En el cálculo deben entrar:

• Hardware: compra o alquiler de GPU, además de servidores, refrigeración y energía.
• Utilización: una máquina utilizada al 10 % tiene un coste efectivo por token unas diez veces mayor que una utilizada al 100 %. La regularidad de la carga es aquí decisiva.
• Trabajo humano: instalación, actualizaciones, monitorización, parches de seguridad, gestión de caídas. Esta partida se subestima a menudo en los cálculos.
• Calidad del modelo: un modelo local puede no alcanzar la calidad de un modelo de pago de primer nivel. Si por ello necesita más intentos, revisión manual o prompts más complejos, sube el coste del resultado correcto, aunque baje el coste por token.
• Escalado y picos: la API absorbe los picos por usted; una pila local no.

Cómo construir una comparación justa

Para que la comparación tenga sentido, no compare el precio por token con el precio por token. Compare el coste por tarea completada con éxito a la calidad requerida. Un marco sencillo:

API: (tokens de entrada × tarifa de entrada + tokens de salida × tarifa de salida, ajustado por la proporción de caché) × número de tareas × número medio de intentos.

Local: (coste mensual de hardware + operación + trabajo) ÷ número de tareas resueltas con éxito con la utilización real.

Compare el resultado con distintos volúmenes. La forma típica de la curva es esta: con volumen bajo, la API casi siempre sale más barata, porque los costes fijos del despliegue local no están repartidos. Con un volumen creciente y estable, las curvas pueden cruzarse. Dónde exactamente depende de su hardware, su modelo y su carga operativa, y por eso no doy ninguna cifra general. La cautela es aquí oportuna: un punto de equilibrio que nadie ha medido con sus propios datos es solo una conjetura.

Dos ajustes que a menudo cambian la comparación antes de cualquier migración:

• Enrutamiento según la dificultad. La documentación sitúa el modelo más barato para clasificación, extracción y enrutamiento; si la mayor parte del tráfico son tareas así, se pueden enviar a un modelo más barato y reservar el caro para los casos complejos (https://platform.claude.com/docs/en/about-claude/pricing).
• Caché y acortamiento de prompts. Los contextos largos y repetidos pueden ser mucho más baratos gracias a la caché, y a menudo sin cambiar nada de la arquitectura.

Si tras estos ajustes la API sigue resultando insosteniblemente cara, solo entonces tiene sentido calcular con detalle la variante local.

Cuándo compensa la API

La API de pago es una elección razonable si:

• el volumen es pequeño, irregular o aún se está descubriendo, de modo que los costes fijos quedarían sin aprovechar;
• necesita la máxima calidad disponible o funciones que un modelo local no ofrece (contexto largo, herramientas, procesamiento de imágenes y PDF);
• no tiene capacidad para operar y asegurar su propia pila de inferencia;
• la carga tiene picos grandes que en local tendría que cubrir con hardware sobredimensionado;
• la rapidez de puesta en marcha importa más que el coste unitario.

En las notas de riesgo también entra la dependencia del proveedor: los precios, los modelos y las condiciones cambian y los modelos antiguos se retiran. La documentación tiene secciones propias sobre la retirada de modelos y sobre la migración entre versiones, lo que indica que hay que contar con migraciones. Diseñe, por tanto, la aplicación de modo que cambiar de modelo sea un cambio de configuración, no una reescritura.

Cuándo compensa un modelo local en Docker

El despliegue local tiene sentido si:

• tiene un volumen estable, predecible y suficientemente alto como para mantener el hardware ocupado;
• las tareas son lo bastante sencillas como para que un modelo más pequeño las resuelva con calidad aceptable (típicamente clasificación, extracción, herramientas internas);
• los datos no pueden salir de su infraestructura y eso es para usted un requisito firme (valórelo usted mismo, o con un especialista en cumplimiento; este texto no es asesoramiento jurídico);
• dispone de personas capaces de operar y mantener la pila a largo plazo;
• necesita una latencia baja y predecible sin depender de un servicio externo.

Docker aporta sobre todo repetibilidad: la misma configuración funciona en la máquina del desarrollador y en el servidor, y Compose permite declarar los requisitos de GPU directamente en la definición del servicio (https://docs.docker.com/compose/gpu-support/). Eso simplifica el despliegue, pero no resuelve la cuestión de si el hardware es suficientemente potente y está suficientemente utilizado.

El enfoque híbrido como punto intermedio realista

La elección no tiene por qué ser binaria. Un compromiso frecuente es la combinación: las tareas baratas, voluminosas y estandarizadas las procesa un modelo local, y los casos exigentes o poco frecuentes van a la API de pago. Una capa de enrutamiento decide según el tipo de tarea, la longitud de la entrada o una puntuación de confianza. Las ventajas son claras: los costes fijos de la máquina local se reparten sobre una base estable de tráfico, y los picos y los casos difíciles los absorbe la API. La desventaja es una arquitectura más compleja, doble monitorización y la necesidad de mantener la calidad en ambas ramas. Conviene introducir un híbrido solo cuando las mediciones muestran qué tareas son realmente sencillas y voluminosas.

Formas típicas de fallo

Subestimar la salida. El equipo calcula los tokens de entrada, pero olvida que en una API la salida es varias veces más cara. Solución: medir la longitud real de las respuestas y acotarla con el prompt o con límites.

Trasladar estimaciones de tokens entre modelos. Por un tokenizador distinto (según la documentación, aproximadamente un 30 % más de tokens en modelos más nuevos), el mismo texto puede costar más. Solución: contar los tokens para cada modelo de destino por separado.

Hardware local infrautilizado. Una GPU que está parada la mayor parte del tiempo es la forma más cara de obtener tokens. Solución: antes de comprar, estimar la utilización real y valorar el alquiler.

Calidad subestimada. Un modelo local barato exige repeticiones o revisión manual, y el coste total por resultado correcto sale mayor. Solución: comparar el coste por tarea exitosa, no por token.

Carga operativa oculta. Actualizaciones, seguridad y monitorización no entran en el cálculo. Solución: cuantificar las horas de trabajo e incluirlas.

Bloqueo por proveedor o por configuración. Los nombres de modelo escritos a fuego dificultan el cambio cuando se retira un modelo. Solución: abstraer la elección del modelo en la configuración.

Lista de comprobación práctica

1. Defina la tarea y el criterio de éxito (calidad, latencia, tasa de error admisible). 2. Reúna una muestra representativa de peticiones reales. 3. Cuente los tokens de entrada para cada modelo candidato con el contador de tokens. 4. Mida la longitud real de las salidas y la proporción de contexto repetido apto para caché. 5. Pruebe una clase de modelo más barata y el enrutamiento según dificultad antes de pensar en migrar. 6. Calcule el coste por tarea exitosa en la API, incluidos los reintentos. 7. Para la variante local, mida en su propio hardware el rendimiento, la latencia y la calidad; no confíe en cifras ajenas. 8. Estime la utilización real del hardware y sume el trabajo de operación. 9. Calcule el punto de equilibrio en varios escenarios de volumen, no en uno solo. 10. Verifique los requisitos de datos y de cumplimiento normativo con la persona responsable. 11. Diseñe el cambio de modelo como un cambio de configuración. 12. Planifique una revisión periódica, porque los precios y los modelos cambian.

Limitaciones de esta comparación

Este texto se basa únicamente en la documentación pública de Anthropic y de Docker, y además en sus extractos. No incluye mediciones de rendimiento de modelos locales, ni precios de hardware ni de energía, y por eso no ofrece ninguna cifra universal a partir de la cual compense el despliegue local. Los precios de la API cambian y su forma actual debe verificarse con el proveedor (https://platform.claude.com/docs/en/about-claude/pricing). Los detalles sobre las capacidades y limitaciones de Docker Model Runner están en su documentación (https://docs.docker.com/ai/model-runner/). El resultado depende siempre de su carga, de sus exigencias de calidad y de sus capacidades operativas, de modo que la única decisión fiable es la que se apoya en mediciones propias.

Conclusión

La API con precio por token es la opción por defecto para volúmenes bajos e inciertos, tareas exigentes y un arranque rápido. Un modelo local en Docker tiene sentido donde el volumen es estable y alto, las tareas son más sencillas y se tiene capacidad para sostener la operación. Entre ambos polos están la solución híbrida y una serie de ajustes más baratos (caché, enrutamiento, salidas más cortas) que a menudo ahorran más que el propio cambio de plataforma. Decida según el coste por tarea exitosa, mida con sus propios datos y cuente con que la elección óptima cambiará con el tiempo.