Локальные LLM и эмбеддинги: Ollama + Sentence Transformers

Архитектура локального инференса: Ollama как замена облачным провайдерам

Корпоративный сектор оказался в архитектурном парадоксе: компании тратят миллионы на защиту внутреннего периметра, внедряют сложные системы контроля доступа и шифрования, а затем передают самую чувствительную коммерческую информацию — исходный код, финансовые отчеты, персональные данные клиентов — в виде обычного JSON-запроса через внешний REST API стороннему провайдеру нейросетей. Помимо очевидных рисков утечки данных (Data Residency) и зависимости от чужой инфраструктуры (Vendor Lock-in), облачный инференс создает непредсказуемую юнит-экономику. Как мы выяснили при расчете ROI, стоимость каждого запроса растет линейно вместе с объемом обрабатываемых документов. Переход к локальному выполнению больших языковых моделей (LLM) решает обе проблемы: данные никогда не покидают серверную стойку компании, а маржинальная стоимость генерации каждого следующего токена стремится к нулю.

Долгое время локальный запуск LLM считался прерогативой исследовательских лабораторий с кластерами из промышленных GPU. Ситуация радикально изменилась с появлением специализированных движков инференса и платформ-оркестраторов, которые абстрагировали сложность работы с тензорами и драйверами видеокарт.

Движок под капотом: феномен llama.cpp

Чтобы понять, как современные системы запускают тяжелые модели на потребительском или стандартном серверном оборудовании, необходимо спуститься на уровень вычислений. Изначально нейросети обучаются и запускаются с использованием тяжелых фреймворков вроде PyTorch или TensorFlow. Эти фреймворки тянут за собой гигантское дерево зависимостей (Python, CUDA, cuDNN) и проектировались прежде всего для этапа обучения (Training), где требуется вычисление градиентов и обратное распространение ошибки.

Для этапа вывода (Inference) — когда веса модели уже заморожены и нужно лишь предсказывать следующий токен — этот стек избыточен. Ответом на эту избыточность стал проект llama.cpp. Это библиотека, написанная на чистом C/C++, которая реализует математику прямого прохода (forward pass) нейросети без единой зависимости от Python.

Ключевая архитектурная инновация llama.cpp заключается в механизме Layer Offloading (выгрузка слоев). Архитектура современных LLM, таких как Llama 3, состоит из последовательности одинаковых блоков — трансформерных слоев (Transformer Layers). Если модель целиком не помещается в быструю видеопамять (VRAM) графического ускорителя, llama.cpp позволяет разделить ее.

!Балансировка слоев между CPU и GPU

Часть слоев загружается в VRAM графического процессора (GPU), а оставшиеся слои остаются в оперативной памяти (RAM) и обрабатываются центральным процессором (CPU). При генерации токена данные проходят через слои последовательно. Если слой находится в GPU, вычисления происходят мгновенно. Когда очередь доходит до слоя в RAM, данные передаются по шине PCIe в центральный процессор, обрабатываются там, и результат возвращается обратно.

Скорость генерации (TPS) в такой гибридной схеме определяется пропускной способностью шины памяти. VRAM современных видеокарт обеспечивает пропускную способность от 500 до 1000 ГБ/с, в то время как обычная DDR5 RAM выдает около 60-80 ГБ/с. Поэтому каждый слой, который не поместился в GPU и остался на CPU, становится бутылочным горлышком, кратно снижая общую скорость ответа модели.

Архитектура Ollama: Docker для нейросетей

Сам по себе llama.cpp — это низкоуровневый инструмент командной строки. Интегрировать его напрямую в корпоративные микросервисы на FastAPI крайне сложно: нужно самостоятельно управлять процессами, выделять память, писать обертки для HTTP-взаимодействия и реализовывать очереди запросов.

Ollama решает эту проблему, выступая высокоуровневым оркестратором. Если провести аналогию с классической инфраструктурой, то llama.cpp — это ядро операционной системы (Linux Kernel), а Ollama — это Docker-демон, который управляет образами, сетью и жизненным циклом контейнеров.

!Архитектура Ollama

Архитектурно Ollama состоит из трех ключевых компонентов, работающих в связке:

Ollama Daemon (Серверная часть). Фоновый процесс, написанный на языке Go. Он отвечает за управление ресурсами операционной системы, мониторинг доступной VRAM и маршрутизацию запросов. Демон постоянно «слушает» порт (по умолчанию 11434) и принимает HTTP-запросы.

Model Registry (Реестр моделей). Подсистема хранения, реализующая концепцию слоистой файловой системы (по аналогии с Docker-образами). Веса модели, системные промпты и конфигурации хранятся как отдельные неизменяемые слои. Это позволяет создавать десятки специализированных агентов на базе одной тяжелой модели (например, Llama 3 8B), не дублируя гигабайты весов на жестком диске.

Runner (Исполнитель). Когда поступает запрос к конкретной модели, демон динамически порождает дочерний процесс — скомпилированный бинарный файл llama.cpp (или другой поддерживаемый движок), передавая ему нужные веса и выделяя память.

Такое разделение ответственности позволяет Ollama бесшовно обновлять модели, управлять кэшем и обрабатывать параллельные запросы от нескольких микросервисов, не блокируя основной Event Loop.

Динамическое управление памятью и KV-кэш

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

При запуске модели Ollama рассчитывает необходимый объем памяти по следующей логической формуле:

Где:

— общий объем требуемой памяти (VRAM или гибридной VRAM+RAM).

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

— динамический объем памяти, выделяемый под контекст диалога.

KV-cache (Key-Value Cache) — это архитектурная оптимизация трансформеров. Чтобы не пересчитывать математические представления (ключи и значения) для всех предыдущих слов при генерации каждого нового токена, модель сохраняет их в специальный буфер в памяти.

Размер растет линейно в зависимости от размера окна контекста (Context Window). Если мы увеличиваем максимально допустимый контекст с 4096 до 8192 токенов, объем требуемой памяти под KV-кэш удваивается. В корпоративных RAG-системах, где в промпт загружаются целые страницы документации, именно размер KV-кэша часто становится причиной нехватки видеопамяти (Out of Memory), даже если сами веса модели успешно поместились в графический ускоритель.

Для оптимизации ресурсов Ollama реализует механизм Keep-Alive. Когда FastAPI-сервис отправляет запрос к Ollama, демон загружает модель в память, генерирует ответ и не выгружает модель сразу после завершения. По умолчанию модель остается в памяти (keep-alive) в течение 5 минут. Если в этот период поступает новый запрос, происходит «теплый старт» (Warm Start) — генерация начинается мгновенно. Если запросов нет, Ollama освобождает VRAM, уступая место другим моделям или системным процессам. При следующем запросе произойдет «холодный старт» (Cold Start), который потребует времени на перенос гигабайтов весов с SSD-накопителя в память видеокарты.

Декларативная конфигурация: Modelfile

В предыдущих модулях мы использовали системные инструкции (System Prompt) и параметры генерации (Temperature, Top-P), передавая их в каждом JSON-запросе к облачному API. В микросервисной архитектуре с множеством узлов (LangGraph) дублирование этих настроек в коде каждого агента приводит к рассинхронизации и усложняет поддержку.

Ollama предлагает перенести конфигурацию агента на уровень инфраструктуры с помощью Modelfile — декларативного файла, синтаксически похожего на Dockerfile.

Пример Modelfile для агента, транслирующего естественный язык в SQL-запросы:

Создание новой модели происходит одной командой в терминале: ollama create sql-agent -f Modelfile.

С этого момента sql-agent становится самостоятельной сущностью в реестре Ollama. Внутренний механизм дедупликации понимает, что веса llama3:8b уже существуют на диске, и создает лишь легковесный конфигурационный слой размером в несколько килобайт. Теперь микросервис на FastAPI может обращаться к модели sql-agent, передавая только пользовательский вопрос, будучи уверенным, что агент всегда будет использовать температуру 0.1 и строгий системный промпт. Это реализует принцип "Единого источника истины" для ИИ-агентов.

Бесшовная миграция: эмуляция OpenAI API

Главный барьер при переходе от облачных провайдеров к локальным решениям — необходимость переписывать кодовую базу. Большинство существующих библиотек, фреймворков и написанных ранее HTTP-клиентов жестко завязаны на спецификацию API от OpenAI.

Архитекторы Ollama решили эту проблему на сетевом уровне. Демон Ollama не только предоставляет собственный нативный API, но и поднимает эмулятор, который полностью повторяет контракты OpenAI.

Когда наш асинхронный клиент на базе httpx отправляет POST-запрос на эндпоинт /v1/chat/completions, маршрутизатор Ollama перехватывает его. Он парсит стандартный JSON-payload, извлекает массив messages, параметры temperature и max_tokens, а затем транслирует их во внутренний формат llama.cpp.

Сгенерированный ответ упаковывается обратно в структуру с массивом choices и блоком статистики usage. Поддерживается даже потоковая передача (Server-Sent Events) с префиксами data: , что позволяет использовать ранее реализованные механизмы накопления состояния без единой строчки изменений в бизнес-логике.

Вся миграция корпоративного чат-API сводится к изменению двух переменных окружения (Environment variables) в файле .env:

Замена OPENAI_API_KEY на произвольную строку (Ollama не требует авторизации по умолчанию, так как разворачивается в закрытом контуре).

Замена OPENAI_BASE_URL с https://api.openai.com/v1 на http://localhost:11434/v1 (или адрес внутреннего сервера с Ollama).

Это архитектурное решение позволяет использовать паттерн LLM Gateway в полной мере. В процессе разработки и отладки (где важна скорость) инженеры могут использовать локальную модель через Ollama. При выводе MVP в продакшен, если локальных мощностей пока не хватает, система переключается на облачного провайдера простым изменением URL, сохраняя идентичную обработку ошибок, валидацию Pydantic-моделей и логику трассировки.

Управление жизненным циклом запроса в локальной среде

Рассмотрим, что физически происходит в системе, когда пользователь отправляет сообщение в наше чат-API, переключенное на Ollama:

Транспортный слой: FastAPI принимает запрос, извлекает историю из PostgreSQL (эпизодическая память) и формирует массив messages.

Сетевой вызов: httpx.AsyncClient отправляет JSON на http://localhost:11434/v1/chat/completions.

Маршрутизация Ollama: Демон принимает запрос. Проверяет, загружена ли запрошенная модель (например, sql-agent) в VRAM.

Аллокация ресурсов: Если модель не в памяти, Ollama читает Modelfile, находит базовые веса на SSD, рассчитывает с учетом переданного размера контекста и начинает копирование слоев в GPU.

Инференс: Запускается процесс llama.cpp. Он принимает токенизированный контекст, помещает его в KV-кэш и начинает авторегрессионную генерацию.

Потоковая отдача: По мере генерации каждого токена, процесс передает его демону, который упаковывает токен в SSE-формат и отправляет по HTTP обратно в FastAPI.

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

Понимание этой цепочки критически важно для архитектора. В облаке задержка TTFT (Time-to-First-Token) зависит в основном от сетевого пинга и загруженности серверов провайдера. В локальной инфраструктуре с Ollama аномально высокий TTFT (например, 15 секунд вместо 1 секунды) почти всегда означает, что сработал «холодный старт», и система тратит время на перенос десятков гигабайт с диска в VRAM. Для высоконагруженных систем это потребует настройки постоянного удержания жизненно важных моделей в памяти, что мы рассмотрим при проектировании мульти-агентных пайплайнов.

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

Экономика и тестирование: метрики качества, пропускная способность и расчет ROI

Стремление корпораций отказаться от платных облачных API в пользу локальных моделей часто начинается с иллюзии бесплатности. Кажется, что достаточно один раз развернуть Llama 3 через Ollama, и стоимость генерации токенов навсегда упадет до нуля. На практике неопытные архитекторы сталкиваются с парадоксом: сервер с двумя графическими ускорителями, арендованный за 2000 USD в месяц, простаивает 90% времени, обрабатывая редкие запросы, себестоимость которых в итоге превышает тарифы самых дорогих коммерческих моделей. Переход на локальный инференс — это смена экономической парадигмы с операционных расходов (Pay-as-you-go) на капитальные, где главным драйвером окупаемости становится утилизация оборудования.

