Развертывание и эксплуатация LLM в локальной инфраструктуре

Архитектура локального AI-сервера и выбор оборудования

Почему компании, которые годами пользовались облачными API, вдруг начинают закупать GPU-серверы и строить собственные инференс-кластеры? Ответ прост: каждый запрос к внешнему провайдеру — это ваши данные на чужом сервере. Для банков, медицинских организаций и госструктур это не вопрос удобства, а вопрос compliance. Но как правильно подобрать оборудование, чтобы не переплатить за ненужную мощность и не упереться в потолок через месяц после запуска?

Три кита локального AI-сервера

Любая LLM-инфраструктура опирается на три ресурса: видеопамять (VRAM), оперативную память (RAM) и скорость дискового ввода-вывода. Именно в этом порядке — VRAM определяет, какую модель вы вообще сможете загрузить, RAM влияет на стабильность при длинных контекстах, а быстрые SSD решают, за сколько секунд модель переместится из хранилища в память.

VRAM — главный ограничивающий фактор. Каждый параметр модели занимает определённое количество памяти. В формате FP16 (16-битные числа с плавающей точкой) один параметр требует 2 байта. Модель на 7 миллиардов параметров потребляет около 14 ГБ VRAM только под веса, плюс overhead на KV Cache и промежуточные вычисления. Квантизация до 4-бит (формат GGUF Q4_K_M) снижает потребление примерно в 4 раза — та же 7B модель займёт около 4–5 ГБ.

RAM нужна как буфер. Когда модель обрабатывает длинный контекст (например, 32 000 токенов), KV Cache растёт линейно. Если VRAM закончится, часть данных переносится в оперативную память — и скорость генерации резко падает. Минимум для серьёзной работы — 64 ГБ, оптимум — 128 ГБ и выше.

Диски влияют на время холодного старта. Модель весом 40 ГБ на медленном HDD будет загружаться минуты, на NVMe SSD — секунды. При частом переключении между моделями это критично.

Выбор GPU: от потребительских до серверных

Видеокарты для LLM делятся на три категории, и выбор зависит от бюджета и задач.

Потребительские карты (NVIDIA RTX 3090, RTX 4090) — точка входа. RTX 4090 с 24 ГБ VRAM стоит около 2 000 долл. и уверенно тянет 7B–13B модели в квантизации. RTX 3090 — более бюджетный вариант с тем же объёмом памяти. Минус: нет серверных функций (ECC-память, NVLink), драйверы оптимизированы под гейминг, а не под инференс.

Серверные карты среднего звена (NVIDIA L40S с 48 ГБ, A10G с 24 ГБ) — хороший баланс цены и возможностей. L40S за ~7 000 долл. даёт вдвое больше VRAM, чем RTX 4090, и поддерживает серверные фичи. Подходит для 70B моделей в 4-битной квантизации.

Флагманские серверные карты (NVIDIA A100 на 40/80 ГБ, H100 на 80 ГБ) — золотой стандарт для продакшена. A100 80 ГБ (~15 000 долл.) позволяет запускать 70B модели в FP16 или даже 405B в агрессивной квантизации. H100 быстрее в 2–3 раза благодаря архитектуре Hopper, но стоит от 25 000 долл.

| Карта | VRAM | Цена (ориент.) | Модели, которые потянет | |---|---|---|---| | RTX 4090 | 24 ГБ | ~2 000 долл. | 7B–13B (Q4), 70B (Q2, медленно) | | NVIDIA L40S | 48 ГБ | ~7 000 долл. | 70B (Q4), Mixtral 8x7B | | NVIDIA A100 80GB | 80 ГБ | ~15 000 долл. | 70B (FP16), 405B (Q4) | | NVIDIA H100 80GB | 80 ГБ | ~25 000 долл. | То же, но в 2–3 раза быстрее |

Мульти-GPU и масштабирование

Одна карта — это пилот. Для реальной нагрузки нужны несколько GPU. Два подхода к распараллеливанию:

Tensor Parallelism — модель разрезается по слоям между GPU. Каждая карта обрабатывает часть вычислений, результаты агрегируются. Требует быструю меж-GPU связь (NVLink или PCIe 4.0). Минимум — две одинаковые карты.

