A IA empresarial está enfrentando um paradoxo de ROI. Embora lançar mais computação no modelo de base mais forte funcione bem em experimentos de produtos, os custos se tornam insuportáveis ​​quando o produto é implantado na produção.

Um novo artigo de pesquisadores do Writer fornece uma solução acessível às equipes de engenharia. O estudo analisa sistematicamente a otimização dos diferentes componentes da camada de orquestração que envolve o modelo básico, também conhecido como equipamento de IA.

Ao otimizar o aproveitamento, os pesquisadores mostram reduções drásticas nos tokens por tarefa, uma queda no custo por tarefa bem-sucedida em até 61% e uma qualidade que se mantém estável, tudo sem alterar o modelo básico subjacente.

Como o aproveitamento está totalmente sob o controle do desenvolvedor e não requer nenhum ajuste fino do modelo, as equipes de engenharia podem aplicar essas descobertas para construir aplicativos de IA altamente econômicos.

A crise do ROI do tokenmaxxing

O estado atual da engenharia de IA é atormentado por "tokenmaxxing," uma tendência do setor em que os desenvolvedores contam com enormes janelas de contexto e consumo de tokens de força bruta como substitutos para um bom design de sistema.

Em vez de criar fluxos de trabalho elegantes, os desenvolvedores importaram um reflexo do desenvolvimento de software tradicional: gerar, executar, falhar, colocar o erro e mais contexto de volta na janela e tentar novamente.

"Equipes tokenmaxx porque é a solução mais barata no momento e porque é literalmente como a maioria dos engenheiros trabalha hoje," Waseem AlShikh, CTO e cofundador da Writer, disse ao VentureBeat. Como essa abordagem é bem-sucedida com bastante frequência em tarefas de codificação, ela se tornou o reflexo padrão para todas as outras cargas de trabalho de agente. O perigo é que as quedas nos preços por token mascarem a ineficiência subjacente.

"Sua fatura é de tokens por tarefa vezes preço por token, e a maioria das equipes assiste apenas ao segundo número," AlShikh disse. "Nas cargas de trabalho de agente, os tokens por tarefa são compostos – cada iteração do loop retransmite o contexto crescente – e aumentam mais rapidamente do que a queda dos preços. A redução de preços torna-se um anestésico. Isso mascara o fato de que a própria alça está sangrando."

Tokenmaxxing leva a vários modos de falha empresarial. As equipes encaminham tarefas simples para modelos de fronteira premium por padrão. Eles usam o LLM como um índice de pesquisa lenta, enchendo a janela de contexto com documentos brutos em vez de recuperar respostas exatas. Mais destrutivamente, eles constroem loops de agente irrestritos que ficam fora de controle quando o modelo encontra um erro. Como os tokens de saída custam significativamente mais do que os tokens de entrada em todos os principais fornecedores de modelos, a execução ineficiente de tarefas atua como um assassino silencioso do orçamento.

A indústria introduziu diversas técnicas de eficiência para reduzir estes custos, mas elas ficam aquém porque tratam o modelo isoladamente:

• Compactação imediata condensa o texto de entrada para economizar espaço, mas ignora como o sistema sequencia essas entradas em fluxos de trabalho complexos.

• Raciocínio orçamentado limita as etapas computacionais que um modelo pode realizar, o que geralmente degrada a qualidade da saída se o fluxo de trabalho não for roteado de forma inteligente.

• Codificação concisa força os modelos a gerar código mínimo para salvar tokens de saída, mas não faz nada para resolver chamadas de ferramentas ineficientes.

• Decodificação especulativa usa um modelo de rascunho menor para acelerar a geração de texto de um modelo maior, otimizando a velocidade de inferência e ao mesmo tempo não abordando arquiteturas de agentes inchadas.

Esses esforços falham porque otimizam o motor ignorando a transmissão. Eles não olham para a camada de orquestração, deixando as ineficiências arquitetônicas subjacentes sem solução.

Desembalar o arnês: as alavancas da eficiência

O chicote é a camada de orquestração que roteia, formata e transforma o LLM subjacente em um sistema funcional.

