Menu Pricing of Large Language Models

Each language version is independently generated for its own context, not a direct translation.

Imagine que você é o dono de uma pizzaria futurista chamada "IA". Você não vende apenas pizzas; você vende "inteligência" para resolver problemas.

Alguns clientes querem apenas uma fatia de queijo para o jantar (uma tarefa simples). Outros querem uma pizza gigante, recheada com ingredientes exóticos, para alimentar uma festa inteira (uma tarefa complexa). E alguns querem criar uma receita nova do zero (ajustar a IA).

O grande dilema do artigo é: Como cobrar o preço certo de cada cliente, se você não sabe exatamente o que eles vão fazer com a pizza?

Aqui está a explicação do artigo, traduzida para a vida real:

1. O Problema: O Cliente Escondido

O dono da pizzaria (a empresa de IA, como OpenAI ou Anthropic) sabe que os clientes são diferentes.

O Cliente A usa a IA para escrever e-mails rápidos.
O Cliente B usa a IA para analisar milhares de documentos jurídicos.
O Cliente C usa a IA para programar um jogo inteiro.

O problema é que o dono da pizzaria não pode ver o que o cliente está fazendo. Ele só vê o cliente pedindo "ingredientes" (chamados de tokens). Se o cliente pede 100 ingredientes, será que ele vai fazer 100 pizzas pequenas ou 1 pizza gigante?

Se o dono cobrar um preço fixo por pizza, o cliente que faz 100 pizzas pequenas vai pagar muito pouco. Se cobrar por ingrediente, o cliente que faz 1 pizza gigante pode achar caro demais. É um caos de preços!

2. A Grande Descoberta: O "Índice de Fome"

Os autores do artigo descobriram uma mágica matemática. Eles provaram que, não importa como o cliente usa a inteligência (se é para escrever, desenhar ou codificar), tudo isso pode ser resumido em uma única coisa: o "Índice de Fome" do cliente.

Pense assim:

Um cliente que quer 100 tarefas pequenas tem a mesma "fome total" que um cliente que quer 1 tarefa enorme, desde que a quantidade total de ingredientes seja a mesma.
A tecnologia da IA é tão flexível que, se você der ao cliente um orçamento de ingredientes, ele vai distribuir esses ingredientes da maneira mais eficiente possível, sozinho.

Isso transforma um problema super complexo (milhares de tipos de clientes) em algo simples: vender orçamentos de ingredientes.

3. A Solução: O "Cartão de Crédito de IA"

Em vez de vender "100 fatias de pizza" ou "100 páginas de texto", a empresa ideal deveria vender créditos.

Imagine que a empresa oferece três planos:

Plano Básico: Você paga R$ 20 e ganha 1.000 créditos. Cada "fatia de pizza" (tarefa simples) custa 1 crédito. Cada "pizza gigante" (tarefa complexa) custa 50 créditos.
Plano Pro: Você paga R$ 100 e ganha 6.000 créditos.
Plano Elite: Você paga R$ 200 e ganha 20.000 créditos.

A mágica: O cliente decide como gastar os créditos. Se ele tem muitas tarefas pequenas, ele gasta devagar. Se tem uma tarefa gigante, ele gasta rápido.

Para a empresa: É perfeito. Ela sabe que quem tem mais dinheiro (e mais tarefas) vai comprar o plano maior.
Para o cliente: É justo. Ele só paga pelo que usa, mas ganha um desconto por comprar o pacote grande (como comprar um combo de pizza).

4. Como isso funciona na vida real?

O artigo mostra que as empresas de IA que você conhece já estão fazendo isso, mesmo sem saber a teoria matemática!

Anthropic (Claude): Eles vendem assinaturas onde você tem um limite de mensagens. Se você usa um modelo mais inteligente (que "come" mais ingredientes), suas mensagens acabam mais rápido. É como vender um "pote de ingredientes" onde o tamanho da pizza define o preço.
OpenAI (ChatGPT): Eles fazem algo parecido, mas também bloqueiam os modelos mais potentes apenas para quem paga mais caro. É como ter uma "pizza especial" que só entra no plano mais caro.
GitHub Copilot: Funciona como um "cartão de crédito". Você paga uma mensalidade e tem um limite de "pedidos". Se passar do limite, pode continuar usando, mas paga por uso extra.

5. A Concorrência: O Mercado de Rua

O artigo também fala sobre o que acontece quando existe um "mercado de rua" (modelos de código aberto, gratuitos ou baratos).

