¿Ajustar con precisión o llamar a la API? Costos de un pipeline de extracción de documentos
Un modelo de costos desarrollado para un flujo de documentos de auditoría muestra por qué la asignación de modelos es mejor que el ajuste fino en cuanto al precio, y cuándo la precisión del esquema o la residencia de datos en la UE justifican poseer un modelo.
Los líderes de ingeniería siguen haciendo la misma pregunta, generalmente justo después de que llegue la primera factura importante de OpenAI o Anthropic: ¿debería el equipo ajustar su propio modelo o seguir utilizando la API? La respuesta esperada es que el ajuste fino es más económico. A veces eso es cierto, pero típicamente por razones más específicas de las que la gente imagina, y para muchos equipos simplemente es falso. Este artículo analiza un sistema realista basado en documentos, evaluando ambos enfoques con precios de lista correspondientes a septiembre de 2026, para que pueda ver de dónde provienen realmente los ahorros, cuándo está justificado poseer un modelo y cómo tomar la decisión sin arriesgar ocho semanas de trabajo de ingenieros basándose en conjeturas.
La opción que la gente imaginaba ya no existe
Un cambio ha redefinido silenciosamente todo el debate: en el momento de escribir esto, no es posible ajustar fino un modelo de vanguardia actual.
Según la página de precios de OpenAI, su plataforma de ajuste fino está siendo eliminada gradualmente: los nuevos clientes no pueden registrarse, y o4-mini es el único modelo aún disponible para ajuste, con un costo de 100 dólares por hora de entrenamiento. La propia API de Anthropic nunca ha ofrecido la posibilidad de ajuste fino. Su única opción histórica fue el ajuste fino supervisado de Claude 3 Haiku en Amazon Bedrock, y Haiku 3 ya no está disponible en ningún otro lugar aparte de Bedrock y Google Cloud.
Así que, a finales de 2026, “ajuste fino versus tecnologías emergentes” significa algo más específico: tomar un modelo de peso abierto como Qwen, Llama, una variante de Nemotron o gpt-oss, entrenar un adaptador LoRA con los propios datos y luego alojarlo en la propia infraestructura o con un proveedor como Fireworks o Together. Los riesgos de esa opción no son los que la gente suele imaginar, relacionados con la selección del modelo, su evaluación y distribución, tareas que normalmente maneja una API alojada. Hay que ser preciso al respecto antes de presentarlo ante la junta directiva.
El sistema de referencia: una plataforma de pruebas de auditoría
El sistema mencionado aquí no es un producto experimental. Se trata de una plataforma completa de pruebas de auditoría para una empresa de tamaño medio, del tipo que realmente compraría un despacho contable del Reino Unido o de los países nórdicos. Funciona en siete etapas:
- Recibimiento de datos. Los clientes suben archivos a través de un portal, principalmente en formato PDF escaneado. Los datos típicos incluyen facturas, órdenes de compra, notas de recepción de mercancías, estados de cuenta bancario, contratos de arrendamiento y actas de reuniones del consejo de administración.
- Clasificación. Cada documento se asigna un tipo y se envía a la prueba correspondiente.
- Extracción. Los campos estructurados se ingresan en un esquema fijo, que incluye al proveedor, fecha, monto neto, IVA, referencia de la orden de compra, persona que aprueba, moneda y centro de costos. El resultado debe ser un JSON válido que se ajuste exactamente al esquema en cada llamada.
- Pruebas de control. La verificación tripartita comprueba si la factura coincide con la orden de compra y la nota de recepción de mercancías, así como si la persona que aprueba actuó dentro de sus facultades delegadas. La mayor parte de esto consiste en código ordinario y no en un modelo.
Las etapas 2 y 3 consumen casi todos los tokens, y también son la parte más repetitiva, mecánica y sujeta a restricciones de esquema del sistema. Las etapas 6 y 7 son donde se toman las decisiones reales, aunque su participación en el volumen total es insignificante. Tenga presente esta distribución, ya que el resto del análisis se deriva de ella.
Estimación del volumen de tokens
El modelo asume que cada documento se convierte en texto mediante OCR antes de que cualquier modelo lo vea. Esto evita la facturación por tokens de imagen y es lo que se haría en la práctica de todos modos.
Cada documento pasa por tres procesos (clasificar, extraer y autoverificar), lo que suma aproximadamente:
- 5,200 tokens de entrada, que incluyen el texto del documento, el esquema y algunos ejemplos de pocos casos
- 600 tokens de salida para el resultado estructurado
Se han modelado dos volúmenes:
- Piloto: 100,000 documentos al mes, que representan a una empresa durante una temporada alta.
- Escala: 2,000,000 documentos al mes, que representan el mismo producto vendido a cincuenta empresas.
Eso equivale a unos 580 millones de tokens al mes en el volumen piloto y 11.6 mil millones en el volumen a escala.
Cómo se ve la factura
Las cifras que se muestran a continuación utilizan precios de lista estándar con enrutamiento global y sin descuentos por lotes ni caché, según lo publicado en la página de precios de cada proveedor en septiembre de 2026. Los precios cambian con frecuencia, por lo que deben considerarse como una instantánea y se debe verificar nuevamente antes de hacer presupuestos.
A un volumen piloto, la necesidad de realizar ajustes detallados desaparece. Ejecutar todo el proceso de extracción en Claude Sonnet 5 cuesta aproximadamente $1,640 al mes, Haiku 4.5 unos $820, y un modelo de 8B ajustado alrededor de $116. Ahorrar unos $1,500 al mes nunca compensará el esfuerzo de crear un modelo ajustado. En esta etapa, es mejor utilizar la API.
A un volumen a gran escala, la elección se vuelve realmente importante:
- Claude Opus 5: aproximadamente $82,000 al mes
- GPT-5.6 Sol: aproximadamente $65,600 al mes
- Claude Sonnet 5: aproximadamente $32,800 al mes
- Claude Haiku 4.5: aproximadamente $16,400 al mes
- GPT-5.6 Luna: aproximadamente $3,520 al mes
Es tentador titular que se logra un ahorro de más del 90% gracias al ajuste fino, y frente a las versiones premium la aritmética lo respalda: el costo del ajuste fino representa alrededor del 7% de la factura de Sonnet 5 y menos del 3% de la de Opus 5. Pero ninguna equipo debería realizar extracción masiva de facturas con un modelo premium en primer lugar. Comparar un diseño optimizado con uno deliberadamente ineficiente es marketing, no análisis.
El enrutamiento, no el ajuste fino, genera el gran ahorro
Compare las dos últimas líneas de esa lista: 3,520 dólares por GPT-5.6 Luna frente a 2,320 dólares por el modelo 8B ajustado con precisión. La diferencia es de 1,200 dólares al mes, o aproximadamente 14,400 dólares al año.
Construir un sistema de ajuste fino adecuado implica etiquetar los datos, escribir una herramienta de evaluación, ejecutar el entrenamiento, implementar un servicio y añadir monitoreo de deriva. Una estimación razonable es de ocho semanas-herrero. Si se multiplica esto por la tarifa típica de un contratista europeo, en el peor de los casos, la recuperación de los ahorros obtenidos solo con tokens supera con creces los dieciocho meses.
La conclusión más útil es que la mayor reducción de costos proviene del enrutamiento. Al trasladar las tareas de clasificación y extracción del servicio principal al nivel más económico que aún cumpla con tus criterios de evaluación, la factura correspondiente al nivel Opus pasa de 82,000 dólares a 3,520 dólares al mes, lo que representa una reducción de aproximadamente el 96 %. Con un enrutador y un conjunto de evaluación adecuado, este cambio puede realizarse en una tarde. El ajuste fino adicional permite ahorrar otro 34 % aproximadamente. El mismo principio, de adaptar el tamaño del modelo a cada llamada, se explora más detalladamente en right-sizing LLMs con enrutamiento, recuperación y evaluación.
El entrenamiento en sí es casi gratuito. Fireworks ofrece el ajuste fino supervisado con LoRA para modelos de hasta 16 mil millones de parámetros por $0.50 por millón de tokens de entrenamiento. Veinte mil ejemplos etiquetados de 2,500 tokens cada uno, entrenados durante tres épocas, equivalen a 150 millones de tokens de entrenamiento, o aproximadamente $75 por ejecución. Ocho ejecuciones durante el desarrollo suman unos $600. El cálculo nunca ha sido la parte costosa; lo son la preparación de los datos y la evaluación. Cualquier cotización de ajuste fino basada principalmente en el costo de las GPU proviene de alguien que no lo ha realizado.
¿Por qué ajustar fino en absoluto?
Si el costo en tokens no lo justifica, otros dos factores sí pueden hacerlo.
Razón número uno: cumplimiento estricto del esquema
Esto es especialmente importante en el trabajo de auditoría y recibe mucha menos atención de la que merece.
Los modelos Frontier son generalistas. Si se les pide que elijan entre 51 subcategorías fijas, de vez en cuando generarán una 52ª, ya que producir texto que suene plausible es precisamente su objetivo de entrenamiento. En el caso de un asistente de chat, tales errores apenas importan. Pero en un documento técnico que respalda una opinión de auditoría firmada, constituyen un defecto.
La investigación reciente apunta en la misma dirección, aunque gran parte de ella es trabajo preliminar y debe leerse teniendo eso en cuenta:
- Un preprint de 2026 sobre la clasificación de documentos de seguridad evaluó modelos contra 51 subcategorías predefinidas, exigiendo respuestas en un formato JSON estricto. Allí, un modelo ajustado localmente superó a los modelos Frontier con prompts en una ventaja de 15 a 20 puntos porcentuales, y los investigadores observaron que GPT-5 inventó nombres de subcategorías que no figuraban en la taxonomía. Su interpretación es la parte importante: los modelos Frontier manejan bien la extracción con formato flexible, pero bajo restricciones de esquema estrictas, la calibración es más importante que la capacidad de razonamiento.
Para un producto de auditoría, una mejora de dos puntos en la precisión de extracción de datos puede valer más que todos los gastos relacionados con la inferencia juntos, ya que cada error de extracción requiere una revisión manual, y la revisión humana es el recurso más costoso en el negocio.
Razón número dos: saber exactamente dónde se encuentran los datos
En Europa, esto suele ser lo que decide la adjudicación del contrato.
Los archivos de auditoría de una firma contable del Reino Unido o de la UE contienen registros financieros de clientes, datos de empleados y, a veces, información personal sobre terceros. El lugar donde se procesan los datos no es una preocupación secundaria; típicamente es la segunda pregunta que plantean los departamentos de adquisiciones.
Las opciones actuales, a septiembre de 2026, sorprenden a muchos equipos:
- La API de Anthropic no ofrece opción de residencia en la UE. El parámetro
inference_geoacepta los valoresglobalous; el procesamiento exclusivo en EE. UU. tiene un costo 1,1 veces superior a la tarifa estándar. Para mantener a Claude dentro de la UE es necesario utilizar una región europea de AWS Bedrock o Google Vertex, donde los endpoints regionales tienen un costo 10% más alto que los globales. En el momento de redactar este texto, Claude en Microsoft Foundry no contaba con zona de datos en la UE. - OpenAI admite el procesamiento regional, lo que implica un aumento del 10% en el precio para los modelos lanzados a partir del 5 de marzo de 2026.
- Fireworks aplica un multiplicador de 1,5 cuando el despliegue dedicado está restringido a una región específica.
Cuando el precio de la residencia se calcula en función del volumen a gran escala, la situación cambia. Dos H100 dedicados que ejecutan el modelo de 8B ajustado, restringidos a una región y en funcionamiento las 24 horas, cuestan aproximadamente $17,520 al mes. Servir la misma carga de trabajo con Claude Sonnet 5 en un endpoint Bedrock de la UE costaría alrededor de $36,080, y con Opus 5 unos $90,200.
Ese es el verdadero argumento europeo a favor de poseer el modelo. No se trata de que los tokens sean más baratos; se trata de que la explicación relacionada con el cumplimiento normativo cabe en una sola oración en lugar de en un diagrama de arquitectura.
No compre GPUs dedicadas demasiado pronto
Un costo mensual fijo por la GPU parece atractivo y engaña a muchos equipos, ya que solo resulta rentable con volúmenes que pocos productos alcanzan. Si tomamos como punto de referencia un par de GPUs H100 dedicadas al precio global, aproximadamente 11,680 dólares por mes, los puntos de equilibrio se sitúan cerca de:
- 700,000 documentos por mes para Claude Sonnet 5; por debajo de esta cifra, la API es más económica
- 1.4 millones por mes para Claude Haiku 4.5
- 6.6 millones por mes para GPT-5.6 Luna
Es probable que un producto de auditoría típico quede por debajo de cada uno de estos umbrales durante sus primeros dos años. El alojamiento sin servidor de un modelo ajustado evita por completo esta trampa: se obtienen pesos personalizados sin tener que pagar por GPUs inactivas, lo que lo convierte en un punto de partida sensato. El trade-off es una menor control sobre la latencia y la capacidad, lo cual solo importa cuando el volumen es alto y constante.
Cuatro preguntas que deciden la elección
1. ¿Cuál es su volumen real mensual de tokens? Si procesa menos de aproximadamente mil millones de tokens al mes, elija la categoría Frontier más económica que permita superar sus evaluaciones e invierta esas ocho semanas-herrero en algo más útil. El ajuste fino con un volumen de prueba es pura formalidad, no ingeniería real.
2. ¿Hasta qué punto es específica y restringida la tarea? Un formato de salida fijo, un conjunto de etiquetas fijo y miles de ejemplos casi idénticos al día indican que se necesita un ajuste fino. El razonamiento abierto, las decisiones subjetivas y la redacción de textos para que los firme un socio corresponden a modelos Frontier, y es probable que sigan allí.
3. ¿Dónde deben residir los datos? Una cláusula contractual que exige que el procesamiento se realice dentro del EEE modifica la lista preliminar antes incluso de considerar los costos. Incluya el costo adicional por la residencia en la primera estimación, en lugar de descubrirlo durante la revisión arquitectónica.
4. ¿Puede obtener al menos 10,000 ejemplos etiquetados? Un documento de investigación de NVIDIA sobre modelos de lenguaje pequeños en sistemas agentes sugiere que un rango útil para ajustar un modelo pequeño está entre diez mil y cien mil ejemplos. Si no se dispone de esa cantidad, el primer proyecto debería consistir en implementar un sistema que registre sus propios datos de entrenamiento.
Ese último punto es el patrón más valioso aquí, y el menos promocionado. Utilice la API de frontera para enviar datos e registre cada llamada, incluidas las entradas, salidas y correcciones de los revisores. Seis meses después tendrá un conjunto de datos etiquetado que no le costará nada adicional, y podrá ajustar los modelos basándose en evidencias reales en lugar de la esperanza. El registro de documentos del cliente conlleva sus propias obligaciones de protección de datos, por lo que debe diseñar reglas de retención y acceso para esos registros desde el principio.
El mismo artículo de NVIDIA también estimó la proporción de llamadas a modelos LLM que podrían asumir los modelos pequeños en tres proyectos de agentes de código abierto: aproximadamente el 60% para MetaGPT, el 40% para Open Operator y el 70% para Cradle. No todos, pero tampoco ninguno. La respuesta correcta es una combinación, y solo los registros revelan qué llamadas corresponden a cada caso.
El argumento en contra más sólido
Los datos sobre la adopción empresarial indican lo contrario. Según la encuesta empresarial de Menlo Ventures, la proporción de cargas de trabajo empresariales basadas en código abierto disminuyó del 19 % al 11 %, mientras que los gastos se concentraron en APIs cerradas: Anthropic representa el 40 % de los gastos empresariales en LLM, OpenAI el 27 % y Google el 21 %. (Menlo es inversor de Anthropic, algo que cabe tener en cuenta al leer estas cifras.)
Esto no contradice el análisis anterior; mide dónde radica la dificultad. Las APIs cerradas ganan en comodidad, y la comodidad suele prevalecer. Los equipos que obtienen un valor real de los ajustes finos con código abierto eligieron conscientemente la carga operativa, por una razón que pudieron exponer claramente. Si no se puede indicar esa razón, la encuesta es una señal que merece atención.
Una breve nota sobre la regulación de la UE
Los equipos del Reino Unido y de la UE preguntarán sobre el AI Act, por lo que es útil tener un breve resumen. Considérelo como información orientativa, no como asesoría legal, y confirme el texto actual antes de basarse en ninguna fecha.
El Digital Omnibus sobre IA, formalmente el Reglamento (UE) 2026/1744, se publicó en el Diario Oficial el 24 de julio de 2026 y entró en vigor tres días después, el 27 de julio. Se retrasaron las obligaciones para sistemas de alto riesgo del Anexo III, que pasaron de ser aplicables a partir del 2 de agosto de 2026 al 2 de diciembre de 2027. En el caso de las IA integradas en productos incluidos en el Anexo I, la nueva fecha es el 2 de agosto de 2028.
Las obligaciones de transparencia del Artículo 50 no se pospusieron y han estado en vigor desde el 2 de agosto de 2026, tal como estaba previsto inicialmente. Para los sistemas puestos en el mercado con anterioridad, la obligación de etiquetado del Artículo 50(2) entra en vigor el 2 de diciembre de 2026.
Las herramientas que brindan soporte a los auditores e incluyen un paso de aprobación humana suelen quedar fuera del Anexo III, pero evalúe su propio caso de uso: si algún componente influye en las decisiones de contratación o en la solvencia, está dentro del alcance. Nada de esto afecta al GDPR, que regula los datos del cliente que fluyen a través del sistema, independientemente de cómo lo clasifique la Ley de IA.
La demanda es real. En una encuesta de Wolters Kluwer, el 39% de los 4,214 profesionales de auditoría interna indicó que ya utiliza la IA, y otro 41% esperaba comenzar a hacerlo dentro de un año.
Un plan por fases para desarrollar algo así
Para un equipo que inicia el desarrollo de este tipo de sistema, la secuencia recomendada es:
- Lanzar la versión más económica que supere su conjunto de evaluación. Registre cada llamada al modelo, permita que los auditores la utilicen durante una temporada alta real y posponga cualquier ajuste fino.
Tres de esas cuatro fases cuestan menos de lo que gastan muchos equipos desde el primer día.
Puntos clave
- Los modelos frontier actuales generalmente no pueden ajustarse con precisión, por lo que la verdadera opción es un modelo de pesos abiertos con adaptador LoRA frente a una API alojada.
La cuestión fundamental nunca fue entre modelos pequeños y modelos de vanguardia. Se trata de determinar cuáles de sus solicitudes realmente necesitan razonamiento. Si se responde a eso, la cuestión del costo queda en gran medida resuelta por sí sola.
Lecturas relacionadas
- Mapeo de RAG: Etapas del pipeline, componentes esenciales y el panorama de variantes — Entienda cómo funciona la generación mejorada con recuperación de información de principio a fin, qué componentes necesita un sistema RAG y cómo encajan las numerosas variantes de RAG en un mismo mapa.