Qual modelo da Cerebras usar para RAG de altíssima velocidade, e o que o seu pipeline precisa ter

Resposta curta: para RAG textual em produção na API pública da Cerebras, use gpt-oss-120b com reasoning_effort="low". E não porque ele ganhou uma comparação de três candidatos: porque ele é o único modelo de produção do catálogo público. Os outros dois são preview, e a própria documentação diz que preview não deve ir para produção.

Quem procura "melhor modelo da Cerebras para RAG" costuma encontrar comparativos com três, cinco ou sete modelos, tabelas de tokens por segundo e um veredito do tipo "depende do seu caso".

Fui conferir o catálogo público de agosto de 2026 e a resposta é bem menos interessante como comparativo, e bem mais útil como decisão: o catálogo público self-service tem três modelos, e só um deles está em produção.

Isso muda a pergunta. Ela deixa de ser "qual dos três" e passa a ser duas outras, que este artigo responde: por que o modelo de produção é adequado para RAG e, principalmente, o que o seu pipeline precisa ter para que a velocidade da infraestrutura signifique alguma coisa.

Porque é aqui que quase todo projeto se perde: a Cerebras acelera uma etapa do RAG, e normalmente não é a etapa que está lenta.

O catálogo público em agosto de 2026

Três leituras que a tabela sozinha não entrega.

"Preview" ali não é um selo de novidade, é um aviso jurídico. A documentação de modelos afirma que os modelos em preview servem apenas para avaliação e não devem ser usados em produção, porque podem ser descontinuados com pouco aviso. Isso não é ressalva de rodapé: elimina Gemma 4 31B e GLM-4.7 de qualquer arquitetura que precise durar.

O GLM-4.7 tem data de morte antes do fim deste mês. Ele sai de linha em 17 de agosto de 2026. Um detalhe que diz muito sobre o estado do catálogo: os exemplos de código do guia oficial de boas práticas da Cerebras usam justamente zai-glm-4.7. Se você copiar aquele código hoje, ele para de funcionar em menos de duas semanas.

Qwen e Llama não estão no catálogo público. Muito material recente ainda lista Qwen3 como opção self-service da Cerebras. O endpoint público do Qwen3-32B foi descontinuado em 16 de fevereiro de 2026, com o próprio gpt-oss-120b como recomendação de migração. A família Qwen continua existindo na Cerebras, mas em endpoints dedicados, que exigem contrato e não são comparáveis a gerar uma chave de API e começar.

Por que o GPT-OSS-120B serve bem para RAG

Além de ser o único de produção, ele reúne quatro coisas que raramente aparecem juntas.

A Cerebras o posiciona explicitamente para esse uso. A página do modelo o descreve como adequado a processar documentos extensos para perguntas e respostas e sumarização. E, no guia de escolha de modelo, na linha de extração e compreensão de linguagem com baixa latência, ele é o único modelo listado. Vale notar que não existe uma linha "RAG" nessa tabela, então ninguém pode dizer que "a Cerebras recomenda X para RAG"; o que existe são as duas categorias vizinhas, e ele domina as duas.

A arquitetura é econômica por desenho. Apesar do nome, são 117 bilhões de parâmetros totais com cerca de 5,1 bilhões ativos por token, numa mistura de especialistas. Você paga inferência de um modelo pequeno com repertório de um grande.

O esforço de raciocínio é configurável. Ele aceita reasoning_effort em low, medium e high. Para RAG clássico, em que a resposta já está literalmente nos trechos recuperados, low é a configuração certa: você não está pedindo ao modelo que descubra a resposta, está pedindo que a redija com fidelidade. Guarde medium e high para quando a pergunta exigir cruzar documentos ou resolver contradição.

Duas ressalvas importantes aqui. Não existe none nem minimal para esse modelo: o piso é low. E os tokens de raciocínio são cobrados como saída, que é a tarifa cara. Deixar o esforço alto por inércia é assinar um cheque em branco.

O preço é o menor do catálogo. US$ 0,35 na entrada e US$ 0,75 na saída, contra US$ 0,99 / US$ 1,49 do Gemma e US$ 2,25 / US$ 2,75 do GLM.

Velocidade: dois números verdadeiros e diferentes

Aqui preciso ser transparente, porque este mesmo blog publicou uma correção sobre isso ontem.

A Cerebras publica cerca de 3.000 tokens por segundo para o gpt-oss-120b. Esse número não está só num post de lançamento antigo: ele está na coluna de velocidade do catálogo de modelos e na página do próprio modelo, na documentação vigente.

A Artificial Analysis, que mede de forma independente, registra 1.851 tokens por segundo, com 1,55 segundo até a primeira resposta. E afirma na página de provedores que nenhum provedor chega perto de 3.000.