Pipeline Parallelism — модель разбивается на стадии: первые слои на одном GPU, последние — на другом. Проще в реализации, но появляется «пузырь» простоя, пока данные передаются между картами.

Для 70B модели в Q4 квантизации (~40 ГБ) хватит одной A100 80 ГБ. Для FP16 версии (~140 ГБ) потребуются минимум две A100 80 ГБ с NVLink. Для 405B модели — четыре–восемь карт.

Процессор, RAM и диски: вторичные, но важные

CPU не участвует в основном инференсе при наличии GPU, но важен для препроцессинга токенов, управления памятью и работы RAG-пайплайна. Современный серверный процессор (Intel Xeon 4-го поколения или AMD EPYC 9004) с 16–32 ядрами — оптимальный выбор. Если GPU нет вообще, CPU-инференс через llama.cpp даёт 5–10 токенов в секунду на 7B модели — медленно, но для batch-задач подходит.

RAM — правило «вдвое больше, чем VRAM». Если у вас 48 ГБ VRAM, ставьте минимум 96 ГБ RAM. Для мульти-GPU конфигураций — 256 ГБ и выше.

Диски — NVMe SSD объёмом от 1 ТБ. Модели в формате GGUF весят от 4 ГБ (7B Q4) до 200+ ГБ (405B FP16). Если планируете хранить несколько версий моделей — закладывайте 2–4 ТБ.

Типовые конфигурации для разных сценариев

Стартовая (до 5 000 запросов в день). Один RTX 4090, 64 ГБ RAM, NVMe 1 ТБ. Модель: Llama 3.1 8B Q4_K_M. Бюджет: ~5 000 долл. Подходит для пилота и внутренних экспериментов.

Средняя (5 000–50 000 запросов в день). Две L40S, 128 ГБ RAM, NVMe 2 ТБ. Модель: Llama 3.1 70B Q4_K_M. Бюджет: ~20 000 долл. Закрывает большинство корпоративных задач.

Масштабная (50 000+ запросов в день). Четыре A100 80 ГБ, 512 ГБ RAM, NVMe 4 ТБ. Модель: Llama 3.1 70B FP16 или 405B Q4. Бюджет: ~80 000+ долл. Для высоконагруженных продакшн-систем.

Типичные ошибки при выборе оборудования

Самая частая ошибка — покупка GPU «на вырост» без расчёта точки окупаемости. Если нагрузка составляет 1 000 запросов в день, A100 будет простаивать, а облачный API обошёлся бы дешевле. Формула простая: если стоимость API за месяц превышает амортизацию сервера (цена оборудования / срок службы в месяцах) плюс электричество и размещение — self-hosted выгоден.

Вторая ошибка — экономия на охлаждении. GPU под нагрузкой выделяют 300–700 Вт тепла каждая. В серверной без кондиционирования карты уйдут в троттлинг при 85°C, и производительность упадёт на 30–50%.

Третья — игнорирование пропускной способности шины. При мульти-GPU конфигурации PCIe 3.0 вместо PCIe 4.0 или отсутствие NVLink создаст узкое место при передаче данных между картами.

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

Развертывание и оптимизация LLM с использованием Ollama и GGUF

Представьте: вы купили сервер, установили драйверы, и теперь перед вами голая машина без единой запущенной модели. Как превратить этот кусок железа в работающий AI-сервис за вечер, а не за неделю? Инструментов десятки, но для системного администратора, который не хочет погружаться в Python-зависимости и компиляцию из исходников, есть два проверенных пути: Ollama для быстрого старта и GGUF-формат для максимальной оптимизации ресурсов.

Ollama: три команды до работающей модели

Ollama — это обёртка над движком llama.cpp с удобным CLI и встроенным REST API. Её философия: «скачал, запусти, работает». На Linux установка занимает одну строку:

После установки запуск модели — ещё одна команда:

Ollama автоматически скачает модель из своего реестра, определит доступные GPU и запустит инференс. Если CUDA-драйверы установлены — модель пойдёт на GPU. Если нет — отработает на CPU.

