De quanta VRAM precisa um assistente de documentos local?

Um assistente de documentos local não necessita de VRAM dedicada quando a geração é executada remotamente ou num servidor de inferência separado. Para inferência na mesma máquina, 8 GB são um ponto de partida prático para modelos pequenos quantizados, enquanto modelos maiores, contextos mais longos e a execução simultânea de vários pedidos podem elevar a necessidade muito acima dos 16–24 GB. Dimensione o modelo exato e o contexto de trabalho antes de comprar, porque a própria aplicação RAG não define os requisitos de VRAM.

Decida se o assistente precisa realmente de uma GPU local

Um assistente de documentos tem, pelo menos, duas camadas: a aplicação que armazena ficheiros, divide o texto em segmentos, pesquisa ou recupera excertos e apresenta respostas; e o backend do modelo que executa a geração. Essas camadas não têm de funcionar no mesmo hardware. Um servidor compacto pode alojar a biblioteca privada de documentos e a infraestrutura de recuperação, enviando os pedidos ao modelo para outra máquina local com GPU ou para um fornecedor remoto.

A documentação de alojamento próprio do AnythingLLM torna esta separação explícita, permitindo que a aplicação se ligue a serviços de modelos e de embeddings noutro local. Por isso, os seus requisitos de alojamento próprio são bastante inferiores aos do hardware necessário para executar um LLM na mesma máquina.

Se o requisito for “os documentos permanecem no meu servidor” e não “cada token do modelo tem de ser gerado neste servidor”, zero VRAM dedicada pode ser uma opção de compra válida. Ainda assim, deve confirmar que texto sai da máquina, onde são produzidos os embeddings, como o modelo remoto processa os pedidos e se o limite de privacidade corresponde ao caso de utilização.

A primeira decisão de compra é arquitetural: a inferência remota ou separada implica dimensionar CPU, RAM e armazenamento para a recuperação; a inferência na mesma máquina faz da VRAM uma restrição essencial na escolha do modelo.

Dimensione os pesos do modelo antes de acrescentar a sobrecarga do RAG

O planeamento da VRAM começa pelo modelo exato e pela precisão. Os pesos em precisão total são muito maiores do que as variantes de 8 ou 4 bits, razão pela qual dois utilizadores que dizem “executo um modelo de 7B” podem ter requisitos de memória muito diferentes. A quantização pode fazer com que um modelo pequeno e útil caiba em hardware comum, mas também pode alterar o comportamento das respostas e deve ser avaliada com a tarefa documental.

A Hugging Face explica que a quantização reduz os custos de memória e computação ao representar pesos e ativações com tipos de dados de menor precisão, suportando percursos comuns de 8 e 4 bits. Assim, a precisão é uma variável de compra, e não apenas uma opção de software aplicada depois de escolher o hardware.

Como regra prática de planeamento, os modelos de 7–8B em 4 bits costumam caber na faixa dos 6–8 GB, os modelos de 13–14B aproximam-se frequentemente dos 10–12 GB e os modelos de 27–32B necessitam muitas vezes de cerca de 20 GB antes de acrescentar margem para o contexto. O guia de dimensionamento de VRAM da Spheron para 2026 apresenta valores semelhantes para planeamento INT4 e acrescenta explicitamente a sobrecarga de execução para além da estimativa dos pesos.

Não compre com base exata no tamanho do ficheiro do modelo descarregado. Reserve espaço para o tempo de execução e para o estado do contexto e, depois, verifique o modelo real no motor de inferência pretendido. Um modelo que carrega com um pequeno pedido de teste pode ainda falhar ou transferir camadas para outro tipo de memória quando o assistente recebe um contexto recuperado longo.

O comprimento do contexto pode alterar o escalão de VRAM depois de o modelo caber

Um assistente de documentos necessita frequentemente de mais contexto do que um chatbot casual, porque os excertos recuperados, as citações, as instruções do sistema, o histórico da conversa e as perguntas do utilizador são reunidos num único pedido. Os pesos do modelo podem permanecer constantes, enquanto a cache de valores-chave e outro estado do pedido aumentam com o comprimento do contexto.