Капитализация инфраструктуры: расчет совокупной стоимости владения (TCO)

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

Для локального сервера TCO складывается из амортизации оборудования (или фиксированной стоимости аренды выделенного сервера), затрат на электроэнергию, охлаждение и администрирование:

Где:

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

— стоимость аренды сервера (например, инстанса с NVIDIA RTX 4090 или A100) или ежемесячная амортизация при покупке собственного железа.

— затраты на электричество и дата-центр.

— стоимость часов DevOps-инженера на поддержку кластера Kubernetes и обновление весов моделей.

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

Где:

— фактическая стоимость обработки одного запроса.

— максимальная теоретическая пропускная способность сервера (запросов в месяц).

— коэффициент утилизации (от 0.0 до 1.0), отражающий реальную загрузку оборудования.

Если сервер способен обрабатывать 1 миллион запросов в месяц, но реальный трафик пользователей составляет лишь 50 000 запросов, коэффициент . В этом случае вся стоимость простаивающего железа ложится на эти 50 000 запросов, делая их экстремально дорогими. Оптимизация локальной экономики сводится к максимизации коэффициента за счет фоновых задач (например, пакетной векторизации архивных документов через Sentence Transformers в часы ночного спада активности пользователей).

Пропускная способность и оценка Goodput

При нагрузочном тестировании локальных систем классические метрики вроде RPS (Requests Per Second) искажают реальную картину. Если отправить 500 одновременных запросов в Ollama без настроенного AI-шлюза, система попытается загрузить их все в VRAM, исчерпает память (OOM) и вернет 500 ошибок HTTP 503. Метрика RPS покажет высокую пропускную способность, но полезная работа будет равна нулю.

Для оценки локальных LLM и батчей эмбеддингов используется метрика Goodput (Полезная пропускная способность). Она учитывает только те запросы, которые завершились успешно, уложились в заданный таймаут и не содержали логических ошибок (галлюцинаций).

Где:

— количество полезных сгенерированных токенов в секунду на уровне всей системы.

— количество запросов, успешно прошедших через все узлы LangGraph и вернувших валидный результат клиенту.

— средний размер успешного ответа в токенах.

— общая длительность окна нагрузочного тестирования в секундах.

Снижение Goodput при росте входящей нагрузки — верный признак проблемы Padding Waste или неэффективной работы механизма Continuous Batching. Например, если в очереди Celery скапливаются задачи на генерацию эмбеддингов, а воркеры обрабатывают их поштучно вместо группировки в тензоры, GPU будет загружен на 100% (Compute-bound), но полезная пропускная способность системы останется минимальной.

Оценка качества (Evals): Cross-Model Evaluation

Переход с тяжелых коммерческих моделей на локальные квантованные версии (например, Llama 3 8B Q4_K_M) неизбежно влечет за собой снижение абсолютного интеллекта системы. Квантование срезает выбросы активаций, что в первую очередь бьет по способности модели следовать сложным системным инструкциям и точно выбирать инструменты (Tool Calling).

Для контроля деградации применяется паттерн Cross-Model Evaluation (Кросс-модельная оценка). В этом подходе эталонная, математически мощная облачная модель (например, GPT-4) используется исключительно на этапе CI/CD в качестве беспристрастного судьи для оценки ответов локальной модели на заранее подготовленном золотом датасете (Golden Dataset).

Процесс оценки разбивается на три изолированные метрики:

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

Answer Relevance (Релевантность ответа). Измеряет, насколько прямо ответ решает изначальную задачу пользователя. Локальные квантованные модели часто страдают многословием, уходя от прямого ответа.

Tool Selection Accuracy (Точность выбора инструмента). В мульти-агентных сетях LangGraph критически важно, чтобы узел-супервизор вызывал правильный инструмент. Оценивается процент совпадений между выбранным локальной моделью инструментом (и его JSON-аргументами) и эталонным вызовом из датасета.

Итоговый балл качества пайплайна рассчитывается как взвешенная сумма:

Где:

— агрегированный балл качества (от 0 до 1).

, , — оценки Faithfulness, Relevance и Tool Accuracy соответственно (от 0 до 1).

— весовые коэффициенты, зависящие от бизнес-задачи (сумма весов равна 1). Для медицинского бота (фактическая точность) может составлять 0.7, оставляя остальные доли на релевантность и точность инструментов.

Если квантованная Llama 3 набирает по оценке GPT-4, модель допускается к деплою в production-кластер Kubernetes.

Оценка качества RAG: метрика Recall@K для Sentence Transformers

В гибридных архитектурах качество финального ответа LLM напрямую зависит от качества извлеченного контекста. Если легковесная модель all-MiniLM-L6-v2 не найдет нужный абзац в векторной базе, даже самая мощная LLM сгенерирует некорректный ответ.

Для тестирования контура эмбеддингов применяется метрика Recall@K (Полнота на уровне K). Она показывает долю тестовых запросов, для которых релевантный документ оказался в топ-K результатов векторного поиска.

Где:

— общее количество тестовых запросов.

— конкретный тестовый запрос.

— индикаторная функция, возвращающая 1, если истинно релевантный документ попал в выдачу размером , и 0 в противном случае.

— множество из документов, возвращенных векторной базой для запроса .

Например, при тестировании базы знаний корпоративных регламентов мы устанавливаем (ровно столько фрагментов мы передаем в контекстное окно локальной LLM). Если из 100 тестовых вопросов правильный абзац регламента оказался в пятерке лучших результатов 92 раза, наш . Если метрика падает ниже допустимого порога, необходимо менять стратегию разбиения текста (Chunking) или переходить на более тяжелую модель эмбеддингов, например, мультиязычную multilingual-e5-large.

Точка безубыточности (Break-Even Point) и расчет ROI

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

Уравнение точки безубыточности:

Где:

— объем запросов в месяц, при котором затраты равны (Break-Even Volume).

— средняя стоимость одного запроса к коммерческому API (с учетом входящих и исходящих токенов).

— совокупная стоимость владения локальным сервером в месяц.

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

Рассмотрим корпоративного агента технической поддержки. Средний диалог потребляет 2500 входящих токенов (история + RAG-контекст) и генерирует 500 исходящих токенов. Стоимость коммерческого API для такого объема составляет в среднем 0.015 USD за запрос.

Компания рассматривает аренду выделенного GPU-сервера (1x NVIDIA RTX 4090 24GB, 64GB RAM) за 450 USD в месяц. Добавим к этому 350 USD как долю зарплаты инженера на поддержку этого узла. Итого USD.

Вычисляем точку безубыточности:

Если бизнес генерирует 20 000 обращений в месяц, локальная инфраструктура принесет убытки. Дешевле оставаться на облачном API. Если бизнес генерирует 150 000 обращений в месяц, локальная инфраструктура становится высокорентабельной.

Рассчитаем экономию (Return on Investment, ROI) для объема в 150 000 запросов: Затраты на API составили бы: USD в месяц. Затраты на локальный сервер: 800 USD в месяц. Ежемесячная экономия: 1450 USD.

Проблема пиковых нагрузок (Peak Provisioning)

Приведенный выше расчет содержит скрытую архитектурную ловушку. Он предполагает равномерное распределение 150 000 запросов по всем дням и часам месяца. На практике корпоративный трафик подчиняется закону Парето: 80% запросов приходятся на рабочие часы (с 10:00 до 18:00).

Если сервер с одной RTX 4090 способен обрабатывать максимум 3 запроса в секунду (исходя из лимитов VRAM и времени генерации), его максимальная пропускная способность в час составляет 10 800 запросов. Если в пиковый час понедельника придет 15 000 запросов, очередь Celery переполнится, таймауты истекут, и Goodput системы резко упадет.

Чтобы выдержать пиковую нагрузку, архитекторам приходится закладывать избыточность (Peak Provisioning) — арендовать второй сервер RTX 4090, удваивая до 1600 USD. В этом случае точка безубыточности сдвигается до 106 666 запросов, а ночная утилизация оборудования () падает до критических значений.

Именно поэтому интеграция асинхронных очередей (Kafka/RabbitMQ) и паттерна AI Gateway из предыдущих глав становится не просто техническим, но и экономическим требованием. Сглаживание пиков за счет контролируемой задержки ответов (увеличение TTFT в часы пик ради сохранения стабильного Goodput) позволяет бизнесу оставаться в зоне высокой рентабельности без покупки простаивающего железа.

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

Квантование и форматы моделей: оптимизация Llama 3 под доступное железо

Официальные веса модели Llama 3 8B от Meta содержат 8.03 миллиарда параметров. В стандартном для глубокого обучения формате половинной точности (FP16) каждый параметр занимает 2 байта. Простая арифметика показывает, что для загрузки только «голого» мозга нейросети в память требуется около 16 гигабайт VRAM. Если добавить к этому динамически растущий KV-кэш для обработки контекста хотя бы на 4096 токенов, требования легко перешагнут отметку в 18-20 ГБ видеопамяти. Стандартные корпоративные серверы начального уровня или рабочие станции разработчиков чаще всего оснащены графическими ускорителями с 12 ГБ или 16 ГБ VRAM. Запуск оригинальной модели в таких условиях приводит к ошибке Out of Memory (OOM) на этапе инициализации. Чтобы уместить передовую LLM в ограниченные аппаратные рамки без критической потери логических способностей, применяется математическое сжатие весов.

Физика весов и проблема пропускной способности памяти

Параметр нейросети — это число, определяющее силу связи между искусственными нейронами. В процессе предварительного обучения (Pre-training) на кластерах из тысяч GPU эти числа вычисляются и сохраняются в формате с плавающей запятой.

Формат FP16 (16-bit Float) состоит из 1 бита знака, 5 битов экспоненты и 10 битов мантиссы. Он обеспечивает огромный динамический диапазон и высокую точность, необходимую для вычисления градиентов при обучении. Однако на этапе инференса (генерации текста) такая избыточная точность становится узким местом.

Проблема заключается не в вычислительной мощности ядер GPU (FLOPS), а в пропускной способности видеопамяти (Memory Bandwidth). Архитектура авторегрессионной генерации требует, чтобы для предсказания каждого следующего токена графический процессор прочитал из памяти абсолютно все веса модели. Если пропускная способность памяти видеокарты составляет 500 ГБ/с, а модель весит 16 ГБ, то теоретический предел скорости генерации составит около 31 токена в секунду (500 / 16), и это без учета накладных расходов на вычисление внимания и работу с KV-кэшем.

Сжатие каждого параметра с 16 бит (2 байта) до 4 бит (0.5 байта) дает двойной эффект. Во-первых, модель начинает занимать 4 ГБ вместо 16 ГБ, что позволяет полностью поместить ее в VRAM потребительской видеокарты. Во-вторых, объем данных, которые нужно перекачивать из памяти в вычислительные ядра для каждого токена, сокращается в 4 раза, что пропорционально увеличивает скорость генерации (TPS).

Математика квантования: от непрерывного к дискретному

Процесс перевода обученной модели из формата высокой точности в формат низкой точности называется Post-Training Quantization (PTQ). В отличие от Quantization-Aware Training (QAT), где модель обучается с учетом будущего сжатия, PTQ применяется к уже готовым весам.

Базовый механизм PTQ — это линейное асимметричное квантование (Min-Max Quantization). Идея заключается в том, чтобы взять диапазон вещественных чисел в конкретном тензоре (матрице весов) и отобразить его на ограниченную сетку целых чисел. Например, для 8-битного квантования (INT8) доступно 256 дискретных значений (от -128 до 127).

Формула перевода оригинального вещественного числа в квантованное целое выглядит так:

Где — итоговое квантованное целое число (например, в формате INT8), — оригинальное вещественное значение параметра (FP16), — масштабный коэффициент (Scale Factor), определяющий шаг сетки, а — нулевая точка (Zero-point), целое число, которое гарантирует, что реальный ноль точно совпадет с одним из дискретных значений квантованной сетки (это критически важно для производительности операций с разреженными матрицами, где много нулей).

Масштабный коэффициент вычисляется на основе минимального и максимального значений в тензоре:

