P·Books
БиблиотекаОглавление
Книга · выпуск 03 · 2026

Локальные LLM без иллюзий: память, скорость и качество на одной машине

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

Скачать Markdown

Локальные LLM без иллюзий: память, скорость и качество на одной машине

Практическая инженерия локального inference: от GGUF и KV-cache до реальных coding, MCP и 1С задач.

Содержание

  1. Глава 1. Что именно мы измеряем
  2. Глава 2. Квантизация без магии
  3. Глава 3. UMA, VRAM, GTT и память процесса
  4. Глава 4. KV-cache и контекстный обвал
  5. Глава 5. ROCm, Vulkan и специализированный runtime
  6. Глава 6. llama.cpp и OpenAI-compatible serving
  7. Глава 7. MTP и speculative decoding
  8. Глава 8. Engram, QSA и SSD-backed state
  9. Глава 9. Честная benchmark-матрица
  10. Глава 10. Качество на реальных задачах
  11. Глава 11. Стабильность и отказоустойчивость
  12. Глава 12. Выбор конфигурации и runbook

Глава 1. Что именно мы измеряем

Когда инженер говорит: «Эта модель работает быстро», это утверждение требует уточнения. Скорость — не скалярная величина. В контексте локальных LLM (Large Language Models — больших языковых моделей) производительность представляет собой многомерный вектор, компоненты которого часто конфликтуют друг с другом. Увеличение пропускной способности (throughput) может привести к деградации времени до первого токена (TTFT), а оптимизация использования памяти способна замедлить процесс декодирования.

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

Анатомия запроса: от байтов до токенов

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

1. Load Time (Время загрузки модели)

Это одноразовая операция при старте сервиса. Она включает чтение весов с диска (или из оперативной памяти, если модель уже там), инициализацию CUDA-контекста и аллокацию памяти под KV-cache (кэш ключей и значений внимания).

2. Prompt Processing (Обработка промпта / Prefill)

На этом этапе модель считывает входной контекст и вычисляет ключи и значения для всех токенов промпта параллельно, заполняя KV-cache.

3. Decode (Генерация токенов)

После обработки промпта модель начинает генерировать ответ токен за токеном. Каждый новый токен требует полного прохода через все слои трансформера с учетом накопленного KV-cache.

Ключевые метрики задержки

Пользователь не видит внутренних этапов. Он воспринимает только время реакции. Однако для инженера критично разделять следующие показатели.

TTFT (Time To First Token)

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

Для состояния «теплого» сервиса (когда модель уже загружена в память) формула выглядит так: $$ TTFT_{warm} = T_{network} + T_{queue} + T_{prefill} + T_{decode_first_token} $$

Total Latency (Общее время ответа)

Время от отправки запроса до получения последнего токена. $$ Total Latency = TTFT + (N_{output_tokens} \times T_{decode_per_token}) $$

Throughput (Пропускная способность)

Количество токенов, обработанных системой в единицу времени. Здесь важно уточнять: входных или выходных?

Ошибки дизайна бенчмарков

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

1. Бенчмарк «Hello World»

Запуск модели с промптом «Привет» и генерацией 10 токенов. * Ошибка: Доминирует накладные расходы (overhead) запуска и обработки короткого промпта. Не показывает поведение при длинных контекстах. * Реальность: В продакшене промпты часто содержат 2–10k токенов (документы, история чата).

2. Игнорирование роста KV-cache

Измерение скорости генерации без учета увеличения размера контекста. * Ошибка: На коротких ответах (до 100 токенов) скорость TPS может быть стабильной. На длинных (1000+ токенов) она падает, так как размер KV-cache растет линейно с длиной контекста, увеличивая время доступа к памяти. * Реальность: Нужно измерять TPS на разных длинах контекста (например, 1k, 4k, 16k, 32k токенов).

3. Смешивание Load Time и Runtime

Включение времени загрузки модели в среднее время ответа. * Ошибка: Если вы измеряете 100 запросов, а модель загружается 10 секунд, то для первого запроса TTFT будет огромным, а для остальных — нормальным. Среднее значение будет искажено. * Реальность: Всегда разделяйте cold start и warm state.

4. Отсутствие конкуренции за ресурсы

Запуск бенчмарка на пустой машине. * Ошибка: В реальных системах GPU разделяется с другими процессами (логирование, мониторинг, другие инференс-сервисы). Также важна конкуренция за PCIe-шину при загрузке данных. * Реальность: Тестируйте под нагрузкой, имитирующей пиковый трафик.

Практический подход к измерению

Вместо использования готовых скриптов, которые выводят «магическое число», напишите простой инструмент для профилирования. Ниже приведен псевдокод логики измерения.

Важно: Реализация зависит от используемого фреймворка. В transformers нужно использовать TextIteratorStreamer, в vLLM — AsyncLLMEngine или LLM.generate с stream=True, в llama.cpp — специфичный API. Приведенный ниже код является абстракцией и требует адаптации под ваш стек.

import time
import statistics

class LLMProfiler:
    def __init__(self, model_client):
        self.client = model_client
        self.metrics = {
            'ttft': [],
            'total_latency': [],
            'output_tps': [],
            'request_processing_rate': [] # Переименовано для точности
        }

    def measure_request(self, prompt: str, max_tokens: int = 512):
        start_time = time.perf_counter()

        # 1. Отправка запроса и ожидание первого токена
        # Предполагаем, что client.generate_stream() возвращает итератор
        stream = self.client.generate_stream(prompt, max_tokens=max_tokens)

        first_token_time = None
        token_count = 0

        for token in stream:
            if first_token_time is None:
                first_token_time = time.perf_counter()
            token_count += 1

        end_time = time.perf_counter()

        # Проверка на пустой ответ
        if first_token_time is None:
            raise Exception("No tokens generated")

        # Расчеты
        ttft = first_token_time - start_time
        total_latency = end_time - start_time
        decode_time = end_time - first_token_time

        # Пропускная способность генерации (без учета TTFT)
        # token_count включает первый токен. decode_time - время от 1-го до последнего.
        # Интервалов генерации: token_count - 1
        if decode_time > 0 and token_count > 1:
            output_tps = (token_count - 1) / decode_time
        else:
            output_tps = 0

        # Скорость обработки запроса до первого вывода
        # Примечание: TTFT включает время Prefill и время генерации 1-го токена.
        # Для длинных промптов T_decode_1 мала, поэтому это хорошая оценка скорости Prefill.
        # Для коротких промптов это скорее "скорость обработки запроса".
        prompt_tokens = self.client.count_tokens(prompt)
        if ttft > 0:
            request_processing_rate = prompt_tokens / ttft
        else:
            request_processing_rate = 0

        # Сохранение
        self.metrics['ttft'].append(ttft)
        self.metrics['total_latency'].append(total_latency)
        self.metrics['output_tps'].append(output_tps)
        self.metrics['request_processing_rate'].append(request_processing_rate)

        return {
            'ttft_ms': ttft * 1000,
            'total_ms': total_latency * 1000,
            'output_tps': output_tps,
            'request_processing_rate': request_processing_rate
        }

    def report(self):
        if not self.metrics['ttft']:
            print("No metrics collected.")
            return

        print(f"--- Results over {len(self.metrics['ttft'])} requests ---")

        # Безопасное вычисление перцентилей
        ttft_sorted = sorted(self.metrics['ttft'])
        n = len(ttft_sorted)

        p50_idx = int(n * 0.50)
        p95_idx = min(int(n * 0.95), n - 1) # Защита от выхода за границы

        print(f"TTFT (p50): {ttft_sorted[p50_idx]*1000:.2f} ms")
        print(f"TTFT (p95): {ttft_sorted[p95_idx]*1000:.2f} ms")
        print(f"Output TPS (avg): {statistics.mean(self.metrics['output_tps']):.2f} tok/s")
        print(f"Request Processing Rate (avg): {statistics.mean(self.metrics['request_processing_rate']):.2f} tok/s")

Чек-лист для валидного бенчмарка

  1. Разделение фаз: Вы явно измеряете TTFT и время декодирования отдельно?
  2. Вариативность контекста: Вы тестируете на разных длинах промптов (короткий, средний, длинный)?
  3. Вариативность ответа: Вы ограничиваете max_tokens или измеряете реальную длину генерации? (Реальная длина важнее для Total Latency).
  4. Статистика: Вы используете медиану и перцентили (p95, p99), а не только среднее? Среднее скрывает выбросы, которые убивают UX.
  5. Изоляция: Вы отключили другие процессы, потребляющие GPU/CPU?
  6. Повторяемость: Вы запускаете тест несколько раз и отбрасываете первый прогон (warm-up)?

Полезная работа vs. Метрики

В конечном счете, метрики — это средство, а не цель. «Полезная работа» зависит от бизнес-кейса.

Не гонитесь за максимальным TPS в вакууме. Оптимизируйте ту метрику, которая напрямую влияет на удовлетворенность пользователя или стоимость обработки единицы данных в вашем конкретном сценарии. В следующей главе мы разберем, как память ограничивает эти метрики и почему «больше VRAM» — это не всегда решение.

Глава 2. Квантизация без магии

Когда вы скачиваете модель с Hugging Face Hub, вы часто видите суффиксы вроде Q4_K_M, IQ4_XS или Q8_0. Для новичка это выглядит как магия: «Q4 в четыре раза меньше, значит, в четыре раза быстрее и почти так же умно». Для инженера это ложная дихотомия. Квантизация — это не просто сжатие данных; это сложный компромисс между точностью представления весов, архитектурой памяти и пропускной способностью шины данных.

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

Анатомия квантизации: от FP16 к целым числам

Стандартная модель в формате FP16 (half-precision float, число с плавающей запятой одинарной точности) хранит каждый вес как 16-битное число. Это обеспечивает высокую точность, но требует значительных объемов памяти. Квантизация заменяет эти 16 бит на меньшее количество (4, 5, 6, 8), используя шкалирование.

Представьте набор весов в диапазоне от -1.0 до 1.0. * В FP16 мы храним само число. * В Q4 мы храним целое число от 0 до 15 (4 бита) и отдельный масштаб (scale) для блока весов.

Формула восстановления веса $w$ из квантованного значения $q$ и масштаба $s$: $$ w \approx q \times s + z $$ где $z$ — нулевая точка (zero-point), используемая при асимметричной квантизации для смещения диапазона.

Почему блоки?

Квантовать весь тензор одним масштабом — плохая идея. Веса в нейросетях имеют неравномерное распределение. Если один вес равен 100, а остальные около 0.01, общий масштаб будет огромным, и мелкие веса превратятся в нули. Поэтому современные схемы (GGUF, GPTQ) используют блочную квантизацию. Тензор делится на блоки (обычно 32 или 64 веса), и для каждого блока вычисляется свой масштаб.

Обзор схем: Q4, IQ4, Q5, Q6, Q8

Разберем основные варианты на рынке локального инференса (на примере формата GGUF, ставшего стандартом де-факто для CPU и гибридных систем).

Q4_K_M (4-bit, Medium)

Это «золотой стандарт» для большинства пользователей. * Структура: Использует 4 бита для весов, но с дополнительными надбавками для масштабов и минимаксов. * Размер: ~4.5–4.8 бита на вес. * Плюсы: Отличный баланс. Потери качества минимальны для большинства задач (код, суммаризация, чат). * Минусы: Не идеален для сложных математических рассуждений или длинных контекстов с высокой плотностью фактов.

IQ4_XS (Importance-aware Quantization, 4-bit Extra Small)

Новое поколение схем от разработчиков llama.cpp (Georgi Gerganov). * Структура: В отличие от стандартных схем, IQ4_XS использует сложные алгоритмы кодирования, основанные на таблицах поиска (lookup tables) и перестановке битов. Это позволяет упаковать информацию плотнее, чем Q4_K_M, за счет более эффективного использования статистического распределения весов. Важно понимать: это не динамическое «умное» распределение битов внутри блока в реальном времени, а предсказуемая, но сложная структура кодирования. * Размер: ~4.0–4.2 бита на вес. * Плюсы: Значительно меньше Q4_K_M при сопоставимом качестве. Позволяет загрузить модель большего размера в ту же VRAM. * Минусы: Вычислительно сложнее при декодировании. Может быть медленнее на старых CPU из-за сложности распаковки.

Q5_K_M и Q6_K

Q8_0 (8-bit)

Память vs. Скорость: Иллюзия tok/s

Главная ошибка при выборе модели — смотреть только на токены в секунду (tok/s) в бенчмарках.

1. Bottleneck: Memory Bandwidth vs. Compute

На GPU инференс LLM часто ограничен пропускной способностью памяти (memory-bound), а не вычислительной мощностью (compute-bound). * Q4: Вы читаете из VRAM в 4 раза меньше данных, чем при FP16. Если ваша видеокарта имеет узкую шину памяти (например, RTX 3060 12GB), Q4 даст огромный прирост скорости. * Q8: Вы читаете в 2 раза меньше данных, чем FP16, но в 2 раза больше, чем Q4.

Уточнение контекста: При генерации с batch size = 1 (типичный сценарий локального чата) узким местом почти всегда является пропускная способность памяти. Однако при пакетной обработке (batching) или на очень мощных GPU (например, RTX 4090) разница может нивелироваться или инвертироваться из-за накладных расходов на распаковку квантованных весов и переключения режимов работы Tensor Cores.

Эвристика выбора: * Если модель влезает в VRAM в Q8, но Q4 дает заметное падение качества, выбирайте Q8. * Если модель не влезает в Q8, но влезает в Q4, Q4 — единственный вариант для запуска на GPU. * Если модель влезает в Q8 и Q4, разница в скорости может быть нелинейной. На современных GPU разница между Q4 и Q8 может составлять всего 10–20%, так как узкое место смещается.

2. Overhead на распаковку

Квантованные веса нужно распаковать обратно в FP16/BF16 перед умножением матриц. * Q4_K_M: Простая распаковка. Быстро на CPU и GPU. * IQ4_XS: Сложная распаковка. Требует больше инструкций процессора. На CPU это может замедлить инференс, несмотря на меньший объем данных. На GPU с большим количеством CUDA-ядер этот overhead часто незаметен.

3. KV-Cache: Скрытый пожиратель памяти

При генерации текста модель хранит ключи и значения (KV-cache) для всех предыдущих токенов. * Размер KV-cache зависит от длины контекста и архитектуры модели, но не зависит напрямую от квантизации весов модели (если не квантован отдельно). * Важно: Модель Q4 может влезть в память только для коротких запросов. При увеличении контекста до 32k токенов KV-cache может занять столько же, сколько сама модель, и вы упретесь в лимит.

Outliers: Почему Q4 иногда «тупеет»

Веса нейросетей имеют тяжелые хвосты распределения. Несколько весов могут быть на порядки больше остальных. Эти outliers (выбросы) критичны для работы модели.

Практический совет: Если модель на Q4 начинает галлюцинировать в задачах с числами или точными фактами, попробуйте Q5 или Q6. Часто проблема не в «глупости» модели, а в потере точности именно на весах, отвечающих за арифметику или поиск в контексте.

Чек-лист выбора схемы

  1. Оцените доступную память (VRAM + RAM).

    • Формула: Размер модели (GB) * 1.2 (overhead) + KV-cache.
    • Точная формула KV-cache: 2 * num_layers * num_kv_heads * head_dim * context_length * bytes_per_element.
    • Примечание: num_kv_heads может быть меньше num_heads из-за GQA (Grouped Query Attention). Для грубой оценки можно использовать hidden_size, но будьте осторожны с моделями, использующими MQA/GQA.

  2. Определите задачу.

    • Чат, суммаризация, простые вопросы: Q4_K_M или IQ4_XS.
    • Код, математика, длинные документы: Q5_K_M или Q6_K.
    • Fine-tuning, критические бизнес-процессы: Q8_0 или FP16.

  3. Проверьте железо.

    • Старый CPU (AVX2): Избегайте IQ-схем, берите Q4_K_M.
    • Новый GPU (RTX 30/40): IQ4_XS может дать больше токенов в секунду за счет меньшего объема данных.
    • Apple Silicon (M1/M2/M3): GGUF работает отлично. Q4_K_M — стандарт. IQ4_XS может быть медленнее из-за специфики NEON-инструкций.

  4. Тестируйте на своих данных.

    • Не верьте бенчмаркам MMLU. Запустите 10 своих самых сложных промптов на Q4 и Q6. Сравните ответы.

