EntrarContatoComeçar grátis
Base URL and SDK Migration27 de julho de 2026Flatkey Team

Uma URL Base Compatível com OpenAI para Testes de Prompts com Vários Modelos

Mantenha o SDK da OpenAI, troque apenas uma URL base e compare vários modelos com um fluxo controlado de testes de prompts e transição para produção.

Uma URL Base Compatível com OpenAI para Testes de Prompts com Vários Modelos

Sua aplicação já sabe como chamar um cliente compatível com OpenAI. Adicionar a escolha do modelo não deve exigir reconstruir essa integração para cada provedor.

A Flatkey oferece uma única URL base compatível com OpenAI:

https://router.flatkey.ai/v1

Aponte seu cliente SDK OpenAI existente para essa URL, use uma chave de API da Flatkey e escolha o modelo que deseja testar no campo model. Seu wrapper de requisição, conjunto de dados de prompts, rubrica de avaliação e código da aplicação podem permanecer centrados em uma única interface.

Isso torna a Flatkey uma opção prática quando sua equipe está pronta para comparar modelos, mas não quer que a configuração de contas específica de cada provedor e as reescritas do cliente virem o projeto de avaliação.

O caminho de menor atrito de um modelo para uma lista curta

Uma avaliação típica de modelo começa com uma pergunta simples: outro modelo pode melhorar a qualidade, a latência ou o custo para esta carga de trabalho?

O trabalho de implementação pode rapidamente ofuscar essa pergunta. Integrações separadas criam variáveis de ambiente, padrões de autenticação, comportamento de retentativa, adaptadores de resposta, painéis e relações de cobrança separados. Quando o harness de teste fica pronto, o experimento original de prompt se transformou em um projeto de infraestrutura.

Uma URL base compatível com OpenAI muda a sequência. Você mantém uma única estrutura de cliente e faz do modelo a variável principal.

Manter estável Alterar de forma deliberada Validar por modelo
SDK e wrapper de requisição base_url uma vez Qualidade da saída
Conjunto de dados de prompts model para cada execução Distribuição de latência
Rubrica de avaliação Parâmetros específicos do modelo quando necessário Uso de tokens e custo
Armazenamento de resultados Configurações de timeout ou retentativa quando justificadas Comportamento de ferramentas e saída estruturada
Observabilidade no lado da aplicação Roteamento de produção somente após a avaliação Padrões de erro e recusa

O objetivo não é fingir que todo modelo se comporta de forma idêntica. O objetivo é remover variações de integração evitáveis para que sua equipe possa dedicar mais tempo a medir as diferenças que importam.

Altere a URL base, não toda a sua camada SDK

Se você já usa o SDK Python da OpenAI, a mudança principal no cliente é pequena:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["FLATKEY_API_KEY"],
    base_url="https://router.flatkey.ai/v1",
)

O mesmo padrão funciona com o cliente JavaScript da OpenAI:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FLATKEY_API_KEY,
  baseURL: "https://router.flatkey.ai/v1",
});

Depois disso, use um ID de modelo do diretório atual de modelos da Flatkey na requisição. Não fixe suposições sobre o modelo com base em uma planilha ou artigo antigo; a disponibilidade e as capacidades dos modelos podem mudar.

response = client.chat.completions.create(
    model=os.environ["EVAL_MODEL_ID"],
    messages=[
        {"role": "system", "content": "Responda usando a política fornecida."},
        {"role": "user", "content": evaluation_prompt},
    ],
    temperature=0,
    max_tokens=800,
)

Esta é a principal vantagem de adoção: sua aplicação pode manter seu cliente compatível com OpenAI enquanto sua avaliação altera a seleção do modelo.

Um fluxo de trabalho focado de teste de prompts com vários modelos

Use o fluxo de trabalho a seguir para transformar uma migração de URL base em uma decisão que sua equipe possa defender.

1. Congelar o contrato da requisição

Comece com uma requisição que já represente a carga de trabalho de produção. Mantenha o seguinte fixo em toda a primeira rodada de comparação:

  • Prompts de sistema e de usuário
  • Exemplos de entrada
  • Temperatura e limites de tokens
  • Definições de ferramentas ou esquema de resposta
  • Política de timeout
  • Rubrica de avaliação

