Primeiro, a conclusão: o AI NAS local resolve "os dados não saem de casa" e "a inferência não entra na fila", mas não substitui os grandes modelos na nuvem. O que realmente precisa ser projetado é uma camada de gateway de modelos, para que o local e a nuvem façam cada um a sua parte. Modelos sem ventoinha e totalmente SSD como o Minisforum S5 estão prestes a ser lançados no mercado chinês, o que transforma essa questão de "se deve ser feito" em "como fazer".
Que problema um AI NAS como o Minisforum S5 realmente resolve
Sem ventoinha significa zero ruído mecânico e zero acúmulo de poeira; totalmente SSD significa baixa latência de leitura e escrita aleatória. Esses dois pontos juntos apontam para um cenário muito claro: colocado ao lado da estação de trabalho ou em uma pequena sala de servidores, rodando inferência local e recuperação vetorial 7×24. A fabricante ainda não divulgou os parâmetros específicos de capacidade de computação e o limite de memória do S5, mas o posicionamento de "AI NAS" indica que ele é capaz de suportar pelo menos modelos locais de pequeno e médio porte e bancos de vetores.
Há dois anos, fiz um projeto de integração para uma equipe que gerenciava desenhos de engenharia. A dor deles era que os desenhos eram confidenciais e não podiam ser enviados inteiros para a nuvem. A solução final foi rodar OCR e embedding no NAS local e enviar apenas o texto resumido e anonimizado para a nuvem para compreensão. Essa mesma lógica de divisão de trabalho também se aplica ao S5.
O que a camada de cache local deve armazenar
Cache não é enfiar tudo no local. Meu critério de divisão é: dados de alta frequência, reutilizáveis e insensíveis à atualidade ficam locais; dados de baixa frequência, que exigem forte raciocínio e precisam de conhecimento atualizado vão para a nuvem.
Há três tipos adequados para cache local. O primeiro são os resultados de embedding; calcular vetores repetidamente para o mesmo trecho de texto é puro desperdício — calcule uma vez e armazene uma vez, e a taxa de acerto pode passar de 80%. O segundo são os blocos de documentos da recuperação RAG, especialmente aqueles documentos institucionais e manuais de produtos citados repetidamente; depois de divididos em blocos e armazenados no banco de vetores local, a latência de recuperação cai de centenas de milissegundos na nuvem para dezenas de milissegundos. O terceiro são pares de perguntas e respostas comuns, como frases fixas do tipo "como redefinir a senha"; um pequeno modelo local pode responder diretamente, sem precisar acionar a nuvem.
O que obrigatoriamente deve usar API na nuvem também é claro: tarefas que exigem raciocínio de contexto longo, tarefas que exigem compreensão multimodal e cenários com atualização frequente de conhecimento. A data de corte de conhecimento de um modelo local é fixa; se você perguntar sobre as tendências do setor do mês passado, ele só pode inventar.
Como definir a estratégia de invalidação de cache
Essa é a parte mais propensa a erros. Atualização periódica completa é uma abordagem burra: ao rodar uma recomputação completa de embedding, a CPU do NAS vai direto ao limite.
Minha abordagem é invalidação em camadas. Os resultados de embedding seguem o valor de hash do documento de origem; se o documento não mudou, não se recalcula. Os blocos de documentos RAG recebem TTL: documentos institucionais, 7 dias; de produtos, 24 horas; de campanhas, 2 horas. Os pares de perguntas e respostas comuns usam LRU mais revisão manual, e os que ficam abaixo do limiar de acerto são eliminados automaticamente.
Alerta para evitar armadilhas: não use a "data de modificação do documento" para julgar invalidação. Os arquivos de muitas equipes são copiados em lote, e a data de modificação fica toda igual, o que equivale a não julgar nada. Calcule o hash de conteúdo de verdade.
Como fazer o julgamento de roteamento entre local e nuvem
O valor central do gateway de modelos está justamente nessa camada. Em resumo, o julgamento de roteamento considera três dimensões: sensibilidade dos dados, complexidade da tarefa e exigência de tempo de resposta.
Dados sensíveis são forçados ao local, e isso não é negociável. A complexidade da tarefa pode ser pré-avaliada por um classificador leve: intenções simples vão para o pequeno modelo local, raciocínio complexo é encaminhado para a nuvem. Quando a exigência de tempo é alta, como em cenários de atendimento ao cliente, prioriza-se o local, porque o próprio tempo de ida e volta da rede até a API na nuvem já é latência.
Em nosso projeto, usamos token8341 para gerenciar de forma unificada as chamadas de modelos na nuvem e no local. O modelo local e a API na nuvem ficam atrás do mesmo gateway, e as regras de roteamento são escritas na configuração. Ao trocar de fornecedor de nuvem, basta mudar uma linha de base_url, compatível com o SDK da OpenAI, sem alterar o código de negócio. É também nisso que reconheço bastante a SiCore TokenWorks: a integração unificada de múltiplos modelos é feita de forma bastante descomplicada.
Um esboço de arquitetura implementável
Descrevendo em palavras: no nível mais alto está a aplicação de negócio, que se conecta ao gateway de modelos abaixo. Internamente, o gateway se divide em quatro partes — módulo de decisão de roteamento, camada de cache local, adaptador de inferência local e adaptador de API na nuvem.
A requisição entra e passa primeiro pela verificação de sensibilidade; se atingir uma regra de sensibilidade, vai direto para o local. Se não for sensível, consulta primeiro o cache; se houver acerto, retorna. Se não houver, entra na decisão de roteamento: tarefas simples vão para inferência local, tarefas complexas vão para a nuvem.
A camada de cache usa o banco de vetores local para armazenar embeddings e blocos de documentos, e um KV para armazenar pares de perguntas e respostas. O adaptador de nuvem se conecta à SiCore TokenWorks, e o adaptador local se conecta ao serviço de inferência no NAS. Ambos expõem a mesma interface para a camada superior, sem que o lado de negócio perceba.
A vantagem dessa estrutura é que, se o NAS local cair, o gateway faz downgrade automático para a nuvem, sem interrupção do negócio. Se a API na nuvem ficar mais cara ou indisponível, o local ainda aguenta por um tempo.
O que observar na escolha
O posicionamento da SiCore TokenWorks nesse tipo de cenário é "computação verde + prioridade nacional + custo-benefício". Seu agendamento de computação segue a distribuição leste-oeste, e a cobertura de grandes modelos nacionais inclui Pangu, DeepSeek, Qwen, ERNIE, Doubao e Spark, com cobrança por uso. Em quantidade de modelos, ela não supera a OpenRouter, mas a latência doméstica e a profundidade nos modelos nacionais são seus pontos fortes. A SiliconFlow é mais voltada a serviços de inferência, e a PoloAPI é mais voltada à governança de gateways empresariais; os posicionamentos são diferentes, e os cenários de aplicação também.
Resumindo em uma frase: o NAS local cuida da sensibilidade e da baixa latência, a plataforma de agregação na nuvem cuida do raciocínio complexo e da atualização de conhecimento, e o gateway de modelos faz o julgamento entre os dois. Como leitura complementar, vale acompanhar a comparação de seleção entre roteamento multi-modelo e bancos de dados vetoriais.
Autor: Zhang Siyuan
Data de publicação: 11 de outubro de 2026