Windows on kenji.blog

Casos de Uso da API Recente e Códigos de Exemplo do Microsoft.Windows.AI

Fri, 11 Sep 2026 18:00:00 +0900

Casos de Uso da API Recente e Códigos de Exemplo do Microsoft.Windows.AI: Explorando as Profundezas do Windows Copilot Runtime

1. Introdução: A Nova Era do Windows com IA Integrada Nativamente

Nos últimos anos, a evolução da tecnologia de IA tem sido notável, com uma rápida mudança de paradigma do uso de Grandes Modelos de Linguagem (LLM) na nuvem para a inferência de IA em dispositivos edge (PCs locais). O núcleo disso é o “Windows Copilot Runtime” fornecido pela Microsoft para o Windows 11 e a API “Microsoft.Windows.AI” para controlá-lo.

O desenvolvimento de aplicativos usando APIs em nuvem (como OpenAI ou Azure OpenAI) é fácil, mas traz desafios como latência, privacidade e custos contínuos. Por outro lado, a execução de modelos de IA localmente permite obter aplicativos de latência ultrabaixa que funcionam offline sem enviar dados confidenciais para fora do dispositivo.

Neste artigo, explicaremos detalhadamente e de forma abrangente, da arquitetura ao ajuste de desempenho, os métodos de implementação de recursos de IA local, que serão essenciais no desenvolvimento de aplicativos para Windows, juntamente com exemplos de código prático em C# e C++. Além de simplesmente chamar a API, nos aprofundaremos em detalhes técnicos avançados, como a utilização de hardware subjacente (NPU e GPU) e a integração com o DirectML.

2. Windows Copilot Runtime e a Visão Geral da Arquitetura

O Windows Copilot Runtime é uma pilha de IA projetada para permitir que os desenvolvedores integrem facilmente modelos de IA no Windows e extraiam o melhor desempenho. Este runtime abstrai a aceleração de hardware no nível do sistema operacional e fornece uma interface unificada para os desenvolvedores.

graph TD App["Aplicativo Windows (C# / C++)"] --> API["APIs Microsoft.Windows.AI"] App --> ORT["ONNX Runtime"] API --> WCR["Windows Copilot Runtime (Camada do SO)"] WCR --> SLM["Modelos Locais (Phi-Silica, etc.)"] ORT --> DML["Provedor de Execução DirectML"] SLM --> DML DML --> DXCore["DXCore / DirectX 12"] DXCore --> NPU["NPU (Unidade de Processamento Neural)"] DXCore --> GPU["GPU (Unidade de Processamento Gráfico)"] DXCore --> CPU["CPU"]

Como o diagrama de arquitetura acima mostra, ao usar a API de alto nível Microsoft.Windows.AI, o aplicativo pode acessar diretamente Pequenos Modelos de Linguagem (SLM: como o Phi-Silica) integrados ao sistema operacional. Além disso, ao usar um modelo personalizado, a aceleração de hardware pode ser explicitamente utilizada via ONNX Runtime e DirectML. Como a camada do sistema operacional otimiza a distribuição da carga de trabalho para CPU, GPU e NPU, os desenvolvedores podem construir aplicativos de IA de alto desempenho sem se preocupar profundamente com as diferenças de hardware.

3. Aceleração de Hardware e Avaliação Matemática da NPU

Os mais recentes Copilot+ PCs são equipados com a NPU (Unidade de Processamento Neural), um processador especializado em processamento de IA. O desempenho da NPU é geralmente avaliado em TOPS (Tera Operations Per Second).

Na inferência de modelos de IA, a capacidade de cálculo, especialmente de multiplicação de matrizes (GEMM: General Matrix Multiply), determina a taxa de transferência (throughput). O desempenho máximo teórico do hardware $P_{\text{peak}}$ é estimado pela seguinte fórmula:

$$ P_{\text{peak}} = f \times N_{\text{cores}} \times N_{\text{MACs/core}} \times 2 $$

Onde:

$f$ é a frequência de clock da NPU (Hz)
$N_{\text{cores}}$ é o número de núcleos dentro da NPU
$N_{\text{MACs/core}}$ é o número de unidades MAC (Multiply-Accumulate) por núcleo
O último $2$ ocorre porque uma única operação MAC é contada como duas operações (FLOPs/OPs) de multiplicação e adição.

Por exemplo, para uma NPU com frequência de 1,5 GHz, 4 núcleos e cada núcleo tendo 4096 MACs:

$$ P_{\text{peak}} = 1.5 \times 10^9 \times 4 \times 4096 \times 2 \approx 49.15 \text{ TOPS} $$

Isso demonstra matematicamente que atende ao requisito de 40 TOPS para os Copilot+ PCs com Windows 11.

Além disso, a inferência (fase de decodificação) de modelos de IA, especialmente LLMs, tende a ser limitada pela memória (Memory-Bound). A largura de banda teórica $BW$ da memória do sistema é calculada da seguinte forma:

$$ BW = f_{\text{mem}} \times W_{\text{bus}} \times \frac{2}{8} $$

