Зачем нужен мониторинг локальных моделей: постановка задачи
Каждый запуск локальной LLM генерирует десятки метрик, которые исчезают сразу после закрытия терминала. Вы платите электричеством, временем и износом оборудования, но не знаете, на что именно уходят ресурсы. За месяц непрерывного трекинга через JSON-логгер мы собрали 14 200 запросов к локальным моделям и 1 840 обращений к облачным API. Цифры показали: 60% токенов генерируется для хобби-проектов, а пиковая нагрузка на GPU приходится на 23:00–02:00.
Задача этого эксперимента - превратить «чёрный ящик» использования AI в прозрачную систему с измеряемыми показателями. Без метрик невозможно ответить на вопросы: окупает ли RTX 4090 своё энергопотребление, когда выгоднее отправить запрос в OpenRouter, и почему модель на 70B параметров иногда отвечает медленнее, чем на 8B. Статья даёт методологию сбора таких данных, анализ паттернов за месяц и практические выводы для оптимизации вашего AI-стека.
Проблема шире, чем кажется. Информационный хаос в AI-сфере заставляет метаться между десятками моделей и сервисов без понимания реальной эффективности каждого. ML-инженеры тратят до 10 часов в неделю на мониторинг AI-новостей, но 80% - информационный шум. Аналогичная ситуация с использованием моделей: без системного трекинга вы опираетесь на впечатления, а не на данные.
Методология сбора данных: JSON-логгер как основа трекинга
Ядро системы - Python-скрипт, который перехватывает запросы к локальному API и пишет структурированные JSON-записи. Логгер работает как middleware между клиентом и бэкендом инференса: Ollama, llama.cpp, LM Studio. Каждая запись содержит временную метку, идентификатор модели, полный промпт, количество токенов входа и выхода, время до первого токена, полное время генерации, tk/s, объём использованной памяти и тег категории.
{
"timestamp": "2026-07-15T23:14:02.341Z",
"model": "qwen3.6-70b-q4_k_m",
"backend": "ollama",
"prompt_tokens": 1240,
"completion_tokens": 856,
"time_to_first_token_ms": 340,
"total_time_ms": 12400,
"tokens_per_second": 69.0,
"gpu_memory_mb": 18400,
"category": "work",
"task_type": "code_generation"
}Интеграция с Ollama потребовала обёртки над /api/generate. Вместо прямых вызовов клиент отправляет запрос через прокси, который замерами оборачивает стриминговый ответ. Для llama.cpp логика аналогична: логгер парсит вывод с флагом --log-format json. За месяц накопилось 2.3 ГБ сырых логов - объём, который уже требует ротации и агрегации.
Выбор метрик продиктован практикой. Tk/s - интегральный показатель скорости, чувствительный к размеру контекста и квантизации. Время до первого токена критично для интерактивных сценариев. Использование GPU-памяти определяет, влезет ли модель в VRAM или уйдёт в swap. Отдельно фиксировался флаг fallback_on_cloud - когда запрос после локальной попытки перенаправлялся в облако.
Аналогичный подход к логированию метрик используется в production-системах. MLflow решает проблему хаоса в ML-экспериментах через централизованное логирование параметров, метрик и артефактов. Для персонального мониторинга LLM достаточно облегчённой версии той же идеи.
Какие метрики действительно важны и как их интерпретировать
Три метрики дают 90% полезной информации. Первая - tk/s в привязке к длине контекста. На графике зависимости виден переломный момент: после 8K токенов контекста скорость падает экспоненциально из-за квадратичной сложности attention. Для qwen3.6-70b падение с 70 tk/s на 2K до 12 tk/s на 32K. Это означает, что длинные диалоги без summarization убивают производительность.
Вторая метрика - time to first token. Для стриминговых ответов этот показатель важнее общего времени генерации. Пользователь ждёт начала ответа, а не его завершения. На MacBook M2 Max с 32 ГБ RAM время до первого токена для модели 8B составляет 180 мс, для 70B - 3.4 секунды. Разница в 19 раз определяет, какую модель использовать для чата в реальном времени.
Третья - коэффициент fallback_on_cloud. За месяц 13% запросов ушли в облако после таймаута локального инференса. Из них 70% - задачи с контекстом больше 16K токенов. Вывод: локальные модели на пользовательском железе проигрывают длинный контекст облачным API.
Интерпретация tk/s зависит от задачи. Для кодогенерации 30 tk/s - комфортный минимум, ниже начинается заметная задержка. Для batch-обработки документов допустимо 5 tk/s, если процесс фоновый. Показатель ниже 1 tk/s означает, что модель не пригодна для практического использования - это уровень Colibri с GLM-5.2 на MacBook.
Потенциальные проблемы с точностью метрик и восстановление данных
Фоновые процессы искажают замеры tk/s сильнее, чем ожидалось. Антивирусная проверка файла логов в момент генерации добавляла 15–20% к времени ответа. Обновление индексов Spotlight на macOS отъедало 8–12% GPU-памяти, вызывая swapping для моделей на границе VRAM. Решение: изоляция замеров - запуск инференса с приоритетом реального времени и отключение фоновых задач на время бенчмарков.
Потеря данных случалась трижды за месяц. Два раза из-за переполнения буфера логгера при пиковой нагрузке в 60 одновременных запросов. Один раз из-за отключения питания. Восстановление шло через парсинг системных логов Ollama и повторные замеры на идентичных промптах. Расхождение восстановленных данных с оригинальными - 3–5% по tk/s, что приемлемо для агрегированной аналитики.
Выбросы фильтровались по правилу трёх сигм внутри каждой категории задач. Запросы с tk/s, отличающимся от медианы категории более чем на 3 стандартных отклонения, помечались как аномальные и анализировались отдельно. 80% выбросов объяснялись OOM-событиями, когда модель частично уходила в swap.
Проблема достоверности метрик касается и индустриальных бенчмарков. Скандал с бенчмарками Laguna показал, что даже опубликованные метрики могут опираться на нерабочие шаблоны и ошибки в скриптах оценки. Собственный трекинг - единственный способ получить данные, которым вы можете доверять.
Аналитика за месяц: паттерны использования и неожиданные находки
Распределение запросов по времени суток выявило три пика: 10:00–11:30 (рабочие задачи), 15:00–16:00 (второй рабочий всплеск) и 23:00–02:00 (хобби-проекты). Ночной пик по объёму токенов превосходит дневной на 40%. Это объясняется запуском длинных batch-задач: рефакторинг кода, анализ логов, генерация документации. Днём преобладают короткие интерактивные запросы.
По дням недели вторник и среда - самые продуктивные: 65% всех рабочих токенов. Суббота - день хобби: 80% запросов с тегом «personal». Воскресенье - провал до 15% от среднего дневного объёма. Эти данные полезны для планирования обслуживания: обновление моделей и драйверов логично ставить на воскресное утро.
Статистика по моделям оказалась контринтуитивной. qwen3.6-70b использовалась в 45% запросов, но сгенерировала только 28% токенов - модель брали для коротких точных ответов. gemma-4-9b, наоборот, в 20% запросов дала 38% токенов: её грузили длинными задачами summarization. Средняя длина промпта для 70B - 340 токенов, для 9B - 2100 токенов. Пользователь интуитивно делегирует большие контексты более лёгким моделям, экономя VRAM.
Паттерны переключения между локальным инференсом и облачными сервисами
Триггеры переключения на облако чётко классифицируются. Первый - длина контекста больше 16K токенов. Локальные модели на GPU с 24 ГБ VRAM теряют производительность из-за квадратичного attention, тогда как GPT-5.5 через OpenRouter держит 50 tk/s на 32K контексте. Второй триггер - задача требует знаний после даты отсечки локальной модели. Третий - время ответа локальной модели превышает 15 секунд, и пользователь отменяет запрос, перенаправляя его в облако.
Количественно: 13% всех запросов ушли в облако. Из них 8% - осознанный выбор пользователя, 5% - автоматический fallback после таймаута. Среднее время ответа облака - 2.1 секунды, локальной модели - 8.7 секунды. Разница в 4 раза стабильно воспроизводится на задачах средней сложности.
Экономика не в пользу облака для высоконагруженных сценариев. Стоимость 1 миллиона токенов через OpenRouter на GPT-5.5 - $15. Локальный инференс на RTX 4090 при энергопотреблении 350 Вт и цене электричества 5 руб/кВт·ч даёт $0.03 за эквивалентный объём. Разница в 500 раз окупает железо за 8 месяцев непрерывной работы. Для эпизодического использования облако выгоднее: нет upfront-инвестиций в GPU.
Гибридный подход, который сложился естественным путём: короткие запросы и кодогенерация - локально, длинный контекст и сложный reasoning - облако. Это совпадает с выводами из тестирования локального инференса на Mac mini. Практический тест Mac mini M4 Pro с 48 ГБ памяти подтверждает: для AI-агентов с частыми короткими вызовами локальный инференс достаточен, но сложные многошаговые задачи требуют облачных ресурсов.
Балансировка рабочих и хобби-проектов: как AI распределяет наше время
Классификация запросов по тегам «work» и «personal» дала неожиданное распределение: 60% всех сгенерированных токенов пришлось на хобби-проекты. При этом по количеству запросов работа лидирует - 55% против 45%. Разрыв объясняется характером задач: хобби-проекты включают генерацию длинных текстов, игровых сценариев, музыки, тогда как рабочие запросы - короткие code review, переводы, фактчекинг.
Временной паттерн: рабочие запросы сконцентрированы в интервалах 10:00–18:00 с двумя пиками, хобби - после 21:00 с максимумом в полночь. Пересечение зон минимально. Это говорит о чётком, хотя и неосознанном, разделении контекстов использования AI.
Практический вывод: разделение API-ключей и конфигураций для работы и хобби снижает риск утечки данных. Рабочий профиль использует только корпоративные облачные сервисы с аудитом, хобби-профиль - локальные модели без ограничений. Технически это реализуется через разные environment variables для клиентов инференса.
Оборудование и производительность: на что способен ваш компьютер
Тестирование проводилось на трёх конфигурациях: MacBook M2 Max (32 ГБ unified memory), рабочая станция с RTX 4090 (24 ГБ VRAM) + 64 ГБ RAM, и сервер с 2× RTX 3090 (48 ГБ VRAM суммарно) + 128 ГБ RAM. Модели: qwen3.6-70b (Q4_K_M), gemma-4-9b (Q8_0), deepseek-coder-33b (Q5_K_M).
| Конфигурация | qwen3.6-70b tk/s | gemma-4-9b tk/s | deepseek-33b tk/s | Энергопотребление |
|---|---|---|---|---|
| MacBook M2 Max 32GB | 4.2 | 38 | 8.1 | 60 Вт |
| RTX 4090 24GB | 69 | 210 | 95 | 350 Вт |
| 2× RTX 3090 48GB | 52 | 195 | 88 | 580 Вт |
RTX 4090 ожидаемо лидирует по чистому tk/s, но важна оговорка: qwen3.6-70b в квантизации Q4_K_M занимает 38 ГБ - она не влезает в 24 ГБ VRAM. На RTX 4090 модель частично уходит в RAM, теряя 40% производительности относительно теоретического максимума. Конфигурация с 2× RTX 3090 держит модель полностью в VRAM, но уступает 4090 в вычислительной мощности - отсюда 52 tk/s против 69.
MacBook M2 Max показывает 4.2 tk/s на 70B-модели - это граница практической применимости. Для сравнения: скорость чтения человека - примерно 10–15 токенов в секунду. Модель генерирует медленнее, чем вы читаете. Для интерактивной работы такой темп приемлем только с стримингом, когда вы видите первые токены через 3.4 секунды.
MacBook против рабочей станции: где узкое место?
Узкое место MacBook - пропускная способность unified memory. M2 Max обеспечивает 400 ГБ/с, тогда как RTX 4090 - 1008 ГБ/с. Разница в 2.5 раза прямо коррелирует с tk/s на моделях, не влезающих в кэш GPU. Для моделей до 8B, которые полностью помещаются в 32 ГБ unified memory, разрыв сокращается: 38 tk/s на MacBook против 210 tk/s на 4090 - пятикратное преимущество дискретной карты.
Преимущество MacBook - энергоэффективность. 60 Вт под нагрузкой против 350 Вт у RTX 4090. За месяц непрерывной работы разница в счетах за электричество составит около 2500 рублей при московских тарифах. Для хобби-проектов, где скорость не критична, MacBook экономически оправдан.
Ещё один фактор - шум и тепло. RTX 4090 под нагрузкой разогревается до 78°C и требует активного охлаждения корпуса. MacBook M2 Max остаётся практически бесшумным. Для домашнего использования это аргумент в пользу Apple Silicon.
Запуск огромных моделей на потребительском оборудовании: миф или реальность?
Colibri - движок, который загружает экспертов MoE-моделей с SSD по мере необходимости. Теоретически это позволяет запустить GLM-5.2 с 744B параметров на MacBook с 32 ГБ RAM. Практический результат: 0.1 токена в секунду. Один токен за 10 секунд. Ответ из 100 токенов генерируется 16 минут. Это не «запуск модели», а демонстрация технологии.
Причина - SSD как узкое место. Даже NVMe с 7000 МБ/с на порядки медленнее GPU-памяти. Каждый вызов эксперта требует чтения с диска, и при 8 экспертах на слой задержка суммируется. Colibri использует кэширование часто используемых экспертов в RAM, но для модели с 744B параметров кэш-промахи неизбежны.
Практическая применимость таких конфигураций - около нуля для интерактивных задач. Возможный сценарий: batch-обработка одного документа в фоне, где время ответа не критично. Но даже там проще арендовать облачный инстанс на час, чем ждать 16 минут на локальном MacBook. Технология интересна как proof of concept, но не как рабочий инструмент.
Альтернатива запуску гигантских моделей - дистилляция и квантизация. qwen3.6-70b в Q4_K_M на RTX 4090 даёт 69 tk/s и решает те же задачи, что и 744B-модель, с минимальной потерей качества. Индустрия движется в сторону эффективных средних моделей, а не запуска монстров на неподходящем железе.
Практические рекомендации: как оптимизировать свой AI-стек
Месяц трекинга кристаллизовался в шесть рекомендаций.
Выбор модели под задачу. Не используйте 70B-модель для ответа «да/нет». Наша статистика показала: 30% запросов к qwen3.6-70b имели сложность, решаемую 8B-моделью. Переключение этих запросов на gemma-4-9b сэкономило бы 15 часов GPU-времени за месяц. Правило: если ожидаемый ответ короче 200 токенов, начинайте с малой модели, переключайтесь на большую только при неудовлетворительном результате.
Настройка кэширования. KV-кэш при повторных запросах с одинаковым префиксом экономит до 70% времени генерации. Ollama включает кэширование автоматически, но размер кэша по умолчанию - 128 записей. Для рабочей станции с 64 ГБ RAM увеличьте до 1024. Для MacBook оставьте 128, иначе рискуете уйти в swap.
Гибридный подход. Настройте автоматический fallback: если локальная модель не ответила за N секунд, запрос уходит в облако. Порог N подбирается под ваше железо. Для RTX 4090 - 10 секунд, для MacBook - 20 секунд. Реализация через wrapper над API с таймаутом и retry logic.
Чек-лист для настройки мониторинга. Минимальный набор: JSON-логгер с полями timestamp, model, tk/s, category. Агрегация раз в сутки в SQLite. Визуализация в Grafana или скриптом на Python. Затраты на внедрение - 2–3 часа, окупаются пониманием своих паттернов использования за первую неделю.
Разделение рабочих и личных запросов. Разные API-ключи, разные директории логов, разные конфигурации таймаутов. Это предотвращает случайную отправку корпоративных данных в облако и упрощает аудит использования AI в компании.
Осторожность с agentic-паттернами. Graph Engineering - проектирование AI-агентов как исполняемого графа - набирает популярность, но требует внешних якорей проверки. Без них агенты могут принять внутреннее согласие за истину и выдать уверенный, но неверный результат. Трассировка запросов, аналогичная описанной в X-Ray, помогает отследить цепочку решений агента и найти точку расхождения с реальностью.
Эти рекомендации опираются на данные, а не на интуицию. В этом их отличие от общих советов «используйте локальные модели для приватности». Приватность важна, но без метрик вы не узнаете, что 13% ваших запросов всё равно утекают в облако из-за таймаутов. Трекинг превращает использование AI из магии в инженерную дисциплину.