Otimização de Custos para Sistemas de LLM: Para Onde o Dinheiro Realmente Vai

Gaste tokens onde realmente importam.

Conteúdo da página

Os custos dos LLMs (Modelos de Linguagem de Grande Escala) escalam linearmente com o uso. Um sistema que processa 10.000 solicitações por dia a $0,01 por solicitação custa $100 diariamente — o que totaliza $365 por ano. Em escala empresarial, isso ultrapassa os $10.000.

A otimização de custos não se trata de cortar caminhos. Trata-se de gastar tokens onde eles realmente importam.

Cada token que você desperdiça é um token que poderia ter sido gasto para obter uma resposta melhor.

Estratégias de otimização de custos de LLM

Orçamento de tokens

A maneira mais simples de controlar os custos é estabelecer limites. Por sessão, por tarefa ou por dia.

Estratégia 1: Orçamentos por Sessão

Os orçamentos por sessão são diretos:

class SessionBudget:
    def __init__(self, budget_tokens: int = 10000):
        self.budget = budget_tokens
        self.used = 0

    def allocate(self, tokens: int) -> bool:
        if self.used + tokens <= self.budget:
            self.used += tokens
            return True
        return False

    def remaining(self) -> int:
        return self.budget - self.used

Estratégia 2: Orçamentos por Tarefa

Os orçamentos por tarefa são mais úteis. Diferentes tarefas necessitam de quantidades distintas de contexto:

task_budgets:
  classify:
    max_tokens: 100
    model: qwen3-1.7b
  summarize:
    max_tokens: 500
    model: qwen3-8b
  code_review:
    max_tokens: 2000
    model: qwen2.5-coder-7b
  reason:
    max_tokens: 4000
    model: qwen3-32b

Estratégia 3: Orçamentos Adaptativos

Os orçamentos adaptativos ajustam-se com base no que realmente acontece. Se as tarefas de classificação consistentemente usam 80 tokens, pare de alocar 100:

class AdaptiveBudget:
    def __init__(self):
        self.task_history = {}

    def allocate(self, task_type: str) -> int:
        if task_type in self.task_history:
            return int(self.task_history[task_type] * 1.5)
        return 1000

    def record(self, task_type: str, tokens_used: int):
        if task_type not in self.task_history:
            self.task_history[task_type] = tokens_used
        else:
            self.task_history[task_type] = (
                0.9 * self.task_history[task_type] + 0.1 * tokens_used
            )

A média móvel exponencial (com peso de 0,9) significa que o uso recente tem mais importância do que o histórico. Ajuste o peso com base na volatilidade das suas cargas de trabalho.

API vs inferência local

A inferência local é mais barata em grande escala. O ponto de equilíbrio depende do seu hardware e das taxas da API.

Modelo API (US$/M tokens) Custo local/hora Ponto de equilíbrio
GPT-4o $2,50 / $10,00 — N/A
Claude Sonnet 4 $3,00 / $15,00 — N/A
Qwen2.5-72B $0,50 / $2,00 ~$0,50 ~4 horas/dia
qwen3-32b $0,30 / $1,20 ~$0,20 ~2 horas/dia
qwen3-8b $0,10 / $0,40 ~$0,05 ~1 hora/dia

A matemática do hardware:

Hardware Investimento inicial Eletricidade mensal Ponto de equilíbrio vs API
RTX 3090 (usada) $600 $15 ~4 meses
RTX 4090 $1.500 $20 ~6 meses
RTX 5080 $1.000 $18 ~5 meses
DGX Spark $2.000 $30 ~8 meses

Com um uso moderado — uma hora ou mais por dia — a inferência local se paga sozinha. Com alto uso, as economias são dramáticas. O porém é o capital inicial. Uma RTX 5080 custa $1.000. Uma fatura de API você pode pausar. Hardware, não.

Estratégias de fallback (recuo)

Quando seu modelo preferencial é muito caro ou muito lento, recua para algo mais barato. A chave é saber quando a qualidade é “boa o suficiente”.

Estratégia 1: Fallback Baseado em Qualidade

O fallback baseado em qualidade tenta modelos até que a saída atinja um limite:

class QualityFallback:
    def __init__(self, quality_threshold: float = 0.8):
        self.threshold = quality_threshold
        self.models = [
            {"model": "claude-sonnet-4", "cost": 0.015},
            {"model": "qwen2.5-72b", "cost": 0.002},
            {"model": "qwen3-32b", "cost": 0.001},
            {"model": "qwen3-8b", "cost": 0.0004},
        ]

    def route(self, prompt: str) -> str:
        for model_config in self.models:
            result = self.call_model(model_config["model"], prompt)
            if self.evaluate_quality(result) >= self.threshold:
                return result
        return self.call_model(self.models[0]["model"], prompt)