Para memória LPDDR5x-8533 ($f_{\text{mem}} = 8533 \text{ MT/s}$) e um barramento de 128 bits ($W_{\text{bus}} = 128$), a largura de banda é de aproximadamente $136 \text{ GB/s}$. Na otimização de aplicativos de IA, a forma de economizar essa largura de banda é muito importante, tornando a quantização (Quantization) de modelos, que será discutida mais adiante, essencial.

4. Configuração do Ambiente de Desenvolvimento

Para usar a API de IA mais recente do Windows, é necessário configurar o seguinte ambiente e conjunto de ferramentas:

SO: Windows 11 Versão 24H2 ou posterior (Altamente recomendado um dispositivo equipado com NPU que atenda aos requisitos do Copilot+ PC)
SDK: Windows App SDK (versão compatível com a extensão de IA, v1.5 ou posterior)
Ambiente de Desenvolvimento: Visual Studio 2022 (v17.10 ou posterior), carga de trabalho de desenvolvimento nativo com C++ e carga de trabalho de desenvolvimento para desktop .NET
Pacotes: Instalar Microsoft.Windows.AI e Microsoft.ML.OnnxRuntime.DirectML via NuGet

1
2
3
4
5
6


<!-- Exemplo de configuração do .csproj -->
<ItemGroup>
 <PackageReference Include="Microsoft.Windows.AI" Version="1.0.0-preview1" />
 <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.5.240311000" />
 <PackageReference Include="Microsoft.ML.OnnxRuntime.DirectML" Version="1.17.1" />
</ItemGroup>

5. [Deep Dive 1] Utilizando o Modelo de Linguagem Local (Phi-Silica) com C#

O Windows Copilot Runtime inclui o “Phi-Silica”, um modelo de linguagem de pequena escala e alta eficiência desenvolvido pela Microsoft, como um componente padrão do sistema operacional. Isso permite o processamento avançado de linguagem natural (resumo de textos, geração de código, chatbots) em um ambiente offline, sem precisar baixar modelos do tamanho de GB pela rede.

Abaixo está um exemplo de código avançado para construir uma IA de bate-papo em C# usando o namespace Microsoft.Windows.AI.Generative. Ele suporta respostas em streaming e gera texto em tempo real sem bloquear a thread da UI.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84


using System;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Windows.AI.Generative;

namespace WindowsAI.Sample
{
 public class LocalLanguageModelService
 {
 private LanguageModel _languageModel;
 private bool _isInitialized = false;

 /// <summary>
 /// Inicializa o modelo de linguagem. Verifica a disponibilidade da NPU e carrega o modelo no dispositivo ideal.
 /// </summary>
 public async Task InitializeAsync()
 {
 if (_isInitialized) return;

 Console.WriteLine("Verificando os requisitos do sistema e a disponibilidade do modelo de IA local (Phi-Silica)...");

 // Verifica se o modelo está disponível no sistema (pode solicitar o download caso não seja suportado)
 var availability = await LanguageModel.CheckAvailabilityAsync();
 if (availability != LanguageModelAvailability.Available)
 {
 throw new InvalidOperationException($"O modelo de IA local não está disponível no momento. Estado: {availability}");
 }

 // Cria a instância do modelo (neste momento, o mapeamento para o espaço de memória e a inicialização da NPU ocorrem)
 _languageModel = await LanguageModel.CreateAsync();
 _isInitialized = true;

 Console.WriteLine("Inicialização do modelo de linguagem concluída. A aceleração de hardware via DirectML está ativa.");
 }

 /// <summary>
 /// Recebe o prompt do usuário e gera uma resposta em streaming.
 /// </summary>
 public async Task GenerateResponseStreamAsync(string prompt, CancellationToken cancellationToken)
 {
 if (!_isInitialized) await InitializeAsync();

 Console.WriteLine($"\n[Entrada do Usuário]: {prompt}\n[Assistente de IA]: ");

 // Configura os hiperparâmetros de geração
 var options = new LanguageModelOptions
 {
 Temperature = 0.7f,
 TopP = 0.9f,
 MaxTokens = 2048,
 RepetitionPenalty = 1.1f
 };

 // Constrói o contexto da conversa
 var context = new LanguageModelContext();
 context.AddSystemMessage("Você é um assistente de IA avançado que funciona diretamente na NPU local do Windows. Pense logicamente passo a passo e responda de forma concisa.");
 context.AddUserMessage(prompt);

 try
 {
 // Chama a API de inferência em streaming
 var responseStream = _languageModel.GenerateResponseStreamAsync(context, options);

 // Itera de forma assíncrona sobre os fragmentos (chunks) retornados como IAsyncEnumerable
 await foreach (var chunk in responseStream.WithCancellation(cancellationToken))
 {
 // Exibe os tokens gerados (chunks) no console em tempo real
 // Em um aplicativo de UI, o DispatcherQueue seria usado aqui para refletir em um TextBox, etc.
 Console.Write(chunk.Text);
 }
 Console.WriteLine();
 }
 catch (OperationCanceledException)
 {
 Console.WriteLine("\n[A geração foi cancelada pelo usuário ou pelo sistema]");
 }
 catch (Exception ex)
 {
 Console.WriteLine($"\n[Ocorreu um erro fatal: {ex.Message}]");
 }
 }
 }
}

5.1 Explicação da Arquitetura na Implementação em C#

