AI 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.

Без Python! Я создал движок ИИ-вывода только на C++

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

1. Введение: Почему стоит отказаться от Python и создать движок ИИ-вывода на C++?

В современной разработке ИИ Python является стандартом де-факто. Благодаря мощным фреймворкам, таким как PyTorch и TensorFlow, можно создавать, обучать и запускать сложные нейронные сети всего несколькими строками кода. Однако за кулисами этих фреймворков стоят низкоуровневые языки, такие как C++ и CUDA, которые берут на себя тяжелые вычислительные процессы. Python играет лишь роль «клея».

Так зачем же отказываться от Python и создавать движок ИИ-вывода исключительно на C++? Для этого есть несколько веских причин:

Максимальная производительность и низкая задержка: Полностью устраняются накладные расходы, связанные с GIL (Global Interpreter Lock) в Python и динамической типизацией. Особенно в системах, требующих работы в реальном времени, задержка в миллисекундах может быть критичной.
Простота развертывания: Настроить среду Python (огромное количество библиотек, ад зависимостей) на стороне конечного пользователя очень сложно. В случае C++ достаточно распространять один скомпилированный исполняемый бинарный файл (с расширением .exe или ELF-бинарник) со статической линковкой.
Поддержка периферийных устройств (Edge Devices): В средах с жесткими ограничениями ресурсов, таких как смартфоны, встраиваемые устройства или Raspberry Pi, нет возможности запускать среду выполнения Python, потребляющую гигабайты памяти.
Прямое управление оборудованием: C++ позволяет осуществлять низкоуровневый контроль, такой как выбор времени выделения памяти, явное использование SIMD-инструкций и оптимизация передачи данных в память GPU.

В этой статье мы подробно, погружаясь в технические глубины, рассмотрим процесс создания с нуля движка вывода для запуска больших языковых моделей (LLM) исключительно на C++, черпая огромное вдохновение в архитектуре библиотеки «GGML», разработанной Георгием Гергановым (Georgi Gerganov).

2. Общая архитектура движка вывода

Процесс вывода ИИ по своей сути представляет собой «непрерывную серию огромных матричных вычислений». Для эффективного выполнения этой задачи движок вывода должен состоять из следующих компонентов:

graph TD A["Входные данные (Токены/Изображения)"] --> B["Управление тензорами"] B --> C["Граф вычислений (DAG)"] C --> D["Арена памяти и Аллокатор"] C --> E["Планировщик и Пул потоков"] E --> F["Бэкенд CPU (AVX2/ARM NEON)"] E --> G["Бэкенд GPU (CUDA/Metal)"] F --> H["Выходные результаты"] G --> H

Управление тензорами (Tensor Management): Управление структурами данных многомерных массивов и шагом (Stride) для каждого измерения.
Граф вычислений (Computation Graph): Представление операций каждого слоя нейронной сети в виде направленного ациклического графа (DAG).
Арена памяти (Memory Arena): Механизм предварительного выделения памяти, позволяющий избежать накладных расходов на динамическое выделение памяти (malloc или new).
Бэкенд (Backend): Реализация вычислений (ядер), оптимизированная для конкретного оборудования, такого как CPU или GPU.

Мы будем собирать эти компоненты, используя мощные возможности C++ (шаблоны, адресная арифметика указателей, RAII и т.д.).

3. Секреты управления памяти: Арена памяти и SIMD-выравнивание

Управление памятью в движке вывода — один из самых важных факторов, напрямую влияющих на производительность. Во время вывода, особенно при прохождении через каждый слой модели Transformer, генерируется огромное количество промежуточных тензоров. Если каждый раз выделять и освобождать их с помощью стандартного malloc, фрагментация кучи и переключение контекста ОС приведут к фатальному падению скорости.

Поэтому мы применим подход, называемый «Арена памяти (Memory Arena)». Этот метод заключается в вычислении (или фиксированном задании) максимального объема памяти, необходимого в начале вывода, ее выделении одним блоком и последующем распределении памяти простым увеличением (инкрементом) указателя.

3.1 Важность выравнивания (Alignment)

Современные процессоры поддерживают SIMD-инструкции (Single Instruction, Multiple Data). К ним относятся AVX2/AVX-512 от Intel/AMD и NEON от ARM. Эти инструкции обрабатывают 256 бит (32 байта) или 512 бит (64 байта) данных за один раз, но требуют, чтобы обрабатываемые данные в памяти были выровнены по определенной границе байтов (обычно 32 или 64 байта).

Ниже приведен пример реализации арены памяти на C++ с учетом выравнивания.

 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


#include <cstdint>
#include <cstddef>
#include <stdexcept>
#include <iostream>

struct MemoryArena {
 size_t size;
 size_t offset;
 uint8_t* data;

 MemoryArena(size_t size) : size(size), offset(0) {
 // Использование posix_memalign для POSIX систем и _aligned_malloc для Windows
#ifdef _WIN32
 data = static_cast<uint8_t*>(_aligned_malloc(size, 64));
#else
 if (posix_memalign(reinterpret_cast<void**>(&data), 64, size) != 0) {
 throw std::bad_alloc();
 }
#endif
 }

 ~MemoryArena() {
#ifdef _WIN32
 _aligned_free(data);
#else
 free(data);
#endif
 }

 void* allocate(size_t bytes, size_t alignment = 64) {
 // Вычисление выравнивания (определение отступа)
 size_t pad = (alignment - (offset % alignment)) % alignment;
 if (offset + pad + bytes > size) {
 throw std::runtime_error("OOM: MemoryArena out of memory");
 }
 offset += pad;
 void* ptr = data + offset;
 offset += bytes;
 return ptr;
 }

 void reset() {
 offset = 0; // Освобождение памяти — это просто возврат указателя (O(1))
 }
};

Таким образом, при создании тензора память всегда получается через эту арену. Просто вызывая reset() после завершения каждого шага вывода (например, генерации каждого токена), можно мгновенно повторно использовать память.

4. Магия структуры данных тензоров и шагов (Stride)

Тензор — это концепция, обобщающая скаляры, векторы и матрицы. Важным моментом в реализации является то, что фактические данные располагаются в памяти в виде одномерного непрерывного массива, но при этом существует понятие «шага (Stride)», позволяющее интерпретировать их как многомерные.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


enum class DataType {
 FP32,
 FP16,
 INT8, // Для квантования
 INT4 // Для квантования
};

struct Tensor {
 int n_dims; // Количество измерений
 int64_t ne[4]; // Количество элементов в каждом измерении (Number of Elements)
 size_t nb[4]; // Шаг каждого измерения в байтах (Number of Bytes)
 DataType type; // Тип данных
 void* data; // Указатель на полезную нагрузку

 // Для графа вычислений
 enum OpType op;
 Tensor* src0;
 Tensor* src1;
};

Шаг nb[i] представляет собой расстояние в байтах в памяти между соседними элементами в измерении i. Например, если матрица с количеством элементов $M \times N$ (FP32, 1 элемент = 4 байта) хранится в формате Row-Major (по строкам), шаги будут следующими:

nb[0] = 4 (байта) : Перемещение по столбцам
nb[1] = $N \times 4$ (байта) : Перемещение по строкам

Используя это, можно реализовать такие операции, как «Транспонирование (Transpose)» или «Представление (View)» без копирования памяти, просто поменяв местами значения шагов. Это очень элегантно и быстро.

5. Построение графа вычислений (DAG) и ленивые вычисления