O problema é a própria avaliação. Como você mede a qualidade sem chamar outro modelo? Alguns sistemas usam um classificador pequeno. Outros usam verificações heurísticas — comprimento, estrutura, presença de palavras-chave. Nenhuma dessas abordagens é perfeita.

Estratégia 2: Fallback Baseado em Latência

O fallback baseado em latência é mais simples. Encaminhe para o modelo mais rápido que atenda ao seu orçamento de tempo:

class LatencyFallback:
    def __init__(self, max_latency: float = 5.0):
        self.max_latency = max_latency
        self.models = [
            {"model": "qwen3-1.7b", "latency": 0.5},
            {"model": "qwen3-8b", "latency": 2.0},
            {"model": "qwen3-32b", "latency": 10.0},
            {"model": "claude-sonnet-4", "latency": 5.0},
        ]

    def route(self, prompt: str) -> str:
        for model_config in sorted(self.models, key=lambda x: x["latency"]):
            if model_config["latency"] <= self.max_latency:
                return self.call_model(model_config["model"], prompt)
        return self.call_model(self.models[0]["model"], prompt)

Armazenamento em cache (Caching)

O cache é a otimização de custos mais subestimada. Prompts idênticos acontecem com mais frequência do que você pensa — solicitações de classificação, consultas estilo FAQ, chamadas de ferramentas repetidas.

Estratégia 1: Cache de Prompts

O cache de prompts exatos é simples:

import hashlib

class PromptCache:
    def __init__(self, max_size: int = 1000):
        self.cache = {}
        self.max_size = max_size

    def get(self, prompt: str) -> str | None:
        key = hashlib.sha256(prompt.encode()).hexdigest()
        return self.cache.get(key)

    def set(self, prompt: str, response: str):
        key = hashlib.sha256(prompt.encode()).hexdigest()
        if len(self.cache) >= self.max_size:
            self.cache.pop(next(iter(self.cache)))
        self.cache[key] = response

Estratégia 2: Cache Semântico

O cache semântico é mais útil. Ele captura prompts que são diferentes, mas significam a mesma coisa:

from sentence_transformers import SentenceTransformer

class SemanticCache:
    def __init__(self, similarity_threshold: float = 0.95):
        self.model = SentenceTransformer('all-MiniLM-L6-v2')
        self.cache = {}
        self.threshold = similarity_threshold

    def get(self, prompt: str) -> str | None:
        prompt_embedding = self.model.encode([prompt])[0]
        for cached_prompt, cached_response in self.cache.items():
            cached_embedding = self.model.encode([cached_prompt])[0]
            similarity = self.cosine_similarity(
                prompt_embedding, cached_embedding
            )
            if similarity >= self.threshold:
                return cached_response
        return None

    def set(self, prompt: str, response: str):
        self.cache[prompt] = response

O limite (threshold) importa. 0,95 é agressivo — apenas prompts muito semelhantes correspondem. 0,85 é mais tolerante, mas corre o risco de retornar respostas erradas. Meça sua taxa de falha (miss rate) e ajuste.

O cache de respostas para consultas comuns também vale a pena. Se os usuários perguntarem repetidamente “qual é o clima” ou “que horas são”, armazene em cache o padrão, não apenas o prompt exato:

class ResponseCache:
    def __init__(self):
        self.common_queries = {
            "what is the weather": "Check weather API",
            "what is the time": "Check system time",
            "who is the president": "Check current president",
        }

    def get(self, query: str) -> str | None:
        query_lower = query.lower()
        for common_query, response in self.common_queries.items():
            if common_query in query_lower:
                return response
        return None

Isso não é sofisticado, mas funciona. Consultas comuns são comuns por um motivo.

Quando a otimização ajuda

A otimização importa quando você está processando altos volumes, executando cargas de trabalho mistas ou pagando custos de API que se acumulam.

Não importa quando você está prototipando, usando um único modelo ou processando baixos volumes. A complexidade do orçamento, fallback e cache não vale a pena para um sistema que faz 100 solicitações por dia.

Primeiro, faça o fluxo básico funcionar. Adicione otimização quando a conta chegar.

Compromissos (Tradeoffs)

Estratégia Custo Qualidade Complexidade
Sem otimização Mais alto Consistente Mais baixa
Orçamento de tokens Moderado Variável Média
Modelos de fallback Baixo-Médio Variável Média
Cache Mais baixo Alta (para acertos de cache) Média
Híbrido Otimizado Otimizado Mais alta

Sistemas de produção geralmente utilizam uma abordagem híbrida. Defina orçamento por sessão, faça fallback com base na qualidade ou latência e armazene em cache o que puder. A complexidade é real, mas as economias também.

Relacionados

Assinar

Receba novos artigos sobre sistemas, infraestrutura e engenharia de IA.