Пользователь r/LocalLLaMA опубликовал финальный отчёт о том, как локальные и облачные модели справляются с задачами из его ежедневной работы: кодинг, кодинг с pandas и numpy, анализ данных, принятие решений на основе данных и локальный RAG. Короткий ответ для тех, кто выбирает модель под таблицы, точность округления и массивы: or-qwen-qwen3.8-27b в bf16 проходит набор ровно, iq3 GSQ-RCO держится на уровне Q4, а or-qwen-qwen3.8-flash-next чаще остальных упирается в лимит токенов из-за переразмышлений.
Тест собран на наборе из 500+ заданий, из которого удалены проверки, одинаково проходимые всеми моделями. Такой отбор оставляет задачи, где модели реально расходятся, и даёт различающий сигнал вместо ровной зелёной таблицы. Для сравнения в набор добавлены Muse Glimmer и Qwen3.6-35B-A3B. Цель автор формулирует буднично: найти модели, которым можно доверить интенсивную работу с таблицами, округлением, массивами и кодом, а затем принимать на их основе решения и действовать.
Границы применимости оговорены сразу. Результаты отражают рабочий процесс одного человека, это не одобрение и не приговор моделям для всех сценариев использования. Автор добавляет, что любую работу, выполненную локально, потом проверяет через Claude или GPT.
Что это за тест и почему ему стоит доверять
Исходная точка - набор из 500+ заданий, собранный под конкретные рабочие задачи. После фильтра остались только те проверки, где модели показывают разное поведение: одни решают, другие путаются в типах данных, округлении или порядке операций. Именно поэтому отчёт читается как различающий сигнал, а не как список галочек.
Как формировался набор заданий
Отбор шёл в одну сторону: всё, что стабильно проходят все модели, из набора вычищалось. Оставшиеся задания как раз и создают разницу между вариантами. Побочный эффект отбора в том, что набор становится сложнее среднего: легкие случаи, в которых модели надёжны, в отчёт не попали и на итоговую картину не влияют.
Сравнивать этот отчёт с публичными таблицами не стоит. MMLU, HumanEval и LiveCodeBench измеряют другое и выдают единый балл, здесь же есть список моделей и заметки о том, где каждая спотыкается. По формату это ближе к внутреннему регресс-тесту на своём датасете, чем к академическому замеру.
Ещё одна деталь, влияющая на чтение результатов: по умолчанию лимит на задание - 16 384 токена. Заметная часть выводов касается именно этого потолка, и он же стал причиной отдельного разбора Flash-Next.
Какие домены покрывает тест
Набор закрывает пять направлений, и все они взяты из ежедневной работы автора:
- кодинг;
- кодинг с pandas и numpy;
- анализ данных;
- принятие решений на основе данных;
- локальный RAG.
Практический смысл списка в том, что он совпадает с реальными запросами к локальной модели: посчитать, сгруппировать, округлить, поправить массив, объяснить результат, найти ответ в своих документах и на основе этого что-то решить. Если ваши задачи с этим набором не пересекаются, выводы стоит читать с поправкой: модель, сильная в таблицах, может проигрывать на генерации текста, фронтенда или длинных рассуждениях.
Qwen3.8-27B и Flash-Next: главные фигуранты теста
Две модели линейки Qwen задают в отчёте рамку сравнения: одна служит ориентиром точности, вторая показывает, где заканчивается запас лимита токенов.
or-qwen-qwen3.8-27b: bf16 и стабильность
or-qwen-qwen3.8-27b доступна в стандартном bf16. Это 16-битный формат с плавающей точкой, при котором веса не ужимаются до четырёх бит, и к ответу не примешивается погрешность квантования. Для задач с точностью округления и массивами такая база важна: вы сравниваете модели, а не форматы файлов.
В отчёте эта конфигурация проходит как надёжный вариант для кодинга и анализа данных. Дополнительный плюс bf16 в том, что отпадает вопрос выбора кванта: если VRAM хватает, вариант не требует серии экспериментов и повторных прогонов.
Скорость при этом зависит не только от модели. Как движок, квантование, объём памяти и драфтеры MTP влияют на токены в секунду, разбирали на примере запуска Qwen3.8-27B и соседних моделей на RTX 5090 с 192 ГБ RAM в материале о сравнении производительности современных LLM на домашнем ПК.
or-qwen-qwen3.8-flash-next: переразмышления и усечение
or-qwen-qwen3.8-flash-next не раскрывает своё квантование. В тесте она усекалась чаще всех остальных моделей при лимите 16 384 токена на задание, а повышение потолка до 32 000 токенов уменьшило число обрывов, но не убрало их полностью.
Механика предсказуемая: модель сначала пишет длинную цепочку рассуждений, и если не успевает её закрыть до лимита, пользователь получает обрезанный текст без финального вывода. На коротких вопросах это незаметно, на длинных ломает весь сценарий. Насколько рост усилий на размышление вообще помогает решать задачи, видно на отдельном мини-бенчмарке Qwen 3.8 на 16 ГБ VRAM: три кванта Qwen 3.8 на задачах AtCoder и проверка thinking effort показали, что рост усилий почти не добавляет решённых задач, зато увеличивает время работы и число упоров в лимит.
Практический вывод для Flash-Next: держите собственный потолок токенов и считайте долю обрезанных ответов. Если выводы рвутся на ваших задачах, помогает не бесконечное увеличение лимита, а смена модели либо более короткий промпт с явным требованием выдать итог.
Квантование и его влияние на результаты
Квантование снижает требования к VRAM: те же веса укладываются в меньший объём и быстрее читаются из памяти. Цена - возможная потеря точности, которая проявляется не ровным падением качества, а отдельными провалами на конкретных типах задач.
iq3 GSQ-RCO: достойный результат среди Q4
В отчёте iq3 GSQ-RCO показывает достойный результат и размещается среди Q4-вариантов. Более агрессивное ужатие на этом наборе не проваливается и держится на уровне заметно более тяжёлых файлов. Для владельца карты с ограниченной памятью это сигнал, что 4-битные варианты не единственный разумный компромисс.
Оговорка обязательна: набор задач специфический, а автор предупреждает, что результаты привязаны к его рабочему процессу. Проверять iq3 GSQ-RCO стоит на своих данных, особенно там, где важна точность округления и порядок операций.
Как честно сравнивать квантованные варианты одной модели, какие метрики собирать и почему режим medium reasoning нельзя объявлять лучшим без парного теста, показано на примере Flash-Next NVFP4 в локальном агентном кодинге: разбор Qwen3.8-Flash-Next NVFP4 и сравнение с 27B-моделями.
Почему OpenRouter не всегда раскрывает квантование
Модели на OpenRouter иногда указывают формат весов, а иногда нет. or-qwen-qwen3.8-27b там лежит в стоковом bf16, у or-qwen-qwen3.8-flash-next формат не раскрыт. Для пользователя это означает разную степень предсказуемости: в первом случае понятно, что именно вы получаете, во втором остаётся догадываться.
Если провайдер молчит про веса, сравнение между провайдерами теряет смысл: непонятно, с чем именно вы сопоставляете результат. Рабочий подход - спрашивать формат напрямую, отдавать предпочтение моделям с явно указанным квантованием и прогонять свои проверки на каждом варианте, прежде чем строить на нём рабочий процесс.
Файнтюны mradermacher: почему они выделяются
Отдельное наблюдение автора: файнтюны mradermacher продолжают выделяться для его типа работы. Формулировка важна. Это не превосходство на всех задачах, а устойчивое совпадение с конкретным набором, которое повторяется от теста к тесту.
Сборки отличаются от стоковых весов донорской базой, датасетом дообучения и настройками, поэтому поведение на табличных операциях может заметно расходиться с оригиналом. Что именно меняется в каждом конкретном файнтюне, автор отчёта не разбирает: он фиксирует результат на своих задачах.
Практический вывод: если стоковая модель стабильно ошибается на ваших данных, сравнение с дообученным вариантом обходится дешевле, чем смена модели или апгрейд железа. Проверяйте, на какой базовой версии собран файнтюн и как давно он обновлялся, иначе легко получить оптимизацию под чужие сценарии. Какие факторы вообще ограничивают качество компактных моделей, разбирали в статье о пределах возможностей малых моделей и упоре в параметры или VRAM.
Muse Glimmer и Qwen3.6-35B-A3B: сравнение с лидерами
Muse Glimmer и Qwen3.6-35B-A3B добавлены в набор для сравнения. Разбивки по задачам в исходном посте для них нет, поэтому строить рейтинг на одном упоминании нельзя: они дают фон, а не выводы о превосходстве или отставании.
Зачем они вообще в отчёте: чтобы тест не превратился в сравнение двух вариантов одной линейки. Разные семейства и разные размеры ведут себя на таблицах и в RAG по-разному, и наличие альтернатив помогает заметить, что часть проблем относится не к квантованию, а к самой архитектуре.
Если интересно, как эти модели выглядят за пределами табличных задач, есть отдельный разбор генерации воксельных миров: Qwen3.6 35B против Muse Glimmer 30B на RTX 5080, где виден компромисс между креативностью и надёжностью и влияние оптимизаций сборки.
Локальный RAG: какие модели справляются
Локальный RAG проверяет другое умение: не решить задачу с нуля, а собрать ответ по извлечённым фрагментам, не подменить факты и довести вывод до конца. Здесь обрыв генерации больнее всего, потому что теряется не только формулировка, но и связь с источниками.
Что даёт отчёт: or-qwen-qwen3.8-27b в bf16 проходит этот домен без оговорок по обрывам, а or-qwen-qwen3.8-flash-next из-за переразмышлений рискует усечением. Нераскрытое квантование у провайдера добавляет ещё одну неизвестную: даже при удачном ответе вы не знаете, на каких весах он получен.
Проверка на своих данных занимает вечер: 20-30 реальных вопросов к своей базе, один и тот же промпт, подсчёт доли ответов, где модель оборвала вывод или сослалась не на тот фрагмент. Для RAG этот показатель информативнее общего впечатления от качества текста.
Ограничения теста и как использовать его результаты
Автор предупреждает прямым текстом: результаты отражают его рабочий процесс и не одобрение и не приговор моделям для всех сценариев использования. Это не скромность, а техническая точность: набор собирался под конкретные задачи, и различающий сигнал работает только внутри этого набора.
Почему нельзя слепо следовать результатам
Оценки в отчёте качественные: «достойный результат», «выделяется». Чисел за ними нет, поэтому выстроить строгий порядок моделей между собой по таким формулировкам невозможно. Ваш промпт, ваш движок, ваша карта и ваш набор данных дают другую картину, особенно на границах, где модель почти справляется.
Разумное применение отчёта - сузить список кандидатов и понять, на что смотреть при проверке. Решение о внедрении всё равно принимается на своих задачах.
Роль Claude и GPT в проверке локальных результатов
Рекомендация автора: любую работу, сделанную локально, нужно проверять через Claude или GPT. Логика простая: локальная модель с одинаковой уверенностью выдаёт и верный, и ошибочный расчёт, а на глаз разница не видна. Для табличных задач это означает сверку итоговых цифр, для кода - прогон тестов, для RAG - проверку ссылок на источники.
Из этого не следует, что локальные модели плохи. Следует, что в процессе появляется второй контур контроля, и стоимость ошибки падает.
Практические выводы: какую модель выбрать
- Точность и предсказуемость. or-qwen-qwen3.8-27b в bf16 - база для кодинга, pandas и анализа данных, если VRAM позволяет держать 16-битные веса.
- Экономия памяти. iq3 GSQ-RCO подойдёт тем, кому нужно уложиться в меньший объём: на этом наборе он держится среди Q4. Проверять на своих данных.
- Flash-Next. Годится там, где ответы короткие и вы контролируете лимит токенов; на длинных задачах и в локальном RAG следите за долей обрезанных выводов.
- Файнтюны mradermacher. Стоит проверить, если стоковые веса стабильно спотыкаются на ваших табличных задачах.
- Muse Glimmer и Qwen3.6-35B-A3B. Держите в списке кандидатов, но не делайте выводов по одному упоминанию в чужом тесте.
- Проверка. Claude или GPT как второй контур для всего, что посчитано локально.
Конкретный следующий шаг: возьмите 20-30 задач из своей работы, задайте каждой модели один и тот же промпт с фиксированным лимитом токенов и посчитайте два числа - сколько задач решено и сколько ответов оборвалось. Эти два показателя скажут о применимости модели к вашему процессу больше, чем любой чужой рейтинг.