Os dois números são reais e têm origens diferentes: um é especificação declarada pelo fornecedor, o outro é medição de terceiro. Um comparativo honesto mostra os dois. Para dimensionar capacidade, use o medido.

E mesmo o número medido é excelente: contra os 50 a 400 tokens/s típicos de endpoints de GPU, continua sendo uma ordem de grandeza de diferença.

A conta que interessa: quanto custa uma consulta

Vamos a um cenário concreto de RAG corporativo:

• 10 mil tokens de entrada por consulta, somando instruções, regras e os trechos recuperados;
• 500 tokens de saída faturáveis;
• 100 mil consultas por mês.

O modelo de produção é 2,75 vezes mais barato que o Gemma e 6,16 vezes mais barato que o GLM. Para um produto com milhões de consultas, isso vira dezenas de milhares de dólares por ano.

A conta cobre só os tokens do gerador. Ficam de fora embeddings, parsing de arquivos, banco vetorial, reranking, rede e observabilidade, que em muitos projetos somam mais que o próprio modelo.

Sobre o "plano gratuito": ele não existe. A documentação responde diretamente que não há camada permanentemente gratuita. O que existe é um Free Trial com US$ 5 em créditos que expiram 30 dias depois de concedidos, e ele exige método de pagamento verificado. O teto de 1 milhão de tokens por dia é limite de vazão do trial, não cota gratuita renovável.

A parte que ninguém conta: a Cerebras acelera a etapa que já era rápida

Um RAG tem duas metades.

A recuperação vai da pergunta até os trechos selecionados: busca vetorial, busca textual, filtros de permissão, reranking. A geração pega esses trechos e escreve a resposta.

A Cerebras executa só a segunda metade. E aqui está o dado que muda o projeto: a Cerebras não tem endpoint de embeddings. Não existe /embeddings na API, não há modelo de embedding no catálogo. Toda a recuperação fica por sua conta, em Milvus, pgvector, Qdrant, Pinecone, Weaviate ou o que você escolher.

Outro detalhe prático: entre os bancos vetoriais, só o Milvus tem página de integração oficial. Os outros funcionam, porque a API é compatível com o formato da OpenAI, mas você monta sozinho.

Faça as contas com o número medido. A 1.851 tokens por segundo, uma resposta de 500 tokens leva 0,27 segundo de geração. Some 1,55 segundo até a primeira resposta e você tem menos de 2 segundos na etapa que a Cerebras acelera.

Agora pergunte quanto tempo levam a busca vetorial, o reranking, as três chamadas ao seu banco de permissões e a renderização no navegador. Na maioria dos pipelines reais, a geração vira a menor fatia do gráfico.

Isso não diminui o valor da plataforma, inverte o roteiro do projeto: com a geração resolvida, o gargalo passa a ser a sua engenharia de recuperação. Se o recuperador trouxer o documento errado, a Cerebras vai entregar a resposta errada mais rápido do que qualquer concorrente.

Cinco otimizações que a documentação entrega de graça

Esta é a parte que separa quem leu a documentação de quem leu um comparativo.

1. Ordene o prompt para o cache pegar

O prompt caching guarda prefixos idênticos em blocos de 128 tokens, com permanência mínima garantida de 5 minutos, podendo chegar a uma hora. Para aproveitar, o começo da requisição precisa ser byte a byte igual entre chamadas. A ordem certa é:

1. prompt de sistema estável;
2. regras de resposta e formato;
3. esquemas de ferramentas;
4. instruções de citação;
5. contexto recuperado (muda a cada consulta);
6. pergunta do usuário (muda sempre).

Duas armadilhas: o cache não dá desconto nenhum, os tokens são cobrados pela tarifa cheia de entrada, e o ganho é só de latência. E ele existe apenas no gpt-oss-120b e no zai-glm-4.7: o gemma-4-31b não tem cache, então qualquer estratégia de prompt longo com o Gemma não se aplica.

2. Comprima o payload com gzip, não com MessagePack

A plataforma aceita gzip e MessagePack. Num exemplo oficial com payload de cerca de 50 mil tokens, a compressão chega perto de 98%.

O detalhe que se perde na leitura rápida: quem entrega os 98% é o gzip. O MessagePack sozinho rende algo em torno de 5% num payload de chat, porque texto natural continua sendo texto depois de virar binário. Em RAG, onde você manda dezenas de milhares de tokens de contexto, o gzip encurta visivelmente o tempo até a primeira resposta.

3. max_completion_tokens não é só um teto, é orçamento de rate limit

Este é o item menos conhecido e o mais caro de ignorar.

O rate limit da Cerebras é aplicado antes do processamento, por estimativa: ela soma os tokens de entrada do prompt com o max_completion_tokens que você declarou. Se você pedir 4.000 tokens de saída para uma resposta que terá 400, os 3.600 restantes foram debitados da sua cota mesmo sem existir.

