El coste de la inferencia es una propiedad de la carga de trabajo: el modelo y la región, las entradas sin caché y con caché, los tokens generados y de razonamiento, las herramientas, los reintentos, la concurrencia, el almacenamiento y la revisión humana son todos relevantes. Comienza por el uso facturado y las trazas, no por una afirmación de ahorro del sector.
Los precios actuales y las reglas de caché cambian con frecuencia. Vuelve a verificar las páginas oficiales de precios de OpenAI, precios de Anthropic y precios de Gemini antes de utilizar cualquier modelo de costes.
Este artículo cubre las técnicas, los números y la disciplina de producción. Asumimos que ya has realizado el enrutamiento básico de modelos (cubierto en Orquestación multi-modelo); vamos a profundizar.
La estructura de costes
Los costes de los LLM provienen de:
- Tokens de entrada. Lo que envías al modelo. Incluye el prompt del sistema, el contexto y la consulta del usuario.
- Tokens de salida. Lo que devuelve el modelo. La relación de precios entre entrada/salida varía según el proveedor, el modelo, el modo por lotes y el estado de caché.
- Cargos de razonamiento o cómputo oculto. La manera en que cada proveedor informa y factura estos cargos varía; utiliza los campos de uso facturado y la hoja de precios actual en lugar de asumir paridad con la salida visible.
- Definiciones de herramientas y uso de herramientas. Los esquemas pueden añadir tokens de entrada, mientras que las herramientas alojadas o servicios externos pueden tener cargos separados.
- Reintentos y trabajo fallido. Algunas llamadas fallidas o abandonadas incurren en uso; clasifica los puntos de fallo a partir de la facturación del proveedor y las trazas.
La optimización funciona en cada capa.
Técnica 1: Almacenamiento en caché de prompts
El almacenamiento en caché puede ser una palanca importante cuando las solicitudes comparten un prefijo elegible y la carga de trabajo produce una tasa de aciertos alta.
Lee la documentación actual de caché de cada proveedor para conocer el tamaño mínimo del prefijo, los cargos de escritura/lectura, la expiración, las restricciones de enrutamiento y la observabilidad.
A grandes rasgos, un prefijo repetido elegible puede reutilizarse dentro de una ventana definida por el proveedor. La semántica exacta no es portátil entre proveedores.
Implementación práctica:
Estructura tus prompts para que el contenido estático venga primero y el dinámico al final:
[EN CACHÉ: 10K tokens]
- Prompt del sistema
- Descripciones de las herramientas
- Perfil estático del usuario
- Fragmentos de la base de conocimientos que es poco probable que cambien por llamada
[SIN CACHÉ: 1K tokens]
- Historial de conversaciones (cambia en cada turno)
- Consulta actual del usuario
Que este prefijo sea elegible, y cómo se factura, depende del modelo y del proveedor seleccionados.
Ecuación de ahorro:
daily cost = calls × (uncached input × input rate + cache writes × write rate + cache reads × read rate + output × output rate + tool charges)
Complétala con los recuentos de tokens facturados y la hoja de precios actual. Compara ventanas temporales equivalentes e incluye los fallos en caché (cache misses).
Disciplina de implementación:
- Identifica las partes estáticas vs dinámicas de los prompts.
- Coloca las partes estáticas primero.
- Utiliza marcadores de caché donde el proveedor los admita (Anthropic) para un control explícito.
- Prueba los aciertos en caché: tu observabilidad debe mostrar la tasa de aciertos en caché. Si es baja, la estructura de tu prompt no es correcta.
Prioriza el almacenamiento en caché solo después de que la traza muestre que las entradas elegibles repetidas son una partida de coste principal.
Técnica 2: Enrutamiento de modelos
Cubierto en detalle en otro lugar. En resumen: distintas solicitudes a distintos modelos según la complejidad.
Construye un conjunto de evaluación de enrutamiento etiquetado, compara los candidatos por calidad y coste, y mantén una alternativa para casos inciertos o fallidos. La mezcla resultante de enrutamiento es específica de la carga de trabajo.
Técnica 3: Control de longitud de salida
Los tokens de salida pueden ser una partida de coste principal. Confírmalo en los datos de uso antes de optimizar la longitud de respuesta.
Estrategias:
Instrucciones explícitas de longitud.
Responde en un máximo de 100 palabras.
Los modelos aún pueden incumplir una instrucción de longitud expresada en prosa. Aplica y evalúa el límite, e informa el cambio medido en tokens y calidad en lugar de prometer ahorros significativos.
Salida estructurada.
Cuando la respuesta requerida es datos estructurados cortos, un esquema estricto puede reducir la prosa irrelevante. No elimina salidas inválidas, valores de campo sobredimensionados, reintentos ni el riesgo de truncamiento; valida cada resultado.
Tope de tokens de salida del proveedor.
Establece el tope de salida de la API actual a partir de las necesidades medidas de la tarea y deja margen para una finalización válida. Los nombres de parámetros y la semántica difieren por API y modelo; un tope demasiado pequeño puede truncar salidas estructuradas y causar más llamadas.
Restricciones de formato.
«Solo viñetas» o «un solo párrafo» producen salidas más cortas que el formato libre.
Viñetas en lugar de prosa.
Las viñetas pueden reducir la prosa conectora para algunas respuestas. Mide los recuentos de tokens; una lista de viñetas verbosa puede ser más larga que un párrafo conciso.
Sin preámbulo.
«Omite frases introductorias. Ve directo a la respuesta.» Los modelos suelen comenzar con «Gran pregunta…» o «Déjame explicarte…» — tokens desperdiciados.
Ejemplo de medición:
Para un flujo de trabajo de resumen, compara las salidas predeterminadas y restringidas en los mismos documentos. Informa sobre los tokens de salida facturados, la cobertura factual, la legibilidad, la tasa de mensajes de seguimiento del usuario y cualquier truncamiento. Un recuento menor de tokens no es un ahorro si los usuarios necesitan otra llamada.
Técnica 4: Muestreo de salida e interrupción temprana
Para algunos casos de uso, no necesitas la salida completa del LLM; necesitas una decisión o clasificación.
Logprobs para clasificación.
# Use only a model and API operation whose current documentation supports
# log probabilities; support varies by model and endpoint.
response = openai.chat.completions.create(
model=SMALL_NON_REASONING_MODEL,
messages=[{"role": "user", "content": prompt}],
logprobs=True,
top_logprobs=5,
max_tokens=1
)
# Read logprobs of first token to determine likely category
Esto pide a un modelo compatible que emita una etiqueta corta. Confirma que la API seleccionada admite log probabilities (probabilidades logarítmicas), que las etiquetas se corresponden limpiamente con tokens y que la calidad de la clasificación cumple con el objetivo.
Etiquetas restringidas o sesgo de logits.
Para salidas de conjunto conocido, prefiere una restricción de enumeración/esquema documentada cuando esté disponible. El sesgo de logits influye en la selección de tokens pero es específico del tokenizador y modelo.
response = openai.chat.completions.create(
model=COMPATIBLE_MODEL,
messages=[...],
# If used, build logit_bias from every tokenization variant you intend
# to accept; do not assume a class label is exactly one token.
logit_bias=VALIDATED_TOKEN_BIAS,
max_tokens=1,
)
El sesgo de logits influye en la selección de tokens; no impone una clase válida ni demuestra la fiabilidad de la clasificación. Valida y rechaza salidas inesperadas.
Técnica 5: Procesamiento por lotes (batching)
Cuando procesas muchos elementos, agrúpalos en lotes.
Lotes asíncronos a nivel de API.
Algunos proveedores admiten productos asíncronos o por lotes, a veces con precios, ventanas de finalización, límites y términos de manejo de datos diferentes.
- Tanto OpenAI como Anthropic documentan productos de procesamiento por lotes asíncrono. Verifica el descuento actual, la ventana de finalización, los límites y los términos de manejo de datos en sus páginas oficiales de precios y lotes.
Si el trabajo acumulado no necesita una respuesta interactiva, compara los precios actuales por lotes y el comportamiento de finalización con la ruta síncrona.
Lotes dentro del prompt.
Procesa múltiples elementos en una sola llamada LLM cuando sea posible.
En lugar de:
[10 llamadas separadas, cada una clasificando un ticket]
Haz:
[1 llamada, clasificando 10 tickets en un único prompt]
La llamada única tiene más entrada de elementos, pero puede reutilizar un solo conjunto de sobrecarga fija del prompt. Puede reducir los tokens totales en algunas cargas de trabajo; separadores, salidas más largas, reintentos y fallos a nivel de lote pueden eliminar ese ahorro.
Salvedad: el procesamiento por lotes puede cambiar la calidad, el orden, el truncamiento y el aislamiento de fallos. Prueba un barrido de tamaños de lote sobre entradas representativas en lugar de adoptar un rango universal.
Técnica 6: Modelos más pequeños para tareas acotadas
Más allá del enrutamiento estándar: considera si una tarea realmente necesita un modelo grande.
Clasificación: evalúa un nivel más pequeño contra el modelo actual de producción con ejemplos etiquetados, incluidas las clases poco frecuentes y la abstención. Utiliza los precios actuales del proveedor en la comparación de costes.
Extracción: Compara extractores pequeños, de nivel medio, deterministas e híbridos por precisión a nivel de campo, manejo de excepciones, latencia y coste. Deriva los casos a niveles superiores mediante reglas probadas.
Traducción: Evalúa sistemas de traducción especializados y niveles de LLM en los pares de idiomas reales, terminología, formato, seguridad y requisitos de revisión humana. No infieras la cobertura a partir de benchmarks agregados.
Embedding: Utiliza modelos especializados en embedding, no LLMs de propósito general para embeddings.
El patrón: identifica tus cargas de trabajo «simples y acotadas». Enrútalas al modelo más pequeño que haga el trabajo adecuadamente. Reserva los modelos insignia (flagship) para el trabajo complejo y basado en juicio.
Técnica 7: Modelos pequeños con ajuste fino
Para tareas acotadas de volumen muy alto, haz un ajuste fino de un modelo pequeño.
Para una carga de trabajo de clasificación de alto volumen, compara un modelo pequeño con prompt, un modelo con ajuste fino, reglas deterministas y un híbrido. Incluye datos de entrenamiento y evaluación, servicio, capacidad inactiva, monitorización, reentrenamiento y coste de ingeniería. El ajuste fino es económico solo si la curva medida de calidad/coste lo justifica.
Cubrimos esto en Ajuste fino en 2026. El principio: cuando la escala y el carácter acotado de la tarea coinciden, el ajuste fino es una palanca de costes.
Técnica 8: Pre-filtrado
Para flujos de trabajo con LLM de varios pasos, un filtrado barato captura los casos obvios antes del procesamiento costoso.
Ejemplo: clasificación y respuesta de soporte al cliente.
Pre-filtrado económico:
- «¿Es esta una pregunta real de soporte o spam/ruido?» (Clasificación de 1 token en un modelo pequeño.)
- «¿Es esto una FAQ conocida?» (Búsqueda por embedding; económica.)
Solo las solicitudes que pasan el filtro llegan a la generación costosa de respuestas.
Mide qué parte del tráfico puede resolver el pre-filtrado con la precisión requerida. Los falsos positivos pueden suprimir solicitudes válidas, por lo que los ahorros de costes deben evaluarse junto con el impacto en calidad y escalada.
Técnica 9: Caché más allá del almacenamiento en caché de prompts
Más allá del almacenamiento en caché de prompts del proveedor del modelo: caché a nivel de aplicación.
Caché de respuestas. Para un alcance aprobado y un conjunto completo de entradas que afectan a la respuesta, reutiliza una respuesta anterior cuando su vigencia y su semántica sigan siendo válidas. El no determinismo implica que esta es una decisión de producto, no una garantía de identidad.
import hashlib
import json
def stable_sha256(value):
payload = json.dumps(value, sort_keys=True, separators=(",", ":"))
return "llm:" + hashlib.sha256(payload.encode("utf-8")).hexdigest()
def cached_call(scope, prompt_version, prompt, model, params, ttl=3600):
# Canonicalize all response-affecting inputs and include tenant/user scope
# where a shared answer is not explicitly safe. Use a stable cryptographic
# digest rather than the process-randomized built-in hash().
cache_key = stable_sha256({
"scope": scope,
"prompt_version": prompt_version,
"prompt": prompt,
"model": model,
"params": params,
})
cached = redis.get(cache_key)
if cached:
return json.loads(cached.decode("utf-8"))
response = call_llm(prompt, model, params)
redis.set(cache_key, json.dumps(response), ex=ttl)
return response
Para consultas elegibles y suficientemente deterministas, esto puede evitar llamadas repetidas una vez que la caché está poblada y se produce un acierto. Define la frescura y la invalidación, aísla los alcances, evita las avalanchas de caché (cache stampedes) y no almacenes en caché salidas sensibles o personalizadas sin aprobación.
Caché de embeddings. Embeddings calculados almacenados en caché.
Caché de resultados de recuperación. Resultados de búsqueda para una consulta almacenados por períodos cortos.
Caché de resultados de herramientas. Resultados de llamadas a herramientas almacenados si los datos subyacentes no cambian con frecuencia.
Los niveles de caché se apilan. En cada capa, ahorras llamadas.
Técnica 10: Ejecución especulativa (compensación de latencia, no un ahorro de costes)
Para flujos sensibles a la latencia donde puedes predecir los siguientes pasos, lanza la llamada por adelantado de forma especulativa.
Ejemplo: agente de soporte al cliente. Sabes que el siguiente paso suele ser «resumir el problema» después de que el cliente lo describe. Inicia ese resumen en paralelo mientras muestras un acuse de recibo al usuario.
Si la predicción es correcta, la respuesta está lista cuando se necesita. Si falla, has desperdiciado una llamada.
Esto gasta deliberadamente trabajo que puede descartarse, por lo que puede aumentar los costes. Úsalo solo cuando el beneficio medido en latencia justifique el desperdicio, las cancelaciones y efectos secundarios estén controlados, y la solicitud especulativa no pueda exponer o mutar datos no autorizados.
Técnica 11: Comparación de proveedores
Los proveedores difieren en precio, capacidad, regiones, cuotas, términos de datos, fiabilidad e implementación del modelo. Compara candidatos equivalentes en calidad bajo la misma carga de trabajo y suposiciones contractuales.
Modelos de pesos abiertos en proveedores de inferencia gestionada.
Compara los precios actuales del proveedor solo después de que el modelo candidato supere la misma evaluación de carga de trabajo. Un tamaño de parámetros o un nivel comercial similares no establecen una calidad equivalente.
Mismo modelo en diferentes proveedores.
Algunos modelos de pesos abiertos son ofrecidos por múltiples proveedores. Haz benchmarking de la revisión exacta, cuantización, configuración de servicio y comportamiento de API; el mismo nombre de modelo no garantiza salida o rendimiento idénticos.
Alojamiento en infraestructura propia a escala.
El alojamiento en infraestructura propia puede volverse más económico en un punto de utilización específico de la carga de trabajo. Modela las horas de GPU, las réplicas, la capacidad inactiva y de pico, la red, la observabilidad, las actualizaciones, la seguridad, la respuesta a incidentes y la propiedad de ingeniería.
El enrutamiento multi-proveedor añade complejidad de integración, evaluación, seguridad, adquisición, observabilidad y modos de fallo. Adóptalo solo cuando la resiliencia medida o el beneficio económico exceda ese coste de propiedad.
Técnica 12: Aceleración de inferencia
Para alojamiento en infraestructura propia: optimización de la capa de inferencia en sí misma.
vLLM, TGI, SGLang. Servidores de inferencia con diferente cobertura de modelos y rutas de optimización. Haz benchmarking de las versiones compatibles en el hardware objetivo.
Cuantización. La menor precisión puede reducir la memoria o mejorar el rendimiento, con efectos de calidad dependientes de la tarea y método. Haz benchmarking del artefacto exacto y configuración de servicio.
Flash Attention, paged attention. Optimizaciones arquitectónicas habilitadas en servidores modernos.
Lote continuo (continuous batching). Servidores que agrupan solicitudes en vuelo para una mejor utilización de la GPU.
Para equipos que alojan su propia infraestructura a escala, esto importa. Para equipos que usan APIs, el proveedor lo maneja.
Técnica 13: Streaming
El streaming no reduce el recuento de tokens, pero mejora la UX, lo cual es relevante para la percepción de rentabilidad.
Para salidas largas, los usuarios ven aparecer el contenido de inmediato. Pueden ir leyendo mientras se completa la generación. Resulta mucho más rápido que esperar a la respuesta completa.
Para agentes, transmite eventos de progreso aprobados o resúmenes de estado. No expongas razonamiento privado, secretos, argumentos de herramientas no revisados ni datos de otros inquilinos como «pasos intermedios».
Implementación: si la API y el modelo seleccionados admiten streaming, pruébalo para flujos visibles al usuario. El streaming cambia la latencia percibida, no necesariamente el coste total o el tiempo de finalización de la tarea.
Técnica 14: Salvaguardas de presupuesto
Más allá de la optimización, aplica presupuestos estrictos para prevenir costes descontrolados.
Presupuesto por solicitud. Máximo de tokens por solicitud. Detén la ejecución si se excede.
Presupuesto por usuario. Tope de coste diario o mensual por usuario. Limita la tasa a medida que se acerque al límite.
Presupuesto por función. Cada función tiene un presupuesto asignado y una respuesta probada cuando se supera un umbral específico de la carga de trabajo.
Presupuesto global. Límite total diario/mensual. Pausa el trabajo no esencial cerca de los límites.
Estos controles no demuestran ahorros. Limitan o redirigen el gasto y también pueden reducir la disponibilidad, por lo que debes probar las alertas, la limitación de uso, la degradación, el encolamiento y el comportamiento del patrón circuit breaker en cargas de trabajo esenciales y no esenciales.
Plantilla de experimento de reducción de costes
No presentes un resultado compuesto como si fuera el resultado de un cliente. Para un flujo de trabajo en producción, registra un periodo de facturación de referencia y aplica un solo cambio cada vez:
Los cambios:
-
Almacenamiento en caché de prompts. Registra tokens de prefijo elegibles, tasa de aciertos, escrituras/lecturas de caché, latencia y coste facturado.
-
Enrutamiento de modelos. Registra distribución por ruta, calidad por ruta, alternativas, latencia y coste.
-
Control de longitud de salida. Registra longitud de salida, calidad de finalización, re-prompts del usuario y coste.
-
Pre-filtrado. Registra precisión, exhaustividad (recall), escaladas, solicitudes válidas suprimidas y llamadas evitadas.
-
Caché de respuestas para FAQ. Registra reglas de equivalencia semántica, frescura, invalidación, tasa de aciertos y calidad de respuesta.
Informa ahorros brutos y netos, resultados de evaluación, tiempo de ingeniería, nuevo coste operativo e intervalos de incertidumbre donde los datos y el método lo apoyen. No afirmes que la calidad no cambió a menos que el diseño de evaluación pueda detectar regresiones significativas.
Errores comunes
Patrones de fallo a verificar en tus propias trazas:
Error 1: Sin seguimiento de costes. El equipo no tiene visibilidad sobre lo que cuesta cada función, usuario o llamada. La optimización es imposible sin medición.
Error 2: Optimizar lo que no toca. Se dedican semanas a reducir los tokens de entrada un 5 % cuando los tokens de salida eran el 80 % de la factura. Mide primero; optimiza los contribuyentes más grandes.
Error 3: Regresiones de calidad. Se aplican recortes de costes sin supervisar la calidad. Se ahorra dinero, pero se pierden usuarios. Acompaña siempre la optimización de costes con conjuntos de evaluaciones.
Error 4: Sobre-enrutamiento. Enrutamiento agresivo a modelos pequeños para tareas que realmente no pueden manejar. Ahorros falsos.
Error 5: Contaminación de caché. La caché se llena de consultas poco frecuentes. La mayoría de las entradas en caché se usan una sola vez. Dominan los fallos de caché. Se necesita una mejor estrategia de caché.
Error 6: Saltarse la evaluación por lotes. Se utiliza procesamiento en tiempo real para trabajo que podría tolerar la ventana y restricciones actuales del proveedor por lotes.
Error 7: Sobre-ingeniería. Construir optimización de costes elaborada sobre funciones que no son rentables de todos modos. A veces la respuesta correcta es «eliminar la función».
Error 8: Sin salvaguardas de presupuesto. Un solo error provoca un gasto descontrolado: una catástrofe en lugar de una molestia menor.
Disciplina operativa
Prácticas operativas recomendadas:
- Trata el coste como una métrica, no como un aspecto secundario.
- Asigna una persona responsable que coordine las funciones de ingeniería y finanzas.
- Revisa los costes con una frecuencia acorde con la volatilidad del gasto y el riesgo empresarial.
- Analiza los picos con respecto a umbrales definidos y procedimientos operativos.
- Establece presupuestos por función y genera alertas cuando se superen los umbrales.
- Explicita las concesiones entre coste, calidad y latencia.
Brechas de control a buscar:
- No hay una persona responsable de los costes.
- Facturación descubierta solo después de que haya pasado la ventana de decisión.
- Hay alertas sin una persona responsable de responder ni un procedimiento operativo.
- No hay un presupuesto aprobado ni un marco de previsión.
- Se omite el debate sobre las concesiones y se optimiza una sola dimensión cada vez.
Estas son decisiones de gobernanza para verificar mediante registros de propiedad, asistencia a revisiones, respuesta a alertas y acciones de costes completadas — no una afirmación sobre la cultura del equipo.
Deriva de precios y capacidad
Una nota sobre la tendencia más amplia.
Los precios de los proveedores, las capacidades de los modelos, los productos por lotes, las reglas de caché y las tarifas de las herramientas alojadas cambian según el calendario de cada proveedor. Este artículo no establece una tendencia histórica universal ni una previsión.
Vuelve a ejecutar el modelo de costes y calidad tras cambios sustanciales en los precios, los modelos, los contratos o las cargas de trabajo. No des por hecho que un flujo de trabajo que hoy no es rentable llegará a serlo, ni que futuras reducciones del precio de lista salvarán un diseño ineficiente.
Una secuencia ilustrativa de doce semanas para optimización de costes
Para un equipo que comienza con «tenemos una función de IA, los costes son más altos de lo esperado», la siguiente secuencia es un ejemplo de planificación. Cambia la duración y las condiciones de parada para ajustarlas a la carga de trabajo, la evidencia y la capacidad operativa.
Semanas 1-2: Medir.
- Instrumenta los costes por llamada.
- Construye paneles por función y por usuario.
- Identifica los mayores contribuyentes de coste.
Semanas 3-4: Ganancias rápidas.
- Prueba el almacenamiento en caché de prompts solo donde las trazas muestren prefijos elegibles repetidos y las reglas actuales del proveedor se ajusten.
- Reestructura los prompts elegibles de mayor coste, luego mide la tasa de aciertos en caché, latencia, calidad y coste facturado.
- Establece el tope actual de salida de cada API solo donde las necesidades medidas de la tarea lo justifiquen; prueba el truncamiento y los reintentos.
- Implementa alertas de presupuesto.
Semanas 5-6: Enrutamiento.
- Identifica tareas simples actualmente en modelos insignia (flagship).
- Construye el router para los 3-5 endpoints más llamados.
- Comprueba si hay regresión de calidad.
Semanas 7-8: Salida y caché.
- Restringe longitudes de salida donde no sean visibles al usuario.
- Añade caché de respuestas a nivel de aplicación para consultas comunes.
- Añade pre-filtros para los flujos de mayor volumen.
Semanas 9-10: Avanzado.
- API por lotes para trabajo no en tiempo real.
- Evaluación de alternativas de proveedores.
- Caché de embeddings, caché de recuperación.
Semanas 11-12: Fortalecimiento.
- Salvaguardas de presupuesto en cada función.
- Paneles de costes en la revisión regular del equipo.
- Documentación de patrones para futuras funciones.
Al final del ciclo de mejora, publica el cambio medido en costes y la evidencia de calidad. Un calendario no garantiza un porcentaje de ahorro.
Mide primero y luego acumula los ahorros
Los costes de LLM a menudo pueden reducirse, pero el porcentaje e impacto en la calidad son específicos de la carga de trabajo. Las técnicas candidatas incluyen caché, enrutamiento, control de salida, procesamiento por lotes, pre-filtrado, caché de respuestas, selección de modelos y salvaguardas de presupuesto.
Aplica cambios secuencialmente para que sus efectos permanezcan atribuibles; las interacciones pueden componerse, superponerse o cancelarse mutuamente.
Utiliza la contribución neta después de inferencia, herramientas, revisión humana, infraestructura, mantenimiento y soporte para decidir si la función es económicamente sostenible.
Mide primero. Optimiza los contribuyentes más grandes. Mantén la monitorización de calidad. Integra la disciplina de costes en el trabajo regular del equipo.
El resultado: funciones de IA que escalan económicamente, no solo técnicamente. Eso es lo que hace que la IA sea una parte sostenible de un producto y no solo un titular de lanzamiento.