Se você alterar o prompt, o modelo e a política de repetição ao mesmo tempo, não saberá qual mudança produziu o resultado.

2. Criar um conjunto de avaliação pequeno e representativo

Não comece com centenas de prompts sintéticos. Comece com 20 a 50 exemplos que cubram os casos que seus usuários realmente criam:

  • Solicitações comuns e de alta frequência
  • Entradas longas ou confusas
  • Instruções ambíguas
  • Casos sensíveis à segurança ou propensos a recusa
  • Casos extremos de saída estruturada
  • Casos de chamada de ferramentas, se sua aplicação usar ferramentas

Remova dados privados e segredos antes de enviar o tráfego de avaliação. O melhor conjunto de avaliação é pequeno o suficiente para ser inspecionado e representativo o suficiente para expor falhas significativas.

3. Executar os mesmos casos em cada modelo candidato

Mantenha a URL base do Flatkey e o wrapper da requisição fixos. Itere pelos IDs de modelo na sua lista curta.

import time

candidate_models = [
    "MODEL_ID_A",
    "MODEL_ID_B",
    "MODEL_ID_C",
]

results = []

for model_id in candidate_models:
    for case in evaluation_cases:
        started_at = time.perf_counter()
        try:
            response = client.chat.completions.create(
                model=model_id,
                messages=case["messages"],
                temperature=0,
                max_tokens=case.get("max_tokens", 800),
            )
            elapsed_ms = round((time.perf_counter() - started_at) * 1000)
            results.append({
                "case_id": case["id"],
                "model": model_id,
                "latency_ms": elapsed_ms,
                "output": response.choices[0].message.content,
                "usage": response.usage.model_dump() if response.usage else None,
                "error": None,
            })
        except Exception as error:
            results.append({
                "case_id": case["id"],
                "model": model_id,
                "latency_ms": None,
                "output": None,
                "usage": None,
                "error": type(error).__name__,
            })

Use espaços reservados nos exemplos compartilhados e selecione os IDs de modelo atuais no diretório ao vivo antes de executar o teste. Confirme também que cada candidato oferece suporte aos recursos de que sua carga de trabalho precisa.

4. Avalie o resultado, não a reputação do modelo

Um scorecard útil separa requisitos obrigatórios de preferências.

Dimensão Pergunta de exemplo Tratamento sugerido
Correção A resposta atendeu à tarefa? Avaliador humano ou específico da tarefa
Seguir instruções Obedeceu às restrições e ao formato? Passa/falha mais observações
Saída estruturada A carga útil foi analisada e correspondeu ao esquema? Validação automatizada
Comportamento da ferramenta As chamadas foram válidas e selecionadas adequadamente? Verificações automatizadas mais revisão
Latência Quanto tempo levaram as solicitações bem-sucedidas? Mediana e percentis de cauda
Confiabilidade Com que frequência as solicitações falharam ou expiraram? Taxa de erro por classe
Uso Quantos tokens de entrada e saída foram reportados? Por caso e agregado
Custo Quanto custaria a carga de trabalho avaliada? Calcular com a precificação atual

Rejeite qualquer candidato que falhe em um requisito obrigatório, mesmo que seja barato. Entre os modelos restantes, compare os trade-offs que importam para o seu produto.

5. Refaça os testes dos finalistas com comportamento de produção

A primeira passada deve ser controlada. A passada dos finalistas deve ser realista.

Teste streaming se sua interface fizer streaming. Teste chamadas de ferramentas se seu agente usar ferramentas. Teste saídas estruturadas se o código downstream as analisar. Exercite suas configurações reais de timeout e retry e verifique como sua aplicação lida com limites de taxa, streams interrompidos, respostas malformadas e estados de conclusão ambíguos.

Os Usage Logs da Flatkey podem ajudar você a confirmar que as solicitações chegaram ao gateway e inspecionar a atividade das requisições. Mantenha também IDs de solicitação e dados de tempo do lado da aplicação, para que você possa conectar a visibilidade do gateway à experiência do usuário.

Para detalhes de retry e cutover, use o guia de migração do cliente OpenAI para limites de taxa e retries.

A compatibilidade é um ponto de partida, não uma promessa de comportamento idêntico

Uma API compatível com OpenAI reduz o trabalho de migração do cliente. Ela não torna modelos diferentes intercambiáveis.

