Porque é que o Zero to MVP executa modelos de IA de 2–4 GB 24 horas por dia, 7 dias por semana, no ZimaCube 2

Eva Wong

IceWhale author

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.

Why Zero to MVP Runs 2–4 GB AI Models 24/7 on ZimaCube 2

Agradecemos ao Zero to MVP por demonstrar uma forma prática de pensar sobre modelos de linguagem pequenos. No seu vídeo completo, defende que os modelos de 2–4 GB se tornam muito mais úteis quando são tratados como ferramentas especializadas e sempre ativas, em vez de substitutos mais fracos dos maiores modelos de IA.

A configuração utiliza um ZimaCube 2 como servidor doméstico silencioso, capaz de manter modelos locais disponíveis permanentemente e, simultaneamente, armazenar os documentos com que esses modelos trabalham. As demonstrações abrangem OCR, resumo automático de artigos, processamento privado de informações relacionadas com a saúde e tradução baseada em ficheiros — tarefas em que entradas previsíveis, pedidos repetidos, privacidade e baixo consumo de recursos podem ser mais importantes do que a capacidade máxima do modelo.

Declaração sobre a colaboração: este artigo baseia-se nos fluxos de trabalho e exemplos de modelos demonstrados pelo Zero to MVP. As versões dos modelos, os tamanhos dos ficheiros, a utilização de memória em tempo de execução, os requisitos de hardware, a compatibilidade do software e o desempenho da inferência podem mudar ao longo do tempo. As ferramentas de IA relacionadas com a saúde aqui mencionadas não devem ser consideradas substitutos de aconselhamento, diagnóstico ou tratamento médico profissional.

O resultado: os modelos pequenos tornam-se particularmente interessantes quando lhes são atribuídas tarefas específicas que precisam de ser executadas repetidamente. Em vez de pedir a um único modelo enorme que faça tudo, um servidor doméstico pode manter vários modelos compactos disponíveis para OCR, criação de resumos, tradução ou outras tarefas especializadas em segundo plano.

Porquê executar modelos de IA pequenos 24 horas por dia, 7 dias por semana?

As discussões sobre IA local centram-se frequentemente no maior modelo que uma máquina consegue carregar. O Zero to MVP adopta uma abordagem diferente. Num fluxo de trabalho sempre ativo, a pergunta mais útil é saber se um modelo consegue executar uma tarefa definida de forma suficientemente fiável para permanecer disponível em segundo plano.

Um modelo de 2–4 GB não precisa de competir com um modelo de escala frontier em todos os tipos de raciocínio. Pode, em vez disso, tornar-se um componente dedicado de um fluxo de trabalho mais abrangente: reconhecer texto num documento, resumir um artigo, traduzir um ficheiro ou processar informações localmente antes de outra aplicação utilizar o resultado.

Isto transforma o papel do modelo, que deixa de ser um chatbot ocasional para passar a ser um serviço.

Como é, na realidade, um modelo local de 2–4 GB?

Os modelos instalados no ambiente Ollama do Zero to MVP mostram como esta abordagem pode ser compacta. O terminal apresenta quatro modelos, com tamanhos aproximados entre 2,1 GB e 3,4 GB, cada um adequado a um tipo diferente de tarefa.

Listagem do terminal Ollama com os modelos MedGemma 1.5, Granite 4.1 3B, GLM-OCR e Qwen 3.5 4B entre 2,1 GB e 3,4 GB

A biblioteca Ollama da Zero to MVP inclui MedGemma 1.5, Granite 4.1 3B, GLM-OCR e Qwen 3.5 4B, com os ficheiros de modelo apresentados a variarem entre 2,1 GB e 3,4 GB.

Modelo apresentado	Tamanho apresentado	Função no fluxo de trabalho
MedGemma 1.5	3,3 GB	Processamento local de informação relacionada com a saúde.
Granite 4.1 3B	2,1 GB	Um modelo compacto de uso geral disponível na biblioteca de modelos locais.
GLM-OCR	2,2 GB	Converte documentos digitalizados em texto e Markdown legíveis por máquina.
Qwen 3.5 4B	3,4 GB	Utilizado em tarefas como o resumo de artigos e a tradução.

