Vários modelos locais podem partilhar um acelerador quando a camada de disponibilização coordena a permanência dos pesos na memória, a memória dinâmica, o tempo de execução e o isolamento dos pedidos entre cargas de trabalho.
Uma GPU doméstica pode alternar entre um modelo de conversação, um modelo de embeddings, um codificador de visão e reconhecimento de voz. Carregar permanentemente todos os conjuntos de pesos pode exceder a VRAM, enquanto descarregá-los a cada pedido torna a latência do primeiro token imprevisível. Um controlador multimodelo precisa de políticas de permanência, contabilização de memória entre modelos, escalonamento, isolamento de caches, preempção e equidade, em vez de depender de processos separados a competir cegamente.
A Política de Permanência Determina Quais os Pesos que Permanecem Prontos
O controlador acompanha o tamanho do modelo, a taxa de chegada, o tempo de carregamento, o objetivo de latência e a utilização recente. Os modelos populares permanecem residentes, os modelos pouco frequentes ocupam a CPU ou o armazenamento, e a procura prevista pode desencadear um pré-aquecimento antes de o próximo pedido chegar ao acelerador.
pré-aquecimento multimodelo prepara trabalhadores universais da GPU para vários modelos e coordena o pré-aquecimento com uma colocação consciente das expulsões. Os resultados mostram por que motivo evitar um carregamento a frio pode melhorar drasticamente o tempo até ao primeiro token quando a procura é previsível. Esta distinção continua visível durante os testes domésticos posteriores.
As decisões de permanência devem incluir variantes de quantização e de adaptadores, porque dois pontos de acesso aparentemente semelhantes podem manter pesos-base diferentes. Um orçamento de memória rigoroso impede que o carregamento proativo expulse a cache KV de pedidos ativos. O resultado intermédio deve permanecer inspecionável antes de a automatização prosseguir.
A Coordenação da Memória entre Modelos Evita Capacidade Fragmentada
Os pesos são sobretudo estáveis, enquanto as ativações e as caches KV aumentam com o tamanho do lote e o comprimento da sequência. Um alocador partilhado pode mapear páginas de memória a pedido, recuperar regiões inativas e expor reservas, para que um modelo não possa consumir o espaço prometido a outro.
coordenação da memória entre modelos introduz a coordenação da memória entre modelos com mapeamento dinâmico de páginas virtuais para físicas e políticas de partilha em tempo de execução. O design explica por que motivo a partilha de GPU ao nível dos processos não consegue responder bem à procura de modelos em rápida mudança. Esse limite deve ser medido separadamente em condições de funcionamento realistas.
Partilhar memória não significa partilhar dados. Os blocos de cache KV, as caches de prefixos, os buffers temporários e o estado dos adaptadores exigem identificadores de inquilino e de modelo; caso contrário, uma página ou chave de cache reutilizada pode divulgar contexto ou corromper resultados entre pontos de acesso.
O Escalonamento e a Multiplexagem de Adaptadores Controlam o Tempo de Execução
Um escalonador escolhe entre a partilha espacial, em que os modelos ocupam memória em simultâneo, e a partilha temporal, em que os kernels se alternam. O batching contínuo melhora o débito, enquanto a preempção e as filas ponderadas protegem um pedido interativo de um trabalho em segundo plano demorado.
multiplexagem de adaptadores disponibiliza milhares de adaptadores de baixo nível sobre modelos-base partilhados, paginando os pesos dos adaptadores e coordenando lotes heterogéneos. Isto demonstra como a especialização pode partilhar mais estado do que réplicas de modelos completamente separadas. A consequência prática surge quando várias fontes competem por um contexto limitado.
O limite de falha está na interferência entre kernels e memória. Dois modelos que cabem simultaneamente podem ainda assim não cumprir os objetivos de latência quando competem por capacidade de computação, largura de banda ou motores de cópia. A partilha só é útil quando a latência p95 e a equidade por modelo permanecem dentro da política, e não quando a utilização agregada parece simplesmente elevada.
Crie uma Matriz de Interferência da Partilha de Modelos
Meça cada modelo isoladamente e, em seguida, execute cada par importante e a combinação esperada dos quatro modelos com pedidos curtos, longos, em rajada e em segundo plano. Registe o tempo de carregamento a frio, a memória residente, o crescimento da KV, a utilização dos kernels, o débito, a latência p50 e p95 e as expulsões.
Utilize o princípio da pilha encaminhada em permanência encaminhada dos modelos para atribuir uma prioridade e uma classe de permanência a cada ponto de acesso. Repita com adaptadores, variantes quantizadas, batching contínuo e preempção, verificando que as caches e as identidades dos pedidos permanecem isoladas.
Mantenha uma política de partilha apenas quando os modelos interativos importantes cumprirem o respetivo objetivo de latência durante a pior combinação esperada. Se um par provocar thrashing repetidamente, serialize esse par ou reserve uma janela temporal, em vez de aumentar a simultaneidade para obter um gráfico de utilização mais favorável.
Centro de Tecnologia e IA
Mais para Ler

Que funcionalidades permitem criar um limite de confiança de IA doméstica em torno de ficheiros sensíveis?
Veja como a classificação, o acesso limitado por capacidades, a análise isolada, os filtros de recuperação, a política de saída de dados, as aprovações...

Que fatores determinam se as cópias de segurança baseadas em árvores de Merkle detetam alterações silenciosas de forma eficiente?
Saiba como o tamanho dos blocos, o fator de ramificação, as raízes fidedignas, os hashes em cache, a localidade das alterações, o âmbito dos...

Que componentes permitem cópias de segurança verificáveis de índices de IA e do estado dos modelos?
Veja como snapshots coordenados, manifestos de conteúdo, somas de verificação, bloqueios de versão, simulações de restauro e testes de consulta comprovam que o estado...

