Локальный инференс на своём железе

На нашем стенде локальная модель справилась с ограниченным заданием под машинной приёмкой. Qwen3.8-27B написала модуль работы с длительностями и прошла все проверки в трёх повторах. Сборка приложения целиком упиралась в бюджет вывода. С включённым размышлением модель могла израсходовать его до появления кода. Эти результаты описывают конкретную конфигурацию и контракт задачи, без универсального рейтинга моделей.

Основные источники — артефакты из задания. Контекст, выгрузку и отказы мы проверяли также по журналам lm_pipeline/phase1.jsonl, phase5.jsonl, phase6.jsonl и соответствующим скриптам. Числа из сводок приведены отдельно от первичных записей. Если измерения нет, так и пишем: «не зафиксировано».

#1. Железо и что значит «локально»

Инференс-станция — ПК Daniel-HOME с RTX 5060 Ti и 16 ГБ видеопамяти. Малина запускает драйвер, отправляет запросы и принимает результаты. local_bench_driver.py обращается к LM Studio по внутреннему адресу стенда (порт 1234), переключает модели через SSH и сохраняет код в локальные временные каталоги. В октябрьском стенде common.py использует HTTP через туннель на порт 12340. Управляющий процесс запускается с малины. Генерация выполняется на ПК.

Модель Raspberry Pi, её оперативная память, процессор ПК и объём его RAM в этих артефактах — не зафиксировано. Скорость генерации непосредственно на процессоре малины — не зафиксировано. Нельзя приписывать ей показатели видеокарты только потому, что журнал лежит в /home/pi.

Ограничение станции видно по размерам весов. В LMSTUDIO_BENCH_29_09.md Qwen3-14B Q4_K_M занимает 9,00 ГБ на диске, после загрузки потребление VRAM составляет 10187 МБ. У Qwen3-30B-A3B Q4_K_M файл уже 18,63 ГБ, VRAM — 15803 МБ. Свободного места для всей модели и рабочего состояния недостаточно. Слово «локально» не обещает, что все вычисления останутся на GPU.

Связь между машинами тоже часть стенда. bench_report_final.md фиксирует No route to host: Gemma остановилась, следующий участник не стартовал. Причину исчезновения ПК из сети мы не знаем. Доказанный переход в сон — не зафиксировано. Без доступной станции автономный исполнитель не получит ответ, даже если модель могла бы решить задачу.

#2. Кванты: вместимость и совместимость

В сентябрьской серии использовались Q8_0 для Qwen3-0.6B, Q6_K для Qwen3-1.7B, Q4_K_M для трёх моделей на 14B и Qwen3-30B-A3B, Q1_0 для Bonsai-27B. Октябрьский phase1.jsonl добавляет Qwen3.8-27B и muse-glimmer в Q4_K_M, а также Ternary-Bonsai в PTQ1_0. Это конкретные форматы весов. При одинаковом числе параметров размер файла, скорость и поддержка загрузчиком могут различаться.

Размеры Bonsai: файл Q1_0 — 4,73 ГБ, VRAM после загрузки — 6385 МБ в сентябрьском отчёте. Сравнение качества одной модели в разных квантах — не зафиксировано. По этим данным нельзя вычислить, сколько качества потеряно при сжатии, или объявить быстрый квант лучшим для любой задачи.

Ternary-Bonsai не удалось загрузить. ITOG.md сообщает совпадение размеров скачанных файлов с удалёнными: 5 954 648 928 байт для модели и 931 145 856 для mmproj. Сводка называет файл целым. Проверка контрольной суммы — не зафиксировано; совпадение длины подтверждает полноту по размеру, но не тождество содержимого.

В phase1.jsonl, строки 8–9, загрузка PTQ1_0 заканчивается load_rc=1 и Failed to load model и с gpu=max, и с gpu=off. Мы повторили загрузку без GPU и сохранили хвост серверного лога. Модель исключили из замеров генерации. ITOG.md связывает отказ с бэкендом llama.cpp 2.49.0 и предлагает обновление либо PQ2_0. Таков диагноз сводки и предложенный способ исправления. Успешная загрузка после замены среды выполнения или кванта — не зафиксировано. Выдавать отказ загрузчика за низкое качество модели нельзя.

#3. Замеры: что именно называется скоростью

Сентябрьская таблица относится к контексту 8192 и температуре 0. Кванты взяты из отчёта LM Studio, скорость — из поля generation.wall_tok_per_s первичного JSON. Это число выходных токенов, делённое на полное время HTTP-запроса. Отдельного измерения чистой фазы декодирования здесь нет.

У большинства участников этой серии content пуст, а has_reasoning_field=true: токены уходили в размышление. У Qwen2.5-Coder есть видимый текст. Скорость 279 ток/с относится к выдаче токенов сервером. Скорость получения полезного ответа она ещё не показывает.