O ponto importante não é que todos os modelos ocupem exatamente a mesma quantidade de memória durante a execução. Estes números descrevem os ficheiros de modelo apresentados pelo Ollama. A memória de execução, o contexto, a colocação em cache, o sistema operativo e outros serviços ativos acrescentam os seus próprios requisitos de recursos.

Os modelos pequenos são uma ferramenta diferente, não apenas modelos grandes mais pequenos

A IA local é frequentemente associada a estações de trabalho desktop e a GPUs discretas de grandes dimensões. Esse hardware faz sentido quando a carga de trabalho exige modelos maiores, elevado débito ou tarefas de geração exigentes.

Estação de trabalho desktop com uma placa gráfica AMD Radeon Pro W7800 instalada

Uma estação de trabalho desktop com uma AMD Radeon PRO W7800 representa a abordagem de alto desempenho mais familiar ao hardware de IA local.

No entanto, um serviço em segundo plano que recebe pedidos simples e repetitivos tem um conjunto de requisitos diferente. Manter um modelo pequeno especializado pronto num hardware modesto pode fazer mais sentido do que reservar uma estação de trabalho potente para cada tarefa de OCR, pedido de tradução ou resumo curto.

Dois dispositivos de computação compactos com dissipadores de calor, posicionados numa secretária ao lado de um teclado

O hardware de computação compacto ilustra o outro lado do espectro da IA local: os modelos pequenos especializados podem tornar possíveis serviços de IA úteis sem dedicar uma estação de trabalho completa, de classe desktop, a cada tarefa.

Modelo grande de uso geral	Modelo pequeno especializado
Foi concebido para lidar com uma vasta gama de pedidos abertos.	Pode ser atribuído a uma tarefa mais limitada e previsível.
Beneficia frequentemente de mais memória e recursos de aceleração.	Pode funcionar com uma utilização mais reduzida de hardware e memória.
É útil quando o raciocínio complexo ou uma ampla gama de capacidades são importantes.	É útil quando a mesma operação simples precisa de ser executada repetidamente.
Pode ser excessivo para processamento simples em segundo plano.	Pode permanecer disponível como um serviço persistente com menor sobrecarga.

Um modelo pequeno não significa um custo de recursos nulo

O tamanho reduzido do ficheiro não deve ser confundido com a ausência de sobrecarga em tempo de execução. O monitor do sistema do Zero to MVP proporciona uma verificação útil da realidade enquanto o Ollama está ativo.

terminal do htop a mostrar a utilização de CPU e memória do llama-server do Ollama enquanto um modelo de IA local está em execução

O monitor do sistema em tempo real mostra o llama-server do Ollama a consumir CPU e vários gigabytes de memória durante a execução, demonstrando que um ficheiro de modelo pequeno continua a exigir recursos adicionais em tempo de execução.

Na carga de trabalho capturada, o sistema indica aproximadamente 7,8 GB de memória total, com vários gigabytes em utilização, enquanto um Ollama llama-server o processo ocupa uma parte substancial da memória residente e do tempo de CPU.

Esta distinção é importante ao planear um servidor sempre ativo. Um ficheiro de modelo de 3,4 GB não deve ser interpretado como significando que 3,4 GB de RAM do sistema são suficientes para toda a máquina. O sistema operativo, o ambiente de execução da inferência, o contexto, as caches, os serviços de armazenamento e quaisquer outras aplicações autoalojadas continuam a precisar de espaço para funcionar.

A vantagem do modelo mais pequeno é, portanto, a necessidade de recursos controlável, e não uma inferência sem consumo de recursos.

Quatro tarefas adequadas para modelos pequenos sempre ativos