O núcleo deste código é a validação pré-execução usando LanguageModel.CheckAvailabilityAsync() e o streaming assíncrono através do GenerateResponseStreamAsync. Quando o Copilot Runtime operando em segundo plano no sistema operacional recebe essa chamada de API, ele invoca internamente o ONNX Runtime e seleciona o Provedor de Execução ideal (DirectML + NPU em muitos dos PCs mais recentes) dependendo da configuração do sistema.

Os desenvolvedores podem integrar pipelines de inferência de IA de última geração em seus aplicativos com apenas algumas linhas de código em C#, sem a necessidade de se preocuparem com o formato dos tensores do modelo, a implementação do tokenizador ou a gestão da memória de cache KV.

6. [Deep Dive 2] Inferência de Alta Velocidade de Modelos Personalizados com C++ e DirectML

Ao lidar com domínios específicos (segmentação de imagens própria, reconhecimento de fala, modelos personalizados de detecção de objetos, etc.) que não podem ser cobertos apenas pelo modelo de linguagem padrão do sistema operacional, os desenvolvedores precisarão manipular diretamente o ONNX Runtime e o DirectML, que estão nas camadas inferiores do Microsoft.Windows.AI.

O uso de C++ permite otimizar a alocação de memória ao máximo e extrair o pico de desempenho da NPU/GPU. Abaixo está a implementação principal de um pipeline avançado de inicialização e inferência para executar um modelo personalizado no formato ONNX (ex: YOLOv8) em C++ usando DirectML.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99


#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>
#include <onnxruntime_cxx_api.h>
#include <dml_provider_factory.h>

class CustomVisionAIProcessor {
private:
 Ort::Env env;
 Ort::Session session{nullptr};
 Ort::AllocatorWithDefaultOptions allocator;

public:
 CustomVisionAIProcessor(const std::wstring& modelPath)
 : env(ORT_LOGGING_LEVEL_WARNING, "VisionAIProcessor") {

 Ort::SessionOptions sessionOptions;
 // Otimização do número de threads
 sessionOptions.SetIntraOpNumThreads(1);
 // Define o nível de otimização do gráfico para o máximo
 sessionOptions.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

 // 1. Adição do Provedor de Execução DirectML (DML EP)
 // device_id = 0 é o adaptador padrão recomendado pelo sistema (NPU ou GPU de alto desempenho)
 const OrtApi& ortApi = Ort::GetApi();
 OrtDmlApi* dmlApi = nullptr;
 OrtStatus* status = ortApi.GetExecutionProviderApi("DML", ORT_API_VERSION, reinterpret_cast<void**>(&dmlApi));

 if (status == nullptr && dmlApi != nullptr) {
 Ort::ThrowOnError(dmlApi->SessionOptionsAppendExecutionProvider_DML(sessionOptions, 0));
 std::cout << "[Info] O Provedor de Execução DirectML foi anexado com sucesso." << std::endl;
 } else {
 std::cerr << "[Warning] Falha ao obter a API do DirectML. Executando no modo de fallback da CPU." << std::endl;
 if (status != nullptr) ortApi.ReleaseStatus(status);
 }

 // 2. Carregamento do modelo e criação da sessão
 try {
 session = Ort::Session(env, modelPath.c_str(), sessionOptions);
 std::cout << "[Info] Modelo ONNX carregado com sucesso e o gráfico de computação foi compilado." << std::endl;
 } catch (const Ort::Exception& e) {
 std::cerr << "[Error] Falha ao carregar o modelo: " << e.what() << std::endl;
 throw;
 }
 }

 void RunInference(const std::vector<float>& imageTensor, const std::vector<int64_t>& inputShape) {
 // 3. Criação do buffer para o tensor de entrada
 Ort::MemoryInfo memoryInfo = Ort::MemoryInfo::CreateCpu(OrtArenaAllocator, OrtMemTypeDefault);
 Ort::Value inputTensor = Ort::Value::CreateTensor<float>(
 memoryInfo,
 const_cast<float*>(imageTensor.data()),
 imageTensor.size(),
 inputShape.data(),
 inputShape.size()
 );

 // 4. Obtenção dinâmica dos nomes dos nós de entrada e saída
 auto inputNamePtr = session.GetInputNameAllocated(0, allocator);
 auto outputNamePtr = session.GetOutputNameAllocated(0, allocator);
 const char* inputNames[] = { inputNamePtr.get() };
 const char* outputNames[] = { outputNamePtr.get() };

 // 5. Execução da inferência (descarregada para NPU/GPU via DirectML)
 std::cout << "[Info] Iniciando a execução do motor de inferência..." << std::endl;
 auto startTime = std::chrono::high_resolution_clock::now();

 auto outputTensors = session.Run(Ort::RunOptions{nullptr}, inputNames, &inputTensor, 1, outputNames, 1);

 auto endTime = std::chrono::high_resolution_clock::now();
 auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime);

 // 6. Recuperação e análise dos tensores de resultado
 float* outputData = outputTensors.front().GetTensorMutableData<float>();
 size_t outputSize = outputTensors.front().GetTensorTypeAndShapeInfo().GetElementCount();

