Saltar para o conteúdo principal
start_within é obrigatório em cada requisição FlexInference. Ele define por quanto tempo o roteador pode esperar que a requisição seja iniciada. Use default, priority ou auto quando quiser um nível de provedor diretamente. Use uma duração quando quiser que o FlexInference tente o flex primeiro em um modelo capaz de flex, e então escale para o padrão se o flex não puder iniciar a tempo. O campo possui quatro formas.

​
As quatro formas

Encaminha para o nível padrão em tempo real do provedor com preço padrão: default da OpenAI, standard da Gemini ou standard_only da Anthropic. Funciona com qualquer modelo.
default, priority e auto fazem proxy de qualquer modelo para seu provedor (OpenAI, Gemini ou Anthropic). Apenas uma duração solicita a corrida flex. Se o modelo não puder usar flex, uma duração retorna 400 (flex_unsupported_for_anthropic ou flex_model_not_capable); use um valor de nível em vez disso.
A corrida flex não está disponível no Claude porque a Anthropic não possui um nível flex. Uma duração start_within em um modelo claude-* retorna 400 flex_unsupported_for_anthropic. A Anthropic ainda funciona com requisições de proxy de nível default, priority e auto.
Uma duração start_within não pode ser combinada com parâmetros de Chat Completions apenas nativos, como logprobs ou seed. Remova esses parâmetros ou use default, priority ou auto em vez disso.

​
A corrida flex

Com uma duração, o FlexInference tenta primeiro o nível flex do provedor (OpenAI ou Gemini). O flex é cobrado pela metade da taxa padrão, mas a capacidade é de melhor esforço. O roteador aguarda o início da requisição upstream dentro do seu prazo:
1

Disparar flex

O FlexInference envia sua requisição para o nível flex e aguarda a confirmação do provedor de que ela está sendo atendida, tudo dentro do tempo que você definiu.
2

Comprometer-se com flex

Se o provedor iniciar a requisição a tempo, o FlexInference se compromete. Sua resposta é transmitida normalmente, cobrada a taxas flex. A resposta mostra "service_tier": "flex".
3

Escalar para o padrão

Se o flex não puder iniciar a tempo, o FlexInference o cancela e envia a requisição para o padrão. Esta é uma escalada do flex mais barato para o padrão, não um downgrade. A resposta mostra "service_tier": "default" (OpenAI) ou "standard" (Gemini).
A escalada para o padrão ocorre apenas antes do início do flex, quando o flex retorna um 429 (sem capacidade), qualquer 5xx, uma falha pré-início ou nenhum início antes do prazo. A mudança de flex para padrão é a única alteração de nível que o FlexInference faz. Um fallback de provedor, onde você define um array provider opcional e o FlexInference tenta a próxima rota após uma rota falhar transitoriamente, muda a rota, nunca o nível ou o modelo. Uma chave ausente para qualquer rota que você nomeou é um erro de configuração em vez de uma falha transitória, então retorna um 400 em vez de prosseguir. Consulte roteamento de provedor.
Escolha a duração mais longa que sua UX pode tolerar. Prazos mais longos dão ao flex mais tempo para vencer, aumentando a proporção de requisições atendidas com a taxa mais barata.

​
Lendo o resultado

Respostas 200 bem-sucedidas incluem cabeçalhos de resultado Flex em cada endpoint, tanto para chamadas de streaming quanto para não-streaming. Respostas de erro usam o corpo do erro em vez disso. Os valores x-flexinference-flex-reason ao vivo são:
Uma duração que não pode executar uma corrida flex retorna 400 (flex_unsupported_for_anthropic em um modelo claude-*, flex_model_not_capable em um modelo OpenAI/Gemini não capaz de flex); as razões do cabeçalho descrevem apenas requisições que executaram flex ou não o solicitaram.

​
Quando o pool flex está indisponível

O nível flex usa capacidade compartilhada e de melhor esforço. Antes do início de uma requisição, o flex pode retornar um 429 quando não há capacidade, retornar qualquer 5xx, falhar antes do início ou perder o prazo. O FlexInference então envia a requisição para o padrão. Em casos raros, o flex falha depois que a requisição foi aceita e começou a transmitir. O FlexInference expõe essa falha. Em uma requisição de streaming, você recebe um evento response.failed terminal. Em uma requisição não-streaming, você recebe um 502. Ele não tenta novamente após o comprometimento porque isso poderia mascarar uma requisição incompleta. Se isso acontecer, tente novamente, ou use default, priority ou auto para pular o flex.