Se o dono da pizzaria cobrar muito caro, os clientes vão para o mercado de rua comprar ingredientes baratos.
Para competir, o dono da pizzaria precisa oferecer um "pacote" tão bom que valha a pena pagar mais.
Resultado: Os clientes com "fome" pequena vão para o mercado de rua. Os clientes com "fome" média compram do dono da pizzaria para não ter que ir ao mercado. E os clientes com "fome" gigante (empresas grandes) compram o pacote premium, porque o mercado de rua não tem ingredientes suficientes para eles.

Resumo Final

O artigo diz que não precisamos de preços confusos e cheios de letras miúdas.

A melhor forma de vender Inteligência Artificial é vender orçamentos flexíveis.

Dê ao cliente um "cartão de crédito" de tokens (ingredientes).
Deixe ele gastar como quiser (em tarefas grandes ou pequenas).
Cobrar um preço fixo pelo cartão, com descontos para quem compra cartões maiores.

Isso funciona porque a tecnologia da IA é tão poderosa que o cliente sabe exatamente como usar os ingredientes para fazer o melhor trabalho possível. A empresa só precisa garantir que o cliente tenha ingredientes suficientes e pagar o preço justo pelo tamanho da "fome" dele.

Em uma frase: Não venda "acesso à IA". Venda "ingredientes" e deixe o cliente cozinhar o que ele quiser, cobrando pelo tamanho do prato que ele consegue servir.

Each language version is independently generated for its own context, not a direct translation.

1. O Problema

O artigo aborda o desafio fundamental de precificar o acesso a Modelos de Linguagem de Grande Escala (LLMs). O problema é inerentemente complexo devido a três características principais:

Informação Privada Multidimensional: Os usuários possuem um perfil de tipo contínuo e de alta dimensão, representado por uma função que mapeia o valor de cada tarefa possível (ex: codificação, análise legal, redação) que eles podem realizar.
Espaço de Alocação de Alta Dimensão: O provedor vende orçamentos de "tokens" (entradas, saídas e tokens de fine-tuning). O usuário decide livremente como alocar esses tokens entre suas diversas tarefas.
Problema Combinado de Seleção Adversa e Risco Moral: O provedor pode medir o uso total de tokens, mas não pode observar nem contratar sobre a alocação específica de tokens por tarefa do usuário. Isso cria um risco moral (o usuário pode alocar tokens de forma ineficiente para maximizar sua utilidade) e seleção adversa (o usuário tem informações privadas sobre seus valores).

A priori, esse problema parece intratável devido à dimensionalidade infinita dos tipos e das ações ocultas.

2. Metodologia e Estrutura do Modelo

Os autores desenvolvem um quadro de design de mecanismos ótimo sob a hipótese de uma tecnologia de produção homogênea.

Função de Ganho: A qualidade/performance do modelo em uma tarefa $i$ $i$ é dada por $g(x_i, z) = \Psi(x_i)\Phi(z)$ $g (x_{i}, z) = Ψ (x_{i}) Φ (z)$ , onde $x_i$ $x_{i}$ são tokens de inferência e $z$ $z$ são tokens de fine-tuning.
- $\Psi$ é estritamente côncava e homogênea de grau $\sigma \in (0,1)$ , capturando retornos decrescentes e leis de escala.
- $\Phi$ captura os retornos do fine-tuning.
Redução de Dimensionalidade (O Resultado Central): Devido à homogeneidade da função de produção, a composição ótima de tokens é invariante de escala. Isso permite que o perfil de tipo multidimensional do usuário ( $w$ ) seja resumido em um índice escalar único, chamado de tipo agregado ( $\theta$ ):
$\theta(w) \triangleq \left( \int_0^1 w_i^{\frac{1}{1-\sigma}} di \right)^{1-\sigma}$
Consequência da Agregação: Usuários com o mesmo tipo agregado demandam o mesmo total de recursos e obtêm o mesmo excedente, independentemente da estrutura fina de suas valorações por tarefa. Isso reduz o problema de screening multidimensional do vendedor para um problema de screening unidimensional clássico (estilo Mussa-Rosen, 1978).

3. Principais Resultados Teóricos

A. Alocação Eficiente e Preços Lineares (Seção 3)

Na alocação socialmente eficiente, todos os tarefas usam classes de tokens em proporções comuns.
Sob restrições de capacidade, a alocação eficiente pode ser implementada através de preços lineares iguais aos custos marginais inflacionados pelos custos sombra das restrições. Isso racionaliza a precificação "pay-per-token" observada em APIs de desenvolvedores.

B. Mecanismo Ótimo para Monopólio de Modelo Único (Seção 4)