Где и — границы диапазона вещественных весов в матрице, а и — границы целевого целочисленного типа (для INT8 это 127 и -128 соответственно).

На этапе инференса, когда ядрам GPU нужно выполнить матричное умножение, происходит обратный процесс — деквантование (Dequantization). Целые числа переводятся обратно в формат с плавающей запятой «на лету» прямо в регистрах процессора:

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

Рассмотрим пример. Допустим, у нас есть тензор весов с диапазоном от -0.5 до 1.2. Мы хотим сжать его в 4-битный формат (INT4), который имеет всего 16 значений (от -8 до 7). Если оригинальный вес равен 0.81, формула квантования может округлить его до значения, которое при обратном деквантовании превратится в 0.77. Разница в 0.04 — это потерянная информация. Если такие потери накапливаются в миллиардах параметров на протяжении 32 слоев трансформера, модель начинает галлюцинировать, забывать факты и терять способность к сложному синтаксису.

Архитектура GGUF: стандарт локального инференса

Оригинальные веса моделей от Meta или Mistral поставляются в форматах экосистемы PyTorch — .bin или .safetensors. Они представляют собой сырые дампы памяти тензоров, разбитые на куски по несколько гигабайт, и требуют загрузки в оперативную память, сборки графа вычислений через Python-код и последующей отправки на GPU. Это медленный процесс, требующий тяжеловесного окружения (CUDA, PyTorch, Transformers).

Для решения задачи эффективного локального запуска был разработан формат GGUF (GPT-Generated Unified Format). Он пришел на смену устаревшим форматам GGML и стал индустриальным стандартом для запуска моделей вне облачных кластеров, лежащим в основе движка llama.cpp и, как следствие, сервера Ollama.

GGUF решает две фундаментальные архитектурные задачи:

Единый файл (Single-file deployment). В классическом PyTorch-подходе для запуска модели нужна папка с десятком файлов: веса (.safetensors), конфигурация архитектуры (config.json), словарь токенизатора (tokenizer.model), параметры генерации (generation_config.json). GGUF упаковывает всё это в один бинарный файл. Метаданные (размер окна контекста, параметры RoPE, архитектура слоев) хранятся в структурированном виде в заголовке файла, а за ними следует непрерывный массив квантованных тензоров.

Memory Mapping (mmap). Формат GGUF спроектирован так, чтобы его структура на диске в точности совпадала с требуемой структурой в оперативной памяти. Это позволяет операционной системе использовать системный вызов mmap. Вместо того чтобы читать файл с диска, копировать его в RAM, а затем парсить, ОС просто проецирует файл в виртуальное адресное пространство процесса. Если модель не помещается в RAM целиком, операционная система будет подгружать нужные страницы памяти с SSD (Page Fault) прозрачно для приложения. Это обеспечивает мгновенный холодный старт: серверу не нужно ждать загрузки 8 ГБ данных в память, он готов отвечать на запросы через миллисекунды после запуска.

K-квантование: смешанная точность (Mixed Precision)

Простое квантование всей модели в 4 бита (так называемый метод Q4_0) работает грубо. Далеко не все слои нейросети одинаково важны для сохранения её «интеллекта». В архитектуре Llama 3 есть матрицы, которые крайне чувствительны к потере точности, и матрицы, где шум почти не влияет на итоговый результат.

Для решения этой проблемы было разработано K-квантование (K-Quants) — метод хирургического сжатия, при котором разные тензоры внутри одной модели квантуются с разной битовой глубиной. Веса разбиваются на суперблоки (обычно по 256 параметров), и для каждого блока вычисляются свои масштабные коэффициенты.

В номенклатуре Ollama и llama.cpp форматы K-квантования обозначаются как Q<bits>_K_<size>. Например, самый популярный формат для Llama 3 8B — это Q4_K_M (4-bit, K-quant, Medium). Разберем, что скрывается под этим индексом:

Тензоры внимания (Attention Q/K/V): Квантуются в 4 бита. Они отвечают за маршрутизацию информации между токенами и относительно устойчивы к шуму.

Тензоры прямой связи (Feed-Forward Networks): Половина матриц FFN (обычно down-projections) сжимается до 4 бит, а другая половина (up-projections/gate) сохраняется в 5 или даже 6 битах, так как именно в полносвязных слоях хранятся фактические знания модели.

Слой эмбеддингов и выходной слой (LM Head): Слой, преобразующий токены во внутренние векторы, и финальный слой, вычисляющий вероятности (логиты) следующего токена, почти всегда квантуются с более высокой точностью (Q6_K или Q8_0). Ошибка на финальном этапе генерации вероятностей фатальна, так как она напрямую искажает распределение Softmax.

Существует шкала размеров K-квантования:

Q4_K_S (Small): Максимально агрессивное сжатие. Почти все слои в 4 битах. Экономит максимум VRAM, но вызывает заметную деградацию логики.

Q4_K_M (Medium): Золотой стандарт. Критичные матрицы FFN используют 5 бит, эмбеддинги 6 бит. Идеальный баланс между размером и качеством.

Q5_K_M: Базовый уровень 5 бит. Используется, когда есть запас VRAM (например, 8 ГБ видеопамяти для модели на 8B параметров) и требуется максимальная точность для задач программирования или сложного математического вывода.

Налог на интеллект: измерение потерь через Perplexity

Сжатие весов не проходит бесследно. Чтобы объективно измерить деградацию модели, используется метрика Перплексии (Perplexity, PPL). В контексте языковых моделей перплексия показывает, насколько модель «удивлена» тестовым набором текста. Чем ниже значение PPL, тем лучше модель предсказывает реальный язык.

Зависимость между битовой глубиной и перплексией не является линейной. Это экспоненциальная кривая. При переходе от оригинальной модели FP16 к квантованию Q8_0 (8 бит) размер файла уменьшается вдвое, а рост перплексии составляет микроскопические доли процента. Модель ведет себя абсолютно идентично оригиналу. Переход от Q8_0 к Q5_K_M дает еще одно двукратное уменьшение размера. PPL возрастает незначительно, разница в ответах неразличима невооруженным глазом в 95% промптов. Переход от Q5_K_M к Q4_K_M вызывает легкий скачок PPL. Модель сохраняет связность речи, фактологию и способность следовать инструкциям, но может начать ошибаться в сложных многошаговых рассуждениях (Chain-of-Thought) или при написании объемного кода.

Однако падение ниже 4 бит (форматы Q3_K, Q2_K) приводит к катастрофическому коллапсу (Catastrophic Forgetting). Перплексия улетает в космос. Модель начинает генерировать бессмысленный набор слов, теряет способность применять системный промпт и забывает языковые конструкции.

Особенность архитектуры Llama 3 заключается в наличии так называемых выбросов активаций (Activation Outliers). В процессе генерации некоторые нейроны выдают значения, которые в сотни раз превышают средний фон тензора. Агрессивное квантование (ниже 4 бит) срезает эти выбросы, что для Llama 3 оказывается фатальным. Именно поэтому для Llama 3 8B формат Q4_K_M является абсолютным нижним порогом применимости в корпоративных задачах.

В контексте построения RAG-системы (Retrieval-Augmented Generation), где агенту необходимо анализировать предоставленный контекст из базы знаний и формулировать точный ответ, выбор формата квантования определяет стабильность пайплайна. Модель Llama 3 8B в формате Q4_K_M занимает около 4.8 ГБ на диске. При загрузке в VRAM вместе с контекстным окном на 8192 токена (KV-кэш) она потребует около 6.5–7 ГБ видеопамяти. Это позволяет комфортно развернуть высокопроизводительного ИИ-агента на одном потребительском GPU уровня RTX 3060/4060 или на сервере с картой Tesla T4, обеспечив скорость генерации свыше 40 токенов в секунду без обращения к платным облачным API.

Sentence Transformers: математика и практика локального создания эмбеддингов

Отправка конфиденциального корпоративного документа в облачный API только ради того, чтобы получить массив из 1536 чисел, нарушает базовые принципы информационной безопасности. При этом использование тяжеловесной генеративной модели вроде Llama 3 на 8 миллиардов параметров для локальной векторизации текста — это неэффективное расходование вычислительных ресурсов. Генерация эмбеддингов — математически иная задача, требующая специализированных, компактных архитектур, способных обрабатывать тысячи документов в секунду без привлечения дорогостоящих GPU.

Исторически языковые модели делились на два класса: авторегрессионные декодеры (как GPT или Llama), предсказывающие следующий токен, и энкодеры (как BERT), анализирующие контекст текста целиком в обоих направлениях. Для задачи семантического поиска энкодеры подходят значительно лучше, так как их цель — не генерация нового текста, а создание плотного математического представления существующего.

Однако использование «голого» BERT для получения эмбеддингов предложений сопряжено с фундаментальной математической проблемой — анизотропией векторного пространства.

Проблема анизотропии и ограничения классического BERT

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

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

Архитектура Sentence Transformers (часто называемая SBERT) была разработана специально для решения этой проблемы. Она модифицирует процесс обучения энкодера таким образом, чтобы заставить векторы семантически разных предложений отталкиваться друг от друга, распределяясь по пространству изотропно (равномерно во всех направлениях).

Сиамские сети и математика отталкивания

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

Процесс получения эмбеддинга внутри SBERT состоит из двух этапов:

Генерация контекстуализированных токенов. Текст разбивается на токены, и энкодер выдает матрицу размера , где — количество токенов, а — размерность скрытого пространства (например, 384 или 768).

Pooling (Объединение). Матрица сжимается в одномерный вектор размера . Чаще всего используется Mean Pooling — покомпонентное усреднение векторов всех токенов с учетом маски внимания (чтобы игнорировать токены отступов — padding).

Формула Mean Pooling выглядит следующим образом:

Где — итоговый вектор предложения, — вектор -го токена, — значение маски внимания для -го токена (1 для реальных слов, 0 для padding-токенов), а — общая длина последовательности.

Чтобы научить модель формировать качественные векторы , используется специальная функция потерь на этапе дообучения. Наиболее эффективной для семантического поиска является Triplet Loss (Тройная функция потерь).

Triplet Loss

Для обучения с использованием Triplet Loss формируются тройки предложений:

Якорь (Anchor, ) — исходное предложение.

Позитивный пример (Positive, ) — предложение, семантически близкое к якорю (например, перефраз).

Негативный пример (Negative, ) — предложение, не связанное по смыслу с якорем.

Цель сети — минимизировать расстояние между и , одновременно максимизируя расстояние между и . Математически функция потерь выражается так:

Где — значение ошибки, — функция расстояния (например, Евклидово расстояние) между векторами и , а (margin) — гиперпараметр зазора.

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

Практика локальной векторизации на Python

Экосистема Hugging Face предоставляет библиотеку sentence-transformers, которая инкапсулирует сложную логику токенизации, применения сиамских сетей и пулинга в простой API. В отличие от генеративных моделей, требующих llama.cpp для приемлемой скорости, энкодеры настолько малы (обычно от 20 до 300 МБ), что эффективно работают через стандартный PyTorch даже на CPU.

Модель all-MiniLM-L6-v2 — это классический пример компактного энкодера. Она генерирует векторы размерностью 384, весит около 90 МБ и способна векторизовать сотни предложений в секунду на обычном процессоре.

Однако при проектировании корпоративных систем необходимо учитывать специфику поиска. Классические модели обучаются на симметричных задачах (сравнение предложений одинаковой длины и структуры). В RAG-системах поиск почти всегда асимметричен: короткий запрос пользователя («как настроить vpn?») сравнивается с длинными параграфами технической документации.

Асимметричный поиск и префиксы инструкций

Для решения проблемы асимметрии современные модели (такие как семейство E5 от Microsoft или BGE от BAAI) обучаются с использованием инструктивных префиксов. Модель искусственно заставляют проецировать короткие вопросы и длинные ответы в одну и ту же область векторного пространства путем добавления специальных маркеров перед текстом.

При использовании модели intfloat/multilingual-e5-large разработчик обязан явно указывать модели, что именно сейчас векторизуется:

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

Оптимизация производительности: Батчинг и маски внимания