Para RAG corporativo, um teto entre 300 e 700 tokens costuma bastar e libera vazão real.

4. Não deixe o navegador ser o gargalo

A plataforma pode enviar cerca de 200 eventos SSE por segundo. Se o seu frontend renderizar Markdown a cada evento, a interface fica mais lenta que o modelo, e o usuário vai culpar a IA.

A recomendação oficial é acumular os eventos e atualizar a tela em intervalos próximos de 50 milissegundos. E usar streaming seletivamente: para respostas abaixo de cerca de 200 tokens, a resposta completa chega tão rápido que o streaming atrapalha mais do que ajuda. Note que a orientação é de uso seletivo, não uma proibição.

5. Conheça o seu teto real de vazão

No plano Developer, o gpt-oss-120b tem 1 milhão de tokens por minuto e 1.000 requisições por minuto, sem limites horários ou diários. No Free Trial, os três modelos ficam em 5 requisições por minuto e 30 mil tokens por minuto.

Com uma consulta de RAG somando cerca de 10.500 tokens, o teto de tokens por minuto é atingido bem antes do teto de requisições. Isso coloca a capacidade teórica em torno de 95 consultas por minuto no Developer, antes de considerar cache e variação de tamanho.

Um detalhe em rollout: o sistema separa tokens servidos do cache dos tokens processados do zero, o que amplia a vazão quando há prefixo repetido. Se a sua organização ainda não vê esse limite no console, ele deve aparecer até 17 de agosto de 2026.

Como evitar alucinação sem trocar de modelo

Em RAG, trocar de modelo é a alavanca menos eficiente. Estas pesam mais:

Resposta restrita às fontes. O prompt precisa proibir explicitamente conhecimento externo e exigir uma resposta de insuficiência quando não houver evidência.

Citações verificáveis. Cada trecho recebe um identificador estável. Depois da geração, a aplicação confere se toda citação usada existe no contexto enviado. É barato e pega uma classe inteira de erro.

Piso de relevância. Se a busca e o reranker não atingirem uma pontuação mínima, não empurre trechos fracos só para produzir alguma resposta.

Verificação posterior. Para resposta crítica, uma segunda chamada curta confere se cada afirmação se sustenta e se os números batem. Em área jurídica, financeira ou de saúde, isso não substitui revisão humana.

Quando sair da API pública

Endpoints dedicados fazem sentido quando você precisa de capacidade reservada, isolamento, latência previsível, pesos próprios ou um modelo que não está no catálogo público. Lá dentro existem 13 famílias, incluindo Kimi, Qwen3, GLM 5, MiniMax, DeepSeek, Llama e Mistral, além da possibilidade de subir seus próprios pesos ajustados.

Uma ressalva para quem vai fazer orçamento: a página de endpoints dedicados não publica número de SLA, nem de uptime nem de latência garantida. Fala em priorização de requisições para atender ao SLA do cliente, o que é diferente de um compromisso numérico. Isso se negocia.

Veredito

Para RAG textual na API pública: gpt-oss-120b com reasoning_effort="low". Não por vitória em comparativo, mas porque é o único de produção, é o mais barato, é o mais rápido e a documentação o posiciona exatamente para extração e perguntas sobre documentos.

Se o seu RAG precisa enxergar: documento escaneado, tabela com diagramação, print de tela. Aí entra o gemma-4-31b, com duas ressalvas honestas: ele está em preview e custa quase três vezes mais. A arquitetura eficiente não é usar Gemma em tudo, é extrair o texto e roteirizar para ele só as páginas em que o layout carrega significado.

O que não fazer: começar um projeto novo no zai-glm-4.7. Ele sai de linha em 17 de agosto de 2026, e a Cerebras não indicou substituto para ele, ao contrário de todas as outras descontinuações do histórico.

E a conclusão que vale mais que a escolha do modelo: a Cerebras resolve a geração, e a geração provavelmente não é o seu problema. Com ela, um RAG bem construído responde quase na velocidade de uma busca tradicional. Um RAG mal construído passa a errar mais rápido.

Se quiser discutir isso aplicado à sua base de documentos, fale com o nosso time sobre agentes de IA para empresas.

---

Leia também:

• Rápido, barato e bom: como escolher a IA que atende o seu cliente
• RAG na prática: guia para chatbot com base de conhecimento
• Dados sensíveis em RAG: privacidade, redaction e controle de acesso
• Testes de regressão de prompts e RAG
• LLMOps: métricas, logs e evals de IA em produção

Catálogo, preços, limites e capacidades verificados na documentação oficial da Cerebras em 5 de agosto de 2026. Medições de velocidade da Artificial Analysis são medianas móveis e mudam com o tempo. Modelos em preview podem sair de linha com pouco aviso: confirme o status antes de fechar arquitetura.