Executando verificação de segurança...
5

Custo alto com IA: problema de modelo ou de implementação?

Atualmente trabalho focado em IA e, mais recentemente, tenho atuado bastante na otimização de fluxos já em produção, principalmente em redução de custo e confiabilidade das respostas.

Uma coisa tem se repetido com frequência:
👉 o custo alto com IA muitas vezes não vem do modelo, mas de implementações mal estruturadas.

Vejo muito código que “funciona”, entrega a resposta correta, passa em tipagem… mas que, por baixo, está desperdiçando tokens sem necessidade. Em vários casos, coisa de 30%+.

E muita discussão sobre custo de IA ainda gira quase exclusivamente em trocar de modelo ou “usar um mais barato”. O problema é que, quando a implementação já nasce inflada/errada, tanto faz o modelo: o desperdício continua.

São padrões que parecem OK à primeira vista, mas escondem falhas. No fim, não é um problema de IA “cara”, é integração mal feita.

Um exemplo real (caso de produção, simplificado e anonimizado)

import { z } from "zod";
import { openai } from "./lib/ai";
import { zodResponseFormat } from "openai/helpers/zod";

const ALL_CATEGORY_CATALOG = [
  {
    slug: "electronics",
    description: "Gadgets e produtos de tecnologia avançada, incluindo smartphones, notebooks, e dispositivos smart home."
  },
  {
    slug: "home_garden",
    description: "Itens para decoração de casa, jardinagem, ferramentas de reparo e vida ao ar livre."
  },
  {
    slug: "fashion",
    description: "Vestuário, calçados e acessórios de moda."
  },
  // + 47 categorias
];

export async function classifyProduct(productName, storeContext) {
  const contextBloat = `
    Store Niche: ${storeContext.niche}
    Active Integrations: ${storeContext.integrations.join(", ")}
    Marketing Tags: ${storeContext.tags.join(", ")}
  `;

  const response = await openai.chat.completions.create({
    model: "gpt-4o",
    messages: [
      {
        role: "system",
        content: `
You are an e-commerce classification assistant.

ALLOWED CATEGORIES:
${ALL_CATEGORY_CATALOG
  .map(c => `slug: ${c.slug}, description: ${c.description}`)
  .join("\n")}

ADDITIONAL CONTEXT:
${contextBloat}

RULES:
- Return valid JSON
- Use only the categories above
        `
      },
      {
        role: "user",
        content: `Product name: ${productName}`
      }
    ],
    response_format: zodResponseFormat(
      z.object({
        categories: z.array(z.enum(
          ALL_CATEGORY_CATALOG.map(c => c.slug)
        ))
      }),
      "classification"
    )
  });

  return response.choices[0].message.parsed;
}

Esse código:

  • ✅ funciona
  • ✅ passa tipagem
  • ✅ gera resposta correta

Mas financeiramente é um vazamento constante.

Pergunta pra vocês 👇

Olhando só para o código acima, onde você enxerga desperdício de tokens ou decisões questionáveis do ponto de vista de custo?

Sem pensar em troca de modelo ou infraestrutura, só na implementação.
(Tem mais de um problema relevante aí.)

Por que estou perguntando isso?

Pra lidar com isso no dia a dia, acabei criando automações internas que analisam implementações de IA em busca de padrões recorrentes de erro.

O ponto principal aqui não é "refatorar tudo". Às vezes faz sentido ajustar parte da implementação, sim, mas na grande maioria dos casos existem quick wins bem claros. Coisas simples de corrigir, que não mudam o comportamento do sistema, mas já reduzem bastante o custo (+30% em vários casos).

A pergunta agora é mais simples:
👉 Isso é um problema real pra mais alguém aqui?
👉 Vocês já fazem esse tipo de otimização manualmente?
👉 Faria sentido liberar algo assim pra uso?

A ideia aqui não é vender nada agora, é entender se isso realmente seria útil pra mais gente.

Curioso pra ouvir experiências reais, especialmente de quem já tomou o susto da fatura no fim do mês 😅

Carregando publicação patrocinada...
7

