Escolha um GPU para suas requisições reais.

Definir o resultado útil antes de buscar taxa de transferência

Em interação, meça a espera do primeiro token e a da resposta completa. Para um corpus offline, meça o tempo necessário para obter todas as saídas esperadas. Nos dois casos, defina a regra de aceitação: exatidão em respostas conhecidas, qualidade de uma classificação ou extração de campos verificada. Um JSON sintaticamente válido ainda pode conter uma resposta errada.

Separe a espera na fila, o processamento e o trajeto completo observado pelo seu cliente quando suas ferramentas permitirem. Uma medição interna ao motor não tem os mesmos limites que a da aplicação. A documentação das métricas do vLLM distingue, em particular, espera, primeiro token e duração total: conserve essa distinção nos seus registros, qualquer que seja o motor escolhido.

Fontes técnicas: vLLM — métricas de requisições e de latência

Transformar suas requisições em critérios de escolha

Prepare entradas curtas, habituais e longas com identificadores estáveis. Mantenha modelo, tokenizer, template de conversa e parâmetros de geração. Conte os tokens realmente transmitidos, incluindo o histórico e os documentos adicionados pela aplicação. Registre separadamente batch solicitado, concorrência enviada e requisições efetivamente processadas simultaneamente: não são necessariamente os mesmos números.

Medir a memória com contexto e concorrência

Para um modelo autorregressivo que gera token por token, o cache KV conserva estados de atenção. Seu tamanho depende do modelo e dos tokens mantidos. Um cache dinâmico pode crescer durante a geração; um cache estático reserva um tamanho máximo. Algumas camadas de janela deslizante limitam esse crescimento. Teste, portanto, os comprimentos e a concorrência previstos com a estratégia realmente utilizada.

A quantização dos pesos e a do cache são duas escolhas distintas. Por exemplo, o bitsandbytes substitui algumas camadas lineares por versões quantizadas; isso não descreve todas as alocações da sua execução. Após uma mudança de precisão, verifique novamente memória e qualidade em vez de supor que todo o pico diminui na mesma proporção.

Com PyTorch, registre separadamente o pico dos tensores alocados e o da memória reservada pelo alocador. Não os some. Indique a GPU medida e a unidade: 1 GiB corresponde a 2³⁰ bytes. Esses contadores não representam necessariamente toda a ocupação do dispositivo. A pasta de memória detalha seus limites.

Fontes técnicas: Hugging Face Transformers 5.17 — estratégias de cache KV · Hugging Face Transformers 5.17 — quantização bitsandbytes · PyTorch 2.14 — gestão e contadores de memória CUDA

Um ensaio mensurável sobre 300 documentos

Exemplo a realizar com seu corpus autorizado: extrair data, valor e categoria de 300 documentos. Revise os valores esperados, especifique o tratamento dos campos ausentes e defina o limiar de aceitação antes do ensaio. O número de documentos descreve o protocolo; nenhum tempo, pontuação ou taxa é presumido.

• Fixe os 300 identificadores, a revisão do modelo, os prompts, os limites de tokens e a regra de parsing. Mantenha os documentos longos identificáveis no balanço.
• Execute uma referência com uma requisição por vez. Separe carregamento, aquecimento e medição; conserve as predições e os erros por documento.
• Aumente depois um único parâmetro: batch para um processamento em lote, ou concorrência para um motor de requisições. Mantenha as mesmas entradas e critérios de qualidade.
• Para cada passagem, registre duração, pico de memória, número de identificadores recuperados sem duplicata e saídas aceitas. Repita as medições e conserve os valores brutos com sua dispersão.
• Se uma variante falhar, registre o motivo: memória, truncamento, formato ou qualidade. Um batch reduzido ou uma retomada cria uma decisão a documentar, não um fracasso a apagar.

Fontes técnicas: IteraGPU — protocolo detalhado de comparação com qualidade equivalente

Usar os recursos do IteraGPU Lab v1 no escopo correto

O notebook e seu script complementar propõem um cálculo de pesos e uma medição em uma pequena rede sintética. Seu código de medição foi executado em uma RTX 5070 local com PyTorch 2.11.0, em uma pequena configuração em float32. Esse ensaio verifica esse caso de execução; ele não mede nem um LLM, nem um cache KV, nem as GPUs do catálogo nas suas requisições.

Use o notebook para entender os contadores, depois meça sua carga real com seu ambiente. O protocolo de qualidade e a tabela bruta servem para preparar a comparação. As saídas do notebook distribuído e as linhas de resultados do CSV permanecem em branco; o procedimento não instala nenhum modelo nem driver. Leia os pré-requisitos do README antes da execução.

• Notebook de memória do IteraGPU Lab v1 ↓

  Cálculos e pequena rede sintética para entender a medição de memória.

• Protocolo de qualidade a completar ↓

  Entradas fixas, aceitação das saídas e comparação dos ensaios.

• Tabela bruta em branco ↓

  Uma linha por passagem real, com parâmetros, medições e veredito.

• Pré-requisitos e limites do IteraGPU Lab v1 ↓

  Instruções e escopo preciso do ensaio local já realizado.

Passar das medições para uma oferta

Sua ficha de escolha deve reunir ambiente compatível, memória por placa, contexto, concorrência, qualidade alcançada e prazos medidos. Compare as configurações que atendem a esses critérios e depois os planos de 3, 7 e 30 dias conforme o cronograma completo: preparação, processamento, avaliação, retomadas e exportação. A calculadora do dossiê de benchmarks usa o plano inteiro e corpora úteis realmente validados.

Guarde esta ficha e as versões do código no seu caderno. Você escolhe seus softwares e seus processamentos; a IteraGPU não inspeciona o conteúdo dos seus arquivos, prompts ou cálculos. Uma escolha de ambiente no pedido expressa sua necessidade de preparação: ela não constitui prova de que seu modelo já foi instalado ou testado.

Perguntas práticas