Псевдокод: Как оценить необходимость квантизации

Ниже приведен исправленный алгоритм выбора схемы. Он учитывает корректную иерархию проверок памяти и отдельно оценивает требования для KV-кэша.

def choose_quantization(model_size_fp16_gb, available_vram_gb, task_criticality, context_length, model_params):
    """
    Эвристика выбора схемы квантизации.

    Args:
        model_size_fp16_gb: Размер модели в FP16 (ГБ).
        available_vram_gb: Доступная видеопамять (ГБ).
        task_criticality: 'low', 'medium', 'high'.
        context_length: Длина контекста в токенах.
        model_params: Словарь с параметрами модели (layers, kv_heads, head_dim).
    """

    # 1. Оценка памяти для KV-кэша (в ГБ)
    # Формула: 2 * layers * kv_heads * head_dim * context_length * bytes_per_element
    # bytes_per_element = 2 для FP16 KV-cache
    kv_cache_bytes = 2 * model_params['layers'] * model_params['kv_heads'] * \
                     model_params['head_dim'] * context_length * 2
    kv_cache_gb = kv_cache_bytes / (1024**3)

    # Добавляем небольшой запас на служебные данные (overhead)
    total_overhead_gb = 0.5 

    # 2. Проверка FP16
    required_fp16 = model_size_fp16_gb + kv_cache_gb + total_overhead_gb
    if required_fp16 <= available_vram_gb:
        return "FP16"

    # 3. Проверка Q8_0
    # Q8 занимает примерно половину от FP16
    q8_size = model_size_fp16_gb / 2
    required_q8 = q8_size + kv_cache_gb + total_overhead_gb
    if required_q8 <= available_vram_gb:
        if task_criticality == "high":
            return "Q8_0"
        else:
            return "Q6_K"  # Компромисс, если Q8 влезает, но можно сэкономить

    # 4. Проверка Q6_K (~6.5 бит, примерно 0.4 от FP16)
    q6_size = model_size_fp16_gb * 0.4
    required_q6 = q6_size + kv_cache_gb + total_overhead_gb
    if required_q6 <= available_vram_gb:
        return "Q6_K"

    # 5. Проверка Q5_K_M (~5.5 бит, примерно 0.35 от FP16)
    q5_size = model_size_fp16_gb * 0.35
    required_q5 = q5_size + kv_cache_gb + total_overhead_gb
    if required_q5 <= available_vram_gb:
        return "Q5_K_M"

    # 6. Проверка Q4_K_M (~4.5-4.8 бит, примерно 0.3 от FP16)
    q4_size = model_size_fp16_gb * 0.3
    required_q4 = q4_size + kv_cache_gb + total_overhead_gb
    if required_q4 <= available_vram_gb:
        return "Q4_K_M"

    # 7. Экстремальные случаи: IQ4_XS (~4.0-4.2 бит, примерно 0.27 от FP16)
    iq4_size = model_size_fp16_gb * 0.27
    required_iq4 = iq4_size + kv_cache_gb + total_overhead_gb
    if required_iq4 <= available_vram_gb:
        return "IQ4_XS"

    # 8. Если ничего не влезает
    return "CPU Offload / Smaller Model"

Заключение

Квантизация — это инструмент оптимизации, а не замена качества. * Q4_K_M — безопасный выбор для большинства. * IQ4_XS — для экономии памяти на современном железе. * Q6/Q8 — когда точность важнее скорости.

Не гонитесь за максимальным tok/s. Гонитесь за стабильным качеством ответов в рамках вашего бюджета памяти. Помните: модель, которая не влезает в память и уходит в swap, будет работать в 100 раз медленнее, чем Q4, который влезает.

Глава 3. UMA, VRAM, GTT и память процесса

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

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

Архитектура памяти: Дискретная vs. Унифицированная

Ключевое различие между платформами заключается в том, где физически хранятся данные и как к ним получают доступ процессор (CPU) и графический процессор (GPU).

1. Дискретная архитектура (NVIDIA, AMD Radeon)

В классической модели dGPU имеет собственную высокоскоростную память — VRAM (Video RAM). CPU и GPU имеют два отдельных пула памяти: системную RAM и видеопамять.

2. Унифицированная архитектура (Apple Silicon, NVIDIA Grace Hopper)

Архитектура UMA (Unified Memory Architecture) предполагает, что CPU и GPU разделяют один физический пул памяти.

Эвристика для Apple Silicon: Система и фоновые процессы всегда занимают часть памяти. Реальный бюджет для LLM составляет примерно Total RAM * 0.85.

Виртуализация памяти: GTT, Pinned и Managed Memory

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

GTT (Graphics Translation Table)

GTT — это механизм адресации, аналог MMU (Memory Management Unit) для GPU. Он позволяет GPU видеть виртуальные адреса, которые могут отображаться как на физическую VRAM, так и на системную RAM.

Механизмы работы с памятью вне VRAM

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

1. Pinned Memory (Zero-Copy)

Данные физически находятся в системной RAM, но закреплены (pinned) так, чтобы не выгружаться в swap. GPU обращается к ним напрямую через PCIe при каждом обращении. * Плюс: Экономия VRAM. * Минус: Высокая задержка (latency) и нагрузка на шину PCIe. Подходит для данных, к которым GPU обращается редко.

2. Managed Memory (cudaMallocManaged)

Это механизм автоматической миграции страниц. * Как это работает: Данные изначально могут находиться в RAM. При первом обращении GPU страница мигрирует в VRAM и остается там, пока не будет вытеснена (evicted) из-за нехватки места. * Риск Thrashing: Если модель постоянно обращается к разным частям данных, превышающим объем VRAM, страницы будут постоянно мигрировать туда-сюда. Это называется thrashing и приводит к катастрофическому падению производительности. * Нюанс: В стандартном CUDA без явного использования Managed Memory переполнение VRAM приводит к крашу, а не к прозрачному свопу.

3. Специфика AMD и Apple

Page Cache, Swap и Фрагментация

Операционная система Linux/macOS использует Page Cache для ускорения доступа к файлам. При загрузке модели (.gguf, .safetensors) файл читается с диска и кэшируется в RAM.

Опасность двойного кэширования

Если библиотека загружает модель в память процесса (Heap), а файл также остается в Page Cache, вы можете потратить память дважды. * Решение: Использование mmap (memory-mapped files). При mmap страницы файла в RAM и страницы процесса разделяются. Если физическая память заканчивается, ОС может выгрузить неиспользуемые страницы модели в Swap, не удаляя их из кэша полностью. * Ограничение: mmap помогает экономить RAM при загрузке, но не заменяет VRAM. Если модель работает на дискретном GPU, данные все равно должны быть скопированы в VRAM для вычислений. mmap не позволяет GPU читать напрямую с диска.

Swap: Последний рубеж

Когда физическая RAM заканчивается, ОС использует Swap. * Для LLM Swap — это смерть производительности. Чтение с NVMe SSD в 10–50 раз медленнее, чем из RAM. * Симптомы: Резкое падение токенов в секунду (TPS), зависания интерфейса. * Диагностика: * Linux: vmstat 1 (колонки si/so должны быть нулевыми). * macOS: Activity Monitor -> вкладка «Память» (индикатор «Давление памяти» должен быть зеленым).

Фрагментация памяти

Фрагментация возникает, когда свободная память разбита на мелкие блоки, и аллокатор не может выделить большой непрерывный кусок, даже если суммарно свободной памяти достаточно. * Причины: Динамическое изменение размера батчей, загрузка нескольких моделей, частое выделение/освобождение памяти под KV-cache. * Решение для PyTorch: * Не используйте torch.cuda.empty_cache() в цикле инференса. Это синхронизирует GPU и вызывает задержки. * Используйте переменную окружения PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True (для новых версий PyTorch), чтобы аллокатор мог расширять сегменты памяти, снижая фрагментацию. * Для продакшена рассмотрите vLLM, который использует PagedAttention для эффективного управления KV-cache.

Расчёт безопасного Memory Budget

Главная ошибка — считать, что размер файла модели равен необходимому объему памяти.

Формула бюджета

$$ \text{Total Required} = W_{model} + C_{kv} + O_{framework} + S_{system} $$

Где: * $W_{model}$: Вес модели на диске. * $C_{kv}$: Память под KV-cache (ключи и значения внимания). * $O_{framework}$: Накладные расходы фреймворка (CUDA context, буферы, фрагментация аллокатора). * $S_{system}$: Память, занятая ОС и GUI.

Корректный расчет KV-cache

Формула зависит от архитектуры внимания. Современные модели (Llama-2/3, Mistral) используют GQA (Grouped Query Attention), где количество KV-голов меньше, чем Q-голов.

$$ C_{kv} = 2 \times n_{layers} \times n_{kv_heads} \times head_dim \times seq_len \times bytes_per_element $$

Пример: Llama-3-8B-Q4_K_M

  1. Вес модели ($W_{model}$): ~4.9 ГБ.
  2. KV-cache ($C_{kv}$):
    • Llama-3 8B: 32 слоя, 8 KV-голов (GQA), head_dim=128.
    • Контекст: 4096 токенов.
    • Точность: fp16 (2 байта).
    • Расчет: $2 \times 32 \times 8 \times 128 \times 4096 \times 2 \approx 536 \text{ МБ}$.
    • Примечание: Черновики часто ошибочно используют 32 головы, завышая оценку в 4 раза.
  3. Overhead ($O_{framework}$):
    • Для llama.cpp: ~0.2–0.5 ГБ.
    • Для PyTorch/vLLM: ~2–4 ГБ (CUDA context, аллокатор).
  4. System ($S_{system}$): ~2–4 ГБ (зависит от ОС).

Итого для llama.cpp: $4.9 + 0.5 + 0.3 + 3.0 \approx 8.7 \text{ ГБ}$. Итого для PyTorch: $4.9 + 0.5 + 3.0 + 3.0 \approx 11.4 \text{ ГБ}$.

Вывод: На машине с 8 ГБ RAM модель запустится только с llama.cpp и минимальным контекстом. На 16 ГБ RAM — комфортно в любом фреймворке.

Мониторинг памяти

Приведенный ниже код универсализирован для NVIDIA (CUDA) и Apple Silicon (MPS).

import torch

def check_memory_pressure():
    """
    Проверяет использование памяти GPU.
    Поддерживает NVIDIA CUDA и Apple Silicon MPS.
    """
    if torch.cuda.is_available():
        device = 'cuda'
        # Выделенная память аллокатором PyTorch
        allocated = torch.cuda.memory_allocated() / 1024**3
        # Зарезервированная память (включая фрагментацию)
        reserved = torch.cuda.memory_reserved() / 1024**3
        # Общая память устройства
        total = torch.cuda.get_device_properties(0).total_memory / 1024**3

        print(f"[CUDA] Allocated: {allocated:.2f} GB")
        print(f"[CUDA] Reserved:  {reserved:.2f} GB")
        print(f"[CUDA] Total:     {total:.2f} GB")

        if reserved > total * 0.9:
            print("WARNING: High memory pressure. Risk of OOM.")

    elif torch.backends.mps.is_available():
        device = 'mps'
        # В MPS API для точного мониторинга требуется macOS-specific tools
        # torch.mps.memory_allocated() доступно в новых версиях
        try:
            allocated = torch.mps.memory_allocated() / 1024**3
            print(f"[MPS] Allocated: {allocated:.2f} GB")
            print("[MPS] Note: Use 'Activity Monitor' or 'vm_stat' for system-wide pressure.")
        except AttributeError:
            print("[MPS] torch.mps.memory_allocated() not available in this version.")
            print("Please use system tools (Activity Monitor) to check memory pressure.")
    else:
        print("No GPU backend available (CUDA or MPS).")

# Вызов функции
check_memory_pressure()

Практический чек-лист перед запуском

  1. Определите архитектуру:
    • [ ] dGPU (NVIDIA/AMD): Модель должна целиком (или почти целиком) помещаться в VRAM. Ошибка OOM означает краш.
    • [ ] UMA (Apple): Модель должна помещаться в RAM вместе с системой. Ошибка — это уход в Swap и падение скорости.
  2. Рассчитайте KV-cache:
    • [ ] Используйте формулу с учетом GQA (количество KV-голов), а не Q-голов.
    • [ ] Оцените overhead вашего фреймворка (llama.cpp < vLLM < PyTorch).
  3. Настройте окружение:
    • [ ] Закройте браузер и IDE.
    • [ ] Для PyTorch установите PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True.
    • [ ] Для llama.cpp используйте флаг -mmap (по умолчанию включен) для экономии RAM при загрузке.
  4. Мониторьте в реальном времени:
    • [ ] Linux: watch -n 1 nvidia-smi (для NVIDIA) или htop.
    • [ ] macOS: Activity Monitor -> Память (следите за «Давлением памяти»).
    • [ ] Если давление памяти красное или Swap активно растет — уменьшите контекст или квантование модели.

Глава 4. KV-cache и контекстный обвал

В предыдущих главах мы закрепили базовое понимание того, как трансформеры обрабатывают токены. Теперь пора столкнуться с главной инженерной реальностью локального инференса: память является не просто ограничением, а основным драйвером производительности. Когда вы увеличиваете контекстное окно с 4k до 128k токенов, вы фундаментально меняете профиль нагрузки на GPU. Если фаза обработки промпта (Prefill) остается вычислительно-ориентированной, то фаза генерации (Decode) превращается в задачу с экстремальным давлением на пропускную способность памяти.

Эта глава объясняет механику KV-cache, почему она вызывает «контекстный обвал» производительности и как найти точку, после которой дальнейшее увеличение контекста становится экономически и технически нецелесообразным.

Механика KV-cache: почему мы платим за память

Архитектура Attention требует, чтобы каждый новый токен «видел» все предыдущие. Наивная реализация пересчитывала бы ключи (Keys) и значения (Values) для всего контекста на каждом шаге генерации. Это имело бы квадратичную сложность $O(N^2)$ по времени и памяти, что сделало бы длинный контекст невозможным.

Решение — KV-cache. При фазе Prefill (обработка промпта) модель вычисляет матрицы $K$ и $V$ для всех токенов промпта и сохраняет их в显ной памяти GPU. В фазе Decode (генерация по одному токену) модель вычисляет $K$ и $V$ только для нового токена, конкатенирует их с кэшем и выполняет операцию Attention против всего накопленного кэша.

Важное уточнение: GQA и MHA

Важно понимать, что современные модели редко используют классический Multi-Head Attention (MHA), где количество голов для ключей, значений и запросов одинаково. Большинство эффективных моделей (Llama 3, Mistral, Gemma) используют Grouped Query Attention (GQA).

При GQA количество голов для ключей и значений ($H_{kv}$) значительно меньше, чем количество голов для запросов ($H_q$). Это позволяет существенно экономить память на KV-cache без критической потери качества.

Формула объема памяти

Объем памяти, занимаемый KV-cache, рассчитывается по следующей формуле:

$$ M_{kv} = 2 \times B \times L \times H_{kv} \times D \times S \times P $$

Где: * $2$: множитель для Key и Value. * $B$: Batch size (размер батча). * $L$: Количество слоев модели. * $H_{kv}$: Количество голов внимания для ключей/значений (в GQA это может быть 8, 4 или даже 1, в то время как $H_q$ может быть 32 или 64). * $D$: Размерность вектора на голову (head dimension). * $S$: Длина последовательности (контекст). * $P$: Размер элемента в байтах (например, 2 для FP16, 1 для INT8).

Пример расчета для Llama-3-8B: Архитектура Llama-3-8B использует GQA с 8 KV-головами ($H_{kv}=8$), 32 слоями и размерностью головы 128.

$$ M_{kv} = 2 \times 1 \times 32 \times 8 \times 128 \times 8192 \times 2 \approx 1.07 \text{ ГБ} $$

При увеличении контекста до 128k токенов объем вырастет до ~17 ГБ.

Реальность на потребительских картах (24 ГБ VRAM): Для Llama-3-8B в FP16: 1. Веса модели: ~16 ГБ. 2. KV-cache (128k): ~17 ГБ. 3. Итого: ~33 ГБ. Это превышает лимит 24 ГБ.

