Windows on kenji.blog

Практические примеры и примеры кода использования новейшего API Microsoft.Windows.AI

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

Практические примеры и примеры кода использования новейшего API Microsoft.Windows.AI: Исследование глубин Windows Copilot Runtime

1. Введение: Новая эра Windows с нативной интеграцией ИИ

В последние годы эволюция технологий ИИ была поразительной, и происходит быстрый сдвиг парадигмы от использования больших языковых моделей (LLM) в облаке к выводу ИИ на граничных устройствах (локальных ПК). Центральную роль в этом играют «Windows Copilot Runtime», предоставляемый Microsoft для Windows 11, и API «Microsoft.Windows.AI» для управления им.

Разработка приложений с использованием облачных API (например, OpenAI или Azure OpenAI) проста, но сопровождается такими проблемами, как задержка, конфиденциальность и постоянные затраты. С другой стороны, запуск моделей ИИ локально позволяет создавать приложения со сверхнизкой задержкой, которые работают даже в автономном режиме, не выводя конфиденциальные данные за пределы устройства.

В этой статье мы подробно и досконально рассмотрим, как реализовать локальные функции ИИ, которые станут необходимыми для разработки приложений Windows в будущем, от архитектуры до настройки производительности, с практическими примерами кода на C# и C++. Мы не только рассмотрим вызов API, но и углубимся в сложные технические детали, такие как использование базового оборудования (NPU и GPU) и интеграцию с DirectML.

2. Windows Copilot Runtime и общий обзор архитектуры

Windows Copilot Runtime — это стек ИИ, разработанный для того, чтобы разработчики могли легко интегрировать модели ИИ в Windows и извлекать максимальную производительность. Эта среда выполнения абстрагирует аппаратное ускорение на уровне ОС и предоставляет разработчикам унифицированный интерфейс.

graph TD App["Приложение Windows (C# / C++)"] --> API["API Microsoft.Windows.AI"] App --> ORT["ONNX Runtime"] API --> WCR["Windows Copilot Runtime (Уровень ОС)"] WCR --> SLM["Локальные модели (Phi-Silica и т.д.)"] ORT --> DML["Провайдер выполнения DirectML"] SLM --> DML DML --> DXCore["DXCore / DirectX 12"] DXCore --> NPU["NPU (Нейронный процессор)"] DXCore --> GPU["GPU (Графический процессор)"] DXCore --> CPU["CPU"]

Как показано на архитектурной диаграмме выше, приложения могут напрямую обращаться к малым языковым моделям (SLM: таким как Phi-Silica), встроенным в ОС, используя высокоуровневый API Microsoft.Windows.AI. Кроме того, при использовании пользовательских моделей можно явно использовать аппаратное ускорение через ONNX Runtime и DirectML. Поскольку уровень ОС оптимизирует распределение рабочих нагрузок между CPU, GPU и NPU, разработчики могут создавать высокопроизводительные приложения ИИ, не задумываясь о различиях в оборудовании.

3. Математическая оценка аппаратного ускорения и NPU

Современные ПК Copilot+ оснащены NPU (нейронным процессором), процессором, специально предназначенным для обработки задач ИИ. Производительность NPU обычно оценивается в TOPS (тера-операциях в секунду - Tera Operations Per Second).

При выводе моделей ИИ вычислительная мощность матричного умножения (GEMM: General Matrix Multiply) в первую очередь определяет пропускную способность. Теоретическая пиковая производительность оборудования $P_{\text{peak}}$ оценивается по следующей формуле:

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

Где:

$f$ — тактовая частота NPU (Гц)
$N_{\text{cores}}$ — количество ядер в NPU
$N_{\text{MACs/core}}$ — количество блоков MAC (Multiply-Accumulate) на ядро
Последняя цифра $2$ связана с тем, что одна операция MAC считается как две операции (FLOPs/OPs) — умножение и сложение.

Например, для NPU с частотой 1.5 ГГц, 4 ядрами и 4096 MAC в каждом ядре:

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

Математически показано, что эта производительность превышает требование в 40 TOPS для ПК Copilot+ с Windows 11.

Кроме того, вывод моделей ИИ, особенно LLM (фаза декодирования), часто ограничен памятью (Memory-Bound). Теоретическая пропускная способность системной памяти $BW$ рассчитывается следующим образом:

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

