Sua IA gasta 90% dos tokens “pensando”. E se ela parasse?

Quem já abriu o log de raciocínio de um modelo como o o3, Claude ou Kimi K3 sabe do que eu estou falando. Você faz uma pergunta simples, tipo “converte essa lista para um dict Python”, e o modelo gera parágrafos inteiros de deliberação interna antes de cuspir três linhas de código. Parece um desenvolvedor júnior explicando a própria solução numa PR de 47 comentários.

Esse desperdício tem um nome técnico: tokens de raciocínio. E um custo bem real. Em modelos reasoning como o Kimi K3, mais de 90% dos tokens gerados vão para o “pensamento” interno, não para a resposta final. Multiplique isso por milhares de chamadas por dia num pipeline agentico e sua fatura de API começa a parecer conta de hospital americano.

A Fireworks AI decidiu resolver esse problema de frente. O resultado é o Ember-1, um modelo que entrega a mesma qualidade do Kimi K3 usando 40% menos tokens. Lançado em 24 de setembro de 2026, ele já está rodando em produção com clientes reais e batendo fronteiras de Pareto que modelos como GPT-6 Sol e Claude Opus 5 não alcançaram.

Vamos ver como isso funciona na prática.

O problema que ninguém quer pagar pra resolver

Modelos de raciocínio são incríveis. Eles resolvem problemas complexos de matemática, debugam código, orquestram agentes. Mas essa capacidade vem com um custo escondido que a maioria dos desenvolvedores só descobre quando a fatura da API chega.

O ciclo funciona assim: o modelo recebe um prompt, entra num loop interno de “chain-of-thought” onde ele questiona a própria resposta, tenta abordagens alternativas, valida suposições, e só depois gera a resposta final. Esse processo é útil: é o que permite ao modelo pegar erros antes de entregar a resposta.

O problema? Nem toda tarefa precisa de toda essa deliberação. Se você pede pro modelo “crie um endpoint REST em FastAPI que retorna uma lista de usuários”, ele não precisa de 2.000 tokens de reflexão interna. Mas é exatamente isso que acontece com modelos como o Kimi K3 Max, o o3 e outros.

Esses números variam muito por tarefa, claro. Mas o padrão é claro: a maior parte do custo de um modelo reasoning vai pro lixo. O Ember-1 ataca exatamente esse desperdício.

Como a Fireworks treinou um modelo pra pensar menos (e melhor)

A abordagem óbvia seria simplesmente reduzir o reasoning_effort do modelo, tipo colocar num modo “lite”. Mas isso geralmente sacrifica qualidade. É como pedir pro dev pular o code review porque tá demorando: resolve o prazo, explode a produção.

A Fireworks fez diferente. Em vez de limitar o raciocínio, eles treinaram o Ember-1 para raciocinar de forma mais eficiente. O modelo aprendeu a distinguir entre reflexão útil (auto-correção, validação de lógica) e loops improdutivos (repetir a mesma verificação três vezes, reformular a resposta desnecessariamente).

O processo envolveu mais de 50 experimentos de treinamento e 200 avaliações. A equipe usou a própria plataforma Serverless Training da Fireworks, que permite iterar rápido sobre hipóteses de treinamento.

A receita do treinamento

O Ember-1 foi treinado em tarefas diversas de propósito:

• Matemática e raciocínio lógico
• Codificação e engenharia de software
• Seguir instruções complexas
• Conversação natural
• Busca e recuperação de informação
• Uso de ferramentas (function calling)
• Tarefas de agentes multi-turno

A ideia é que o modelo aprenda quando pensar mais e quando ir direto ao ponto. Numa tarefa de SWE-bench (debugging e correção de código real), ele mantém o raciocínio profundo. Numa conversação simples, ele corta o excesso.

# Exemplo de chamada ao Ember-1 via API
import openai

client = openai.OpenAI(
    base_url="https://api.fireworks.ai/inference/v1",
    api_key="fw_..."
)

response = client.chat.completions.create(
    model="accounts/fireworks/models/ember-1",
    messages=[
        {"role": "user", "content": "Refatore esse código para usar async/await"}
    ],
    max_tokens=4096
)

# 40% menos tokens de raciocínio vs Kimi K3
# mesma qualidade de resposta

Benchmarks: onde o Ember-1 realmente brilha

