LLM on kenji.blog

Как быстрее всего настроить 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.

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

LLM on kenji.blog

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

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

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

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

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

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

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

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

Рекомендуемые характеристики оборудования

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

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

5.1 Flash Attention 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2 RoPE (Rotary Position Embedding)

4.3 Grouped-Query Attention (GQA)

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

1.1 OpenAI (ChatGPT)

1.2 Google (Gemini)

1.3 Anthropic (Claude)

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

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

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

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

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

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

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

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

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