As principais alavancas da otimização do chicote incluem cache de prompt do sistema, compactação do histórico de interação, gerenciamento de ferramentas, estratégias de recuperação e gerenciamento de erros. Estes são os pontos de intervenção mais acessíveis para equipes de engenharia que buscam melhorar o desempenho da IA.

Como observam os pesquisadores do Writer no estudo: “Se o arnês é a camada que compõe as chamadas do modelo para o trabalho, é também a camada que define o preço do trabalho”.

Historicamente, os desenvolvedores têm tratado o chicote como um código descartável projetado simplesmente para conectar uma API a uma interface de usuário. O estudo sinaliza que o chicote deve agora ser tratado como um objeto de primeira classe: um artefato de software primário que requer seus próprios testes, controle de versão e design rigoroso.

Para as empresas, isto reformula o "próprio versus aluguel" decisão.

"As empresas passam meses avaliando modelos e depois alugam sua orquestração imediatamente – o que significa que estão otimizando a alavanca menor e terceirizando a maior." AlShikh disse. "Quem possui o chicote é dono da economia da sua unidade, e uma estrutura aberta ajustada para demonstrações não está ajustada para sua fatura."

Dentro dos experimentos

Para isolar o impacto da camada de orquestração, os pesquisadores realizaram experimentos em seis modelos básicos abrangendo vários fornecedores e classes de peso: Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1 e o modelo do próprio Writer, Palmyra X6.

Seus experimentos compararam um loop de agente de produção convencional congelado com o Writer Agent Harness finalizado nas mesmas 22 tarefas corporativas bloqueadas, abrangendo recursos como aterramento e recuperação, fluxos de trabalho de várias etapas, uso de ferramentas e geração de conteúdo. Ao manter os modelos e tarefas constantes, eles poderiam isolar os efeitos da própria camada de orquestração.

O aproveitamento otimizado gerou uma queda significativa nos custos, reduzindo o custo combinado por tarefa em 41%, de 21 centavos para 12 centavos. Isto foi conseguido em grande parte através da redução do consumo de tokens, com o número de tokens por tarefa caindo 38%, de 14,2 mil para 8,8 mil.

O equipamento foi projetado para delegar tarefas como pesquisa a subagentes especializados. Um subagente recebe apenas a ferramenta e a consulta específica necessária, recupera os dados exatos e retorna um resumo limpo e limitado ao agente principal, evitando que a janela de contexto principal seja preenchida com resultados brutos de pesquisa.

As taxas de sucesso das tarefas permaneceram estáveis ​​mesmo com a queda no uso de tokens – passando de 78% para 81%, um ganho que os pesquisadores descrevem como direcional em vez de estatisticamente significativo no tamanho da amostra, o que significa que a qualidade não foi prejudicada mesmo com a queda dos custos.

A latência de tarefas de ponta a ponta também caiu significativamente, reduzindo o tempo médio do relógio em 44%, de 48 segundos para 27 segundos, devido ao cache imediato e à eliminação de loops de raciocínio sem saída.

No entanto, os pesquisadores também encontraram limites para a orquestração multiagente. Modelos menores, como Gemini Flash 3.5 e Qwen 3.6, obtiveram pontuação bem abaixo do limite de confiabilidade utilizável em tarefas de delegação de subagentes (0,45 e 0,42, respectivamente) — a capacidade simplesmente ainda não é confiável em modelos mais leves.

A orquestração de subagentes apenas cruzou um limite de confiabilidade utilizável nos dois modelos mais fortes testados: Palmyra X6 do próprio escritor (0,86) e Claude Sonnet 4,6 (0,85).

O manual do desenvolvedor: conclusões e compensações acionáveis

As descobertas do estudo se traduzem em um manual para desenvolvedores corporativos que criam fluxos de trabalho de agentes em grande escala. O primeiro passo é implementar o que AlShikh chama de "Alerta de duas zonas" e "Descarregamento de Contexto."