Números bonitos em benchmarks são fáceis de fabricar. A Fireworks publicou resultados em benchmarks padrão da indústria, mas o que chama atenção são os testes com clientes reais em produção.

Benchmarks de engenharia de software

O Ember-1 praticamente empata com o Kimi K3 Max em qualidade, mas gasta muito menos:

Vou repetir aquele número do DeepSWE porque ele merece: $126.90 de economia por tarefa. Se você roda 100 tarefas por dia, são quase $13.000 de economia por dia. Por mês, mais de $380.000.

E o SWE-bench Verified a 92.2% coloca o Ember-1 no mesmo patamar dos melhores modelos do planeta pra coding. Só que gastando menos pra chegar lá.

O teste Bedside Bench (Doximity)

O benchmark mais interessante talvez seja o Bedside Bench, criado pela Doximity pra avaliar modelos em tarefas médicas. O Ember-1 estabeleceu uma nova fronteira de Pareto nesse benchmark, superando tanto modelos open-source quanto closed-source, incluindo GPT-5.6 Sol, GPT-6 Astra e Claude Opus 5.

Isso é relevante porque mostra que a otimização do Ember-1 não é específica pra código. O modelo mantém a qualidade em domínios completamente diferentes.

Testes A/B em produção real

Dois clientes enterprise da Fireworks rodaram testes A/B com o Ember-1 em workloads de codificação reais. Os resultados:

• 35% de redução nos tokens por tarefa
• Métricas de qualidade (task completion, success scores) mantidas ou melhoradas
• Um dos clientes já migrou pra produção com o Ember-1

O time da própria Fireworks também trocou o modelo interno de coding pro Ember-1 sem avisar os desenvolvedores. Ninguém percebeu a diferença. “No news is good news”, nas palavras da empresa.

$3 por milhão de tokens de entrada. $15 de saída.

O pricing do Ember-1 segue a estrutura da Fireworks:

Com a janela de contexto de 1.048.576 tokens (1M), o modelo suporta repositórios inteiros de código num único prompt.

Mas o preço por token conta só metade da história. O verdadeiro diferencial é que o Ember-1 gera menos tokens pra chegar no mesmo resultado. Se o Kimi K3 Max gera 5.000 tokens pra resolver uma tarefa e o Ember-1 gera 3.000, você economiza 40% independente do preço por token.

Na prática, a economia total (preço por token x tokens gerados) fica entre 35% e 55% dependendo da tarefa. Pra empresas que gastam seis ou sete dígitos por mês em APIs de LLM, isso é dinheiro sério.

Por que modelos “eficientes” importam mais do que modelos “maiores”

A corrida de modelos de IA nos últimos dois anos seguiu uma lógica: quanto maior, melhor. Mais parâmetros, mais dados de treino, mais compute. O GPT-6 é maior que o GPT-5, que é maior que o GPT-4, e por aí vai.

O Ember-1 questiona essa lógica. Em vez de fazer o modelo maior, a Fireworks fez ele mais inteligente sobre quando e quanto pensar.

Isso importa por três razões:

1. Latência é experiência do usuário

Menos tokens de raciocínio significa resposta mais rápida. Num agente que faz 15 chamadas pra completar uma tarefa, reduzir 40% dos tokens em cada chamada pode ser a diferença entre 30 segundos e 18 segundos de espera total.

2. Custo escala exponencialmente em agentes

Agentes multi-turno são o caso de uso que mais cresce em IA. Cada turno gera tokens, e cada token custa dinheiro. Um agente que faz 50 turnos pra resolver um ticket de JIRA pode gastar $200 em tokens com o K3 Max. Com o Ember-1, esse custo cai pra $120.

3. Eficiência abre mercados

Empresas menores, que não podiam justificar $50.000/mês em API de LLM, agora podem rodar workloads agenticos. A redução de custo não é só economia pra quem já usa: é acesso pra quem não podia.

Comparação direta: Ember-1 vs a concorrência

Vou ser direto. Como o Ember-1 se compara com os modelos que você provavelmente já usa?

O Ember-1 não é o melhor modelo absoluto em nenhuma métrica isolada. O K3 Max ainda ganha por uma fração no SWE-bench. O Claude Opus 5 ainda é superior em tarefas de escrita e raciocínio criativo. O GPT-6 tem o ecossistema mais maduro.

Mas o Ember-1 é o melhor custo-benefício pra quem precisa de qualidade de tier-1 sem pagar tier-1.

