Лимиты ChatGPT и локальные LLM: мой эксперимент с Hermes Agent

Иногда я за час работы с облачной моделью выбираю весь доступный лимит. Потом ещё четыре часа жду его восстановления. Задача уже в голове, хочется продолжать, но приходится прерываться.

В последнее время всё чаще смотрю на следующий тариф ChatGPT за 100 евро. Но жаба душит: прежде чем платить больше, хочется понять, нельзя ли часть работы выполнять на своём компьютере.

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

Так я и пришёл к локальным LLM. Хотелось сохранить привычное качество, а более долгого ответа я был готов подождать. Проверил Qwen и GLM на домашнем ПК, сравнил квантования, подключил модели к Hermes и дал доступ к одной из них с Mac Neo.

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

Что у меня было

Нового оборудования я не покупал. Использовал домашний Windows-ПК:

• Intel Core i9-10900;

• 32 ГБ оперативной памяти;

• RTX 3080 с 10 ГБ видеопамяти.

Для запуска моделей использовал Ollama. Основным исполнителем в Hermes оставалась облачная модель; локальные подключал отдельно и проверял как через API, так и внутри самого агента.

В этой статье речь о конкретной серии моих проб. На каждое задание в сравнительном прогоне получал один итоговый ответ, поэтому судить по ним обо всём семействе Qwen или GLM я бы не стал. Я был сильно ограничен «железом». Скрипты испытаний и разбор ответов готовил с платной облачной моделью. Исходные локальные ответы сохранял без исправлений, чтобы результат облачной доработки случайно не выдать за возможности локальной модели.

Сначала всё выглядело неплохо

Начал с Qwen3.5 9B в Q4_K_M. В первых коротких запросах она генерировала около 89 токенов в секунду на GPU. Редактура небольшого русского текста тоже выглядела вполне пригодной для черновой работы.

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

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

CRM передаёт заказ через интеграционный сервис в ERP. ERP иногда недоступна или отвечает после тайм-аута. CRM повторяет запрос, из-за чего возникают дубли. Нужно предложить решение и отдельно разобрать ситуацию, когда ERP уже создала заказ, но ответ потерялся.

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

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

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

С включённым reasoning ответ стал аккуратнее: появилась проверка ключа на стороне ERP, модель явнее назвала допущения. Но описание хранения ключа в Redis с TTL оставило открытым вопрос, как согласованы создание заказа и фиксация этого ключа.

Если читать ответ по диагонали, такие ошибки легко пропустить. Текст выглядит профессионально, а существенное условие в нём потеряно.

Qwen 9B, GLM и Qwen 27B на одинаковых заданиях

Дальше сравнил три модели в Q4_K_M:

• qwen3.5:9b;

• glm-4.7-flash:latest;

• qwen3.5:27b.

Давал четыре задания: разобрать риски интеграции CRM и ERP, выбрать схему передачи изменений данных, отредактировать технический текст без добавления фактов и прочитать тестовый файл с извлечением данных в JSON.

В этой серии настроил окно 32768 токенов, включил reasoning. Начальный бюджет генерации составлял 8192 токена; если ответ обрывался по лимиту, был предусмотрен повтор с бюджетом 16384. Для текстовых задач использовал temperature 1.0, top_p 0.95 и seed 42. Для задания с инструментом — temperature 0.7 и top_p 1.0; num_batch — 128.

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

Что получилось по содержанию

Особенно показателен пример с историей изменений. Если между двумя опросами строка изменилась несколько раз, очередное чтение её текущего состояния не восстановит промежуточные версии. Для обещания сохранить каждое изменение нужен дополнительный механизм. В ответе более крупной Qwen этого обоснования не было.

Ещё в условии одного задания одновременно присутствовали задержка не более пяти минут и возможная недоступность единственного приёмника на тридцать минут. Ни одна модель явно не разобрала это противоречие. Очередь поможет сохранить события, но не доставит их в недоступную систему за пять минут.