Однако, если использовать квантование весов до Q4 (~5 ГБ) и квантование KV-cache до INT8 (~8.5 ГБ), суммарное потребление составит ~13.5 ГБ. Это позволяет комфортно работать с 128k контекстом на RTX 3090/4090. Таким образом, длинный контекст возможен, но требует грамотного управления точностью.

Prefill vs Decode: смена парадигмы

Понимание разницы между фазами критично для диагностики проблем.

  1. Prefill (Обработка промпта):

    • Характер: Compute-bound (ограничен вычислениями).
    • Действие: Параллельная обработка всех токенов промпта.
    • Метрика: TTFT (Time To First Token).
    • Влияние контекста: Время Prefill растет квадратично относительно длины промпта в терминах вычислений Attention ($O(N^2)$). Хотя современные оптимизации, такие как FlashAttention, снижают потребление памяти для промежуточных активаций и улучшают эффективность использования пропускной способности, асимптотическая сложность вычислений остается высокой. Если промпт занимает 90% контекста, время до первого токена может составлять секунды.

  2. Decode (Генерация ответа):

    • Характер: Memory-bandwidth-bound (ограничен пропускной способностью памяти).
    • Действие: Последовательная генерация по одному токену.
    • Метрика: TPS (Tokens Per Second) при выходе.
    • Влияние контекста: Время генерации каждого токена растет линейно с размером KV-cache. Чем больше контекст, тем больше данных нужно читать из VRAM для каждого нового токена.

Ключевой инсайт: Увеличение контекста почти не влияет на скорость Prefill (если он не превышает лимиты), но линейно замедляет Decode. Если ваш сценарий предполагает генерацию длинных ответов, длинный контекст убьет производительность. Если же вы генерируете короткие ответы на длинные запросы, узким местом становится TTFT.

Роль FlashAttention

Невозможно обсуждать длинные контексты, не упомянув FlashAttention. Это алгоритм, который переосмысливает вычисление Attention, избегая создания огромной матрицы $N \times N$ в памяти.

Поиск Performance Cliff

«Контекстный обвал» — это не резкий обрыв, а точка перегиба, где дополнительные затраты памяти начинают непропорционально сильно влиять на latency или приводят к OOM (Out Of Memory).

Как найти свою точку обвала

Маркетинговые цифры «128k context» отражают архитектурные возможности модели, но не гарантируют приемлемую производительность на вашем оборудовании. Реальный рабочий лимит определяется вашей видеокартой и профилем нагрузки.

Чек-лист для бенчмаркинга:

  1. Изоляция переменных: Зафиксируйте модель, квантование весов и размер батча ($B=1$).
  2. График зависимости: Измеряйте два показателя при увеличении длины контекста $S$ (например, 2k, 4k, 8k, 16k, 32k, 64k):
    • TTFT (Time To First Token).
    • TPS (Tokens Per Second) в фазе Decode.
  3. Определение порога:
    • Memory Cliff: Точка, где VRAM заполняется на 95-98%. Здесь начинается аллокация на CPU RAM (offloading). При синхронном offloading это вызывает значительное падение TPS (в 5-10 раз и более). Некоторые движки могут просто падать с OOM, если не настроено динамическое управление памятью (например, PagedAttention).
    • Latency Cliff: Точка, где TTFT превышает ваш SLA (например, > 2 секунд).
    • Throughput Cliff: Точка, где TPS падает ниже приемлемого уровня (например, < 10 ток/с для интерактивного чата).

Псевдокод для автоматизированного поиска:

Примечание: Ниже приведен упрощенный пример для понимания логики. Для продакшен-бенчмарков используйте специализированные инструменты (например, llm-bench или встроенные утилиты vLLM), так как они корректно обрабатывают overhead фреймворка, очистку памяти и асинхронные операции.

import torch
import time
import gc

def find_context_cliff(model, tokenizer, max_context=131072, step=4096):
    results = []

    # Важно: убедитесь, что модель загружена с поддержкой нужного контекста
    # и оптимизациями (например, flash_attention_2)

    for ctx_len in range(4096, max_context + 1, step):
        try:
            # 1. Очистка памяти перед итерацией
            torch.cuda.empty_cache()
            gc.collect()

            # 2. Подготовка данных
            # Создаем случайный токен-вектор нужной длины
            input_ids = torch.randint(0, 50000, (1, ctx_len)).cuda()

            # 3. Измерение Prefill (TTFT)
            torch.cuda.synchronize()
            start_time = time.time()
            with torch.no_grad():
                # Forward pass для Prefill
                outputs = model(input_ids)
            torch.cuda.synchronize()
            ttft = time.time() - start_time

            # 4. Измерение Decode (TPS)
            # Для чистого измерения Decode лучше использовать ручную генерацию 
            # с past_key_values, но для простоты используем generate с max_new_tokens
            # ВНИМАНИЕ: стандартный HF generate может включать overhead.
            start_decode = time.time()
            with torch.no_grad():
                generated = model.generate(
                    input_ids, 
                    max_new_tokens=50, 
                    do_sample=False # Детерминированность для стабильности
                )
            torch.cuda.synchronize()
            decode_time = time.time() - start_decode

            # Вычитаем время Prefill из общего времени generate, если generate 
            # включает его, или измеряем отдельно. Здесь предполагаем, что 
            # generate включает Prefill, поэтому TPS считаем только по новым токенам.
            # Более точный метод: измерить время между первым и последним токеном.
            tps = 50 / decode_time

            # 5. Сбор метрик
            # memory_allocated показывает только аллоцированную PyTorch память.
            # Реальное потребление выше из-за фрагментации и контекста CUDA.
            vram_used = torch.cuda.memory_allocated() / 1e9

            results.append({
                'context': ctx_len,
                'ttft_ms': ttft * 1000,
                'tps': tps,
                'vram_used_gb': vram_used
            })

            # Очистка объектов для освобождения памяти
            del outputs, generated, input_ids

        except RuntimeError as e:
            if "out of memory" in str(e):
                print(f"OOM at context {ctx_len}")
                break
            raise e

    return results

Стратегии выбора рабочего Context Limit

Выбор лимита контекста — это компромисс между качеством (доступ к информации) и производительностью.

1. Статический лимит (Hard Limit)

Установите жесткий лимит, который гарантирует стабильную работу. * Когда использовать: Для production-сервисов с жесткими SLA. * Как выбрать: Найдите контекст, при котором TTFT < 1с и TPS > 20. Не обязательно округлять до степени двойки, но удобно для конфигурации. * Риск: Потеря информации, если пользователь отправит промпт длиннее лимита. Требует стратегии обрезки (truncation) или суммаризации.

2. Динамический лимит с приоритетом

Используйте разные лимиты для разных типов запросов. * Короткие запросы (Chat): Контекст 4k-8k. Приоритет на низкий TTFT. * Длинные документы (RAG): Контекст 32k-64k. Приоритет на качество извлечения. Разрешите высокий TTFT (до 5-10с), но ограничьте длину генерации. * Реализация: Маршрутизация запросов на основе длины промпта.

3. Оптимизация KV-cache для расширения лимита

Если вам критичен длинный контекст, но VRAM ограничена, рассмотрите следующие техники:

Чек-лист перед продакшеном

  1. [ ] Измерен реальный объем KV-cache для целевой модели и контекста с учетом GQA.
  2. [ ] Найдена точка OOM на целевом железе с учетом весов, кэша и активаций.
  3. [ ] Определен Performance Cliff для TTFT и TPS.
  4. [ ] Выбрана стратегия обработки запросов, превышающих рабочий лимит (отказ, обрезка, суммаризация).
  5. [ ] Протестировано квантование KV-cache на предмет деградации качества на ваших данных.
  6. [ ] Настроено логирование использования VRAM и latency для мониторинга деградации со временем.
  7. [ ] Проверена стабильность питания и охлаждения GPU при длительных тестах на максимальном контексте.

Заключение

Длинный контекст — это не бесплатная функция. Каждый дополнительный токен в контексте стоит вам байтов VRAM и миллисекунд latency. Инженерная задача заключается не в том, чтобы включить максимальный контекст, а в том, чтобы найти «золотую середину», где качество ответа остается приемлемым, а скорость — интерактивной.

Начинайте с малого контекста, измеряйте, и расширяйте его только тогда, когда это оправдано бизнес-логикой, а не техническими возможностями модели. Помните: пользователь предпочтет быстрый ответ с 90% релевантности медленному ответу со 100% релевантностью, если он ждет 10 секунд вместо 1.

Глава 5. ROCm, Vulkan и специализированный runtime

В предыдущих главах мы закрепились в мире CUDA, где экосистема NVIDIA обеспечивает предсказуемость, но диктует цены. Однако рынок локальных LLM не ограничивается «зелёными» картами. AMD Radeon, Intel Arc и даже интегрированные решения предлагают альтернативы, которые могут быть экономически оправданы или технически необходимы.

Но переход с CUDA на ROCm или Vulkan — это не просто смена флага компилятора. Это смена парадигмы управления памятью, драйверами и диагностикой. Эта глава посвящена тому, как заставить работать LLM на не-CUDA оборудовании, не превращая ваш рабочий стол в полигон для экспериментов с ядром Linux. Мы разберём ROCm для AMD, Vulkan как кроссплатформенный стандарт и специализированные runtime-решения, а также обсудим изоляцию этих сред, чтобы они не ломали вашу основную систему.

ROCm: Мощь AMD и боль совместимости

ROCm (Radeon Open Compute) — это ответ AMD на CUDA. Теоретически он позволяет использовать GPU-вычисления на картах Radeon. Практически поддержка LLM в ROCm зависит от конкретного чипа, версии драйвера и того, насколько активно сообщество поддерживает нужную вам библиотеку (например, llama.cpp или vLLM).

Архитектурные особенности и ограничения

Главное отличие ROCm от CUDA в контексте LLM — это управление памятью и поддержка архитектур. Многие потребительские карты AMD имеют ограничения на объём VRAM, доступный для вычислений, или требуют специфических настроек для активации полного объёма памяти в режимах, отличных от графики.

Важное уточнение по поддержке: Не все карты AMD поддерживаются ROCm «из коробки». Список официально поддерживаемых GPU часто короче, чем список реально работающих карт. Для чипов, не входящих в официальный список поддержки текущей версии ROCm, часто требуется подмена версии архитектуры через переменную окружения HSA_OVERRIDE_GFX_VERSION.

Пример: RX 6700 XT (архитектура RDNA 2, gfx1031) в некоторых конфигурациях может требовать подмены на gfx1030, если драйвер не определяет её корректно. Однако современные карты RDNA 3 (например, RX 7900 XTX, gfx1100) уже имеют официальную поддержку в актуальных версиях ROCm (6.0+), и подмена им обычно не требуется.

⚠️ ОПАСНО: В старых руководствах можно встретить советы по модификации прошивки (vBIOS) для разблокировки памяти. Не делайте этого без крайней необходимости и глубокого понимания рисков. Модификация vBIOS может привести к необратимому повреждению видеокарты («кирпичу»). Большинство современных карт AMD не требуют модификации vBIOS для работы с LLM, если используется актуальный ROCm и драйверы.

Установка и изоляция через Docker

Пытаться установить ROCm напрямую в хост-систему — плохая идея. Драйверы ROCm глубоко интегрированы в ядро Linux и могут конфликтовать с графическими драйверами (Mesa/AMDGPU). Лучшая стратегия — использование контейнеров с пробросом устройств.

Ниже приведён пример Dockerfile для сборки llama.cpp с поддержкой ROCm. Обратите внимание: мы используем CMake, так как он лучше управляет зависимостями HIP, чем старый Makefile.

FROM rocm/dev-ubuntu-22.04:6.0-complete