Для памяти LPDDR5x-8533 ($f_{\text{mem}} = 8533 \text{ MT/s}$) и 128-битной шины ($W_{\text{bus}} = 128$) пропускная способность составит около $136 \text{ GB/s}$. При оптимизации ИИ-приложений важно, как экономится эта пропускная способность, что делает необходимым квантование (Quantization) моделей, которое будет описано позже.

4. Настройка среды разработки

Чтобы использовать новейший API Windows AI, необходимо подготовить следующую среду и цепочку инструментов:

ОС: Windows 11 версии 24H2 или новее (настоятельно рекомендуется устройство с NPU, соответствующее требованиям Copilot+ PC)
SDK: Windows App SDK (версия 1.5 или новее с поддержкой расширений ИИ)
Среда разработки: Visual Studio 2022 (версия 17.10 или новее), рабочие нагрузки для нативной разработки на C++ и разработки классических приложений .NET
Пакеты: Установите Microsoft.Windows.AI и Microsoft.ML.OnnxRuntime.DirectML через NuGet

1
2
3
4
5
6


<!-- Пример настройки .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] Использование локальной языковой модели (Phi-Silica) с C#

Windows Copilot Runtime включает высокоэффективную малую языковую модель «Phi-Silica», разработанную Microsoft, в качестве стандартного компонента ОС. Это обеспечивает расширенную обработку естественного языка (краткое изложение текста, генерация кода, чат-боты) в автономной среде без необходимости загрузки гигабайтных моделей из сети.

Ниже приведен продвинутый пример кода для создания ИИ-чата на C# с использованием пространства имен Microsoft.Windows.AI.Generative. Он поддерживает потоковые ответы и генерирует текст в реальном времени, не блокируя поток пользовательского интерфейса.

 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>
 /// Инициализирует языковую модель. Проверяет доступность NPU и загружает модель на оптимальное устройство.
 /// </summary>
 public async Task InitializeAsync()
 {
 if (_isInitialized) return;

 Console.WriteLine("Проверка системных требований и доступности локальной ИИ-модели (Phi-Silica)...");

 // Проверка доступности модели в системе (если не поддерживается, может быть предложено скачивание)
 var availability = await LanguageModel.CheckAvailabilityAsync();
 if (availability != LanguageModelAvailability.Available)
 {
 throw new InvalidOperationException($"Локальная ИИ-модель в настоящее время недоступна. Состояние: {availability}");
 }

 // Создание экземпляра модели (на этом этапе происходит маппинг в адресное пространство памяти и инициализация NPU)
 _languageModel = await LanguageModel.CreateAsync();
 _isInitialized = true;

 Console.WriteLine("Инициализация языковой модели завершена. Аппаратное ускорение через DirectML активно.");
 }

 /// <summary>
 /// Принимает промпт пользователя и генерирует ответ в виде потока.
 /// </summary>
 public async Task GenerateResponseStreamAsync(string prompt, CancellationToken cancellationToken)
 {
 if (!_isInitialized) await InitializeAsync();

 Console.WriteLine($"\n[Ввод пользователя]: {prompt}\n[ИИ-ассистент]: ");

 // Настройка гиперпараметров для генерации
 var options = new LanguageModelOptions
 {
 Temperature = 0.7f,
 TopP = 0.9f,
 MaxTokens = 2048,
 RepetitionPenalty = 1.1f
 };

 // Построение контекста разговора
 var context = new LanguageModelContext();
 context.AddSystemMessage("Вы — продвинутый ИИ-ассистент, работающий напрямую на локальном NPU Windows. Рассуждайте логически шаг за шагом и отвечайте лаконично.");
 context.AddUserMessage(prompt);

 try
 {
 // Вызов API потокового вывода
 var responseStream = _languageModel.GenerateResponseStreamAsync(context, options);

 // Асинхронная итерация чанков, возвращаемых как IAsyncEnumerable
 await foreach (var chunk in responseStream.WithCancellation(cancellationToken))
 {
 // Вывод сгенерированных токенов (чанков) в консоль в реальном времени
 // В случае UI-приложения здесь следует использовать DispatcherQueue для обновления TextBox и т.д.
 Console.Write(chunk.Text);
 }
 Console.WriteLine();
 }
 catch (OperationCanceledException)
 {
 Console.WriteLine("\n[Генерация была отменена пользователем или системой]");
 }
 catch (Exception ex)
 {
 Console.WriteLine($"\n[Произошла критическая ошибка: {ex.Message}]");
 }
 }
 }
}

5.1 Пояснение архитектуры реализации на C#

