Несколько месяцев назад я решил, что хватит гонять чувствительные запросы через OpenAI. Не потому что параноик — просто часть задач касалась внутренних данных, и платить за каждый токен при этом как-то не хотелось. Думал: разверну за выходные, делов-то. Вышло три вечера, одна перезагрузка сервера и два часа чтения документации, которую я поначалу благополучно проигнорировал.
Вот что я понял по итогу — и что бы я сделал иначе, начни заново.
Железо решает всё, и лучше понять это заранее
Первая ошибка — я недооценил требования к памяти. Взял Mistral 7B, подумал: семь миллиардов параметров, звучит скромно. На деле в полной точности fp16 это около 14 ГБ только под веса. Плюс контекст, плюс накладные расходы — и сервер с 16 ГБ RAM просто отказывался её нормально запускать.
Рабочее правило, которое я вывел: умножай количество параметров на 2 — получаешь примерный объём VRAM в гигабайтах для fp16. Для 4-битного квантования дели на четыре. Та же 7B в 4-bit занимает около 4 ГБ — влезает на недорогую карту или вообще тянется на CPU, пусть и медленно.
Если GPU нет совсем — не страшно. Но готовься к тому, что ответ на простой вопрос будет идти 20–40 секунд. Для пакетной обработки терпимо, для живого диалога — уже мучение.
Ollama: то, с чего я советую начинать
Я начинал с llama.cpp напрямую. Это было... образовательно. Компиляция под конкретное железо, флаги, разные бэкенды. Работает, но это явно не то, чем хочется заниматься, когда нужен просто рабочий инструмент.
Ollama сделал всё это скучным — в хорошем смысле. Ставится одной командой, модели скачиваются через ollama pull, сервер поднимается автоматически и сразу отдаёт REST API на порту 11434.
curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3
ollama serve
После этого у тебя есть endpoint http://localhost:11434/api/generate, который понимает JSON. Никакого Python-окружения с конфликтующими зависимостями, никакой магии.
Ollama проигрывает в одном — тонкая настройка под высокую нагрузку в продакшне. Там уже смотришь в сторону vLLM. Но об этом чуть позже.
Квантование: как не потерять много, сэкономив прилично
Суть простая: веса модели сжимают с 16-битных чисел до 4-битных или 8-битных. Теряется немного точности, выигрывается вдвое-вчетверо по памяти.
Я сравнивал ответы Mistral 7B в fp16 и Q4_K_M — разница на большинстве задач была на уровне шума. Код, суммаризация, Q&A по документам — не заметно. Тонкие рассуждения или математика — заметнее, но для большинства рабочих задач несущественно.
Форматы GGUF, которые используют llama.cpp и Ollama — это и есть квантованные версии. На Hugging Face у каждой популярной модели найдёшь репозитории вроде TheBloke/Mistral-7B-Instruct-v0.2-GGUF с файлами Q4_K_M, Q5_K_S, Q8_0. Чем выше цифра — тем точнее и тем тяжелее.
Я остановился на Q5_K_M: памяти нужно разумно, качество хорошее.
vLLM для тех, кому нужна настоящая нагрузка
Как только задача — держать несколько запросов одновременно, Ollama начинает проседать. Он обрабатывает запросы последовательно, и при нескольких пользователях очередь растёт линейно.
vLLM решает это через PagedAttention — механизм, который эффективно делит GPU-память между параллельными запросами. На одной A100 можно держать десятки конкурентных запросов без заметной просадки по латентности.
Поднимается через Docker:
docker run --gpus all \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-p 8000:8000 \
vllm/vllm-openai:latest \
--model mistralai/Mistral-7B-Instruct-v0.2
Дело в том что vLLM отдаёт API, совместимый с OpenAI. Любой код, который работает с openai Python-библиотекой, переключается на локальный сервер простой заменой base_url на http://localhost:8000/v1. Я переключил несколько своих скриптов за пять минут.
Что я настроил бы сразу, а не потом
До нескольких вещей я дошёл с задержкой — лучше бы сделал их с самого начала.
Systemd-юнит. Когда сервер перезагружается, Ollama нужно поднимать автоматически. Установщик делает это сам, но если разворачиваешь вручную — не забудь.
Обратный прокси с аутентификацией. По умолчанию API открыт голым на порту. Если сервер публичный — nginx с basic auth или API-ключом в заголовке, иначе любой желающий погенерирует текст за счёт твоего электричества.
Мониторинг температуры GPU. Звучит параноидально, но при долгой генерации GPU реально греется. На первой неделе у меня срабатывал троттлинг — обнаружил это только когда заметил, что ответы стали приходить вдвое медленнее после часа работы. nvidia-smi -l 1 в фоне решил вопрос с диагностикой.
Размер контекста под задачу. Ollama по умолчанию ставит 2048 токенов. Для чата хватает, для работы с длинными документами — нет. Можно переопределить через OLLAMA_NUM_CTX, но большой контекст требует больше памяти под KV-cache.
Стоило ли оно того
Смотря для чего. Там, где данные нельзя отправлять наружу — однозначно да. Для экспериментов с тонкой настройкой моделей — тоже. А вот чтобы просто сэкономить на API при небольших объёмах — считай внимательно: электричество и амортизация железа иногда дороже, чем двадцать долларов в месяц на OpenAI.
Но есть кое-что, чего я не ожидал. Локальный сервер даёт другое ощущение от работы — нет лимитов на запросы, нет задержки сети, нет зависимости от того, упал ли OpenAI этой ночью. Просто работает, пока работает железо. Для меня это оказалось ценнее, чем я думал.