При обработке больших объемов данных (например, первичной индексации корпоративной Wiki) передача текстов в модель по одному предложению (model.encode("текст") в цикле) приведет к катастрофической потере производительности. Архитектура процессоров и видеокарт оптимизирована для параллельного умножения больших матриц.

Метод encode принимает список строк и автоматически объединяет их в батчи (пакеты).

Математика батчинга скрывает в себе важный нюанс обработки текстов разной длины. Тензоры в PyTorch должны иметь строгую прямоугольную форму. Если в одном батче оказались предложение из 10 токенов и параграф из 50 токенов, короткое предложение будет дополнено 40 нулями (padding-токенами), чтобы размерность матрицы составила .

Именно здесь вступает в работу маска внимания (Attention Mask), упомянутая в формуле Mean Pooling. Без маски внимания нули исказили бы итоговый вектор при усреднении, сместив его к началу координат. Маска внимания, состоящая из единиц для реальных токенов и нулей для padding-токенов, гарантирует, что математическое усреднение применяется только к значимой части текста, делая результат независимым от того, с какими соседями текст оказался в одном батче.

Параметр normalize_embeddings=True выполняет L2-нормализацию итоговых векторов. Длина каждого вектора приводится к единице (). Это критически важная оптимизация для векторных баз данных: если векторы нормализованы, вычисление косинусного расстояния математически сводится к простому скалярному произведению (Dot Product), которое процессоры выполняют значительно быстрее.

Ограничения контекста и «тихое» усечение

Генеративные модели вроде Llama 3 оперируют окном контекста в 8192 токена и более. Модели семейства Sentence Transformers, базирующиеся на архитектуре BERT, имеют жесткое архитектурное ограничение, обусловленное матрицей позиционных эмбеддингов, которая обучается на фиксированную длину.

Для большинства моделей (all-MiniLM, multilingual-e5) это ограничение составляет 512 токенов (около 300-400 слов на русском языке).

Опасность кроется в поведении библиотеки по умолчанию: если передать в model.encode() документ длиной 2000 токенов, библиотека не выдаст ошибку. Она произведет «тихое» усечение (Silent Truncation) — отбросит все токены после 512-го и сгенерирует вектор только для начала текста. В контексте RAG-системы это означает, что факты, находящиеся в конце длинного документа, никогда не будут найдены векторным поиском, так как они физически не участвовали в формировании эмбеддинга.

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

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

Интеграция локальных моделей в FastAPI: создание унифицированного внутреннего API

Если в корпоративной микросервисной архитектуре позволить пятидесяти независимым RAG-агентам напрямую отправлять запросы к порту 11434 демона Ollama, система гарантированно рухнет с ошибкой Out of Memory (OOM) в течение нескольких минут. Локальные графические ускорители, в отличие от эластичных облачных кластеров, имеют жесткие физические лимиты видеопамяти (VRAM). Кроме того, библиотека sentence-transformers является синхронным Python-кодом, который при прямом вызове внутри асинхронного веб-фреймворка полностью блокирует обработку всех остальных сетевых запросов.

Для построения надежной системы требуется архитектурный слой, который скроет физические ограничения оборудования от бизнес-логики агентов. Эту задачу решает внутренний AI Gateway — единый FastAPI-микросервис, инкапсулирующий работу с локальными моделями, управляющий очередями и предоставляющий стандартизированный интерфейс, совместимый со спецификацией OpenAI.

Архитектура AI Gateway для локального инференса

Паттерн AI Gateway в контексте локальных моделей выполняет три критические функции:

Унификация контрактов. Агенты не должны знать, генерируется ли вектор через облачный API или через локальную модель all-MiniLM-L6-v2. Gateway принимает стандартные JSON-запросы (например, /v1/embeddings и /v1/chat/completions) и маршрутизирует их под капотом.

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

Защита ресурсов (Backpressure). Gateway выступает в роли «буфера», отсекая или выстраивая в очередь избыточные запросы до того, как они достигнут GPU и вызовут падение процесса из-за нехватки VRAM.

Изоляция синхронного инференса Sentence Transformers

Библиотека sentence-transformers базируется на PyTorch. Метод model.encode() выполняет синхронные вычисления. Если вызвать его напрямую внутри async def маршрута FastAPI, цикл событий (Event Loop) остановится на всё время генерации вектора (от десятков до сотен миллисекунд). Все остальные клиенты, ожидающие ответа от сервера, получат задержку.

Решение заключается в выносе инференса в пул потоков. Особенность PyTorch заключается в том, что при выполнении тяжелых тензорных операций на уровне C++ (как на CPU, так и на GPU) он освобождает глобальную блокировку интерпретатора Python (GIL). Это означает, что использование ThreadPoolExecutor будет эффективным: потоки действительно смогут работать параллельно на многоядерном процессоре, не блокируя Event Loop.

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

Для обработки запроса создается эндпоинт, который принимает данные в формате, совместимом с OpenAI, и делегирует выполнение пулу потоков с помощью asyncio.get_running_loop().run_in_executor().

В этом сценарии FastAPI мгновенно передает задачу в фоновый поток и возвращает управление Event Loop. Сервер остается отзывчивым для новых HTTP-запросов, пока PyTorch выполняет вычисления.

Проксирование и потоковая передача ответов Ollama

В отличие от sentence-transformers, Ollama работает как независимый фоновый процесс (демон), доступный по HTTP. Задача AI Gateway здесь — не выполнять вычисления самостоятельно, а безопасно проксировать запросы к Ollama, обеспечивая маршрутизацию и обработку обрывов соединений.

Авторегрессионная генерация текста требует потоковой передачи (Server-Sent Events), чтобы клиент (например, веб-интерфейс или другой агент) получал токены по мере их появления, а не ждал завершения всей генерации.

Для этого используется асинхронный HTTP-клиент httpx внутри генератора, который передается в StreamingResponse от FastAPI.

Критически важный элемент в этом коде — проверка await client_request.is_disconnected(). Если пользователь закроет вкладку браузера или микросервис-потребитель отвалится по таймауту, FastAPI узнает об этом. Вызов break прервет цикл aiter_bytes(), что приведет к выходу из контекстного менеджера client.stream. Это немедленно закроет TCP-соединение с Ollama. Демон Ollama, обнаружив закрытый сокет, остановит генерацию токенов и освободит ресурсы GPU. Без этой проверки локальная видеокарта продолжала бы генерировать текст «в пустоту», блокируя очередь для других агентов.

Эндпоинт в FastAPI выступает простым транслятором:

Управление конкурентностью: защита видеопамяти (VRAM)

Главная уязвимость локального инференса — состояние Out of Memory. При каждом новом запросе LLM требует выделения памяти под KV-кэш (Key-Value Cache) для хранения контекста.

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

Где — статичная память под веса модели (например, ~4.8 ГБ для Llama 3 8B Q4_K_M), — количество одновременных запросов, а — динамически выделяемая память под контекст одного запроса (сильно зависит от размера окна контекста, num_ctx).

Если видеокарта имеет 12 ГБ VRAM, а для окна в 8192 токена составляет около 1.5 ГБ, то максимальное количество параллельных запросов рассчитывается как:

Если AI Gateway пропустит пятый одновременный запрос к Ollama, демон попытается выделить память, получит отказ от драйвера NVIDIA/AMD и аварийно завершит работу (или начнет агрессивно выгружать слои в медленную оперативную память, обрушив TPS до неприемлемых значений).

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

В этой архитектуре пятый и последующие запросы не дойдут до Ollama. Они будут приостановлены на строке llm_semaphore.acquire() внутри Event Loop FastAPI, потребляя лишь несколько килобайт оперативной памяти. Как только один из первых четырех запросов завершится (или клиент отключится), блок finally вызовет release(), и следующий запрос в очереди получит доступ к GPU. Если запрос прождет в очереди более 30 секунд, клиент получит корректный HTTP 503, что позволит агентам на другой стороне инициировать алгоритм Exponential Backoff для повторной попытки.

Аналогичный подход применяется и для пула потоков sentence-transformers. Параметр max_workers=4 в ThreadPoolExecutor уже действует как жесткий лимит конкурентности для CPU-вычислений, выстраивая остальные задачи во внутреннюю очередь пула.

Динамическая маршрутизация и единая точка входа

Имея защищенные эндпоинты для эмбеддингов и генерации текста, AI Gateway становится полноценной заменой облачным API для всей внутренней инфраструктуры. Агентам, написанным на LangChain или LangGraph, достаточно передать базовый URL микросервиса http://internal-ai-gateway:8000/v1.

Маршрутизация внутри Gateway может быть расширена. Например, если в будущем потребуется добавить модель whisper для распознавания аудио или маршрутизировать запросы к легким моделям (qwen:0.5b) на CPU, а тяжелые (llama3:70b) отправлять на отдельный сервер с кластером GPU, эта логика инкапсулируется в Gateway. Агенты продолжат отправлять запросы на единый эндпоинт, меняя лишь параметр "model" в JSON-нагрузке.

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

Оптимизация производительности: батчинг запросов и управление видеопамятью (VRAM)

Вы арендовали сервер с мощным графическим ускорителем на 24 ГБ VRAM, развернули локальную модель и замерили скорость: один запрос обрабатывается за 1 секунду. Логично предположить, что при поступлении 10 одновременных запросов сервер справится с ними примерно за то же время, распределив ресурсы. На практике, если пропустить эти 10 запросов через базовый шлюз с семафором, общее время ожидания для последнего пользователя составит 10 секунд. Графический процессор загружен на 100%, кулеры работают на максимуме, но пропускная способность системы остается на уровне одного запроса в секунду. Эта иллюзия эффективности возникает из-за непонимания разницы между вычислительной плотностью и пропускной способностью памяти.

Анатомия простоя: Memory-bound против Compute-bound

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

Генерация текста авторегрессионной моделью (например, Llama 3) на уровне размера батча, равного единице, является задачей класса Memory-bound. Чтобы сгенерировать один токен, графический процессор должен загрузить все веса модели (миллиарды параметров) из видеопамяти (VRAM) в регистры вычислительных ядер. Вычисления происходят за микросекунды, после чего ядра простаивают, ожидая следующей порции данных для следующего токена.

Если мы обрабатываем запросы строго последовательно, мы используем лишь малую долю вычислительного потенциала GPU (Compute-bound емкости). Решение кроется в объединении запросов в пакеты (батчи). При батчинге веса модели загружаются из памяти в регистры ровно один раз, но умножаются сразу на матрицу входных данных от нескольких пользователей.

Математически время выполнения пакета запросов описывается как , где — время обработки одного запроса, а — незначительные накладные расходы на вычисление дополнительных матриц. Таким образом, обработка 10 запросов в батче займет не 10 секунд, а условные 1.2 секунды.

Однако реализация батчинга в асинхронном веб-сервере сталкивается с архитектурной проблемой: HTTP-запросы приходят непредсказуемо и изолированно.

Динамический батчинг на уровне AI Gateway

Классический (статический) батчинг подразумевает ожидание фиксированного количества запросов перед отправкой их в модель. Если размер батча равен 8, а пришло только 3 запроса, система будет бесконечно ждать еще 5, заморозив ответы первым пользователям. Для API реального времени это неприемлемо.

Решением выступает Dynamic Batching (Динамический батчинг) — паттерн проектирования, при котором накапливание запросов ограничено двумя независимыми триггерами: максимальным размером пакета и максимальным временем ожидания.

Архитектура накопительного буфера в FastAPI

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

Инициализация Future-объекта: Когда пользователь делает запрос к эндпоинту, создается объект asyncio.Future, который будет хранить результат. Запрос вместе с этим объектом помещается в глобальную очередь asyncio.Queue.

Фоновый воркер (Background Worker): Бесконечный цикл, запущенный при старте приложения, непрерывно читает эту очередь.

Окно сбора (Gathering Window): Воркер извлекает первый запрос и запускает таймер (например, миллисекунд). В течение этого времени он собирает все поступающие в очередь запросы, пока не истечет таймер или не будет достигнут лимит (например, 16 запросов).