Ядром этого кода является проверка перед выполнением с помощью LanguageModel.CheckAvailabilityAsync() и асинхронная потоковая передача с помощью GenerateResponseStreamAsync. Copilot Runtime, работающий в фоновом режиме ОС, получает этот вызов API, внутренне запускает ONNX Runtime и выбирает оптимальный провайдер выполнения (Execution Provider) (DirectML + NPU на многих современных ПК) в соответствии с конфигурацией системы.

Разработчики могут интегрировать передовой конвейер логического вывода ИИ в свои приложения всего несколькими строками кода на C#, не заботясь о форме тензоров модели, реализации токенизатора или управлении памятью кэша KV.

6. [Deep Dive 2] Высокоскоростной вывод пользовательских моделей с использованием C++ и DirectML

При работе с конкретными доменами, которые не могут быть охвачены стандартной языковой моделью ОС (например, собственная сегментация изображений, распознавание речи, пользовательские модели обнаружения объектов), разработчикам необходимо напрямую взаимодействовать с низкоуровневыми компонентами Microsoft.Windows.AI — ONNX Runtime и DirectML.

Использование C++ позволяет максимально оптимизировать распределение памяти и извлечь пиковую производительность из NPU/GPU. Ниже приведена базовая реализация конвейера инициализации и расширенного вывода для выполнения пользовательской модели в формате ONNX (например, YOLOv8) на C++ с использованием 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;
 // Оптимизация количества потоков
 sessionOptions.SetIntraOpNumThreads(1);
 // Установка максимального уровня оптимизации графа
 sessionOptions.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

 // 1. Добавление провайдера выполнения DirectML (DML EP)
 // device_id = 0 — это рекомендуемый по умолчанию адаптер системы (NPU или высокопроизводительный GPU)
 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] Провайдер выполнения DirectML успешно подключен." << std::endl;
 } else {
 std::cerr << "[Warning] Не удалось получить API DirectML. Выполнение в режиме резервного копирования на CPU." << std::endl;
 if (status != nullptr) ortApi.ReleaseStatus(status);
 }

 // 2. Загрузка модели и создание сессии
 try {
 session = Ort::Session(env, modelPath.c_str(), sessionOptions);
 std::cout << "[Info] Модель ONNX успешно загружена, вычислительный граф скомпилирован." << std::endl;
 } catch (const Ort::Exception& e) {
 std::cerr << "[Error] Ошибка загрузки модели: " << e.what() << std::endl;
 throw;
 }
 }

 void RunInference(const std::vector<float>& imageTensor, const std::vector<int64_t>& inputShape) {
 // 3. Создание буфера для входного тензора
 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. Динамическое получение имен входных и выходных узлов
 auto inputNamePtr = session.GetInputNameAllocated(0, allocator);
 auto outputNamePtr = session.GetOutputNameAllocated(0, allocator);
 const char* inputNames[] = { inputNamePtr.get() };
 const char* outputNames[] = { outputNamePtr.get() };

 // 5. Выполнение вывода (переносится на NPU/GPU через DirectML)
 std::cout << "[Info] Запуск механизма логического вывода..." << 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. Получение и анализ результирующего тензора
 float* outputData = outputTensors.front().GetTensorMutableData<float>();
 size_t outputSize = outputTensors.front().GetTensorTypeAndShapeInfo().GetElementCount();

 std::cout << "[Result] Вывод завершен: " << duration.count() << " мс" << std::endl;
 std::cout << "[Result] Количество элементов выходного тензора: " << outputSize << std::endl;
 // *После этого реализуется постобработка, например, NMS (Non-Maximum Suppression) и отрисовка ограничивающих рамок для выходного тензора.
 }
};

int main() {
 try {
 // Путь к исполняемой модели ONNX
 CustomVisionAIProcessor processor(L"models/yolov8n_quantized.onnx");

 // Фиктивные данные изображения для вывода (размер пакета 1 x 3 канала 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 << "Программа завершилась с ошибкой: " << e.what() << std::endl;
 return -1;
 }
 return 0;
}

6.1 Важность управления памятью и вывода с нулевым копированием (Zero-Copy) в C++

Самое большое преимущество использования DirectML в C++ заключается в возможности тесной интеграции с DirectX 12 (DX12). В приведенном выше коде в образовательных целях включено стандартное копирование данных из памяти CPU, но в реальных игровых движках или приложениях для обработки видео часто изображения (текстуры) уже хранятся в памяти GPU или NPU с использованием DX12.