Подобно PyTorch и другим, наш движок вывода также использует концепцию ленивых вычислений (Lazy Evaluation), близкую к «Define-by-Run». То есть, в момент вызова функции вычисления сами вычисления не выполняются, а строится только граф (зависимости между узлами).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Tensor* tensor_add(MemoryArena& arena, Tensor* a, Tensor* b) {
 Tensor* out = create_tensor(arena, a->type, a->n_dims, a->ne);
 out->op = OpType::ADD;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Tensor* tensor_mul_mat(MemoryArena& arena, Tensor* a, Tensor* b) {
 // b часто бывает транспонирован
 int64_t ne[2] = { a->ne[0], b->ne[1] };
 Tensor* out = create_tensor(arena, a->type, 2, ne);
 out->op = OpType::MUL_MAT;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Поток процесса вывода выглядит следующим образом:

graph LR A["Определение тензоров"] --> B["Построение графа через операции"] B --> C["Топологическая сортировка"] C --> D["Выделение памяти для выходных данных"] D --> E["Выполнение узлов по порядку"]

При оценке графа (прямой проход - forward pass) используется топологическая сортировка для последовательного выполнения узлов, начиная с тех, у которых нет зависимостей. Поскольку это только вывод, нет необходимости хранить градиенты для обратного распространения ошибки, что делает управление памятью очень простым.

6. Ядро математики и оптимизации: Умножение матриц (GEMM)

Более 90% вычислительной нагрузки при выводе ИИ тратится на общее умножение матриц (GEMM: General Matrix Multiply). Механизм внимания (Attention) и полносвязные сети (Feed-Forward Networks, FFN), являющиеся ядром моделей Transformer, в конечном итоге сводятся к огромным матричным умножениям.

Произведение $C = A B$ (размер $M \times N$) двух матриц $A$ (размер $M \times K$) и $B$ (размер $K \times N$) можно выразить математически следующим образом:

$$ C_{i,j} = \sum_{k=0}^{K-1} A_{i,k} \cdot B_{k,j} $$

Если реализовать это в виде простого тройного цикла, будут постоянно возникать промахи кэша, и производительность будет нулевой.

6.1 Кэш-блокировка на CPU и оптимизация SIMD

Базовые стратегии для ускорения GEMM на CPU следующие:

Разбиение циклов на тайлы (Кэш-блокировка - Cache Blocking): Разделение матрицы на небольшие блоки, помещающиеся в кэш L1/L2, и вычисление по ним.
Упаковка данных (Data Packing): Внутренняя перестановка данных для обеспечения последовательного паттерна доступа к памяти.
Использование SIMD: Использование инструкций FMA (Fused Multiply-Add), таких как _mm512_fmadd_ps в AVX-512, для выполнения множества операций умножения-сложения за один тактовый цикл.

Ниже приведен пример упрощенного скалярного произведения векторов (Dot Product) с использованием C++ и SIMD Intrinsics.

 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


#include <immintrin.h> // Для инструкций AVX

// Быстрое скалярное произведение для FP32 с использованием AVX2
float dot_product_avx2(const float* a, const float* b, int n) {
 __m256 sum256 = _mm256_setzero_ps();
 int i = 0;

 // Обработка по 8 элементов за раз (256 бит = 32 байта = 8 * 4 байта)
 for (; i <= n - 8; i += 8) {
 __m256 va = _mm256_loadu_ps(a + i);
 __m256 vb = _mm256_loadu_ps(b + i);
 // Инструкция FMA: sum256 = va * vb + sum256
 sum256 = _mm256_fmadd_ps(va, vb, sum256);
 }

 // Горизонтальное сложение значений в SIMD регистре
 float result[8];
 _mm256_storeu_ps(result, sum256);
 float dot = result[0] + result[1] + result[2] + result[3] +
 result[4] + result[5] + result[6] + result[7];

 // Обработка остатка
 for (; i < n; ++i) {
 dot += a[i] * b[i];
 }
 return dot;
}

Даже эта небольшая хитрость позволяет увеличить скорость в несколько, а то и в десяток раз по сравнению с наивной реализацией.

7. Преодоление аппаратных барьеров: Интеграция бэкендов CUDA и Metal

Хотя чистая реализация на C++ работает довольно неплохо на CPU, для запуска гигантских моделей, таких как LLM, с приемлемой скоростью (например, генерация 20 и более токенов в секунду) вычислительные возможности GPU становятся необходимыми. Для этого мы внедряем в наш движок уровень абстракции бэкендов.

7.1 Абстракция бэкенда

Используя полиморфизм в C++, мы можем переключать исполнителей операций (Executors).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class Backend {
public:
 virtual ~Backend() = default;
 virtual void alloc_buffer(Tensor* t) = 0;
 virtual void free_buffer(Tensor* t) = 0;
 virtual void copy_to_device(Tensor* t) = 0;
 virtual void copy_to_host(Tensor* t) = 0;

 // Выполнение различных операций
 virtual void compute_add(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
 virtual void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
};

7.2 Реализация бэкенда NVIDIA CUDA

Для использования графических процессоров NVIDIA мы реализуем бэкенд с помощью расширения CUDA C++. Можно написать собственные ядра, но для умножения матриц лучше всего использовать «cuBLAS» — библиотеку высшего класса, предоставляемую самой NVIDIA.

 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


#include <cublas_v2.h>
#include <cuda_runtime.h>

class CUDABackend : public Backend {
private:
 cublasHandle_t handle;

public:
 CUDABackend() {
 cublasCreate(&handle);
 }

 ~CUDABackend() {
 cublasDestroy(handle);
 }

 void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) override {
 // В CUDA по умолчанию используется формат Column-Major, поэтому нужно быть осторожным с параметрами
 const float alpha = 1.0f;
 const float beta = 0.0f;

 int m = src0->ne[0];
 int k = src0->ne[1];
 int n = src1->ne[1]; // предполагается, что src1 транспонирован

 cublasSgemm(handle, CUBLAS_OP_T, CUBLAS_OP_N,
 m, n, k,
 &alpha,
 (const float*)src0->data, k,
 (const float*)src1->data, k,
 &beta,
 (float*)dst->data, m);
 cudaDeviceSynchronize();
 }
};

Передача данных (cudaMemcpy) между памятью CUDA и памятью хоста (CPU) очень «тяжелая», поэтому критически важен дизайн, при котором все веса (тензоры весов) и промежуточные тензоры по возможности хранятся в VRAM (видеопамяти) на протяжении всего вывода.

7.3 Бэкенд Apple Silicon (Metal)

В последние годы процессоры Mac M1/M2/M3 (Apple Silicon) показывают превосходные результаты в качестве машин для вывода ИИ. Причина кроется в их «объединенной памяти» (Unified Memory). Поскольку CPU и GPU делят одну и ту же область памяти, высокозатратная передача данных между хостом и устройством по шине PCIe, как в случае с CUDA, описанным выше, становится совершенно не нужной.

Для вызова Metal из C++ используется Objective-C++ (файлы .mm) в качестве моста, либо библиотека metal-cpp. Мы описываем ядра с помощью Metal Compute Shader (написанных в файлах .metal в стиле C++).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// Шейдер Metal (kernel.metal)
#include <metal_stdlib>
using namespace metal;

kernel void mul_mat_kernel(
 device const float* A [[buffer(0)]],
 device const float* B [[buffer(1)]],
 device float* C [[buffer(2)]],
 constant uint3& dims [[buffer(3)]],
 uint2 gid [[thread_position_in_grid]]
) {
 uint m = dims.x; uint k = dims.y; uint n = dims.z;
 uint row = gid.y; uint col = gid.x;

 if (row < m && col < n) {
 float sum = 0.0;
 for (uint i = 0; i < k; ++i) {
 sum += A[row * k + i] * B[i * n + col]; // Упрощено
 }
 C[row * n + col] = sum;
 }
}

В среде Apple Silicon также предоставляется библиотека оптимизации умножения матриц MPS (Metal Performance Shaders), поэтому при ее использовании в реальных задачах можно добиться потрясающей скорости вывода.

8. Специфическая обработка для моделей Transformer: Attention и кэш KV

Передовые LLM, такие как LLaMA 2/3 и GPT, основаны на архитектуре Transformer. Для реализации этого на C++ необходимо создать «Scaled Dot-Product Attention», который описывается следующей формулой:

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

Кроме того, при авторегрессионной (Autoregressive) генерации токенов необходимо сохранять результаты вычислений прошлых токенов (Key и Value). Это называется «KV-кэшем (Key-Value Cache)».

graph TD T["Текущий токен"] --> Q["Запрос (Query)"] T --> K["Ключ (Key)"] T --> V["Значение (Value)"] K --> KCache["Добавить в кэш KV"] V --> VCache["Добавить в кэш KV"] Q --> Dot1["Q * K_Cache^T"] KCache --> Dot1 Dot1 --> Scale["Масштабирование (1/sqrt(d))"] Scale --> Softmax["Softmax"] Softmax --> Dot2["SoftmaxOut * V_Cache"] VCache --> Dot2 Dot2 --> Out["Контекстный вектор"]

Для KV-кэша также применяется стратегия предварительного выделения в арене пространства памяти, достаточного для максимальной длины контекста (например, 4096 или 8192 токена), и его использование по принципу кольцевого буфера. Это предотвращает необходимость перераспределения памяти на каждом шаге генерации.

Кроме того, для позиционного кодирования (Positional Encoding) реализуется «RoPE (Rotary Position Embedding)», который стал мейнстримом в последние годы. Это метод встраивания информации о позиции в виде вектора вращения в комплексном пространстве, где ключом к производительности является оптимизация вызовов функций sin и cos в C++ (например, путем создания таблиц поиска).

9. Экстремальная оптимизация посредством квантования моделей (Quantization)

Если загрузить большую модель (например, модель LLaMA с 7 миллиардами параметров) в формате FP32 (32-битное число с плавающей запятой), то только веса займут около 28 ГБ памяти (VRAM). А если добавить к этому KV-кэш и буферы для вывода, объем легко превысит 30 ГБ, что делает выполнение на обычных потребительских видеокартах невозможным.

Здесь на помощь приходит «Квантование (Quantization)». Это истинная сила формата GGML.

Квантование — это технология намеренного снижения точности весов.

FP16 (16-бит): Размер уменьшается вдвое. Потеря точности практически отсутствует.
INT8 (8-бит): Размер уменьшается в 4 раза. Незначительная потеря точности.
INT4 (4-бит): Размер уменьшается в 8 раз. Использование уникальных факторов блокировки и масштабирования позволяет осуществлять вывод с приемлемым качеством.

На стороне движка вывода сжатые в INT4 (или INT8) веса считываются из памяти и развертываются (Dequantize) в FP16 или FP32 сразу после их загрузки в регистры CPU или GPU, после чего выполняются вычисления.

Удивительно, но выгоднее уменьшить объем данных, считываемых из памяти, даже ценой увеличения количества вычислений. Это связано с тем, что в современном оборудовании узким местом при задачах вывода является не «вычислительная мощность (Compute Bound)», а «пропускная способность памяти (Memory Bandwidth Bound)». Движок, реализованный на C++ с квантованием INT4, позволяет быстро запускать локальные LLM даже на MacBook Air с 8 ГБ объединенной памяти.

10. Тюнинг производительности: Архитектура NUMA и пул потоков

При выполнении вывода с использованием CPU многопоточность обязательна. Однако простого запуска множества std::thread будет недостаточно для достижения оптимальных результатов.

Современные многопроцессорные серверы и высокопроизводительные процессоры, такие как Ryzen Threadripper, используют архитектуру NUMA (Non-Uniform Memory Access). Доступ ядра CPU к физически близкой к нему памяти (локальной памяти) осуществляется быстро, но доступ к памяти, привязанной к другому процессору, становится крайне медленным.

В продвинутых движках вывода на C++ используются следующие техники:

Привязка потоков (Thread Pinning): Закрепление каждого потока за определенным ядром CPU (установка Affinity) для предотвращения сброса кэша из-за переключения контекста.
NUMA-ориентированное выделение памяти: Выделение памяти на том же узле NUMA, где находится поток, обрабатывающий данные.
Пул потоков с кражей работы (Work-Stealing): Реализация эффективного планировщика, который разбивает каждый узел графа вычислений на мелкие задачи, и свободные потоки автоматически «крадут» и выполняют эти задачи.

Полное использование этих методов позволяет удерживать загрузку CPU близко к 100% и достигать пропускной способности, близкой к теоретическому максимуму.

11. Заключение: Удовольствие от работы с ИИ на «мускулах» C++

Python, безусловно, удобен. В области исследований и разработки, а также создания прототипов нет языка, способного сравниться с ним в продуктивности. Однако, как только вы переходите на этап, когда готовую модель необходимо «эффективно запускать в реальном мире на любых устройствах», наступает время для C++.

Когда вы видите, как движок вывода, созданный путем прямого манипулирования массивами байтов в памяти, максимального использования регистров через SIMD-инструкции и борьбы за пропускную способность VRAM графического процессора, один за другим генерирует на консоли токены естественного текста — вы испытываете чувство глубокого удовлетворения, «чистую радость инженера», которую невозможно получить, просто вызвав model.generate() во фреймворке Python.

Технологии ИИ часто кажутся «черным ящиком», но, написав все своими руками на C++, от тензорных операций до выделения памяти, вы сможете глубоко понять истинные механизмы того, как «мыслит» LLM.

Если вы обладаете базовыми знаниями C++ и глубоко интересуетесь современными технологиями ИИ, обязательно попробуйте создать свой собственный движок вывода. Исходный код GGML и llama.cpp станет для вас лучшим живым учебником.

Итак, отбросьте тяжелую среду выполнения Python и позвольте передовому ИИ работать на мощных мускулах C++!

Как быстрее всего настроить TinyLLaMA в локальной (on-premises) среде

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

1. Введение: Почему именно сейчас TinyLLaMA и локальная среда?

Эволюция больших языковых моделей (LLM) идет с невероятной скоростью, и вместе с этим количество параметров моделей продолжает разрастаться до сотен миллиардов. Хотя сверхгигантские модели, такие как GPT-4 и Claude 3, обладают непревзойденной производительностью, вычислительные затраты на инференс и обучение, а также проблемы безопасности и конфиденциальности данных при использовании внешних API стали серьезным препятствием для бизнеса. В частности, при работе с высококонфиденциальными внутренними данными компании или личной информацией, отправка данных в публичные API LLM в облаке часто недопустима с точки зрения соблюдения нормативных требований (таких как GDPR, APPI и др.).

Именно поэтому в центре внимания оказались малые языковые модели (SLM: Small Language Models) и локальная эксплуатация в on-premises среде. Среди них «TinyLLaMA» при компактном размере всего 1.1B (1,1 миллиарда) параметров была предварительно обучена на огромном наборе данных объемом около 3 триллионов токенов, демонстрируя поразительную производительность по сравнению с моделями того же класса.

В этой статье мы представляем полное руководство по файнтюнингу (тонкой настройке) TinyLLaMA в локальной среде (на локальном сервере или рабочей станции) «максимально быстро и эффективно» для ваших собственных специализированных задач. Мы всесторонне рассмотрим всё: от математических основ до новейших технологий оптимизации и конкретного кода реализации на PyTorch.

2. Архитектура и особенности TinyLLaMA

TinyLLaMA следует архитектуре LLaMA (Large Language Model Meta AI), разработанной компанией Meta. При ограничении количества параметров до 1.1B она использует тот же технологический стек, что и LLaMA 2, что обеспечивает ей чрезвычайно высокую совместимость в экосистеме.

Основные компоненты архитектуры

RMSNorm (Root Mean Square Normalization): Это метод нормализации, который опускает вычитание среднего значения из традиционного вычисления LayerNorm, тем самым повышая эффективность вычислений. Это увеличивает пропускную способность при сохранении стабильности обучения.
Функция активации SwiGLU: В сети прямого распространения (Feed Forward Network, FFN) вместо традиционных ReLU или GELU используется SwiGLU. Математически это выражается следующим образом: $$ \text{SwiGLU}(x, W, V) = \text{Swish}(xW) \otimes (xV) $$ Здесь $\otimes$ обозначает поэлементное произведение (произведение Адамара), а функция Swish — это $\text{Swish}(z) = z \cdot \sigma(\beta z)$. Это значительно повышает выразительность.
RoPE (Rotary Position Embedding): Это метод, сочетающий преимущества абсолютного и относительного позиционного кодирования. Он обладает высокой обобщающей способностью даже при увеличении длины последовательности.
Grouped Query Attention (GQA): Это промежуточный подход между Multi-Head Attention (MHA) и Multi-Query Attention (MQA), который значительно увеличивает скорость инференса и экономит пропускную способность памяти за счет группировки голов ключей (key) и значений (value).

Следующая диаграмма Mermaid показывает общий поток данных TinyLLaMA и структуру блока Transformer.

graph TD A["Входной текст"] --> B["Токенизатор (BPE)"] B --> C["Слой Embedding"] C --> D["Блоки Transformer (x22 слоя для TinyLLaMA)"] D --> E["RMSNorm (Финальный)"] E --> F["Линейная проекция (Размер словаря)"] F --> G["Выходные вероятности (Softmax)"] subgraph "Анатомия блока Transformer" D1["Входное скрытое состояние"] --> D2["RMSNorm"] D2 --> D3["Grouped Query Attention (GQA)"] D3 --> D4["Остаточное сложение (Residual Add)"] D4 --> D5["RMSNorm"] D5 --> D6["SwiGLU FFN"] D6 --> D7["Остаточное сложение (Residual Add)"] D7 --> D8["Выход на следующий слой"] D1 -.-> D4 D4 -.-> D7 end

3. Прорыв в файнтюнинге: LoRA и QLoRA

Для выполнения полного файнтюнинга параметров в локальной среде, даже для модели 1.1B, требуются десятки гигабайт видеопамяти (VRAM) для хранения состояний оптимизатора и градиентов. Для эффективного обучения с ограниченными ресурсами необходимы методы PEFT (Parameter-Efficient Fine-Tuning), такие как «LoRA» и её квантованное расширение «QLoRA».

3.1 Математические основы LoRA (Low-Rank Adaptation)

LoRA — это метод, который фиксирует (замораживает) предварительно обученную матрицу весов и аппроксимирует обновление весов ($\Delta W$) как произведение двух небольших матриц низкого ранга.

Пусть предварительно обученные веса равны $W_0 \in \mathbb{R}^{d \times k}$. При полном файнтюнинге обновляется сама $W_0$ до $W_0 + \Delta W$, но в LoRA матрица обновлений $\Delta W$ разлагается следующим образом:

$$ \Delta W = B \times A $$

Здесь $B \in \mathbb{R}^{d \times r}$, $A \in \mathbb{R}^{r \times k}$, а $r$ — это гиперпараметр, называемый рангом (Rank), который является очень маленьким значением (обычно 8, 16, 32 и т.д.), удовлетворяющим условию $r \ll \min(d, k)$.

Вычисление прямого прохода выглядит следующим образом:

$$ h = W_0 x + \Delta W x = W_0 x + B A x $$

В начальном состоянии матрица $A$ инициализируется случайным образом с нормальным (гауссовым) распределением, а матрица $B$ инициализируется нулевой матрицей. В результате $\Delta W$ в начале обучения равна нулю, и мы можем начать обучение, полностью сохраняя выходные данные базовой модели.

graph LR X["Входной вектор x"] --> W0["Замороженные предварительно обученные веса (W_0)"] X --> A["Обучаемая матрица LoRA A (r x k)"] A --> B["Обучаемая матрица LoRA B (d x r)"] W0 --> Add["Сложение векторов"] B --> Add Add --> Y["Выходной вектор h"]

3.2 Инновационность QLoRA (Quantized LoRA)

QLoRA развивает подход LoRA дальше, квантуя базовую модель $W_0$ с 4-битной точностью (NormalFloat 4, NF4) и загружая её в память. Это кардинально снижает потребление VRAM.

В QLoRA интегрированы три ключевые технологии:

Квантование 4-bit NormalFloat (NF4): Теоретически оптимальный тип данных, оптимизированный для весов, распределенных по нормальному закону.
Двойное квантование (Double Quantization): Квантование самих констант квантования (масштабных коэффициентов) для дополнительной экономии памяти.
Paged Optimizers: Механизм, использующий функцию объединенной памяти (unified memory) NVIDIA для временной выгрузки состояний оптимизатора в оперативную память CPU (RAM) при нехватке VRAM.

Благодаря этому тюнинг, который обычно требует от 16 до 24 ГБ VRAM, может быть легко выполнен даже на потребительских GPU (таких как RTX 3060 12GB или RTX 4070).

4. Требования к оборудованию и настройка в локальной среде

Требования к оборудованию для тюнинга TinyLLaMA (1.1B) с помощью QLoRA очень низки.

Настройка программной среды

Процедура настройки предполагается для среды Ubuntu 22.04 LTS. Мы будем использовать Python 3.10 или новее.

1
2
3
4
5
6
7
8
9


# Создание и активация виртуальной среды
python3 -m venv tinyllama_env
source tinyllama_env/bin/activate

# Установка PyTorch (для CUDA 12.1)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# Установка библиотек, связанных с трансформерами
pip install transformers datasets peft trl accelerate bitsandbytes

5. Методы оптимизации для самого быстрого тюнинга

Для завершения тюнинга «максимально быстро» недостаточно просто запустить скрипт, необходимо комбинировать следующие методы оптимизации.

5.1 Flash Attention 2

Стандартный механизм внимания (Attention) имеет временную и пространственную сложность $O(N^2)$ для длины последовательности $N$. Flash Attention 2 оптимизирует доступ к памяти между SRAM и HBM (High Bandwidth Memory) GPU, устраняя узкое место ввода-вывода (IO) без сокращения вычислений, что в разы увеличивает скорость обучения и кардинально снижает потребление памяти.

5.2 Gradient Checkpointing (Чекпойнтинг градиентов)

Это метод, при котором в VRAM сохраняются не все промежуточные активации, вычисленные при прямом проходе, а лишь некоторые из них; остальные пересчитываются при обратном проходе, когда это необходимо. Время вычислений увеличивается примерно на 20%, но потребление памяти значительно сокращается, что позволяет установить больший размер батча (batch size) и в итоге повысить общую пропускную способность.

5.3 Обучение со смешанной точностью (Mixed Precision Training) и Bfloat16

Для максимального использования тензорных ядер (Tensor Cores) GPU вычисления при обучении выполняются в bfloat16 (Brain Floating Point). По сравнению с float16 длина бита экспоненты у него такая же, как у float32, поэтому риск переполнения и потери значимости (overflow/underflow) крайне низок, что делает обучение стабильным.

6. Практика: Код файнтюнинга TinyLLaMA с помощью QLoRA

Теперь давайте разберем скрипт PyTorch для самого быстрого тюнинга, который включает в себя все вышеупомянутые оптимизации. Здесь мы будем использовать SFTTrainer из библиотеки Hugging Face trl (Transformer Reinforcement Learning).

6.1 Подготовка набора данных и загрузка модели

 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


import torch
from datasets import load_dataset
from transformers import (
 AutoModelForCausalLM,
 AutoTokenizer,
 BitsAndBytesConfig,
 TrainingArguments
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

# 1. Указание модели и токенизатора
model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# 2. Настройка 4-битного квантования для QLoRA
bnb_config = BitsAndBytesConfig(
 load_in_4bit=True,
 bnb_4bit_use_double_quant=True,
 bnb_4bit_quant_type="nf4",
 bnb_4bit_compute_dtype=torch.bfloat16 # Вычисления производятся в bfloat16
)

# 3. Загрузка модели (Включение Flash Attention 2)
print("Loading model...")
model = AutoModelForCausalLM.from_pretrained(
 model_id,
 quantization_config=bnb_config,
 device_map="auto",
 use_flash_attention_2=True # Ключ к максимальной скорости
)

# 4. Загрузка токенизатора
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right" # Устанавливаем right для предотвращения багов при обучении fp16/bf16

6.2 Применение адаптера LoRA и форматирование набора данных

 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


# 5. Подготовка к k-bit обучению и включение чекпойнтинга градиентов
model.gradient_checkpointing_enable()
model = prepare_model_for_kbit_training(model)

# 6. Настройка LoRA
peft_config = LoraConfig(
 r=16, # Ранг
 lora_alpha=32, # Масштабный коэффициент
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] # Ориентация на все линейные слои улучшает производительность
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()
# Пример вывода: trainable params: 14,286,848 || all params: 1,114,335,232 || trainable%: 1.282%

# 7. Загрузка набора данных (В качестве примера используется японский датасет инструкций)
# На практике здесь загружается локальный приватный JSONL файл и т.д.
dataset = load_dataset("kunishou/databricks-dolly-15k-ja", split="train")

def format_instruction(sample):
 """
 Форматирует строку в соответствии с форматом ChatML или шаблоном промпта
 """
 prompt = f"<|im_start|>user\n{sample['instruction']}"
 if sample.get("input", "") != "":
 prompt += f"\n{sample['input']}"
 prompt += f"<|im_end|>\n<|im_start|>assistant\n{sample['output']}<|im_end|>"
 return {"text": prompt}

dataset = dataset.map(format_instruction)

6.3 Выполнение обучения

 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


# 8. Настройка аргументов обучения
training_args = TrainingArguments(
 output_dir="./tinyllama-lora-output",
 per_device_train_batch_size=8, # Увеличьте, если есть свободная VRAM
 gradient_accumulation_steps=2, # Эффективный размер батча = 8 * 2 = 16
 optim="paged_adamw_32bit", # Экономия VRAM с помощью Paged Optimizer
 save_steps=100,
 logging_steps=10,
 learning_rate=2e-4,
 fp16=False,
 bf16=True, # Обучение со смешанной точностью (bfloat16)
 max_grad_norm=0.3,
 max_steps=500, # 500 шагов для тестирования. В реальности указывайте количество эпох
 warmup_ratio=0.03,
 group_by_length=True,
 lr_scheduler_type="cosine",
)

# 9. Запуск обучения с помощью SFTTrainer
trainer = SFTTrainer(
 model=model,
 train_dataset=dataset,
 peft_config=peft_config,
 dataset_text_field="text",
 max_seq_length=1024, # Настройте в соответствии с ожидаемой длиной входа
 tokenizer=tokenizer,
 args=training_args,
)

print("Starting training...")
trainer.train()

# 10. Сохранение адаптера LoRA
trainer.model.save_pretrained("./tinyllama-lora-final")
tokenizer.save_pretrained("./tinyllama-lora-final")
print("Training complete and model saved.")

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

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

Возникает ошибка OOM (Out Of Memory):
- Уменьшите per_device_train_batch_size до 1.
- Увеличьте gradient_accumulation_steps, чтобы сохранить эффективный размер батча.
- Сократите max_seq_length с 2048 до 1024 или 512.
Loss (Потеря) не снижается или расходится:
- Возможно, скорость обучения (learning_rate) слишком высока. Попробуйте снизить её с 2e-4 до примерно 5e-5.
- Если используется Float16 вместо Bfloat16, возможно, происходит потеря значимости градиента (underflow). Проверьте наличие bf16=True.
При инференсе генерируются непонятные символы:
- Убедитесь, что padding_side="right" настроен правильно. Также необходимо проверить, соответствует ли формат датасета (специальные токены вроде <|im_start|>) формату базовой модели при предварительном обучении.

8. Развертывание модели (Deployment) после тюнинга

После завершения тюнинга сохраняется не “вся базовая модель”, а только “адаптер LoRA (веса разницы)” размером от нескольких до десятков мегабайт. Для быстрого инференса эти веса LoRA необходимо слить (merge) с исходной базовой моделью и экспортировать как единую модель.

Скрипт слияния модели

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import torch
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer

output_dir = "./tinyllama-lora-final"

# Загрузка модели и адаптера в формате FP16/BF16
model = AutoPeftModelForCausalLM.from_pretrained(
 output_dir,
 device_map="auto",
 torch_dtype=torch.bfloat16
)
tokenizer = AutoTokenizer.from_pretrained(output_dir)

# Слияние и сохранение весов
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./tinyllama-merged", safe_serialization=True)
tokenizer.save_pretrained("./tinyllama-merged")
print("Model merged and saved successfully!")

Запуск сверхбыстрого сервера инференса с помощью vLLM

Для максимизации скорости инференса (токенов в секунду) при развертывании в локальной среде настоятельно рекомендуется использовать vLLM или TGI (Text Generation Inference) вместо стандартного pipeline от Hugging Face. vLLM использует технологию PagedAttention для предотвращения фрагментации памяти GPU и кардинально увеличивает пропускную способность при параллельных запросах.

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

graph TD A["Сырые приватные данные"] --> B["Предобработка и форматирование (JSONL)"] B --> C["Файнтюнинг QLoRA (SFTTrainer)"] C --> D["Веса адаптера LoRA (.safetensors)"] D --> E["Слияние с базовой TinyLLaMA 1.1B"] E --> F["Слитая модель (Merged Model)"] F --> G["Развертывание через сервер vLLM"] G --> H["Конечная точка API / UI (например, Чат-бот)"]

Запуск API-сервера с использованием vLLM выполняется всего одной командой:

1
2
3
4
5
6


python -m vllm.entrypoints.openai.api_server \
 --model ./tinyllama-merged \
 --host 0.0.0.0 \
 --port 8000 \
 --max-model-len 2048 \
 --dtype bfloat16

Теперь в вашей локальной среде развернута конечная точка, совместимая с OpenAI API, что позволяет безопасно и быстро использовать локальный ИИ.

9. Заключение

В этой статье мы рассмотрели методы максимально быстрого и экономичного с точки зрения памяти файнтюнинга в локальной среде легкой, но высокопроизводительной модели «TinyLLaMA» с 1.1B параметров.

LoRA / QLoRA делают возможным полноценный тюнинг LLM даже на потребительских GPU.
Использование Flash Attention 2 и Gradient Checkpointing позволяет предельно оптимизировать время обучения и потребление VRAM.
Развертывание с помощью vLLM обеспечивает высокую пропускную способность даже в рабочей (production) среде.

Эксплуатация локальной LLM в on-premises среде не только защищает конфиденциальность данных, но и становится мощнейшим инструментом для создания по низким затратам специализированного ИИ, адаптированного для конкретных областей (юриспруденция, медицина, внутренние правила компании и т.д.). Пожалуйста, используйте это руководство для создания вашей собственной специализированной версии TinyLLaMA.

Как программистам выжить в эпоху ИИ?

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

Как программистам выжить в эпоху ИИ? Конец кодинга и рассвет новой инженерии

По состоянию на 2026 год сфера разработки программного обеспечения переживает период беспрецедентных потрясений. Всего несколько лет назад концепция «ИИ пишет код» сводилась, в лучшем случае, к роли «вспомогательного инструмента» программиста: генерации шаблонного кода (boilerplate) и автодополнению функций. Однако благодаря ошеломляющей эволюции больших языковых моделей (LLM) ситуация в корне изменилась. Современный ИИ — это не просто «умная пишущая машинка». Стоит лишь дать ему спецификацию требований, и он превращается в «автономного младшего инженера», способного мгновенно и самостоятельно собрать всю систему: от фронтенда до бэкенд-логики, проектирования схемы базы данных и даже настройки пайплайна CI/CD.

Как же в такую эпоху выжить нам, «программистам» и «инженерам-программистам»? В то время как экономическая ценность самого процесса «написания кода» стремительно падает, «кодеры», знающие лишь синтаксис конкретного языка программирования и хорошо разбирающиеся в API определенного фреймворка, быстро вытесняются с рынка.

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

1. История абстракции (Abstraction) и переосмысление «программирования»

Оглядываясь на историю программной инженерии, можно заметить, что это всегда была история «абстракции». Мы постоянно создавали слои, чтобы описывать всё более сложные системы на языке, всё более близком к человеческому.

Первые специалисты в области вычислительной техники с помощью перфокарт напрямую переключали физические тумблеры оборудования, отдавая компьютеру команды в машинном коде (последовательностях 0 и 1). Затем появился язык ассемблера, позволивший управлять оборудованием с помощью понятной человеку мнемоники. С течением времени появились высокоуровневые языки, такие как C и Fortran, которые успешно инкапсулировали сложные детали оборудования: управление памятью и регистры CPU. Появление современных языков, таких как Java, Python, Ruby и TypeScript, позволило программистам сосредоточиться не на том, «как заставить компьютер работать (How)», а на том, «что мы хотим, чтобы компьютер сделал (What)».

Появление ИИ (LLM) является новейшим и величайшим сдвигом парадигмы в этой истории абстракции. Если эволюция языков программирования заключалась в «сокрытии оборудования», то эволюция LLM — это «сокрытие синтаксиса (грамматики)».

graph TD A["Машинный код / Перфокарты (1940-е)"] --> B["Язык ассемблера (1950-е)"] B --> C["Компилируемые высокоуровневые языки (1970-е)"] C --> D["Управляемые / Скриптовые языки (1990-е)"] D --> E["Естественный язык через LLM (2020-е)"] E --> F["Автономные ИИ-агенты (2026-)"] style E fill:#f9f,stroke:#333,stroke-width:2px style F fill:#fbb,stroke:#333,stroke-width:2px

Эпоха, когда разработчики беспокоились об утечках памяти, управляя указателями, или писали сотни строк шаблонного кода для парсинга JSON, подошла к концу. Определение систем с использованием естественного языка (японского, английского и др.), как наиболее высокоуровневой абстракции для человечества, стало стандартом «программирования» в 2026 году.

2. Математическая модель продуктивности: на гребне волны экспоненциального роста

Давайте количественно оценим рост продуктивности, обусловленный ИИ, с помощью математической модели. Личную продуктивность $P_{traditional}$ в традиционной разработке программного обеспечения можно было смоделировать как линейную комбинацию уровня индивидуальных навыков $S$, опыта в предметной области $E$ и эффективности инструментов $T$.

$$ P_{traditional} = c_1 \cdot S + c_2 \cdot E + c_3 \cdot T $$

Однако в современной разработке с использованием ИИ возможности ИИ $A(t)$ действуют как «мощный рычаг (Multiplier)», усиливающий способности человека. Поскольку возможности ИИ растут экспоненциально с течением времени $t$ (версия закона Мура для ИИ), продуктивность в эпоху ИИ $P_{AI}(t)$ может быть выражена следующим уравнением:

$$ P_{AI}(t) = \alpha \cdot S_{core} \cdot e^{\beta \cdot A(t)} $$

Где каждая переменная означает следующее:

$\alpha$: Базовый коэффициент продуктивности человека
$S_{core}$: «Ключевые человеческие навыки», которые не может заменить ИИ (проектирование архитектуры, понимание бизнес-требований, этические суждения и т. д.)
$A(t)$: Абсолютные возможности модели ИИ в момент времени $t$ (количество параметров, размер контекстного окна, способность к рассуждениям)
$\beta$: Коэффициент, показывающий, насколько эффективно используются инструменты ИИ (качество промпт-инжиниринга и продуманность совместных рабочих процессов с ИИ)

Важный вывод из этой формулы заключается в том, что в мире, где $A(t)$ растет экспоненциально, традиционные навыки, такие как скорость печати или заучивание конкретного языка, оказывают крайне незначительное влияние на общую продуктивность. Вместо этого коэффициент $\beta$, позволяющий оседлать экспоненциальный рост ИИ, и $S_{core}$, представляющий собой область, недоступную ИИ, становятся доминирующими факторами, определяющими рыночную стоимость инженера.

3. Вероятность автоматизации задач (Probability of Automation)

Итак, какие задачи будут автоматизированы, а какие останутся в руках человека? Вероятность $P_{auto}(T)$ того, что задача $T$ будет полностью автоматизирована ИИ, может быть сформулирована следующим образом:

$$ P_{auto}(T) = 1 - \exp\left(-\lambda \cdot \frac{\text{Predictability}(T)}{\text{Complexity}(T) \times \text{Context Dependency}(T)}\right) $$

$\text{Predictability}(T)$: Предсказуемость задачи (насколько очевидны паттерны в исторических данных)
$\text{Complexity}(T)$: Сложность задачи
$\text{Context Dependency}(T)$: Сила «неявного контекста» (знаний, специфичных для предметной области, или человеческих отношений), от которого зависит задача
$\lambda$: Скорость технического прогресса ИИ

Задачи с высокой предсказуемостью и низкой зависимостью от контекста, такие как написание обработки маршрутизации API или создание простого экрана CRUD, будут иметь $P_{auto} \approx 1$ и автоматизируются почти полностью. С другой стороны, автоматизировать задачи с чрезвычайно высокой зависимостью от контекста, такие как «как безопасно интегрировать устаревшие системы (legacy) с новыми микросервисами» или «как спроектировать процесс аутентификации, который удовлетворяет требованиям юридического отдела, не портя пользовательский опыт», крайне сложно.

4. Возврат от синтаксиса (грамматики) к архитектуре (структуре)

Четкое разделение того, в чем хорош ИИ, и того, в чем силен человек, является абсолютным условием для выживания.

graph LR Sub1["Сферы превосходства ИИ"] Sub2["Сферы превосходства человека"] A["Генерация кода по спецификации"] --> Sub1 B["Синтаксические ошибки и исправление багов"] --> Sub1 C["Шаблонный код / Генерация тестов"] --> Sub1 D["Анализ логов и поиск паттернов"] --> Sub1 E["Проектирование системной архитектуры"] --> Sub2 F["Разрешение неоднозначных требований"] --> Sub2 G["Межгрупповые переговоры"] --> Sub2 H["Этическое суждение / Ответственность"] --> Sub2

ИИ превосходит человека в «локальной оптимизации». У человека нет шансов в скорости и точности написания одной функции, одного класса или одного модуля. Однако ИИ крайне уязвим перед «глобальной оптимизацией» и «отсутствием контекста (Missing Context)».

Отныне программисты должны сменить свою роль с «рабочих, пишущих код» на «архитекторов, оркеструющих бесчисленные компоненты, сгенерированные ИИ». Способность окинуть взглядом систему в целом, определить, где провести границы микросервисов, как разрешить компромисс между доступностью и согласованностью (теорема CAP) в бизнес-контексте, и как управлять техническим долгом — всё это высокоинтеллектуальная работа, которую может выполнять только человек, понимающий общую картину и бизнес-цели.

5. Определение требований — это и есть «истинный промпт-инжиниринг»

Термин «промпт-инжиниринг», который так часто звучит в последнее время, нередко ошибочно воспринимается как «хак для обмана ИИ с целью получения желаемого результата». Однако суть промпт-инжиниринга в разработке программного обеспечения, несомненно, заключается в «продвинутом определении требований (Requirements Engineering)».

Чтобы дать ИИ инструкции на естественном языке и получить именно то программное обеспечение, которое было задумано, необходимо строго вербализовать следующие элементы:

Цель (Why): Зачем нужна эта функция. Какова ее бизнес-ценность.
Ограничения (Constraints): Требования к производительности (задержка, пропускная способность), требования к безопасности, ограничения по стоимости.
Пограничные случаи (Edge Cases): Резервная логика (fallback) на случай неожиданного ввода пользователя.
Интерфейсы (Interfaces): Спецификации интеграции с существующими системами.

Из расплывчатых инструкций (промптов) рождаются только расплывчатые и хрупкие системы. Способность глубоко выяснять, «что на самом деле хотел клиент», разрешать противоречивые требования и создавать спецификации (промпты) без логических изъянов — это и есть самый сильный «навык кодинга» в эпоху ИИ. Программисты будут проводить всё больше времени не в редакторах кода, а в Notion или Markdown-файлах, тщательно описывая идеальное состояние системы текстом.

6. Подавляющее преимущество предметных знаний (Domain Knowledge)

Поскольку ИИ обучается на открытом исходном коде и публичной документации со всего мира, он хорошо разбирается в общих веб-технологиях и алгоритмах. Однако есть данные, к которым у ИИ нет доступа. Это «уникальные бизнес-правила вашей компании» и «глубоко укоренившиеся знания предметной области (домена), специфичные для конкретной отрасли (медицина, финансы, производство и т. д.)».

Например, предположим, что медицинский стартап разрабатывает систему электронных медицинских карт. ИИ знает, «как создать табличный интерфейс в React» или «общую структуру данных HL7 FHIR». Однако он не знает таких неявных вещей, как «в определенном отделении больницы А, в каком порядке врач просматривает данные пациента и какой пользовательский интерфейс сведет к минимуму риск врачебной ошибки».

В мире, где сами технологии становятся коммодити (товаром широкого потребления), истинная ценность инженера рождается на пересечении «технологий» и «бизнес-домена». Рынок будущего возглавят не те, кто конкурирует только за счет технических навыков, а те, кто обладает глубокими экспертными знаниями в конкретной предметной области (медицина, финансы, логистика, развлечения и др.) и может решать её проблемы, используя ИИ как мощный инструмент.

7. «Проблема вагонетки» в разработке ПО: кто несет ответственность?

По мере роста нашей зависимости от ИИ мы сталкиваемся с серьезной философской и этической проблемой — проблемой «локализации ответственности» в программной инженерии.

Если код, автономно сгенерированный ИИ, вызовет серьезный баг в продакшене, который принесет компании убытки в миллионы долларов, или приведет к сбою в медицинской системе, от которой зависят жизни людей, кто будет нести ответственность? Компания, разработавшая модель ИИ? Или инженер, который ввел промпт? ИИ нельзя «уволить» или «арестовать».

Роль «человека» как субъекта, берущего на себя «юридическую и этическую ответственность (Accountability)» за влияние системы на общество, не исчезнет, как бы ни развивались технологии. Напротив, чем более непрозрачным (black box) становится процесс генерации кода, тем большую ответственность несет человек как «финальный утверждающий (Approver)» и «контролер (Supervisor)» системы.

Аудит предложенной ИИ архитектуры и кода на соответствие стандартам безопасности, отсутствие этических проблем (таких как предвзятость), соблюдение нормативных требований (комплаенс) и, наконец, выдача окончательного разрешения. Сам акт «принятия ответственности» становится важной частью работы инженера.

8. Парное программирование с ИИ и управление когнитивной нагрузкой (Cognitive Load)

При работе с ИИ природа «когнитивной нагрузки (Cognitive Load)» человека также меняется. Когнитивная нагрузка при написании кода с нуля и когнитивная нагрузка при «чтении и ревью» сотен строк неизвестного кода, сгенерированного ИИ, — это совершенно разные вещи.

Согласно психологической теории когнитивной нагрузки, когда мы обрабатываем сложную информацию, которая не соответствует нашим существующим схемам (структурам знаний в голове), наша рабочая память быстро истощается. Код, сгенерированный ИИ, иногда содержит продвинутые оптимизации, до которых человек мог бы не додуматься, но при этом может содержать «галлюцинации», игнорирующие контекст.

Чтобы предотвратить это, необходимо систематизировать процесс ревью для ИИ.

sequenceDiagram participant H as "Инженер-человек (Архитектор)" participant A as "ИИ-агент" participant S as "CI/CD и Тестирование" H->>A: "Определить строгие требования и ограничения" A->>H: "Предложить архитектуру и начальный код" Note over H,A: Фаза ревью: Высокая когнитивная нагрузка H->>A: "Критиковать выбор дизайна, попросить рефакторинг" A->>S: "Сгенерировать финальный код и отправить" S-->>H: "Результаты автоматических тестов и статического анализа" H->>H: "Финальное одобрение и принятие ответственности"

Людям необходимо развивать навыки «скорочтения и мгновенного выявления логических ошибок (Code Reading & Auditing)» в еще большей степени, чем навыки «написания». Важность разработки через тестирование (TDD) в эпоху ИИ возрастает еще больше. До того, как позволить ИИ писать код, преобладающим подходом станет тот, при котором человек или другой ИИ пишет строгие тестовые сценарии, а затем заставляет ИИ исправлять код до тех пор, пока он не пройдет эти тесты.

9. Конкретные стратегии выживания: что изучать завтра

Основываясь на проведенном выше анализе, предлагаем конкретный план действий для выживания программистов в эпоху ИИ.

Тщательно изучите «основы» технологий: Использование фреймворков можно доверить ИИ. Однако глубокое понимание устройства ОС, сетевых протоколов (TCP/IP, HTTP/3), внутреннего устройства баз данных (B-Tree, уровни изоляции транзакций), а также структур данных и алгоритмов является абсолютно необходимым. Прочный фундамент компьютерных наук (Computer Science) жизненно важен для того, чтобы судить о правильности результатов ИИ.
Освойте облачную архитектуру и распределенные системы: Сосредоточьтесь не на написании отдельных кусков кода, а на том, как комбинировать облачные ресурсы AWS, GCP или Azure для создания масштабируемых систем. Поймите концепцию IaC (Infrastructure as Code), например Terraform, и развивайте способность проектировать всю систему в виде кода.
Станьте экспертом в бизнес-домене: Глубоко изучите бизнес-модель, нормативно-правовую базу и психологию поведения пользователей в вашей отрасли. Выходите за рамки обычного инженера и стремитесь к взгляду, близкому к продакт-менеджеру (PM).
Оттачивайте навыки коммуникации и фасилитации: Процесс разрешения «неоднозначностей» между людьми и достижения консенсуса не может быть заменен ИИ. Soft skills (гибкие навыки), необходимые для общения со стейкхолдерами и выявления истинных проблем, станут самыми ценными.
Используйте ИИ как своего «коллегу»: Не бойтесь эволюции инструментов ИИ, а используйте их как свое самое мощное оружие. Ежедневно применяйте новейшие LLM и ИИ-агенты для кодинга, накапливая «неявные знания» о том, где ИИ ошибается и как нужно изменить промпт, чтобы добиться от него максимальной эффективности.

Заключение: не бойтесь, оседлайте волну

Автоматизация программирования с помощью ИИ не означает «смерть» профессии программиста. Скорее, это «Ренессанс (возрождение)», который освобождает нас от «несущественного труда» в разработке ПО: исправления опечаток, устранения проблем при настройке окружения или написания скучного шаблонного кода.

Исторически сложилось так, что с появлением автоматических ткацких станков или электронных таблиц (Excel) преобладал пессимизм по поводу исчезновения рабочих мест. Но в реальности резкий скачок продуктивности создал новый спрос и привел к появлению более продвинутой работы. То же самое произойдет и в мире программного обеспечения. По мере того, как «создавать системы становится дешевле», ПО будет проникать во все те области, которые раньше не были автоматизированы из-за нерентабельности, и количество проблем (What), которые должны решать инженеры, будет расширяться бесконечно.

Сегодня мы, программисты, получили шанс эволюционировать от ремесленников, пишущих код, до «дирижеров оркестра», управляющих мощным интеллектом ИИ. Вместо того чтобы со страхом перед технологической волной оставаться на берегу, давайте как можно скорее оседлаем эту волну и отправимся в путешествие за созданием всё более масштабных и ценных систем. Эпоха ИИ — это время, когда начинается истинная «инженерия».

Разработка небольших ИИ-моделей (таких как TinyLLaMA) на C++

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

Руководство по разработке небольших ИИ-моделей (таких как TinyLLaMA) на C++

В последние годы стремительно растет интерес к запуску больших языковых моделей (LLM) в локальных средах. В частности, небольшие модели, такие как TinyLLaMA (1,1 млрд параметров), могут осуществлять вывод с практической скоростью даже на периферийных устройствах с ограниченными ресурсами и обычных ноутбуках (включая среды Windows). В то время как разработка с использованием Python и PyTorch является мейнстримом, для достижения максимальной производительности и экономии памяти де-факто стандартом становится комбинация C++ и основанной на C тензорной библиотеки “ggml”.

В этой статье будет представлено очень подробное пошаговое руководство по разработке для создания механизма вывода с нуля (или глубокого понимания внутренней структуры существующего llama.cpp) для загрузки TinyLLaMA и генерации текста с использованием C++.

1. Почему C++ и ggml?

На этапе обучения ИИ Python имеет подавляющее преимущество благодаря своей гибкости и богатой экосистеме. Однако на этапах развертывания и “вывода” (Inference) C++ становится мощным выбором по следующим причинам:

Снижение накладных расходов: Можно полностью исключить глобальную блокировку интерпретатора (GIL) и накладные расходы времени выполнения Python.
Эффективность памяти и выделение арены: Поскольку выделение и освобождение памяти можно контролировать вручную, предотвращаются непредсказуемые всплески, вызванные сборкой мусора.
Прямой доступ к оборудованию: Можно напрямую вызывать встроенные функции SIMD (Intrinsics), такие как AVX-512, AVX2, ARM NEON, чтобы максимально использовать вычислительную мощность процессора.
Отсутствие зависимостей: ggml — это библиотека C/C++ с нулевыми зависимостями (Zero dependencies), которую можно легко собрать даже в среде MSVC на Windows, если есть компилятор.

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

Общий поток конвейера вывода показан на диаграмме Mermaid ниже. Это серия процессов, начиная с введенного пользователем текста и заканчивая генерацией следующего токена.

graph TD A["Введенный пользователем текст"] --> B["Токенизатор BPE"] B --> C["Массив ID токенов"] C --> D["Поиск в слое Embedding"] D --> E["Блоки Transformer"] E --> F["RMSNorm"] F --> G["Слой LM Head"] G --> H["Массив логитов"] H --> I["Модуль Sampler"] I --> J["ID следующего токена"] J --> K["Детокенизатор"] K --> L["Фрагмент выходного текста"] J -.-> |"Добавить в контекст"| C

Поскольку это авторегрессионная модель, выведенный токен снова добавляется в контекст и циркулирует как входные данные для прогнозирования следующего токена (пунктирная линия на диаграмме).

3. Формат модели и отображение памяти (mmap)

Самым большим препятствием при работе с весами гигантских нейронных сетей являются дисковый ввод-вывод и потребление памяти. В реализации на C++ это решается с помощью отображения памяти (mmap).

3.1 Механизм отображения памяти и реализация в Windows

С помощью mmap содержимое файла можно напрямую отобразить в виртуальное адресное пространство процесса.

Zero-copy (Нулевое копирование): Данные считываются непосредственно с диска в страничный кэш ядра, и лишнее копирование в пользовательское пространство не происходит.
Загрузка по требованию (Page Fault): В тот момент, когда процессор фактически обращается к этому адресу памяти, происходит ошибка страницы (page fault), и в физическую память загружается только необходимый фрагмент (обычно 4 КБ).

В среде Windows вместо POSIX mmap используются API Win32 CreateFileMapping и MapViewOfFile.

sequenceDiagram participant OS["ОС Windows"] participant RAM["Физическая память"] participant App["Приложение C++"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "Указатель адреса виртуальной памяти" App->>App: "Чтение тензорных данных по указателю" OS->>RAM: "Ошибка страницы / Загрузка страницы с диска" RAM-->>App: "Данные готовы для вычислений SIMD"

3.2 Бинарная структура формата GGUF

GGUF (GPT-Generated Unified Format), преобразованный из таких форматов, как .safetensors на Hugging Face, является идеальным форматом для вывода. Он имеет строгую бинарную структуру, как показано ниже:

Magic Bytes: 0x46554747 (GGUF).
Version: Номер версии формата.
Tensor Count & Metadata Count: Количество тензоров и количество пар ключ-значение метаданных.
Metadata (Key-Value Pairs): Ключи с префиксом длины строки и типизированные значения.
Tensor Info: Имя каждого тензора, количество измерений, тип данных (FP16, Q4_K и т.д.) и позиция смещения в файле.
Padding: Заполнение (padding), вставляемое для того, чтобы тензорные данные были выровнены по определенной границе (обычно 32 или 64 байта). Это важно для быстрого доступа к памяти с помощью инструкций SIMD (особенно AVX).
Tensor Data: Массив выровненных фактических данных весов.

4. Математические основы TinyLLaMA и алгоритмы C++

TinyLLaMA включает в себя несколько продвинутых архитектурных хитростей для повышения эффективности. Мы объясним математические выражения, необходимые для их правильной реализации на C++.

4.1 RMSNorm (Нормализация среднеквадратичного значения)

Затраты на вычисления снижаются за счет отказа от центрирования по среднему значению из LayerNorm и выполнения только масштабирования дисперсии.

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

Где $d$ — количество измерений, а $\gamma$ — обученный тензор масштабирования. При реализации на C++ сначала быстро вычисляется сумма квадратов массива с помощью _mm256_fmadd_ps из AVX2 и оптимизируется путем умножения на обратный квадратный корень (например, инструкция _mm256_rsqrt_ps).

4.2 RoPE (Rotary Position Embedding)

Это метод, который применяет информацию о позиции токена в виде вращения в тензорном пространстве. Его можно рассматривать как вращение на комплексной плоскости, и к соседней паре измерений $(x_1, x_2)$ вектора $x$ применяется следующее вращение:

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

Где $m$ — абсолютный индекс позиции токена, а $\theta$ — предварительно вычисленная базовая частота. В ggml это выполняется параллельно просто путем добавления оператора ggml_rope во время построения графа вывода.

4.3 Grouped-Query Attention (GQA)

В обычном Multi-Head Attention (MHA) количество голов для Query, Key и Value одинаково. Однако TinyLLaMA использует Grouped-Query Attention (GQA), чтобы радикально снизить пропускную способность памяти и потребление кэша KV.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d_k}}\right) V $$

В GQA несколько голов Query совместно используют одну голову Key/Value. В реализации C++ перед выполнением матричного умножения ggml_mul_mat требуется операция широковещательной рассылки (broadcast) тензора KV в соответствии с количеством Query.

4.4 Функция активации SwiGLU

В слоях Feed-Forward Network (FFN) вместо GELU используется SwiGLU.

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

В вычислительном графе это выражается путем объединения оператора ggml_silu и ggml_mul.

5. Построение вычислительного графа и управление памятью с помощью ggml

ggml использует подход “Define-and-Run” (определи и запусти), при котором строится статический вычислительный граф для вывода, а затем вычисляется (evaluate).

5.1 ggml_context и распределитель арены (Arena Allocator)

Самая уникальная особенность ggml — это “выделение арены” (arena allocation), которое вообще не выполняет динамическое выделение памяти (malloc или new) внутри цикла вывода. При инициализации выделяется огромная непрерывная область памяти (арена), и указатель этой области увеличивается (increment) каждый раз при вызове ggml_new_tensor и т.д. Когда один шаг вывода завершен, достаточно сбросить указатель выделения в исходное положение, и выделение памяти для следующего шага вывода мгновенно завершается.

5.2 Конкретный пример построения графа

Для каждого шага вывода в памяти собирается следующий вычислительный граф.

graph TD A["Входные ID токенов"] --> B["Поиск Embed"] B --> C["ggml_rms_norm"] C --> D["Проекции Q / K / V"] D --> E["Позиционное ggml_rope"] E --> F["Сохранение в кэш KV"] E --> G["Загрузка из кэша KV"] G --> H["Self Attention"] H --> I["Масштабирование и Softmax"] I --> J["Вывод Attention"] J --> K["Выходная проекция"] K --> L["Добавление Residual"]

6. Квантование (Quantization) и оптимизация Windows / SIMD

Если обрабатывать TinyLLaMA (1.1B) в формате FP16, потребуется около 2,2 ГБ памяти, но с помощью 4-битного квантования (например, Q4_K) её можно радикально сжать примерно до 600 МБ.

6.1 Архитектура блочного квантования

ggml не квантует весь тензор единообразно, а делает это по «блокам». В формате Q4_0 32 значения FP16 объединяются в один блок.

Масштабный коэффициент (Scale factor): 1 значение FP16 (2 байта)
Квантованные данные: 32 4-битных значения (16 байт) Это сводит к минимуму влияние локальных выбросов.

6.2 Ускорение скалярного произведения с помощью AVX2

При сборке для новейших процессоров x86 в среде Windows использование флагов компилятора, таких как /arch:AVX2, обеспечивает обработку SIMD в следующем потоке:

Загрузка: Загрузка 4-битных квантованных данных из памяти в 256-битный регистр AVX.
Распаковка: Развертывание 4-битных значений в Int8 или Int16 с помощью битовых масок и операций сдвига.
Деквантование (Обратное квантование): Умножение на масштабный коэффициент для преобразования в число с плавающей запятой.
Операция FMA: Параллельное выполнение операций умножения с накоплением (multiply-add) со значениями активации с помощью _mm256_fmadd_ps (Fused Multiply-Add).

7. Детали реализации кэша KV

В авторегрессионной генерации «кэш KV» является важной функцией для пропуска вычисления Key и Value для прошлых токенов.

Ключевые моменты при реализации на C++:

Предварительное выделение тензора: Инициализируйте огромный тензор для кэша KV на максимальную длину контекста (например, 2048 токенов) (рекомендуется FP16).
Копирование со смещением: Когда выполняются вычисления для позиции токена $N$, векторы K и V, полученные на этом шаге, сохраняются в $N$-й строке тензора кэша KV с помощью ggml_cpy и т.д.
Создание представления (view) во время Attention: При вычислении Attention создается «представление» (view), указывающее только на часть токенов от 0 до $N$, которое передается в матричное умножение.

8. Токенизатор BPE и декодирование

Входная строка обрабатывается как последовательность байтов UTF-8 и сравнивается с заранее определенным словарем. В C++ для ускорения поиска по словарю реализуются алгоритмы с использованием Trie-дерева (префиксного дерева) или очереди с приоритетом.

Из логитов (logits), выводимых из LM Head, вероятности масштабируются с использованием параметра Temperature, кандидаты сужаются с помощью методов Top-K или Top-P (Nucleus Sampling), а затем случайные числа используются для определения конечного следующего токена.

9. Настройка проекта C++ (среда Windows / PowerShell)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# Настройки оптимизации и флага AVX2 для Windows (MSVC)
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

Пример команды сборки в PowerShell:

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. Заключение

Реализация механизма вывода для небольших ИИ-моделей, таких как TinyLLaMA, с нуля с использованием C++ и ggml — это отличная возможность раскрыть черный ящик глубокого обучения и оценить красоту низкоуровневого управления аппаратным обеспечением. Давайте прокладывать путь в будущее периферийного ИИ (Edge AI), в полной мере наслаждаясь сутью системного программирования, такой как загрузка без копирования с использованием отображения памяти, оптимизация SIMD и создание кэша KV.

【Введение в реализацию RAG】Как заставить локальный ИИ читать ваши документы

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

Введение

В последние годы развитие больших языковых моделей (LLM) поражает воображение: множество ИИ, во главе с ChatGPT и Claude, проникают в нашу жизнь и работу. Однако у обычных LLM есть очевидная слабость: они знают только “публичную информацию на момент обучения”. Естественно, они не могут ответить на вопросы, касающиеся “приватных документов”, таких как внутренние правила компании, личные заметки или неопубликованные проектные материалы. Если попытаться заставить их ответить, возрастает риск генерации правдоподобной лжи, не соответствующей действительности (галлюцинаций).

В связи с этим сегодня в мире взрывными темпами распространяется технологическая архитектура RAG (Retrieval-Augmented Generation: генерация с дополненной выборкой). Использование RAG позволяет динамически предоставлять LLM собственные знания из внешней базы данных, на основе которых можно генерировать точные и обоснованные ответы.

Кроме того, при работе с корпоративными данными или личной конфиденциальной информацией передача данных в облачные API, такие как OpenAI, часто недопустима с точки зрения политики безопасности. Именно здесь возникает потребность в создании “Локального RAG” в сочетании с локальным ИИ (LLM, полностью работающей на вашем ПК или локальном сервере).

В этой статье мы подробно рассмотрим все: от базовой теории RAG до конкретных методов реализации локального RAG с использованием Python, математической основы (механизм векторного поиска) и продвинутых методов запуска системы в рабочую среду.

1. Общая архитектура RAG

RAG — это не единая модель ИИ, а системная архитектура, в которой взаимодействуют несколько компонентов. Она условно делится на две фазы: “фаза поглощения (загрузка данных)” и “фаза поиска и генерации”.

Следующая диаграмма Mermaid показывает общую картину системы RAG.

graph TD subgraph "Фаза поглощения (Предварительная подготовка)" Doc["Собственные документы (PDF, TXT и т.д.)"] --> Loader["Загрузчик документов"] Loader --> Splitter["Разделение текста (Чанкинг)"] Splitter --> EmbedModel1["Модель встраивания (Embedding)"] EmbedModel1 --> VectorDB["Векторная база данных"] end subgraph "Фаза вывода (При запросе пользователя)" User["Вопрос пользователя (Запрос)"] --> EmbedModel2["Модель встраивания (Embedding)"] EmbedModel2 --> QueryVector["Вектор запроса"] QueryVector --> Search["Поиск по сходству (Векторный поиск)"] VectorDB --> Search Search --> Context["Извлечение связанных фрагментов (Контекст)"] User --> PromptBuilder["Построение промпта"] Context --> PromptBuilder PromptBuilder --> LocalLLM["Локальная LLM"] LocalLLM --> Answer["Генерация окончательного ответа"] end

Фаза поглощения (Предварительная подготовка)

Загрузка документов: Загрузка неструктурированных данных, таких как PDF, Word, текстовые файлы и т.д.
Чанкинг (разделение текста): Разделение длинных текстов на осмысленные фрагменты (чанки) для того, чтобы они поместились в ограничение на ввод LLM (контекстное окно) и для повышения точности поиска.
Эмбеддинг (векторизация): Передача разделенных чанков в модель встраивания (Embedding Model) и преобразование их в массивы чисел (векторы) размерностью от сотен до тысяч.
Сохранение в базу данных: Сохранение преобразованных векторов и связывание их с исходными текстовыми данными в векторной базе данных (Vector DB).

Фаза вывода (Во время выполнения)

Векторизация запроса: Векторизация вопроса пользователя с использованием той же модели встраивания, что и при предварительной подготовке.
Поиск по сходству: Расчет сходства между вектором запроса и векторами документов в базе данных для получения нескольких наиболее семантически близких (релевантных) фрагментов текста.
Построение промпта: Объединение полученных связанных текстов в качестве “контекста (фоновых знаний)” с вопросом пользователя для создания промпта ввода в LLM.
Генерация ответа: Получив расширенный промпт, LLM генерирует ответ на основе предоставленной контекстной информации.

2. Глубокое понимание векторного поиска и встраиваний (Embeddings)

В основе RAG лежит “векторный поиск (семантический поиск)”. В отличие от традиционного поиска по ключевым словам (например, BM25), который основан на точном совпадении и частоте слов, векторный поиск основан на “смысловом сходстве”. Например, даже если используются разные слова, такие как “собака” и “щенок”, “ПК” и “компьютер”, они будут найдены, если их значения близки.

Что такое модель встраивания (Embedding Model)?

Модель встраивания — это нейронная сеть, которая принимает на вход текст на естественном языке и выводит плотный вектор (Dense Vector) фиксированной длины. Обычные модели (например, text-embedding-3-small или модель с открытым исходным кодом multilingual-e5-large) отображают текст в векторы вещественных чисел размерностью 384 или 1024.

В этом многомерном пространстве (скрытом пространстве) они обучены так, что чем ближе по смыслу предложения, тем меньше расстояние между ними в координатном пространстве.

Математическая основа расчета сходства: Косинусное сходство

Когда векторная база данных ищет связанные документы, наиболее часто используемой метрикой расстояния является косинусное сходство (Cosine Similarity). В отличие от евклидова расстояния (абсолютного расстояния в пространстве), косинусное сходство фокусируется на “угле между двумя векторами”. Поскольку оно менее подвержено влиянию длины предложения (нормы вектора), оно очень хорошо подходит для расчета сходства текстов.

В виде формулы косинусное сходство между векторами $\mathbf{A}$ и $\mathbf{B}$ выглядит следующим образом:

$$ \text{Cosine Similarity}(\mathbf{A}, \mathbf{B}) = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}} $$