 std::cout << "[Result] Inferência concluída: " << duration.count() << " ms" << std::endl;
 std::cout << "[Result] Número de elementos no tensor de saída: " << outputSize << std::endl;
 // *Após isso, a implementação do processamento NMS (Non-Maximum Suppression) e o desenho das caixas delimitadoras (bounding boxes) devem ser feitos no tensor de saída
 }
};

int main() {
 try {
 // Caminho do modelo ONNX a ser executado
 CustomVisionAIProcessor processor(L"models/yolov8n_quantized.onnx");

 // Dados de imagem fictícios para inferência (Tamanho do lote 1 x 3 canais x 640 x 640)
 std::vector<int64_t> inputShape = {1, 3, 640, 640};
 std::vector<float> dummyImage(1 * 3 * 640 * 640, 0.5f);

 processor.RunInference(dummyImage, inputShape);
 } catch (const std::exception& e) {
 std::cerr << "O programa foi encerrado de forma anormal: " << e.what() << std::endl;
 return -1;
 }
 return 0;
}

6.1 A Importância da Gestão de Memória e Inferência Zero-Copy em C++

A maior vantagem de usar o DirectML com C++ é a forte integração com o DirectX 12 (DX12) que isso possibilita. O código acima inclui a cópia de dados da memória da CPU padrão por uma questão didática, mas em aplicações de processamento de vídeo e motores de jogos reais, muitas vezes já existem imagens (texturas) mantidas no espaço de memória da GPU ou NPU via DX12.

Neste caso, usando as características avançadas de vinculação da API OrtDmlApi, você pode alcançar a “Inferência Zero-Copy (Zero-Copy Inference)”, onde recursos DX12 são mapeados diretamente como tensores para o ONNX Runtime. Com isso, o custo indireto de transferência de dados do barramento PCIe (o consumo da largura de banda $BW$ descrito acima) desaparece completamente, resultando em uma melhoria drástica nas taxas de quadros para o processamento de vídeo em tempo real.

7. Otimização de Desempenho e Melhores Práticas

Abaixo estão as estratégias de otimização essenciais para o desenvolvimento de aplicativos de IA de ponta usando a API de IA do Windows e o DirectML.

7.1 Quantização de Modelos (Quantization) e Toolkit Olive

Para extrair o verdadeiro poder da NPU, é uma condição absoluta quantizar (Quantization) os pesos e ativações do modelo de IA de FP32 (ponto flutuante de precisão simples) para INT8 ou INT4. A arquitetura da NPU é especializada em operações com inteiros, o que permite atingir taxas de transferência teoricamente quatro vezes maiores e reduzir drasticamente o consumo de energia em INT8 em comparação com o FP32.

Ao usar a cadeia de ferramentas Olive (ONNX Live) oferecida pela Microsoft, os modelos de IA, como os do PyTorch, podem ser automaticamente otimizados para ambientes Windows. A ferramenta Olive fornece forte suporte para otimizações de atenção especializadas para modelos baseados em Transformers e compilação de gráficos por hardware.

7.2 Trade-off Entre Processamento em Lote e Streaming Interativo

Nas chamadas de API, a utilização da NPU (Compute Utilization) pode ser aumentada combinando múltiplas solicitações de inferência num processamento em lote. No entanto, no caso de IUs interativas, como chatbots, não é a taxa de transferência, mas sim o tempo até que o primeiro token seja gerado (TTFT: Time To First Token) que determina a experiência do usuário (UX). Portanto, as melhores práticas ditam projetar o tamanho de lote (batch size) como 1 em IUs interativas, priorizando a geração de streaming.

7.3 Tarefas em Segundo Plano e Integração com o SO

A inferência de IA consome localmente grandes quantidades de energia e recursos do sistema. Ao cooperar com a App Lifecycle API do Windows, há a necessidade de uma implementação que suspenda (Suspend) as tarefas de inferência de baixa prioridade ou restrinja o consumo de recursos quando o aplicativo for movido para o segundo plano.

sequenceDiagram participant User as "Usuário" participant App as "Aplicativo Windows (C#)" participant API as "Microsoft.Windows.AI" participant OS as "Windows Copilot Runtime" participant ORT as "ONNX Runtime (DML)" participant NPU as "Hardware NPU" User->>App: "Insere o prompt" App->>API: "GenerateResponseStreamAsync()" API->>OS: "Despacha o trabalho de inferência" OS->>ORT: "Solicitação de execução do gráfico" ORT->>NPU: "Execução da lista de comandos via DirectML" NPU-->>ORT: "Cálculo concluído (Geração de 1 token)" ORT-->>OS: "Resultado em tensor" OS-->>API: "Texto decodificado" API-->>App: "Fragmento IAsyncEnumerable" App-->>User: "Desenho em tempo real do texto na UI" Note over ORT,NPU: "Repete esse loop em alta velocidade até ser concluído"

Este diagrama de sequência ilustra a beleza do processamento assíncrono, através do qual os dados fluem em streaming da camada de hardware mais profunda da NPU para a camada de apresentação do aplicativo de forma contínua, sem bloquear a thread de UI de forma alguma.

8. Perspectivas Futuras e a Evolução da IA do Windows

As APIs Microsoft.Windows.AI e o Copilot Runtime estão passando por uma rápida evolução neste exato momento. Nas futuras atualizações para os desenvolvedores, são esperadas as seguintes mudanças de paradigma:

Integração Nativa da API Multimodal no SO: Em vez de apenas texto, a capacidade de processar simultaneamente e de forma contínua áudio, imagens e até transmissões de vídeo ao vivo, fornecendo inferência transversal de IA como um padrão ao nível do SO.
RAG (Retrieval-Augmented Generation) a Nível de Sistema: Uma IA pessoal super avançada construída através da colaboração de um modelo de IA com grupos de documentos pessoais locais e o índice do Windows Search, operando dentro de uma sandbox segura do SO e protegendo completamente a privacidade do usuário.
Dimensionamento Dinâmico de Recursos da NPU: Quando vários aplicativos de IA funcionam simultaneamente (por exemplo, cancelamento de ruído em segundo plano e geração de código em primeiro plano), o escalonador do kernel do Windows alterna os contextos de execução da NPU de forma dinâmica para garantir a Qualidade de Serviço (QoS).

9. Conclusão: O Futuro dos Aplicativos Transformados pela IA Local

O Copilot Runtime do Windows 11 e a API Microsoft.Windows.AI trouxeram uma arma extremamente poderosa chamada “IA Local” para todos os desenvolvedores do Windows. Não há mais a necessidade de depender completamente de APIs em nuvem. É possível eliminar a latência e oferecer uma experiência de IA de última geração que funciona totalmente offline aos usuários, protegendo rigorosamente a sua privacidade.

Pedimos que você utilize os conhecimentos abordados neste artigo sobre a integração do modelo de linguagem padrão do sistema via C#, a avaliação matemática de desempenho e a otimização extrema de hardware usando C++ e DirectML, para criar, com as suas próprias mãos, os próximos aplicativos de Windows “Nativos de IA”. As possibilidades infinitas que a IA traz estão à sua espera, através do código que você escrever.

Aviso Legal: Note que este artigo foi escrito com base nas versões de pré-lançamento da API e especificações mais recentes disponíveis em Setembro de 2026. Como as especificações da API e os requisitos de hardware podem mudar devido às atualizações do Windows, certifique-se de consultar as documentações oficiais da Microsoft Learn ao implementar.

【Atualizado em 2026】Guia Completo para Executar LLM Local em Ambiente Windows

Fri, 11 Sep 2026 10:00:00 +0900

1. Introdução: Por que LLM Local no Windows agora?

Em 2026, a evolução da IA generativa e dos Grandes Modelos de Linguagem (LLM) está mostrando uma grande mudança de paradigma de serviços gigantescos de API na nuvem para “LLMs Locais” rodando em PCs pessoais ou ambientes locais (on-premises). IAs na nuvem como o GPT-5 da OpenAI e o Claude 3.5 da Anthropic são extremamente poderosas, mas nem todas as empresas ou indivíduos podem enviar todos os seus dados para a nuvem. Do ponto de vista de privacidade, segurança, latência e custos sustentáveis a longo prazo, a demanda por LLMs locais explodiu como nunca antes.

Particularmente no ambiente Windows, a evolução do ecossistema de LLM local tem sido notável. Até poucos anos atrás, “Desenvolvimento e execução de IA significa Linux” era o senso comum, mas em 2026, o Windows se transformou em uma plataforma de IA extremamente poderosa e acessível.

Neste artigo, com base nas últimas tendências tecnológicas de 2026, forneceremos um guia completo para construir, operar e otimizar LLMs locais em ambientes Windows. Explicaremos detalhadamente, com um volume esmagador, desde configurações simples com o Ollama para iniciantes, passando por otimizações extremas usando o llama.cpp para usuários avançados, até abordagens matemáticas para cálculo de VRAM, compreensão profunda da arquitetura e fine-tuning local.

1.1 Tendências Tecnológicas de LLM Local em 2026

As principais tendências que moldam o atual ecossistema de LLM local são as seguintes:

Adoção total do formato GGUF: O GGUF (GPT-Generated Unified Format), que integra metadados e tensores em um único arquivo, tornou-se completamente o padrão de fato. Isso permite a execução em qualquer ambiente apenas baixando um único arquivo do Hugging Face.
Democratização da arquitetura MoE (Mixture of Experts): Vários modelos MoE pequenos, porém de alto desempenho, foram lançados. Ao ativar apenas alguns especialistas durante a inferência, eles alcançam um desempenho comparável ao de modelos gigantes, mantendo a carga computacional baixa em PCs de consumo.
Abstração avançada e otimização de motores de inferência: Ferramentas como Ollama, LM Studio e AnythingLLM foram refinadas, eliminando a necessidade de os usuários se preocuparem com dependências complexas, como a instalação de drivers CUDA. Além disso, o suporte nativo do FlashAttention 3 para Windows melhorou drasticamente a velocidade de inferência.
Utilização da NPU e a ascensão dos PCs Windows Copilot+: Mesmo em laptops sem GPU, a tecnologia para executar pequenos LLMs (SLMs: Small Language Models) com baixo consumo de energia usando a NPU (Neural Processing Unit) integrada entrou em fase prática.

2. Requisitos de Hardware e Preparação do SO

Para que um LLM local opere em uma velocidade prática (15 a 30+ tokens por segundo), a escolha do hardware é o fator mais importante.