Limitações que você precisa conhecer

Nem tudo são flores. O Ember-1 tem limitações importantes:

Research Preview: o modelo está disponível como preview por duas semanas na plataforma serverless da Fireworks. Se a comunidade não demonstrar interesse suficiente, ele pode ser descontinuado. Apostar sua stack inteira num modelo que pode sumir em 14 dias é arriscado.

Base Kimi K3: por ser construído sobre o Kimi K3 da Moonshot AI, o Ember-1 herda as limitações e vieses do modelo base. Se o K3 tem problemas com determinados tipos de prompt, o Ember-1 provavelmente também terá.

Otimização de raciocínio não é mágica: em tarefas que genuinamente precisam de raciocínio profundo (provas matemáticas complexas, debugging de race conditions), cortar tokens pode reduzir a qualidade. A Fireworks reporta que o score cai menos de 1% nesses casos, mas é algo pra monitorar.

Sem fine-tuning público: por enquanto, você não pode fazer fine-tune do Ember-1. A Fireworks oferece treinamento enterprise customizado, mas isso exclui a maioria dos desenvolvedores independentes.

Como integrar o Ember-1 no seu pipeline

Se você já usa a API da OpenAI ou qualquer modelo via OpenRouter, migrar pro Ember-1 é trivial. A API segue o padrão OpenAI Chat Completions:

import openai

client = openai.OpenAI(
    base_url="https://api.fireworks.ai/inference/v1",
    api_key="fw_sua_chave_aqui"
)

# Chamada básica
response = client.chat.completions.create(
    model="accounts/fireworks/models/ember-1",
    messages=[
        {
            "role": "system",
            "content": "Você é um assistente de código especializado em Python."
        },
        {
            "role": "user",
            "content": "Implemente um rate limiter com sliding window em Redis."
        }
    ],
    max_tokens=4096,
    temperature=0.7
)

print(response.choices[0].message.content)

# Com function calling (tool use)
tools = [
    {
        "type": "function",
        "function": {
            "name": "buscar_documentacao",
            "description": "Busca na documentação oficial de uma biblioteca",
            "parameters": {
                "type": "object",
                "properties": {
                    "biblioteca": {"type": "string"},
                    "query": {"type": "string"}
                },
                "required": ["biblioteca", "query"]
            }
        }
    }
]

response = client.chat.completions.create(
    model="accounts/fireworks/models/ember-1",
    messages=[{"role": "user", "content": "Como configuro conexão pooling no SQLAlchemy 2.0?"}],
    tools=tools,
    tool_choice="auto"
)

O Ember-1 também está disponível via OpenRouter, o que facilita se você já roda múltiplos modelos por lá:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "fireworks/ember-1",
    "messages": [{"role": "user", "content": "Explique consistent hashing em 3 parágrafos"}]
  }'

Pra quem o Ember-1 faz sentido (e pra quem não faz)

Faz sentido se:

• Você roda pipelines agenticos com dezenas de chamadas por tarefa
• Seu gasto mensal com API de LLM passa de $5.000
• Você precisa de qualidade SWE-bench >90% mas não pode pagar Claude Opus 5
• Latência importa pro seu produto (chat em tempo real, autocomplete de código)
• Você já usa a plataforma Fireworks ou OpenRouter

Não faz sentido se:

• Você precisa de um modelo pra produção de longo prazo (ainda é Research Preview)
• Seu caso de uso principal é escrita criativa ou marketing (Claude continua superior)
• Você precisa de fine-tuning
• Seu volume é baixo o suficiente pra que 40% de economia não faça diferença material

O que vem depois: a série Ember

A Fireworks chamou o Ember-1 de “o primeiro de uma série de modelos especializados”. Isso sugere que mais modelos virão, provavelmente otimizados pra domínios específicos: talvez um Ember focado em código, outro em dados tabulares, outro em conversação.

Se a estratégia funcionar, a Fireworks pode se posicionar como a empresa que não treina os maiores modelos do mundo, mas sim os mais eficientes. Num mercado onde todo mundo briga pra ter o modelo com mais parâmetros, otimizar o raciocínio pode ser o diferencial que realmente importa pro bolso do desenvolvedor.

E se tem uma coisa que dev aprende rápido, é prestar atenção quando alguém mexe no bolso dele.

Fonte de inspiração: Introducing Ember-1 (Fireworks AI Blog)