$\mathbf{A} \cdot \mathbf{B}$ обозначает скалярное произведение (Dot Product).
$\|\mathbf{A}\|$ обозначает L2-норму (длину) вектора $\mathbf{A}$.
$n$ — это размерность вектора.

Косинусное сходство принимает значения от -1 до 1.

Ближе к 1: направления двух векторов почти совпадают (очень схожи по смыслу)
Ближе к 0: два вектора перпендикулярны (не связаны)
Ближе к -1: два вектора указывают в противоположные стороны (противоположные по смыслу)

Современные векторные БД (Chroma, FAISS, Qdrant и т.д.) используют алгоритм приближенного поиска ближайших соседей (ANN), называемый HNSW (Hierarchical Navigable Small World), который оптимизирован для поиска документов с высоким косинусным сходством среди миллионов векторных данных за миллисекунды.

3. Технологический стек для создания локального RAG

Для создания полностью локального RAG, не зависящего от облака, мы будем использовать экосистему с открытым исходным кодом. Ниже представлен рекомендуемый технологический стек.

Языковая модель (LLM)
- Инструмент: Ollama или Llama.cpp
- Модель: легкие и высокопроизводительные открытые модели, такие как Llama-3-8B-Instruct, Gemma-2-9B-It, Qwen2-7B-Instruct. Для задач на японском языке подходят модели, настроенные на японский язык, такие как Llama-3-ELYZA-JP-8B.
Модель встраивания (Embedding)
- Модель: intfloat/multilingual-e5-large или BAAI/bge-m3. При локальном запуске обычно их скачивают с Hugging Face и запускают с помощью Sentence-Transformers.
Векторная база данных (Vector DB)
- ChromaDB: основана на Python, очень проста в настройке. Идеально подходит для локальной разработки.
- FAISS: высокоскоростная библиотека векторного поиска, разработанная Meta.
- Qdrant / Milvus: для более масштабных проектов и рабочих сред.
Фреймворк оркестрации
- LangChain: фактический стандарт для связывания (Chain) компонентов.
- LlamaIndex: фреймворк для подключения данных, специально ориентированный на RAG.