Antes de aprovar um modelo para produção, verifique:

  • O ID exato do modelo está disponível no momento.
  • O modelo oferece suporte ao endpoint e à modalidade de que você precisa.
  • Os parâmetros exigidos são aceitos e se comportam como esperado.
  • Chamadas de ferramentas, JSON ou saídas estruturadas e streaming passam nos seus testes.
  • Os limites de tokens se ajustam às suas entradas e saídas reais.
  • O comportamento de segurança corresponde aos requisitos do seu produto.
  • Timeouts, retries e tratamento de erros não criam trabalho duplicado ou ambíguo.
  • Os preços atuais se encaixam na mistura de tráfego esperada.

Se você precisar de uma checklist de engenharia mais abrangente, veja o guia de migração para um gateway de API compatível com OpenAI. Esta página é intencionalmente mais restrita: ela é para equipes que já entendem o padrão de migração e querem transformar uma mudança de uma única base URL em um teste justo com vários modelos.

Uma checklist prática de cutover

Passe de avaliação para produção apenas quando puder responder sim a cada item.

  • Paridade de requisição: O finalista funciona com seu padrão real de prompt, mensagem, ferramenta e saída.
  • Limiar de qualidade: Ele atende aos requisitos rígidos da sua rubrica.
  • Tratamento de falhas: Sua aplicação lida com limites de taxa, timeouts e respostas interrompidas com segurança.
  • Observabilidade: Você registra modelo, latência, uso, classe de erro e um identificador de requisição da aplicação.
  • Modelo de custo: Você calculou o gasto esperado com base na precificação atual e no uso realista de tokens.
  • Rollback: Você pode retornar ao modelo ou configuração anterior sem uma nova versão de código.
  • Plano de canary: Você pode expor a mudança a uma fatia limitada do tráfego antes do rollout completo.

A interface estável facilita o rollback e testes repetidos porque a superfície de integração permanece consistente. Sua decisão de modelo pode mudar sem forçar, a cada vez, uma nova camada de cliente específica do provedor na aplicação.

Comece com uma única base URL e uma carga de trabalho real

Se sua equipe já usa um SDK compatível com OpenAI, o próximo passo útil não é outra discussão de arquitetura. É um teste controlado com seus próprios prompts.

  1. Crie uma conta Flatkey e uma chave de API.
  2. Defina base_url como https://router.flatkey.ai/v1.
  3. Selecione uma pequena shortlist de modelos no diretório atual.
  4. Execute os mesmos casos representativos em cada modelo.
  5. Revise qualidade, latência, confiabilidade, uso e custo atual em conjunto.

Compare a precificação atual dos modelos e escolha sua shortlist, depois execute a primeira avaliação usando o mesmo cliente que sua aplicação já utiliza.

Perguntas frequentes

Qual é a base URL compatível com OpenAI da Flatkey?

Use https://router.flatkey.ai/v1. Configure-a no seu cliente compatível com OpenAI e autentique-se com uma chave de API da Flatkey.

Preciso substituir o SDK da OpenAI?

Não. O quickstart da Flatkey documenta o uso dos SDKs OpenAI para Python e JavaScript com a base URL da Flatkey. Ainda assim, você deve testar cada recurso de requisição e cada capacidade de modelo de que sua aplicação depende.

Posso comparar vários modelos com o mesmo código de prompt?

Sim. Mantenha estáveis o cliente, o conjunto de prompts de avaliação e a lógica de avaliação e, então, altere o valor de model para cada candidato. Capacidades e parâmetros específicos do modelo ainda precisam de validação.

Compatibilidade com OpenAI é a mesma coisa que comportamento idêntico do modelo?

Não. A compatibilidade reduz mudanças de integração. Os modelos podem diferir em qualidade de saída, uso de ferramentas, comportamento de saída estruturada, latência, limites, comportamento de segurança e custo.

O que devo medir em um teste com vários modelos?

Meça a correção da tarefa, o seguimento de instruções, a validade de schema ou de ferramenta, latência, taxa de erro, uso de tokens e custo atual. Defina requisitos rígidos antes de comparar preferências.

Onde devo verificar os preços dos modelos?

Use a página de preços ao vivo da Flatkey em vez de copiar os preços para um documento de avaliação de longa duração.