Como é que um servidor de IA doméstico encaminha modelos com base na utilização de memória?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Um servidor de IA doméstico encaminha os modelos com base na sua utilização de memória, associando cada pedido a um modelo cujo conjunto de trabalho completo caiba na margem disponível do dispositivo.

Um encaminhador local pode escolher entre modelos de linguagem pequenos e grandes, modelos de embeddings, codificadores de visão, sistemas de voz e vias de execução em CPU ou GPU. O ficheiro de checkpoint é apenas o valor inicial. A admissão efetiva também depende dos metadados de quantização, do contexto de execução, da cache KV, do comprimento do prompt, da concorrência, dos tokens de visão, dos espaços de trabalho temporários e da memória já reservada por outros serviços. Um encaminhador eficaz traça o perfil desses custos antes da execução e escolhe um modelo, uma precisão, um limite de contexto e uma via de hardware que possam manter-se estáveis durante todo o pedido.

O tamanho do checkpoint é apenas a parte fixa da utilização

Os pesos e os metadados de quantização criam uma base residente previsível. Depois, o runtime acrescenta bibliotecas, pools do alocador, grafos de execução, buffers de entrada, ativações e o estado do pedido.

O guia de hardware da ZimaSpace considera a memória total para IA como algo mais abrangente do que o tamanho do ficheiro do modelo.

Um encaminhador que utilize apenas o tamanho do ficheiro pode admitir um modelo que é carregado com sucesso, mas falha durante um prefill longo, um pedido multimodal ou uma conversa concorrente.

Cada modelo precisa de um perfil de memória empírico

Registe a memória residente em inatividade, a memória máxima durante o prefill, os bytes por token de contexto, a precisão da KV, os limites de batch, o custo dos tokens visuais e a reserva do runtime para cada modelo e quantização.

Um estudo de 2026 sobre agendamento de vários modelos caracteriza o comportamento da memória dos modelos em diferentes arquiteturas e hardware heterogéneo, em vez de assumir que uma única fórmula de colocação serve para todos os modelos.

Os perfis devem incluir estados a frio e a quente, porque as caches de compilação e os valores máximos do alocador podem alterar a memória disponível depois de pedidos anteriores.

Volte a criar o perfil depois de alterar o runtime, o controlador, a definição de contexto, a quantização ou o formato do modelo.

O encaminhador tem de reservar margem dinâmica antes da admissão

O pedido fornece informações adicionais: comprimento do prompt, saída esperada, número e resolução das imagens, batch solicitado e concorrência atual de utilizadores.

O agendador global de memória do Prism ajusta a ativação e a expulsão de modelos com base na carga de trabalho e nas informações da fila, em vez de utilizar reservas fixas.

Um encaminhador doméstico pode usar uma fórmula de admissão mais simples: a memória livre do dispositivo, menos a margem de segurança, tem de exceder a base do modelo acrescida do estado estimado do pedido e do espaço de trabalho.

Se a estimativa não couber, o encaminhador pode encurtar o contexto, reduzir o batch, escolher um modelo mais pequeno, utilizar uma precisão inferior na cache, colocar o pedido em fila ou encaminhá-lo para outro dispositivo.

Execução integral na GPU, offload parcial e execução na CPU são vias diferentes

Um modelo que caiba totalmente na VRAM geralmente evita transferências repetidas dos pesos entre o anfitrião e o dispositivo. Um modelo maior pode funcionar através de offload parcial para a CPU ou de memória unificada, mas com limites diferentes de latência e largura de banda.

O ATSInfer utiliza a colocação ao nível dos tensores para coordenar o armazenamento, as transferências e a computação entre a memória da CPU e da GPU em dispositivos de consumo.

O encaminhador deve distinguir entre “consegue executar” e “cumpre o prazo do fluxo de trabalho”. Um modelo parcialmente descarregado pode ser adequado para uma análise noturna e inaceitável para uma interação por voz.

A popularidade e o custo de recarregamento influenciam os modelos que permanecem residentes

Os modelos solicitados com frequência podem permanecer quentes, enquanto os modelos grandes e raros ficam no armazenamento até que uma tarefa justifique o custo do seu carregamento.

O Weaver analisa modelos quentes e frios em sistemas que servem muitos endpoints com popularidade desigual.

Um pedido pode ser encaminhado para um modelo quente ligeiramente mais pequeno quando este cumpre os requisitos de qualidade e evita um longo ciclo de expulsão e recarregamento. Uma tarefa difícil pode justificar o carregamento do modelo maior quando o ganho de qualidade esperado supera o atraso.

Os requisitos da tarefa devem limitar as decisões baseadas apenas na memória

A menor utilização de memória nem sempre corresponde à via correta. Programação, texto multilingue, raciocínio complexo, OCR e planeamento de ferramentas podem exigir capacidades ausentes num modelo mais pequeno.

O MuxServe combina a colocação e o agendamento, porque a disponibilização eficiente depende tanto da procura pelos modelos como do comportamento dos recursos.

Defina primeiro um nível mínimo de capacidades e, depois, escolha o modelo com menor utilização de memória entre os que passam os testes de qualidade, segurança, latência e formato do fluxo de trabalho.

Uma tarefa de extração determinística pode ser encaminhada para um modelo pequeno residente, enquanto um pedido de planeamento difícil é encaminhado para um modelo maior ou aguarda por capacidade.

O encaminhamento deve adaptar-se à memória disponível e ao histórico recente de execução

Os perfis estáticos não conseguem captar todas as reservas do alocador, regiões fragmentadas, contentores concorrentes ou reduções de desempenho causadas pela temperatura. O encaminhador também precisa da memória livre atual, da profundidade da fila, dos modelos residentes e das falhas recentes.

A investigação sobre agendamento agentivo CPU-GPU combina utilizações de memória, custo de arranque a frio, histórico de execução e dados do hardware ao atribuir trabalho de IA heterogéneo.

Registe a via escolhida, a memória prevista, o pico real, o tempo de carregamento, a latência até ao primeiro token, a velocidade de saída e qualquer fallback. Atualize o perfil do modelo quando o erro de previsão ultrapassar uma margem definida.

O encaminhamento orientado pela memória é bem-sucedido quando os pedidos permanecem dentro de uma capacidade estável, enquanto o servidor continua a escolher o modelo mais potente capaz de cumprir o objetivo de serviço da tarefa atual.

FAQ

Um encaminhador pode utilizar o tamanho do ficheiro do modelo como estimativa rápida?

É uma base útil, mas o encaminhador continua a precisar de considerar a sobrecarga do runtime, a cache KV, o prompt, o batch e uma margem de segurança antes de admitir o pedido.

Um modelo deve ser encaminhado para a CPU sempre que a VRAM estiver cheia?

Apenas quando a execução na CPU ou híbrida cumprir os requisitos de latência e memória da tarefa. Colocar o pedido em fila ou selecionar um modelo mais pequeno pode ser uma opção melhor.

O encaminhamento orientado pela memória exige várias GPUs?

Não. Pode escolher entre uma GPU, execução na CPU, offload parcial, diferentes quantizações e vários tamanhos de modelo num único servidor doméstico.

Centro de Tecnologia e IA

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.