Escolher um provedor de LLM por pontuações de benchmark é como escolher um restaurante pelas fotos do menu. O modelo importa, mas tudo ao redor do modelo também importa, e são essas coisas ao redor que realmente te prejudicam em produção. Esta é a lista de verificação que aplico a um provedor antes de apontar qualquer coisa real para ele.
Uptime e SLA
Um SLA é uma promessa com números anexados, então leia os números. As porcentagens de uptime parecem enganosamente próximas até você convertê-las:
| SLA | Indisponibilidade por ano | Indisponibilidade por mês |
|---|---|---|
| 99,9% | 8,76 horas | 43,8 minutos |
| 99,95% | 4,38 horas | 21,9 minutos |
| 99,99% | 52,6 minutos | 4,4 minutos |
99,9% soa excelente e ainda permite quase uma hora de indisponibilidade mensal. Se o seu produto depende do endpoint, 99,9% versus 99,99% é a diferença entre "irritante" e "esquecível". Verifique também duas coisas além do número principal:
•O que conta como indisponibilidade. Alguns SLAs cobrem apenas quedas totais, não throughput degradado ou altas taxas de erro.
•O que você recebe quando eles falham. Um crédito vale pouco se o crédito for limitado ou exigir que você abra uma reclamação. O remédio deve ser concreto.
Um provedor que não publica um SLA de forma alguma está te dizendo algo, e não é bom.
Latência e throughput
A latência tem dois números que importam para você e eles medem coisas diferentes:
•Tempo até o primeiro token (TTFT). Quanto tempo até a resposta começar a transmitir. Isso é o que o usuário sente como "ágil".
•Tokens por segundo (throughput). Quão rápido o restante da resposta chega. Isso é o que determina se uma resposta longa parece lenta.
Ambos variam por modelo e por carga, então não confie em um número de marketing. Meça você mesmo:
import time
from openai import OpenAI
client = OpenAI(base_url="https://api.token8341.com/v1",
api_key="sk-your-key")
start = time.perf_counter()
stream = client.chat.completions.create(
model="deepseek-chat",
messages=[{"role": "user", "content": "Write 200 words about caching"}],
stream=True,
)
ttft = None
tokens = 0
for chunk in stream:
if ttft is None:
ttft = time.perf_counter() - start
tokens += 1
elapsed = time.perf_counter() - start
print(f"TTFT: {ttft:.2f}s, total: {elapsed:.2f}s, "
f"{tokens / elapsed:.1f} tok/s")Execute isso em diferentes horários do dia e sob a concorrência que você espera. Um provedor que é rápido às 10h e lento às 19h tem um problema de capacidade sobre o qual você precisa saber.
Custo
O preço por token é a parte fácil. O quadro completo de custos inclui:
•Preços de entrada vs. saída, já que a saída geralmente custa várias vezes a entrada.
•Preço de acerto de cache. Para cargas de trabalho repetitivas, um cache de prompt pode reduzir o custo mais do que qualquer desconto.
•Limites de taxa e throttling. Um endpoint barato que você só consegue acessar com parcimônia não é barato depois que você adiciona enfileiramento e retentativas.
•Moeda e atrito de pagamento. Taxas de cartão transfronteiriças e custos de conversão são reais para equipes pequenas.
Peça o preço da sua carga de trabalho real, não o preço por milhão de tokens isoladamente.
Cobertura de modelos e compatibilidade
•A API é compatível com OpenAI? Se for, você pode usar os SDKs padrão e trocar depois sem reescrever. Se for proprietária, você está se casando com o provedor.
•Você consegue acessar várias famílias de modelos com uma única chave? Um catálogo com um ou dois modelos te prende tão firmemente quanto uma API proprietária. Um catálogo com muitos modelos te dá um fallback e um caminho para roteamento mais barato.
•Embeddings, chamada de funções e streaming são suportados, não apenas chat simples? Esses são os recursos que decidem se o endpoint serve para um aplicativo real ou apenas para uma demonstração.
Tratamento de dados e suporte
•Retenção de dados. O provedor mantém seus prompts e completions para treinamento? Obtenha isso por escrito.
•Região e residência. Onde as requisições são processadas? Para alguns usuários isso é um requisito legal, não uma preferência.
•Qualidade do suporte. Tente abrir um ticket de suporte antes de se comprometer. A velocidade e a utilidade da primeira resposta são um forte indicador de como será uma indisponibilidade.
•Transparência de status. Uma página de status pública e um histórico de incidentes dizem se o provedor é honesto sobre sua própria confiabilidade.
A versão resumida
Passe cada candidato por estas cinco perguntas:
1.Qual é o SLA, e qual é o remédio quando ele é descumprido?
2.Quais são o TTFT e o throughput medidos sob a minha carga?
3.Quanto custa minha carga de trabalho real, incluindo acertos de cache?
4.A API é compatível com OpenAI, com vários modelos atrás de uma única chave?
5.Eles vão me dizer onde os dados são processados e como o suporte responde?
Nenhuma dessas perguntas exige expertise profunda. Elas exigem que você pergunte antes da indisponibilidade, não depois. Os provedores que respondem a elas com tranquilidade tendem a ser aqueles que realmente operaram tráfego de produção, em vez de apenas listar um modelo.
SiCore TokenWorks se encaixa facilmente na maioria desta lista: um SLA de 99,9%, um endpoint compatível com OpenAI em https://api.token8341.com/v1, uma chave cobrindo GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, Spark e Pangu, e cobrança medida por token com preço de acerto de cache.