В этот раз мы реализуем систему, используя самую простую в освоении комбинацию: LangChain + ChromaDB + Ollama + HuggingFaceEmbeddings.

4. Учебное руководство по реализации: Создание полного локального RAG на Python

Начиная с этого момента, мы будем создавать локальный RAG, написав фактический код на Python. Пожалуйста, предварительно установите Ollama на свой ПК и запустите его в фоновом режиме. Также загрузите модель в Ollama (например: ollama run llama3).

Шаг 1: Установка необходимых библиотек

1
2


pip install langchain langchain-community langchain-huggingface
pip install chromadb sentence-transformers pypdf

Шаг 2: Обзор кода реализации

Ниже представлен полный Python-скрипт для загрузки PDF-файла, его векторизации и ответов на вопросы с помощью локальной LLM.

 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


import os
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.llms import Ollama
from langchain_core.prompts import PromptTemplate
from langchain.chains import RetrievalQA

def main():
 # 1. Загрузка документов
 print("Загрузка документов...")
 # Укажите путь к PDF, который нужно загрузить
 file_path = "sample_company_policy.pdf"
 loader = PyPDFLoader(file_path)
 documents = loader.load()

 # 2. Разделение на чанки (Text Splitting)
 # Разделение на фрагменты подходящего размера, не нарушая смысла текста
 text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500, # Максимальное количество символов в одном чанке
 chunk_overlap=50, # Количество перекрывающихся символов между чанками (предотвращает потерю контекста)
 separators=["\n\n", "\n", "。", "、", " ", ""]
 )
 chunks = text_splitter.split_documents(documents)
 print(f"Разделено на {len(chunks)} чанков.")

 # 3. Инициализация модели встраивания (Local HuggingFace Model)
 # Использование мультиязычной модели
 print("Загрузка модели встраивания...")
 embeddings = HuggingFaceEmbeddings(
 model_name="intfloat/multilingual-e5-large",
 model_kwargs={'device': 'cpu'} # Используйте 'cuda' или 'mps', если есть GPU
 )

 # 4. Создание векторной базы данных (Chroma)
 print("Создание векторной базы данных...")
 persist_directory = "./chroma_db"
 vectorstore = Chroma.from_documents(
 documents=chunks,
 embedding=embeddings,
 persist_directory=persist_directory
 )
 # Создание ретривера (поисковика). Настройка на получение топ-3 связанных документов
 retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

 # 5. Инициализация локальной LLM (Ollama)
 print("Подключение к локальной LLM...")
 # Предварительно загрузите модель, например, с помощью 'ollama pull llama3'
 llm = Ollama(model="llama3")

 # 6. Определение шаблона промпта
 prompt_template = """Вы - превосходный ассистент, хорошо разбирающийся в правилах и внутренней информации компании.
Используя ТОЛЬКО следующий контекст (фоновую информацию), подробно ответьте на вопрос пользователя.
Если ответ не может быть найден в контексте, не стройте догадок и честно ответьте «Я не могу найти ответ в предоставленной информации».

【Контекст】
{context}

【Вопрос】
{question}

【Ответ】:
"""
 PROMPT = PromptTemplate(
 template=prompt_template,
 input_variables=["context", "question"]
 )

 # 7. Создание цепочки RAG
 qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=retriever,
 return_source_documents=True, # Настройка возврата источников информации
 chain_type_kwargs={"prompt": PROMPT}
 )

 # 8. Выполнение вопроса
 query = "Расскажите об условиях оплаты транспортных расходов при удаленной работе."
 print(f"\nВопрос: {query}\n")

 result = qa_chain.invoke({"query": query})

 print("【Ответ】")
 print(result['result'])
 print("\n---")
 print("【Использованные источники】")
 for doc in result['source_documents']:
 print(f"- Страница {doc.metadata.get('page', 'неизвестно')}: {doc.page_content[:50]}...")