Векторизация и возврат: Собранный массив текстов передается в модель (например, Sentence Transformers) единым тензором. После получения результатов воркер распределяет векторы по соответствующим Future-объектам, что мгновенно разблокирует ожидающие HTTP-запросы.

Оптимизация выравнивания (Padding Waste)

При батчинге текстов для генерации эмбеддингов возникает нюанс: тензоры должны иметь строгую прямоугольную форму. Если в один батч попадают тексты длиной 10 токенов и 500 токенов, короткий текст будет дополнен нулями (padding-токенами) до длины максимального.

В результате графический процессор будет выполнять ресурсоемкие операции внимания (Attention) над пустотой. Доля бесполезных вычислений (Padding Waste) может достигать 90%.

Для минимизации потерь применяется предварительная сортировка. AI Gateway накапливает большой пул запросов (например, 100), сортирует их по длине (количеству токенов), а затем нарезает на батчи по 16 элементов. В таком случае тексты длиной 10 и 12 токенов окажутся в одном батче (потери минимальны), а текст на 500 токенов попадет в батч с другими длинными документами.

От статики к потоку: Continuous Batching для LLM

Если для моделей-энкодеров (Sentence Transformers) динамический батчинг работает идеально, то для авторегрессионных LLM (Ollama, Llama 3) он сталкивается с фундаментальной проблемой разной длины генерации.

Предположим, мы собрали 4 запроса в батч.

Запрос А требует ответа «Да» (1 токен).

Запрос Б требует написания эссе (500 токенов).

В парадигме обычного батчинга, сгенерировав ответ для запроса А, GPU продолжит прогонять его через матричные умножения (генерируя мусор или стоп-токены) еще 499 раз, пока не завершится генерация для запроса Б. Вычислительные ресурсы тратятся впустую, а новые запросы из очереди не могут занять освободившееся место запроса А, так как батч заблокирован до полного завершения самой длинной генерации.

Индустриальным стандартом решения этой проблемы является Continuous Batching (Непрерывный батчинг) или планирование на уровне итераций (Iteration-level scheduling).

В этой архитектуре батч не является статичным массивом на всё время генерации. Система управляет пулом запросов на уровне каждого отдельного шага предсказания токена. Как только запрос А генерирует свой стоп-токен (EOS), он немедленно удаляется из исполняемого батча. На его место, прямо в следующем цикле генерации (на следующей миллисекунде), инжектируется новый запрос В из очереди ожидания.

Внутри непрерывного батча одновременно находятся запросы на разных стадиях: для одного вычисляется фаза префилла (чтение контекста), для другого генерируется 5-й токен, для третьего — 100-й. Это позволяет поддерживать загрузку GPU на уровне, близком к 100%, увеличивая пропускную способность (TPS) в десятки раз по сравнению с последовательной обработкой.

Примечание к архитектуре: Базовый движок llama.cpp (используемый в Ollama) поддерживает непрерывный батчинг, но его эффективность ограничена при высоких нагрузках. В корпоративных системах с сотнями RPS для реализации этой логики шлюз маршрутизирует запросы к специализированным инференс-серверам (например, vLLM), которые спроектированы исключительно вокруг концепции Continuous Batching.

Управление видеопамятью: фрагментация и PagedAttention

Рост пропускной способности через батчинг имеет жесткий лимит — объем доступной VRAM. И главной причиной ошибок OOM (Out of Memory) при конкурентной нагрузке является не размер самих весов модели, а неконтролируемый рост KV-кэша.

В авторегрессионных моделях ключи (K) и значения (V) внимания для каждого сгенерированного токена сохраняются в памяти, чтобы не вычислять их заново на следующем шаге. Размер KV-кэша зависит от размера батча и длины контекста.

Проблема внутренней фрагментации

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

Если пользователь просит перевести одно предложение (ответ занимает 20 токенов), остальные 4076 слотов в выделенном блоке памяти остаются пустыми, но заблокированными для других запросов. Это явление называется внутренней фрагментацией. Из-за нее реальная утилизация VRAM часто не превышает 20-30%, а система падает с ошибкой OOM, хотя физически память свободна.

PagedAttention как спасение VRAM

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

Вместо выделения одного гигантского непрерывного куска памяти под весь контекст, KV-кэш разбивается на небольшие блоки фиксированного размера (например, по 16 токенов). Система поддерживает таблицу страниц (Block Table), которая маппит логические блоки запроса на физические блоки в VRAM. Физические блоки не обязаны располагаться последовательно.

Механика работы:

При старте запроса выделяется только один физический блок на 16 токенов.

По мере генерации, когда 16-й токен заполняет блок, система динамически выделяет следующий физический блок и обновляет таблицу страниц.

Если генерация останавливается на 20-м токене, теряется только пустое место в последнем блоке (максимум 12 слотов), а не тысячи слотов.

Такой подход практически полностью устраняет внутреннюю фрагментацию, позволяя увеличить размер батча (и, следовательно, пропускную способность) в 2-4 раза на том же оборудовании.

Разделение префиксов (Prefix Caching)

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

В корпоративных системах множество агентов используют один и тот же объемный системный промпт (например, правила поведения на 1000 токенов). При классическом подходе этот промпт вычисляется и сохраняется в KV-кэш индивидуально для каждого из 10 пользователей в батче, дублируя данные 10 раз.

С таблицей страниц (Block Table) система физически вычисляет и сохраняет KV-кэш системного промпта один раз. Таблицы страниц всех 10 пользовательских запросов просто ссылаются на одни и те же физические блоки в VRAM. Копирование данных (Copy-on-Write) происходит только в момент, когда контексты начинают расходиться (на этапе пользовательского ввода). Это радикально снижает (стоимость запроса) при использовании тяжелых системных инструкций.

Стратегии защиты от перегрузок (Graceful Degradation)

Даже при использовании непрерывного батчинга и PagedAttention, входящий трафик может превысить физические возможности сервера. AI Gateway должен реализовывать механизмы защиты, чтобы система не рухнула целиком, а плавно снизила качество обслуживания.

Динамическое ограничение контекста: Если мониторинг показывает, что свободно менее 10% VRAM, шлюз может начать принудительно обрезать историю диалогов (эпизодическую память) перед отправкой в модель. Пользователь получит ответ с учетом последних 3 сообщений вместо 10, но система продолжит работать.

KV-Cache Offloading (Выгрузка кэша): При нехватке видеопамяти блоки KV-кэша наименее активных запросов могут быть временно асинхронно выгружены в оперативную память (RAM) через шину PCIe, а затем возвращены обратно, когда придет их очередь генерации. Это увеличивает задержку (Latency), но сохраняет консистентность сессий.

Раннее отклонение (Shedding): Если очередь запросов в динамическом батчере превышает допустимое время ожидания (например, клиент всё равно отвалится по таймауту через 30 секунд), шлюз должен мгновенно возвращать HTTP 429 Too Many Requests, не допуская попадания "мертвых" запросов в вычислительный конвейер GPU.

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

Мульти-агентные системы на LangGraph: циклы, условия и сохранение состояний

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

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

От конвейеров к графам состояний

Традиционные пайплайны обработки данных работают по принципу передачи вывода одной функции на вход следующей. В контексте вероятностных LLM этот подход приводит к накоплению ошибки. Если Llama 3 сгенерировала некорректный SQL-запрос, следующая функция в DAG попытается его выполнить, получит ошибку синтаксиса базы данных и передаст эту ошибку финальному генератору ответа, который выдаст пользователю нерелевантный текст.

Архитектура LangGraph решает эту проблему, реализуя модель акторов поверх графа состояний. Вместо прямой передачи данных между узлами, вводится концепция глобального состояния графа (State). Каждый узел (Node) в графе — это чистая функция, которая принимает текущее состояние, выполняет полезную работу (например, обращается к AI Gateway для вызова локальной LLM) и возвращает дельту (изменения), которая должна быть применена к состоянию.

Маршрутизация между узлами определяется ребрами (Edges). В отличие от статических пайплайнов, LangGraph позволяет создавать условные ребра (Conditional Edges) — функции, которые анализируют текущее состояние и динамически определяют, какой узел должен быть выполнен следующим. Это открывает возможность для создания циклов саморефлексии (Self-Reflection Loops). Если база данных возвращает ошибку синтаксиса, условное ребро направляет поток выполнения обратно к узлу генерации SQL, прикрепив текст ошибки к состоянию, чтобы модель могла исправить свой код.

Архитектура состояния и редукторы

Фундаментом любого графа в LangGraph является схема состояния. Поскольку мы строим надежные системы, состояние типизируется с помощью TypedDict из стандартной библиотеки Python или моделей Pydantic, что позволяет валидировать данные на каждом шаге.

Ключевой механизм управления состоянием — это редукторы (Reducers). Когда узел завершает работу, он возвращает словарь с обновлениями. Граф должен знать, как объединить эти обновления с существующим состоянием. Математически процесс обновления можно описать как , где — текущее состояние, — изменения, предложенные узлом, а — функция-редуктор.

По умолчанию LangGraph использует редуктор перезаписи: если узел возвращает значение для существующего ключа, старое значение уничтожается. Однако для списков (например, истории сообщений) такое поведение деструктивно.

Для ключей, хранящих массивы данных, применяется редуктор добавления (часто реализуемый через operator.add). Если текущее состояние содержит messages: ["User: Найди ошибки"], а узел возвращает messages: ["AI: Ошибка в строке 5"], редуктор объединит их в messages: ["User: Найди ошибки", "AI: Ошибка в строке 5"]. Это критически важно для сохранения контекста диалога при многократном прохождении циклов.

Пример схемы состояния для агента-исследователя:

task: строка, исходная задача (перезаписывается).

draft: строка, текущий черновик ответа (перезаписывается).

critique: строка, замечания от узла-рецензента (перезаписывается).

messages: список сообщений (добавляется через редуктор).

revision_number: целое число, счетчик итераций (перезаписывается, инкрементируется узлом).

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

Узлы и условная маршрутизация

В мульти-агентной системе узлы графа инкапсулируют специфичные роли. Рассмотрим паттерн «Генератор-Оценщик» (Generator-Evaluator), где две разные инстанции локальной Llama 3 (возможно, с разными системными промптами и температурой) работают в тандеме.

Узел Generator: принимает задачу и замечания (если они есть), обращается к Ollama, генерирует текст и обновляет поле draft.

Узел Evaluator: принимает draft, анализирует его на соответствие требованиям задачи. Возвращает булевый флаг is_accepted и текст critique.

Условное ребро: функция, которая читает is_accepted. Если True — направляет поток в специальный узел END (завершение графа). Если False — проверяет revision_number. Если лимит не исчерпан, направляет поток обратно в узел Generator.

Эта архитектура изолирует зоны ответственности. Generator может использовать модель с высокой температурой для креативности, а Evaluator — модель с температурой для строгой детерминированной проверки фактов.

Условные ребра также решают проблему динамического выбора инструментов (Tool Calling). Узел, взаимодействующий с LLM, может вернуть структурированный запрос на вызов функции (например, запрос к векторной базе Qdrant для получения эмбеддингов). Условное ребро анализирует состояние: если в массиве сообщений появилось требование вызова инструмента, поток направляется в узел ToolExecutor, который выполняет Python-код. После выполнения ToolExecutor всегда возвращает результат в узел LLM, замыкая цикл.

Паттерны мульти-агентного взаимодействия

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

Паттерн Supervisor (Супервизор)

В этой топологии существует один центральный узел-маршрутизатор (Supervisor) и несколько рабочих узлов (Workers). Рабочие узлы не общаются друг с другом напрямую.

Супервизор получает общую задачу и текущее состояние, после чего принимает решение, какому агенту передать управление. Например, при запросе «Проанализируй финансовый отчет за 2023 год и напиши summary», супервизор сначала вызывает SearchAgent (для поиска документа), затем DataExtractionAgent (для извлечения цифр), и наконец WriterAgent (для формирования текста).

Сложность реализации этого паттерна с локальными моделями заключается в том, что супервизор должен строго соблюдать формат вывода для корректной маршрутизации. Если Llama 3 8B вместо точного названия узла SearchAgent сгенерирует фразу «Я думаю, нам нужно использовать агента поиска», алгоритм маршрутизации сломается. Для решения этой проблемы применяется строгая валидация Pydantic с использованием типа Literal, принуждающая локальную LLM генерировать исключительно разрешенные ключи маршрутизации.