Но настоящая сила Ollama — в REST API, который стартует на порту 11434 по умолчанию. Любой запрос к http://localhost:11434/api/generate или http://localhost:11434/api/chat возвращает ответ модели в формате JSON. Это значит, что Ollama можно интегрировать с любым внутренним приложением — от корпоративного портала до системы мониторинга — без дополнительных обвязок.

Формат GGUF: почему он стал стандартом

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

Ключевое преимущество GGUF — квантизация. Вместо хранения каждого веса модели в 16-битном формате (FP16), GGUF позволяет сжимать их до 4, 5 или 8 бит. Это не просто уменьшение размера файла — это прямая экономия VRAM и ускорение вычислений, потому что GPU обрабатывает меньший объём данных за такт.

Уровни квантизации в GGUF обозначаются кодами вида Q4_K_M, Q5_K_M, Q8_0. Расшифровка:

Практический пример: модель Llama 3.1 8B в формате FP16 весит ~16 ГБ. В Q4_K_M — ~4,9 ГБ. Разница в три раза позволяет запустить её на RTX 4090 с запасом памяти на KV Cache, тогда как FP16 версия займёт почти всю VRAM карты.

Настройка Ollama для продакшн-режима

Базовая установка Ollama — это старт. Для реальной эксплуатации нужно несколько дополнительных шагов.

Управление моделями. Ollama хранит модели в каталоге ~/.ollama/models. Список загруженных моделей:

Удаление ненужной модели:

Создание кастомных моделей. Ollama поддерживает файлы Modelfile — аналог Dockerfile для моделей. Вы можете задать системный промпт, параметры генерации и даже добавить свои данные:

Сборка кастомной модели:

Настройка GPU. По умолчанию Ollama использует все доступные GPU. Для тонкой настройки — переменные окружения:

Параметр OLLAMA_NUM_GPU_LAYERS управляет тем, сколько слоёв трансформера обрабатывается на GPU, а сколько — на CPU. Если VRAM не хватает для всей модели, часть слоёв переносится на процессор. Это замедляет генерацию, но позволяет запустить модель, которая иначе не поместилась бы в память.

Ollama против других инструментов

Ollama — не единственный вариант. Важно понимать, когда он лучше, а когда стоит выбрать альтернативу.

Ollama vs llama.cpp напрямую. llama.cpp даёт больше контроля: ручная компиляция под конкретное железо, тонкая настройка параметров инференса, поддержка экзотических форматов. Но требует работы с командной строкой и понимания внутренностей. Ollama берёт на себя эту сложность ценой некоторой гибкости.

Ollama vs vLLM. vLLM — инструмент для высоконагруженного продакшена. Он использует PagedAttention — механизм эффективного управления KV Cache, который позволяет обслуживать десятки параллельных запросов без фрагментации памяти. Ollama заточена под одиночные или малопараллельные запросы. Если у вас 50+ одновременных пользователей — vLLM будет значительно эффективнее.

Ollama vs LM Studio. LM Studio — десктопное приложение с графическим интерфейсом, которое тоже использует llama.cpp под капотом. Удобно для экспериментов и демонстраций, но для серверного развёртывания headless-режим Ollama практичнее.

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

После развёртывания модели наступает этап оптимизации. Четыре параметра, которые дают наибольший эффект:

Размер контекста (num_ctx). По умолчанию — 2 048 токенов. Увеличение до 4 096 или 8 192 позволяет модели «помнить» больше текста, но линейно увеличивает потребление памяти. Не ставьте больше, чем реально нужно для ваших задач.

Температура (temperature). Контролирует случайность генерации. Для технических ответов — 0.1–0.3 (детерминированность). Для творческих задач — 0.7–1.0.

Количество предиктов (num_predict). Максимальная длина ответа в токенах. Ограничьте, чтобы длинные генерации не блокировали GPU.

Потоковая передача (stream). В API-режиме включение потоковой передачи ("stream": true) отдаёт ответ по мере генерации — пользователь видит текст сразу, а не ждёт полного завершения.

Мониторинг после развёртывания

Ollama не имеет встроенного мониторинга, но его API позволяет собирать метрики. Ключевые показатели:

Для систематического мониторинга оберните Ollama в скрипт, который каждые 10 секунд снимает показания nvidia-smi и пишет их в лог-файл или отправляет в Prometheus.

Ollama и GGUF — это связка, которая позволяет системному администратору без опыта в ML развернуть работающую LLM за вечер. Но для масштабирования на десятки тысяч запросов в день потребуется более серьёзный стек — и к нему мы перейдём в следующих статьях.

Создание корпоративной базы знаний на основе RAG

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

Как работает RAG простыми словами

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

Технически процесс делится на три этапа:

Ключевое отличие от fine-tuning: модель не меняется. Вы не дообучаете её на своих данных — вы просто даёте ей нужные материалы «в руки» при каждом запросе. Это быстрее, дешевле и безопаснее.

Шаг 1: Подготовка и разбиение документов

Корпоративная документация бывает разной: PDF-инструкции, Word-регламенты, Markdown-вики, CSV-таблицы, HTML-страницы внутреннего портала. Всё это нужно привести к единому текстовому формату и разбить на фрагменты.

Разбиение на чанки — самый недооценённый этап. От него зависит 80% качества RAG-системы. Слишком большие чанки (3 000+ токенов) содержат много «шума», и модель может пропустить нужную деталь. Слишком маленькие (100–200 токенов) теряют контекст — фраза «заменить фильтр» без указания, какой именно фильтр и в каком оборудовании, бесполезна.

Оптимальный размер чанка — 300–800 токенов с перекрытием (overlap) в 50–100 токенов. Перекрытие нужно, чтобы смысл не обрывался на границе чанков: если важное предложение оказалось на стыке двух фрагментов, overlap гарантирует, что оно попадёт в оба.

Практический инструмент для разбиения — библиотека LangChain с классом RecursiveCharacterTextSplitter:

Для PDF-документов с таблицами и изображениями используйте Unstructured или LlamaParse — они извлекают структуру, а не просто читают текст.

Шаг 2: Создание эмбеддингов и векторная база

Каждый чанк нужно превратить в вектор — числовое представление смысла. Для этого используется эмбеддинг-модель — отдельная небольшая нейросеть, которая переводит текст в вектор фиксированной размерности (обычно 384, 768 или 1 024 числа).

Популярные эмбеддинг-модели для локального развёртывания:

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

Пример индексации чанков в Chroma:

Шаг 3: Поиск и генерация ответа

Когда пользователь задаёт вопрос, система выполняет поиск по векторной базе и передаёт найденные фрагменты в LLM.

Параметр n_results=5 означает, что система подаёт модели пять наиболее релевантных фрагментов. Увеличение этого числа даёт больше контекста, но увеличивает промпт и замедляет генерацию.

Типичные ошибки при построении RAG

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

Ошибка 2: один размер чанка для всех документов. Технический паспорт оборудования и корпоративный регламент — документы разной структуры. Для таблиц лучше маленькие чанки, для текстов — покрупнее. Настраивайте разбиение под тип документа.

Ошибка 3: отсутствие оценки качества. Без метрик вы не узнаете, работает ли RAG. Соберите golden set — 20–50 пар «вопрос — правильный ответ» из вашей документации. Прогоняйте его после каждого изменения настроек и замеряйте точность.

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

Инструменты для сборки RAG-пайплайна

Для оркестрации всего процесса — от загрузки документов до генерации ответа — используют фреймворки:

Для GUI-обёртки поверх RAG используйте Open WebUI — веб-интерфейс с поддержкой загрузки документов и чата по ним. Он интегрируется с Ollama и позволяет пользователям без технических навыков взаимодействовать с корпоративной базой знаний через привычный чат.

RAG — это не магия, а инженерная задача. Качество зависит не от размера модели, а от качества подготовки документов, настройки поиска и правильного формирования промпта. Именно поэтому в следующей статье мы разберём, как интегрировать RAG-систему с автоматизацией технической поддержки через API.

Автоматизация технической поддержки и интеграция API

