Guias de migraçãoVindo do Bifrost
De um gateway Bifrost que você opera
O Bifrost é um gateway open source em Go que você mesmo implanta, com chaves virtuais, orçamentos, fallbacks e cache, e um tier Enterprise para guardrails, SSO e clustering. O INFRO cobre a mesma governança como serviço hospedado. A requisição quase não muda; o que muda é que ninguém na sua equipe opera o gateway.
Gateway em Go open source (Apache 2.0) da Maxim; auto-hospedado, com um nível Enterprise licenciado
As contas do INFRO são self-service. O catálogo, a documentação e o contrato da API são públicos, o gateway está implantado, e tudo o que vai além da v1 está marcado para depois. Planos e teste
Situação atual
Licença
Apache 2.0, da Maxim. Guardrails, balanceamento de carga adaptativo, SSO, RBAC, logs de auditoria e clustering ficam em um tier Enterprise com licença comercial.
A conta de quem atende a requisição
Você. As chaves de provedor ficam no seu próprio deployment do Bifrost.
A governança é opcional
Sem a imposição de políticas ativada, uma requisição sem chave virtual passa sem governança. No INFRO, toda requisição precisa de uma chave de gateway.
O Bifrost é rápido, aberto e seu para operar. Mantenha-o se uma destas situações se aplicar.
- O gateway precisa rodar dentro da sua rede, em uma VPC ou isolado da rede (air-gapped).
- Você usa cache semântico, afinidade de sessão, plugins em Go ou jobs de inferência assíncronos.
- Você exporta para Prometheus ou Datadog com dimensões por requisição (
x-bf-dim-*). - Você chama provedores que o INFRO não conecta, ou o Ollama em um notebook.
As alterações, uma linha cada. Tudo o que não está listado aqui continua como está.
| Bifrost | INFRO | |
|---|---|---|
| URL base | http://localhost:8080/openai ou o seu deployment. | https://api.infro.io/v1 |
| Chave | Uma chave virtual (sk-bf-*) em x-bf-vk ou Authorization. | Uma chave do gateway do INFRO em Authorization: Bearer. |
| Id do modelo | openai/gpt-5.6-terra, vertex/gemini-3.8-flash, azure/gpt-prod. | openai/gpt-5.6-terra, google/gemini-3.8-flash; o provedor é escolhido pelas suas conexões ou por routing.providers. |
| Headers e 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"],
});Depois · 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" } },
});Prefixos de provedor
O id de modelo do INFRO nomeia o fornecedor, não o host: google/gemini-3.8-flash, seja no Google AI ou na Vertex. Qual das suas conexões o atende é decidido pelas suas conexões, por uma rota ou por routing.providers.
O mesmo campo `fallbacks`
Os dois aceitam uma lista de ids de modelo. Os do INFRO são tentados depois que todas as conexões para model falharam, até 5.
Dimensões viram tags
Os headers x-bf-dim-* viram chaves em metadata.tags, agrupadas no uso e filtradas no log de requisições.
Os objetos do Bifrost comparados aos do INFRO, a partir da documentação pública do Bifrost lida em 19 de outubro de 2026 e conferidos com o que o gateway implementa. Uma linha diz que o INFRO não tem nada.
| Bifrost | O que faz lá | No INFRO |
|---|---|---|
| Chaves virtuaismesmo formato | Modelos e provedores permitidos, orçamentos, rate limits, validade. | Chaves do gateway com listas de permissões, listas de provedores, limites de gastos, tiers de taxa de requisições, faixas de IP, rotação. |
| Orçamentos hierárquicosmesmo formato | Entre chaves virtuais, equipes e clientes. | Em organização, projeto, membro, chave e cliente final, mantidos sob concorrência. |
| Fallbacks e retentativasmesmo formato | fallbacks e backoff de novas tentativas por provedor. | fallbacks e rotas com regras de falha por tipo. |
| Balanceamento de carga entre chavesmesmo formato | Entre chaves de provedor; adaptativo no Enterprise. | Distribuído entre as chaves de um provedor, chaves em espera por último; rotas ponderadas. |
| Cache semânticodiferente | Exato e semântico, no seu próprio vector store. | Apenas correspondência exata, hospedado. |
| Observabilidadediferente | Métricas Prometheus, tracing OTel, logs de requisições. | Log de requisições e traces com custo estimado, exportações, spans para o seu collector OpenTelemetry. Sem endpoint Prometheus. |
| Guardrails, SSO, logs de auditoriamesmo formato | Tier Enterprise. | Guardrails nos planos que os incluem; SSO e SCIM a partir do Business; um log de auditoria. |
| Pluginsnada | Plugins personalizados em Go no caminho da requisição. | Nada. O INFRO não executa o seu código. |
| Auto-hospedagemdiferente | Apache 2.0, em qualquer lugar. | Hospedado. Auto-hospedado ou híbrido é um contrato enterprise.Enterprise — Disponível em um contrato enterprise, não em self-service. |
Nossa leitura da documentação publicada do Bifrost, não um teste nem um benchmark. Se lemos algo errado, avise-nos e corrigimos a linha.
O que o INFRO não faz
- Rodar na sua rede sem contrato enterprise, ou sob uma licença open source.
- Cache semântico, afinidade de sessão, plugins, jobs de inferência assíncronos.
- Um endpoint de métricas Prometheus.
O que não é levado
- Logs no seu armazenamento de logs do Bifrost. Não há importador.
- Chaves virtuais. Emita chaves de gateway do INFRO e migre os chamadores para elas.
Perguntas
- Mantenho minhas contas de provedor?
- Sim. Elas viram conexões do INFRO e continuam cobrando você diretamente. O INFRO adiciona 0% ao gasto com modelos.
- O campo `fallbacks` continua funcionando?
- Sim. O INFRO aceita
fallbackscomo uma lista de até 5 ids de modelo. - O INFRO pode rodar na nossa infraestrutura?
- Somente mediante contrato enterprise. Os planos são hospedados.
Migre conosco ou por conta própria
O programa de migração mapeia, numa chamada, a sua configuração do Bifrost para conexões, rotas e orçamentos do INFRO e migra o primeiro serviço com você. Seus provedores continuam cobrando você diretamente; o INFRO é uma assinatura e acrescenta 0% ao gasto com modelos.
Fontes
Cada afirmação desta página sobre o Bifrost vem de uma destas fontes, lidas em 19 de outubro de 2026. Nada é inferido de um teste, de um benchmark ou de uma conversa.
- GitHub — maximhq/bifrostlido em 19 de out. de 2026
- Bifrost docs — Virtual keyslido em 19 de out. de 2026
- Bifrost docs — OpenAI SDKlido em 19 de out. de 2026
- Bifrost docs — Request optionslido em 19 de out. de 2026
- Bifrost docs — Fallbackslido em 19 de out. de 2026
- Bifrost docs — Semantic cachinglido em 19 de out. de 2026
- Maxim — Bifrost pricinglido em 19 de out. de 2026