GLM и Qwen 27B правильно извлекли из тестового файла все шесть проверяемых значений. Но обе модели добавили вокруг JSON Markdown-разметку, хотя требовался только JSON. Значения верные, формат ответа нарушен. Однако все три модели обернули JSON в Markdown-блок, хотя требовался только объект. Обрамление я снимал отдельно для диагностики. В результате хранится и исходный ответ с нарушением формата, и результат проверки его содержимого.

Сколько пришлось ждать

Это время полного задания с загрузкой или ожиданием, рассуждениями и выводом. Предусмотренный повтор после исчерпания бюджета тоже включён. У Qwen 9B в части снимков были другие загруженные модели, поэтому её ожидание нельзя полностью приписать скорости самой Qwen.

Крупные модели размещались частично в видеопамяти, частично в системной памяти. Qwen 27B на моем ПК действительно работала, но в одной из задач ждать пришлось больше получаса. И при этом как-то использовать комп было невозможно. Я был готов к медленной генерации; проблема в том, что и после такого ожидания ответ требовал содержательных исправлений.

Окно 32K было настроено у всех трёх моделей. Сами задания были короткими: обработку полностью заполненного контекста на 32 тысячи токенов эта серия не проверяла.

Поможет ли менее агрессивное квантование

После сравнения семейств отдельно проверил GLM-4.7-Flash в Q4_K_M, Q5_K_M и Q6_K.

Квантование позволяет хранить веса с меньшей точностью и сократить их объём. При переходе к более высокой битности потери точности обычно уменьшаются, но модель занимает больше памяти. Количество её параметров от этого не меняется. У K-квантований обозначение также не означает, что абсолютно каждый вес занимает ровно четыре, пять или шесть битов.

Мне хотелось проверить, насколько потери при квантовании влияют на ошибки именно в моих заданиях.

Для сравнения взял контрольные сборки Unsloth из одной закреплённой ревизии. Использовал одинаковые задания, настройки генерации и окно 16384 токена. Начальный бюджет и обработка ответов тоже были одинаковыми.

Скорость здесь рассчитана по числу сгенерированных токенов и времени генерации, включая reasoning, без загрузки весов. Свободная RAM — наблюдаемый запас всей системы вместе с остальными приложениями.

У Q6 появились отдельные улучшения. Например, в редактуре она сохранила смысл фразы «реализация механизма ещё не подтверждена», тогда как контрольные Q4/Q5 написали «алгоритм не утверждён». Для технического документа разница существенная: отсутствие подтверждения реализации и отсутствие утверждения алгоритма означают разные вещи.

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

Q6 работала, требовала больше памяти и генерировала медленнее. Заметного выигрыша, ради которого стоило бы переводить рабочую GLM с Q4, я не увидел. Утверждать, что любая Q6 бесполезна или что Q8 точно не поможет, я не могу: Q8 в этой серии вообще не запускал.

Эти результаты относятся к окну 16K. Переносить их на 64K без отдельной проверки памяти было бы рискованно: уже в этом прогоне запас системной RAM у Q6 опускался до 5,29 ГиБ.

Что произошло внутри Hermes

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

В отдельной проверке Qwen 9B как основная модель локального профиля заменила (зачем?) диск в пути с C: на Q:. Файл не прочитался, но ответ с данными всё равно появился. С контрольным результатом совпало только одно поле из семи.

В другом запуске та же Qwen получила задание как делегированный исполнитель с явной схемой ответа. Она прочитала правильный файл и вернула верные значения всех семи проверяемых полей.

Первый запуск занял 58,33 секунды, второй — 221,56 секунды. Во время второго работал другой локальный субагент, поэтому разницу во времени нельзя объяснять только способом постановки задачи.

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

Какую модель я в итоге оставил

Для дальнейшей работы на Windows оставил Qwen3.5 9B в Q4_K_M. Главная причина — расход памяти. При настроенном окне 65536 токенов модель целиком размещалась в видеопамяти и оставляла больше свободной системной RAM.