2.1 Configuração de Hardware Recomendada

Com a evolução dos AI PCs, as especificações exigidas também estão mudando.

SO: Windows 11 Pro (24H2 ou posterior). Essencial para utilizar as funções completas do WSL2, gerenciamento avançado de memória e as APIs mais recentes do DirectML.
CPU: Série Intel Core Ultra 200 ou superior, ou série AMD Ryzen 9000 ou superior. Quando usado em conjunto com inferência de CPU, a comunicação de memória de alta largura de banda é indispensável.
RAM: Mínimo de 32GB, recomendado 64GB ou mais. A largura de banda da memória principal (MB/s) torna-se o gargalo decisivo durante a inferência na CPU ou offloading. Memória de alta velocidade, como DDR5-6000 ou superior, é o ideal.
GPU: Séries NVIDIA RTX 4000/5000. O que mais importa para LLMs locais não é o desempenho de processamento, mas sim a “Capacidade de VRAM”.
- Entrada: RTX 4060 Ti (versão de 16GB) - Melhor custo-benefício. Ideal para modelos na classe de 8B a 14B.
- Intermediário: RTX 4070 Ti SUPER (16GB) / RTX 4080 SUPER (16GB)
- High-end: RTX 4090 (24GB) / RTX 5090 (32GB) - Necessário para rodar modelos quantizados na classe de 30B a 70B.
Armazenamento: NVMe SSD PCIe Gen4 ou Gen5. Reduz drasticamente o tempo de carregamento de dezenas de GB de modelos.

2.2 Configuração do WSL2 (Windows Subsystem for Linux 2)

Embora muitas ferramentas GUI funcionem nativamente no Windows, o WSL2 é extremamente útil para desenvolvimento com Python, compilação de ferramentas mais recentes e para o fine-tuning LoRA mencionado posteriormente. Nos ambientes Windows 11 mais recentes, você pode usar GPUs (CUDA) de forma transparente no WSL2 apenas instalando o driver da NVIDIA no host.

Abra o PowerShell com privilégios de administrador e execute o seguinte:

1
2
3
4
5


# Instalação do WSL2 e do Ubuntu mais recente
wsl --install -d Ubuntu-24.04

# Atualização do kernel
wsl --update

Após a instalação, execute nvidia-smi no terminal do WSL2; se a GPU for reconhecida corretamente, a configuração foi bem-sucedida.

3. Arquitetura de LLM Local e Mecanismo de Inferência

Compreender a estrutura interna de como o modelo gera texto em um ambiente local é extremamente útil para solução de problemas e otimização.

O diagrama Mermaid abaixo mostra um pipeline típico de inferência de LLM local.

graph TD User["Entrada do usuário (Prompt)"] --> Tokenizer["Tokenizador (Tokenizer)"] Tokenizer --> Embedding["Camada de Embedding (Embedding)"] subgraph "Transformer Block (x Layers)" Embedding --> Attn["Autoatenção (Self-Attention)"] Attn --> KVCache["Cache KV (Retenção Key/Value)"] Attn --> FFN["Rede Feed-Forward (FFN)"] end FFN --> Logits["Cálculo de Logits (Logits)"] Logits --> Sampler["Amostrador (Temperature, Top-K, Top-P)"] Sampler --> OutputToken["Token de saída"] OutputToken --> |"Geração autorregressiva"| Tokenizer OutputToken --> Decoder["Detokenizador (Detokenizer)"] Decoder --> FinalOutput["Texto de saída final"]

3.1 Duas Fases: Prefill e Decode

A geração de texto do LLM é dividida em duas fases com características computacionais diferentes.

Fase Prefill (Processamento de Prompt): A fase onde todo o prompt inserido é processado e compreendido de uma só vez. Devido à possibilidade de cálculo paralelo, a capacidade de cálculo da GPU (FLOPS) está diretamente ligada à velocidade. Se o prompt for longo, esta fase pode levar alguns segundos.
Fase Decode (Geração de Tokens): A fase onde se prevê um token de cada vez, que é repassado como próxima entrada (autorregressivo). Nesta fase, o cálculo paralelo é limitado, portanto a largura de banda de memória VRAM da GPU (Memory Bandwidth) se torna um gargalo decisivo.

4. Cálculo do Consumo de VRAM e Compreensão Matemática do Tamanho do Modelo

Para julgar corretamente “quais modelos rodam no meu PC?”, é necessário entender a fórmula de cálculo da VRAM. Se a falta de VRAM causar fallback para a memória do sistema (RAM), a velocidade de inferência cairá de 10x a 100x.

4.1 VRAM Base com Base no Tamanho dos Parâmetros

Esta é a quantidade de memória necessária para carregar os pesos (weights) do modelo para a VRAM. É calculada usando o tamanho do modelo $P$ (número de parâmetros, unidade: 1 bilhão = 1B) e os bytes por parâmetro $B$.

$$ V_{base} = P \times B \quad \text{(GB)} $$

Por exemplo, ao carregar um modelo de 8B (8 bilhões) de parâmetros em FP16 (ponto flutuante de meia precisão, 16 bits = 2 bytes):

$$ V_{base} = 8 \times 2 = 16 \text{ GB} $$