Zero to MVP demonstra quatro fluxos de trabalho que partilham uma característica importante: têm limites mais claros do que um assistente geral de finalidade aberta. Isso torna-os bons candidatos a modelos especializados que podem permanecer ativos num servidor doméstico.

1. Converter PDFs digitalizados em Markdown com o GLM-OCR

O primeiro fluxo de trabalho utiliza o GLM-OCR para converter PDFs digitalizados em Markdown. O OCR é um exemplo útil porque o objetivo está bem definido: obter o conteúdo visual de um documento e produzir texto legível por máquina, que possa ser armazenado, pesquisado, indexado, resumido ou processado por outra aplicação.

Quando o OCR passa a ser um serviço do lado do servidor, um fluxo de trabalho não precisa de começar com uma conversa manual com um chatbot. Um documento pode entrar numa pasta, ser processado automaticamente e sair da etapa de OCR como texto estruturado.

Isto é especialmente útil quando o servidor doméstico já armazena os PDFs de origem. O armazenamento e o processamento de documentos podem ocorrer no mesmo ambiente local, em vez de ser necessário carregar repetidamente os ficheiros para um serviço externo.

2. Resumir artigos automaticamente com o Qwen 3.5 4B

O segundo exemplo utiliza o Qwen 3.5 4B para resumir artigos. O resumo ilustra por que motivo a repetição é mais importante do que a inteligência máxima em algumas cargas de trabalho.

Se o objetivo for transformar consistentemente os artigos recebidos em notas mais curtas, um modelo compacto pode tornar-se uma etapa de um pipeline automatizado:

Receba ou guarde um artigo.
Extraia o texto.
Envie o texto para o modelo local.
Gere um resumo mais curto.
Guarde o resultado para leitura, indexação ou pesquisa posterior.

Para este tipo de fluxo de trabalho, a disponibilidade é importante. Um modelo pequeno que já esteja a funcionar localmente pode processar tarefas repetidas sem exigir que alguém abra manualmente uma interface de IA para cada documento.

3. Mantenha as informações relacionadas com a saúde localmente com o MedGemma

A Zero to MVP também demonstra o MedGemma como assistente local privado para informações relacionadas com a saúde. A principal vantagem aqui não é simplesmente o tamanho do modelo. É o local onde os dados são processados.

Manter a inferência num equipamento sob o controlo do utilizador pode reduzir a necessidade de enviar documentos pessoais para um chatbot remoto para tarefas rotineiras de organização, extração ou resumo.

Isso não transforma um modelo local num médico. Os resultados do modelo podem estar incompletos, imprecisos ou ser enganadores, e as decisões relacionadas com a saúde devem continuar a ser tomadas com profissionais de saúde qualificados. O papel útil do modelo local é servir como ferramenta de processamento de informação, sobretudo quando a privacidade é uma parte importante do fluxo de trabalho.

4. Execute a tradução automática com o Qwen 3.5 4B

A demonstração de tradução mostra talvez o exemplo mais claro de um modelo pequeno a funcionar como serviço em segundo plano. Em vez de tratar a tradução como uma sessão de chat, o fluxo de trabalho pode ser organizado em torno de ficheiros e pastas.

O exemplo da Zero to MVP mostra um diretório de tradução no servidor local, com pastas de entrada e de saída separadas. Um ficheiro de texto em japonês pode então ser consultado como resultado desse fluxo de processamento.

ficheiro de texto em japonês apresentado numa pasta de tradução no servidor doméstico zimacube2-local

É aberto um ficheiro de texto traduzido do japonês a partir do zimacube2-local servidor, com diretórios de entrada e de saída separados visíveis atrás dele, como parte do fluxo de trabalho de tradução baseado em ficheiros.

A tradução é especialmente adequada à especialização, porque tanto a entrada como o resultado esperado são restritos. Se o objetivo for traduzir repetidamente documentos para um idioma de destino conhecido, o sistema poderá não precisar do modelo de raciocínio mais abrangente possível para todos os pedidos.

