Después del cierre de la vista previa pública de la Llama API propia de Meta, las llamadas a modelos Llama no desaparecieron: se repartieron entre plataformas de nube, proveedores de inferencia y nodos autohospedados. Para los equipos de China, conectarse directamente a cada upstream consume cuentas y operación, así que el "relay" se volvió una forma habitual de acceso: una entrada compatible con OpenAI con varios upstreams de Llama detrás.
Pero el relay solo cambia la capa de acceso, no la capacidad del modelo. Aporta comodidad y también nuevas tareas de verificación: si el modelo es el original, si la facturación es transparente, si la clave y los datos están seguros y cómo revertir ante un punto único de falla. Este artículo desarrolla esos cuatro puntos y termina con una lista de migración.
Nota: Meta, Llama y Llama 4 son marcas de Meta Platforms, Inc.; Groq, Together AI, Fireworks, OpenRouter, AWS, Azure y Google Cloud son marcas de sus respectivos titulares. Este artículo solo discute tecnología y no tiene afiliación ni relación de cooperación con esas empresas. Los modelos y precios se rigen por la documentación oficial de cada plataforma y por la página de precios del sitio; los precios cambian.
1. Por qué aumentaron los relay de Llama en 2026
La vista previa pública de Llama API de Meta dejó de funcionar el 6 de julio de 2026. Los pesos de Llama se siguen descargando y todavía los alojan plataformas como AWS Bedrock, Azure AI Foundry, Google Cloud Vertex AI, Groq, Together AI, Fireworks y DeepInfra, pero cada una tiene ID de modelo, interfaz, límites y facturación distintos.
El relay consolida esas diferencias: el equipo usa una sola clave, memoriza una URL base y concilia una factura, lo que para equipos pequeños resulta cómodo. El costo es una capa adicional de dependencia y un objeto que debe auditarse.
2. Relay, proxy y pasarela: tres palabras distintas
Relay/agregador: el proveedor mantiene varias cuentas upstream y reenvía las solicitudes a distintas plataformas según reglas, con facturación y registros unificados. También suele hacer mapeo de nombres de modelo, por ejemplo, asignar llama-4-scout al ID completo de un upstream.
Proxy: se parece más a un proxy inverso o a un reenvío directo; resuelve alcanzabilidad de red y salida unificada, puede corresponder a un solo upstream y no necesariamente tiene facturación ni capacidad multi-proveedor.
Pasarela: abarca más; además del reenvío incluye autenticación, cuotas, gestión de miembros, auditoría, enrutamiento y facturación. En los productos reales los tres conceptos se superponen; al elegir, no mire el nombre, pregunte qué hace exactamente.
Cada capa de reenvío añade latencia, un punto de falla y una superficie de exposición de datos, y debe incorporarse a la arquitectura y a la gestión contractual.
3. Cómo combinar varios proveedores
El principio es asignar por tarea: conversación de baja latencia en Groq; contratos empresariales, cumplimiento regional o acceso por red privada en Bedrock, Vertex AI o Azure; procesamiento por lotes y tareas offline en plataformas por uso como Together AI, Fireworks o DeepInfra; y autohospedaje cuando los datos no pueden salir del centro de datos.
Detrás de una entrada puede haber varias rutas, pero cada una requiere mantener su propio mapeo de modelos y línea base de evaluación. No enrute automáticamente solo por precio: los distintos upstreams pueden diferir en nivel de cuantización, contexto y filtrado de contenido, y la ruta más barata no siempre cumple los requisitos de calidad.
4. Verificación de identidad del modelo: el mismo nombre no es lo mismo
"Llama 4 Scout" puede significar cosas distintas en cada plataforma: versión de pesos, cuantización (FP8, INT4, AWQ, GPTQ), ventana de contexto, plantilla de diálogo y salida máxima diferentes; algunas añaden además su propio filtro de seguridad. El nombre es igual, el comportamiento puede diferir mucho.
La verificación puede empezar por seis puntos:
- Revise la tarjeta del modelo: versión de pesos, cuantización, longitud de contexto, fecha de corte de conocimiento y si hubo ajuste fino.
- Consulte el ID y el campo de versión que devuelve
/modelspara confirmar que no es un alias difuso. - Use prompts fijos como huella de comportamiento: número de tokens, estructura de salida y recuperación en contexto largo.
- Pruebe llamadas a herramientas, salida JSON, formato de streaming y capacidad multimodal; ahí suelen aparecer las diferencias.
- Registre encabezados de respuesta, ID de solicitud e identificador del upstream para rastrear el nodo exacto si algo falla.
- Haga A/B con el conjunto de evaluación del negocio, no solo pregunte al modelo "quién eres"; la autodescripción no prueba identidad.
Para negocios sensibles a la versión, fije el ID de modelo y el upstream; no acepte "actualización automática".
5. Transparencia de facturación: abra la factura por partes
La factura del relay suele tener varias capas: costo de tokens del upstream, margen o multiplicador del proveedor, consumo mínimo, descuento por recarga, solicitudes fallidas y reintentos. Mirar solo "cuánto cuesta el millón de tokens" deja fuera partidas.
Confirme al menos: si entrada, salida y aciertos de caché se cobran por separado; quién cuenta los tokens y con qué tokenizer; si las interrupciones de streaming y los timeouts se cobran; si los reintentos se cobran dos veces; qué tipo de cambio se aplica entre monedas; y si la factura puede emitirse a nombre de la empresa. Lo prudente es exigir un registro de uso por solicitud con ID, modelo, tokens, duración y nombre del upstream, y conciliar una muestra cada día.
La facturación y los modelos de ZSQH AI Gateway se rigen por la página de precios del sitio; sea cual sea el proveedor elegido, conviene recargar poco y probar una semana antes de validar multiplicadores y reglas de solicitudes fallidas con la factura real. El registro se hace en la página de registro.
6. Claves, datos y riesgo de punto único
El relay puede ver prompts y salidas en texto claro; eso lo determina el modelo de servicio y no se elimina con promesas. Al elegir, pregunte: cuánto tiempo se conservan los registros, quién puede acceder, si se usan para entrenamiento, cuál es el mecanismo de borrado y si hay un acuerdo de procesamiento de datos. Con datos personales o de clientes, conviene anonimizar campos o dejar las solicitudes sensibles en nodos autohospedados.
En la gestión de claves, emita una subclave por proyecto, fije cuotas y listas blancas de modelos, vincule el origen, rote periódicamente y revoque al terminar el proyecto. La clave principal no debe ir en el frontend ni en aplicaciones móviles. El relay también es un punto único: si cae, no importa cuántos upstreams haya detrás. Los negocios críticos deben conservar una ruta directa o autohospedada de respaldo.
7. Reversión ante fallas: convertir "cambiar de proveedor" en proceso
La reversión no puede depender de modificar código sobre la marcha. Conviene mantener una tabla de rutas con upstreams ordenados por prioridad, cada uno con clave, ID de modelo y presupuesto de tiempo de espera propios; ante fallo de salud, abrir el circuito y pasar al siguiente; reintentar con retroceso exponencial y jitter; y, si todo falla, degradar a un modelo menor o devolver un error explicable.
El ejemplo mínimo siguiente solo muestra la reversión secuencial; en producción hay que añadir cortacircuitos, registros y control de cuotas. Los ID de modelo y las direcciones se rigen por la documentación de cada plataforma.
import os
from openai import OpenAI
ROUTES = [
("groq", "https://api.groq.com/openai/v1",
"llama-4-scout-17b-16e-instruct", "GROQ_API_KEY"),
("together", "https://api.together.xyz/v1",
"meta-llama/Llama-4-Scout-17B-16E-Instruct", "TOGETHER_API_KEY"),
("gateway", "https://your-gateway.example.com/v1",
"llama-4-scout", "GATEWAY_API_KEY"),
]
def chat(messages):
last_error = None
for name, base_url, model, key_env in ROUTES:
try:
client = OpenAI(
base_url=base_url,
api_key=os.environ[key_env],
timeout=30,
)
return client.chat.completions.create(
model=model,
messages=messages,
)
except Exception as exc:
last_error = exc
raise last_error
El modelo de respaldo puede tener contexto, tokenizer y capacidad de llamadas a herramientas distintos; tras la reversión limite la longitud de entrada y registre una marca de degradación para evitar "solicitud exitosa con resultado inutilizable".
8. Migrar desde la antigua Llama API: lista de nueve pasos
- Inventaríe URL base, claves, ID de modelo, versión de SDK y forma de llamada en el código.
- Mueva los ID de modelo a la configuración y cree una tabla de mapeo del ID antiguo al nuevo upstream.
- Elija upstream principal y de respaldo; confirme región, pago, factura y cláusulas de datos.
- Cambie autenticación y URL base; priorice interfaces compatibles con OpenAI para reducir cambios de SDK.
- Vuelva a probar streaming, llamadas a herramientas, modo JSON y entrada visual.
- Ajuste contexto, salida máxima y timeouts según los límites del nuevo upstream.
- Compare calidad, latencia P95 y costo por solicitud con el conjunto del negocio.
- Concilie durante una semana para confirmar conteo de tokens, solicitudes fallidas y criterios de reintento.
- Despliegue al diez, cincuenta y cien por ciento, con reversión en un clic y una instantánea de configuración.
9. Una tabla: verificación de un servicio relay
| Punto | Pregunta | Práctica recomendada |
|---|---|---|
| Identidad del modelo | Versión de pesos, cuantización, contexto | Pedir tarjeta del modelo y ejecutar un conjunto fijo |
| Composición upstream | A qué proveedores reenvía y si se puede especificar | Poder ver el upstream y el ID de solicitud |
| Facturación | Entrada, salida, caché, solicitudes fallidas | Pedir registro por solicitud y conciliar muestras |
| Cuotas | ¿Se pueden separar por miembro y proyecto? | Subclaves con alertas de presupuesto |
| Datos | Cuánto se conservan y si se usan para entrenar | Firmar acuerdo de tratamiento y anonimizar campos |
| Estabilidad | Límites, SLA, mecanismo de aviso de fallas | Pruebas de carga y canal de respaldo |
| Reversión | ¿Cambia de upstream automáticamente? | Tabla de rutas propia y ensayos periódicos |
| Contrato | Factura, reembolso, aviso previo de cierre | Incluirlo en las cláusulas de compra y salida |
10. Preguntas frecuentes
¿Qué diferencia hay entre un relay de Llama API y conectarse directo al upstream?
La conexión directa implica tener cuenta, clave y factura del upstream, con más control pero mayor costo de mantenimiento; el relay consolida varios upstreams en una interfaz, se activa rápido y unifica la factura, pero añade dependencia de varias capas y exige verificar identidad del modelo, facturación y cláusulas de datos.
¿Cómo saber si el relay entrega el Llama original?
Revise la tarjeta del modelo y el campo de versión, consulte /models, pruebe con prompts fijos el comportamiento, el conteo del tokenizer, el contexto largo y las llamadas a herramientas, y compare con el conjunto de evaluación. La autodescripción del modelo y el nombre comercial no bastan como evidencia.
¿Por qué la factura del relay no coincide con la del upstream?
Las causas habituales son tokenizer, criterio de caché, cobro de fallos y reintentos, multiplicador o consumo mínimo, y conversión de moneda. Exija un registro por solicitud y concilie muestras por ID; es más útil que mirar solo el total mensual.
¿Qué hacer si el servicio relay se cae?
Mantenga una ruta directa o autohospedada de respaldo para lo crítico, cambie por prioridad y configure cortacircuitos y degradación; además, confirme en el contrato el aviso de fallas, el SLA y las cláusulas de salida. No ponga todo el tráfico en un solo relay.
¿Cuánto código hay que cambiar en la migración?
Si ambas interfaces son compatibles con OpenAI, normalmente solo cambian URL base, clave e ID de modelo; con protocolos propios del proveedor, visión, herramientas o detalles de streaming, el cambio es mayor. Conviene llevar primero los ID de modelo a configuración y validar de forma gradual.
Resumen
El valor del relay de Llama está en la capa de acceso: entrada única, factura única y reversión entre varios upstreams. No cambia la capacidad del modelo ni resuelve automáticamente el cumplimiento y los datos. Si la identidad del modelo, la facturación, los riesgos de claves y datos y el proceso de reversión quedan en los criterios de aceptación, la migración será mucho más controlable.
Lecturas relacionadas: Qué es una API relay: selección, precios y cumplimiento, Proxy de API LLM: cumplimiento, facturación y fiabilidad, API de ChatGPT desde China: tres vías de acceso. Si necesita una entrada unificada, empiece en la página de registro; los precios se rigen por la página de precios.
