KINGAI OS AI Workstation | Edição estação de trabalho de IA

Posicionamento

A AI Workstation é voltada a quem roda desenvolvimento de modelos e fluxos de trabalho com GPU localmente, com a capacidade de computação e os dados na própria máquina. Ainda está na fase de planejamento; esta página é a direção de design, não uma lista de funções.

Direção de design

• Runtimes de GPU (NVIDIA, AMD, Intel) só entram na lista de suporte depois de aprovados em testes em máquinas reais; não se promete antes
• Os modelos são instalados pelo próprio usuário, que gerencia a origem e as licenças; o sistema não pré-instala modelos
• Agentes rodam em ambientes isolados rootless, com permissões autorizadas separadamente
• Painel de status do hardware e da memória de vídeo e áreas de trabalho utilizáveis off-line (em planejamento)

Ver o roteiro das quatro edições → Ver antes a edição desktop já lançada →

Posicionamento: os modelos rodam localmente e quem decide é o usuário

A AI Workstation está sendo preparada para um grupo específico: quem precisa desenvolver, depurar e rodar modelos grandes localmente — sem querer que os dados saiam da máquina, querendo fazer as contas do custo de computação por conta própria e sem querer que o fluxo de trabalho fique preso à interface de alguma plataforma de nuvem. A descrição do público-alvo no catálogo oficial é muito clara: desenvolvimento local de modelos controlado pelo usuário, e fluxos de trabalho de IA com GPU.

Esta edição tem um princípio que a atravessa do início ao fim, e que merece destaque: a IA é opcional, não é a autoridade do sistema. O sistema não pré-instala modelos, não se vincula a nenhum provedor de modelos e, muito menos, permite que algum componente de agente fique acima das permissões do usuário. Qual modelo instalar, de onde baixá-lo, se a licença está em conformidade e qual runtime usar — tudo é decidido e assumido pelo próprio usuário. O que o sistema precisa fazer é construir de verdade, primeiro, três peças de infraestrutura: o ambiente, o isolamento e a visibilidade de status.

Capacidades planejadas, uma a uma

Runtime de GPU: só entra na lista de suporte depois de testado

Os runtimes de GPU de NVIDIA, AMD e Intel estão todos no planejamento, mas o critério é only when tested — um modelo, em uma versão de kernel, testado em uma máquina real, entra na lista de compatibilidade; o que não foi testado não é prometido em uma única palavra. Esse é o mais duro dos quatro requisitos de lançamento, porque os problemas de drivers de GPU só aparecem, sempre, em máquinas reais.

Matriz de compatibilidade de drivers

Reunir em uma tabela consultável as combinações validadas de «qual placa, qual versão de driver, qual kernel». Antes de comprar uma placa, consulte a tabela — em vez de descobrir, depois de instalar, que o driver não confere. Essa tabela não existe hoje; ela espera os dados de testes reais se acumularem.

Modelos instalados pelo usuário, com origem rastreável

Tanto modelos locais quanto provedores de API em nuvem são conectados pelo próprio usuário. O registro de origem (provenance) dos modelos, em planejamento, existe para que você consiga responder, no futuro, «de onde veio este arquivo de modelo na época e qual é a sua licença» — e não para o sistema decidir isso por você.

Execução de agentes em isolamento rootless

Os agentes rodam em um ambiente isolado rootless, com permissões concedidas separadamente conforme a necessidade, e a fuga da sandbox precisa passar por testes negativos — tentar deliberadamente romper o isolamento e só considerar aprovado se não conseguir. A premissa para dar capacidade de execução local a ferramentas de IA é que elas não consigam sair do círculo que você mesmo delimitou para elas.

Painel de status do hardware e da memória de vídeo

Indicadores como utilização da GPU, ocupação da memória de vídeo e temperatura precisam ser visíveis de imediato. Ao rodar tarefas longas de inferência, ver a memória de vídeo quase cheia antes é muito melhor do que a tarefa ser encerrada silenciosamente no meio da noite. O controle de cotas também está no planejamento, para definir limites de recursos para tarefas longas — a forma concreta será decidida na fase de implementação.

Áreas de trabalho off-line e controles de privacidade

As áreas de trabalho precisam ser utilizáveis off-line: sem rede, o código a escrever e a inferência local a rodar não param. A direção dos controles de privacidade é que o usuário saiba com clareza quais dados cada componente pode acessar, e não depender de uma mera declaração.

Requisitos de lançamento: sem passar em cinco testes, não há ISO

• Validar a compatibilidade item por item, por modelo real de GPU e versão de kernel
• Testes de licenças e jurídicos dos modelos — os limites de redistribuição e de uso dos arquivos de modelo precisam ser esclarecidos primeiro
• Testes de limites de consentimento — antes de qualquer dado sair desta máquina, é preciso uma ação expressa de consentimento do usuário
• Estabilidade térmica e de memória de vídeo — rodar por muito tempo em carga máxima sem reduzir a frequência e travar, e sem estourar a memória de vídeo
• Testes negativos de fuga de sandbox — o mecanismo de isolamento precisa resistir a tentativas ativas de ataque e de fuga

Progresso atual, com franqueza

Publicamente: planned, sem número de versão, sem ISO. As palavras do catálogo oficial: não se afirma suporte a GPU/drivers, nem se afirmam runtimes de modelos pré-instalados. Na linha experimental interna, há um registro de compilação experimental amd64, na direção de um ambiente de desenvolvimento KDE sobre Debian 13, expressamente sem compromissos de modelos e de drivers; a imagem não foi conservada e não foi feita validação de inicialização por firmware. Entre ela e «poder instalar na sua estação de trabalho e rodar modelos» há toda a lista de requisitos acima; esta página não comemora por ela antecipadamente.

Ver o roteiro das quatro edições → Ver antes a prévia da edição desktop já lançada → Ir para a central de downloads → Acompanhar o progresso nas Issues →