Source: https://aiprimetech.io/es/blog/choosing-the-right-model-cost/ Jun 21, 2026 · 6 min · API # Elegir el modelo adecuado para la tarea (y el presupuesto) A Por [AI Prime Tech](https://aiprimetech.io/es/) · Con asistencia de IA A las 9:17 a. m. de un martes, nuestro sistema de resumen de solicitudes de soporte parecía estar «en buen estado» en el panel: una tasa de éxito del 99.4%, una latencia p95 inferior a 3 segundos y ninguna acumulación en la cola. La factura contaba otra historia. Estábamos pagando precios de modelos de la categoría de Opus para resumir solicitudes como: ``` { "subject": "Can I reset my password?", "messages": 3, "language": "en", "attachments": 0 } ``` Eso no es un problema de razonamiento. No es un problema de contexto de 1M. Apenas es un problema de lenguaje. La solución no fue «usar el modelo más barato para todo». Eso falla en cuanto aparece una disputa por un reembolso, un informe de errores enrevesado o una escalación delicada desde el punto de vista del cumplimiento normativo. La solución fue el enrutamiento: empezar con un modelo económico, medir la confianza y escalar solo cuando la tarea realmente lo justifique. Elegir el modelo adecuado tiene menos que ver con encontrar «el mejor modelo de IA» y más con construir un sistema de decisión sencillo y fiable: - ¿Qué requiere esta tarea? - ¿Qué margen de error puede permitirse el modelo? - ¿Cuánto contexto hace falta? - ¿Cuánta latencia puede tolerar el usuario? - ¿Cuál es la vía de reintento o escalación? Ahí es donde Haiku, Sonnet, Opus, Fable, GPT, Gemini y los modelos de pesos abiertos tienen cada uno un lugar real. ## Un modelo mental útil: primero el tipo de tarea, después el modelo En la práctica, clasifico las cargas de trabajo de los LLM según cinco ejes antes siquiera de mirar los nombres de los modelos: | Tipo de tarea | Ejemplo | Mejor opción inicial | Cuándo escalar | Transformación sencilla | Reescribir, clasificar y resumir textos breves | Modelo de la categoría de Haiku o modelo abierto pequeño | El formato de la salida es incorrecto o la confianza es baja | Extracción estructurada | Analizar facturas, solicitudes de soporte y registros | Haiku/Sonnet o un modelo abierto con restricciones | Campos ambiguos o un registro de alto valor | Razonamiento aplicado al producto | Planificación de agentes, depuración y soporte en varios pasos | Modelo de la categoría de Sonnet/GPT/Gemini | Fallos de herramientas, contradicciones o baja confianza | Análisis profundo | Revisión de arquitectura, comparación de políticas con aspectos jurídicos y razonamiento sobre código complejo | Opus/GPT-5.5/Gemini 3 | Por lo general, empezar aquí si hay mucho en juego | Síntesis con un contexto enorme | Un repositorio completo, un gran archivo de transcripciones o documentos extensos | Fable 5 o un modelo de contexto largo | Se necesita un razonamiento local preciso después de la recuperación | Gran volumen en privado o sin conexión | Prefiltrado de moderación, clasificación relacionada con embeddings y trabajos internos por lotes | Llama/Qwen/DeepSeek/MiniMax/Kimi de pesos abiertos | Casos límite o decisiones sujetas a regulación Elegir un modelo se vuelve mucho más fácil cuando deja de preguntar «¿qué modelo es más inteligente?» y empieza a preguntar «¿qué tipo de fallo estoy pagando por reducir?». Por ejemplo: - Un sistema de resumen de solicitudes de restablecimiento de contraseñas necesita coherencia y un coste bajo. - Un asistente de migración de código necesita razonamiento y uso de herramientas. - Una herramienta de comparación de contratos necesita un contexto largo, pero también una atribución cuidadosa. - Un agente de cara al cliente necesita una latencia predecible más que una calidad máxima en las pruebas de referencia. - Un flujo de enriquecimiento por lotes puede dar más importancia al volumen procesado por dólar que a la elegancia de las respuestas. A menudo, el modelo equivocado no lo es desde el punto de vista técnico. Lo es desde el punto de vista económico. ## Una escala práctica de modelos Esta es la escala que utilizo para la mayoría de los sistemas de producción. ### Modelos de la categoría de Haiku: la opción predeterminada para tareas de lenguaje rápidas y económicas Los modelos de la categoría de Haiku son excelentes para una primera pasada. Los utilizo en tareas donde la respuesta es breve, la entrada está limpia y el formato de salida está restringido. Usos adecuados: - Etiquetado de solicitudes de soporte - Resúmenes breves - Clasificación de sentimientos - Normalización de asuntos de correo electrónico - Identificación de coincidencias con preguntas frecuentes - Extracción sencilla de JSON - Prefiltros de moderación de bajo riesgo Ejemplo de prompt para un clasificador económico de primera pasada: ``` { "model": "claude-haiku-4.5", "temperature": 0, "max_tokens": 120, "response_format": { "type": "json" }, "messages": [ { "role": "system", "content": "Classify the support ticket. Return only valid JSON." }, { "role": "user", "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge." } ] } ``` Salida esperada: ``` { "category": "billing", "urgency": "medium", "needs_human": true, "reason": "Refund dispute involving payment status" } ``` Un problema habitual: los equipos piden a los modelos económicos que razonen y den un formato perfecto a la vez. Si el modelo a veces genera JSON no válido, no pases inmediatamente a Opus. Primero, delimita mejor la tarea: - Configura temperature: 0 - Usa un esquema JSON o una llamada a una herramienta - Reduce el alcance de las instrucciones - Separa la clasificación de la explicación - Valida la salida y reintenta una vez Para muchas tareas en producción, un reintento con un modelo de la clase Haiku sigue siendo más barato y rápido que recurrir por defecto a un modelo de razonamiento de vanguardia. ## Modelos de la clase Sonnet: el motor de la lógica real del producto Los modelos de la clase Sonnet suelen ser mi elección para las funciones interactivas de un producto. Son lo bastante capaces para razonar, lo bastante estables para usar herramientas y, por lo general, lo bastante rápidos para los flujos orientados al usuario. Usos adecuados: - Redacción de respuestas de atención al cliente - Flujos de trabajo de agentes con herramientas - Explicación de código y refactorización ligera - Preguntas y respuestas sobre documentos en varios pasos - Flujos de trabajo con copilotos para ventas o éxito del cliente - Extracción estructurada a partir de entradas desordenadas En la práctica, Sonnet suele ser la mejor opción cuando quieres evitar pensar demasiado en el enrutamiento. Si solo puedes integrar una categoría de modelos en una función nueva, empieza por esta. Ejemplo: un agente de soporte que puede consultar un pedido, una política y los tickets anteriores. ``` SYSTEM = """ You are a support resolution assistant. Use tools before making claims about orders, refunds, or account state. If policy is ambiguous, say what is ambiguous and escalate. Return: - summary - recommended_action - customer_reply - escalate: true/false """ request = { "model": "claude-sonnet-4.6", "temperature": 0.2, "max_tokens": 900, "tools": [ {"name": "get_order", "description": "Fetch order state"}, {"name": "get_refund_policy", "description": "Fetch current refund rules"}, {"name": "search_prior_tickets", "description": "Search customer history"} ], "messages": [ {"role": "system", "content": SYSTEM}, {"role": "user", "content": "Customer says they returned item A but were charged again."} ] } ``` Lo que realmente ocurre cuando ejecutas este tipo de flujo de trabajo en producción: la mayoría de los fallos no se deben a que «el modelo sea torpe». Son fallos de integración. - La herramienta devuelve un estado desactualizado. - El modelo recibe demasiado contexto irrelevante. - El documento de políticas contiene texto contradictorio. - Se permite que el agente continúe tras una llamada fallida a una herramienta. - El prompt pide tanto un análisis interno como un texto listo para el cliente sin separarlos. Un modelo de la clase Sonnet ofrece suficiente inteligencia para resolver algunos problemas derivados del desorden, pero no elimina la necesidad de contratos de herramientas bien definidos. ## Modelos de la clase Opus: caros, pero a veces más baratos que los errores Los modelos de la clase Opus están pensados para tareas en las que el coste de una mala respuesta supera con creces el coste de la inferencia. Recurro a Opus cuando: - La entrada es ambigua y hay mucho en juego - Hay muchas restricciones que interactúan entre sí - El usuario espera un razonamiento profundo - La tarea implica decisiones sobre código, políticas o arquitectura que requieren sopesar ventajas e inconvenientes - Un intento fallido con un modelo económico haría perder tiempo a las personas Ejemplos: - Revisar un plan de migración de una base de datos - Analizar la cronología de un incidente en producción - Generar una comparación compleja de políticas legales para su revisión humana - Depurar un fallo de un agente que abarca varios servicios - Evaluar si una acción automatizada es segura No uso Opus para todas las tareas «importantes». La importancia y la dificultad son cosas distintas. Un millón de tickets de restablecimiento de contraseñas son importantes para los usuarios, pero cada uno de ellos no es difícil. Una sola migración de eliminación de datos con implicaciones sutiles puede ser importante y difícil a la vez. Un patrón útil es «escalar ante la incertidumbre»: ``` def choose_model(task): if task["context_tokens"] > 700_000: return "fable-5" if task["risk"] == "high" and task["requires_reasoning"]: return "claude-opus-4.8" if task["requires_tools"] or task["multi_step"]: return "claude-sonnet-4.6" return "claude-haiku-4.5" ``` Es deliberadamente sencillo. El enrutador debe ser lo bastante simple como para que tu equipo pueda depurarlo a las 2 de la madrugada. ## Fable 5 y el contexto de 1M: úsalo cuando el problema sea la recuperación de información Los modelos de contexto largo resultan tentadores porque evitan mucho trabajo de ingeniería de recuperación de información. La ventana de contexto de 1M de Fable 5 cambia lo que puedes abordar directamente: revisión de documentos completos, síntesis de transcripciones enormes, inspección de repositorios grandes y análisis de políticas repartidas en varios archivos. Pero el contexto largo no es magia. Una ventana de 1M tokens ayuda cuando la dificultad es que «el dato relevante podría estar en cualquier parte». No garantiza que el modelo razone perfectamente sobre el millón de tokens, ni hace que el contexto irrelevante sea gratis. Los prompts largos siguen costando dinero, añaden latencia y pueden dispersar la atención. Uso contexto largo al estilo de Fable cuando: - El corpus está demasiado interconectado para una división simple en fragmentos - Omitir un detalle es peor que pagar por contexto adicional - El usuario puede tolerar respuestas más lentas - La tarea se beneficia de ver el material circundante sin procesar Ejemplo de arquitectura para revisar documentos extensos: ``` User request -> lightweight classifier -> retrieve obvious relevant sections -> if confidence high: Sonnet answer with citations/quotes from chunks -> if confidence low or query is global: Fable 5 over full document set -> optional Opus review for high-risk final answer ``` Este enfoque híbrido funciona mejor que «meter siempre todo en el contexto». En la práctica, los modelos de contexto largo son más valiosos como vía de escape cuando la confianza en la recuperación de información es baja. ## Modelos de pesos abiertos: control, coste y capacidad de procesamiento Los modelos de pesos abiertos como Llama, Qwen, DeepSeek, MiniMax y Kimi no son solo «alternativas más baratas». Son decisiones operativas. Tienen sentido cuando necesitas: - Despliegue local o en una VPC - Costes predecibles para el procesamiento por lotes de gran volumen - Ajuste fino o destilación - Optimizaciones personalizadas de inferencia - Control de la residencia de los datos - Un coste marginal extremadamente bajo tras la configuración inicial Son especialmente buenos para tareas específicas y repetitivas. Por ejemplo, una variante de Qwen o Llama servida mediante vLLM puede gestionar clasificación, extracción y enriquecimiento interno con una alta capacidad de procesamiento si controlas la longitud del prompt y el formato de salida. Ejemplo de configuración para servir un modelo localmente: ``` vllm serve Qwen/Qwen3-14B \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 ``` Después, llámalo mediante un cliente compatible con OpenAI: ``` from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="local" ) result = client.chat.completions.create( model="Qwen/Qwen3-14B", temperature=0, messages=[ {"role": "system", "content": "Return valid JSON only."}, {"role": "user", "content": "Classify: user cannot access invoice PDF"} ] ) ``` La contrapartida es asumir la responsabilidad de ingeniería. Con los modelos de vanguardia alojados, otra persona se encarga de la capacidad, los parches, las decisiones de cuantización y el trabajo de rendimiento a nivel de kernel. Con los modelos abiertos, todo eso pasa a ser tu responsabilidad. Los modelos de pesos abiertos encajan muy bien cuando la carga de trabajo es estable. Encajan peor cuando el producto cambia cada semana y la calidad del prompt importa más que el coste puro de servir el modelo. ## Enrutamiento con modelos económicos primero y escalado posterior Un buen enrutador no es una clasificación de rendimiento. Es un sistema de control de riesgos. Aquí tienes un patrón adecuado para producción: - Prueba el modelo más barato que debería ser capaz de realizar la tarea. - Valida la salida mediante comprobaciones automáticas. - Pide al modelo una autocomprobación calibrada basada únicamente en criterios observables. - Escala si falla la validación, la confianza es baja o el riesgo es alto. - Registra la ruta y el resultado para realizar ajustes posteriores. Ejemplo de enrutador: ``` def run_with_escalation(task, input_text): first_model = pick_first_model(task) response = call_model( model=first_model, input=input_text, schema=task["schema"], temperature=0 ) validation = validate(response, task["schema"]) if not validation.ok: return call_model( model="claude-sonnet-4.6", input=input_text, schema=task["schema"], temperature=0 ) if task["risk"] == "high" and response.get("needs_review"): return call_model( model="claude-opus-4.8", input=input_text, schema=task["schema"], temperature=0 ) return response ``` Lo importante es que el escalado se base en señales medibles, no en impresiones. Señales útiles para escalar: - JSON no válido - Faltan campos obligatorios - Respuesta contradictoria - Falló la llamada a una herramienta - La evidencia recuperada es débil - El usuario solicita una acción irreversible - La entrada supera la longitud habitual - El modelo indica explícitamente que hay incertidumbre - El clasificador detecta contenido legal, médico, de seguridad o financiero Evita usar únicamente la «confianza del modelo» como puntuación numérica. La confianza de un LLM no es una probabilidad calibrada. Aun así, resulta útil cuando se limita a comprobaciones específicas: «¿La entrada contenía información suficiente para responder?» es mejor que «¿Qué grado de confianza tienes?». ## Latencia, precio y experiencia de usuario El modelo más rápido no siempre ofrece la mejor experiencia de usuario. La mejor experiencia es la que lleva al usuario a un resultado correcto con una espera tolerable. Para los sistemas interactivos, pienso en presupuestos de latencia: | Experiencia | Presupuesto aproximado | Estrategia de modelos | Autocompletado o asistencia en línea | 100–500 ms percibidos | Modelo pequeño o abierto, streaming y uso intensivo de caché | Respuesta de chat | 1–5 segundos | Modelos de la categoría Haiku/Sonnet con streaming | Flujo de trabajo de un agente con herramientas | 5–20 segundos | Modelos de la categoría Sonnet, herramientas en paralelo, actualizaciones de progreso | Análisis profundo | 30–180 segundos | Modelos de la categoría Opus/Fable/GPT/Gemini, tarea asíncrona | Procesamiento por lotes | De minutos a horas | Modelo de pesos abiertos o nivel de servicio alojado más económico No oculte un razonamiento lento detrás de un indicador de carga sin ofrecer información. Si una tarea de Opus o Fable necesita 90 segundos, preséntela como una tarea de análisis explícita: ``` Analyzing 184 files... ✓ Indexed repository structure ✓ Found 12 migration scripts ✓ Checking rollback safety ``` Eso cambia la percepción del usuario porque el sistema está realizando un trabajo visible. Además, utilice streaming siempre que sea posible. El streaming no reduce el tiempo total de ejecución, pero mejora considerablemente la latencia percibida en los flujos de trabajo de chat y redacción. ## Decisiones reales según la tarea Estas son las decisiones concretas que tomaría hoy. ### Clasificación inicial de tickets de soporte Utilice Haiku primero. - Entrada: texto breve del ticket - Salida: categoría, urgencia, cola de asignación - Escale a Sonnet en caso de disputas de facturación, clientes enfadados o ambigüedad en las políticas - Revisión humana para reembolsos que superen el umbral Este es un flujo de trabajo clásico que empieza por la opción más económica. ### Agente de soporte de cara al cliente Utilice Sonnet. - Requiere el uso de herramientas - Requiere control del tono - Requiere gestionar políticas - Requiere un escalamiento adecuado Utilice Haiku solo para el preprocesamiento. Utilice Opus para la revisión de supervisión en casos de alto riesgo. ### Asistente de revisión de código Utilice Sonnet para la revisión habitual de PR. Utilice Opus para cambios sensibles a la arquitectura, concurrencia, seguridad, migraciones de datos y tareas de verificación de corrección que exijan atención a detalles sutiles. Un error habitual es proporcionar todo el repositorio por defecto. Empiece con el diff, el grafo de dependencias y los archivos relacionados. Escale a Fable u otro modelo de contexto largo solo cuando el cambio abarque muchas áreas. ### Comparación de contratos o políticas extensos Utilice recuperación de información junto con Sonnet para preguntas acotadas. Utilice Fable 5 cuando la pregunta sea global, como «encuentre todas las contradicciones entre estos documentos». Si la salida influye en una decisión real de carácter jurídico o de cumplimiento normativo, utilice el modelo para preparar el análisis, no para tomar la decisión. ### Enriquecimiento de datos a gran escala Utilice un modelo de pesos abiertos si el volumen es alto y la tarea es estable. Ejemplo: - Normalizar nombres de empresas - Extraer etiquetas de sector - Clasificar clientes potenciales entrantes - Generar resúmenes internos breves Ejecute lotes nocturnos, valide muestras y escale los casos excepcionales a un modelo alojado. ### Asistente de investigación sobre grandes archivos documentales Utilice Gemini 3, GPT-5.5, Opus o Fable según la longitud del contexto y las necesidades de razonamiento. No empezaría por la opción más económica para esto, salvo que la consulta sea claramente sencilla. Los fallos de investigación suelen ser silenciosos: el modelo da una respuesta plausible, pero pasa por alto el documento clave. ## Elaborar presupuestos sin engañarse La forma más fácil de gastar de más es optimizar el coste por llamada ignorando los reintentos, las correcciones humanas y los flujos de trabajo fallidos. Registre estas métricas por tipo de tarea y modelo: - Tokens de entrada - Tokens de salida - Latencia p50/p95 - Tasa de fallos de validación - Tasa de escalamiento - Tasa de correcciones humanas - Tasa de reintentos de los usuarios - Coste por tarea completada con éxito, no coste por llamada La última métrica importa. Un modelo económico que requiere tres reintentos y aun así provoca una revisión manual puede resultar más caro que Sonnet. Una llamada a Opus que evita una migración fallida puede ser la decisión más económica de la semana. Si utiliza una pasarela multimodelo, como el acceso mediante API de AI Prime Tech a las familias Claude, GPT y Gemini, la principal ventaja no es solo poder elegir entre proveedores. También facilita el enrutamiento y la medición entre distintas categorías de modelos. Pero la parte difícil sigue siendo el diseño de sus tareas. ## Conclusiones prácticas - Empiece por la naturaleza de la tarea: transformación, extracción, razonamiento, síntesis de contexto largo o enriquecimiento por lotes. - Utilice modelos de la categoría Haiku para trabajos económicos, rápidos y acotados con validación mecánica. - Utilice modelos de la categoría Sonnet como opción predeterminada para funciones de producto que necesiten razonamiento, herramientas o calidad de cara al usuario. - Utilice modelos de la categoría Opus cuando los errores sean costosos, la ambigüedad sea alta o importe el razonamiento profundo. - Utilice un contexto largo del tipo Fable 5 cuando la incertidumbre en la recuperación de información sea el problema principal, no como estrategia predeterminada para volcar información en el prompt. - Utilice modelos de pesos abiertos cuando la estabilidad de la carga de trabajo, la privacidad, la capacidad de procesamiento o el control del despliegue justifiquen gestionar su propia inferencia. - Implemente un enrutamiento que empiece por la opción más económica, con señales explícitas de escalamiento: salida no válida, evidencias débiles, fallos de herramientas, acciones de alto riesgo e incertidumbre. - Mida el coste por tarea completada con éxito, no el coste por token ni por llamada. - Mantenga los enrutadores lo bastante sencillos como para depurarlos bajo presión. - Trate la elección del modelo como un mecanismo de control de ingeniería, no como una decisión puntual sobre un proveedor. [Modelos](/es/blog/tag/models/)[API](/es/blog/tag/api/) A [AI Prime Tech](https://aiprimetech.io/es/) AI Prime Tech publica este blog. Los artículos se redactan con asistencia de IA; comprueba los detalles específicos de cada versión, como los identificadores de modelos, los precios y los límites, en la documentación oficial antes de basarte en ellos. Obtén acceso más económico a la API de Claude Una sola clave de API para Claude Opus 5.5, Sonnet 5, Haiku 4.5 y Fable 5.1, además de GPT-6 modelos. Pago por uso, sin suscripción. [Obtén tu clave de API →](/register) AI Prime Tech es una pasarela de API independiente de terceros. Claude™ y Anthropic® son marcas comerciales de Anthropic, PBC. No se implica ninguna afiliación ni respaldo.