Guías de migraciónDesde Bifrost
Desde un gateway Bifrost que operas tú
Bifrost es un gateway de código abierto en Go que despliegas tú, con claves virtuales, presupuestos, respaldos y caché, y un nivel Enterprise para barreras de protección, SSO y clustering. INFRO cubre la misma gobernanza como servicio alojado. La solicitud apenas cambia; lo que cambia es que nadie de tu equipo opera el gateway.
Gateway en Go de código abierto (Apache 2.0) de Maxim; autoalojado, con un nivel Enterprise con licencia
Las cuentas de INFRO son de autoservicio. El catálogo, la documentación y el contrato de la API son públicos, el gateway está desplegado, y todo lo que va más allá de v1 está marcado como Más adelante. Planes y prueba
Dónde están las cosas
Licencia
Apache 2.0, de Maxim. Las barreras de protección, el balanceo de carga adaptativo, SSO, RBAC, los registros de auditoría y el clustering están en un nivel Enterprise con licencia comercial.
En qué cuenta se sirve la solicitud
Tuyas. Las claves de proveedor están en tu propio deployment de Bifrost.
La gobernanza es opcional
Sin la imposición de políticas activada, una solicitud sin clave virtual pasa sin gobernanza. En INFRO, toda solicitud necesita una clave de gateway.
Bifrost es rápido, abierto y lo operas tú. Consérvalo si se aplica alguna de estas condiciones.
- El gateway debe ejecutarse dentro de tu red, en una VPC o aislado de la red.
- Usas caché semántica, afinidad de sesión, plugins de Go o trabajos de inferencia asíncronos.
- Exportas a Prometheus o Datadog con dimensiones por solicitud (
x-bf-dim-*). - Llamas a proveedores que INFRO no conecta, o a Ollama en un portátil.
Los cambios, uno por fila. Todo lo que no aparece aquí queda como está.
| Bifrost | INFRO | |
|---|---|---|
| URL base | http://localhost:8080/openai o tu deployment. | https://api.infro.io/v1 |
| Clave | Una clave virtual (sk-bf-*) en x-bf-vk o Authorization. | Una clave del gateway de INFRO en Authorization: Bearer. |
| Id del modelo | openai/gpt-5.6-terra, vertex/gemini-3.8-flash, azure/gpt-prod. | openai/gpt-5.6-terra, google/gemini-3.8-flash; el proveedor lo eligen tus conexiones o routing.providers. |
| Encabezados y campos | fallbacks, x-bf-cache-*, x-bf-dim-*, x-request-id. | fallbacks, cache, metadata.tags, X-INFRO-Trace-Id. |
Antes · Bifrost
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "http://localhost:8080/openai",
apiKey: process.env.BIFROST_VIRTUAL_KEY,
defaultHeaders: { "x-bf-dim-feature": "chat" },
});
await client.chat.completions.create({
model: "openai/gpt-5.6-terra",
messages: [{ role: "user", content: "Hello" }],
// @ts-expect-error Bifrost extension
fallbacks: ["anthropic/claude-sonnet-5.5"],
});Después · INFRO
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://api.infro.io/v1",
apiKey: process.env.INFRO_API_KEY,
});
await client.chat.completions.create({
model: "openai/gpt-5.6-terra",
messages: [{ role: "user", content: "Hello" }],
// @ts-expect-error INFRO extensions
fallbacks: ["anthropic/claude-sonnet-5.5"],
metadata: { tags: { feature: "chat" } },
});Prefijos de proveedor
El id de modelo de INFRO nombra al fabricante, no al host: google/gemini-3.8-flash corra en Google AI o en Vertex. Cuál de tus conexiones lo sirve lo deciden tus conexiones, una ruta o routing.providers.
El mismo campo `fallbacks`
Ambos aceptan una lista de ids de modelo. Los de INFRO se prueban después de que haya fallado cada conexión para model, hasta 5.
Las dimensiones pasan a ser etiquetas
Los encabezados x-bf-dim-* pasan a ser claves bajo metadata.tags, agrupadas en el uso y filtradas en el registro de solicitudes.
Los objetos de Bifrost frente a los de INFRO, según la documentación pública de Bifrost leída el 19 de octubre de 2026 y comprobados contra lo que implementa el gateway. Una fila dice que INFRO no tiene nada.
| Bifrost | Qué hace allí | En INFRO |
|---|---|---|
| Claves virtualesmisma forma | Modelos y proveedores permitidos, presupuestos, límites de tasa, caducidad. | Claves del gateway con listas de permitidos, listas de proveedores, límites de gasto, niveles de tasa de solicitudes, rangos de IP y rotación. |
| Presupuestos jerárquicosmisma forma | Entre claves virtuales, equipos y clientes. | En organización, proyecto, miembro, clave y cliente final, también bajo concurrencia. |
| Respaldos y reintentosmisma forma | fallbacks y retroceso de reintentos por proveedor. | fallbacks, y rutas con reglas de fallo por tipo. |
| Balanceo de carga entre clavesmisma forma | Entre claves de proveedor; adaptativo en Enterprise. | Se reparte entre las claves de un proveedor, con las claves de reserva al final; rutas ponderadas. |
| Caché semánticadistinto | Exacta y semántica, en tu propio almacén vectorial. | Solo coincidencia exacta, alojada. |
| Observabilidaddistinto | Métricas de Prometheus, trazado con OTel, registros de solicitudes. | Registro de solicitudes y trazas con costo estimado, exportaciones, spans a tu colector de OpenTelemetry. Sin endpoint de Prometheus. |
| Barreras de protección, SSO, registros de auditoríamisma forma | Nivel Enterprise. | Barreras de protección en los planes que las incluyen; SSO y SCIM desde Business; un registro de auditoría. |
| Pluginsnada | Plugins de Go personalizados en la ruta de la solicitud. | Nada. INFRO no ejecuta tu código. |
| Autoalojamientodistinto | Apache 2.0, en cualquier lugar. | Alojado. Lo autoalojado o híbrido es un acuerdo empresarial.Empresas — Disponible con un acuerdo enterprise, no en autoservicio. |
Nuestra lectura de la documentación publicada de Bifrost, no una prueba ni un benchmark. Si leímos algo mal, dínoslo y corregiremos la fila.
Lo que INFRO no hace
- Ejecutarse en tu red sin un acuerdo enterprise, o bajo una licencia de código abierto.
- Caché semántica, afinidad de sesión, plugins, trabajos de inferencia asíncronos.
- Un endpoint de métricas de Prometheus.
Lo que no se traslada
- Los registros en tu almacén de registros de Bifrost. No hay importador.
- Claves virtuales. Emite claves de gateway de INFRO y rota a quienes llaman hacia ellas.
Preguntas
- ¿Conservo mis cuentas de proveedor?
- Sí. Pasan a ser conexiones de INFRO y siguen facturándote directamente. INFRO añade 0% al gasto en modelos.
- ¿El campo `fallbacks` sigue funcionando?
- Sí. INFRO admite
fallbackscomo una lista de hasta 5 ids de modelo. - ¿Puede INFRO correr en nuestra infraestructura?
- Solo con un acuerdo enterprise. Los planes son alojados.
Migra con nosotros o por tu cuenta
El programa de migración traslada en una llamada tu configuración de Bifrost a conexiones, rutas y presupuestos de INFRO, y migra contigo el primer servicio. Tus proveedores te siguen facturando directamente; INFRO es una suscripción y agrega 0% al gasto en modelos.
Fuentes
Cada afirmación de esta página sobre Bifrost proviene de una de estas fuentes, leídas el 19 de octubre de 2026. Nada se deduce de una prueba, un benchmark o una conversación.
- GitHub — maximhq/bifrostleído el 19 oct 2026
- Bifrost docs — Virtual keysleído el 19 oct 2026
- Bifrost docs — OpenAI SDKleído el 19 oct 2026
- Bifrost docs — Request optionsleído el 19 oct 2026
- Bifrost docs — Fallbacksleído el 19 oct 2026
- Bifrost docs — Semantic cachingleído el 19 oct 2026
- Maxim — Bifrost pricingleído el 19 oct 2026