Анубхав в своей статье ставит вопрос так: лучшая локальная модель для кода — не та, у кого выше балл на бенчмарке, а та, которую ваша машина реально потянет, не зависнув. Он предлагает выбирать локальную coding-модель по железу, латентности и приватности, а не по скриншотам лидербордов: «You cannot pick a model based on a leaderboard. You have to pick a model based on your silicon.» С этой методикой я согласен почти целиком. Но у меня есть встречный вопрос, и он, по-моему, важнее.
Вопрос не в том, «какая локальная модель победит». Вопрос — где локальной модели вообще место. Я держу LM Studio и локальный MCP, гоняю модели каждый день, и при этом считаю их непригодными для продакшена. В «The Harness Is the Cheap Part» я уже формулировал: локальную LLM нельзя ставить туда, где требуется продакшен-точность. Реальную работу я отдаю облаку. Эта статья — хороший повод заострить ту мысль до одной линии.
Где проходит граница
Граница — не «локально против облака» как мировоззрение. Граница проходит по характеру задачи. Есть агентские циклы, где доминирует стоимость токенов: скрипт читает упавший тест, предлагает фикс, компилирует, повторяет — пятьдесят раз в день. Анубхав описывает ровно этот сценарий и делает верный вывод: «You buy the hardware once and run infinite tokens.» Такие итерации дешёвые, объёмные и устойчивые к ошибкам — отдельная неудачная попытка ничего не стоит, потому что цикл всё равно перепробует. Вот сюда локальная модель ложится идеально.
А есть выход, от которого зависит результат: финальный патч, архитектурное решение, код, который уйдёт в ревью и в прод. Здесь цена ошибки не «лишний токен», а сломанный релиз. Этот выход идёт в облако — у меня к Claude. Дешёвые высокообъёмные циклы — локально; точностно-критичный результат — в облако. Это и есть граница, и она важнее любого рейтинга моделей.
Что в методике стоит сохранить
Самое ценное в статье — не список моделей, а инженерная методика «выбирай по кремнию, а не по лидерборду». Её я бы оставил себе целиком, потому что она не устаревает с очередным релизом.
- Q4_K_M как практический пол по качеству. Анубхав прямо предупреждает: «==The tradeoff is a slight loss in reasoning capability.==» Ниже Q4 для кода — модель «forget basic syntax and hallucinate variables». Это совпадает с моим опытом.
- Меньшая модель в Q8 лучше большой в Q2. «I always recommend running a smaller parameter model at Q8 rather than a bigger model at Q2.» Гнаться за числом параметров, добивая его агрессивным квантованием, — самообман.
- KV-кэш конкурирует с весами за unified memory. Контекст занимает физическую RAM наравне с весами модели; это, а не размер весов, чаще упирается в потолок.
- Swap-to-disk убивает скорость. Кончилась unified memory — и «generation speed will immediately drop from 30 tokens a second to 1 token a second». Это не деградация, это конец.
- Целься в ~15 tok/s для чата и ~40 tok/s для автокомплита. «Latency will kill your focus faster than a slightly wrong answer will» — формулировка, под которой я подпишусь. Ниже порога — бери модель меньше или тяжелее квантуй.
И тиры по железу — три практических класса (~16 ГБ unified, 32–64 ГБ или 24 ГБ VRAM, 128 ГБ и multi-GPU) — это честная рамка для разговора «что я вообще могу запустить», без иллюзий.
Где я бы притормозил
А вот к чему стоит отнестись осторожно — к конкретике 2026 года. Статья называет вполне определённые модели и числа: headline-модель на 80B MoE с «==it scores 58.7% on SWE-bench Verified==», семейство 27B-моделей, апрельский релиз Google на Apache 2.0, coding-семейство от Mistral, свёрнутое в одну 128B-модель, отдельную reasoning-модель и узкоспециализированный автокомплит. Я не могу подтвердить ни эти названия, ни эти цифры. Open-weight-экосистема, как и пишет автор, «moves incredibly fast» — часть моделей могла быть переименована, часть SWE-bench-чисел проверить нечем. Поэтому я отношусь к именам и баллам как к иллюстрации, а не как к факту: они показывают как рассуждать (по тиру и квантованию), но конкретный чарт протухнет к следующему релизу. Опирайтесь на принципы, не на таблицу.
Вердикт
Как фреймворк по тирам железа статья полезна: она честно связывает «что у тебя в машине» с «что ты можешь запустить» и задаёт правильные пороги латентности. Как лидерборд моделей — ей доверять не стоит: имена и SWE-bench-числа быстротечны и частью непроверяемы. Держатель ценности здесь один: выбирай по своему кремнию и своей нише, а не по скриншоту SWE-bench. А ниша у локальных моделей — дешёвые высокообъёмные агентские циклы, где ошибка дешева. Точность по-прежнему в облаке.