# Установка зависимостей для сборки llama.cpp
RUN apt-get update && apt-get install -y \
    build-essential \
    cmake \
    git \
    python3-pip \
    && rm -rf /var/lib/apt/lists/*

# Клонирование и сборка llama.cpp с поддержкой ROCm (HIP)
WORKDIR /app
RUN git clone https://github.com/ggerganov/llama.cpp.git && \
    cd llama.cpp && \
    mkdir build && cd build && \
    cmake .. -DGGML_HIPBLAS=ON -DCMAKE_HIP_ARCHITECTURES=gfx1100 && \
    make -j$(nproc)

# Копирование модели (в реальном сценарии лучше использовать volume)
COPY models/ /app/models/

# Переменные окружения для ROCm
# HSA_OVERRIDE_GFX_VERSION: подмена архитектуры только если карта не поддерживается официально
# HIP_VISIBLE_DEVICES: выбор конкретного GPU
ENV HSA_OVERRIDE_GFX_VERSION=11.0.0
ENV HIP_VISIBLE_DEVICES=0

# Запуск сервера. Путь к бинарнику зависит от структуры сборки CMake
CMD ["./llama.cpp/build/bin/llama-server", "-m", "/app/models/model.gguf", "--host", "0.0.0.0", "--port", "8080"]

Запуск контейнера требует проброса специфических устройств ROCm:

docker run -d \
  --name llm-rocm \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  -p 8080:8080 \
  -v ./models:/app/models \
  llm-rocm-image

Безопасность и доступ: Проброс /dev/kfd (Kernel Fusion Driver) и /dev/dri предоставляет контейнеру прямой доступ к GPU-вычислениям. Убедитесь, что вы доверяете образу, так как это может привести к исчерпанию ресурсов GPU или сбоям графической подсистемы хоста. Также убедитесь, что ваш пользователь на хосте входит в группу video, иначе контейнер не получит прав на доступ к устройствам.

Чек-лист диагностики ROCm: 1. Проверка видимости устройств: Выполните rocminfo внутри контейнера. Если список пуст, проблема в пробросе /dev/kfd или правах доступа. 2. Логирование ошибок памяти: ROCm часто падает с ошибкой HSA_STATUS_ERROR_OUT_OF_RESOURCES. Это не всегда означает нехватку VRAM. Часто это следствие фрагментации памяти или неправильного размера батча. 3. Версия драйвера: Убедитесь, что версия драйвера на хосте (amdgpu) совместима с версией ROCm в контейнере. Несовпадение приводит к тихим сбоям или зависаниям.

Vulkan: Кроссплатформенный компромисс

Vulkan — это низкоуровневый API, который позволяет писать высокопроизводительный код для GPU от разных производителей (AMD, NVIDIA, Intel, Apple через MoltenVK). Для LLM Vulkan интересен своей универсальностью: один бинарник может работать на Windows, Linux и macOS.

Почему Vulkan для LLM сложен?

В отличие от CUDA, где есть высокоуровневые библиотеки вроде cuBLAS, в Vulkan вы часто имеете дело с более примитивными инструментами. Реализация матричных умножений (GEMM) на Vulkan требует ручной оптимизации под конкретную архитектуру GPU.

Наиболее популярным проектом, использующим Vulkan для LLM, является llama.cpp с бэкендом Vulkan. Он использует библиотеку ggml, которая абстрагирует работу с GPU.

Особенности производительности

Производительность Vulkan-бэкенда сильно зависит от драйверов: * NVIDIA: Драйверы NVIDIA для Vulkan часто уступают CUDA по производительности в задачах машинного обучения, так как NVIDIA оптимизирует CUDA в первую очередь. Однако для инференса LLM разница может быть менее критичной, чем в сырых вычислениях. * AMD: Драйверы AMD (RADV) для Vulkan показывают хорошие результаты, особенно на картах RDNA 2/3. * Intel: Поддержка Vulkan на Intel Arc улучшается, но всё ещё может быть нестабильной для больших моделей.

Изоляция и запуск

Важно понимать: драйверы GPU (Mesa, NVIDIA proprietary, AMDGPU) должны быть установлены и обновлены на хосте. Docker изолирует только библиотеки пользовательского пространства (SDK, компиляторы шейдеров), но не драйвер ядра. Вы не можете «установить» драйвер Vulkan внутри контейнера, если он не установлен на хосте.

Для Vulkan часто проще использовать нативную установку с контролем версий через пакетный менеджер (apt/dnf), чем пытаться полностью изолировать его в Docker, так как проброс ICD (Installable Client Driver) может быть сложным.

При запуске llama.cpp с Vulkan важно правильно выбрать GPU, если в системе их несколько.

# Список доступных GPU Vulkan
./llama.cpp/build/bin/llama-server --list-devices

# Запуск с выбором конкретного устройства (индекс из списка выше)
./llama.cpp/build/bin/llama-server \
  -m model.gguf \
  --device vulkan0 \
  --n-gpu-layers 40 \
  --ctx-size 4096

Эвристика выбора слоёв: В Vulkan перенос слоёв на GPU может быть менее предсказуемым, чем в CUDA. Не используйте фиксированное число (например, 10) как универсальное правило. 1. Оцените размер модели и доступную VRAM. 2. Начните с загрузки всех слоёв на GPU (--n-gpu-layers 999). 3. Если приложение падает с ошибкой VK_ERROR_DEVICE_LOST или вылетает из-за нехватки памяти, уменьшайте количество слоёв на GPU, оставляя остальные на CPU. 4. Ошибка VK_ERROR_DEVICE_LOST часто указывает на перегрев, нехватку памяти или сбой драйвера, который не смог корректно обработать запрос.

Специализированные runtime: Intel OpenVINO и Apple MLX

Помимо ROCm и Vulkan, существуют runtime-решения, оптимизированные под конкретные архитектуры.

Intel OpenVINO

OpenVINO — это набор инструментов для оптимизации и развертывания моделей ИИ на процессорах Intel, GPU Intel и NPU. Для LLM на CPU Intel (особенно с AVX-512) OpenVINO может быть быстрее, чем чистый CPU-бэкенд llama.cpp.

Когда использовать: * У вас нет дискретной GPU, но есть современный CPU Intel (12-е поколение и новее). * Вам нужна максимальная энергоэффективность.

Ограничения: OpenVINO не поддерживает формат GGUF напрямую. llama.cpp использует GGUF, тогда как OpenVINO работает с моделями в форматах ONNX или PyTorch. Для использования OpenVINO необходимо конвертировать модели из HuggingFace в формат Intermediate Representation (IR) с помощью инструментов OpenVINO, что требует отдельного пайплайна подготовки моделей.

Apple MLX

Для пользователей Mac с чипами M1/M2/M3/M4 MLX — это нативный путь. MLX использует unified memory (общую память CPU и GPU), что позволяет загружать модели, превышающие объём VRAM традиционных дискретных GPU.

Ключевое преимущество: Отсутствие копирования данных между CPU и GPU. Недостаток: Экосистема инструментов MLX всё ещё развивается. Многие функции, доступные в CUDA/ROCm (например, квантование на лету), могут отсутствовать или работать медленнее. Также помните, что когда модель начинает активно использовать системную RAM (сверх выделенной GPU-памяти), производительность падает, так как пропускная способность RAM ниже, чем у VRAM.

Изоляция сборок и диагностика без глобального upgrade

Главный риск при работе с альтернативными runtime — «засорение» системы. Установка ROCm может сломать графическую подсистему. Установка Vulkan SDK (инструментов разработки) безопасна, но конфликт может возникнуть, если вы попытаетесь установить несколько несовместимых версий драйверов или ICD одновременно.

Стратегия изоляции

  1. Контейнеризация для ROCm: Используйте Docker или Podman для всех экспериментов с ROCm. Это позволяет держать разные версии ROCm/HIP runtime в изолированных пространствах, при условии, что драйвер ядра (amdgpu) на хосте совместим.
  2. Нативная установка для Vulkan: Для Vulkan часто проще использовать нативную установку, так как драйверы должны быть на хосте. Контролируйте версии через пакетный менеджер.
  3. Flatpak/Snap для GUI-приложений: Если вы используете GUI-интерфейсы для LLM (например, Ollama GUI), предпочитайте их установку через Flatpak. Это снижает риск конфликта системных библиотек.
  4. Отдельные виртуальные окружения Python: Для runtime, зависящих от Python (как MLX или OpenVINO), используйте venv или conda. Не устанавливайте пакеты глобально.

Диагностика проблем

Когда LLM не запускается на не-CUDA оборудовании, стандартные методы диагностики часто недостаточны.

Чек-лист диагностики:

  1. Проверка поддержки инструкций:

    • Для CPU: lscpu | grep avx512 (для OpenVINO/llama.cpp CPU).
    • Для GPU: Используйте утилиты производителя (rocminfo, vulkaninfo). Примечание: vulkaninfo входит в Vulkan SDK. Если вы не устанавливали SDK глобально, запустите эту утилиту внутри контейнера с SDK или используйте альтернативные методы проверки (например, запуск простого Vulkan-приложения).

  2. Анализ логов драйвера:

    • ROCm: dmesg | grep -i amdgpu
    • Vulkan: Проверьте статус устройства через vulkaninfo --summary (убедитесь, что устройство имеет статус VK_PHYSICAL_DEVICE_TYPE_DISCRETE_GPU).

  3. Тестирование памяти:

    • Запустите модель с минимальным контекстом (--ctx-size 512) и одним слоем на GPU. Если работает — увеличивайте параметры постепенно. Это поможет отделить проблемы с памятью от проблем с вычислениями.

  4. Сравнение с CPU-режимом:

    • Запустите ту же модель в режиме CPU (--n-gpu-layers 0). Если она работает, проблема точно в GPU-бэкенде (драйверы, память, синхронизация). Если нет — проблема в самой модели или её квантовании.

Заключение

Выбор между ROCm, Vulkan и специализированными runtime — это компромисс между стоимостью оборудования и сложностью эксплуатации. ROCm предлагает высокую производительность на картах AMD, но требует тщательной настройки и изоляции. Vulkan обеспечивает кроссплатформенность, но может уступать в производительности на некоторых архитектурах. Специализированные runtime, такие как MLX или OpenVINO, идеальны для конкретных экосистем (Apple, Intel), но ограничивают переносимость.

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

Практический чек-лист: Подготовка к запуску LLM на не-CUDA оборудовании

  1. [ ] Проверка оборудования:

    • [ ] Определите точную модель GPU и архитектуру (например, RDNA 2, RDNA 3, Intel Arc).
    • [ ] Проверьте официальный список поддержки ROCm/Vulkan для вашей версии драйвера.
    • [ ] Убедитесь, что драйверы GPU установлены и обновлены на хосте.

  2. [ ] Выбор стратегии изоляции:

    • [ ] Для ROCm: Подготовьте Dockerfile с пробросом /dev/kfd и /dev/dri.
    • [ ] Для Vulkan: Решите, использовать ли нативную установку или контейнер с пробросом ICD.
    • [ ] Для OpenVINO/MLX: Создайте изолированное Python-окружение (venv/conda).

  3. [ ] Подготовка модели:

    • [ ] Убедитесь, что формат модели поддерживается выбранным runtime (GGUF для llama.cpp, IR для OpenVINO, MLX-формат для Apple).
    • [ ] При необходимости конвертируйте модель (например, из HuggingFace в IR для OpenVINO).

  4. [ ] Первый запуск и диагностика:

    • [ ] Запустите модель с минимальными параметрами (--ctx-size 512, --n-gpu-layers 1).
    • [ ] Проверьте логи (dmesg, rocminfo, vulkaninfo) на наличие ошибок.
    • [ ] Если запуск успешен, постепенно увеличивайте контекст и количество слоёв на GPU, следя за стабильностью.

  5. [ ] Безопасность:

    • [ ] Убедитесь, что вы доверяете используемым Docker-образам.
    • [ ] Не модифицируйте vBIOS без крайней необходимости.

Глава 6. llama.cpp и OpenAI-compatible serving

Переход от экспериментов в терминале к интеграции локальной модели в существующий продукт требует решения вопроса совместимости. Большинство современных приложений — от фреймворков вроде LangChain до простых веб-интерфейсов — ожидают стандартный интерфейс API OpenAI. llama.cpp предоставляет встроенный сервер llama-server, реализующий этот протокол. Однако «совместимость» не означает «готовность к продакшену» из коробки. Эта глава разбирает критические параметры сервера, определяющие стабильность, скорость и предсказуемость ответов.

Архитектура сервера и модель слотов

В отличие от классических веб-серверов, где каждый запрос часто обрабатывается в отдельном потоке или процессе, llama.cpp использует архитектуру на основе слотов (slots). Слот — это выделенное контекстное окно для одного пользователя или сессии.

Параметр --parallel (или -np) определяет количество одновременных слотов. Важно понимать: это не количество потоков CPU, а количество независимых контекстных окон, которые сервер может обслуживать параллельно.

Ключевое ограничение: Память GPU (VRAM) или оперативная память (RAM) делится между всеми активными слотами. Если модель занимает 10 ГБ, а вы запускаете 4 слота с контекстом 4096 токенов каждый, вам потребуется дополнительная память под KV-кэш (Key-Value cache) для каждого слота.

# Пример запуска с 4 параллельными слотами
# --host 127.0.0.1: Безопасный режим, доступ только с локальной машины.
# Для внешнего доступа используйте 0.0.0.0, но ОБЯЗАТЕЛЬНО за reverse proxy.
./llama-server -m model.gguf \
  --host 127.0.0.1 \
  --port 8080 \
  --parallel 4 \
  --ctx-size 8192

Если все слоты заняты, новые запросы обычно ставятся в очередь ожидания (блокировка), а не возвращают ошибку мгновенно. При длительном ожидании клиент может получить таймаут. Для предотвращения накопления очереди и обеспечения предсказуемой задержки необходимо использовать балансировщик нагрузки или ограничивать количество одновременных соединений на уровне reverse proxy, а не пытаться увеличить --parallel до бесконечности.

Batch processing: server vs ubatch

В llama.cpp существует два уровня батчинга (batching — пакетной обработки), которые часто путают:

  1. --batch-size (или -b): Размер батча для обработки всех токенов, накопленных во всех активных слотах за один шаг генерации. Это глобальный лимит на количество токенов, которые модель пропустит через себя за один проход.
  2. --ubatch-size (или -ub): Максимальный размер батча для одного слота.

Эвристика настройки: * Убедитесь, что ubatch-size ≤ batch-size. Нарушение этого условия приведет к ошибке или непредсказуемому поведению. * Для большинства задач ubatch-size можно оставить по умолчанию (512) или увеличить до 1024, если у вас много коротких запросов. * batch-size критичен для этапа предобработки промпта (prefill stage). Если вы отправляете длинный промпт (например, 2000 токенов), сервер разобьет его на куски размером batch-size. Увеличение batch-size ускоряет обработку длинных промптов, но требует больше памяти.

Рекомендации по батчингу: * Если преобладают длинные промпты (например, в задачах RAG — Retrieval-Augmented Generation), увеличьте --batch-size до 2048–4096. * Если преобладают короткие чаты, оставьте --batch-size в диапазоне 512–1024 для экономии памяти.

Управление памятью и производительностью

Выгрузка слоев на GPU (--n-gpu-layers)

Это главный рычаг управления балансом между скоростью и потреблением VRAM. Параметр --n-gpu-layers (или -ngl) определяет, сколько слоев нейросети выгружается на видеокарту.

Flash Attention и типы KV-кэша

Производительность на длинных контекстах сильно зависит от реализации механизма внимания (Attention).

Flash Attention

Флаг --flash-attn включает оптимизированные ядра для вычисления внимания. * Плюсы: Значительное ускорение на длинных контекстах (>4k токенов), снижение потребления памяти. * Ограничения: Поддержка зависит от версии llama.cpp, бэкенда (CUDA, Metal, Vulkan) и архитектуры GPU. На CPU эффект минимален или отсутствует. * Проверка: Всегда проверяйте лог запуска на наличие сообщений об ошибках или предупреждениях, связанных с Flash Attention. Если функция не поддерживается, сервер может игнорировать флаг или работать некорректно.

KV Cache Types

По умолчанию KV-кэш хранится в формате f16 (float16). Это занимает много памяти. * --cache-type-k q8_0 и --cache-type-v q8_0: Квантование ключей и значений до 8 бит. * Эффект: Экономия памяти ~50% для KV-кэша. * Риск: Возможная потеря качества на очень длинных контекстах или сложных задачах рассуждения. * Рекомендация: Для продакшена с ограниченной VRAM начните с q8_0. Если заметите деградацию качества (галлюцинации, потеря деталей), откатитесь на f16.

# Конфигурация для экономии памяти и ускорения (если поддерживается GPU)
./llama-server -m model.gguf \
  --flash-attn \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --ctx-size 16384 \
  --n-gpu-layers 999

MMAP и управление памятью

По умолчанию llama.cpp использует mmap (memory-mapped files) для загрузки модели. Это позволяет ОС управлять страницами памяти: в RAM держатся только те части модели, которые активно используются.

Сценарий Рекомендация Причина
GPU + модель помещается в VRAM Отключить (--no-mmap) mmap может добавить накладные расходы на чтение с диска при первом обращении к слоям.
Медленный диск (HDD) Отключить (--no-mmap) Гарантирует полную загрузку модели в RAM перед началом работы, избегая лагов.
Контейнеры с лимитами RAM Отключить (--no-mmap) mmap может привести к непредсказуемому поведению OOM-killer из-за особенностей учета памяти.
Несколько моделей одновременно Оставить (--mmap) Экономит RAM, так как общие части моделей могут переиспользоваться.
Модель больше физической RAM Оставить (--mmap) Позволяет работать с моделью, частично загружая её с диска.

Потоки CPU (--threads)

Для CPU-инференса или гибридного режима критичен параметр --threads (-t). По умолчанию llama.cpp может использовать не оптимальное количество потоков. * Совет: Явно задайте --threads равным количеству физических ядер процессора. Использование логических ядер (SMT/Hyper-Threading) часто не дает прироста скорости для инференса и может увеличить задержки. Для GPU-инференса этот параметр влияет на предобработку данных.

Reasoning и Chat Templates

OpenAI-совместимый API ожидает массив messages. llama.cpp должен преобразовать этот массив в формат, понятный конкретной модели (например, ChatML, Llama-3, Mistral).

Используйте флаг --chat-template для явного указания шаблона. Если шаблон не указан, сервер попытается угадать его из метаданных GGUF. Это часто приводит к ошибкам форматирования.

Пример проблемы: Модель ожидает формат <|start_header_id|>user<|end_header_id|>, но получает стандартный Human: .... Результат — мусор в ответе или игнорирование инструкций.

Решение: Рекомендуется явно указывать шаблон для исключения ошибок автоопределения. Для моделей, поддерживающих reasoning (например, DeepSeek-R1, QwQ), убедитесь, что шаблон корректно обрабатывает теги <think>.

Флаг --jinja включает поддержку Jinja2-шаблонов. Он необходим для корректной обработки сложных шаблонов, включая условные блоки и циклы, которые используются в большинстве современных моделей (Llama 3, Mistral, Qwen). Без него сервер может использовать упрощенную подстановку, что приведет к ошибкам.

# Явное указание шаблона для Llama 3 с поддержкой Jinja2
./llama-server -m model.gguf \
  --chat-template chatml \
  --jinja

Воспроизводимость запуска

Для отладки и тестирования критично получать одинаковые ответы при одинаковых входных данных.

  1. Seed: Используйте --seed 42. Без этого параметра сервер будет использовать случайное зерно при каждом запуске, и ответы будут различаться даже при temperature=0.
  2. Temperature: Для детерминированного вывода ставьте --temperature 0. Однако учтите, что из-за параллелизма и особенностей плавающей арифметики на GPU полная бит-в-бит воспроизводимость не гарантируется, но семантическая идентичность достигается.
  3. LoRA: Если вы используете LoRA-адаптеры (Low-Rank Adaptation), фиксируйте их версии. llama.cpp позволяет загружать несколько LoRA одновременно, но порядок их применения важен.

Пример интеграции

Чтобы убедиться, что сервер работает корректно, отправьте тестовый запрос, используя библиотеку openai в Python, указав локальный base_url.

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:8080/v1",
    api_key="not-needed" # Ключ не требуется для локального llama-server
)

response = client.chat.completions.create(
    model="local-model",
    messages=[
        {"role": "user", "content": "Привет! Кто ты?"}
    ],
    temperature=0.7
)

print(response.choices[0].message.content)

Чек-лист продакшен-конфигурации

Перед запуском в production проверьте следующие пункты:

Сеть и безопасность

Память и ресурсы

Конфигурация модели

Заключение

llama.cpp предоставляет мощный и гибкий механизм для локального инференса, но его OpenAI-совместимость требует ручной настройки. Не полагайтесь на значения по умолчанию. Понимание взаимодействия между слотами, батчингом, выгрузкой слоев на GPU и типами кэша позволяет выжать максимум из вашего железа, сохраняя предсказуемость ответов. Начните с минимальной конфигурации, измерьте потребление памяти и задержки, а затем итеративно оптимизируйте параметры под вашу нагрузку.

Глава 7. MTP и speculative decoding: ускорение без потери качества

В предыдущих главах мы сосредоточились на оптимизации памяти и квантовании. Однако даже идеально настроенная модель сталкивается с фундаментальным ограничением архитектуры Transformer: генерация токенов строго последовательна. Каждый новый токен требует полного прохода через все слои сети, завися от предыдущего. Это создает «узкое горлышко» пропускной способности памяти (memory-bound), где GPU простаивает, ожидая загрузки весов, а не выполняя полезные вычисления.

Спекулятивное декодирование (Speculative Decoding, SD) и его современная архитектурная вариация Multi-Token Prediction (MTP) позволяют обойти это ограничение. Они не меняют математическую природу модели, но меняют стратегию генерации, позволяя предсказывать несколько токенов за один шаг верификации.

Принцип работы: Draft и Target

Классическое спекулятивное декодирование работает по схеме «черновик и проверка» (Draft and Verify).

  1. Draft Model (Черновик): Маленькая, быстрая модель (например, 1B параметров) генерирует последовательность из $K$ токенов.
  2. Target Model (Цель): Большая, качественная модель (например, 70B параметров) проверяет эти $K$ токенов за один проход.
  3. Acceptance (Принятие): Если токен в черновике совпадает с вероятностным распределением целевой модели, он принимается. Если нет — генерация продолжается от точки расхождения, и черновик корректируется.

Важная оговорка: Математически доказано, что при использовании алгоритма принятия rejection sampling итоговое распределение токенов идентично тому, что выдала бы большая модель при обычном декодировании. Однако на практике, особенно при использовании квантованных моделей (GGUF, AWQ), численные ошибки округления могут незначительно искажать логиты. Поэтому гарантия «идентичности» действует в рамках точности вычислений движка инференса.

Псевдокод процесса

Ниже приведена упрощенная схема логики. В реальных движках (vLLM, llama.cpp) этот процесс оптимизирован с использованием KV-cache (кэша ключей и значений), чтобы избежать повторной обработки всего контекста.

def speculative_decode(target_model, draft_model, prompt, n_max=5):
    tokens = []
    current_input = prompt

    while not is_eos(current_input):
        # 1. Черновик генерирует K токенов
        # В реальности здесь также сохраняются логиты черновика для сравнения
        draft_tokens, draft_logits = draft_model.generate(
            current_input, 
            max_new_tokens=n_max, 
            return_logits=True
        )

        # 2. Целевая модель оценивает вероятность каждого черновика
        # Важно: один проход через Target Model для всей последовательности
        # target_logits[i] соответствует вероятности i-го токена черновика
        target_logits = target_model.forward(
            current_input + draft_tokens,
            use_kv_cache=True # Упрощение: реальный API сложнее
        )

        accepted_this_step = []

        for i, token in enumerate(draft_tokens):
            # Вероятность токена в целевой модели
            p_target = softmax(target_logits[i])[token]
            # Вероятность токена в черновике (сохраненная ранее)
            p_draft = softmax(draft_logits[i])[token]

            # Критерий принятия (Rejection Sampling)
            if random() < min(1.0, p_target / p_draft):
                accepted_this_step.append(token)
            else:
                # Если не приняли, берем токен из распределения разницы
                # и останавливаем проверку черновика
                residual_token = sample_from_residual_distribution(p_target, p_draft)
                accepted_this_step.append(residual_token)
                break

        # Обновляем вход только токенами, принятыми на ТЕКУЩЕМ шаге
        current_input += accepted_this_step
        tokens.extend(accepted_this_step)

    return tokens

Параметры настройки: n_max и Acceptance Rate

Эффективность метода зависит от двух переменных: длины черновика (n_max) и качества черновика (acceptance rate).

n_max: Сколько токенов гадать?

n_max — это количество токенов, которые черновик пытается угадать за один шаг.

Acceptance Rate: Качество черновика

Это процент токенов из черновика, которые принимает целевая модель.

Эвристика: Если acceptance rate падает ниже 50%, проверьте температуру генерации (высокая температура снижает предсказуемость), смените черновик на более близкий по архитектуре или уменьшите n_max.

Multi-Token Prediction (MTP): Архитектурная эволюция

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

Multi-Token Prediction (MTP) — это архитектурная особенность модели, которая позволяет ей предсказывать не только следующий токен, но и последующие $N$ токенов одновременно внутри одной сети.

Как это работает?

Вместо отдельного черновика, модель имеет дополнительные «головы» (heads) или использует механизм, позволяющий на каждом шаге выдавать распределение для токенов $t+1, t+2, ..., t+N$.

  1. Модель предсказывает токен $t+1$ (основной выход).
  2. Параллельно она предсказывает вероятности для $t+2, t+3...$ на основе контекста до $t$.
  3. Эти предсказания используются как черновик для следующего шага верификации.

MTP и Self-Speculative Decoding

Важно не путать понятия: * MTP — это способность модели генерировать несколько токенов за проход. * Speculative Decoding — это стратегия использования этих токенов с верификацией.

Когда модель с MTP используется для ускорения, она часто работает в режиме Self-Speculative Decoding. В этом случае «черновик» — это предсказания MTP-головы, а «верификатор» — основная голова той же модели. Это устраняет необходимость в отдельной модели-черновике.

Преимущества MTP перед классическим Speculative Decoding

  1. Единая модель: Не нужно хранить и загружать веса отдельного черновика. Экономия VRAM критична для локальных машин.
  2. Согласованность: Черновик и целевая модель — это одна и та же сеть. Acceptance rate обычно выше, так как «черновик» знает внутренние представления целевой модели.
  3. Простота деплоя: Один бинарник, один файл весов.

Недостатки и ограничения MTP

Когда MTP ускоряет, а когда мешает?

Не стоит включать спекулятивное декодирование «по умолчанию». Вот чек-лист применимости.

✅ MTP ускоряет, когда:

  1. Высокая пропускная способность памяти, низкие вычисления: Типичный сценарий для больших моделей (70B+) на GPU с быстрым HBM. Узкое место — загрузка весов. MTP позволяет «размазать» стоимость загрузки весов на несколько токенов.
  2. Длинные генерации: Если вы генерируете сотни токенов, накладные расходы на инициализацию черновика окупаются.
  3. Предсказуемый текст: Код, структурированные данные, шаблоны. Здесь acceptance rate может достигать 80–90% (в идеальных условиях), но чаще находится в диапазоне 60–80%.
  4. Ограниченный VRAM: MTP не требует памяти под отдельную черновую модель, в отличие от классического Speculative Decoding.
  5. Batch Size = 1: Эффективность максимальна при обработке одного запроса за раз.

❌ MTP мешает или бесполезен, когда:

  1. Маленькие модели (<7B): Для маленьких моделей узкое место часто смещается в сторону вычислений (compute-bound) или латентности запуска ядра. Оверхед на проверку нескольких токенов может съесть всю выгоду.
  2. Короткие ответы: Если вы генерируете 5-10 токенов, накладные расходы на настройку окна верификации могут превысить время генерации.
  3. Высокая энтропия вывода: Креативное письмо, генерация случайных чисел, сложные рассуждения с высокой неопределенностью. Acceptance rate падает, и модель тратит время на проверку неверных гипотез.
  4. Большой Batch Size (>16-32): Эффективность резко падает, так как верификация требует синхронизации по всем последовательностям в батче. Разные запросы имеют разный acceptance rate, что приводит к простаиванию GPU.
  5. Отсутствие поддержки в движке: Если ваш inference-движок плохо реализовал MTP (например, делает лишние копирования памяти), вы получите замедление.

Важно про Latency: MTP/SD оптимизирует throughput (скорость генерации длинных ответов), но может незначительно увеличить TTFT (Time To First Token — задержку первого токена) из-за дополнительных вычислений MTP-головы или загрузки весов черновика.

Практические рекомендации и движки

Поддержка в движках

Реализация MTP и SD сильно зависит от движка инференса.

Движок Флаги / Настройки Примечание
vLLM --speculative-model, --num-speculative-tokens Для MTP (если поддерживается архитектурой, напр. DeepSeek) может определяться автоматически или требовать специфичных флагов версии.
llama.cpp -mdraft, -ngl_draft, -sp Поддержка MTP появляется в новых версиях через флаг -mtp (требует компиляции с поддержкой).
TGI --speculative-decoding Требует указания модели-черновика.

Выбор моделей

Настройка параметров

  1. Начните с базовой модели. Убедитесь, что стандартное декодирование работает стабильно.
  2. Настройте n_max динамически.
    • Для кода: n_max = 4-6.
    • Для прозы: n_max = 2-3.
    • Для чата: n_max = 3.
  3. Мониторьте Acceptance Rate. В логах vLLM или TGI есть метрика spec_decode_acceptance_rate.
    • Если < 0.5: Отключите спекулятивное декодирование или уменьшите n_max.
    • Если > 0.8: Попробуйте увеличить n_max на 1.
  4. Учитывайте температуру. Высокая температура (temp > 1.0) снижает acceptance rate. Для максимальной скорости используйте низкую температуру.

Чек-лист перед включением MTP/SD

  1. [ ] Тип задачи: Генерация длинная (>50 токенов) и предсказуемая (код, шаблоны)?
  2. [ ] Размер модели: Модель большая (>7B) и работает в memory-bound режиме?
  3. [ ] Batch Size: Вы работаете с batch_size = 1 или очень малым батчем?
  4. [ ] Поддержка движка: Ваш движок (vLLM, llama.cpp) официально поддерживает MTP для вашей архитектуры?
  5. [ ] Метрики: Вы готовы измерять TTFT и Throughput до и после включения?
  6. [ ] Квантование: Вы понимаете, что квантование может вносить небольшие погрешности в верификацию?

Заключение

MTP и speculative decoding — это не «магическая кнопка ускорения», а инструмент компромисса. Они обменивают дополнительную вычислительную мощность (проверка нескольких токенов) на экономию времени доступа к памяти. На локальных машинах, где VRAM часто является главным ограничением, MTP становится все более привлекательной альтернативой классическому спекулятивному декодированию с отдельным черновиком.

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

Глава 8. Engram, QSA и SSD-backed state: иллюзия бесконечной памяти

В предыдущих главах мы закрепили базовое правило локального инференса: VRAM — это единственный ресурс, который нельзя обмануть. Когда модель не помещается в видеопамять, инженеры часто обращаются к концепции «внешней памяти» или offloading (выгрузке данных), полагая, что быстрый NVMe SSD может заменить медленную RAM или стать прозрачным расширением VRAM.

Эта глава разрушает миф о том, что SSD является автоматическим ускорителем для LLM. Мы разберем три разные сущности, которые часто путают: 1. Engram-память (фиксированное состояние в архитектурах типа SSM/RWKV). 2. QSA (Query-Sparse Attention — метод разреженного внимания в трансформерах). 3. SSD-backed state (стратегия хранения любого состояния на диске).

Ключевой вывод: работа с диском — это всегда компромисс между latency (задержкой) и throughput (пропускной способностью), требующий явного управления, а не прозрачной абстракции операционной системы.

1. Физика доступа к памяти: RAM vs SSD

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

Для LLM критична именно latency при малых размерах запросов (small I/O), так как инференс состоит из миллионов микроскопических операций чтения весов и состояния.

Сравнение характеристик

Параметр RAM (DDR5) NVMe SSD (Gen4) HDD (SATA)
Latency (задержка) ~80–100 нс ~10–100 мкс ~5–10 мс
Throughput (поток) ~50–100 ГБ/с ~5–7 ГБ/с ~0.2 ГБ/с
Стоимость за ГБ Высокая Средняя Низкая

Важное уточнение: Разница в latency между RAM и NVMe составляет примерно 100–200 раз (2 порядка), а не «в 1000 раз», как иногда ошибочно утверждают. Однако для последовательного чтения больших блоков (например, загрузки модели) SSD проигрывает RAM не так критично, так как там доминирует throughput. Проблема возникает при случайном доступе.

Почему mmap — это ловушка для инференса

Многие фреймворки (например, llama.cpp) используют mmap (memory-mapped file) для загрузки весов. Это позволяет ОС подгружать страницы памяти по требованию (lazy loading).

На первый взгляд, это идеально: вы можете «загрузить» модель на 70B параметров, даже если у вас всего 16 ГБ RAM, потому что ОС будет выгружать неиспользуемые страницы на swap. Однако для LLM это катастрофа.

Как это работает на низком уровне

Когда процессор обращается к адресу, который не находится в физической RAM, происходит page fault (страничное прерывание). ОС перехватывает прерывание, находит нужную страницу на диске, копирует её в RAM и обновляет таблицы страниц (Page Table Entries, PTE).

Для LLM проблема усугубляется двумя факторами: 1. Размер страницы: Стандартная страница — 4 КБ. Современные модели используют блоки памяти по 2 МБ (huge pages) для снижения нагрузки на TLB (Translation Lookaside Buffer — кэш переводов виртуальных адресов в физические). Если huge pages отключены, количество промахов TLB значительно возрастает, вызывая каскадные промахи кэша процессора. 2. Случайный доступ к весам: В Dense-моделях доступ к весам слоистый и предсказуемый. Но в MoE (Mixture of Experts) или при использовании sparse attention активные веса могут быть разбросаны по всему файлу модели.

Псевдокод: Правильное и неправильное использование mmap

import mmap
import os

# НЕПРАВИЛЬНО: Наивное использование mmap для инференса
# Модель "загружается" мгновенно, но каждый шаг генерации вызывает page faults.
weights = mmap.mmap(open("model.gguf", "rb").fileno(), 0)

def forward_layer_naive(x, layer_idx):
    # Обращение к весам слоя.
    # Если страница не в RAM -> Page Fault -> Disk I/O.
    # Время: ~10–100 мкс (NVMe) до ~10 мс (HDD).
    # Для 1000 токенов это добавит секунды к генерации.
    w = weights[layer_idx] 
    return matmul(x, w)

# ПРАВИЛЬНО: Предварительная загрузка и блокировка памяти
# 1. Читаем модель в RAM полностью (или критическую часть).
# 2. Используем madvise для подсказки ОС о последовательном доступе.
# 3. Используем mlock, чтобы ОС не выгружала эти страницы в swap.

def load_and_lock_weights(filepath):
    with open(filepath, "rb") as f:
        # Читаем файл в память
        data = f.read()

    # Подсказка ОС: данные будут читаться последовательно
    # MADV_SEQUENTIAL помогает предвыборке (prefetching)
    os.madvise(data, os.MADV_SEQUENTIAL)

    # Блокировка памяти: запрещает ОС выгружать эти страницы в swap
    # Требует прав root или настроенных лимитов (ulimit -l)
    try:
        os.mlock(data)
    except PermissionError:
        print("Warning: mlock failed. Check ulimit -l.")

    return data

Практическая рекомендация: Используйте mmap только для первичной загрузки весов в RAM. Для инференса убедитесь, что модель полностью resides (находится) в RAM (или VRAM). Если модель не помещается в RAM, offload на диск должен быть явным (через логику приложения), а не через swap. Swap-файл на NVMe медленнее RAM на 2 порядка (latency ~10–100 мкс vs ~100 нс).

2. Engram vs KV-cache: два типа состояния

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

Динамический KV-cache (Transformer)

В классических трансформерах (Llama, Mistral) состояние контекста хранится в KV-cache (Key-Value cache). * Размер: Растет линейно с длиной контекста. * Доступ: При генерации нового токена нужно обратиться ко всем предыдущим ключам и значениям (в стандартном attention) или к их подмножеству (в sparse attention). * Проблема: Для контекста в 100k токенов KV-cache может занимать десятки гигабайт.

Фиксированное состояние (Engram / SSM)

В архитектурах State-Space Models (SSM), таких как Mamba, или в гибридных моделях (RWKV), используется механизм, часто называемый Engram-памятью или скрытым состоянием. * Размер: Фиксирован и не зависит от длины контекста. * Доступ: Состояние обновляется рекурсивно. * Преимущество: Не требует хранения истории всех токенов. * Недостаток: Может терять точность на очень длинных зависимостях по сравнению с полным attention.

Вывод: SSD-backed state имеет смысл в основном для KV-cache в трансформерах с длинным контекстом. Для Engram-памяти (фиксированного размера) выгрузка на диск обычно нецелесообразна, так как это состояние нужно обновлять на каждом шаге, и его размер мал.

3. QSA и Gather: когда разреженность не спасает

Query-Sparse Attention (QSA) и другие методы разреженного внимания (Longformer, BigBird) обещают линейную сложность вместо квадратичной. Логика проста: вместо того чтобы считать attention для всех токенов, мы выбираем только наиболее релевантные ключи (keys) и значения (values).

На бумаге это снижает объем данных, которые нужно держать в памяти. На практике это создает проблему случайного доступа к KV-cache.

Проблема Gather-операций

В стандартном attention доступ к KV-cache последовательный или блочный. GPU оптимизированы для коалесцированных (coalesced) обращений к памяти. В QSA вы выполняете операцию gather: 1. Вычисляется индекс важного токена (например, idx = [10, 500, 1024, ...]). 2. Нужно извлечь строки KV_cache[idx].

Если KV-cache хранится в VRAM, это дорого из-за разрыва в адресах (non-coalesced access). Если KV-cache выгружен на SSD, это катастрофично.

Схема: SSD-backed KV-cache с QSA

[Query] -> [Router] -> [Indices: 10, 500, 1024]
                          |
                          v
                  [KV-Cache on SSD]
                          |
                  [Random Read I/O]
                          |
                          v
                  [Latency Spike]

Каждый шаг генерации (decoding step) требует нескольких случайных чтений с диска. При скорости NVMe ~100k IOPS (для маленьких блоков) и latency ~10–100 мкс, даже 10 таких операций добавят 0.1–1 мс к каждому токену.

Уточнение масштаба: Для модели с 20 токенами в секунду (50 мс на токен) добавление 1 мс — это замедление на 2%. Это может быть незаметно для пользователя. Однако, при агрессивном sparse attention (например, выборка 1% от контекста в 100k токенов) количество операций gather растет линейно с длиной контекста. Для длинных документов latency становится доминирующим фактором, превращая генерацию в слайд-шоу.

Эвристика: QSA эффективен, когда KV-cache помещается в VRAM, но вы хотите уменьшить вычислительную нагрузку. Он неэффективен как механизм экономии памяти через выгрузку на SSD, так как случайный доступ к SSD убивает throughput.

4. A/B тест: UMA vs Disk-backed state

Давайте проведем мысленный эксперимент на типичной рабочей станции: * CPU: AMD Ryzen 9 7950X * RAM: 64 ГБ DDR5-6000 * GPU: NVIDIA RTX 4090 (24 ГБ VRAM) * SSD: Samsung 990 Pro (NVMe Gen4)

Мы тестируем модель Llama-3-70B (квантованную до Q4_K_M, ~40 ГБ).

Сценарий A: UMA (Unified Memory Architecture) с offload в RAM

Модель частично в VRAM, частично в RAM. Используется llama.cpp с --n-gpu-layers 40. * Механизм: Весы, не помещающиеся в VRAM, лежат в RAM. CPU читает их из RAM и передает в VRAM через PCIe. * Latency: Чтение из RAM ~100 нс. PCIe transfer ~10 мкс. * Throughput: ~5–8 токенов/сек. * CPU Load: Высокая загрузка CPU из-за синхронизации и управления DMA (Direct Memory Access).

Сценарий B: Disk-backed state (Offload в Swap/SSD)

Модель частично в VRAM, частично в Swap (файл на NVMe). * Механизм: ОС выгружает страницы весов на SSD. При обращении к ним происходит page fault. * Latency: Чтение с NVMe ~10–100 мкс. Плюс overhead ОС на обработку page fault (~10–50 мкс). * Throughput: < 1 токен/сек. Часто система уходит в thrashing (постоянная подкачка страниц, когда система тратит больше времени на обмен данными, чем на вычисления).

Результаты A/B теста (оценочные)

Метрика Сценарий A (RAM Offload) Сценарий B (SSD Offload)
Первый токен (TTFT) 2–5 сек 10–30 сек
Скорость генерации 5–8 tok/s 0.5–1.5 tok/s
Стабильность Стабильно Нестабильно (зависит от кэша ОС)
Основное узкое место Пропускная способность PCIe Latency дисковой подсистемы

Вывод: SSD не является заменой RAM. Он является заменой отсутствующей RAM, но с потерей производительности на 1–2 порядка.

5. Стратегия: Когда использовать SSD?

  1. Хранение модели: Да. Загрузка модели с SSD быстрее, чем с HDD. Это стандартная практика.
  2. Хранение KV-cache: Только если контекст очень длинный (>100k токенов) и вы готовы к latency в секунды на каждый шаг генерации. Это применимо для офлайн-обработки документов, но не для чат-ботов.
  3. Хранение весов: Только если модель не помещается в RAM, и вы готовы к скорости < 1 токена/сек.

Заключение

SSD — это не магическое расширение памяти. Это медленное, но надежное хранилище. Lazy mmap и QSA могут помочь управлять памятью, но они не устраняют фундаментальное ограничение скорости доступа к данным.

Для senior-инженера ключевой навык — понимать, где заканчивается абстракция ОС и начинается физика железа. Если ваша модель не помещается в RAM, решение не в том, чтобы «доверить это SSD», а в том, чтобы: 1. Уменьшить модель (квантование, дистилляция). 2. Использовать более эффективную архитектуру (MoE с правильным роутингом или SSM). 3. Принять низкую скорость генерации как компромисс.

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

Практический чек-лист

Диагностика проблем с памятью

Оптимизация SSD-backed state

Глава 9. Честная benchmark-матрица: от хаоса к данным

Большинство локальных бенчмарков LLM страдают от фундаментальной методологической ошибки: они смешивают влияние аппаратных ограничений с настройками инференса, создавая результат, который невозможно воспроизвести в другой среде. Запуск llama.cpp или vLLM с дефолтными параметрами, без прогрева и контроля состояния памяти, дает цифры, которые отражают не столько производительность модели, сколько текущий шум системы: фоновые процессы, троттлинг и фрагментацию памяти.

В этой главе мы построим инженерный протокол тестирования, превращающий субъективное «ощущение скорости» в точную метрику. Мы будем использовать детерминированные промпты, строгий контроль контекста (от 1K до 128K токенов) и параллельный сбор метрик использования ресурсов. Наша цель — не найти «самую быструю модель», а понять, где именно ваша инфраструктура становится узким местом под нагрузкой.

1. Методология: почему «среднее» лжет

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

  1. Thermal Throttling (Троттлинг): GPU и CPU снижают частоты при перегреве. Первый запуск после простоя часто бывает быстрее из-за отсутствия накопленного тепла, но может быть медленнее из-за холодного кэша инструкций. Требуется прогрев.
  2. KV-Cache Fragmentation: При работе с длинным контекстом (например, 128K) память VRAM фрагментируется. Аллокатор может тратить время на поиск свободных блоков, даже если общая память формально доступна.
  3. Cold Start vs. Warm State: Загрузка весов модели в VRAM занимает секунды или минуты. Тестирование должно начинаться только после полной инициализации и стабилизации температурного режима.

Правило №1: Исключите замеры в состоянии Cold Start (до полной загрузки весов и прогрева кэшей). Правило №2: Никаких тестов без контроля температуры и utilization (загрузки) GPU. Правило №3: Каждый замер — это медиана из N повторений, а не среднее арифметическое (выбросы из-за фоновых процессов искажают среднее).

2. Архитектура тестового стенда

Нам нужен скрипт, который управляет жизненным циклом инференса. Ключевой момент — изоляция каждого теста и корректная инициализация модели.

Важное техническое замечание: В большинстве движков (включая llama.cpp) параметр n_ctx (максимальная длина контекста) задается при инициализации модели. Вы не можете динамически менять его «на лету» для одного экземпляра модели. Либо вы инициализируете модель с максимальным требуемым контекстом (что резервирует VRAM под KV-cache заранее), либо перезагружаете модель для каждого размера контекста. В примере ниже мы предполагаем инициализацию с максимальным контекстом для простоты, но в продакшене часто используют перезагрузку для экономии памяти.

Ниже приведена схема для Python, использующая llama-cpp-python. Обратите внимание на разделение метрик TTFT и Decode Speed.

import time
import json
import subprocess
import psutil
import pynvml  # Рекомендуемая библиотека для точного мониторинга NVIDIA GPU
from llama_cpp import Llama

class BenchmarkRunner:
    def __init__(self, model_path, max_context_length, n_repeats=5):
        self.model_path = model_path
        self.max_context_length = max_context_length
        self.n_repeats = n_repeats
        self.results = []
        self.llm = None

        # Инициализация NVML для точных метрик
        pynvml.nvmlInit()
        self.handle = pynvml.nvmlDeviceGetHandleByIndex(0)

    def load_model(self):
        """Загружает модель один раз перед началом матрицы тестов."""
        print(f"Загрузка модели: {self.model_path}")
        self.llm = Llama(
            model_path=self.model_path,
            n_ctx=self.max_context_length,
            n_gpu_layers=-1,  # Загружать все слои на GPU, если возможно
            verbose=False
        )
        # Прогрев: 3 прогона с минимальным контекстом для стабилизации кэша и температур
        self.warm_up()

    def warm_up(self):
        """Прогрев модели для исключения Cold Start."""
        dummy_prompt = "Hello" * 10
        for _ in range(3):
            self.llm.create_completion(prompt=dummy_prompt, max_tokens=10)
        time.sleep(5) # Пауза для стабилизации температур

    def get_system_metrics(self):
        """Собирает метрики GPU и CPU. 
        Примечание: Для максимальной точности этот метод должен вызываться 
        параллельно с генерацией или использовать встроенные логи движка."""
        try:
            gpu_util = pynvml.nvmlDeviceGetUtilizationRates(self.handle).gpu
            gpu_mem_used = pynvml.nvmlDeviceGetMemoryInfo(self.handle).used / (1024**2) # MB
            cpu_util = psutil.cpu_percent()
            ram_used = psutil.virtual_memory().used / (1024**3) # GB

            return {
                "gpu_util_percent": gpu_util,
                "gpu_mem_used_mb": gpu_mem_used,
                "cpu_util_percent": cpu_util,
                "ram_used_gb": ram_used
            }
        except Exception as e:
            return {"error": str(e)}

    def run_single_test(self, prompt_tokens, output_tokens):
        """Выполняет один замер с разделением TTFT и Decode Speed."""
        # 1. Формирование детерминированного промпта
        prompt = self.generate_deterministic_prompt(prompt_tokens)

        # 2. Замер времени
        start_time = time.perf_counter()
        first_token_time = None

        # Используем stream для захвата момента появления первого токена
        stream = self.llm.create_completion(
            prompt=prompt,
            max_tokens=output_tokens,
            stream=True
        )

        token_count = 0
        for chunk in stream:
            if first_token_time is None:
                first_token_time = time.perf_counter()
            token_count += 1

        end_time = time.perf_counter()

        # 3. Расчет метрик
        ttft_ms = (first_token_time - start_time) * 1000 if first_token_time else 0
        total_duration = end_time - start_time

        # Decode Speed: скорость генерации после первого токена
        # Вычитаем 1, так как первый токен уже учтен в TTFT
        decode_duration = end_time - first_token_time
        decode_tps = (token_count - 1) / decode_duration if decode_duration > 0 else 0

        # 4. Сбор метрик системы (приближенно, так как генерация уже завершилась)
        # В идеале использовать фоновый поток мониторинга
        metrics = self.get_system_metrics()

        return {
            "context_len": prompt_tokens,
            "output_len": token_count,
            "ttft_ms": round(ttft_ms, 2),
            "decode_tps": round(decode_tps, 2),
            "total_duration_sec": round(total_duration, 2),
            "system_metrics": metrics
        }

    def generate_deterministic_prompt(self, target_tokens):
        """Генерирует промпт с фиксированным количеством токенов."""
        # Реализация зависит от токенизатора. 
        # Пример: повторение структурированного блока до достижения нужной длины.
        base_block = "Error: Connection timeout. Retrying... "
        # Упрощенная логика: грубая оценка 1 токен ~ 4 символа
        target_chars = target_tokens * 4
        prompt = base_block * (target_chars // len(base_block))
        return prompt

    def run_matrix(self):
        contexts = [1024, 4096, 16384, 32768, 65536, 131072]
        outputs = [128, 512, 1024]

        self.load_model() # Загрузка и прогрев

        for ctx in contexts:
            # Проверка: если модель инициализирована с меньшим контекстом, чем требуется,
            # тест будет некорректным. Убедитесь, что max_context_length >= ctx.
            if ctx > self.max_context_length:
                print(f"Пропуск контекста {ctx}: превышает лимит модели {self.max_context_length}")
                continue

            for out in outputs:
                for i in range(self.n_repeats):
                    try:
                        res = self.run_single_test(ctx, out)
                        self.results.append(res)
                        print(f"Ctx: {ctx}, Out: {out}, TTFT: {res['ttft_ms']}ms, Decode: {res['decode_tps']} tps")
                    except Exception as e:
                        print(f"Ошибка при тесте Ctx:{ctx}, Out:{out}: {e}")
                        # Сохраняем частичные результаты при ошибке
                        self.save_results()

                    time.sleep(2) # Пауза для остывания

        self.save_results()

    def save_results(self):
        with open("benchmark_results.json", "w") as f:
            json.dump(self.results, f, indent=2)

Детерминированные промпты

Использование случайного текста (lorem ipsum) не позволяет точно контролировать нагрузку на attention-механизмы и может приводить к вариативности из-за разной длины токенов в байтах. Лучше использовать структурированный текст, который гарантированно заполнит KV-cache предсказуемым образом.

Пример детерминированного промпта:

[SYSTEM] Ты — инженерный ассистент.
[USER] Проанализируй следующий лог сервера и выдели ошибки.
[LOG_DATA]
{repeat_block_of_structured_json}
...
[END_LOG]
Выведи только список ошибок в формате JSON.

Блок {repeat_block_of_structured_json} генерируется программно и имеет фиксированную длину в токенах. Это позволяет точно контролировать размер контекста.

3. Матрица тестирования: 1K–128K

Мы тестируем не просто «длинный контекст», а поведение системы на разных этапах заполнения памяти.

Контекст (Input) Output Цель теста Ожидаемое поведение
1K 128 Базовая скорость (TTFT) Максимальный Decode TPS. TTFT минимален.
4K 512 Стандартный рабочий режим TPS начинает снижаться из-за роста KV-cache.
16K 1024 Средний контекст Заметное влияние на время первого токена (TTFT).
32K 1024 Высокий контекст Проверка на OOM (Out of Memory) при батчинге.
64K 512 Экстремальный контекст Сильное падение TPS. Проверка аллокатора памяти.
128K 128 Предел модели TTFT может достигать десятков секунд. Decode TPS минимален.

Важное замечание: При тестировании 128K контекста убедитесь, что ваша модель действительно поддерживает такую длину. Для 128K часто требуется специфическая конфигурация flash-attention или paged-attention, а также значительный объем VRAM.

4. Анализ данных: где падает скорость?

После сбора данных в CSV/JSON мы должны построить графики зависимости Decode TPS и TTFT от Context Length.

Критические точки падения

  1. Порог VRAM (Swap to RAM): Если при переходе с 32K на 64K Decode TPS падает не плавно, а резко (в 2-3 раза), это признак того, что KV-cache превысил доступную VRAM и начал свопиться в системную память (RAM) или аллокатор столкнулся с фрагментацией.
    • Диагностика: Смотрите на gpu_mem_used. Если он близок к 100%, а cpu_util резко вырос — идет активный свопинг данных между GPU и CPU.
  2. Порог Compute: Если TPS падает линейно или квадратично с ростом контекста, но память свободна, это нормальное поведение для attention-механизмов (квадратичная сложность $O(N^2)$). Однако, если падение круче, чем $O(N^2)$, возможно, проблема в реализации attention (отсутствие оптимизаций вроде Flash Attention).
  3. I/O Bottleneck: Если при малом контексте (1K) TTFT выше ожидаемого, проверьте скорость загрузки модели и диска. Но чаще это проблема CPU-препроцессинга токенов или медленного PCIe-соединения.

Пример анализа CSV

context_len,output_len,ttft_ms,decode_tps,gpu_util,ram_used_gb
1024,128,150,45.2,85%,4.0
4096,512,450,38.1,88%,6.0
16384,1024,1200,22.5,92%,12.0
32768,1024,3500,12.1,95%,20.0
65536,512,12000,4.5,98%,38.0
131072,128,45000,1.2,99%,72.0

В этом примере видно, что при 64K контекста TTFT возрастает до 12 секунд, а Decode TPS падает до 4.5, что может быть неприемлемо для интерактивных приложений. При 128K система работает на грани OOM, и TTFT становится критическим.

5. Чек-лист перед запуском

  1. [ ] Контроль n_ctx: Убедитесь, что модель инициализирована с n_ctx, достаточным для максимального теста, или реализована перезагрузка модели для каждого размера контекста.
  2. [ ] Очистка кэша: Убедитесь, что между тестами разных длин контекста модель перезагружается или кэш принудительно очищается, чтобы избежать влияния предыдущих состояний.
  3. [ ] Температурный контроль: Если GPU греется выше 85°C, результаты будут занижены из-за троттлинга. Используйте паузы или активное охлаждение.
  4. [ ] Фоновые процессы: Закройте браузеры, IDE и другие приложения, использующие GPU.
  5. [ ] Версионирование: Записывайте версию библиотеки (llama.cpp, transformers), версию драйвера GPU и версию модели в каждый JSON-запись.
  6. [ ] Детерминизм: Установите seed для генератора промптов. Для скорости это не критично, но для воспроизводимости качества вывода — обязательно.
  7. [ ] Обработка ошибок: Добавьте try-except для перехвата MemoryError или CUDA OOM, чтобы скрипт не падал при исчерпании памяти, а фиксировал это как результат теста.

Заключение

Честный бенчмарк — это не цифра в твите, а таблица с условиями воспроизведения. Если вы не можете повторить свой результат через неделю на той же машине, ваш тест бесполезен. Используйте описанный протокол, чтобы находить узкие места: не «модель медленная», а «при контексте >32K аллокатор памяти работает неэффективно» или «при 128K происходит свопинг в RAM».

Эти данные позволяют принимать инженерные решения: менять квантование, переходить на vLLM с PagedAttention, ограничивать максимальный контекст в продакшене или закупать больше VRAM. Без матрицы вы гадаете. С матрицей вы управляете производительностью.

Глава 10. Качество на реальных задачах

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

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

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

1. Coding: Синтаксис против Семантики

Генерация кода — самая популярная задача, но и самая коварная. Локальные модели (особенно размером 7–13 миллиардов параметров) отлично справляются с шаблонным кодом, но часто ошибаются в логике бизнес-процессов или использовании специфичных API.

Критерии качества

Стратегия валидации

Не полагайтесь на то, что модель «понимает» код. Внедряйте пайплайн верификации:

  1. Статический анализ: Сразу после генерации запускайте линтер (например, ESLint для JavaScript, Pylint для Python, Clippy для Rust). Если линтер выдает ошибки — это сигнал к ретраю (повторной попытке) с уточняющим промптом.
  2. Изолированное исполнение: Выполняйте сгенерированный код в песочнице.
    • Важное предупреждение: Для локальных разработчиков запуск Docker с правами root или даже обычными правами может быть опасен, если не настроена изоляция сети и ресурсов. Firecracker требует поддержки KVM и сложной настройки. Безопаснее использовать специализированные инструменты изоляции (например, nsjail) или готовые облачные сервисы исполнения кода (например, E2B), если это допустимо политикой безопасности.
  3. Unit-тесты: Если задача позволяет, генерируйте не только код, но и тесты к нему. Совпадение результатов тестов — наиболее надежный автоматический индикатор семантики.

Пример псевдокода пайплайна

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

import ast
import subprocess

def syntax_check(code: str, language: str) -> bool:
    """Проверяет синтаксис кода. Для Python используем AST, для других — линтер."""
    if language == 'python':
        try:
            ast.parse(code)
            return True
        except SyntaxError:
            return False
    elif language == 'javascript':
        # Пример вызова линтера через subprocess
        # В реальном проекте лучше использовать библиотеку-обертку
        try:
            subprocess.run(['eslint', '--stdin'], input=code.encode(), 
                           check=True, capture_output=True)
            return True
        except subprocess.CalledProcessError:
            return False
    return True # По умолчанию считаем валидным, если проверка не настроена

def contains_dangerous_patterns(code: str) -> bool:
    """Базовая проверка на опасные паттерны (пример)."""
    dangerous_keywords = ['eval(', 'exec(', 'os.system(', 'subprocess.call(']
    return any(keyword in code for keyword in dangerous_keywords)

def sandbox_execute(code: str) -> dict:
    """
    Запуск кода в изолированной среде.
    ВНИМАНИЕ: Реализация зависит от инфраструктуры (Docker, nsjail, E2B).
    Возвращает словарь со статусом и выводом.
    """
    # Заглушка для примера
    return {"exit_code": 0, "stderr": "", "stdout": "Success"}

def generate_and_verify(prompt: str, language: str):
    max_retries = 3
    current_prompt = prompt

    for attempt in range(max_retries):
        code = llm.generate(current_prompt)

        # 1. Синтаксис
        if not syntax_check(code, language):
            current_prompt += "\nОшибка синтаксиса. Исправь код."
            continue

        # 2. Безопасность (базовые проверки)
        if contains_dangerous_patterns(code):
            return {"status": "rejected", "reason": "security_risk"}

        # 3. Исполнение (если применимо)
        try:
            result = sandbox_execute(code)
            if result["exit_code"] == 0:
                return {"status": "success", "code": code}
            else:
                current_prompt += f"\nКод упал с ошибкой: {result['stderr']}. Исправь."
        except TimeoutError:
            return {"status": "timeout"}

    return {"status": "failed", "reason": "max_retries_exceeded"}

Human Intervention

Человек необходим, когда задача требует архитектурных решений или работы с legacy-кодом, где контекст слишком велик для локальной модели. Локальная LLM хороша для написания утилит, парсеров и шаблонных CRUD-операций (Create, Read, Update, Delete), но не для проектирования систем.

2. Structured JSON: Проблема «Лишнего текста»

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

Критерии качества

Стратегия корректности

  1. Function Calling / Tool Use: Если модель поддерживает нативный вызов инструментов, используйте его. Это надежнее, чем обычный промптинг.
  2. Constrained Decoding (Ограниченное декодирование): Используйте библиотеки вроде outlines или guidance. Они на уровне генерации токенов запрещают недопустимые символы, обеспечивая синтаксическую валидность JSON относительно схемы.
    • Важно: Это не гарантирует семантическую корректность. Модель может сгенерировать {"age": -5}, если схема допускает тип int, или выдумать имя, которого нет в исходном тексте.
  3. Retry с обратной связью: Если валидация прошла, но данные выглядят подозрительно, отправьте модели сообщение об ошибке валидатора или попросите перепроверить источники.

Пример использования Outlines

Примечание: API библиотеки outlines быстро меняется. Ниже приведен пример для стабильных версий. Всегда сверяйтесь с документацией вашей версии.

from pydantic import BaseModel
import outlines

class UserProfile(BaseModel):
    name: str
    age: int
    is_active: bool

# Инициализация модели (синтаксис может варьироваться в зависимости от версии)
# Для новых версий может потребоваться явная загрузка модели и токенизатора
model = outlines.models.transformers("mistralai/Mistral-7B-Instruct-v0.2")

# Создание генератора, привязанного к схеме Pydantic
generator = outlines.generate.json(model, UserProfile)

# Генерация гарантированно валидного JSON (синтаксически)
user = generator("Extract user data from: John is 30 and active.")
print(user.name) # John

Human Intervention

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

3. MCP Recovery: Обработка сбоев инструментов

Model Context Protocol (MCP) позволяет LLM взаимодействовать с внешними системами. Главная проблема — не то, что модель вызовет инструмент, а то, что она неправильно интерпретирует ошибку от инструмента или зациклится.

Критерии качества

Стратегия корректности

  1. Четкие контракты ошибок: Инструменты должны возвращать структурированные ошибки, понятные модели (например, {"error": "invalid_date_format", "hint": "Use YYYY-MM-DD"}).
  2. Ограничение итераций: Жесткий лимит на количество вызовов инструментов за один диалог.
  3. Fallback-стратегии: Если MCP-сервер недоступен, модель должна сообщить об ошибке и попросить пользователя ввести данные вручную или отложить задачу.
    • Критическое предупреждение: Использование внутренних знаний модели для замены внешних источников данных (например, баланса счета или наличия товара) недопустимо, так как эти знания устарели и могут привести к галлюцинациям.

Чек-лист для MCP-инженера

Human Intervention

Если модель дважды подряд получает ошибку от одного и того же инструмента, она должна остановиться и передать управление человеку. Автоматическое «угадывание» параметров при сбое интеграции недопустимо.

4. 1C Reasoning: Специфика предметной области

Задачи, связанные с 1С:Предприятие (или другими специфичными ERP/CRM), требуют глубокого понимания доменной логики. Локальные модели, обученные на общих данных, часто путают регистры накопления, справочники и документы. Причина не только в «общих данных», но и в том, что метаданные 1С имеют сложную иерархию, которую сложно передать в контекст без качественной системы поиска по смыслу (RAG).

Критерии качества

Стратегия корректности

  1. RAG с метаданными: Индексируйте не только код, но и справочники метаданных 1С. Контекст должен включать структуру регистров и типов данных.
  2. Few-Shot Prompting: В промпте обязательно приводите 2–3 примера корректных запросов к базе данных или модулей.
  3. Верификация через компилятор: Если задача — написать модуль, его нужно попытаться скомпилировать в среде 1С (через CI/CD пайплайн).

Пример промпта с контекстом

Контекст:
Регистр накопления: "ОстаткиТоваров"
Измерения: Склад, Номенклатура
Ресурсы: Количество, Сумма
Периодичность: По записям

Задача: Напиши запрос, который вернет остатки на складе "Центральный" для номенклатуры "Товар А".

Пример правильного ответа:
ВЫБРАТЬ
    ОстаткиТоваров.Количество КАК Количество
ИЗ
    РегистрНакопления.ОстаткиТоваров.Остатки(
        ,
        Склад = &Склад И Номенклатура = &Номенклатура
    ) КАК ОстаткиТоваров

Примечание: В реальном запросе параметры &Склад и &Номенклатура должны быть объявлены в блоке Параметры или переданы программно. Также важно учитывать период действия данных, если регистр периодический.

Human Intervention

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

5. Long-form Writing: Согласованность и Фактология

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

Критерии качества

Стратегия корректности

  1. Chain-of-Thought (CoT): Требуйте от модели сначала составить план, затем написать разделы по плану.
  2. Суммаризация контекста: Для длинных документов используйте скользящее окно или рекурсивное суммаризирование предыдущих частей, чтобы держать модель в курсе сюжета.
  3. Цитирование: Требуйте от модели указывать источник информации для каждого факта. Если источника нет — помечать как «требует проверки».

Чек-лист для редактора

Human Intervention

Локальная LLM — это черновик. Человек выступает редактором и фактчекером. Автоматическая публикация длинных текстов без человеческой проверки несет высокие риски репутационных потерь.

Заключение: Матрица доверия

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

Задача Валидность Корректность Ретраи Human Intervention
Coding Линтер, Тесты Высокая (для шаблонов) Низкая (синтаксис) Среднее (архитектура)
JSON Схема Высокая (с constrained decoding) Высокая (формат) Низкое
MCP Логика вызова Средняя Высокая (ошибки API) Высокое (при сбоях)
1C Компилятор Низкая (без RAG) Низкая Высокое (обязательно)
Writing Грамматика Низкая (факты) Низкая Высокое (редактура)

Главный вывод: Не пытайтесь сделать локальную LLM «умнее». Сделайте систему вокруг нее «строже». Используйте детерминированные инструменты для валидации, четкие контракты для интеграций и оставляйте человеку финальное слово там, где цена ошибки высока. Локальная модель — это мощный ассистент, но не автономный агент, если вы не построили вокруг нее надежный каркас проверок.

Практический чек-лист внедрения

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

  1. Инфраструктура верификации:

    • [ ] Настроен пайплайн автоматической проверки синтаксиса (линтеры, компиляторы).
    • [ ] Реализована изолированная среда для исполнения кода (или отключено исполнение).
    • [ ] Внедрена валидация структурированного вывода (JSON Schema/Pydantic).

  2. Обработка ошибок:

    • [ ] Определены лимиты на количество повторных попыток (retries).
    • [ ] Настроено логирование всех сбоев инструментов и генераций.
    • [ ] Реализованы fallback-стратегии при недоступности внешних сервисов.

  3. Человеческий контроль:

    • [ ] Определены точки обязательного ручного ревью (архитектура, финансовые данные, публикация).
    • [ ] Подготовлены инструкции для операторов по интерпретации ошибок модели.
    • [ ] Внедрен процесс фактчекинга для генеративного контента.

  4. Безопасность:

    • [ ] Проведен аудит на наличие опасных паттернов в генерируемом коде.
    • [ ] Настроена изоляция сети для песочниц исполнения.
    • [ ] Проверено отсутствие утечек секретов в логах и промптах.

Глава 11. Стабильность и отказоустойчивость

В production-среде локальные LLM редко падают с громким исключением. Чаще они деградируют тихо: латентность растет, качество ответов падает, память утекает, пока процесс не будет убит ядром. Эта глава посвящена диагностике конкретных сценариев отказа и построению архитектуры, которая переживает их без ручного вмешательства.

1. Диагностика деградации памяти

Утечка памяти в LLM-инференсе — это не всегда классическая ошибка C++. Часто это накопление контекста, особенности работы аллокатора CUDA или отсутствие сброса состояния между запросами.

Сценарий: Медленный рост RSS

Если потребление RAM растет линейно с количеством обработанных токенов, но не возвращается к базовому уровню после завершения запроса, вы имеете дело с утечкой.

Диагностика: 1. Мониторинг аллокатора: Используйте py-spy или memray для Python-обвязки. Для C++ бэкендов (llama.cpp, vLLM) используйте инструменты профилирования памяти CUDA: nsys (Nsight Systems) или ncu (Nsight Compute). Для поиска ошибок доступа к памяти (а не утечек) подходит compute-sanitizer. * Примечание: Переменная окружения CUDA_LAUNCH_BLOCKING=1 синхронизирует все вызовы CUDA с CPU, что критически снижает производительность. Используйте её только для отладки порядка выполнения ядер при поиске race conditions, но никогда для профилирования памяти в проде. 2. Анализ KV-кэша: Убедитесь, что кэш очищается. Важно понимать механику аллокатора CUDA (например, в PyTorch): он намеренно удерживает освобожденные блоки в пуле для быстрого повторного использования. Память не возвращается ОС сразу, но доступна для новых тензоров. Проблемой становится ситуация, когда фрагментация пула мешает выделить большой непрерывный блок, или когда утечка происходит на уровне Python-объектов, удерживающих ссылки на тензоры.

Решение: * Принудительный сброс состояния сессии. * Ограничение размера контекста на уровне API-шлюза. * Регулярный перезапуск воркеров (rolling restart) как страховка, а не как основное решение.

Сценарий: Swap Storm

Когда физическая память исчерпана, ОС начинает выгружать страницы в swap. Для LLM это катастрофа: инференс замедляется в десятки раз.

Признаки: * Высокий si/so (swap in/out) в vmstat. * Резкий скачок P99 латентности. * Процесс не убит OOM-killer, но фактически недоступен.

Митигация: 1. Запрет swap для процесса: Используйте cgroups v2 с параметром memory.swap.max=0 или systemd-параметр MemorySwapMax=0. Лучше упасть с OOM (Out Of Memory), чем деградировать до непригодности. * Важно: Не используйте ulimit -v для ограничения виртуальной памяти в GPU-процессах. Виртуальная адресация CUDA может быть огромной и не коррелировать напрямую с физическим использованием RAM, что приведет к ложным падениям. 2. Pre-allocation (Предварительное выделение): Настройте движок так, чтобы он аллоцировал максимальный ожидаемый размер KV-кэша при старте, если это поддерживается. Например, в vLLM это регулируется параметром gpu_memory_utilization. В llama.cpp память выделяется динамически, поэтому критически важно ограничивать размер контекста (-ctx-size) и количество параллельных последовательностей, чтобы избежать фрагментации и выхода в swap во время работы.

2. Аппаратные и драйверные сбои: DeviceLost и NaN

DeviceLost

Ошибка CUDA error: device lost или аналогичные в ROCm/Vulkan обычно означают, что GPU был сброшен ядром (TDR — Timeout Detection and Recovery) или вышел из строя.

Причины: * Перегрев. * Дефект VRAM. * Длительные ядра, превышающие лимит TDR (актуально для Windows, реже для Linux).

Стратегия восстановления: 1. Изоляция узла: При получении DeviceLost немедленно выведите узел из балансировщика. 2. Проверка оборудования: Запустите nvidia-smi -q -d ECC (для NVIDIA) или rocm-smi --showecc (для AMD). Если есть исправимые ошибки ECC — это предупреждение. Если есть неисправимые — замена карты. 3. Автовосстановление: Если ошибки редки, настройте systemd-юнит с Restart=on-failure и RestartSec=10. Обязательно добавьте health-check, который не вернет узел в пул, пока он не выполнит тестовый инференс.

NaN (Not a Number)

Появление NaN в логах или в ответах модели — признак численной нестабильности.

Причины: * Ошибки в квантовании (особенно при смешанной точности FP16/INT4 или INT8). * Дефектные веса модели или плохая калибровка. * Входные данные с экстремальными значениями, вызывающие переполнение в экспоненте softmax. * Уточнение: Высокая температура (temperature > 1.5) сама по себе редко вызывает NaN в стабильных архитектурах. Она лишь усиливает дисперсию, но прямой причиной численного переполнения обычно являются ошибки реализации или квантования.

Диагностика и защита: 1. Валидация на входе: Проверяйте эмбеддинги на NaN перед подачей в модель. 2. Валидация на выходе: Если логиты содержат NaN, прерывайте генерацию и возвращайте ошибку 500, а не мусор. 3. Снижение точности: Попробуйте переключиться с FP16 на BF16 (если поддерживается) или FP32 для критических слоев. BF16 имеет больший динамический диапазон и менее склонен к переполнению.

3. Поведенческие аномалии: Repetition и Corruption

Repetition Loop

Модель зацикливается на фразе или токене. Это не баг кода, а проблема сэмплинга и состояния контекста.

Решения: * Penalty: Используйте repetition_penalty (1.1–1.2) и frequency_penalty. * Top-P/Top-K: Ограничьте выборку. top_p=0.9 часто эффективнее, чем top_k=40. * Детерминированность: Для production-задач рассмотрите temperature=0 (greedy search), если качество позволяет.

Output Corruption

Гарнбл, обрезанные токены, странные символы. Часто связано с race condition в многопоточной обработке или ошибками в токенизаторе.

Чек-лист: 1. Потокобезопасность: Убедитесь, что экземпляр модели не используется одновременно из нескольких потоков без блокировок или пула инстансов. 2. Версия токенизатора: Проверьте соответствие версии токенизатора и модели. 3. Логирование сырых байт: Логируйте только хэши сырых байтов или их длину для диагностики. Полное логирование сырых данных допустимо только в режиме отладки на изолированных стендах с соответствующими политиками безопасности, так как это создает риск утечки PII (персональных данных) или коммерческой тайны.

4. Архитектура отказоустойчивого сервиса

Единый процесс инференса — точка отказа. Используйте паттерны распределенных систем.

4.1. Health Checks и Readiness Probes

Не используйте простой GET /health, который всегда возвращает 200. Реализуйте глубокие проверки, но защищайте их от DoS-атак.

Риск: Выполнение инференса внутри синхронного endpoint /health/ready создает вектор для DoS-атаки. Злоумышленник может спамить запросами, заставляя GPU выполнять работу, что исчерпает ресурсы быстрее, чем реальный трафик.

Безопасная реализация: 1. Ограничьте доступ к endpoint только из внутренней сети (VPC/Service Mesh). 2. Добавьте rate-limiting для health-checks. 3. Лучше: выполняйте тестовый инференс в фоновом потоке, а health-check просто читает актуальный флаг состояния.

import threading
import time
import torch
import logging

log = logging.getLogger(__name__)

# Глобальный флаг состояния, обновляемый фоновым потоком
_health_status = {"ready": False, "last_check": 0}
MIN_REQUIRED_MEM = 1024 * 1024 * 1024  # 1 GB

def run_test_inference_with_timeout(timeout=5.0):
    """
    Выполняет тестовый инференс с таймаутом.
    Возвращает True, если успешно, иначе False.
    """
    try:
        # Имитация проверки: в реальном коде здесь вызов model.generate
        # Важно: этот код должен быть неблокирующим или выполняться в отдельном потоке
        # с жестким таймаутом, чтобы зависший инференс не убил health-check.
        time.sleep(0.1) 
        return True
    except Exception as e:
        log.error(f"Test inference failed: {e}")
        return False

def background_health_check():
    """Фоновый поток, периодически проверяющий состояние системы."""
    while True:
        try:
            # 1. Проверка наличия GPU
            if not torch.cuda.is_available():
                _health_status["ready"] = False
            else:
                # 2. Проверка свободной памяти (быстрая операция)
                free_mem, total_mem = torch.cuda.mem_get_info()
                if free_mem < MIN_REQUIRED_MEM:
                    _health_status["ready"] = False
                else:
                    # 3. Тестовый инференс с таймаутом
                    success = run_test_inference_with_timeout(timeout=5.0)
                    _health_status["ready"] = success

            _health_status["last_check"] = time.time()
        except Exception as e:
            _health_status["ready"] = False
            log.error(f"Health check failed: {e}")

        time.sleep(5)  # Интервал проверки

def readiness_check():
    """
    Endpoint для Kubernetes Readiness Probe.
    Быстро возвращает статус, не выполняя тяжелые операции.
    """
    # Проверяем свежесть статуса
    if time.time() - _health_status["last_check"] > 10:
        return 503, "Health check stale"

    if _health_status["ready"]:
        return 200, "OK"
    else:
        return 503, "Service not ready"

Важно: Readiness probe должен быть быстрым (< 100 мс). Глубокий тест инференса выполняется асинхронно в фоне.

4.2. Circuit Breaker и Fallback

Если модель начинает возвращать ошибки или NaN, не отправляйте туда весь трафик. Circuit Breaker должен реагировать не только на HTTP 500, но и на превышение P99 латентности (симптом Swap Storm) или на появление NaN в ответах (симптом численной нестабильности).

Схема: 1. Primary: Основная модель (например, Llama-3-70B). 2. Secondary: Более легкая модель (Llama-3-8B) или кэш частых запросов. 3. Circuit Breaker: Если 50% запросов к Primary падают или превышают лимит латентности за 10 секунд, открываем цепь. Трафик идет на Secondary. 4. Half-Open: Через 30 секунд пропускаем 10% трафика на Primary. Если успешно — закрываем цепь.

4.3. Graceful Shutdown

При обновлении или остановке сервиса нельзя просто убивать процесс. Активные запросы должны завершиться.

Алгоритм: 1. Сигнал SIGTERM получен. 2. Сервис перестает принимать новые соединения (или возвращает 503). 3. Ждем завершения активных запросов (timeout, например, 30 секунд). 4. Если timeout истек, принудительно завершаем оставшиеся запросы. 5. Освобождаем ресурсы GPU. 6. Завершение процесса.

5. Чек-лист production-готовности

Перед выводом локальной LLM в production убедитесь в следующем:

Заключение

Стабильность локальной LLM — это не свойство модели, а свойство системы вокруг неё. Вы не можете контролировать численную нестабильность весов или дефекты VRAM, но можете контролировать то, как ваша система реагирует на эти события. Ключевые принципы: быстрая детекция, изоляция отказа, предсказуемое поведение при деградации и автоматическое восстановление.

Не стремитесь к 100% аптайму любой ценой. Стремитесь к предсказуемому поведению при сбоях. Лучше вернуть 503 и перенаправить трафик на резервную модель, чем часами обслуживать запросы с латентностью в 30 секунд и мусорным выводом.

Глава 12. Выбор конфигурации и Runbook

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

В этой главе мы соберём финальный артефакт — Decision Matrix (матрицу решений), которая связывает технические параметры с бизнес-рисками, и определим Runbook (инструкцию по эксплуатации), позволяющий команде безопасно обновлять конфигурации без простоев.

1. Decision Matrix: от параметров к бизнес-логике

Частая ошибка команд — выбирать модель, опираясь исключительно на бенчмарки вроде MMLU или пиковую скорость генерации токенов. Такой подход ведёт к «галлюцинациям в проде» и неожиданным сбоям под нагрузкой. Правильная матрица решений должна включать три слоя: Технический, Экономический и Рисковый.

Структура матрицы

Каждая строка матрицы представляет собой кандидатную конфигурацию (например, Llama-3-8B-Instruct-Q4_K_M на llama.cpp с контекстом 8k). Каждый столбец — критерий оценки с чётко определёнными условиями измерения.

Критерий Тип метрики Как измерять Порог приемлемости (пример)*
TTFT (Time to First Token) Latency P95 задержки при нагрузке 10 RPS < 500 мс (для GPU уровня A100/4090, низкий батч)
Throughput Производительность Токенов/сек на GPU при батче 4 > 150 ток/сек (при средней длине промпта 512 токенов)
VRAM Usage Ресурсы Пиковое потребление памяти (GB) < 90% от доступного VRAM
Task Quality Score Качество Оценка по шкале 1–5 (LLM-as-a-Judge или Human Eval) Средний балл > 4.0
Cost of Error Бизнес-риск Финансовый/репутационный ущерб при неверном ответе Низкий / Средний / Высокий
Rollback Time Операционный риск Время переключения трафика на стабильную версию < 5 минут

*Примечание: Значения порогов сильно зависят от аппаратного обеспечения. Для CPU или Edge-устройств допустимая задержка TTFT может составлять 2–5 секунд, а требования к точности — корректироваться в зависимости от критичности задачи.

Пример заполнения

Рассмотрим два кандидата для сервиса поддержки клиентов. Важно помнить о совместимости форматов: vLLM работает с весами в формате HuggingFace (FP16/BF16) или специализированных квантах (AWQ, GPTQ), тогда как формат GGUF (включая Q4_K_M) является стандартом для llama.cpp и Ollama.

  1. Конфигурация A: Mistral-7B-Instruct-v0.2, квант Q5_K_M (GGUF), runtime llama.cpp, контекст 4k.

    • Плюсы: Низкое потребление памяти, стабильная работа на смешанных стеках CPU/GPU, простота деплоя.
    • Минусы: Более высокий TTFT при длинных промптах, риск потери контекста диалога из-за малого окна.
    • Cost of Error: Средний (клиент может получить неполный ответ, но не опасный совет).

  2. Конфигурация B: Llama-3-8B-Instruct, квант AWQ (или GPTQ), runtime vLLM, контекст 8k.

    • Плюсы: Высокая пропускная способность (throughput), лучшее понимание инструкций, длинный контекст.
    • Минусы: Требует мощного GPU с достаточным VRAM, выше стоимость инфраструктуры, сложнее настройка квантования.
    • Cost of Error: Низкий (высокая точность и скорость снижают риск эскалации тикетов).

Вывод: Если ваш SLA требует ответа менее чем за 1 секунду и у вас есть бюджет на GPU уровня A100/4090, выбирайте Конфигурацию B. Если бюджет ограничен, а латентность до 3 секунд допустима — Конфигурация A.

Эвристика: Никогда не выбирайте модель с максимальным контекстом «про запас». Контекст стоит памяти и времени обработки. Начинайте с минимально необходимого размера (например, 4k) и расширяйте его только если внутренние тесты показывают деградацию качества на коротких окнах.

2. Production Gate: автоматизация проверки качества

Перед тем как новая конфигурация попадёт в продакшен, она должна пройти через автоматизированный гейт. Ручная проверка «на глаз» не масштабируется и субъективна.

Что включать в гейт?

  1. Smoke Test: Проверка базовой работоспособности. Модель загружается, отвечает на простой промпт (Hello), не падает и корректно завершает генерацию.
  2. Regression Eval: Запуск фиксированного набора из 50–100 задач, специфичных для вашего домена.
    • Пример: Для чат-бота юристов тесты должны включать извлечение статей из документов.
    • Метрика: Используйте не бинарную оценку «правильно/неправильно», а скоринг по критериям (полнота, точность ссылок, отсутствие галлюцинаций). Часто применяется метод LLM-as-a-Judge, где более сильная модель оценивает ответы тестируемой модели по шкале.
  3. Stress Test: Проверка поведения при исчерпании контекста и высокой конкурентности. Убедитесь, что при переполнении окна модель корректно обрезает историю или возвращает ошибку, а не «зависает».

Псевдокод CI/CD пайплайна

Критически важно, чтобы пайплайн не просто запускал скрипты, но и интерпретировал результаты. Если скрипт завершается успешно (exit code 0), но качество ниже порога, деплой должен блокироваться.

# .gitlab-ci.yml или аналог
stages:
  - build
  - test
  - deploy

test_model_quality:
  stage: test
  script:
    # 1. Запуск оценки качества. Скрипт должен вернуть JSON с метриками.
    - python run_eval.py --model_config configs/candidate.yaml --dataset internal_eval_v2.json --output eval_results.json

    # 2. Проверка латентности. Скрипт должен вернуть код ошибки, если TTFT > threshold.
    - python check_latency.py --config configs/candidate.yaml --threshold_ttft 500

    # 3. Валидация результатов оценки.
    # Если score < 4.0, скрипт завершается с кодом 1, блокируя пайплайн.
    - python validate_score.py --input eval_results.json --min_score 4.0
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

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

3. Стратегия Rollback и версионирование

Локальные LLM — это не просто бинарник. Это связка: Модель + Квантование + Runtime + Конфигурация. Изменение любого элемента требует возможности быстрого отката.

Версионирование конфигурации

Используйте декларативные файлы (YAML/JSON) для описания окружения. Не храните пути к моделям или параметры квантования в коде приложения.

# config/production.yaml
version: "1.2.0"
model:
  name: "meta-llama/Llama-3-8B-Instruct"
  quantization: "AWQ"  # Важно: соответствует формату для vLLM
  path: "/models/llama3-8b-awq"
runtime:
  engine: "vllm"
  max_model_len: 8192
  gpu_memory_utilization: 0.9

Механизм отката

  1. Blue/Green Deployment: Держите две инстансы. Новая версия поднимается на «зелёной», проходит гейты, и трафик переключается. Если метрики падают — мгновенный возврат на «синюю».
    • Важно: Время загрузки весов модели в VRAM может занимать 30–60 секунд. Поэтому «время отката» в матрице решений должно учитывать не только переключение трафика, но и время прогрева новой инстансы, если она не была запущена заранее.
  2. Feature Flags: Используйте флаги для изменения параметров сэмплирования (temperature, top_p) или логики постобработки.
    • Осторожно: Смена системного промпта «на лету» может потребовать сброса кэша KV-cache или миграции сессий, так как контекст диалога становится невалидным для новой инструкции. Для таких изменений безопаснее использовать перезапуск сервиса или стратегию «мягкого» перехода для новых сессий.
  3. Мониторинг аномалий: Настройте алерты на:
    • Резкий рост TTFT или снижение Throughput.
    • Увеличение доли пустых ответов или ответов, содержащих маркеры остановки (например, `