Estrutura para cache de prompt do sistema (prompt de duas zonas): APIs LLM modernas oferecem cache imediato, mas os desenvolvedores devem estruturar suas cargas corretamente para acioná-lo. Os desenvolvedores devem separar o "zona estável" do "zona volátil." Coloque elementos estáticos e imutáveis ​​(por exemplo, regras básicas, grandes esquemas de ferramentas e procedimentos operacionais padrão) no topo do prompt. Elementos dinâmicos, como a consulta específica do usuário ou o estado recente da tarefa de conversação, devem ser anexados na parte inferior. Essa ordenação permite que o chicote reutilize o prefixo armazenado em cache em centenas de chamadas. "Essa separação única faz com que o cache imediato realmente funcione e impede que você pague novamente pelas mesmas instruções em cada uma das trinta etapas de um agente," AlShikh disse.

Gerencie o contexto com o descarregamento de contexto: Evite o preenchimento de contexto, onde cada volta de um loop é anexada a um prompt monolítico até que a janela atinja o limite máximo. Em vez disso, mova o histórico e os artefatos intermediários para fora da janela, para o armazenamento recuperável, e recupere apenas o que a etapa atual precisa. Se possível, delegue tarefas a subagentes de propósito único para evitar excesso de contexto. Como aponta AlShikh, "o maior item de linha nos gastos do agente não é o raciocínio – é o reenvio de coisas que o modelo já viu."

Crie ciclos resilientes e redefina KPIs: Loops de agentes não gerenciados esgotam rapidamente os orçamentos de API. As equipes devem começar a rastrear tokens de conclusões por milhão (CPM) para entender seus verdadeiros custos de tarefa, mas o equipamento em si deve conter proteções físicas. "O princípio fundamental é que você nunca peça ao modelo para policiar seus próprios gastos," AlShikh disse. "A cerca deve ficar abaixo do modelo, no código, do seu lado da API." Isso requer três verificações rigorosas:

• Orçamentos rígidos de tokens por tarefa: A execução termina quando o orçamento é gasto, sem exceções.

• Cerca de geração: Limites de etapas, chamadas de ferramentas e profundidade de recursão para interromper agentes não convergentes.

• Governança de gastos insucessos: Limite o que uma execução pode gastar após sua primeira validação com falha, para que uma tarefa com falha não se torne sua tarefa mais cara.

Evite complexidade desnecessária: A otimização da camada de orquestração acarreta sobrecarga de engenharia. Se você estiver no estágio de prototipagem e exploração, essa sobrecarga não se justifica – itere rapidamente com um modelo forte e um equipamento leve. Depois que você escalar para milhões de solicitações por dia, a economia com a otimização do aproveitamento se tornará substancial.

Contudo, as equipes devem estar atentas "aproveitar a alavancagem." Adicionar andaimes estruturais exige que o modelo mantenha e obedeça a esse contexto. Se um modelo for muito pequeno, ele gastará sua capacidade limitada analisando o andaime em vez de realizar a tarefa, fazendo com que a precisão caia e os tokens aumentem. A regra para adicionar recursos de orquestração complexos é estritamente matemática: "Se um recurso adicionar mais tokens de coordenação do que remover tokens de tarefa para esse modelo específico, corte-o," AlShikh disse. "Nada no arnês é de graça."

O futuro do aproveitamento empresarial

A era do tokenmaxxing e do tratamento de janelas de contexto como baldes sem fundo está chegando ao fim. Acrescentar mais computação a sistemas mal concebidos não é uma estratégia viável para empresas que necessitam de demonstrar retorno dos seus investimentos em IA.

À medida que os modelos básicos evoluem para absorver nativamente o planejamento, a seleção de ferramentas e o raciocínio em várias etapas em seus pesos, o papel do equipamento mudará de compensar a fraqueza do modelo para impor a política empresarial.

"O que nunca entra no modelo é o “permitido”: orçamentos, permissões, limites de dados, trilhas de auditoria, interruptores determinísticos," AlShikh disse. "Daqui a cinco anos, o arnês será mais fino, mas mais importante. Haverá menos andaimes e mais governação. Por mais capaz que o modelo se torne, alguém externo a ele ainda precisa definir o que ele pode gastar, ver e tocar. Essa camada pertence à empresa e nunca deve ser alugada."

Fonte ==> Cyberseo