Паттерн Hierarchical (Иерархический)

Для масштабных корпоративных систем применяется вложенная архитектура. Граф верхнего уровня (Top-Level Graph) управляет графами нижнего уровня (Sub-graphs).

Например, узел ResearchDepartment в главном графе на самом деле является самостоятельным графом LangGraph, внутри которого есть свой супервизор, свои агенты поиска и сбора данных. Когда ResearchDepartment завершает работу, он возвращает агрегированный результат в главное состояние, и управление переходит к следующему макро-узлу, например, LegalCompliance. Эта инкапсуляция позволяет разрабатывать, тестировать и версионировать графы агентов независимо друг от друга.

Checkpointers: долговременная память и прерывание выполнения

В базовом варианте граф выполняется в оперативной памяти от узла START до узла END. Если в процессе выполнения сервер FastAPI перезагрузится, весь прогресс агентов будет потерян. Для обеспечения отказоустойчивости и реализации асинхронного взаимодействия с пользователем в LangGraph внедрен механизм Checkpointers (Контрольные точки).

Checkpointer автоматически сохраняет полный снимок состояния графа (State Snapshot) после завершения работы каждого узла. Это реализуется путем привязки состояния к уникальному идентификатору потока (thread_id).

Сохранение состояния решает две критические задачи корпоративных ИИ-систем:

Устойчивость к сбоям (Fault Tolerance): Если узел WebSearch падает из-за сетевого таймаута, система не начинает работу с нуля. При повторном вызове графа с тем же thread_id LangGraph загрузит последнее успешное состояние из базы данных и продолжит выполнение с того узла, на котором произошел сбой.

Human-in-the-Loop (Человек-в-контуре): Автономным агентам нельзя доверять деструктивные действия (удаление файлов, отправка писем клиентам, выполнение SQL-запросов на запись).

Механизм Human-in-the-Loop реализуется через установку точек останова (Breakpoints) перед критическими узлами. При проектировании графа разработчик указывает, что перед выполнением узла ExecuteSQL выполнение должно быть приостановлено.

Когда поток доходит до этого узла, LangGraph сериализует текущее состояние (включая сгенерированный агентом SQL-запрос) и сохраняет его в персистентное хранилище (например, в колонку типа JSONB в PostgreSQL). Выполнение графа замораживается, освобождая ресурсы сервера.

В этот момент внешний интерфейс (веб-приложение) может запросить состояние по thread_id, отобразить SQL-запрос оператору-человеку и предоставить кнопки «Одобрить» или «Отклонить». Если оператор нажимает «Одобрить», FastAPI-эндпоинт отправляет сигнал возобновления в LangGraph, передавая тот же thread_id. Граф «просыпается», загружает состояние из БД и бесшовно выполняет узел ExecuteSQL.

Более того, оператор может не просто одобрить действие, но и мутировать состояние перед возобновлением. Если человек замечает мелкую ошибку в SQL-запросе, он может отредактировать его в интерфейсе. Измененный запрос перезаписывается в чекпоинт, и при возобновлении графа узел ExecuteSQL выполнит уже исправленный код. Эта возможность прямого вмешательства в память графа (State Modification) делает систему управляемой и безопасной для внедрения в production.

Управление параллелизмом внутри графа

В сложных сценариях некоторые задачи не зависят друг от друга и могут выполняться параллельно для снижения общей задержки системы. LangGraph поддерживает параллельное ветвление (Fan-out) и слияние (Fan-in).

Если узел маршрутизации возвращает массив следующих узлов, например ["SearchGoogle", "SearchInternalDB"], граф запускает оба узла одновременно. Ключевым моментом здесь является безопасное слияние результатов. Поскольку оба узла работают с одним и тем же состоянием параллельно, возникает классическая проблема состояния гонки (Race Condition).

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

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

Оркестрация распределенных агентов: Celery, Kafka и асинхронное взаимодействие

Ситуация: мульти-агентная система, построенная на графовой логике, успешно проходит локальные тесты. Узел Researcher собирает данные, узел Coder пишет скрипт, узел Reviewer проверяет код. Но при развертывании в production система начинает хаотично возвращать ошибки 504 Gateway Timeout, а сервер баз данных сигнализирует о блокировках. Причина кроется в физике локальных LLM: если узел Coder обращается к тяжелой модели Llama 3 70B, генерация может занять 45 секунд. В рамках единого процесса этот вызов либо блокирует асинхронный цикл событий, либо удерживает открытым HTTP-соединение и транзакцию к базе данных на непозволительно долгое время. Монолитное выполнение графа становится нежизнеспособным.

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

Архитектурные парадигмы: Оркестрация против Хореографии

При проектировании распределенных ИИ-систем фундаментальный выбор лежит между двумя паттернами управления потоком выполнения.

Оркестрация (Orchestration) подразумевает наличие единого центрального контроллера. В нашем контексте это инстанс графа (например, Supervisor), который точно знает всю схему бизнес-логики. Контроллер принимает решение, какой агент должен работать следующим, формирует для него конкретную команду и отправляет её в очередь задач (через Celery/RabbitMQ). Агент-воркер получает приказ «Сгенерируй SQL-запрос по схеме X», выполняет его и возвращает результат контроллеру. Контроллер обновляет глобальное состояние и решает, что делать дальше. Плюсы: логика системы прозрачна и описана в одном месте (в коде графа). Минусы: контроллер становится единой точкой отказа и потенциальным узким местом.

Хореография (Choreography) исключает центрального дирижера. Агенты представляют собой полностью независимые микросервисы, которые общаются через шину событий (обычно Apache Kafka). Никто не отдает прямых приказов. Вместо этого агент Researcher, завершив сбор данных, публикует в топик событие DataGathered. Агент Coder, подписанный на этот топик, видит событие, самостоятельно решает, что ему нужно написать код, выполняет работу и публикует событие CodeWritten. Плюсы: максимальная слабая связность (loose coupling) и легкость добавления новых агентов (достаточно просто подписать нового агента на существующий топик). Минусы: общую логику процесса невозможно увидеть в одном файле, отладка усложняется, возникает риск появления «заброшенных» событий, на которые никто не отреагировал.

На практике корпоративные ИИ-системы используют гибридный подход: локальные циклы рассуждений реализуются через оркестрацию (LangGraph + Celery), а глобальное взаимодействие между независимыми доменами (например, ИИ-отдел продаж и ИИ-отдел аналитики) — через хореографию (Kafka).

Интеграция LangGraph и Celery: Граф как задача vs Узел как задача

При использовании Celery для выноса тяжелых LLM-вычислений в фоновые воркеры существует два основных подхода к декомпозиции.

Подход 1: Граф как единая фоновая задача

Самый простой путь — обернуть весь вызов графа в задачу Celery. FastAPI-эндпоинт принимает запрос пользователя, генерирует уникальный task_id, отправляет задачу в RabbitMQ и немедленно возвращает HTTP 202 Accepted. Celery-воркер извлекает задачу, инициализирует граф, прогоняет все узлы локально в своей памяти и сохраняет финальное состояние в базу данных.

Этот подход решает проблему таймаутов HTTP-запросов, но сохраняет аппаратную монолитность. Если в графе есть узел, требующий GPU для эмбеддингов, и узел, требующий огромного объема RAM для агрегации данных, воркер должен обладать и тем, и другим. Масштабировать узлы независимо невозможно.

Подход 2: Узлы как распределенные задачи (Node-as-a-Task)

В этой архитектуре граф выполняется на легковесном контроллере, но сами узлы не делают запросов к LLM. Узел графа выступает лишь диспетчером: он формирует полезную нагрузку, отправляет задачу в специализированную очередь Celery (например, маршрутизация routing_key='gpu_heavy') и приостанавливает выполнение графа.

Реализация этого паттерна требует механизма Suspend/Resume. Когда узел отправляет задачу в Celery, он должен завершить свое выполнение, вернув специальный маркер состояния (например, status: 'waiting_for_coder'). Граф сохраняет свой снимок (State Snapshot) в Checkpointer (PostgreSQL) и засыпает. Когда удаленный Celery-воркер завершает генерацию кода через локальную Llama 3, он сохраняет результат в базу данных и инициирует пробуждение графа (например, отправляя легковесный webhook обратно в API контроллера или вызывая задачу пробуждения). Контроллер загружает состояние по thread_id, видит обновленные данные и продолжает выполнение со следующего узла.

Здесь критически важно применять паттерн «Камера хранения» (Claim Check). Передавать весь массив истории диалога (сотни килобайт JSON) через брокер RabbitMQ неэффективно — это приведет к деградации производительности брокера и переполнению памяти. В задачу Celery передается только thread_id и node_name. Воркер самостоятельно обращается к реляционной БД, извлекает нужный контекст, выполняет инференс и записывает результат обратно в БД.

Apache Kafka: Потоковая обработка и Fan-out паттерны

В сценариях, где требуется параллельная работа множества независимых агентов над одним и тем же контекстом (паттерн Fan-out), традиционные очереди задач вроде Celery/RabbitMQ уступают место потоковым платформам, таким как Apache Kafka.

Kafka работает по принципу иммутабельного журнала (Log). Сообщения не удаляются после прочтения, а остаются на диске в течение заданного времени удержания (retention period). Это открывает возможность для использования Consumer Groups (групп потребителей).

Представим процесс обработки загруженного корпоративного документа. Событие DocumentUploaded попадает в топик Kafka. У нас есть три независимых агента:

Агент суммаризации (создает краткую выжимку).

Агент PII-фильтрации (ищет и маскирует персональные данные).

Агент векторного поиска (разбивает текст на чанки и генерирует эмбеддинги).

Если бы мы использовали очередь задач, нам пришлось бы создавать три отдельные задачи и отправлять их в три разные очереди. В Kafka мы отправляем одно событие в топик documents_events. Три агента запускаются с разными идентификаторами group.id. Kafka гарантирует, что каждая группа потребителей получит копию этого события. Они начнут обрабатывать документ параллельно.

Математика масштабирования в Kafka строго привязана к партициям (Partitions). Топик разбивается на партиций. Одно событие записывается строго в одну партицию (обычно на основе хэша ключа, например, document_id). Внутри одной Consumer Group каждую партицию может читать только один воркер. Следовательно, максимальный уровень параллелизма для одного типа агентов ограничен количеством партиций:

Если в топике 4 партиции, а мы запустим 5 воркеров агента суммаризации, пятый воркер будет простаивать. Это кардинально отличается от Celery, где можно добавить 100 воркеров к одной очереди, и они будут разбирать задачи конкурентно.

Управление смещениями (Offsets) и проблема долгих LLM-вызовов

Оркестрация ИИ-агентов через Kafka сталкивается с серьезной технической проблемой: временем обработки. Инференс LLM — это Compute-bound задача, которая может длиться минутами.

Kafka отслеживает прогресс чтения через механизм смещений (Offsets). По умолчанию потребитель периодически отправляет брокеру сигнал heartbeat (пульс), подтверждая, что он жив, и автоматически коммитит смещения (auto-commit). Если агент берет сообщение, начинает 60-секундную генерацию текста, и в это время поток блокируется, heartbeat не отправляется. Брокер Kafka считает агента мертвым (Session Timeout), инициирует ребалансировку (Rebalance) и передает это же сообщение другому воркеру. В итоге два агента параллельно генерируют один и тот же текст, сжигая вычислительные ресурсы.

Для решения этой проблемы необходимо:

Разделить поток потребления (чтения из Kafka) и поток обработки (инференс LLM).

Отключить enable.auto.commit и перевести систему на ручное подтверждение (Manual Commit).

Тщательно настроить параметры max.poll.interval.ms (максимальное время между вызовами поллинга), установив его выше максимально возможного времени генерации LLM (например, 300000 мс, то есть 5 минут).