В проверенном запуске Ollama показывала около 7,03 ГБ VRAM для модели. Минимальная свободная системная RAM составляла 19,26 ГБ. Но общая занятость видеокарты с Windows и другими приложениями доходила до 9,67 ГБ из 10 ГБ. По видеопамяти запас всё равно небольшой.

Reasoning в проверенных маршрутах Qwen отключил. Для локального профиля настроил окно 65536: установленная у меня версия Hermes отказывалась запускать основного агента с первоначально выбранными 32K из-за своего минимального требования к окну. Обходить эту проверку я не стал.

Здесь тоже проверено выделенное окно, а не обработка документа на 64 тысячи токенов. И эти замеры памяти сделаны в другой серии, чем сравнительный прогон моделей выше.

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

По итогам этой серии роли распределились так:

Причем здесь Mac и что на нём настроено

Раз модель уже работает на домашнем ПК, хотелось дать доступ к ней и Hermes на Mac моей жены. Это ее рабочий ноут, и там тоже есть тяжелые задачи хоть и не архитектурные. Повторно запускать тяжёлую модель на самом Mac для этого не потребовалось.

Основную облачную модель на Mac сохранил. Локальную GLM на Windows подключил для делегированных подзадач. Получилась такая схема:

Hermes на Mac  ├─ облачная модель координирует работу  └─ локальный субагент:       инструменты выполняются на Mac       запрос к модели → HTTPS-шлюз в домашней сети                       → Ollama / GLM на Windows-ПК

Доступ сделал через HTTPS с проверкой сертификата и отдельным клиентским ключом. Саму Ollama оставил на loopback-интерфейсе ПК; напрямую в домашнюю сеть её API не открывал. Через шлюз доступны список разрешённых моделей и генерация, без загрузки или удаления моделей.

Для проверки дал настоящему субагенту прочитать тестовый файл на Mac. Инструмент выполнился на Mac, содержимое ушло модели на ПК, результат вернулся в Hermes на Mac. В журнале подтвердились нужное чтение и два вызова Qwen через HTTPS. Подмены локального ответа облачным в этой проверке не было.

Важно понимать, где оказываются данные: файл остаётся на Mac, но прочитанный текст передаётся на Windows-ПК для обработки. Слово «локальная» здесь относится к домашней сети и моему оборудованию.

Для шлюза также настроил запуск после входа в Windows и восстановление его дочернего процесса после сбоя.

На шлюзе ограничил число активных запросов и добавил очередь ожидания. При этом Hermes на Windows продолжал обращаться к Ollama напрямую, минуя эту очередь. Одновременную работу двух полноценных клиентов я ещё не проверял. Поэтому рассчитывать, что шлюз уже управляет всей общей нагрузкой, нельзя.

Получилось ли сэкономить облачный лимит

Конечно нет. У меня появилась работающая локальная модель и несколько способов её использовать, но экономии подписочного лимита нет.

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

Разница объясняется главным образом отдельными экспериментами в изолированном профиле, который не знает о подписке GPT. Она не показывает, что основной помощник передал локальной модели десятую часть полезной работы.

В эти числа входят подтверждённые завершённые ответы моделей, включая неудачные по содержанию. Прямые API-пробы Ollama и запросы Mac в таблицу не включены. Часть служебных записей пересекала границы периода, поэтому целиком отнести их к этому срезу было нельзя.

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

Что я вынес из этих проб

На своём ПК я смог запустить и небольшую Qwen, и более тяжёлые модели, сравнить квантования и подключить к локальному серверу ещё один компьютер. Для этого не понадобилось покупать новое железо, хотя вначале хотелось докупить еще 32 Гб оперативки.

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

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

Зато теперь у меня есть своя локальная LLM на случай зомби-апокалипсиса. Если интернет пропадёт, с текстами и локальными файлами совсем уж не пропаду. Лишь бы электричество осталось)