Em outras palavras, mesmo uma GPU com 16GB de VRAM estará no seu limite apenas carregando o modelo.

4.2 A Magia da Quantização (Quantization)

Aí entra a “quantização”. Ao reduzir a precisão dos parâmetros, o tamanho do modelo é reduzido drasticamente. Na quantização de 4 bits mais comum (ex: Q4_K_M), a média é cerca de 0,55 bytes por parâmetro.

$$ V_{base\_4bit} = 8 \times 0.55 = 4.4 \text{ GB} $$

Com isso, se você tiver 16GB de VRAM, terá bastante margem para rodar um modelo 8B de forma muito tranquila.

4.3 Cálculo do Cache KV (Versão Compatível com GQA)

Durante a inferência, o “Cache KV”, usado para manter o contexto passado, consome VRAM. Nos modelos mais recentes, como o Llama 3, o GQA (Grouped Query Attention) é adotado para economizar memória.

O consumo do Cache KV $V_{kv}$ (em gigabytes) é expresso pela seguinte fórmula:

$$ V_{kv} = 2 \times b \times s \times l \times \left( \frac{h_{kv}}{h_q} \right) \times h_q \times d \times B_{kv} \div 10^9 $$

Simplificando, podemos calcular usando o número de cabeças de chave/valor (key/value heads) $h_{kv}$:

$$ V_{kv} = 2 \times b \times s \times l \times h_{kv} \times d \times B_{kv} \div 10^9 $$

Onde:

$b$: Tamanho do batch (geralmente 1 para uso local pessoal)
$s$: Comprimento da sequência (comprimento do contexto, ex: 8192)
$l$: Número de camadas (ex: 32)
$h_{kv}$: Número de cabeças KV (ex: 8)
$d$: Dimensões por cabeça (ex: 128)
$B_{kv}$: Bytes do Cache KV (2 para FP16)

Exemplo de cálculo (Llama 3 8B, Contexto 8192, Cache FP16): $V_{kv} = 2 \times 1 \times 8192 \times 32 \times 8 \times 128 \times 2 \div 10^9 \approx 1.07 \text{ GB}$

Note que quanto mais longo for o comprimento do contexto $s$, mais a VRAM necessária aumentará linearmente.

5. Prática 1: Configuração Rápida e Curta com Ollama

Agora que entendemos a teoria, vamos rodar um LLM num ambiente Windows na prática. A partir de 2026, a ferramenta mais amigável ao usuário é o “Ollama”. Ele fornece uma CLI intuitiva semelhante à do Docker.

5.1 Instalação e Execução

Baixe e execute o instalador para Windows no Site Oficial do Ollama.
Abra o PowerShell e insira o seguinte comando. Aqui usaremos o llama3:8b, que possui suporte para japonês.

1

ollama run llama3:8b

Na primeira execução, o modelo será baixado. Ao concluir, você poderá conversar diretamente no terminal.

5.2 Criação de uma IA Customizada via Modelfile

Você pode criar facilmente uma IA com uma persona específica. Crie um Modelfile em qualquer local.

1
2
3
4
5
6
7
8
9


FROM llama3:8b