В этом случае вы можете использовать расширенные функции привязки OrtDmlApi для сопоставления ресурсов DX12 непосредственно с тензорами ONNX Runtime, достигая «вывода с нулевым копированием (Zero-Copy Inference)». Это полностью устраняет накладные расходы на передачу данных по шине PCIe (потребление упомянутой выше пропускной способности $BW$) и значительно повышает частоту кадров при обработке видео в реальном времени.

7. Оптимизация производительности и лучшие практики

Ниже приведены основные стратегии оптимизации для разработки первоклассных приложений ИИ с использованием API Windows AI и DirectML.

7.1 Квантование модели (Quantization) и Olive Toolkit

Чтобы раскрыть истинную мощь NPU, обязательным условием является квантование (Quantization) весов и активаций моделей ИИ с FP32 (одинарная точность с плавающей запятой) до INT8 или INT4. Архитектура NPU оптимизирована для целочисленной арифметики и теоретически достигает четырехкратной пропускной способности и значительной экономии энергии с INT8 по сравнению с FP32.

Используя набор инструментов Olive (ONNX Live), предоставляемый Microsoft, вы можете автоматически оптимизировать модели, такие как PyTorch, для сред Windows. Olive обеспечивает мощную поддержку специализированной оптимизации внимания для моделей Transformer и компиляции графов для конкретного оборудования.

7.2 Компромисс между пакетной обработкой и интерактивной потоковой передачей

В вызовах API пакетная обработка нескольких запросов вывода может повысить эффективность использования NPU (Compute Utilization). Однако для интерактивного пользовательского интерфейса, такого как чат-бот, время до отображения первого токена (TTFT: Time To First Token) определяет пользовательский опыт (UX) в большей степени, чем пропускная способность. Следовательно, для интерактивных пользовательских интерфейсов лучшей практикой является установка размера пакета равным 1 и приоритизация потоковой генерации.

7.3 Фоновые задачи и интеграция с ОС

Вывод ИИ потребляет значительное количество локальной энергии и системных ресурсов. Требуется интеграция с App Lifecycle API Windows: когда приложение переходит в фоновый режим, задачи логического вывода с низким приоритетом должны приостанавливаться (Suspend) или ограничивать потребление ресурсов.

sequenceDiagram participant User as "Пользователь" participant App as "Приложение Windows (C#)" participant API as "Microsoft.Windows.AI" participant OS as "Windows Copilot Runtime" participant ORT as "ONNX Runtime (DML)" participant NPU as "Оборудование NPU" User->>App: "Ввод промпта" App->>API: "GenerateResponseStreamAsync()" API->>OS: "Диспетчеризация задачи вывода" OS->>ORT: "Запрос выполнения графа" ORT->>NPU: "Выполнение списка команд через DirectML" NPU-->>ORT: "Вычисление завершено (генерация 1 токена)" ORT-->>OS: "Результат тензора" OS-->>API: "Декодированный текст" API-->>App: "Чанк IAsyncEnumerable" App-->>User: "Отрисовка текста в реальном времени в UI" Note over ORT,NPU: "Быстрое повторение этого цикла до завершения"

Эта диаграмма последовательности иллюстрирует красоту асинхронной обработки, при которой данные передаются потоком с самого нижнего уровня аппаратного обеспечения NPU на уровень представления приложения, совершенно не блокируя поток пользовательского интерфейса.

8. Перспективы на будущее и эволюция Windows AI

API Microsoft.Windows.AI и Copilot Runtime в настоящее время быстро развиваются. В будущих обновлениях для разработчиков ожидаются следующие сдвиги парадигмы:

Нативная интеграция мультимодальных API в ОС: Плавная одновременная обработка не только текста, но также голоса, изображений и даже живых видеопотоков, обеспечивающая стандартный кросс-модальный вывод ИИ на уровне ОС.
Поддержка RAG (Retrieval-Augmented Generation) на системном уровне: Создание сверхпродвинутого персонального ИИ-ассистента путем связи личных документов на локальном ПК и индексов Windows Search с моделями ИИ в безопасной песочнице ОС, с полной защитой конфиденциальности пользователя.
Динамическое масштабирование ресурсов NPU: Когда одновременно работают несколько приложений ИИ (например, шумоподавление в фоновом режиме и генерация кода на переднем плане), планировщик ядра Windows динамически переключает контекст выполнения NPU, чтобы гарантировать качество обслуживания (QoS).

9. Заключение: Как локальный ИИ меняет будущее приложений