if __name__ == "__main__":
 main()

Объяснение ключевых моментов кода

RecursiveCharacterTextSplitter: Это наиболее рекомендуемый разделитель для естественного языка. Он пытается разделить текст в порядке: абзац (\n\n), строка (\n), точка (。), чтобы разделить текст таким образом, чтобы он уместился в заданный chunk_size, сохраняя при этом смысловые блоки насколько это возможно. Установив chunk_overlap, вы предотвращаете потерю информации на границах контекста.
HuggingFaceEmbeddings: intfloat/multilingual-e5-large — это очень мощная многоязычная модель встраивания с открытым исходным кодом. Вы можете векторизовать текст оффлайн в локальной памяти, не используя облачные API (например, text-embedding-ada-002 от OpenAI).
ChromaDB: Она работает в оперативной памяти или локальном хранилище (на базе SQLite), поэтому вам не нужно настраивать сложный сервер базы данных. Указав persist_directory, вы можете пропустить процесс векторизации при повторном выполнении и загрузить базу данных с диска.

5. Продвинутые методы RAG (Advanced RAG Techniques)

Базовая система RAG (Naive RAG), созданная в приведенном выше руководстве, также будет работать, но если в рабочей среде требуется высокая точность ответов, необходимо внедрить следующие продвинутые методы.