Por que motivo a ZimaCube 2 é adequada para este tipo de IA em segundo plano

O modelo é apenas uma camada de um fluxo de trabalho sempre ligado. O servidor também precisa de armazenar ficheiros de origem, manter as aplicações em execução, disponibilizar esses serviços a outros dispositivos e continuar a ser prático de operar durante longos períodos.

A Zero to MVP descreve a sua ZimaCube 2 como um sistema sempre ligado, com baixo consumo de energia, bastante capacidade de armazenamento para os dados processados pelos seus modelos e funcionamento silencioso, adequado a uma utilização contínua.

Esta combinação é particularmente relevante para fluxos de trabalho com modelos pequenos, porque o serviço de IA pode ficar junto dos ficheiros de que necessita. PDFs que aguardam OCR, artigos que aguardam resumos, documentos privados e trabalhos de tradução podem permanecer no mesmo ambiente de servidor doméstico que executa os modelos.

O ZimaCube 2 também proporciona um caminho de expansão para os utilizadores cujas cargas de trabalho de IA cresçam mais tarde. Assim, é possível começar com inferência local mais leve e adicionar hardware acelerador quando um modelo maior ou um débito mais elevado justificarem o consumo de energia e o custo adicionais.

Para uma análise mais aprofundada desta abordagem de expansão, consulte o guia da ZimaSpace sobre a IA local do ZimaCube 2, que explora o Ollama, a expansão PCIe e o percurso de atualização de cargas de trabalho baseadas no CPU para inferência assistida por GPU.

Os modelos pequenos funcionam melhor como trabalhadores em segundo plano

As quatro demonstrações apontam para um padrão de conceção mais abrangente. Um modelo pequeno torna-se especialmente valioso quando os utilizadores deixam de lhe pedir que funcione como um assistente universal e, em vez disso, o integram num processo específico.

Esse processo pode ser semelhante a:

Observar: monitorizar uma pasta ou aplicação à procura de novas entradas.
Processar: enviar a entrada para um modelo escolhido para essa tarefa.
Validar: verificar se o resultado tem a estrutura ou a qualidade esperadas.
Armazenar: guardar o resultado novamente no servidor local.
Repetir: manter o serviço disponível para o pedido seguinte.

É por isso que a expressão “IA 24/7” não significa necessariamente gerar tokens continuamente. Pode significar ter vários serviços leves prontos sempre que surge um novo documento, artigo ou trabalho de tradução.

Quando deve escolher um modelo de linguagem pequeno?

Perto do final do vídeo, Zero to MVP resume seis condições em que os modelos pequenos são especialmente vantajosos. Em conjunto, fornecem um quadro de decisão útil para escolher entre um modelo local compacto e uma alternativa maior.

Slide que apresenta seis benefícios dos modelos de IA pequenos, incluindo privacidade, utilização offline, hardware de baixo consumo, pedidos simples, custos mais baixos e especialização

Zero to MVP resume seis situações em que os modelos pequenos são especialmente úteis: processamento local e privado, funcionamento offline, hardware de baixo consumo, muitos pedidos simples, minimização de custos e especialização.

Os modelos pequenos são especialmente úteis quando...	Porque é importante
O processamento local e privado é importante	Os dados podem permanecer num fluxo de trabalho autoalojado, em vez de serem enviados para um modelo remoto a cada pedido.
Não existe ligação à Internet	Um modelo disponível localmente pode continuar a processar tarefas compatíveis sem depender de um endpoint de inferência na nuvem.
O hardware tem recursos limitados	Ficheiros de modelos mais pequenos e requisitos de execução mais modestos podem tornar a inferência local prática em sistemas menos potentes.
Existem muitos pedidos simples	Um modelo persistente pode executar repetidamente uma operação específica sem utilizar um modelo muito maior em cada tarefa.
É necessário minimizar os custos	A utilização de hardware local para cargas de trabalho repetitivas pode reduzir a dependência de serviços de inferência alojados cobrados por pedido, embora a eletricidade e o hardware continuem a ter custos.
A tarefa pode ser especializada	Um modelo selecionado para uma tarefa específica não precisa de executar igualmente bem todas as categorias de raciocínio.