A atual documentação do contexto do Ollama torna esta troca visível: o comprimento de contexto predefinido aumenta com a VRAM disponível, de 4K abaixo de 24 GiB para 32K entre 24 e 48 GiB e valores muito superiores a partir de 48 GiB. As predefinições exatas dependem do motor, mas a conclusão para a compra é que o trabalho documental com contexto longo consome memória para além dos pesos do modelo.

Não responda maximizando o contexto indiscriminadamente. A recuperação deve selecionar o menor conjunto de excertos que responde à pergunta, e a divisão em segmentos ou a reordenação deve remover texto irrelevante antes da geração. Um assistente de documentos que precisa de inserir todos os documentos num único pedido está a usar VRAM para compensar um desenho de recuperação fraco.

Avance para o escalão seguinte de VRAM quando o modelo testado tiver qualidade suficiente, mas os pedidos documentais reais provocarem transferência de camadas, erros de falta de memória ou latência inaceitável no comprimento de contexto de que realmente necessita. Se a qualidade da recuperação for fraca antes de o contexto chegar ao modelo, corrija primeiro o índice e a ordenação.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Faça um orçamento separado para embeddings, reordenação, OCR e execução simultânea

O LLM local não é o único componente que pode utilizar memória da GPU. Alguns assistentes de documentos também aceleram embeddings, reordenadores, OCR, transcrição de voz ou modelos de visão na mesma GPU. Executar esses modelos simultaneamente pode reduzir a VRAM disponível para o gerador, mesmo quando cada componente cabe individualmente.

O artigo da ZimaSpace sobre a utilização total de memória dos modelos explica por que motivo os buffers de execução e o estado dos pedidos devem ser considerados juntamente com o tamanho do checkpoint. Num assistente de documentos, o contexto recuperado e os serviços paralelos acrescentam outra camada de pressão sobre a memória partilhada.

A execução simultânea também altera a resposta. Dois utilizadores ativos podem necessitar de estados de cache KV separados, mesmo quando partilham um único modelo residente. Um servidor orientado para processamento em lote pode melhorar a utilização do acelerador, mas não elimina a memória necessária por pedido. Meça a consulta documental normal mais longa com o número esperado de utilizadores simultâneos.

Se o gerador for a única carga de trabalho da GPU, pode dimensionar mais próximo do conjunto de trabalho testado. Se OCR, embeddings, reordenação e geração tiverem de funcionar em paralelo, compre mais VRAM, serialize as fases pesadas ou distribua os serviços pelos recursos de CPU e GPU. A opção mais económica é a que preserva a latência necessária sem pagar por aceleração ociosa.

Use escalões de VRAM para selecionar modelos e, depois, teste a qualidade

Uma seleção útil pode ser organizada pelo que o assistente de documentos tem de fazer, em vez de se basear no maior modelo que cabe. Com cerca de 6–8 GB de VRAM, comece por modelos pequenos de 7–8B em 4 bits e por uma recuperação limitada. Com cerca de 12–16 GB, terá margem para modelos maiores, maior precisão ou mais contexto. Com cerca de 24 GB, muitos modelos quantizados de 27–32B tornam-se práticos, com mais margem de trabalho. Cerca de 40–48 GB ou mais corresponde ao escalão em que os modelos de 70B em 4 bits começam a ser realistas sem transferência significativa de camadas.

O guia de LLMs locais da SitePoint para 2026 refere que um modelo 7B Q4_K_M pode caber confortavelmente em cerca de 6 GB de VRAM. Outros guias atuais de dimensionamento colocam os modelos quantizados de 14B e 32B em escalões superiores, reforçando a regra de que o escalão depende do checkpoint exato e não de uma designação genérica como “PC para IA”.

Crie um conjunto de avaliação a partir dos seus próprios documentos antes de comprar o escalão seguinte. Inclua perguntas que exijam extração exata, síntese de vários excertos, recusa quando a fonte não contém a resposta, tabelas ou texto estruturado, se for relevante, e o contexto mais longo que espera utilizar. Compare a qualidade das respostas, o comportamento das citações, a latência até ao primeiro token, a velocidade de geração e o pico de VRAM.