Сотрудник пишет в чат: «Не работает принтер на 3 этаже, кабинет 312». Раньше это падало в тикет-систему, ждало очереди и обрабатывалось живым специалистом через 20–40 минут. А если бы AI-ассистент мгновенно нашёл в базе знаний инструкцию по сбросу этого принтера, проверил статус оборудования через мониторинг и выдал пошаговое решение — или эскалировал на инженера, если проблема аппаратная? Именно так работает автоматизация техподдержки на базе локальной LLM, и для её запуска не нужен интернет — только внутренний API и ваша документация.

Архитектура автоматизированной техподдержки

Система состоит из четырёх компонентов, связанных через API-интерфейс:

Ключевой элемент — единый API-интерфейс между всеми компонентами. Ollama предоставляет REST API на порту 11434, vLLM — OpenAI-совместимый API. Это позволяет менять движок инференса без переписывания интеграций.

Настройка API-интерфейса Ollama для интеграций

Ollama API работает по протоколу HTTP и принимает JSON-запросы. Для интеграции с внутренними системами используются два эндпоинта:

Chat API — для диалоговых взаимодействий:

Generate API — для одиночных запросов без контекста диалога:

Для Python-интеграций библиотека ollama предоставляет нативный клиент:

Построение пайплайна обработки обращения

Разберём полный цикл обработки типового обращения на примере Python-сервиса на FastAPI:

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

Интеграция с тикет-системой

Для связи с Jira, Zammad или другой тикет-системой используется их REST API. Пример создания тикета в Jira при эскалации:

Логика эскалации проста: если AI не уверен в ответе (низкий score при поиске в RAG) или категория требует физического вмешательства — создаётся тикет. Если ответ найден с высокой уверенностью — пользователь получает его мгновенно.

OpenAI-совместимый API и переход между движками

Одно из преимуществ локального стека — взаимозаменяемость движков. И Ollama, и vLLM, и LM Studio могут предоставлять API в формате, совместимом с OpenAI. Это значит, что ваш код интеграции не привязан к конкретному инструменту.

vLLM запускается как OpenAI-совместимый сервер:

После этого любой код, написанный для OpenAI API, работает с локальной моделью — достаточно поменять base_url:

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

Обработка ошибок и отказоустойчивость

Локальная LLM может «упасть» — закончилась VRAM, сбой драйвера, перегрев GPU. Интеграционный слой должен это обрабатывать:

Таймауты. Устанавливайте таймаут на каждый запрос к LLM (например, 30 секунд). Если модель не ответила — возвращайте стандартное сообщение и эскалируйте на живого оператора.

Очередь запросов. При пиковых нагрузках запросы должны ставиться в очередь, а не отбрасываться. Ollama обрабатывает запросы последовательно — при параллельных обращениях они ждут своей очереди. vLLM поддерживает continuous batching и эффективнее работает с параллельными запросами.

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

Метрики эффективности автоматизации

После запуска замеряйте:

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

Безопасность, мониторинг и управление ресурсами в закрытой сети

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

Сетевая изоляция: закрытый контур на практике

Главное преимущество локального развёртывания — данные не покидают периметр компании. Но это преимущество обнуляется, если сам AI-сервер доступен извне или находится в одной плоской сети с пользовательскими машинами.

Физическая и логическая сегментация. AI-сервер должен располагаться в отдельном VLAN, недоступном напрямую из пользовательской сети. Доступ к API — только через reverse proxy (Nginx, Traefik) с принудительной аутентификацией. Все остальные порты, кроме API-эндпоинта, закрыты на файрволе.

Типичная схема изоляции:

Между VLAN работают правила файрвола: из VLAN 10 во VLAN 20 — только HTTPS на порт 443 (через reverse proxy), обратный трафик — запрещён. Из VLAN 30 во VLAN 20 — SSH и метрические порты. Из VLAN 20 в интернет — полностью закрыт, если модель не требует обновлений извне.

Отключение внешнего доступа. Если модель развёрнута и работает, внешний интернет серверу не нужен. Физически отключите WAN-интерфейс или настройте iptables/nftables так, чтобы все исходящие соединения блокировались по умолчанию. Исключение — только если вы используете автоматическое обновление моделей из реестра (например, ollama pull), но и тогда лучше загружать модели на отдельной машине и переносить их по внутренней сети.

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

Аутентификация и авторизация API

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

Reverse proxy с Basic Auth или mTLS. Самый простой способ — закрыть Ollama за Nginx с базовой аутентификацией:

``nginx server { listen 443 ssl; server_name ai.internal.company.ru;

ssl_certificate /etc/ssl/certs/ai.pem; ssl_certificate_key /etc/ssl/private/ai.key;

location / { auth_basic "AI API"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://localhost:11434; proxy_set_header Host > 80°C> 85°C> 90\%> 20> 5> 1\%< 10\%$ более 10 минут — модель не используется или упала

Алерты направляйте в корпоративный мессенджер (Telegram, Slack, Mattermost) и в тикет-систему. Критические алерты (падение модели, OOM) — с эскалацией на дежурного инженера.

Управление ресурсами: лимиты и квоты

Без лимитов один пользователь или скрипт может монополизировать GPU, вытеснив все остальные запросы. Управление ресурсами строится на трёх уровнях.

Лимиты на длину генерации. Ограничьте максимальное количество токенов в ответе (num_predict в Ollama, max_tokens в API). Для технической поддержки обычно достаточно 512–1024 токенов. Без лимита пользователь может запросить генерацию на 32 000 токенов и заблокировать GPU на несколько минут.

Rate limiting на уровне API-шлюза. Ограничьте количество запросов в минуту от одного пользователя или приложения. Например, 10 запросов в минуту на пользователя. Реализуется в Nginx (limit_req_zone), Kong или на уровне FastAPI-сервиса.

Квоты на потребление токенов. Для каждого пользователя или сервиса установите месячную квоту (например, 100 000 токенов). При превышении — запросы отклоняются или ставятся в низкоприоритетную очередь. Это защищает от случайного или намеренного исчерпания ресурсов.

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

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

Хранение версий. Каждая модель хранится с версией в имени файла: llama3.1-8b-q4km-v2.gguf`. При обновлении старая версия не удаляется, а архивируется. Это даёт возможность быстрого отката.

Тестирование перед продакшеном. Новая версия модели сначала загружается на тестовый контур (отдельный GPU или CPU-режим), прогоняется через golden set — набор эталонных запросов с ожидаемыми ответами. Если метрики качества и производительности удовлетворительны — модель выходит в продакшен.

Canary deployment. При обновлении направляйте 5–10% трафика на новую версию, остальные 90% — на старую. Сравнивайте TPS, TTFT, error rate и качество ответов. Если за 24 часа аномалий нет — переключайте 100% трафика.

Регулярный аудит качества. Даже без обновления модели качество может деградировать — из-за изменений в промптах, RAG-индексе или формате входных данных. Раз в месяц прогоняйте golden set и сравнивайте с baseline.

Защита данных на уровне модели

Даже в закрытом контуре есть риски утечки через саму модель.

Prompt injection. Пользователь может попытаться через промпт заставить модель раскрыть системные инструкции, содержимое других документов или внутренние настройки. Защита — фильтрация входных запросов на уровне API-шлюза и ограничение контекста, который модель видит при каждом запросе.

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

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

Типичные ошибки эксплуатации

Ошибка 1: мониторинг только «жив/мёртв». Проверка, что процесс запущен, не говорит о качестве работы. Модель может генерировать ерунду, отвечать за 30 секунд или работать при 92°C — и формально быть «живой». Мониторьте TPS, TTFT, температуру и VRAM.

Ошибка 2: игнорирование логов. Логи inference-сервера содержат предупреждения о нехватке памяти, некорректных токенах, проблемах с драйверами. Регулярно просматривайте их или настройте автоматический анализ.

Ошибка 3: отсутствие плана восстановления. Что делать, если GPU вышла из строя? Если диск с моделью повреждён? Если сервер перезагрузился? Заранее подготовьте runbook — пошаговую инструкцию по восстановлению сервиса. Храните бэкапы моделей на отдельном носителе.

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

Локальная LLM в закрытой сети — это не просто «поставил и забыл». Это инфраструктура, которая требует такого же внимания, как база данных или почтовый сервер. Безопасность — чтобы данные не утекли. Мониторинг — чтобы знать, что происходит. Управление ресурсами — чтобы система не падала под нагрузкой. Три кита, на которых держится стабильная эксплуатация.