Escolhendo um modelo: de fronteira, barato e aberto
O melhor modelo para uma tarefa é o mais barato que passa nos seus testes. Preço, velocidade e privacidade importam tanto quanto as pontuações de benchmark, e modelos no estilo DeepSeek tornam esse trade-off concreto.
Pense em faixas, não em marcas
- Modelos de fronteira (as melhores ofertas de Anthropic, OpenAI, Google): os melhores em trabalho longo, ambíguo e com vários arquivos, e em se recuperar de erros. Maior preço por token. Use para planejamento, bugs difíceis e código sensível à segurança.
- Variantes rápidas e pequenas dos mesmos fornecedores: muito mais baratas e rápidas, boas para edições com instrução clara, testes, renomeações e resumos.
- Modelos open-weight e de baixo custo (DeepSeek, Qwen, Kimi, GLM e outros): muitas vezes próximos da fronteira em benchmarks de código por uma fração do preço, e alguns podem rodar no seu próprio hardware. A qualidade varia por tarefa e por harness, então meça no seu código.
- Modelos locais: nada sai da máquina; úteis para código privado e trabalho offline. Limitados pelo seu hardware, então geralmente menores e mais lentos que os hospedados.
Sobre o DeepSeek em particular
DeepSeek é uma família de modelos, não uma ferramenta de código. Você o usa por meio de um harness que consiga alcançá-lo: sua própria API, um roteador como o OpenRouter, um host em nuvem ou um runtime local se você executar os pesos abertos por conta própria. O mesmo modelo pode se comportar de forma bem diferente dependendo do harness.
Duas perguntas decidem se ele serve ao seu projeto. Primeiro, a qualidade: execute suas próprias tarefas e testes em vez de confiar em um leaderboard. Segundo, os dados: ao usar o serviço hospedado do fornecedor, seu código e seus prompts são processados sob os termos de privacidade e a jurisdição desse serviço. Muitas empresas restringem ou proíbem enviar código proprietário a alguns serviços hospedados. Leia a política atual, verifique as regras da sua empresa e considere um host em que você confie ou executar os pesos abertos por conta própria quando o código for sensível.
Uma política de roteamento que funciona
Não escolha um único modelo para tudo. Use um modelo forte para planejar e revisar, um mais barato para executar edições bem especificadas e os testes como juiz. Muitos harnesses permitem definir um modelo padrão e sobrescrevê-lo por agent ou por tarefa. O exemplo abaixo é ilustrativo: as chaves exatas diferem por ferramenta.
planning: { model: frontier, why: "ambiguidade e arquitetura" }
implementing: { model: fast-or-open, why: "spec clara, testes verificam" }
review: { model: frontier-from-a-different-vendor, why: "segunda opinião independente" }
sensitive-code:
allowed_providers: ["self-hosted", "company-approved-cloud"]
forbidden: ["consumer chat endpoints", "unreviewed third-party routers"]Meça antes de se comprometer
- Monte um pequeno benchmark privado com tarefas reais do seu repositório (uma correção de bug, uma funcionalidade, um refactor) com testes que decidem aprovação ou reprovação.
- Compare o custo por tarefa resolvida, não o preço por token: um modelo barato que precisa de três tentativas pode custar mais que um forte que acerta de primeira.
- Acompanhe os modos de falha: APIs inventadas, edições quebradas, desistir cedo, ignorar instruções.
- Reexecute quando surgir um novo modelo ou o seu harness mudar; os resultados envelhecem em meses.
- Verifique o tratamento de dados de cada provider na cadeia, incluindo roteadores que encaminham seus prompts para outro lugar.
conexões no mapa
- Modelo, harness e providersepara o modelo emEscolhendo um modelo: de fronteira, barato e aberto
- Escolhendo um modelo: de fronteira, barato e abertoalimentaQuando usar o quê
atualizado em 14/10/2026 · fontes para aprofundar · reportar erro
Estude antes
Desbloqueia
teste o que entendeu
Carregando perguntas…