Analisando o seu código, identifiquei três grandes ralos de dinheiro que explicam facilmente esses 30% (ou mais) de desperdício:

O Ralo do Contexto Irrelevante (Token Bloat) o objeto contextBloat é o culpado clássico.

Você está enviando Active Integrations e Marketing Tags para uma tarefa de classificação de produto.

Se uma loja tem 50 tags e 10 integrações, você está pagando por esses tokens em cada chamada, mesmo que eles não ajudem o modelo a decidir se uma "Camiseta" é fashion ou electronics.

Em escala, você paga milhares de dólares para o GPT-4o "ler" dados que ele vai descartar.

Catálogo Estático no System Prompt

Você está passando a lista completa de 50 categorias (slug + descrição longa) em todas as requisições.

Se o produto é "iPhone 15", o modelo não precisa ler a descrição de home_garden.

A solução de custo: Um passo prévio de busca vetorial (RAG) ou uma filtragem simples por palavras-chave poderia reduzir o catálogo enviado de 50 para as 5 mais prováveis.

Duplicação de Tokens no Schema (Zod + Prompt)

Aqui está um desperdício técnico sutil, mas pesado:

Você lista os slugs e descrições no system.content e depois repete todos os slugs no z.enum do response_format.

O zodResponseFormat converte o esquema Zod em um JSON Schema que é enviado na requisição. Você está enviando a lista de categorias duas vezes na mesma chamada.

Refatoração:
Com Structured Outputs, muitas vezes você pode remover a lista exaustiva do prompt e deixar apenas no schema, ou vice-versa, dependendo de como o modelo precisa da descrição para decidir.

Respondendo às suas perguntas:

Isso é um problema real para mais gente?
Sim, é um problema silencioso. A maioria das empresas só percebe quando a fatura bate os 5k ~ 10k/mês. Até lá, tratam como "custo de inovação".

Vocês já fazem esse tipo de otimização manualmente?
Sim, mas é um processo artesanal e chato.

Faria sentido liberar algo assim para uso?
Com certeza. Uma ferramenta que atue como um "Linter de Custos para LLM" teria muito valor.

3
2

Confesso que não identifiquei o desperdício.

Seria nao ter a necessidade de informar a descrição, considerando que o modelo consegue inferir?

Ou repetir o termo SLUG e DESCRIPTION para cada categoria?

Ou passar contexto nao relacionado com a tarefa (integrações e tags de marketing)?

2

pelo que entendi, está "socando conteudo no contexto" então está entrando muitos tokens para a inferencia da llm. O comentário +47 categorias assustou um pouco.

Eu particularmente não entregaria algo que é possivel implementar de forma determinística para um llm que é probabilístico com um custo computacional, financeiro, energético e ecológico altissimo.

Mas se tratando de um chatbot para consultar e interagir com usuário final fazendo questões relacionadas ao e-commerce, usaria uma LLM que tenha tools disponível, e um serviço MCP responderia algo mais preciso sem sujar muito o contexto, economizando muitos tokens de entrada, e talvez já fazendo essa classificação de forma determinística.

Outra abordagem é usar um vLLM ou serviço de LLM em cloud rodando uma versão opensource.

Inclusive tem o llm gpt-oss, que é "equivalente" a versão gpt-4o, podendo rodar na sua própria infraestrutura (se tiver gpu com 16gb ou 80gb de vram), ou em algum serviço cloud de llm da china.

3

Você sabe quanto custa uma Nvidia A100 80gb de VRAM? R$ 179.219,99 no boleto com desconto. Ou 1K/m USD no gpu-mart para um servidor com somente uma placa. Considerar também o custo da infraestrutura para a compra da placa.
Então tem que fazer muito bem a conta para definir o preço final para o cliente em relação ao volume de transações token.

2

Pois é... Por isso comentei alternativas, inclusive de nao usar llm para fazer esse tipo de classificação. Também falei da opção de usar um cloud chines com sua llm de preferência. Só nao citei o "Airbnb de máquina" vast.ai que também pode ser uma opção.