​
Retentativa de transporte

A corrida flex decide qual nível atende à sua requisição. A retentativa de transporte decide o que acontece quando esse nível falha ao iniciar. Adicione um objeto retry opcional e o FlexInference aguarda e tenta novamente o nível estabelecido em caso de falha upstream transitória, em vez de retornar o erro para você.
Um retry inválido retorna 400 invalid_retry. O FlexInference tenta novamente apenas uma falha de transporte genuína pré-comprometimento do nível estabelecido: um 429 real, um 5xx real ou uma conexão que nunca foi aberta (upstream_unavailable). Ele não tenta novamente um 4xx do cliente, uma falha de autenticação upstream (upstream_auth_failed), um timeout upstream (upstream_timeout) ou uma requisição que o cliente cancelou. Esses falham da mesma forma em uma nova tentativa ou significam que o chamador já se foi. A retentativa tenta novamente o nível que estabeleceu sua requisição, não a perna flex. Em uma requisição default, priority ou auto, esse é o nível que você nomeou. Em uma requisição de duração que perde a corrida flex, é o nível padrão para o qual você escalou. A tentativa flex e a escalada são o trabalho próprio da corrida flex e nunca contam contra count. Escalar um nível e tentar novamente o mesmo nível são etapas separadas que se encadeiam: o flex perde para o padrão, então o padrão pode tentar novamente. Quando o provedor envia um cabeçalho Retry-After, o FlexInference espera esse tempo em vez do cronograma de backoff, limitado a 60 segundos para que um valor ruim não possa estacionar sua requisição.
A retentativa é apenas pré-comprometimento. Ela para no momento em que um nível se compromete, que é a linha de status 200 para chamadas de streaming e não-streaming. Uma vez que o primeiro byte está a caminho de você, o FlexInference nunca tenta novamente, a mesma regra que a corrida flex segue após o comprometimento. Uma falha no meio do stream, ou um 502 não-streaming após um 200 comprometido, é repassada para você.
A retry do lado do servidor é separada de qualquer loop de retentativa em seu cliente, e os dois se acumulam. Os SDKs do FlexInference não tentam novamente, mas um SDK padrão da OpenAI ou Anthropic tenta novamente duas vezes por padrão. Um cliente que tenta novamente duas vezes além de um count de 3 no servidor gera até seis tentativas upstream, porque cada tentativa do cliente executa um orçamento completo do servidor. Quando você define retry, o FlexInference carimba x-flexinference-retries na resposta com o número de novas tentativas que executou, para que você possa diminuir o max_retries do seu cliente.

​
Cobrança

Com BYOK, o FlexInference usa sua chave de provedor criptografada armazenada no lado do servidor; você não envia chaves de provedor por requisição. Seu provedor cobra sua conta pela taxa do nível que atendeu à requisição. Você paga taxas flex quando o flex se compromete e taxas padrão após a escalada. Uma tentativa flex pode consumir alguns tokens antes de falhar. Seu provedor cobra esse uso da mesma forma que cobraria se você chamasse o flex diretamente, e o FlexInference o inclui no uso. O FlexInference não adiciona nenhuma margem de lucro aos seus tokens. Ele cobra 20% do dinheiro que economiza para você e não cobra nada quando não há economia.

​
O que o FlexInference muda

O FlexInference pode mudar o nível. Ele não muda o significado da sua requisição ou o resultado do provedor. Ele nunca reescreve o status ou a mensagem de um provedor. Ele normaliza apenas o envelope de erro: um erro é retornado no formato do endpoint que você chamou (OpenAI em respostas e chat, Anthropic em mensagens, Google em interações), carregando o status e a mensagem do provedor, para que seu SDK possa analisá-lo. Consulte Erros.
start_within é obrigatório. Sem ele, a requisição retorna 400 missing_start_within, inclusive com um SDK OpenAI simples apontado para nossa URL base. Se você enviar um valor que o FlexInference não pode ler, você receberá invalid_start_within. Valores válidos são "default", "priority", "auto" ou uma duração como "00h-00m-30s". A palavra standard costumava ser permitida e não é mais, então envie default em vez disso. Consulte Erros para a lista completa.