Compre mais VRAM quando o modelo mais pequeno falhar porque a capacidade do modelo ou do contexto for genuinamente insuficiente. Não faça uma atualização apenas porque existe um checkpoint maior. A recuperação pode tornar um modelo mais pequeno e rápido mais útil para uma base de conhecimento privada e limitada do que um modelo mais lento com fundamentação fraca.

Mantenha o anfitrião de armazenamento e recuperação separado da decisão de VRAM

Um assistente de documentos também precisa de armazenamento persistente para ficheiros originais, texto extraído, índices, bases de dados das aplicações, registos e cópias de segurança. Normalmente, esses recursos consomem RAM do sistema e capacidade de disco, e não VRAM. Combinar todos os recursos num único valor de “memória para IA” conduz a más decisões de hardware.

A visão geral da ZimaSpace sobre um assistente de IA privado num NAS descreve o papel dos ficheiros locais numa arquitetura orientada para a recuperação. Essa arquitetura permite que o sistema de armazenamento permaneça estável mesmo que o hardware de inferência seja alterado mais tarde.

O ZimaBoard 2 1664 é adequado quando a função do servidor compacto é armazenar documentos, indexar, alojar aplicações e coordenar serviços, enquanto o LLM é executado remotamente ou numa máquina separada com GPU. Os gráficos Intel integrados não devem ser considerados VRAM dedicada para LLMs.

Escolha o anfitrião de armazenamento com base no volume de documentos, nas cópias de segurança, na memória das aplicações e nas necessidades de rede. Escolha o acelerador com base no modelo exato, na quantização, no contexto e na execução simultânea. Manter estas decisões separadas permite atualizar a GPU sem reconstruir o repositório documental principal.

Verifique qualquer configuração de GPU na mesma caixa antes de comprar

Se quiser armazenamento, recuperação e geração local na mesma caixa, a verificação final da compra é a memória exata da GPU disponível para o motor de execução. Nomes de produtos como “IA”, “Creator” ou “RTX” não indicam se o modelo local escolhido irá caber. É necessário verificar a VRAM, o suporte de controladores, o acesso a contentores, a alimentação, a refrigeração e a possibilidade de expansão física.

O ZimaCube 2 Creator Pack é a opção da Zima a avaliar quando o comprador pretende armazenamento com várias baias e uma GPU NVIDIA dedicada no mesmo sistema. A página atual do produto identifica a família da GPU, mas não publica um valor de VRAM no texto principal das especificações; por isso, não o associe a um escalão de 8, 16, 24 ou 48 GB até confirmar a memória exata da GPU instalada.

Antes de finalizar a compra, execute ou solicite, sempre que possível, um teste com um modelo representativo. Registe o pico de VRAM com a quantização e o contexto normais e repita o teste com os embeddings, o reordenador, o OCR ou outros serviços da GPU do assistente ativos. Confirme que o motor utiliza realmente a GPU pretendida, em vez de transferir silenciosamente camadas para a memória do sistema.

A regra final é comprar VRAM para o conjunto de trabalho validado, e não para a categoria de marketing. Use zero VRAM dedicada quando a inferência puder ser executada noutro local; comece com cerca de 6–8 GB para modelos locais pequenos quantizados; avance para 12–16 GB para modelos maiores ou mais margem; e considere 24 GB ou mais apenas quando o fluxo de trabalho documental testado demonstrar que o tamanho do modelo, o contexto ou a execução simultânea o exigem.

Perguntas frequentes

O RAG reduz a quantidade de VRAM de que necessito?

O RAG pode permitir que um modelo mais pequeno responda com base em evidências recuperadas, em vez de depender do conhecimento interno de um modelo maior, o que pode reduzir o escalão de modelo necessário. Os excertos recuperados continuam a consumir memória de contexto, pelo que uma recuperação deficiente que envie texto em excesso pode aumentar a pressão sobre a VRAM.

Os embeddings necessitam da mesma VRAM que o modelo de conversação?

Não. Os modelos de embeddings têm a sua própria utilização de CPU, RAM ou GPU e podem ser executados na CPU ou num serviço separado. Se os embeddings e a geração partilharem uma GPU, meça o pico combinado em vez de somar no papel os tamanhos dos ficheiros dos modelos.