O que esta experiência mostra — e o que não mostra

A demonstração mostra	Não garante
Os modelos locais úteis podem ocupar apenas alguns gigabytes no disco.	Um modelo de 2–4 GB requer apenas 2–4 GB de memória total do sistema durante a execução.
Os modelos pequenos podem executar OCR, sumarização, tradução e outras tarefas específicas.	Um modelo compacto terá um desempenho equivalente ao de um modelo muito maior em qualquer pedido complexo ou aberto.
Vários modelos especializados podem coexistir num único servidor local.	Todos os modelos têm de permanecer simultaneamente carregados na memória.
Os fluxos de trabalho de IA baseados em ficheiros podem funcionar sem pedidos manuais constantes.	Todas as respostas geradas terão precisão suficiente para serem utilizadas sem revisão.
O processamento local pode reduzir a exposição desnecessária de dados externos.	Uma implementação local é automaticamente segura simplesmente por funcionar em casa.
Os modelos pequenos podem reduzir os requisitos de hardware para uma IA local útil.	As GPUs grandes e os modelos maiores já não têm lugar em cargas de trabalho exigentes.

Pense em tarefas, não em classificações de modelos

A lição mais útil da experiência da Zero to MVP não é que os modelos pequenos são melhores do que os modelos grandes. É que a seleção do modelo deve começar pela tarefa.

Se a tarefa exigir raciocínio difícil em domínios desconhecidos, programação complexa ou interação altamente aberta, um modelo maior pode justificar os recursos adicionais necessários. Mas, se a tarefa for OCR, sumarização previsível, tradução rotineira, classificação, extração ou outra operação repetida, um modelo especializado mais pequeno pode ser a opção mais prática.

A pergunta fundamental muda de “Qual é o modelo mais inteligente que consigo executar?” para “Qual é o modelo mais pequeno que conclui de forma fiável esta tarefa específica?”

Esta abordagem pode tornar um servidor doméstico sempre ativo muito mais útil. Em vez de esperar que um utilizador inicie uma sessão de IA, o servidor pode processar silenciosamente ficheiros e pedidos como parte da infraestrutura que já está em execução.

Crie um espaço de trabalho de IA local sempre ativo

A configuração do Zero to MVP demonstra como o armazenamento e a IA podem complementar-se. O NAS armazena a informação, enquanto os modelos locais pequenos fornecem processamento especializado junto desses dados.

Com um sistema como o ZimaCube 2, a mesma máquina pode funcionar como uma plataforma de armazenamento doméstico, um servidor de aplicações autoalojadas e a base para fluxos de trabalho de IA persistentes. Os utilizadores podem começar com modelos mais pequenos e expandir o hardware mais tarde, caso os seus requisitos evoluam para modelos maiores ou inferência assistida por GPU mais rápida.

Se está a explorar como o armazenamento e a inteligência local podem funcionar em conjunto, o guia da ZimaSpace sobre fluxos de trabalho de NAS com IA mostra outra abordagem para combinar o armazenamento de documentos, a indexação e o processamento local de IA no ZimaCube 2.

Também pode consultar o guia de configuração de GPU para IA local se a sua carga de trabalho ultrapassar os modelos compactos e quiser compreender como o ZimaCube 2 pode evoluir para inferência assistida por GPU.

Veja o vídeo completo do Zero to MVP para ver os fluxos de trabalho de OCR, sumarização, MedGemma e tradução em contexto e conhecer os critérios que utiliza para decidir quando um modelo pequeno é a ferramenta certa.

Quer comparar fluxos de trabalho de IA local, opções de modelos e configurações de servidores autoalojados com outros utilizadores? Junte-se à comunidade ZimaSpace no Discord para explorar mais projetos de servidores domésticos e de IA local.