Copilot Runtime в Windows 11 и API Microsoft.Windows.AI дали всем разработчикам Windows чрезвычайно мощное оружие: «локальный ИИ». Больше нет необходимости полностью полагаться на облачные API. Можно устранить задержки, строго соблюдать конфиденциальность и предоставить пользователям возможности ИИ нового поколения, которые полностью работают даже в автономном режиме.

Используйте знания об интеграции стандартных языковых моделей ОС с помощью C#, математической оценке производительности и экстремальной оптимизации аппаратного обеспечения с помощью C++ и DirectML, описанные в этой статье, чтобы своими руками создать следующее поколение «AI-нативных» приложений Windows. Бесконечные возможности, открываемые ИИ, лежат прямо за пределами кода, который вы пишете.

Примечание: Эта статья написана на основе предварительной версии API и последних спецификаций по состоянию на сентябрь 2026 года. Поскольку спецификации API и требования к оборудованию могут изменяться с обновлениями Windows, при реализации обязательно сверяйтесь с официальной документацией Microsoft Learn.

【2026 год: Последняя версия】Полное руководство по запуску локальных LLM в среде Windows

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

1. Введение: Почему именно сейчас локальные LLM на Windows?

По состоянию на 2026 год эволюция генеративного ИИ и больших языковых моделей (LLM) демонстрирует серьезный сдвиг парадигмы — от гигантских облачных API-сервисов к «локальным LLM», работающим на персональных ПК или в локальной среде (on-premise). Облачные ИИ, такие как GPT-5 от OpenAI или Claude 3.5 от Anthropic, очень мощны, но компании и частные лица не могут отправлять абсолютно все свои данные в облако. С точки зрения конфиденциальности, безопасности, задержек, а также долгосрочной и устойчивой стоимости, спрос на локальные LLM сейчас высок как никогда.

В частности, экосистема локальных LLM для среды Windows переживает поразительное развитие. Еще несколько лет назад здравый смысл подсказывал, что «разработка и запуск ИИ означает Linux», но в 2026 году Windows превратилась в очень мощную и удобную платформу для ИИ.

В этой статье представлено полное руководство по созданию, развертыванию и оптимизации локальных LLM в среде Windows с учетом последних технологических тенденций 2026 года. Мы детально и всесторонне рассмотрим всё: от простой настройки для новичков с помощью Ollama до экстремальной оптимизации для продвинутых пользователей с использованием llama.cpp, а также глубокого понимания архитектуры, математического подхода к расчету VRAM и локального файнтюнинга.

1.1 Технологические тенденции в сфере локальных LLM в 2026 году

Основные тенденции, формирующие текущую экосистему локальных LLM, следующие:

Полное распространение формата GGUF: Формат GGUF (GPT-Generated Unified Format), объединяющий метаданные и тензоры в один файл, стал абсолютным стандартом де-факто. Теперь достаточно скачать один файл с Hugging Face, чтобы запустить его в любой среде.
Демократизация архитектуры MoE (Mixture of Experts): Выпущено множество небольших, но высокопроизводительных моделей MoE. Активируя при выводе (инференсе) лишь часть «экспертов», они достигают производительности, сопоставимой с гигантскими моделями, при этом снижая вычислительную нагрузку на потребительские ПК.
Высокий уровень абстракции и оптимизации движков вывода: Такие инструменты, как Ollama, LM Studio и AnythingLLM, стали настолько совершенными, что пользователям больше не нужно беспокоиться о сложных зависимостях, вроде установки драйверов CUDA. Кроме того, нативная поддержка FlashAttention 3 для Windows привела к резкому увеличению скорости инференса.
Использование NPU и развитие Windows Copilot+ PC: Технология запуска небольших LLM (SLM: Small Language Models) с низким энергопотреблением на ноутбуках без GPU с использованием встроенного NPU (Neural Processing Unit) достигла стадии практического применения.

2. Требования к аппаратному обеспечению и подготовка ОС

Чтобы локальная LLM работала с приемлемой скоростью (от 15 до 30+ токенов в секунду), самое важное — правильно выбрать аппаратное обеспечение.

2.1 Рекомендуемая конфигурация оборудования

С развитием ИИ-ПК меняются и системные требования.