5.1 Гибридный поиск (Hybrid Search)

Векторный поиск хорошо справляется с пониманием “смысла”, но он может плохо справляться со строгим поиском по ключевым словам, таким как “определенные имена собственные”, “номера моделей продуктов” и “идентификаторы сотрудников”. Следовательно, параллельно выполняя семантический поиск (с помощью векторного поиска) и поиск по ключевым словам (с использованием алгоритмов типа BM25), а затем оценивая и объединяя результаты обоих подходов (используя методы типа Reciprocal Rank Fusion, RRF), можно радикально сократить количество пропусков в поиске.

5.2 Повторное ранжирование (Re-ranking)

Векторный поиск работает быстро, но он не обязательно оценивает точную контекстную релевантность. Общий конвейер для повышения точности поиска выглядит следующим образом:

Начальный поиск (First-stage Retrieval): Широкий и поверхностный поиск из векторной БД, извлечение примерно 20–30 связанных чанков.
Повторная оценка (Re-ranking): Использование другой, более “тяжелой” модели машинного обучения, называемой Cross-Encoder (например, bge-reranker), для подачи пар запроса пользователя и извлеченного чанка и пересчета баллов семантической релевантности.
Отбор: Только верхние 3–5 с наивысшими баллами передаются в промпт LLM в качестве окончательного контекста.

Этот метод предотвращает передачу нерелевантной шумовой информации в LLM и может значительно повысить точность (Precision) ответов.

graph LR Query["Запрос"] --> VSearch["Векторный поиск (топ 20)"] VSearch --> Reranker["Модель реранкера (Cross-Encoder)"] Query --> Reranker Reranker --> TopK["Высокоточные топ 3"] TopK --> LLM["Генерация LLM"]

5.3 Семантический чанкинг и поиск родительского документа

Существует метод под названием “Semantic Chunking” (Семантический чанкинг), который использует ИИ для обнаружения изменений в смысле предложений и разделяет текст на их основе, а не механически разбивает текст на фиксированное количество символов. Кроме того, существует метод “Parent Document Retriever” (Поиск родительского документа), в котором векторизация выполняется на очень маленьких единицах (например, предложениях) для высокоточного поиска, но при передаче в LLM передается “исходный большой абзац (родительский документ)”, содержащий это предложение, что обеспечивает LLM достаточным контекстом.

6. Проблемы и решения при эксплуатации локального RAG

При создании и эксплуатации RAG в локальной среде существуют специфические препятствия.

Нехватка VRAM (видеопамяти): Чтобы запустить локальную LLM с практичной скоростью (десятки токенов в секунду), вам необходимо загрузить модель в VRAM вашего GPU. Для работы модели класса 8B в формате fp16 (16-битная плавающая запятая) требуется около 16 ГБ VRAM, но с использованием технологии квантования (Quantization) (сжатие до 4 или 8 бит, например, в форматах GGUF или AWQ), ее можно заставить работать достаточно быстро даже на 8 ГБ VRAM (например, на стандартном игровом ПК). Llama.cpp и Ollama поддерживают эти форматы квантования из коробки.
Ограничение контекстного окна: Если объем полученного контекста слишком велик, он может превысить лимит ввода LLM (лимит токенов) или модель может “забыть” среднюю часть информации (феномен Lost in the middle). Важно настраивать количество извлекаемых чанков и тщательно отбирать их с помощью вышеупомянутых технологий реранжирования.
Управление свежестью данных: Если исходные документы обновляются, соответствующие векторы документов в векторной базе данных также должны быть обновлены или удалены (операции CRUD). Поскольку ChromaDB поддерживает обновление на основе идентификаторов документов, практично управлять хеш-значениями файлов и настраивать пакетную обработку для синхронизации только изменений.

Заключение

RAG (Retrieval-Augmented Generation) — это мощная парадигма, которая превращает ИИ из обычного универсального ассистента в вашего «персонального эксперта» или «эксперта, специализирующегося на ваших внутренних задачах».

Мы увидели, что даже с высокими требованиями к конфиденциальности, не позволяющими использовать облачные сервисы, можно относительно легко создать полноценную среду «локального RAG», комбинируя элементы экосистемы с открытым исходным кодом, такие как Ollama, LangChain и ChromaDB.

Основываясь на математическом понимании векторных пространств и продвинутых подходах, таких как разделение текста и реранжирование, рассмотренных в этой статье, попробуйте разработать собственную оригинальную систему ИИ, используя свои данные. Скорость эволюции локального ИИ поразительна, и система, которую вы построили сегодня, может быть мгновенно обновлена по производительности завтра, просто заменив ее на еще более умную легкую модель.

В этом блоге мы продолжим публиковать подробные статьи о технологиях ИИ и RAG. Если у вас есть какие-либо вопросы или отзывы, пожалуйста, оставьте их в разделе комментариев.

Подробное сравнение API ChatGPT, Gemini и Claude! Что выбрать?

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

Подробное сравнение API ChatGPT, Gemini и Claude! Что выбрать?

Развитие технологий ИИ поражает, особенно в области больших языковых моделей (LLM: Large Language Model), где ChatGPT (серия GPT) от OpenAI, Gemini от Google и Claude от Anthropic ведут ожесточенную борьбу за лидерство. По состоянию на 2026 год, каждая компания выпускает новые модели и функции API раз в несколько месяцев, а то и недель. Для разработчиков и ИТ-архитекторов вопрос «Какой API интегрировать в продукт?» стал важнейшим решением, определяющим успех проекта.

В этой статье мы подробно сравним и разберем API этих трех ведущих провайдеров ИИ с точки зрения разработчика. Мы не просто перечислим их характеристики, но и углубимся в архитектуру, подробную структуру тарифов, математический анализ задержки (latency), конкретные примеры реализации на Python и Node.js, а также в новейшие методы оптимизации затрат, такие как кэширование промптов.

Мы надеемся, что это руководство поможет вам выбрать идеальный API LLM для вашего юзкейса и создать масштабируемое, экономически эффективное ИИ-приложение.

1. Философия и принципы проектирования каждого LLM API

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

1.1 OpenAI (ChatGPT)

Миссия OpenAI — «создание универсального искусственного интеллекта (AGI)», и компания постоянно задает стандарты в отрасли. Они предлагают разнообразные модели для разных задач, включая GPT-4o, GPT-4o-mini, а также модели серии o1, специализирующиеся на логических рассуждениях. Экосистема OpenAI является самой зрелой, с огромным количеством официальных и неофициальных библиотек и документации.

1.2 Google (Gemini)

Google придерживается стратегии «AI First» (ИИ в первую очередь) и делает ставку на масштабируемость, максимально используя собственную инфраструктуру (сети TPU). Главная особенность Gemini 1.5 Pro/Flash — огромное контекстное окно до 2 миллионов токенов, что позволяет за один раз обрабатывать длинные документы и многочасовые видео или аудио. Тесная интеграция с Google Cloud (Vertex AI) также делает этот вариант привлекательным для корпоративного сектора.

1.3 Anthropic (Claude)

Anthropic, основанная бывшими сотрудниками OpenAI, использует уникальный подход к безопасности под названием «Конституционный ИИ (Constitutional AI)». Модели Claude 3.5 Sonnet и Opus завоевали огромную популярность среди разработчиков благодаря своим высоким способностям к рассуждению, генерации кода, а главное — благодаря «естественному диалогу, похожему на человеческий» и «низкому уровню галлюцинаций».

2. Подробное сравнение характеристик семейств моделей

Сравним характеристики основных моделей по состоянию на 2026 год.

Провайдер	Основная модель	Максимальный контекст	Главные преимущества	Рекомендуемые юзкейсы
OpenAI	GPT-4o	128K	Скорость, распознавание изображений, голосовой интерфейс	Интерактивные приложения, задачи общего назначения
OpenAI	o1-preview	128K	Продвинутая логика, математика, кодинг	Генерация сложных алгоритмов, исследовательские задачи
Google	Gemini 1.5 Pro	2,000K	Обработка сверхдлинных текстов, мультимодальность (видео/аудио)	Анализ огромных кодовых баз, суммаризация видео
Google	Gemini 1.5 Flash	2,000K	Низкая задержка, высокая пропускная способность, низкая стоимость	Обработка в реальном времени, пакетная обработка больших объемов данных
Anthropic	Claude 3.5 Sonnet	200K	Написание кода, генерация естественного текста	Помощь в разработке ПО, продвинутая поддержка клиентов
Anthropic	Claude 3.5 Haiku	200K	Сверхбыстрые ответы, экономичность	Периферийный ИИ (Edge AI), чат-боты в реальном времени

3. Глубокое погружение в архитектуру: что происходит за API-запросом

Какие процессы происходят на бэкенде при вызове LLM API? Чтобы оптимизировать производительность, необходимо понимать эту архитектуру.

Следующая диаграмма Mermaid показывает весь путь — от отправки API-запроса клиентом до возврата токенов в виде потока (streaming).

graph TD A["Клиентское приложение"] -->|HTTP/REST или gRPC| B["API-шлюз"] B --> C["Балансировщик нагрузки"] C --> D["Кластер вывода (Inference Cluster)"] D --> E["Токенизатор (BPE / SentencePiece)"] E --> F["KV Кэш и механизм внимания (Attention Mechanism)"] F --> G["Блоки Transformer (Прямой проход)"] G --> H["Выходной слой (Логиты)"] H --> I["Сэмплер (Температура, Top-p, Top-k)"] I --> J["Детокенизатор"] J -->|Потоковый ответ (Чанки)| A

3.1 Алгоритмы токенизации (Tokenization)

Текст, передаваемый в API, внутренне разбивается на единицы, называемые «токенами».

OpenAI (tiktoken): Использует Byte-Pair Encoding (BPE). Очень эффективно сжимает текст на английском языке, но для языков, не использующих латиницу (например, японского или русского), количество токенов может значительно возрастать.
Google (Gemini): Использует SentencePiece (Unigram Language Model). Отлично работает с разными языками, обычно требуя меньше токенов для текстов на отличных от английского языках.
Anthropic (Claude): Использует кастомную версию BPE. Улучшена мультиязычная поддержка, а начиная с версии Claude 3, эффективность токенизации для японского и других языков была существенно повышена.

4. Математический анализ задержки (Latency) и производительности

В приложениях реального времени задержка напрямую влияет на пользовательский опыт (UX). Задержку LLM API $T_{total}$ можно математически смоделировать следующим образом:

$$ T_{total} = T_{network} + T_{TTFT} + (N \times T_{TPOT}) $$

Где каждая переменная означает:

$T_{network}$: Время пути туда и обратно по сети (RTT).
$T_{TTFT}$ (Time To First Token): Время до генерации первого символа. Сильно зависит от затрат на расчет механизма внимания (Attention), который пропорционален квадрату длины промпта (количества входных токенов).
$N$: Общее количество сгенерированных токенов.
$T_{TPOT}$ (Time Per Output Token): Время генерации одного токена. Поскольку модели авторегрессионные, каждый следующий токен вычисляется последовательно на основе предыдущего вывода.

4.1 Сложность вычисления механизма внутреннего внимания (Self-Attention)

Вычислительная сложность внутреннего внимания (Self-Attention) в архитектуре Transformer возрастает квадратично относительно длины входной последовательности $L$.

$$ \text{Complexity} = O(L^2 \cdot d) $$

Где $d$ — размерность вектора встраивания (embedding). Из-за этого ограничения при увеличении промпта $T_{TTFT}$ обычно резко ухудшается. Однако в модели Gemini 1.5 от Google используются инновационные архитектурные оптимизации, такие как «Ring Attention» и «Block-wise Compute», что позволяет генерировать первый токен за разумное время (от нескольких секунд до нескольких десятков секунд) даже при подаче текста длиной в 2 миллиона токенов.

5. Структура тарифов и стратегии оптимизации затрат

Стоимость API в основном рассчитывается на основе количества входных и выходных токенов.

$$ Cost = (Tokens_{in} \times Rate_{in}) + (Tokens_{out} \times Rate_{out}) $$

Но в новейших API появились новые механизмы, позволяющие радикально снизить затраты.

5.1 Кэширование промптов (Prompt Caching)

Постоянная отправка длинных системных промптов или огромных объемов документов, извлеченных через RAG, каждый раз обходится очень дорого. Чтобы решить эту проблему, компании предлагают функции кэширования.

Anthropic (Claude) и Google (Gemini) позволяют кэшировать определенные блоки текста, снижая затраты на ввод (до 90%).

Модель затрат при использовании кэша выглядит так:

$$ Cost_{cached} = (Tokens_{cache\_write} \times Rate_{cache\_write}) + (Tokens_{cache\_read} \times Rate_{cache\_read}) + (Tokens_{out} \times Rate_{out}) $$

Где $Rate_{cache\_read}$ обычно составляет около 10-25% от стандартного $Rate_{in}$. Это позволяет дешево поддерживать работу чат-ботов, постоянно храня в фоне знания в виде десятков тысяч строк кодовой базы.

5.2 Пакетное API (Batch API)

Для задач, не требующих обработки в реальном времени (анализ логов, массовая классификация данных и т. д.), OpenAI и Anthropic предлагают Batch API. Это мощный механизм, позволяющий отправлять запросы группами и получать результаты в течение 24 часов со скидкой 50% (в два раза дешевле) от стандартной цены API.

6. Сравнение опыта разработчика (DX) и SDK

Сравним предлагаемые компаниями SDK (Software Development Kit) с точки зрения эффективности разработки.

6.1 OpenAI API

Используется шире всего, имеет самую быструю поддержку в сторонних библиотеках (LangChain, LlamaIndex и т.д.). Кроме того, функция Structured Outputs (Структурированный вывод) гарантирует 100% точность ответа в соответствии с заданной JSON-схемой, что делает системную интеграцию чрезвычайно простой.

6.2 Anthropic API (Claude)

Интерфейс SDK выглядит очень элегантно, и, по отзывам, работать с типами в TypeScript очень удобно. Структура Message API интуитивно понятна, что позволяет легко создавать мультимодальные запросы, включающие несколько изображений.

6.3 Google Gemini API

Существуют два типа доступа: через Google Cloud Vertex AI и через AI Studio (Google Gen AI SDK), что может немного запутать новичков. Тем не менее, Vertex AI SDK, предназначенный для энтерпрайз-клиентов, полностью интегрирован с системой аутентификации GCP (IAM), что позволяет создать безопасную среду разработки.

7. Практика! Интеграционное тестирование нескольких API на Python

В этом разделе мы используем Python для написания скрипта, который одновременно отправляет асинхронные запросы к трем API: OpenAI, Anthropic и Gemini, а затем сравнивает их задержки.

 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


import asyncio
import time
import os
from openai import AsyncOpenAI
from anthropic import AsyncAnthropic
import google.generativeai as genai

# Инициализация клиентов
openai_client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
anthropic_client = AsyncAnthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
genai.configure(api_key=os.environ.get("GEMINI_API_KEY"))

prompt = "Объясните основы квантовых вычислений и их влияние на современную криптографию простым языком для начинающих."

async def fetch_openai():
 start_time = time.time()
 response = await openai_client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "OpenAI (GPT-4o)", elapsed, response.choices[0].message.content