В октябрьской серии common.py считает completion_tokens / wall_s, включая ожидание начала ответа. phase1_settings.py выполняет два коротких запроса и сохраняет лучший показатель в gen_tok_s; обе скорости остаются в gen_tok_s_all. TTFT отсчитывается до первого непустого content или reasoning_content. Это может быть первый токен рассуждения, а не готового ответа.

Ранний ночной отчёт отдельно даёт медианы: gpt-oss-20b — около 42 ток/с и TTFT около 0,7 с; qwen3-coder-30b — около 5,9 и 2,0 с; Gemma — около 12 и 2,6 с. Кванты — не зафиксировано; драйвер задаёт контекст 8192. Метод слабее: при отсутствии usage он считает фрагменты потока как токены, а первым событием считает любой разобранный JSON. Эти приблизительные значения нельзя объединять с октябрьской серией в точный рейтинг.

#4. Чем платим за контекст и выгрузку

Контекст — ресурс загруженного экземпляра. В него должны помещаться вход, история и продолжение. При обработке последовательности среда выполнения хранит состояние внимания, обычно KV-кэш. Если памяти едва хватает, этот кэш конкурирует с весами за место. Размер KV-кэша и число слоёв на CPU в журналах — не зафиксировано.

В этих экспериментах --gpu задаёт режим переноса вычислений на видеокарту. Его нужно отличать от lms unload, которым драйвер освобождает станцию перед сменой модели. При уменьшении доли GPU размещение меняется. Значение max ещё не доказывает, что вся модель поместилась в VRAM.

У Qwen3.8-27B переход между записанными режимами 4096/0.90 и 8192/max сопровождается падением скорости с 19,80 до 11,73 ток/с и ростом TTFT с 0,73 до 2,09 с. Но одновременно изменены контекст и параметр GPU, а длина генерации различается. Это сравнение рабочих конфигураций; изолированная цена удвоения контекста — не зафиксировано. Входы здесь короткие: 75 токенов. Сравнение обработки заполненных окон 4096 и 8192 — не зафиксировано.

При неизменных 8192 изменение max на 0.95 даёт Qwen 11,73 → 11,20 ток/с, muse — 16,44 → 16,05. У Bonsai автоматическая загрузка практически сохраняет скорость относительно max. Поэтому эффект частичной выгрузки нельзя описывать единым коэффициентом. Точное фактическое размещение слоёв нужно измерять отдельно от запрошенного параметра.

В сводке есть неточность: ITOG.md приписывает 19,8 ток/с режиму max и сравнивает с 7,5 ток/с. Первичный журнал записывает 0.90, а строка, связывающая 7,5 с конкретным запуском, в этой серии — не зафиксировано. Для воспроизведения берём параметры JSON.

В сентябрьском замере Qwen3-30B-A3B видна цена тесной памяти: загрузка 192,5 с, выдача 8,9 ток/с. Запрос с входом 3472 токена и коротким продолжением занимает 26,34 с; у Qwen3-14B аналогичный запрос — 2,40 с (JSON). Сводка объясняет это размещением весов за пределами карты. Это правдоподобная интерпретация, но сравниваются разные модели. Отдельное доказательство потерь именно от перемещения слоёв — не зафиксировано.

Обработка длинного входа тоже занимает время. У Qwen3-14B короткий запрос-решение занимает 0,446 с, длинный — 2,401 с, оба дают 16 выходных токенов. Назвать вторую величину чистым временем обработки входа нельзя: она включает весь запрос. Сообщение об HTTP 400 для входа около 5,9 тысячи токенов в сводке также требует осторожности: там заявлен контекст 8192, но конфигурация конкретного отказавшего экземпляра — не зафиксировано. Это не доказательство запрета такого входа при любом окне 8192.

#5. Что модель делает, а что нет

Повторяемую приёмку прошёл один файл по ясному контракту. В phase5.jsonl, строки 1–3, Qwen3.8-27B с reasoning_effort="none" выдаёт модуль за 787 токенов. Времена запросов — 39,7, 40,1 и 39,5 с, приёмка — 10/10 во всех повторах. Проверяются разбор длительностей, форматирование, агрегация и обработка мусора. Это подтверждённая пригодность для данного модуля; покрытие произвольных заданий — не зафиксировано.

Та же модель с размышлением получает 3072 токена на раунд. В двух попытках по три раунда она расходует по 9216 токенов, заканчивает с finish="length" и нулевым content_chars; время — 473,9 и 530,0 с. Пустой ответ здесь объясняется исчерпанием вывода до появления полезного содержимого. Само увеличение лимита не обеспечило результат.

Полное Flask-приложение проверялось иначе. В phase6.jsonl включённое размышление расходует 4096 токенов и оставляет пустой ответ. После отключения размышления два запуска достигают структурной оценки 9/10: все семь маршрутов, компилируемый блок Python, но нет тестов и не закрыт блок Markdown. Оба ответа заканчиваются length ровно на 4096 токенах. Здесь подтверждён обрыв по бюджету; успешное завершение с большим лимитом — не зафиксировано. Структурные 9/10 не равны функциональной приёмке приложения.