Смещение должно фиксироваться строго после того, как результат работы LLM успешно сохранен в базу данных (двухфазная фиксация). Если агент падает во время генерации (например, из-за нехватки VRAM — OOM), смещение не коммитится, и после перезапуска агент прочитает сообщение заново, обеспечивая гарантию доставки At-Least-Once (хотя бы один раз).

Идемпотентность и разрешение состояния гонки при Fan-in

Гарантия At-Least-Once неизбежно ведет к дублированию сообщений. Сетевой сбой в момент отправки коммита смещения приведет к тому, что сообщение будет обработано повторно. В распределенных ИИ-системах повторная генерация ответа LLM не только стоит дорого, но и может разрушить консистентность диалога.

Все действия агентов должны быть идемпотентными — повторное выполнение операции не должно менять состояние системы после первого успешного выполнения. Реализуется это через уникальные ключи идемпотентности. Когда агент получает событие из Kafka или задачу из Celery, он первым делом извлекает event_id и пытается создать запись в таблице processed_events базы данных. Если срабатывает ограничение уникальности (Unique Violation), агент понимает, что задача уже была обработана, и мгновенно завершает работу, коммитя смещение.

Куда более сложная проблема возникает при паттерне Fan-in — когда параллельно работающие агенты (например, суммаризатор и PII-фильтр) завершают работу и пытаются одновременно обновить глобальное состояние графа (State) в таблице Checkpointer'а.

Если два воркера прочитают текущее состояние State (версия 1), локально применят свои редукторы, а затем попытаются записать результат (версия 2), произойдет классическая аномалия Lost Update. Изменения того агента, который запишет данные первым, будут затерты вторым агентом.

Для защиты распределенного графа применяется оптимистичная блокировка (Optimistic Concurrency Control), встроенная в реляционные БД. Каждая запись состояния имеет колонку version_id. При попытке обновления воркер выполняет запрос:

Если количество обновленных строк равно нулю (другой воркер уже успел обновить состояние и изменить версию), ORM выбрасывает исключение (например, StaleDataError). Воркер перехватывает его, заново считывает актуальное состояние из БД, повторно применяет свой редуктор к новым данным и повторяет попытку записи. Это гарантирует математическую целостность памяти агентов без использования тяжелых пессимистичных блокировок, которые могли бы парализовать систему.

Обработка отказов: Dead Letter Queues и паттерн Saga

Вероятностная природа локальных LLM делает отказы нормой. Модель может выдать невалидный JSON, который не пройдет строгую валидацию Pydantic, или уйти в бесконечную генерацию мусорных токенов.

В архитектуре на базе Celery/RabbitMQ для изоляции сбойных задач настраивается Dead Letter Exchange (DLX). Если задача превышает SoftTimeLimit или падает с ошибкой парсинга более 3 раз (настраивается через autoretry_for), она не отбрасывается, а перенаправляется в специальную очередь Dead Letter Queue (DLQ). Инженеры могут проанализировать промпты, попавшие в DLQ, исправить системные инструкции агента и отправить задачи на повторную обработку.

В сложных мульти-агентных цепочках отказ одного узла может потребовать отмены действий, уже совершенных предыдущими узлами. Поскольку мы не можем удерживать ACID-транзакцию в БД на протяжении работы всего распределенного графа (это займет минуты), применяется паттерн Saga.

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

Агент A бронирует слот в расписании (успех, локальная БД обновлена).

Агент B генерирует текст письма клиенту (успех).

Агент C пытается отправить письмо через внешний API, но получает перманентный отказ (сбой).

Оркестратор (или хореографическая логика) ловит событие сбоя и отправляет команду Агенту A: «Отмени бронирование слота». Агенты должны быть спроектированы так, чтобы для каждого действия изменения состояния существовало явное действие отмены. В контексте LangGraph это реализуется через условные ребра, которые при получении статуса error маршрутизируют поток к специальным узлам-компенсаторам, очищающим промежуточные данные перед окончательным завершением графа со статусом failed.

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

Корпоративный мониторинг и трассировка: Prometheus, Grafana и LangSmith

Когда мульти-агентная система зависает на 40 секунд при обработке пользовательского запроса, сырые логи стэк-трейсов оказываются бесполезными. Проблема может скрываться на любом уровне: исчерпание VRAM при загрузке новой модели в Ollama, блокировка Event Loop в FastAPI из-за долгого тензорного вычисления Sentence Transformers, отставание консьюмеров Kafka или бесконечный цикл саморефлексии внутри узлов LangGraph. Для диагностики сложных ИИ-пайплайнов требуется разделение телеметрии на два независимых потока: макроуровневый мониторинг инфраструктуры и микроуровневую трассировку логики агентов.

Двойственная природа ИИ-наблюдаемости

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

Метрики — это агрегированные числовые показатели, привязанные к временной шкале (Time-Series Data). Они отвечают на вопрос «Что происходит с системой в целом?». Метрики обладают фиксированным размером в памяти независимо от нагрузки: счетчик обработанных токенов занимает столько же байт при 10 запросах в секунду, сколько и при 10 000. Это делает их идеальным инструментом для мониторинга аппаратных ресурсов (GPU, RAM), размеров очередей и пропускной способности. Стандартом де-факто для сбора метрик является Prometheus.

Трассировки (Traces) — это структурированные записи о конкретном пути выполнения единичного запроса. Они отвечают на вопрос «Почему этот конкретный запрос обработан именно так?». В контексте LLM трассировка должна захватывать не только время выполнения функций, но и объемные текстовые данные: системные промпты, промежуточные ответы модели, аргументы вызовов инструментов и результаты поиска по векторной базе. Из-за огромного объема данных (один запрос может генерировать мегабайты логов) трассировки требуют специализированных хранилищ. Для экосистемы LangChain и LangGraph таким стандартом выступает платформа LangSmith.

Архитектура сбора метрик: Prometheus и FastAPI

Prometheus использует Pull-модель сбора данных. Вместо того чтобы микросервисы отправляли метрики в центральное хранилище (Push-модель), Prometheus сам периодически (например, каждые 15 секунд) опрашивает HTTP-эндпоинты /metrics всех зарегистрированных сервисов. Это снимает с FastAPI-приложения ответственность за сетевую доставку телеметрии и предотвращает падение ИИ-шлюза при недоступности сервера мониторинга.

Для интеграции с FastAPI используется библиотека prometheus_client, которая предоставляет четыре основных типа метрик. В контексте локальных LLM наиболее востребованы три из них:

Counter (Счетчик) — монотонно возрастающее значение. Используется для подсчета общего количества сгенерированных токенов, количества запросов к Ollama или числа ошибок валидации Pydantic.

Gauge (Датчик) — значение, которое может как увеличиваться, так и уменьшаться. Идеально подходит для мониторинга текущего потребления VRAM, количества активных соединений с БД или длины очереди задач в Celery.

Histogram (Гистограмма) — семплирует наблюдения и распределяет их по заданным корзинам (buckets), параллельно считая сумму и количество. Это критически важный тип для замера задержек (Latency) и размеров батчей.

Пример проектирования метрик для AI Gateway: Для отслеживания эффективности динамического батчинга Sentence Transformers создается гистограмма embedding_batch_size. Корзины настраиваются нелинейно: [1, 2, 4, 8, 16, 32, 64]. Если Prometheus показывает, что 90% наблюдений попадают в корзину le="1" (less or equal), это означает, что батчинг не работает, система обрабатывает запросы по одному, и GPU простаивает.

Для мониторинга генерации текста создается гистограмма llm_ttft_seconds (время до первого токена) с корзинами [0.1, 0.5, 1.0, 2.0, 5.0]. Если Ollama выгружает модель из памяти (Cold Start), значение попадает в корзину le="5.0", что немедленно отражается на графиках.

Аналитика в Grafana: PromQL для ИИ-нагрузок

Grafana выступает визуальным интерфейсом для Prometheus, отправляя запросы на специализированном языке PromQL. В отличие от SQL, PromQL оперирует временными рядами и векторами.

Ключевая функция для работы со счетчиками — rate(). Она вычисляет скорость изменения значения в секунду за указанное окно времени, автоматически сглаживая сбросы счетчиков при перезапуске подов.

Для расчета TPS (Tokens Per Second) конкретной модели используется запрос: sum(rate(llm_generated_tokens_total{model="llama3:8b"}[1m])) Этот запрос берет счетчик токенов, вычисляет скорость его роста за последнюю минуту ([1m]) для каждого воркера, а затем суммирует (sum()) результаты со всех инстансов AI Gateway, выдавая общую пропускную способность кластера.

Оценка задержек требует вычисления перцентилей. Среднее арифметическое время ответа искажается единичными выбросами (например, когда один запрос попал на холодный старт модели). Для объективной оценки используется 95-й перцентиль (P95) — значение времени, в которое укладываются 95% всех запросов.

В PromQL расчет P95 для времени генерации полного ответа выглядит так: histogram_quantile(0.95, sum(rate(llm_request_duration_seconds_bucket[5m])) by (le)) Функция rate вычисляет скорость прироста попаданий в каждую корзину (le) за 5 минут, sum агрегирует данные со всех реплик сервиса, а histogram_quantile аппроксимирует значение 95-го перцентиля внутри корзины математическим интерполированием.

Связывание метрик инфраструктуры с бизнес-логикой позволяет выявлять скрытые узкие места. Например, наложение графика kafka_consumer_lag (количество необработанных сообщений в топике) на график gpu_vram_used_bytes может показать, что очередь начинает расти ровно в тот момент, когда VRAM заполняется на 95%, и Ollama начинает агрессивно использовать Layer Offloading, перенося вычисления на медленный CPU.

Трассировка логики агентов через LangSmith

Если Prometheus показывает наличие проблемы (например, резкий рост ошибок 500 или падение TPS), то LangSmith показывает ее причину.

Фреймворки вроде LangChain и LangGraph генерируют сложные иерархические структуры вызовов. Выполнение одного графа может включать десятки шагов: инициализацию состояния, вызов супервизора, маршрутизацию к агенту-исполнителю, поиск в Qdrant, форматирование промпта и финальную генерацию. Стандартное плоское логирование (через модуль logging) превращает этот процесс в нечитаемую простыню текста, особенно при конкурентной обработке множества запросов.

LangSmith решает эту проблему через концепцию Run Tree (Дерево выполнений). Каждое действие в системе оборачивается в Span (интервал), который имеет тип, время начала, время завершения, входные и выходные данные.

Основные типы Span в LangSmith:

Chain / Graph: логическая группировка операций (например, весь цикл выполнения StateGraph).

LLM: непосредственный вызов языковой модели. Захватывает точный массив messages (включая системный промпт), параметры генерации (temperature, stop) и сырой ответ модели до его парсинга.

Tool: вызов внешнего инструмента (например, выполнение SQL-запроса или парсинг веб-страницы). Захватывает переданные аргументы и результат.

Retriever: обращение к векторной базе. Захватывает исходный текст запроса и массив возвращенных документов с их relevance_score.

Интеграция LangSmith в Python-приложение происходит прозрачно. Достаточно установить переменные окружения LANGCHAIN_TRACING_V2=true и LANGCHAIN_API_KEY. Внутренние механизмы LangChain автоматически начнут перехватывать вызовы и асинхронно отправлять их на сервер трассировки в фоновом потоке, не блокируя Event Loop основного приложения.

Глубокая ценность LangSmith раскрывается при отладке мульти-агентных систем. Рассмотрим топологию Supervisor, где главный агент анализирует вопрос пользователя и решает, передать его агенту-аналитику БД или агенту векторного поиска. Если система выдает некорректный ответ, в LangSmith можно развернуть дерево конкретного запроса и увидеть:

Supervisor принял верное решение и сгенерировал JSON для вызова инструмента route_to_sql_agent.

Вложенный Span SQL Agent получил задачу, но сгенерировал синтаксически неверный SQL-запрос (например, ошибся в названии таблицы).

Span инструмента execute_sql вернул ошибку базы данных.

SQL Agent в следующем цикле попытался исправить ошибку, но галлюцинировал и вернул пустой ответ.

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

Корреляция инфраструктуры и логики

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

Связующим звеном выступают метаданные и теги. При запуске графа (например, через метод ainvoke) в конфигурации передаются кастомные атрибуты:

Эти же trace_id и model_version должны добавляться в качестве лейблов к метрикам Prometheus в FastAPI-приложении.

Если в Grafana настроен алерт на превышение 95-м перцентилем задержки порога в 30 секунд, алерт помимо графика выведет список trace_id, попавших в этот временной интервал. Инженер копирует trace_id, вставляет его в строку поиска LangSmith и мгновенно получает дерево выполнения проблемного запроса.

Анализ дерева может показать, что задержка вызвана не инфраструктурными проблемами Ollama, а логическим зацикливанием: агент 15 раз пытался вызвать инструмент с неверными аргументами, пока не уперся в лимит revision_number. Метрики показали симптом (высокий Latency), а трассировка выявила болезнь (плохой системный промпт инструмента).

Для локальных систем, где стоимость API не измеряется в долларах, LangSmith позволяет отслеживать потребление ресурсов через токены. Анализ распределения токенов по узлам графа часто выявляет архитектурные изъяны. Например, может обнаружиться, что 80% всех сгенерированных токенов (и, следовательно, процессорного времени) тратится на работу внутреннего узла-оценщика (Evaluator), чьи вердикты в 99% случаев игнорируются из-за ошибки в условном ребре графа. Оптимизация таких скрытых потерь высвобождает VRAM и кратно повышает общую пропускную способность кластера.

Безопасность и изоляция: контейнеризация в Kubernetes и защита данных

Атака на корпоративную ИИ-систему редко начинается со взлома серверов. Злоумышленнику достаточно передать агенту специально сформированный текст (Prompt Injection), который заставит модель сгенерировать вредоносный Python-код. Если этот агент имеет доступ к инструменту выполнения кода (REPL), а сам процесс запущен с правами root и имеет выход в интернет, злоумышленник получает полный контроль над контейнером. Отсюда он может просканировать внутреннюю сеть, выгрузить базу данных клиентов или запустить майнер, монополизировав вычислительные ресурсы графических ускорителей (GPU). В архитектуре автономных агентов непредсказуемость заложена в саму природу авторегрессионной генерации, поэтому безопасность строится не на попытках сделать модель «идеально послушной», а на жесткой изоляции среды ее выполнения.

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

Управление GPU: от монополии к аппаратной изоляции

В классических микросервисах процессорное время (CPU) и оперативная память (RAM) легко квотируются средствами ядра Linux (cgroups). Графические ускорители устроены иначе: по умолчанию контейнер, получивший доступ к устройству /dev/nvidia0, может занять всю доступную видеопамять (VRAM), спровоцировав ошибку Out-Of-Memory (OOM) у соседних процессов.

Для интеграции GPU в Kubernetes используется плагин NVIDIA Device Plugin, который позволяет запрашивать ускорители в манифестах подов так же, как CPU. Однако базовый механизм выделяет GPU целиком: если поду Ollama назначен один ускоритель, другой под (например, с моделями Sentence Transformers) не сможет его использовать, даже если Ollama простаивает.

Для решения этой проблемы применяются две стратегии разделения ресурсов:

Time-Slicing (Временное разделение). Программный механизм, при котором несколько подов получают доступ к одному физическому GPU. Планировщик NVIDIA переключает контекст между процессами. Это увеличивает утилизацию оборудования, но не обеспечивает строгой изоляции VRAM. Если агент внезапно получит аномально длинный промпт и размер его KV-кэша превысит свободный остаток VRAM, ядро завершит процесс (OOM Kill), что приведет к падению всех подов, делящих этот ускоритель.

Multi-Instance GPU (MIG). Аппаратная технология (доступна на архитектурах Ampere и новее, например, A100/H100), позволяющая физически разделить один чип на несколько независимых экземпляров (до семи). Каждый MIG-инстанс имеет выделенную пропускную способность шины памяти и изолированный объем VRAM.

Для корпоративных систем с жесткими SLA (Service Level Agreement) применяется MIG. Математика планирования емкости кластера в этом случае опирается на строгие лимиты. Если физический ускоритель имеет 80 ГБ VRAM и разбит на профили по 10 ГБ (профиль 1g.10gb), максимальное количество подов рассчитывается аппаратно:

В Kubernetes такой ресурс запрашивается явно: nvidia.com/mig-1g.10gb: 1. Это гарантирует, что тяжелая аналитическая задача, запущенная на одном агенте, никак не повлияет на задержку (TTFT) соседнего агента, обслуживающего клиентский чат.

Стратегии хранения весов: Persistent Volumes и Init-контейнеры

Жизненный цикл пода в Kubernetes эфемерен: он может быть удален, перемещен на другой узел или перезапущен в любой момент. Если образ контейнера содержит в себе веса модели Llama 3 (около 4.8 ГБ для квантованной версии), размер Docker-образа становится неприемлемо большим. Это приводит к колоссальным задержкам при масштабировании (Cold Start), так как K8s вынужден скачивать гигабайты данных по сети при каждом запуске нового воркера.

Архитектурно правильный подход — разделение исполняемой среды (бинарного файла Ollama или llama.cpp) и состояния (весов моделей). Веса должны храниться на внешнем томе, смонтированном в под.

Для реализации этого паттерна используются Init-контейнеры (Init Containers). Это специализированные контейнеры, которые запускаются и должны успешно завершиться до того, как стартует основной контейнер пода.

Процесс загрузки ИИ-агента выглядит так:

К поду подключается постоянный том (Persistent Volume Claim, PVC) в режиме ReadWriteMany (RWX), если используется сетевая файловая система (например, NFS), или ReadWriteOnce (RWO) для локальных дисков узла.

Стартует Init-контейнер. Его задача — проверить наличие файла llama3-8b.gguf на смонтированном томе.

Если файла нет, Init-контейнер скачивает его из корпоративного S3-хранилища или Hugging Face Hub.

После успешной загрузки Init-контейнер завершается.

Запускается основной контейнер Ollama. Он мгновенно обнаруживает веса на диске и начинает загрузку тензоров в VRAM.

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

Сетевая изоляция: Network Policies и принцип наименьших привилегий

В мульти-агентной системе на базе LangGraph разные узлы графа выполняют разные функции. Супервизор (Supervisor) только маршрутизирует задачи, агент веб-поиска (Web Search Agent) обращается к внешнему интернету, а SQL-агент (SQL Agent) генерирует запросы к корпоративной базе данных PostgreSQL.

По умолчанию в Kubernetes все поды могут свободно обмениваться трафиком друг с другом. Если злоумышленник проведет успешную атаку Prompt Injection на агента веб-поиска, он сможет отправить HTTP-запрос к внутреннему API базы данных или сервису биллинга, минуя внешние системы авторизации.

Для предотвращения латерального движения (Lateral Movement) применяются Network Policies (Сетевые политики). Это правила межсетевого экрана на уровне K8s, которые работают по принципу Default Deny (запрещено все, что не разрешено явно).

Сетевая топология ИИ-приложения должна строиться на следующих правилах:

AI Gateway (FastAPI): Разрешен входящий трафик от Ingress-контроллера. Разрешен исходящий трафик только к подам Супервизора и подам Sentence Transformers (для эмбеддингов).

Supervisor: Разрешен входящий трафик от AI Gateway. Разрешен исходящий трафик к подам конкретных воркеров (SQL Agent, RAG Agent).

SQL Agent: Разрешен входящий трафик от Супервизора. Разрешен исходящий трафик только к поду PostgreSQL по порту 5432. Исходящий трафик в интернет (0.0.0.0/0) жестко блокируется на уровне ядра Linux (через eBPF или iptables, управляемые CNI-плагином).

В этой конфигурации, даже если SQL-агент будет полностью скомпрометирован и злоумышленник получит доступ к консоли (shell), он физически не сможет выгрузить украденные данные на внешний сервер, так как сетевой пакет за пределы кластера будет отброшен.

Защита на уровне ОС: Security Context и Read-Only файловые системы

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

Для ИИ-агентов, особенно тех, что используют инструменты выполнения кода (Python REPL), критически важно применять Security Context (Контекст безопасности). Это набор директив в манифесте пода, определяющих привилегии процессов.

Три обязательных правила для любого LLM-воркера:

runAsNonRoot: true. Процесс должен запускаться от имени непривилегированного пользователя (например, UID 1000). Если уязвимость в llama.cpp или FastAPI позволит выполнить произвольный код, этот код не сможет изменить конфигурацию сети или прочитать сертификаты узла.

allowPrivilegeEscalation: false. Запрещает дочерним процессам получать больше прав, чем имеет родительский (блокирует работу бинарных файлов с флагом SUID, таких как sudo).

readOnlyRootFilesystem: true. Самый мощный инструмент защиты. Вся файловая система контейнера монтируется в режиме "только чтение". Злоумышленник не сможет перезаписать системные утилиты, добавить свой ключ в ~/.ssh/authorized_keys или скачать скрипт в /usr/bin.

Однако агентам часто требуется временное хранилище (например, для сохранения промежуточных CSV-файлов перед их анализом). Для этого в под монтируется emptyDir (временный том, хранящийся в оперативной памяти узла) строго в директорию /tmp, с жестким лимитом объема:

При такой конфигурации атакующая полезная нагрузка, даже будучи успешно сгенерированной моделью, столкнется с Read-Only файловой системой. Попытка сохранить скрипт где-либо, кроме /tmp, завершится ошибкой доступа, а данные в /tmp будут уничтожены при перезапуске пода.

Управление секретами и ServiceAccounts

Локальные LLM устраняют необходимость отправки корпоративных данных во внешние API (например, OpenAI), но сами агенты постоянно взаимодействуют с внутренними системами: базами данных, брокерами сообщений (Kafka), векторными хранилищами (Qdrant). Для этого требуются пароли и токены.

Хранение секретов в переменных окружения прямо в манифестах Deployment — грубое нарушение безопасности. В Kubernetes для этого существует ресурс Secret. Данные в нем хранятся в формате base64 (что является кодированием, а не шифрованием), поэтому на уровне кластера должна быть включена опция Encryption at Rest (Шифрование в состоянии покоя), чтобы файлы базы данных etcd, где K8s хранит свое состояние, были зашифрованы криптографическим ключом.

Секреты должны монтироваться в поды агентов не как переменные окружения, а как файлы в памяти (через volumeMounts), так как переменные окружения могут быть случайно выведены в логи приложения при ошибках трассировки (например, при падении LangChain-пайплайна).

Кроме того, каждому поду Kubernetes по умолчанию монтирует токен доступа к API самого кластера (ServiceAccount token). Если агент скомпрометирован, злоумышленник может использовать этот токен для отправки запросов к K8s API, пытаясь прочитать секреты других компонентов системы. Для ИИ-агентов, которым не нужно управлять инфраструктурой, этот механизм должен быть принудительно отключен директивой automountServiceAccountToken: false.

Guardrails на уровне Ingress и API Gateway

Последний рубеж обороны выстраивается на границе системы, до того как запрос попадет в граф LangGraph. Ingress-контроллер и AI Gateway выполняют роль программных ограждений (Guardrails).

Помимо ограничения частоты запросов (Rate Limiting), защищающего графические ускорители от истощения видеопамяти (DDoS-атак), на этом уровне внедряются легковесные модели классификации промптов. Прежде чем тяжелая модель Llama 3 начнет генерировать ответ, легковесная модель Sentence Transformers (или специализированная модель вроде DeBERTa) векторизует входящий запрос и сравнивает его с базой известных векторов атак (Prompt Injection, Jailbreak).

Если косинусное расстояние между входящим запросом и известным вредоносным паттерном превышает заданный порог, AI Gateway мгновенно блокирует запрос, возвращая HTTP 403 Forbidden. Это экономит драгоценное время инференса GPU и предотвращает попадание токсичного контекста в реляционную историю диалогов, защищая систему от отравления данных (Data Poisoning) в будущих сессиях.

Комплексное применение аппаратной изоляции (MIG), сетевых политик (Network Policies), Read-Only файловых систем и криптографической защиты секретов превращает уязвимую по своей природе вероятностную LLM в предсказуемый и безопасный микросервис, готовый к работе с критичными корпоративными данными.