ОС: Windows 11 Pro (24H2 или новее). Необходимо для полноценного использования функций WSL2, продвинутого управления памятью и работы с новейшим API DirectML.
CPU: Серия Intel Core Ultra 200 или выше, либо серия AMD Ryzen 9000 или выше. Если параллельно используется инференс на CPU, жизненно необходима высокоскоростная связь с памятью.
RAM: Минимум 32 ГБ, рекомендуется 64 ГБ или больше. Пропускная способность основной памяти (МБ/с) становится решающим узким местом при инференсе на CPU или переносе (offload) вычислений. В идеале использовать высокоскоростную память DDR5-6000 или выше.
GPU: Серия NVIDIA RTX 4000/5000. В локальных LLM наиболее важна не вычислительная мощность, а «объем VRAM».
- Начальный уровень: RTX 4060 Ti (версия 16 ГБ) — лучшее соотношение цены и качества. Идеально подходит для моделей класса 8B–14B.
- Средний уровень: RTX 4070 Ti SUPER (16 ГБ) / RTX 4080 SUPER (16 ГБ)
- High-end: RTX 4090 (24 ГБ) / RTX 5090 (32 ГБ) — необходимы для запуска квантованных моделей класса 30B–70B.
Накопитель: NVMe SSD PCIe Gen4 или Gen5. Резко сокращает время загрузки моделей объемом в десятки гигабайт.

2.2 Настройка WSL2 (Windows Subsystem for Linux 2)

Хотя многие инструменты с графическим интерфейсом работают в Windows нативно, WSL2 очень удобен для разработки на Python, компиляции новейших инструментов и файнтюнинга LoRA, о котором пойдет речь ниже. В последних версиях среды Windows 11 достаточно установить драйвер NVIDIA на хосте, чтобы прозрачно использовать GPU (CUDA) из WSL2.

Откройте PowerShell от имени администратора и выполните следующее:

1
2
3
4
5


# Установка WSL2 и последней версии Ubuntu
wsl --install -d Ubuntu-24.04

# Обновление ядра
wsl --update

После установки выполните команду nvidia-smi в терминале WSL2. Если GPU распознан корректно — установка прошла успешно.

3. Архитектура локальных LLM и механизм вывода (инференса)

Понимание внутренней структуры того, как модель генерирует текст в локальной среде, очень полезно для устранения неполадок и оптимизации.

Следующая диаграмма Mermaid показывает типичный конвейер инференса локальной LLM.

graph TD User["Пользовательский ввод (Промпт)"] --> Tokenizer["Токенизатор (Tokenizer)"] Tokenizer --> Embedding["Слой встраивания (Embedding)"] subgraph "Transformer Block (x Layers)" Embedding --> Attn["Механизм внутреннего внимания (Self-Attention)"] Attn --> KVCache["KV-кэш (Хранение Key/Value)"] Attn --> FFN["Сеть прямой связи (FFN)"] end FFN --> Logits["Вычисление логитов (Logits)"] Logits --> Sampler["Сэмплер (Temperature, Top-K, Top-P)"] Sampler --> OutputToken["Выходной токен"] OutputToken --> |"Авторегрессионная генерация"| Tokenizer OutputToken --> Decoder["Детокенизатор (Detokenizer)"] Decoder --> FinalOutput["Итоговый сгенерированный текст"]

3.1 Две фазы: Prefill и Decode

Генерация текста LLM разделена на две фазы с различными вычислительными характеристиками.

Фаза Prefill (Обработка промпта): Фаза, в которой весь введенный промпт обрабатывается и понимается за один раз. Поскольку возможны параллельные вычисления, вычислительная мощность GPU (FLOPS) напрямую влияет на скорость. Если промпт длинный, эта фаза может занять несколько секунд.
Фаза Decode (Генерация токенов): Фаза, в которой предсказывается по одному токену за раз, и результат передается на следующий вход (авторегрессия). Поскольку параллельные вычисления на этом этапе ограничены, пропускная способность VRAM (Memory Bandwidth) становится решающим узким местом.

4. Расчет потребления VRAM и математическое понимание размера модели

Чтобы правильно определить, «какая модель будет работать на моем ПК», необходимо понимать формулу расчета VRAM. Если из-за нехватки VRAM происходит откат (фолбэк) к системной памяти (RAM), скорость вывода падает в 10–100 раз.

4.1 Базовый объем VRAM на основе размера параметров

Это объем памяти, необходимый для загрузки весов модели в VRAM. Он рассчитывается с использованием размера модели $P$ (количество параметров, единица измерения: 1 миллиард = 1B) и количества байт на 1 параметр $B$.

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

Например, при загрузке модели с 8B (8 миллиардами) параметров в формате FP16 (полуточные числа с плавающей запятой, 16 бит = 2 байта):

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

Другими словами, даже на GPU с 16 ГБ VRAM вы достигнете предела уже только при загрузке модели.

4.2 Магия квантования (Quantization)

