NCM (Next Concept Model) até 31x mais rápido: e o seu agente de IA com ERP?

Modelo mais rápido sai toda semana, e para quem tem agente de IA em produção a pergunta é sempre a mesma: se o modelo gera texto 20 vezes mais rápido, o agente fica quanto mais rápido?

Fiz a conta com o NCM, de Stanford, que gera texto até 31 vezes mais rápido, num agente que lê o e-mail de pedido, consulta o ERP e lança o pedido em 40 segundos. O resultado fica longe de 31 vezes.

O vídeo de mesmo nome mostra as contas com animações.

01. O que é o NCM e onde ele está hoje

O NCM (Next-Concept Modeling) é um trabalho da Hazy Research, de Stanford, com a Together AI, publicado em 12 de outubro de 2026 (arXiv 2610.14162). Nas redes, virou Next Concept Model.

O modelo que você chama por API gera um token por vez, e cada token espera o anterior, então uma frase de 15 tokens leva 15 passos. O NCM escreve em níveis, do rascunho grosso ao detalhe, e todos os pedaços de um nível saem juntos.

O paper mediu de 10 a 31 vezes mais velocidade numa H100, contra modelos de difusão do mesmo tamanho. Não houve comparação com os modelos que você usa por API.

Em novembro de 2026, o NCM continua sendo pesquisa: modelos de 97 a 725 milhões de parâmetros, um checkpoint por tarefa, código com licença MIT em github.com/HazyResearch/ncm e nenhuma API ou servidor de inferência para produção. Só que a pergunta já vale hoje: trocar o modelo de um agente que usa API é mudar uma linha de configuração.

02. O cenário: o agente de pedidos por e-mail

As contas usam um cenário fictício, com empresas e pessoas criadas para o exemplo. O Vértice é um ERP para distribuidoras, com 7 devs, que roda no servidor de cada cliente. A Distribuidora Alvorada, cliente do Vértice, tem 60 usuários no faturamento e recebe boa parte dos pedidos por e-mail.

No sábado, 7 de novembro, a Renata Lima, do Supermercado Bom Lar, manda o e-mail “Pedido semana 46” com um PDF de 12 itens. O agente do Vértice faz nove passos para lançar o pedido, três deles com o modelo:

1. busca o e-mail e o anexo;
2. extrai o pedido do PDF, com o modelo;
3. consulta o cadastro do cliente no ERP;
4. consulta o estoque de cada um dos 12 itens no ERP;
5. decide a substituição dos itens sem estoque, com o modelo;
6. consulta o crédito do cliente no ERP;
7. grava o pedido no ERP;
8. redige a resposta, com o modelo;
9. envia a confirmação para quem mandou o pedido.

Dois itens estão sem estoque, o modelo escolhe os substitutos, e o pedido 73.118 sai com 12 itens e R$ 14.326,40.

03. Onde vão os 40 segundos

O modelo ocupa 6 dos 40 segundos do pedido. O resto é operação de I/O, e o maior pedaço é o estoque: 12 consultas de 1,25 segundo em sequência, 15 segundos no total.

Essa barra é o que um trace do OpenTelemetry mostra, com um span por passo. Sem ela, a troca de modelo é decidida no chute.

04. A lei de Amdahl e o modelo 20x mais rápido

A lei de Amdahl, de 1967, dá o limite de acelerar só uma parte de um processo:

O ganho máximo de trocar o modelo é a fatia de tempo dele, 15% neste agente. Com o modelo 20 vezes mais rápido, os 6 segundos viram 0,3 e o pedido cai para 34,3 segundos. Com 31 vezes, vai a 34,2, e um modelo instantâneo pararia em 34.

05. O que ganha mais que o modelo novo

Rodar as 12 consultas de estoque 4 por vez tira 28%, o dobro do modelo 20x. Nenhuma consulta depende da outra, então são 3 rodadas de 1,25 segundo: o estoque cai de 15 para 3,75 segundos, e o pedido, para 28,75.

As duas mudanças somam: com o estoque em paralelo e o modelo 20x, o pedido leva 23,05 segundos, 42% a menos.

O recurso para paralelizar com limite já existe em cada linguagem:

Se o ERP tiver consulta de estoque em lote, as 12 chamadas viram uma. Ah, e o limite de 4 por vez tem motivo: é a conta da próxima seção.

