Aprenda
O glossário da infraestrutura de IA
Definições claras e técnicas dos conceitos por trás do custo da infraestrutura de IA — e o que cada um significa para a sua conta, a sua escolha de GPU e a sua arquitetura.
Comece por aqui
LLM e APIs 11
API de batchUm modo assíncrono oferecido pela maioria dos provedores de LLM: você envia um arquivo de requisições, recebe os resultados dentro de um prazo (normalmente 24 h) e paga cerca de 50% do preço por token normal.Preço misto de tokenUm número único por milhão de tokens que combina os preços de entrada e saída a uma proporção assumida, para ordenar os modelos numa única coluna. O Obolith pondera a entrada 3× em relação à saída.Preço de entrada em cacheUm desconto sobre os tokens de entrada que se repetem entre chamadas — um prompt de sistema estável, exemplos few-shot, um documento longo. O prefixo em cache é cobrado a cerca de 10-25% da tarifa de entrada normal.Janela de contextoO número máximo de tokens que um modelo consegue considerar de uma vez — prompt e resposta somados. Os tamanhos comuns vão de 8K a mais de 1M de tokens.Custo por milhão de tokensA unidade padrão para o preço das APIs de LLM. Indicada separadamente para entrada e saída, em USD por 1.000.000 de tokens.EmbeddingUma lista de números (um vetor) que representa o significado de um trecho de texto, de modo que significados parecidos fiquem próximos. A peça básica da busca semântica e do RAG.Tokens de entradaOs tokens que você envia ao modelo: prompt de sistema, histórico da conversa, contexto recuperado e a mensagem do usuário. Normalmente a metade mais barata da conta.Tokens de saídaOs tokens que um modelo gera na resposta. Normalmente a metade cara da conta — 2 a 5 vezes o preço da entrada — porque cada um exige uma passada para a frente completa.Cache de promptReutilizar o estado já calculado de um prefixo de prompt repetido em vez de recalculá-lo a cada chamada. Nas APIs aparece como uma tarifa reduzida de "leitura de cache"; no self-host é um recurso do servidor (prefix caching).RAG (geração aumentada por recuperação)Responder com um LLM recuperando primeiro trechos relevantes dos seus próprios dados e colocando-os no prompt. Mais barato e mais atual do que enfiar tudo numa janela de contexto enorme.TokenA unidade que um LLM lê e escreve. Cerca de 3-4 caracteres de inglês, ou umas 0,75 palavras. Toda conta de API é contada em tokens.
Inferência 17
Partida a frioO atraso quando um endpoint serverless ou escalado a zero precisa carregar um modelo na memória da GPU antes de poder responder à primeira requisição. Pode ser de segundos a minutos para modelos grandes.ConcorrênciaQuantas requisições um modelo atende ao mesmo tempo. Mais concorrência sobe a vazão e a eficiência de custo, mas é limitada pela VRAM porque cada requisição em curso precisa do seu próprio cache KV.Janela de contextoO número máximo de tokens que um modelo consegue considerar de uma vez — prompt e resposta somados. Os tamanhos comuns vão de 8K a mais de 1M de tokens.Batching contínuoUma técnica de servidor de inferência que adiciona e remove requisições do batch em andamento token a token, em vez de esperar um batch inteiro terminar. Multiplica várias vezes o throughput da GPU com a mesma latência.InferênciaRodar um modelo já treinado para obter uma resposta, em contraposição a treiná-lo. Divide-se numa fase de prefill (ler o prompt) e numa fase de decodificação (escrever a resposta um token de cada vez).Cache KVMemória que guarda as chaves e valores de atenção de cada token já processado, para que o modelo não os recalcule a cada novo token de saída. Vive na VRAM e cresce com o comprimento do contexto e a concorrência.LatênciaTempo total da requisição até a resposta completa. Para um LLM é aproximadamente TTFT mais (tokens de saída / tokens por segundo), mais a sobrecarga de rede.Mistura de especialistas (MoE)Uma arquitetura de modelo em que cada token é roteado apenas para algumas de muitas sub-redes "especialistas". O total de parâmetros é enorme, mas a computação por token é pequena — e por isso esses modelos são baratos de servir.Multi-GPURepartir um modelo entre várias GPUs quando não cabe em uma. Adiciona custo e sobrecarga de comunicação, e precisa de uma interconexão rápida como NVLink para continuar eficiente.QuantizaçãoGuardar os pesos do modelo (e às vezes as ativações ou o KV cache) em menor precisão numérica — 8 bits, 4 bits — para reduzir o uso de memória e acelerar a geração, normalmente com um pequeno custo de qualidade.Self-hosting (auto-hospedagem)Rodar um modelo de pesos abertos em GPUs que você aluga ou possui, em vez de chamar a API de um provedor. Você troca uma conta por token por uma conta por hora mais esforço de engenharia.Inferência serverlessUm endpoint de GPU hospedado que escala com o seu tráfego, inclusive até zero. Você paga por requisição ou por segundo de computação, não por uma máquina sempre ligada — ao custo de partidas a frio.Decodificação especulativaUm truque de velocidade: um modelo pequeno e rápido propõe vários tokens, o modelo grande verifica todos numa passada só e fica com os que aprova. Geração 2-3× mais rápida, com saída idêntica.Vazão (throughput)Quanto trabalho um sistema faz por unidade de tempo — requisições por segundo, ou tokens totais por segundo entre todos os usuários concorrentes. O número que decide a eficiência de custo ao fazer self-hosting.Tempo até o primeiro token (TTFT)Quanto um usuário espera entre enviar uma requisição e ver aparecer a primeira palavra. É dominado pela fase de prefill, então cresce com o comprimento do prompt.Tokens por segundoA velocidade com que um modelo gera saída depois de ter começado. Fixa quanto tempo leva uma resposta completa e, numa GPU auto-hospedada, determina o custo por token.VRAMA memória dedicada de uma GPU. Precisa conter os pesos do modelo, o KV cache de cada requisição em curso e as ativações. Quando esgota, você precisa de uma GPU maior, mais GPUs ou um modelo menor.
GPU e hardware 9
FP16 / BF16Formatos de ponto flutuante de 16 bits. A precisão padrão para servir modelos grandes: ~2 bytes por parâmetro. O BF16 troca bits de mantissa por alcance e é o padrão na fase de treinamento.FP8Ponto flutuante de 8 bits. Reduz a memória pela metade frente a 16 bits mantendo um alcance de ponto flutuante, então a perda de qualidade costuma ser menor que com o INT8 inteiro. Precisa de suporte de hardware (Hopper, Blackwell, MI300).GPUUm processador com milhares de núcleos em paralelo e memória muito rápida no mesmo encapsulamento. O carro-chefe tanto do treinamento quanto da inferência de modelos grandes.GPU-horaA unidade para alugar computação de GPU: o custo de uma GPU por uma hora. O Obolith normaliza cada oferta para preço por GPU-hora para poder comparar de forma justa as instâncias multi-GPU.HBMHigh Bandwidth Memory — a memória empilhada usada como VRAM nas GPUs de data center. O que fixa a velocidade de geração de um LLM é a sua largura de banda (TB/s), não a sua capacidade.Cache KVMemória que guarda as chaves e valores de atenção de cada token já processado, para que o modelo não os recalcule a cada novo token de saída. Vive na VRAM e cresce com o comprimento do contexto e a concorrência.Multi-GPURepartir um modelo entre várias GPUs quando não cabe em uma. Adiciona custo e sobrecarga de comunicação, e precisa de uma interconexão rápida como NVLink para continuar eficiente.QuantizaçãoGuardar os pesos do modelo (e às vezes as ativações ou o KV cache) em menor precisão numérica — 8 bits, 4 bits — para reduzir o uso de memória e acelerar a geração, normalmente com um pequeno custo de qualidade.VRAMA memória dedicada de uma GPU. Precisa conter os pesos do modelo, o KV cache de cada requisição em curso e as ativações. Quando esgota, você precisa de uma GPU maior, mais GPUs ou um modelo menor.
Desempenho 10
Partida a frioO atraso quando um endpoint serverless ou escalado a zero precisa carregar um modelo na memória da GPU antes de poder responder à primeira requisição. Pode ser de segundos a minutos para modelos grandes.ConcorrênciaQuantas requisições um modelo atende ao mesmo tempo. Mais concorrência sobe a vazão e a eficiência de custo, mas é limitada pela VRAM porque cada requisição em curso precisa do seu próprio cache KV.Janela de contextoO número máximo de tokens que um modelo consegue considerar de uma vez — prompt e resposta somados. Os tamanhos comuns vão de 8K a mais de 1M de tokens.InferênciaRodar um modelo já treinado para obter uma resposta, em contraposição a treiná-lo. Divide-se numa fase de prefill (ler o prompt) e numa fase de decodificação (escrever a resposta um token de cada vez).Cache KVMemória que guarda as chaves e valores de atenção de cada token já processado, para que o modelo não os recalcule a cada novo token de saída. Vive na VRAM e cresce com o comprimento do contexto e a concorrência.LatênciaTempo total da requisição até a resposta completa. Para um LLM é aproximadamente TTFT mais (tokens de saída / tokens por segundo), mais a sobrecarga de rede.Tokens de saídaOs tokens que um modelo gera na resposta. Normalmente a metade cara da conta — 2 a 5 vezes o preço da entrada — porque cada um exige uma passada para a frente completa.Vazão (throughput)Quanto trabalho um sistema faz por unidade de tempo — requisições por segundo, ou tokens totais por segundo entre todos os usuários concorrentes. O número que decide a eficiência de custo ao fazer self-hosting.Tempo até o primeiro token (TTFT)Quanto um usuário espera entre enviar uma requisição e ver aparecer a primeira palavra. É dominado pela fase de prefill, então cresce com o comprimento do prompt.Tokens por segundoA velocidade com que um modelo gera saída depois de ter começado. Fixa quanto tempo leva uma resposta completa e, numa GPU auto-hospedada, determina o custo por token.
Otimização 11
API de batchUm modo assíncrono oferecido pela maioria dos provedores de LLM: você envia um arquivo de requisições, recebe os resultados dentro de um prazo (normalmente 24 h) e paga cerca de 50% do preço por token normal.Preço de entrada em cacheUm desconto sobre os tokens de entrada que se repetem entre chamadas — um prompt de sistema estável, exemplos few-shot, um documento longo. O prefixo em cache é cobrado a cerca de 10-25% da tarifa de entrada normal.Batching contínuoUma técnica de servidor de inferência que adiciona e remove requisições do batch em andamento token a token, em vez de esperar um batch inteiro terminar. Multiplica várias vezes o throughput da GPU com a mesma latência.FP16 / BF16Formatos de ponto flutuante de 16 bits. A precisão padrão para servir modelos grandes: ~2 bytes por parâmetro. O BF16 troca bits de mantissa por alcance e é o padrão na fase de treinamento.FP8Ponto flutuante de 8 bits. Reduz a memória pela metade frente a 16 bits mantendo um alcance de ponto flutuante, então a perda de qualidade costuma ser menor que com o INT8 inteiro. Precisa de suporte de hardware (Hopper, Blackwell, MI300).INT4Quantização inteira de 4 bits. Reduz o tamanho do modelo para cerca de um quarto do de 16 bits. Grande economia de custo, mas a perda de qualidade é mais perceptível e depende do modelo — teste antes de confiar nela.INT8Quantização inteira de 8 bits. Reduz aproximadamente pela metade o tamanho do modelo frente a 16 bits, com uma perda de qualidade pequena, muitas vezes desprezível para cargas do tipo chat. Amplamente suportada.Mistura de especialistas (MoE)Uma arquitetura de modelo em que cada token é roteado apenas para algumas de muitas sub-redes "especialistas". O total de parâmetros é enorme, mas a computação por token é pequena — e por isso esses modelos são baratos de servir.Cache de promptReutilizar o estado já calculado de um prefixo de prompt repetido em vez de recalculá-lo a cada chamada. Nas APIs aparece como uma tarifa reduzida de "leitura de cache"; no self-host é um recurso do servidor (prefix caching).QuantizaçãoGuardar os pesos do modelo (e às vezes as ativações ou o KV cache) em menor precisão numérica — 8 bits, 4 bits — para reduzir o uso de memória e acelerar a geração, normalmente com um pequeno custo de qualidade.Decodificação especulativaUm truque de velocidade: um modelo pequeno e rápido propõe vários tokens, o modelo grande verifica todos numa passada só e fica com os que aprova. Geração 2-3× mais rápida, com saída idêntica.
Infraestrutura de nuvem 9
API vs self-hostingA decisão central de infraestrutura para quem roda LLMs em escala: pagar por token a um provedor, ou pagar por hora por GPUs que você opera. A resposta depende do volume, da utilização e de quanto controle você precisa.Partida a frioO atraso quando um endpoint serverless ou escalado a zero precisa carregar um modelo na memória da GPU antes de poder responder à primeira requisição. Pode ser de segundos a minutos para modelos grandes.Egress (saída de dados)A taxa que as nuvens cobram para tirar dados da rede delas para a internet. Armazenar é barato; tirar os seus dados de volta é onde a conta do armazenamento de objetos dispara.GPU-horaA unidade para alugar computação de GPU: o custo de uma GPU por uma hora. O Obolith normaliza cada oferta para preço por GPU-hora para poder comparar de forma justa as instâncias multi-GPU.Instância on-demandUma GPU na nuvem que você aluga por hora ou por segundo sem compromisso, à tarifa padrão. Disponível na hora, cobrada apenas enquanto está rodando, mas a mais cara por hora.Self-hosting (auto-hospedagem)Rodar um modelo de pesos abertos em GPUs que você aluga ou possui, em vez de chamar a API de um provedor. Você troca uma conta por token por uma conta por hora mais esforço de engenharia.Inferência serverlessUm endpoint de GPU hospedado que escala com o seu tráfego, inclusive até zero. Você paga por requisição ou por segundo de computação, não por uma máquina sempre ligada — ao custo de partidas a frio.Instância spotCapacidade sobrando de GPU na nuvem vendida com um desconto forte (muitas vezes 50-80% abaixo do on-demand) que o provedor pode retomar com pouco aviso. Boa para trabalho interrompível, arriscada para serviço ao vivo.Taxa de utilizaçãoA fração do tempo em que uma GPU alugada faz trabalho útil em vez de ficar ociosa. O número que decide se o self-hosting supera uma API.
Treinamento e fine-tuning 7
Época (epoch)Uma passada completa do conjunto de treinamento pelo modelo. As execuções de fine-tuning costumam ser de 1 a 4 épocas; cada época extra multiplica o custo de GPU da execução e, passado um ponto, causa overfitting.Fine-tuningContinuar treinando um modelo existente com os seus próprios exemplos para que ele se adapte a uma tarefa, estilo ou formato. Mais barato e rápido que treinar do zero; ainda é um custo de GPU que você paga uma vez por execução.Fine-tuning completoUm fine-tuning que atualiza todos os pesos do modelo, não um pequeno adaptador. O teto de qualidade mais alto, mas precisa de várias vezes o tamanho do modelo em VRAM e normalmente um nó multi-GPU.LoRALow-Rank Adaptation: um fine-tuning que congela o modelo base e, no lugar, treina um pequeno par de matrizes por camada. ~0,1-1% de parâmetros treináveis, então cabe numa GPU e roda em minutos a horas.Multi-GPURepartir um modelo entre várias GPUs quando não cabe em uma. Adiciona custo e sobrecarga de comunicação, e precisa de uma interconexão rápida como NVLink para continuar eficiente.Ajuste por preferência (RLHF, DPO)Uma segunda etapa de treinamento que ensina o modelo qual de duas respostas as pessoas preferem, em vez de uma única resposta-alvo. RLHF usa um modelo de recompensa + aprendizado por reforço; DPO faz isso de forma direta e barata.QLoRALoRA em cima de um modelo base que foi quantizado para 4 bits. Corta a VRAM necessária para o fine-tuning em ~3-4×, então um modelo de 70B é ajustado numa única GPU de 48 GB em vez de um nó multi-GPU.
Embeddings e bancos vetoriais 5
Divisão em trechos (chunking)Dividir os documentos em passagens menores antes de fazer os embeddings para RAG. O tamanho do trecho equilibra a precisão de recuperação e a completude do contexto, e afeta diretamente o número de vetores e o custo.EmbeddingUma lista de números (um vetor) que representa o significado de um trecho de texto, de modo que significados parecidos fiquem próximos. A peça básica da busca semântica e do RAG.Modelo de embeddingsUm modelo especializado em produzir embeddings em vez de gerar texto. Escolhido pela qualidade de recuperação (pontuação MTEB), as dimensões do vetor, o comprimento máximo de entrada e o preço.RAG (geração aumentada por recuperação)Responder com um LLM recuperando primeiro trechos relevantes dos seus próprios dados e colocando-os no prompt. Mais barato e mais atual do que enfiar tudo numa janela de contexto enorme.Banco de dados vetorialUm banco de dados feito para armazenar embeddings e achar rápido os mais próximos de um vetor de consulta. O centro de custo recorrente de um sistema RAG.
Armazenamento 2
Egress (saída de dados)A taxa que as nuvens cobram para tirar dados da rede delas para a internet. Armazenar é barato; tirar os seus dados de volta é onde a conta do armazenamento de objetos dispara.Banco de dados vetorialUm banco de dados feito para armazenar embeddings e achar rápido os mais próximos de um vetor de consulta. O centro de custo recorrente de um sistema RAG.
Economia e preços 22
API vs self-hostingA decisão central de infraestrutura para quem roda LLMs em escala: pagar por token a um provedor, ou pagar por hora por GPUs que você opera. A resposta depende do volume, da utilização e de quanto controle você precisa.API de batchUm modo assíncrono oferecido pela maioria dos provedores de LLM: você envia um arquivo de requisições, recebe os resultados dentro de um prazo (normalmente 24 h) e paga cerca de 50% do preço por token normal.Preço misto de tokenUm número único por milhão de tokens que combina os preços de entrada e saída a uma proporção assumida, para ordenar os modelos numa única coluna. O Obolith pondera a entrada 3× em relação à saída.Ponto de equilíbrioO nível de volume ou de utilização em que duas opções custam o mesmo — tipicamente API vs self-hosting, ou alugar vs comprar uma GPU. Abaixo dele, uma opção ganha; acima, a outra.Preço de entrada em cacheUm desconto sobre os tokens de entrada que se repetem entre chamadas — um prompt de sistema estável, exemplos few-shot, um documento longo. O prefixo em cache é cobrado a cerca de 10-25% da tarifa de entrada normal.ConcorrênciaQuantas requisições um modelo atende ao mesmo tempo. Mais concorrência sobe a vazão e a eficiência de custo, mas é limitada pela VRAM porque cada requisição em curso precisa do seu próprio cache KV.Custo por milhão de tokensA unidade padrão para o preço das APIs de LLM. Indicada separadamente para entrada e saída, em USD por 1.000.000 de tokens.Egress (saída de dados)A taxa que as nuvens cobram para tirar dados da rede delas para a internet. Armazenar é barato; tirar os seus dados de volta é onde a conta do armazenamento de objetos dispara.GPU-horaA unidade para alugar computação de GPU: o custo de uma GPU por uma hora. O Obolith normaliza cada oferta para preço por GPU-hora para poder comparar de forma justa as instâncias multi-GPU.Tokens de entradaOs tokens que você envia ao modelo: prompt de sistema, histórico da conversa, contexto recuperado e a mensagem do usuário. Normalmente a metade mais barata da conta.Mistura de especialistas (MoE)Uma arquitetura de modelo em que cada token é roteado apenas para algumas de muitas sub-redes "especialistas". O total de parâmetros é enorme, mas a computação por token é pequena — e por isso esses modelos são baratos de servir.Instância on-demandUma GPU na nuvem que você aluga por hora ou por segundo sem compromisso, à tarifa padrão. Disponível na hora, cobrada apenas enquanto está rodando, mas a mais cara por hora.Tokens de saídaOs tokens que um modelo gera na resposta. Normalmente a metade cara da conta — 2 a 5 vezes o preço da entrada — porque cada um exige uma passada para a frente completa.Cache de promptReutilizar o estado já calculado de um prefixo de prompt repetido em vez de recalculá-lo a cada chamada. Nas APIs aparece como uma tarifa reduzida de "leitura de cache"; no self-host é um recurso do servidor (prefix caching).RAG (geração aumentada por recuperação)Responder com um LLM recuperando primeiro trechos relevantes dos seus próprios dados e colocando-os no prompt. Mais barato e mais atual do que enfiar tudo numa janela de contexto enorme.Self-hosting (auto-hospedagem)Rodar um modelo de pesos abertos em GPUs que você aluga ou possui, em vez de chamar a API de um provedor. Você troca uma conta por token por uma conta por hora mais esforço de engenharia.Inferência serverlessUm endpoint de GPU hospedado que escala com o seu tráfego, inclusive até zero. Você paga por requisição ou por segundo de computação, não por uma máquina sempre ligada — ao custo de partidas a frio.Instância spotCapacidade sobrando de GPU na nuvem vendida com um desconto forte (muitas vezes 50-80% abaixo do on-demand) que o provedor pode retomar com pouco aviso. Boa para trabalho interrompível, arriscada para serviço ao vivo.Vazão (throughput)Quanto trabalho um sistema faz por unidade de tempo — requisições por segundo, ou tokens totais por segundo entre todos os usuários concorrentes. O número que decide a eficiência de custo ao fazer self-hosting.TokenA unidade que um LLM lê e escreve. Cerca de 3-4 caracteres de inglês, ou umas 0,75 palavras. Toda conta de API é contada em tokens.Tokens por segundoA velocidade com que um modelo gera saída depois de ter começado. Fixa quanto tempo leva uma resposta completa e, numa GPU auto-hospedada, determina o custo por token.Taxa de utilizaçãoA fração do tempo em que uma GPU alugada faz trabalho útil em vez de ficar ociosa. O número que decide se o self-hosting supera uma API.