Вот здесь в игру вступает «квантование». Снижая точность параметров, размер модели кардинально уменьшается. В случае наиболее распространенного 4-битного квантования (например, Q4_K_M), на один параметр приходится в среднем около 0.55 байта.

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

Таким образом, имея 16 ГБ VRAM, вы сможете запускать модель 8B с достаточным запасом памяти.

4.3 Расчет KV-кэша (с поддержкой GQA)

Во время вывода (инференса) «KV-кэш», предназначенный для сохранения прошлого контекста, потребляет VRAM. В последних моделях, таких как Llama 3, для экономии памяти применяется GQA (Grouped Query Attention).

Потребление KV-кэша $V_{kv}$ (в гигабайтах) выражается следующей формулой:

$$ 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 $$

Упростив это, мы можем произвести вычисления с помощью количества голов Key и Value $h_{kv}$:

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

Где:

$b$: Размер батча (обычно 1 для локального индивидуального использования)
$s$: Длина последовательности (длина контекста, например: 8192)
$l$: Количество слоев (например: 32)
$h_{kv}$: Количество голов KV (например: 8)
$d$: Размерность на одну голову (например: 128)
$B_{kv}$: Количество байт KV-кэша (2 для FP16)

Пример расчета (Llama 3 8B, контекст 8192, кэш FP16): $V_{kv} = 2 \times 1 \times 8192 \times 32 \times 8 \times 128 \times 2 \div 10^9 \approx 1.07 \text{ ГБ}$

Обратите внимание, что чем больше длина контекста $s$, тем больше необходимо VRAM, и этот рост линеен.

5. Практика 1: Самая быстрая и короткая настройка с использованием Ollama

Теперь, поняв теорию, давайте действительно запустим LLM в среде Windows. По состоянию на 2026 год, самым удобным инструментом является «Ollama». Он предоставляет интуитивно понятный CLI в стиле Docker.

5.1 Установка и запуск

Скачайте и запустите установщик для Windows с официального сайта Ollama.
Откройте PowerShell и введите следующую команду. Здесь мы используем llama3:8b.

1

ollama run llama3:8b

При первом запуске произойдет загрузка модели. По завершении вы сможете вести диалог прямо в терминале.

5.2 Создание собственного ИИ с помощью Modelfile

Вы можете легко создать ИИ с определенной персоной. Создайте файл Modelfile в любом месте.

1
2
3
4
5
6
7
8
9


FROM llama3:8b