06. O limite do ERP no servidor do cliente

A API do ERP aceita 8 chamadas por segundo, e isso limita o agente a 1.920 pedidos por hora. O Vértice roda no mesmo servidor que atende os 60 usuários do faturamento da Alvorada, e o limite foi pedido do cliente para a tela deles não travar.

Com 15 chamadas por pedido, são 8 ÷ 15 = 0,53 pedido por segundo, com qualquer modelo.

07. Segunda às 8h com 1.200 e-mails

Quanto mais curto o pedido, mais chamadas por segundo chegam ao ERP. Na segunda, 9 de novembro, às 8h, a caixa tem 1.200 e-mails e o agente processa 20 pedidos ao mesmo tempo. A carga é pedidos ao mesmo tempo × chamadas por pedido ÷ duração do pedido.

No fluxo original, a carga fica em 7,5 chamadas por segundo. Com o estoque em paralelo, sobe para 10,4, e com o modelo 20x junto, para 13. Acima de 8, o ERP responde 429.

O estudo de Choi et al. (arXiv 2609.19947), de setembro de 2026, viu o mesmo efeito dentro da máquina: com o modelo mais rápido, as ferramentas do agente disputam mais a CPU.

A conta ao contrário dá quantos pedidos cabem no limite (limite × duração ÷ chamadas por pedido):

Mesmo no limite, os 1.200 e-mails levam pelo menos 37,5 minutos. A otimização precisa de duas regras: limitar os pedidos ao mesmo tempo pelo limite do ERP e respeitar o cabeçalho Retry-After do 429.

08. A gravação que estoura o timeout

Com 3% de timeout na gravação, a segunda termina com 22 pedidos duplicados, e a velocidade do modelo não muda esse número. Gravar no Vértice leva 9 segundos, o cliente HTTP desiste em 10, e na segunda de manhã 36 gravações passam desse limite.

O agente tem um try/catch em volta do fluxo inteiro e recomeça do zero, o que gera 108 chamadas extras ao modelo. Em 22 dos 36 casos, o ERP já tinha gravado o primeiro pedido.

Três regras resolvem, e nenhuma depende do modelo.

1. Repetir só o passo que falhou

O retry fica no ponto da chamada: p-retry no Node, Polly no .NET, resilience4j no Java, tenacity no Python.

2. Guardar o resultado de cada passo

O agente retoma do último passo concluído, sem chamar o modelo de novo.

3. Referência externa na gravação

O pedido vai com o Message-ID do e-mail, <20261107164233.5512@bomlar.example>, como referência, e o agente consulta essa referência antes de gravar. Se o pedido existe, devolve o número. Se o ERP não tem esse campo, uma tabela de efeitos aplicados no seu banco faz o mesmo papel.

09. Quando o modelo rápido faz diferença, e como medir

Em agente de código, de raciocínio longo ou com poucas ferramentas, o modelo ocupa quase todo o tempo, e um modelo mais rápido faz diferença. Raj et al. (arXiv 2511.00739, abril de 2026) mediram os dois extremos: ferramentas com mais de 80% do tempo em agentes de RAG e de química, e o modelo com 77% a 88% no Toolformer.

No seu agente, a resposta sai de um span por passo e de quatro números, depois de uma semana de produção:

10. O agente numa execução durável

Aqui entra o skail, e já aviso: eu faço parte da skail, então leia com esse filtro. O skail é uma plataforma de execução durável: o processo vira uma função escrita de cima para baixo, e a plataforma guarda o estado e retoma de onde parou quando algo falha.

A function orquestra os passos. Cada operação de I/O e cada chamada ao modelo vira um command, com o resultado gravado no histórico, e um command concluído não roda de novo na retomada (Functions e commands).

import { Skail, SkailCommand, SkailFunction } from "@skail/runtime";