Разбиение само по себе не гарантирует успех. В той же фазе вариант по 2048 токенов оставляет незакрытую конструкцию Python и получает 4,9/10. Каждый шаг должен помещаться в бюджет и завершаться проверяемым артефактом.

Есть и ошибки понимания входа. Qwen в монолитном варианте модуля получает 9/10: 1h30m проходит, 1h 30m отвергается. В сохранённом коде комментарий допускает пробел, но регулярное выражение его не содержит. Bonsai получает 8/10 с нормальным finish="stop": ломаются обе составные строки. В её коде часть до m преобразуется в число целиком, вместе с часами. В реализации заявлена поддержка примеров, но поведение расходится с контрактом. Такой отказ нельзя списать на длину ответа.

Пришлось исправлять и измеритель. Ночной отчёт сообщает, что автоматический pytest запускался через Python без установленного pytest. Ручная проверка gpt-oss дала 9 прошедших тестов и 1 упавший: ошибка обновления статуса задачи была реальной. У muse ошибочные стоп-маркеры обрезали ответ; после исправления phase7.jsonl сохраняет 5/10, 5/10 и 1/10. Починка обвязки сделала оценку осмысленнее, но не сделала модель принятой.

#6. Локально против облака

Облачные артефакты дают отдельную точку сравнения. TASK.md задаёт Godot-флаг --probe-dump и проверяемую строку stdout. В latest.json все три участника проходят проверку за 96,9, 102,2 и 109,1 с. Соседний bench_20260911_0412.json повторяет эти данные; считать его независимым повтором нельзя. bench_20260910_1422.json хранит другой запуск Flash: 88,6 с. Кванты, GPU-контекст и TTFT этих облачных прогонов — не зафиксировано.

moa_final.jsonl и real.jsonl описывают облачные конструкции и машинную приёмку, без прямого сравнения локальной и облачной модели на одном контракте. profile.json сохраняет 562 вызова, 1 275 325 некэшированных входных токенов, 374 010 выходных и 33 026 101 кэшированных. Это объём всего агентного цикла. Он не должен помещаться в локальное окно одним запросом.

Экономика облака взята из исторического снимка GO_LIMITS_ECONOMY.md от 28.09.2026. Для профиля тикета с входом 117K, кэшем 4,35M и выходом 48K файл даёт расход, названный процентом окна: MiMo — 0,070%, DeepSeek вне пика — 0,099%, в пик — 0,198%. Лимиты отдельных моделей различаются; общий счётчик складывает доли расхода относительно собственного лимита каждой модели. Эти значения нельзя выдавать за актуальные тарифы или автоматически переносить на пятичасовое окно.

Локальный исполнитель может экономить облачный лимит при повторяющихся заданиях, если уже имеющаяся станция свободна и результат проходит приёмку. Это инженерный вывод, а не измеренная окупаемость. Потребление электричества, его тариф, стоимость покупки GPU, амортизация и денежная цена локального принятого решения — не зафиксировано. Утверждение «локально всегда дешевле» данными не подтверждается. Выгоду могут съесть медленная генерация, повторные попытки, загрузка весов и ручные исправления.

Параллельные запросы повышают общий выпуск. Отдельное задание при этом не обязательно выполняется быстрее. lmsbench.log для Qwen3-14B сохраняет 38,8 ток/с при одном запросе и 88,4 суммарно при четырёх; медианное время запроса растёт с 6,59 до 11,58 с. Экономику очереди нужно считать вместе со временем ожидания и долей принятых работ.

#7. Вывод и границы

Мы подтвердили, что локальная модель может выполнить небольшую операцию по точному ТЗ. Она должна выдать завершённый файл, который проходит внешнюю проверку. Для Qwen3.8-27B это показано на модуле длительностей. Расширять роль следует через новые контракты и повторяемую приёмку, сохраняя квант, контекст, настройки загрузки, выходной лимит, причину остановки и время до полезного результата.

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

#Что проверить скептику

— Сверить каждую строку таблиц с generation.wall_tok_per_s или gen_tok_s; учесть выбор лучшего из двух запросов в октябрьской серии. — Проверить определения TTFT в обоих драйверах и различить первый фрагмент потока, размышление и полезный ответ. — Сопоставить gpu=0.90, контекст 4096 и 19,8 ток/с с рекомендацией max в сводке. Запросить отдельные замеры контекста и числа слоёв на CPU. — Для Ternary проверить размеры, контрольные суммы, версию бэкенда и успешный повтор после изменения формата: последний не зафиксирован. — Пересмотреть finish, ctok, content_chars, reason_chars в фазах 5–6; отличить функциональные тесты модуля от структурной оценки приложения. — Проверить составные длительности в сохранённом коде, доступность pytest и все повторы muse после исправления обвязки. — Считать экономику по принятой работе с повторными попытками. Потребовать измерения энергозатрат и сравнение с облаком на одинаковой задаче: они не зафиксированы.

Написано по артефактам студии; ссылки на файлы — имена наших исходников, они живут в репозитории, а не в вебе.