O mecanismo ótimo assume a forma de contratos de gasto comprometido (committed-spend contracts).
O vendedor oferece um menu de orçamentos monetários. O usuário paga uma taxa fixa para obter um orçamento que pode ser gasto livremente em tokens de diferentes classes, precificados ao custo marginal do provedor.
Implementações Indiretas: O mecanismo direto ótimo pode ser implementado de três formas práticas:
1. Máximo de Gasto (Maximum-Spend): Um teto de gastos (créditos) com preços unitários fixos.
2. Mínimo de Gasto (Minimum-Spend): Compromissos de volume que desbloqueiam descontos marginais.
3. Tarifas de Duas Partes: Taxa fixa + preço por token.
O mecanismo exclui tipos baixos e distorce a qualidade para baixo para a maioria dos tipos (exceto o topo), oferecendo descontos quantitativos (preço médio por token diminui conforme o orçamento aumenta).

C. Múltiplos Modelos e Versionamento (Seção 5.1 e 5.2)

Quando há múltiplos modelos com diferentes retornos ao fine-tuning ( $\hat{\sigma}$ ), o comprador otimiza usando apenas um modelo para todas as suas tarefas.
O monopolista cria um menu de versionamento onde tipos mais altos (maior $\theta$ ) acessam modelos mais capazes (maior $\hat{\sigma}$ ), não apenas maiores orçamentos.
A função de custo torna-se não convexa (com "quinas" nas trocas de modelo), levando a descontinuidades na alocação ótima: usuários na fronteira entre modelos saltam para uma qualidade estritamente superior ao fazer o upgrade.

D. Competição Líder-Fringe (Seção 5.3)

Analisa a competição entre um líder proprietário e uma "franja" de código aberto que vende tokens ao custo marginal.
Surgem três regiões distintas:
1. Tipos Baixos: Compram exclusivamente da franja.
2. Tipos Intermediários: O líder oferece exatamente a quantidade necessária para desencorajar o usuário de complementar com a franja (deterrence region).
3. Tipos Altos: O líder atua como monopolista puro, com distorções padrão.
A competição afeta tanto a margem intensiva (quantidade vendida) quanto a extensiva (quem adota o modelo proprietário).

4. Conexão com a Prática (Seção 6)

Os autores mapeiam seus resultados teóricos para as práticas de precificação observadas em provedores reais (Anthropic, OpenAI, GitHub, Quora):

Anthropic: Implementa o mecanismo de orçamento de tokens (Seção 4). Todos os planos pagos dão acesso aos mesmos modelos; a diferenciação ocorre puramente pelo volume de uso (orçamento computacional).
OpenAI: Implementa o mecanismo de múltiplos modelos (Seção 5). Planos superiores não só dão mais tokens, mas desbloqueiam modelos mais capazes (ex: o1-pro), alinhando-se com a versionamento ótimo.
Model Aggregators (Poe, GitHub Copilot):
- Poe: Implementa um mecanismo de gasto máximo (teto de créditos).
- GitHub Copilot: Implementa um mecanismo de gasto mínimo (compromisso de uso com opção de overage a preço linear).
APIs para Desenvolvedores: Seguem a precificação linear de custo marginal (Seção 3), priorizando a adoção e a eficiência de alocação sob restrições de capacidade, em vez da extração de renda via menus não lineares.

5. Contribuições e Significância

Tratabilidade de Problemas Complexos: O artigo demonstra que, sob homogeneidade tecnológica, problemas de screening com informação multidimensional e risco moral podem ser reduzidos a problemas unidimensionais tratáveis.
Fundamentação Teórica para Práticas Atuais: Oferece a primeira base teórica rigorosa para explicar por que as empresas de IA usam estruturas de preços específicas (orçamentos, tiers de modelos, preços lineares em API), mostrando que elas não são escolhas ad hoc, mas respostas ótimas a forças econômicas fundamentais.
Design de Produto e Precificação: Fornece diretrizes claras para provedores sobre como estruturar menus de produtos (ex: quando separar por modelo vs. por volume) e como lidar com a competição de código aberto.
Implicações de Bem-Estar: A análise revela como a competição e a estrutura de mercado distorcem a alocação de recursos computacionais, identificando regiões onde a eficiência é sacrificada para extrair renda ou deter concorrentes.

Em suma, o paper estabelece que a economia dos LLMs pode ser compreendida através de uma lente de "orçamento agregado", onde a heterogeneidade complexa dos usuários é condensada em um único parâmetro, permitindo mecanismos de precificação simples e implementáveis que espelham o mercado atual.