export class PedidosEmail {
  @SkailFunction()
  async ProcessarPedidoEmail(emailId: string): Promise<string> {
    const email = await this.BuscarEmail(emailId);
    const pedido = await this.ExtrairPedido(emailId);
    const cliente = await this.ConsultarCliente(pedido.cnpj);

    // estoque em lotes de 4: os commands começam juntos e o whenAll espera os 4
    const saldos: Saldo[] = [];
    for (let i = 0; i < pedido.itens.length; i += 4) {
      const lote = pedido.itens.slice(i, i + 4);
      const consultas = lote.map((item) => this.ConsultarEstoque(item.sku));
      saldos.push(...(await Skail.whenAll(consultas)));
    }

    const ajustado = await this.DecidirSubstituicao(pedido, saldos);
    const credito = await this.ConsultarCredito(cliente.id, ajustado.total);
    const numero = await this.GravarPedido(email.messageId, ajustado, credito.aprovado);
    const resposta = await this.RedigirResposta(ajustado, numero);
    await this.EnviarResposta(email.remetente, resposta);
    return numero;
  }

  @SkailCommand({ retryCount: 8 })
  async GravarPedido(
    messageId: string, pedido: PedidoAjustado, creditoAprovado: boolean
  ): Promise<string> {
    // regra da duplicidade: consulta pela referência do e-mail antes de gravar
    const existente = await this.erp.buscarPedidoPorReferencia(messageId);
    if (existente) return existente.numero;

    const criado = await this.erp.criarPedido(pedido, creditoAprovado, {
      referenciaExterna: messageId,
    });
    return criado.numero;
  }
}

• Estoque em lotes de 4. Os commands são chamados sem await, e o Skail.whenAll espera os 4 e devolve os resultados na ordem da lista (Rodar em paralelo e juntar).
• Gravação sem duplicar. O GravarPedido consulta pela referência antes de gravar, que é o caso 3 de Escrever commands idempotentes, e usa retryCount: 8 porque repetir é seguro.
• Rede e relógio nos commands. Dentro da function, fetch() e Date.now() lançam erro, e o paralelo usa Skail.whenAll no lugar de Promise.all (SDKs e linguagens).

  @SkailCommand()
  async BuscarEmail(emailId: string): Promise<EmailInfo> {
    return await this.caixa.buscar(emailId);
  }

  @SkailCommand()
  async ExtrairPedido(emailId: string): Promise<PedidoExtraido> {
    return await this.modelo.extrairPedido(await this.caixa.anexo(emailId));
  }

  @SkailCommand({ retryCount: 8 })
  async ConsultarEstoque(sku: string): Promise<Saldo> {
    return await this.erp.saldo(sku);
  }

  // ConsultarCliente e ConsultarCredito seguem o ConsultarEstoque;
  // DecidirSubstituicao e RedigirResposta seguem o ExtrairPedido

  @SkailCommand()
  async EnviarResposta(para: string, texto: string): Promise<void> {
    await this.smtp.enviar(para, texto);
  }

Eu completei o corpo dos commands no estilo da doc. Os clientes caixa, erp, modelo e smtp são classes da aplicação.

O Vértice dispara uma execução por e-mail com POST /api/v1/trigger/pedidos-email/v1.0.0/ProcessarPedidoEmail/{id}, usando o id do e-mail, que é um GUID, como id da execução (Disparar uma função pela API). Não sobra fila, job nem tabela de controle para lembrar em que passo cada pedido está.

A segunda-feira no Monitor

Às 8h, o Vértice dispara 1.200 execuções. Cada instância da aplicação trata um número limitado de execuções por vez, e o resto fica Na fila (Limites e cotas). O time ajusta as réplicas até a carga no ERP chegar perto de 8 chamadas por segundo.

No Monitor, a execução da Renata sai da fila às 08:14:05, e a linha do tempo mostra a mesma barra da seção 3, sem instrumentação, com o estoque em 3 lotes de 4.

O GravarPedido estoura os 10 segundos na primeira tentativa. Na segunda, a consulta pela referência acha o 73.118, gravado depois do timeout, e devolve o número sem gravar de novo. Os passos anteriores voltam do histórico, sem chamar o modelo.

11. Tabela de decisão

O que atacar primeiro, de acordo com o que a medição mostrar:

PRÓXIMO PASSO

Por onde começar

O primeiro passo é medir: instrumente o agente, rode uma semana e calcule os quatro números da seção 9.

Se quiser levar o agente para execução durável, a doc do skail tem o caso de uso Agente de IA com ferramentas e o guia Migrar código existente, que tira jobs, fila e tabela de controle sem reescrever o sistema.

As contas com animações e a execução no Monitor estão no vídeo do NCM.