SYSTEM """
Você é um excelente engenheiro de software sênior.
Sempre responda às perguntas dos usuários com exemplos de código, de forma lógica e concisa.
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

Execute os comandos a seguir para compilar e executar o seu próprio modelo customizado.

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 Utilização de Aplicações Externas (Editores de IA)

O Ollama expõe um endpoint de API compatível com OpenAI em http://localhost:11434. Ao especificar esta URL nas configurações de backend de extensões do VS Code, como Cursor ou Continue.dev, e designar o nome do modelo como SeniorDev, você tem um assistente de codificação local poderoso e gratuito.

6. Prática 2: Afinação Extrema de Desempenho com llama.cpp

Se você quiser ter uma gestão fina de memória ou testar antecipadamente novos formatos (como EXL2, quantização IQ), interaja diretamente com o mecanismo central llama.cpp.

6.1 Procedimento de Compilação do llama.cpp

No ambiente Windows, a melhor forma é compilá-lo a partir do código-fonte usando CUDA Toolkit e CMake.

1
2
3
4
5
6
7
8


git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build
cd build

# Configurar e compilar com suporte a CUDA
cmake .. -DLLAMA_CUBLAS=ON -DBUILD_SHARED_LIBS=OFF
cmake --build . --config Release -j 16

6.2 Execução Avançada no Modo Servidor

Use o llama-server.exe compilado para hospedar o modelo.

1
2
3
4
5
6
7


.\bin\Release\llama-server.exe `
 --model "C:\models\Llama-3-8B-Instruct.Q4_K_M.gguf" `
 --ctx-size 8192 `
 --n-gpu-layers 99 `
 --threads 8 `
 --flash-attn `
 --port 8080

--n-gpu-layers 99: Descarrega (offload) todas as camadas possíveis para a VRAM da GPU.
--flash-attn: Habilita o FlashAttention 3, alcançando uma melhoria de velocidade de inferência e redução de consumo de VRAM para o Cache KV.

7. Front-end GUI: LM Studio e Construção de RAG Local

Se você não gosta de linhas de comando ou quer usar a RAG (Geração Aumentada por Recuperação) intuitivamente, utilize uma GUI.

7.1 LM Studio

O LM Studio é um aplicativo maravilhoso que centraliza a busca de modelos, o download, as verificações de pré-requisitos do sistema e a interface de chat. Ao simplesmente apertar o botão “Local Server” no app, uma API compatível com OpenAI é iniciada.

7.2 Arquitetura de RAG usando o AnythingLLM

Este é o diagrama de arquitetura do ambiente RAG para carregar documentos internos e notas pessoais.

graph LR Document["Documentos (PDF, MD)"] --> Chunking["Divisão em Chunks"] Chunking --> EmbedModel["Modelo de Embedding"] EmbedModel --> VectorDB["Banco de Dados Vetorial"] UserQuery["Pergunta do usuário"] --> EmbedQuery["Embedding da Pergunta"] EmbedQuery --> VectorDB VectorDB --> |"Busca de similaridade"| RetrievedDocs["Extração de Documentos Relevantes"] UserQuery --> PromptBuilder["Geração do Prompt"] RetrievedDocs --> PromptBuilder PromptBuilder --> LocalLLM["LLM Local"] LocalLLM --> Answer["Resposta Final"]

Com a versão desktop do AnythingLLM (Windows), você só precisa designar o Ollama (para LLM e Embedding) e configurar o VectorDB local (LanceDB) nas opções, e essa arquitetura estará concluída em minutos. É o nascimento de uma IA Privada que nunca envia os dados a terceiros.

8. Fine-tuning no WSL2 do Windows (LoRA)

Além de rodar os modelos localmente, se você deseja que eles fiquem mais inteligentes com seus próprios dados, o fine-tuning através do LoRA (Low-Rank Adaptation) é possível. Em 2026, com uma biblioteca chamada “Unsloth”, o treinamento de um modelo 8B é finalizado em algumas horas, mesmo com 16GB de VRAM, no ambiente Windows WSL2.

Crie o ambiente executando o seguinte dentro do Ubuntu do WSL2:

1
2
3
4


conda create --name unsloth_env python=3.11
conda activate unsloth_env
pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git"
pip install --no-deps trl peft accelerate bitsandbytes

O Unsloth otimiza ao extremo os kernels do CUDA. Se comparado a uma biblioteca padronizada do Hugging Face, sua velocidade de treinamento é duas vezes maior e o consumo de VRAM é reduzido pela metade. Bastará iniciar um Jupyter Notebook e carregar o seu dataset (formato JSONL) para que ocorram as épocas de treinamento em GPUs com VRAM entre 12GB a 16GB, como a RTX 4060 Ti, por exemplo.

9. Solução de Problemas de Desempenho

Abaixo, encontre os problemas comumente encontrados e suas soluções.

1. A velocidade de inferência é extremamente lenta (1~2 tokens/s)

Causa: O modelo extrapolou a capacidade da VRAM e o processamento offload recaiu à memória do sistema (RAM). Solução: Inspecione o espaço de “Memória da GPU Dedicada” no Gerenciador de Tarefas do Windows. Se já atingiu o limite, reduza o tamanho do contexto (-c) ou utilize um modelo quantizado com menor número de bits (como o Q4_K_M).

2. Erro “CUDA out of memory”

Causa: A VRAM foi completamente esgotada. Geralmente ocorre quando a conversa se estende, inchando o tamanho do Cache KV. Solução: Restrinja intencionalmente o valor de num_ctx no Ollama ou o parâmetro -c do llama.cpp para um número mais baixo.

3. A geração em japonês está estranha

Causa: Incompatibilidade no template de prompt ou o modelo não possui suporte. Solução: Utilize modelos que incluam Instruct no nome, e confirme na ferramenta se o template exigido pelos criadores do modelo, como os formatos ChatML ou Llama3, encontra-se devidamente selecionado.

10. Resumo e Perspectivas Futuras

Em 2026, criar um ambiente local de LLM no Windows não é mais privilégio de apenas alguns engenheiros. Devido à padronização do formato GGUF, à ascensão de ecossistemas refinados como Ollama e LM Studio, e a otimizações de hardware como FlashAttention, qualquer pessoa pode obter um ambiente de IA corporativo com extrema facilidade.

Aproveite ao máximo os seguintes pontos detalhados neste artigo:

Fazer uso do cálculo matemático de VRAM para logicamente selecionar o nível de quantização e o tamanho do modelo ideais para as especificações do seu computador.
Usar o Ollama para um ambiente o mais rápido de construir e integrá-lo a um editor de IA, com o objetivo de aumentar drasticamente a produtividade.
Usar os parâmetros de controle avançado no llama.cpp para extrair as margens de desempenho do hardware.
Construir através do AnythingLLM um ambiente e sistema RAG Local seguro o suficiente para manipular os dados da sua empresa.
Fazer uso do Unsloth (WSL2) para criar a sua própria customizada IA, baseada no seu nível e especialidade de conhecimento.

A “democratização” da IA não se resume a um mero jargão tecnológico. Trata-se do real cenário em que os próprios sistemas são executados na tela de desktop de seu Windows. Livre-se dos riscos de vazamento de dados e custos nas APIs em nuvem, e comece hoje mesmo sua imersão em um mundo onde a IA Privada é poderosa e completamente sua.