Лимиты 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.
В этой серии настроил окно 32 768 токенов, включил reasoning. Начальный бюджет генерации составлял 8192 токена; если ответ обрывался по лимиту, был предусмотрен повтор с бюджетом 16384. Для текстовых задач использовал temperature 1.0, top_p 0.95 и seed 42. Для задания с инструментом — temperature 0.7 и top_p 1.0; num_batch — 128.
Чтение файла в этом сравнении выполнял ограниченный тестовый обработчик. Полный цикл Hermes с его историей, навыками и всеми инструментами я проверял позже отдельно.
Что получилось по содержанию
Модель | Интеграция CRM → ERP | Передача изменений | Редактура текста |
|---|---|---|---|
Qwen3.5 9B | Спутала подтверждение брокера с результатом ERP, предложила компенсацию без подтверждения нужных возможностей | В описании Outbox остались пробелы в идентификаторах, версиях и повторной обработке | Добавила утверждения, которых не было в исходнике |
GLM-4.7-Flash | Превратила неизвестную возможность поиска заказа в ERP в утверждение о её отсутствии, затем снова назвала её неизвестной | Выбрала Outbox, но ошиблась в объяснении альтернативы и недостаточно описала повторную загрузку | Текст сдержаннее, но изменён смысл одной оговорки и не соблюдён объём |
Qwen3.5 27B | Лучше разделила часть требований и неизвестных свойств, но не дала безопасного решения для неизвестного результата операции | Предложила опрос текущих строк и при этом пообещала историю изменений, для которой этих строк недостаточно | Соблюла объём, но тоже изменила смысл исходных ограничений |
Особенно показателен пример с историей изменений. Если между двумя опросами строка изменилась несколько раз, очередное чтение её текущего состояния не восстановит промежуточные версии. Для обещания сохранить каждое изменение нужен дополнительный механизм. В ответе более крупной Qwen этого обоснования не было.
Ещё в условии одного задания одновременно присутствовали задержка не более пяти минут и возможная недоступность единственного приёмника на тридцать минут. Ни одна модель явно не разобрала это противоречие. Очередь поможет сохранить события, но не доставит их в недоступную систему за пять минут.
GLM и Qwen 27B правильно извлекли из тестового файла все шесть проверяемых значений. Но обе модели добавили вокруг JSON Markdown‑разметку, хотя требовался только JSON. Значения верные, формат ответа нарушен. Однако все три модели обернули JSON в Markdown‑блок, хотя требовался только объект. Обрамление я снимал отдельно для диагностики. В результате хранится и исходный ответ с нарушением формата, и результат проверки его содержимого.
Сколько пришлось ждать
Задание | Qwen 9B | GLM-4.7-Flash | Qwen 27B |
|---|---|---|---|
Риски интеграции | 5,91 мин | 2,10 мин | 16,54 мин |
Выбор архитектуры | 3,34 мин | 2,89 мин | 24,27 мин |
Редактура | 6,22 мин | 2,22 мин | 37,66 мин |
Чтение файла и ответ | 0,47 мин | 0,80 мин | 4,03 мин |
Это время полного задания с загрузкой или ожиданием, рассуждениями и выводом. Предусмотренный повтор после исчерпания бюджета тоже включён. У Qwen 9B в части снимков были другие загруженные модели, поэтому её ожидание нельзя полностью приписать скорости самой Qwen.
Крупные модели размещались частично в видеопамяти, частично в системной памяти. Qwen 27B на моем ПК действительно работала, но в одной из задач ждать пришлось больше получаса. И при этом как‑то использовать комп было невозможно. Я был готов к медленной генерации; проблема в том, что и после такого ожидания ответ требовал содержательных исправлений.
Окно 32K было настроено у всех трёх моделей. Сами задания были короткими: обработку полностью заполненного контекста на 32 тысячи токенов эта серия не проверяла.
Поможет ли менее агрессивное квантование
После сравнения семейств отдельно проверил GLM-4.7-Flash в Q4_K_M, Q5_K_M и Q6_K.
Квантование позволяет хранить веса с меньшей точностью и сократить их объём. При переходе к более высокой битности потери точности обычно уменьшаются, но модель занимает больше памяти. Количество её параметров от этого не меняется. У K‑квантований обозначение также не означает, что абсолютно каждый вес занимает ровно четыре, пять или шесть битов.
Мне хотелось проверить, насколько потери при квантовании влияют на ошибки именно в моих заданиях.
Для сравнения взял контрольные сборки Unsloth из одной закреплённой ревизии. Использовал одинаковые задания, настройки генерации и окно 16 384 токена. Начальный бюджет и обработка ответов тоже были одинаковыми.
Квантование GLM | Генерация, токенов/с | Минимальная свободная системная RAM, ГиБ |
|---|---|---|
Q4_K_M | 30,02 | 11,02 |
Q5_K_M | 25,07 | 8,22 |
Q6_K | 21,47 | 5,29 |
Скорость здесь рассчитана по числу сгенерированных токенов и времени генерации, включая 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 получила задание как делегированный исполнитель с явной схемой ответа. Она прочитала правильный файл и вернула верные значения всех семи проверяемых полей.
Проверка Qwen 9B внутри Hermes | Результат |
|---|---|
Основной агент локального профиля: прочитать файл и извлечь данные | Изменила путь, не прочитала файл, выдала неподтверждённые значения |
Делегированная подзадача с явной схемой результата | Прочитала нужный файл, семь из семи проверяемых полей верны |
Первый запуск занял 58,33 секунды, второй — 221,56 секунды. Во время второго работал другой локальный субагент, поэтому разницу во времени нельзя объяснять только способом постановки задачи.
Для меня неприятнее всего в первом результате была готовность продолжить после ошибки чтения. Если модель не получила исходник, мне нужен ответ об этом, а не правдоподобно заполненные поля. Удачный второй запуск полезен, но после первого я хочу проверить повторяемость на нескольких заданиях.
Какую модель я в итоге оставил
Для дальнейшей работы на Windows оставил Qwen3.5 9B в Q4_K_M. Главная причина — расход памяти. При настроенном окне 65 536 токенов модель целиком размещалась в видеопамяти и оставляла больше свободной системной RAM.
В проверенном запуске Ollama показывала около 7,03 ГБ VRAM для модели. Минимальная свободная системная RAM составляла 19,26 ГБ. Но общая занятость видеокарты с Windows и другими приложениями доходила до 9,67 ГБ из 10 ГБ. По видеопамяти запас всё равно небольшой.
Reasoning в проверенных маршрутах Qwen отключил. Для локального профиля настроил окно 65536: установленная у меня версия Hermes отказывалась запускать основного агента с первоначально выбранными 32K из‑за своего минимального требования к окну. Обходить эту проверку я не стал.
Здесь тоже проверено выделенное окно, а не обработка документа на 64 тысячи токенов. И эти замеры памяти сделаны в другой серии, чем сравнительный прогон моделей выше.
Qwen осталась, потому что с ней меньше давление на системную память. Ошибки в ответах никуда не делись. Комфортную длительную работу вместе с другими приложениями и самостоятельное выполнение задач ещё нужно проверить.
По итогам этой серии роли распределились так:
Где | Что оставил | Почему |
|---|---|---|
Локальный профиль и локальные субагенты на Windows. Локальный субагент для Hermes на Mac | Qwen3.5 9B, Q4_K_M | Меньше нагрузка на системную RAM |
Основной координатор Hermes на Mac и Windows | Облачная модель | Качество архитектурных ответов локальных моделей меня пока не устраивает |
Причем здесь 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‑установки за одни сутки в обычный рабочий день.
Область учёта | Облачные вызовы | Локальные вызовы | Доля локальных |
|---|---|---|---|
Основной рабочий профиль | 477 | 12 | 2,45% |
Все учтённые Windows‑профили вместе | 477 | 53 | 10% |
Разница объясняется главным образом отдельными экспериментами в изолированном профиле, который не знает о подписке GPT. Она не показывает, что основной помощник передал локальной модели десятую часть полезной работы.
В эти числа входят подтверждённые завершённые ответы моделей, включая неудачные по содержанию. Прямые API‑пробы Ollama и запросы Mac в таблицу не включены. Часть служебных записей пересекала границы периода, поэтому целиком отнести их к этому срезу было нельзя.
Перевести долю вызовов в экономию денег или подписочной квоты по этим журналам я не могу. Если облачная модель ставит задачу, проверяет локальный ответ и затем его переделывает, дополнительные локальные вызовы ещё ничего не говорят о пользе всей схемы.
Что я вынес из этих проб
На своём ПК я смог запустить и небольшую Qwen, и более тяжёлые модели, сравнить квантования и подключить к локальному серверу ещё один компьютер. Для этого не понадобилось покупать новое железо, хотя вначале хотелось докупить еще 32 Гб оперативки.
С качеством получилось хуже, чем хотелось. Модели находили часть проблем, но допускали ошибки в тех местах, ради которых я и просил разобрать задачу. В агентском сценарии отдельно пришлось столкнуться с ответом по файлу, который модель не смогла прочитать.
Поэтому следующая задача для меня — найти несколько полезных операций, которые Qwen выполняет достаточно хорошо и повторяемо: извлечение заданных фактов, редактура коротких фрагментов, сводка по указанному материалу. При проверке буду смотреть, сколько облачной доработки остаётся после каждого результата. Ну и еще нужно как‑то заставить Hermes чаще пользоваться бесплатной моделью.
Зато теперь у меня есть своя локальная LLM на случай зомби‑апокалипсиса. Если интернет пропадёт, с текстами и локальными файлами совсем уж не пропаду. Лишь бы электричество осталось)
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.