async def fetch_anthropic():
 start_time = time.time()
 response = await anthropic_client.messages.create(
 model="claude-3-5-sonnet-20240620",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "Anthropic (Claude 3.5 Sonnet)", elapsed, response.content[0].text

async def fetch_gemini():
 start_time = time.time()
 model = genai.GenerativeModel('gemini-1.5-pro')
 # Использование асинхронного метода из Gemini Python SDK
 response = await model.generate_content_async(prompt)
 elapsed = time.time() - start_time
 return "Google (Gemini 1.5 Pro)", elapsed, response.text

async def main():
 print("Отправка запросов к LLM API...")

 # Выполнение 3-х API параллельно
 results = await asyncio.gather(
 fetch_openai(),
 fetch_anthropic(),
 fetch_gemini()
 )

 for provider, latency, text in results:
 print(f"--- {provider} ---")
 print(f"Задержка: {latency:.2f} секунд")
 print(f"Ответ (фрагмент): {text[:100]}...\n")

if __name__ == "__main__":
 asyncio.run(main())

Запустив этот скрипт, вы сможете легко измерить, какая из моделей отвечает быстрее всего (минимизируя $T_{total}$) в реальных сетевых условиях.

8. Реализация вызова инструментов (Tool Calling / Function Calling) на Node.js

Чтобы заставить LLM работать не просто как чат-бот, а как «ИИ-агент», взаимодействующий с внешними системами, необходим функционал Tool Calling (или Function Calling). Ниже приведен пример на Node.js (TypeScript), в котором API OpenAI просят вызвать API погоды.

 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


import OpenAI from "openai";

const openai = new OpenAI({
 apiKey: process.env.OPENAI_API_KEY,
});

async function runAgent() {
 const tools = [
 {
 type: "function",
 function: {
 name: "get_weather",
 description: "Получает текущую погоду для указанного города.",
 parameters: {
 type: "object",
 properties: {
 location: {
 type: "string",
 description: "Название города (например: Токио, Нью-Йорк)",
 },
 },
 required: ["location"],
 },
 },
 },
 ];

 const response = await openai.chat.completions.create({
 model: "gpt-4o",
 messages: [{ role: "user", "content": "Какая сегодня погода в Токио? Нужен ли зонт?" }],
 tools: tools,
 tool_choice: "auto",
 });

 const message = response.choices[0].message;

 if (message.tool_calls) {
 const toolCall = message.tool_calls[0];
 console.log(`LLM запросила вызов инструмента: имя функции = ${toolCall.function.name}`);

 const args = JSON.parse(toolCall.function.arguments);
 console.log(`Аргументы: ${args.location}`);

 // Здесь реализуется вызов реального API погоды (например, OpenWeatherMap)
 // const weather = await fetchWeatherFromAPI(args.location);

 // Полученный результат снова передается LLM для формирования окончательного ответа
 }
}

runAgent().catch(console.error);

Claude 3.5 Sonnet и Gemini 1.5 Pro также имеют аналогичные функции Tool Calling, и хотя способы определения схем немного отличаются, базовый рабочий процесс остается тем же.

9. RAG против Long Context Window: что использовать?

Одна из крупнейших дискуссий в архитектуре корпоративного ИИ сегодня — «Стоит ли использовать RAG (поисковую генерацию) для интеграции внешних знаний, или же лучше просто закидывать все в огромное контекстное окно (Long Context)?».

Преимущества и недостатки RAG (Retrieval-Augmented Generation)

Преимущества: Низкая стоимость (в промпт включаются только нужные чанки), легко определить источники ответов.
Недостатки: Зависит от точности семантического поиска. Не подходит для продвинутых задач, где контекст разбросан по нескольким документам (например: «Опираясь на все протоколы совещаний за прошлый год, проанализируйте в хронологическом порядке основную причину задержки проекта А»).

Long Context (например, 2 миллиона токенов в Gemini 1.5 Pro)

Преимущества: Нет упущений информации из-за поиска. Даже в тесте «Поиск иголки в стоге сена» (Needle In A Haystack: NIAH) Gemini 1.5 Pro и Claude 3.5 Sonnet извлекают нужную информацию с точностью более 99%.
Недостатки: Огромный расход токенов ведет к большим затратам, возрастает задержка ($T_{TTFT}$).

Вывод: Лучшей практикой в 2026 году является «Гибридный подход». Для рутинных Q&A используется RAG с векторными базами данных, а для сложных аналитических задач или обзора всего кода применяются механизмы Long Context с кэшированием промптов.

10. Сравнение возможностей мультимодальной обработки

ИИ-приложения следующего поколения должны уметь напрямую понимать не только текст, но и изображения, звук и видео.

sequenceDiagram participant User as "Пользователь" participant Client as "Фронтенд-приложение" participant API as "LLM API (Мультимодальный)" User->>Client: Загрузить видео и текстовый промпт Client->>API: Отправить байты видео/URI + текст Note over API: Разбиение видео на чанки и извлечение аудио Note over API: Модель мультимодального встраивания API-->>Client: Вернуть текстовое резюме и таймкоды Client-->>User: Отобразить результаты

OpenAI (GPT-4o): Исключительно высокая точность распознавания изображений, отлично справляется с чтением рукописных чертежей и сложных графиков. Также выделяется сверхнизкой задержкой (сотни миллисекунд) для нативного голосового общения через Realtime API.
Google (Gemini 1.5 Pro): Безоговорочный лидер в анализе видео. Позволяет напрямую загружать часовой видеофайл (кадры + звук) и получать ответы на такие узконаправленные вопросы, как: «Как называется документ в руках человека, появившегося в правой части экрана на 12-й минуте 45-й секунде?».
Anthropic (Claude 3.5 Sonnet): Способности к распознаванию изображений (Vision) находятся на том же впечатляющем уровне, что и у GPT-4o. Демонстрирует непревзойденную силу в помощи фронтенд-разработчикам: можно просто дать скриншот интерфейса со словами «Сгенерируй код React-компонента для этого экрана».

11. Безопасность и комплаенс корпоративного уровня

Когда компании используют LLM API в производственной среде, они больше всего беспокоятся о том, «Не будут ли наши данные использоваться для обучения ИИ?» и «Соответствует ли это требованиям комплаенса?».

Все три компании четко заявляют, что данные (промпты и ответы), передаваемые через их API, не используются для обучения моделей (Zero Data Retention / No Training on Customer Data). (※ Это не относится к бесплатным веб-версиям чат-ботов для обычных пользователей).

Если требуются более высокие уровни безопасности:

OpenAI: При использовании Azure OpenAI Service вы получаете доступ к системе безопасности корпоративного уровня от Microsoft, SLA и возможности подключения к закрытой сети с помощью Azure Private Link.
Google: При доступе через Google Cloud Vertex AI можно обеспечить строгую сетевую изоляцию с помощью VPC Service Controls и защиту данных клиентскими ключами шифрования (CMEK).
Anthropic: Доступ через AWS Bedrock или Google Cloud Vertex AI позволяет опираться на надежную базовую инфраструктуру безопасности облачных провайдеров.

12. Заключение: идеальное руководство по выбору для каждого юзкейса

Мы рассмотрели вопрос с разных сторон, но итоговый ответ на вопрос «Что же выбрать?» зависит от вашего юзкейса.

Сложная разработка ПО, генерация кода и продвинутые рассуждения: 👑 Победитель: Claude 3.5 Sonnet (Anthropic) На данный момент обеспечивает лучшую производительность в понимании контекста кода, рефакторинге и написании естественного человеческого текста. Также обладает удобным API и высокой экономической эффективностью благодаря кэшированию промптов.
Анализ сверхдлинных документов и массовая обработка видео/аудио: 👑 Победитель: Gemini 1.5 Pro (Google) Контекстное окно в 2 миллиона токенов — это его уникальное преимущество. Если вам необходимо охватить картину целиком, например, проанализировать сотни страниц PDF-руководств или резюмировать многочасовые видеозаписи встреч, Gemini просто нет равных.
Универсальность, скорость выполнения и стабильный структурированный вывод (JSON): 👑 Победитель: GPT-4o / GPT-4o-mini (OpenAI) Отлично справляется с любыми задачами и обладает наиболее широкой поддержкой сторонних инструментов. Если требуется надежный парсинг JSON с помощью Structured Outputs или сверхсложная логика с использованием модели o1, экосистема OpenAI является незаменимой.

Рекомендация: мультимодельная маршрутизация

Вместо того чтобы полагаться на один API (vendor lock-in), будущим трендом становится архитектура «LLM-маршрутизации (LLM Routing)», при которой модель динамически переключается в зависимости от сложности и важности задачи. Например, на простые вопросы пользователей можно отвечать с помощью недорогих и быстрых GPT-4o-mini или Gemini 1.5 Flash, а ресурсоемкие задачи поручать Claude 3.5 Sonnet. Это обеспечивает идеальный баланс между затратами и производительностью.

Эволюция ИИ не останавливается. Глубоко понимая сильные и слабые стороны каждого API, а также характеристики их архитектур, вы сможете создавать гибкие и масштабируемые ИИ-приложения.

Использование llama.cpp и введение в кастомизацию на C++

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

В последние годы эволюция больших языковых моделей (LLM) поражает воображение, и сфера их применения расширяется с каждым днем. Однако для запуска моделей с миллиардами и десятками миллиардов параметров в локальной среде обычно требуются высокопроизводительные GPU с огромным объемом VRAM. llama.cpp — это то, что разрушило эту “аппаратную стену” и сделало возможным практический инференс LLM на обычных ПК, Mac и даже устройствах вроде Raspberry Pi.

В этой статье мы не ограничимся простым использованием инструмента командной строки, а подробно, специально для инженеров, разберем архитектуру базовой технологии ggml, математическую основу Transformer и квантования, а также способы интеграции и кастомизации LLM в ваших собственных приложениях с использованием C++ API.

1. Обзор llama.cpp и ggml

llama.cpp — это легковесный движок инференса LLM, написанный на C/C++ разработчиком Георгием Гергановым. Изначально он был создан для быстрого запуска модели LLaMA от Meta на Apple Silicon (M1/M2 Mac), но теперь поддерживает различные архитектуры и модели.

Его главная особенность — это чистая реализация на C/C++ без внешних зависимостей. Он не требует огромных экосистем вроде Python или PyTorch и может быть скомпилирован как один исполняемый файл, что делает деплой чрезвычайно простым.

Сердцем этого llama.cpp является библиотека тензорных вычислений ggml. ggml была разработана с нуля для максимальной оптимизации матричных вычислений в машинном обучении на CPU (а также на некоторых GPU).

1.1 Почему llama.cpp такой быстрый?

Использование отображения памяти (mmap): При загрузке весов модели в память используется системный вызов OS mmap, что позволяет избежать полной загрузки в RAM, обеспечивая быстрый запуск и экономию памяти.
Тщательная оптимизация SIMD-инструкций: Для сверхбыстрого перемножения матриц используются специфичные для CPU наборы инструкций, такие как AVX2, AVX-512, ARM NEON и Apple AMX.
Квантование (Quantization): Веса в формате 16-битных чисел с плавающей запятой (FP16) сжимаются в 4-битные, 5-битные и 8-битные целые числа, что устраняет узкое место пропускной способности памяти (подробнее об этом ниже).

2. Математическая основа: Transformer и Квантование (Quantization)

Для глубокого понимания llama.cpp необходимо знать, какие математические формулы он вычисляет и как аппроксимирует вычисления.

2.1 Процесс инференса Transformer

Такие модели, как LLaMA, используют архитектуру авторегрессионного (Auto-regressive) декодера Transformer. Ядром генерации текста является механизм Self-Attention.

Для входной матрицы скрытых состояний $X \in \mathbb{R}^{N \times d}$, запрос (Query) $Q$, ключ (Key) $K$ и значение (Value) $V$ вычисляются как произведения с матрицами весов.

$$ Q = X W_Q, \quad K = X W_K, \quad V = X W_V $$

Здесь выход Attention определяется следующим образом:

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

В цикле инференса llama.cpp узким местом становится произведение этих огромных матриц $W_Q, W_K, W_V$ и матриц весов сети прямого распространения (FFN) на вектор $X$ (на этапе генерации $N=1$, так как обрабатывается по одному токену), то есть GEMV (General Matrix-Vector Multiplication).

2.2 Математические основы квантования (Quantization)

При инференсе, где узким местом является пропускная способность доступа к памяти, квантование, представляющее весовые параметры небольшим количеством бит, жизненно необходимо. Давайте объясним базовый принцип блочного квантования (например, Q4_K или Q4_0), широко используемого в llama.cpp.

Например, рассмотрим блок $w = [w_1, w_2, \dots, w_B]$ длины $B$ (обычно 32 или 64), который является частью матрицы весов $W$ в формате FP16. Этот блок аппроксимируется 4-битными целыми числами $q_i \in [-8, 7]$ и одним масштабным коэффициентом (scaling factor) $\Delta$ (FP16 или FP32).

$$ w_i \approx \Delta \times q_i $$

$\Delta$ определяется на основе максимального абсолютного значения внутри блока.

$$ \Delta = \frac{\max_i |w_i|}{7} $$

Если входной вектор $x$ также квантуется как $x_i \approx \Delta_x \times q_{x, i}$ при вычислении скалярного произведения $y = w \cdot x$ с использованием квантованных весов, то:

$$ y = \sum_{i=1}^{B} w_i x_i \approx \Delta \Delta_x \sum_{i=1}^{B} q_i q_{x, i} $$

Часть $\sum q_i q_{x, i}$ становится чисто целочисленной арифметикой и может быть вычислена параллельно на очень высокой скорости с использованием SIMD-инструкций. Это и есть математический секрет того, как llama.cpp достигает невероятной скорости на CPU.

3. Архитектура и поток инференса

Чтобы понять внутреннее устройство llama.cpp, на следующей диаграмме Mermaid показана архитектура всей системы и потоки данных.

graph TD A["Пользовательский ввод (String)"] --> B["Токенизатор llama.cpp"] B --> C["ID токенов (int32 массив)"] C --> D["Буфер контекста (KV Cache)"] D --> E["Вычислительный граф ggml"] E --> F["Слои Transformer"] subgraph "Движок ggml" F --> G["Self-Attention (RoPE)"] G --> H["Feed Forward Network"] H --> F end F --> I["Логиты (Размер словаря)"] I --> J["Сэмплер (Temperature, Top-K, Top-P)"] J --> K["Выбранный ID токена"] K --> L["Детокенизатор llama.cpp"] L --> M["Выходная строка"] K -. "Авторегрессионный цикл" .-> D

Генерация текста — это авторегрессионный цикл: каждый раз, когда выводится один токен, он добавляется в KV Cache как следующий вход и снова проходит через вычислительный граф.

4. Настройка окружения и сборка

Прежде чем интегрировать llama.cpp в проект C++, давайте сначала соберем исходный код.

4.1 Клонирование репозитория

1
2


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

4.2 Сборка с использованием CMake

При интеграции в другие приложения в качестве C++ проекта использование CMake является наиболее стандартным подходом. Включение платформозависимого ускорителя (бэкенда) позволяет ускорить вычисления.

Только CPU (базовая сборка):

1
2
3


mkdir build && cd build
cmake ..
cmake --build . --config Release -j 8

При использовании NVIDIA GPU (CUDA):

1
2
3


mkdir build && cd build
cmake .. -DGGML_CUDA=ON
cmake --build . --config Release -j 8

При использовании Apple Silicon (Metal):

1
2
3


mkdir build && cd build
cmake .. -DGGML_METAL=ON
cmake --build . --config Release -j 8

После успешной сборки в директории build/bin/ будут сгенерированы исполняемые файлы, такие как llama-cli, и библиотека llama (а также библиотека ggml) для линковки через C++ API, о котором пойдет речь ниже.

5. Введение в кастомизацию на C++: Использование API llama.cpp

С этого момента мы перейдем к главной теме — управлению llama.cpp из кода на C++. Чтобы не просто использовать инструмент командной строки, а встроить LLM в собственное приложение (например, игровой движок, десктопное приложение, встроенную систему и т. д.), необходимо напрямую обращаться к C++ API.

llama.cpp предоставляет интерфейс на языке C в основном через заголовочный файл llama.h. При вызове из C++ также используется этот интерфейс.

5.1 Минимально необходимые инклуды и настройки

При использовании llama.cpp в собственном проекте добавьте следующие #include.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#include "llama.h"
#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>

// Макрос для обработки ошибок
#define LLAMA_ASSERT(x) \
 do { \
 if (!(x)) { \
 std::cerr << "Assertion failed: " << #x << std::endl; \
 std::terminate(); \
 } \
 } while (0)

5.2 Загрузка модели и инициализация контекста

Сначала загрузим файл модели в формате .gguf и выделим контекст (область памяти и KV-кэш) для инференса.

 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


int main(int argc, char ** argv) {
 if (argc < 2) {
 std::cerr << "Usage: " << argv[0] << " <model.gguf>" << std::endl;
 return 1;
 }
 std::string model_path = argv[1];

 // 1. Инициализация бэкенда (настройка окружения для CPU/GPU и т.д.)
 llama_backend_init();

 // 2. Получение настроек параметров модели по умолчанию
 llama_model_params model_params = llama_model_default_params();
 model_params.n_gpu_layers = 35; // Количество слоев, переносимых на GPU

 // 3. Загрузка модели
 llama_model * model = llama_load_model_from_file(model_path.c_str(), model_params);
 if (model == nullptr) {
 std::cerr << "Failed to load model" << std::endl;
 return 1;
 }

 // 4. Настройка параметров контекста
 llama_context_params ctx_params = llama_context_default_params();
 ctx_params.n_ctx = 2048; // Максимальный размер контекста (количество токенов)
 ctx_params.n_threads = 8; // Количество потоков CPU, используемых для инференса

 // 5. Создание контекста
 llama_context * ctx = llama_new_context_with_model(model, ctx_params);
 if (ctx == nullptr) {
 std::cerr << "Failed to create context" << std::endl;
 llama_free_model(model);
 return 1;
 }

 std::cout << "Model and context loaded successfully!" << std::endl;
 // ... дальнейшая обработка

5.3 Токенизация промпта (Tokenization)

LLM не понимают текст напрямую, а обрабатывают его как последовательность целочисленных ID (токенов). Входную строку необходимо преобразовать в токены.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 std::string prompt = "Q: Какая столица Японии?\nA:";
 std::vector<llama_token> tokens_list;
 tokens_list.resize(prompt.length() + 4); // Размер буфера с запасом

 // Добавлять ли специальные токены (BOS: Begin of Sequence и т.д.) в начало
 bool add_special = true;
 // Преобразование строки в массив ID токенов
 int n_tokens = llama_tokenize(
 model,
 prompt.c_str(),
 prompt.length(),
 tokens_list.data(),
 tokens_list.size(),
 add_special,
 false // parse_special
 );

 if (n_tokens < 0) {
 // Требуется логика для перераспределения буфера и повторной попытки, если места не хватает (опущено для простоты)
 std::cerr << "Failed to tokenize prompt" << std::endl;
 return 1;
 }
 tokens_list.resize(n_tokens);

5.4 Цикл инференса и сэмплирование

Мы построим цикл, который передает токены в модель, получает распределение вероятностей (Logits) следующего токена и выполняет сэмплирование для определения следующего токена.

 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


 // Максимальное количество генерируемых токенов
 const int max_gen_tokens = 100;

 // Инициализация структуры для пакетной обработки (batch evaluation)
 llama_batch batch = llama_batch_init(512, 0, 1);

 // Добавление токенов промпта в пакет
 for (size_t i = 0; i < tokens_list.size(); i++) {
 llama_batch_add(batch, tokens_list[i], i, { 0 }, false);
 }
 // Настройка вывода логитов (результатов предсказания) только для последнего токена промпта
 batch.logits[batch.n_tokens - 1] = true;

 // Первоначальная оценка (скармливание промпта модели)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "llama_decode() failed" << std::endl;
 return 1;
 }

 int n_cur = batch.n_tokens; // Текущая длина контекста
 int n_decode = 0;

 std::cout << "\nOutput: ";

 // Инициализация контекста сэмплера (настройки Temperature, Top-K, Top-P и т.д.)
 llama_sampler * smpl = llama_sampler_chain_init(llama_sampler_chain_default_params());
 llama_sampler_chain_add_top_k(smpl, 40);
 llama_sampler_chain_add_top_p(smpl, 0.9f, 1);
 llama_sampler_chain_add_temp(smpl, 0.7f);
 llama_sampler_chain_add_dist(smpl, 1234); // Значение Seed

 while (n_decode < max_gen_tokens) {
 // 1. Сэмплирование: предсказание следующего токена на основе текущего контекста
 llama_token new_token_id = llama_sampler_sample(smpl, ctx, -1);

 // 2. Если токен - это EOS (End of Sequence), завершить цикл
 if (llama_token_is_eog(model, new_token_id)) {
 break;
 }

 // 3. Декодирование токена в строку (текст) и ее отображение
 char buf[128];
 int n_chars = llama_token_to_piece(model, new_token_id, buf, sizeof(buf), 0, false);
 if (n_chars > 0) {
 std::cout << std::string(buf, n_chars) << std::flush;
 }

 // 4. Подготовка только что сгенерированного токена как следующего пакета
 llama_batch_clear(batch);
 llama_batch_add(batch, new_token_id, n_cur, { 0 }, true);

 // 5. Оценка модели (обновление KV-кэша и предсказание следующего)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "Failed to evaluate" << std::endl;
 break;
 }

 n_cur += 1;
 n_decode += 1;
 }

 std::cout << std::endl;

 // Очистка
 llama_sampler_free(smpl);
 llama_batch_free(batch);
 llama_free(ctx);
 llama_free_model(model);
 llama_backend_free();

 return 0;
}

Этот код реализует собственный цикл инференса с использованием базового API llama.cpp. Группа токенов управляется с помощью структуры llama_batch, а прямой проход (forward pass) нейронной сети выполняется с помощью llama_decode.

6. Продвинутые примеры кастомизации: Управление логитами и штрафами на C++

Если вы хотите выйти за рамки простой генерации текста и принудительно задать определенный формат вывода (например, только JSON) или запретить вывод определенных слов, вы можете напрямую управлять логитами (Logits) на стороне C++ перед сэмплированием.

Вы можете получить массив необработанных оценок (значений до их преобразования в вероятности) непосредственно перед тем, как модель выведет каждый токен.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Получение массива необработанных логитов сразу после инференса и перед выполнением сэмплирования
float * logits = llama_get_logits_ith(ctx, batch.n_tokens - 1);
int n_vocab = llama_n_vocab(model);

// Список ID запрещенных токенов (например, 1234, 5678)
std::vector<llama_token> forbidden_tokens = { 1234, 5678 };

// Установка вероятности появления запрещенных токенов на 0 (логит в минус бесконечность)
for (llama_token bad_tok : forbidden_tokens) {
 logits[bad_tok] = -INFINITY;
}

Таким образом, работая напрямую с C++ API, становится возможным “вмешательство на микросекундном уровне на каждом цикле инференса”, что трудно реализовать или влечет за собой большие накладные расходы при использовании LangChain или Python.

7. Секреты настройки производительности

После завершения реализации на C++, вот несколько контрольных точек для максимизации скорости в преддверии запуска в производственную среду (production).

Оптимизация пакетной обработки (Batching): При одновременной обработке запросов от нескольких пользователей включите несколько последовательностей в llama_batch и вызовите llama_decode один раз (Continuous Batching). Это позволяет объединить обращения к памяти и значительно повысить пропускную способность.
Включение Flash Attention: Установив ctx_params.flash_attn = true; в параметрах контекста, вы можете ускорить вычисления Attention, одновременно уменьшив использование памяти. Это обязательная настройка при работе с длинными контекстами (десятки тысяч токенов).
Поддержка NUMA: В многопроцессорных серверных средах (multi-socket) задержку доступа к памяти можно уменьшить путем правильной настройки NUMA перед вызовом llama_backend_init().

8. В заключение

В этой статье мы подробно рассмотрели всё: от математической базы llama.cpp и разбора его архитектуры до создания кастомного движка инференса с использованием C++ API.

Хотя экосистема Python очень удобна для прототипирования, в производственных средах, где требуется деплой на edge-устройства, интеграция в игры или обработка в реальном времени, прямое управление через llama.cpp на базе C/C++ демонстрирует подавляющее превосходство.

Обязательно попробуйте написать код на C++ своими руками и ощутите радость от свободного управления LLM в вашей локальной среде.

Полезные ссылки

llama.cpp Official Repository

ggml - Tensor Library

Attention Is All You Need (Vaswani et al., 2017)

【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 и рисков утечки информации, и прямо сейчас сделайте шаг в свободный и мощный мир приватного ИИ.