SYSTEM """
Вы — выдающийся старший инженер-программист (Senior Software Engineer).
На вопросы пользователя всегда отвечайте логично и кратко, обязательно приводя примеры кода.
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

Используйте следующие команды для сборки и запуска вашей собственной модели:

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 Использование из внешних приложений (ИИ-редакторов)

Ollama открывает API-эндпоинт, совместимый с OpenAI, по адресу http://localhost:11434. В настройках бэкенда таких расширений для VS Code, как Cursor или Continue.dev, просто укажите этот URL и имя модели (например, SeniorDev), чтобы получить мощного локального помощника по программированию абсолютно бесплатно.

6. Практика 2: Экстремальная настройка производительности с помощью llama.cpp

Если вы хотите получить доступ к детальному управлению памятью или быстро опробовать новейшие форматы (такие как EXL2 или IQ квантование), то стоит использовать основной движок llama.cpp напрямую.

6.1 Процесс сборки llama.cpp

В среде Windows лучше всего собирать из исходного кода, используя CUDA Toolkit и CMake.

1
2
3
4
5
6
7
8


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

# Конфигурация и компиляция с поддержкой CUDA
cmake .. -DLLAMA_CUBLAS=ON -DBUILD_SHARED_LIBS=OFF
cmake --build . --config Release -j 16

6.2 Продвинутый запуск в режиме сервера

Используйте собранный llama-server.exe для хостинга модели.

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: Переносит на VRAM GPU все возможные слои (максимально возможное количество).
--flash-attn: Включает FlashAttention 3, что повышает скорость инференса и снижает потребление VRAM KV-кэшем.

7. GUI фронтенды: LM Studio и создание локального RAG

Если вы не любите командную строку или хотите интуитивно выполнять RAG (Генерация с дополненной выборкой), воспользуйтесь графическими интерфейсами.

7.1 LM Studio

LM Studio — это отличное приложение, которое объединяет поиск моделей, их загрузку, предварительную проверку системных требований и пользовательский интерфейс для чата в одном месте. Просто нажав кнопку “Local Server” в приложении, вы запускаете API, совместимый с OpenAI.

7.2 Архитектура RAG с использованием AnythingLLM

Вот схема архитектуры среды RAG для чтения внутренних корпоративных документов или личных заметок.

graph LR Document["Документ (PDF, MD)"] --> Chunking["Разделение на чанки"] Chunking --> EmbedModel["Модель встраивания (Embedding)"] EmbedModel --> VectorDB["Векторная база данных"] UserQuery["Запрос пользователя"] --> EmbedQuery["Встраивание запроса"] EmbedQuery --> VectorDB VectorDB --> |"Поиск по сходству"| RetrievedDocs["Извлеченные релевантные документы"] UserQuery --> PromptBuilder["Генератор промпта"] RetrievedDocs --> PromptBuilder PromptBuilder --> LocalLLM["Локальная LLM"] LocalLLM --> Answer["Итоговый ответ"]

Используя десктопную версию AnythingLLM (для Windows), достаточно указать Ollama (как LLM и Embedding) на экране настроек и настроить использование локальной векторной БД (LanceDB), и эта архитектура будет готова за несколько минут. Так рождается приватный ИИ, который совершенно не отправляет данные наружу.

8. Файнтюнинг на Windows в WSL2 (LoRA)

Если вы хотите не только локально запускать модели, но и обучать их на своих собственных данных, чтобы сделать умнее, вы можете использовать файнтюнинг с помощью LoRA (Low-Rank Adaptation). По состоянию на 2026 год, благодаря библиотеке под названием “Unsloth”, обучение 8B-модели в среде Windows WSL2 с 16 ГБ VRAM завершается всего за несколько часов.

Выполните следующее в Ubuntu под 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

Unsloth доводит оптимизацию ядер CUDA до предела, так что скорость обучения примерно удваивается, а потребление VRAM снижается вдвое по сравнению со стандартными библиотеками Hugging Face. Просто запустите Jupyter Notebook, загрузите свой набор данных (в формате JSONL), и вы сможете выполнить несколько эпох обучения даже на RTX 4060 Ti с VRAM от 12 ГБ до 16 ГБ.

9. Устранение проблем с производительностью (Troubleshooting)

Часто возникающие проблемы и способы их решения.

1. Скорость вывода крайне низкая (1-2 tokens/s)

Причина: Модель не помещается в VRAM и выгружается (offload) в системную память (RAM). Решение: Проверьте параметр «Выделенная память графического процессора» в Диспетчере задач. Если он достиг предела, уменьшите размер контекста (-c) или используйте квантованную модель с меньшим битрейтом (например, Q4_K_M).

2. Ошибка “CUDA out of memory”

Причина: VRAM полностью исчерпан. В основном возникает, когда диалог затягивается, и KV-кэш разрастается. Решение: Намеренно ограничьте значение num_ctx в Ollama или -c в llama.cpp, сделав его меньше.

3. Странная генерация на японском (или другом) языке

Причина: Несоответствие шаблона промпта или неподдерживаемая модель. Решение: Убедитесь, что вы используете модель, содержащую слово Instruct в названии, и что в инструменте выбран правильный шаблон, указанный автором модели (например, формат ChatML или Llama3).

10. Заключение и перспективы на будущее

В 2026 году развертывание локальных LLM в среде Windows больше не является привилегией лишь избранных инженеров. Благодаря формату GGUF, ставшему стандартом де-факто, появлению продуманных экосистем, таких как Ollama и LM Studio, а также аппаратной оптимизации, включая FlashAttention, каждый может легко получить ИИ-среду корпоративного уровня.

Пожалуйста, воспользуйтесь ключевыми моментами, описанными в этой статье:

Используйте математические расчеты VRAM, чтобы логически выбрать размер модели и уровень квантования, оптимальные для характеристик вашего ПК.
Используйте Ollama для максимально быстрой настройки среды и интегрируйте её с ИИ-редакторами для резкого повышения производительности.
Раскройте предельные возможности оборудования с помощью продвинутого контроля параметров в llama.cpp.
Создайте безопасную локальную систему RAG для работы с конфиденциальными данными с помощью AnythingLLM.
Используйте Unsloth (WSL2), чтобы вырастить собственного персонализированного ИИ, обладающего вашими экспертными знаниями.

«Демократизация» ИИ — это больше не модное словечко, а реальная система, работающая на вашем рабочем столе Windows. Освободитесь от затрат на облачные API и рисков утечки информации, и прямо сейчас сделайте шаг в свободный и мощный мир приватного ИИ.