Хм, только в чем смысл. Ведь такими действиями по сути уничтожают ru ML сцену, которая и так очень слабо представлена, ни датасетов, ни материалов, лишь одни переводы.
Тоже прислали письмо
Добрый день,
Обратили внимание на Вашу статью https://habr.com/ru/articles/1054710/, точнее, на датасет, использованный для обучения LLM, ссылка на который содержится в статье - https://huggingface.co/datasets/IlyaGusev/habr. Этот дата-сет был создан нелегально, поэтому мы уже обратились к его создателю (тоже пользователю Хабра) с требованием об удалении. Просим Вас также удалить ссылку из статьи.
Там без подбора, гиперпараметры в nanochat выставляются автоматически, сам Карпатый уже давно занимается оптимизацией параметров обучения, поэтому выставлены по его личному опыту, закону Шиншиллы и так далее. Только на DPO пришлось снижать, но в nanochat вообще нет DPO этапа.
Если в целом на все эксперименты, то ушел где-то месяц, я обучал не только nanochat, обучал и MoE подобные модели, и чистый 0.25B на кастомной архитектуре которую собирал из разных новых архитектур, и даже пытался обучить 7B модельку, которую с помощью многих ухищрений удалось вместить в 32Гб, но скорость обучения была 500 t/s. Выше уже писал про дообучения 1.3B претрейна, в целом dense 1.3B вполне можно дома обучать.
И кстати может качество будет получше если обучать на меньшем количестве токенов, но уже предобученную модельку? А то обучать с нуля обычно мало смысла…
Есть и такое. У меня готова, но не опубликована, статья, где я дообучал старую ruGPT3 XL 1.3B (как раз @efreelancer недавно публиковал статью, где сделал для этой модели конвертацию в современный формат и поддержку gguf). Это pretrain 2020-2021 года обученный на 80B токенов, который умеет только продолжать текст, и выглядит это часто не как ответ, а как повествование:
Создавался этот pretrain во времена, когда ещё не было понимания, как заставить хороший pretrain вести диалог в чате, следовать инструкциям. Это время за 2 года до выхода ChatGPT и первой InstructGPT. И после дообучения на SFT такая модель на 80B токенов куда богаче по возможностям, она больше знает, хорошо следует инструкциям, может работать с текстом, даже решать головоломки:
И чтобы было понятно, какой уровень получился у модели, то сравнил её с Gemma3 1B 2025 года, при чем получилось не всегда в пользу Gemma3.
Задача на внимательность, Gemma3 1B провалил:
Про квантовую причину горения Солнца, Gemma3 1B дал не правильное название явления:
Это не полный датасет хабра, в статье есть ссылка на датасет, которую выше уже продублировали. Датасет собрал @Takagi, его же датасет IlyaGusev/saiga_preferences я использовал для SFT.
но оценить сколько это всё таки в токенах сложно из-за дополнительных полей Интересно было бы посмотреть что получится с несколькими эпохами или большим датасетом.
Это оказалось 508M токенов, совсем мало. Но всё равно обучил модель, уже по нормальному, и в этот раз результат получился получше:
Спасибо, хотел как раз не сразу результат, а для тех кому интересна тема обучения LLM дома, чтобы было побольше материала, тупики, ошибки и гипотезы.
Чекпоинты загрузил, обновил статью. Поддержка gguf только в форках, поэтому запуск через nanochat, нужно только разобраться куда ложить файлы и как запустить.
Вот тут я показывал опыт работы с Qwen3.6-35B-A3B, включая UD-Q2_K_XL и REAP урезание до 28B. Если памяти мало, то REAP интересная технология вырезания наименее активных экспертов, которые не нужны для определённых задач, и можно создать более компактную модель. И рядом про как ускорить без потерь за счет MTP.
REAP как агент доработала код майнкрайфта в браузере, добавила новые блоки с алмазами и создала постройку
Проблема в ассиметричных k и v, не все модели поддерживают такую работу на GPU и вычисления переносятся на CPU.
А симметричное q4_0 совсем плохо работает? Ключевая идея турбокванта это поворот Адамара, этот поворот добавили в llama.cpp и он по умолчанию работает для всего квантования KV, что должно давать не плохое качество на q4_0, но на практике не понятно, так это или нет.
вместо cpu-moe использовал n-cpu-moe - раскидал сколько смог слоев в видеокарту. n-cpu-moe на обычной llama.cpp дал 50 т/с, на ik_llama.cpp получил 60 т/с
Для qwen3.6 на днях добавили поддержку MTP, можно получить еще больше скорости без потери качества. Для Qwen3.6-35B-A3B ускорение не такое большое, как для Qwen3.6 27B, но оно тоже есть.
Интересная идея и реализация, а есть какой-то результат для примера?
Неделю назад обучал 0.25B LLM с нуля исключительно на статьях с хабра, датасет IlyaGusev/habr, просто посмотреть, что из этого получится. SFT датасет автоматически построен из датасета хабра, чтобы не было примесей из других источников. Токенизатор обучен тоже только на хабре.
Идея была попробовать обучить 1B, но времени было мало, поэтому на коленке обучил только 0.25B за 3 часа. Первый шаг, это pre-train, который умеет только продолжать то, что ему задать как промпт:
Правильное понимание, где римские цифры, а где буквенное перечисление
Что-то похожее на связный текст
Обучение pre-train было всего на 1 эпохе, поэтому знания плохо усвоены, но что-то аппроксимировано. Модель сама выявила паттерны русского языка, родов, склонений и прочего, хотя логика и знания хромают, общее написание фраз вполне корректное.
Для примера как выглядело начало обучения:
10% от 1 эпохи
Дальше идет обучение SFT, где pre-train учится шаблону чата и умению отвечать на вопросы и уметь разделять где assistant, а где user. Качество общения зависит от качества SFT датасета, его я сделал автоматически и всего на 1к записей, как старт сойдет, но о проработке речи не идет:
Первое, что ответила модель после SFT обучения, все совпадения случайны
Выставил температуру минимально, результаты должны быть максимально близки. Есть шанс заруинить. Допустим взяли черновую очень маленькую 0.6B
Отвечаю сам себе и уточняю для тех, кто сюда забредёт. Это информация устарела, она больше не актуальна. Проблем с черновыми моделями нет.
Спекулятивное декодирование дает идентичный результат без искажений, я специально проверил исходники llama.cpp, чтобы убедиться, что это действительно так. Особенно это актуально для новых методов MTP, Eagle-3, DFlash, которые дают сильно большее ускорение, чем старый метод через маленькие черновые модели.
Так не получится сравнить, сделав несколько прогонов, вы оцениваете сэмплинг, а не модель MTP. Модель детерминирована, а сэмплинг стохастичен и сэмплинг это внешняя от модели сущность. Для сравнения надо либо отключить сэмплинг, либо собрать статистику на большом количестве замеров.
Прогнал 100 замеров без MTP и 100 с MTP на вашем задании. Температура 0.8, top_p 0.85.
Вариант с MTP выдал 64% правильных ответов, а без MTP - 57%. Но не стоит цепляться за сами проценты, в следующем прогоне будет наоборот, серия “доехать” может составлять 10 подряд, а потом 5 подряд будет “прогуляться”, один “доехать” и снова 5 “прогуляться”. Главное тут то, что температура 0.8 добавляет слишком много случайности, а top_p 0.85 креативности (значение по умолчанию в 0.95 добавляет ещё больше креативности).
Температура 0.3, процент правильных ответов стремится к 75%:
Температура 0, процент правильных ответов 100%:
Сэмплинг в данном случае вносит слишком много хаоса, модель хоть и может найти правильный ответ на задачу, но внешняя случайность от сэмплинга уводит модель в сторону. MTP тут не при чём, в статье я как раз смотрел исходники llama.cpp чтобы убедиться, что MTP не добавляет от себя ничего и никак не искажает генерацию.
До сих пор не добавили TurboQuant, но на то есть причина - ощутимая просадка скорости, так как вычисления до сих пор не смогли полноценно перенести на GPU и работа выполняется на CPU. Вместо этого добавили “у нас есть turboquant дома”, а именно Rotate Activations. Это одна из частей турбокванта, вращение активаций через матрицу Адамара. И даже это очень сильно повысило качество квантования KV-кэша в размере Q4_0.
Это улучшение включено по умолчанию, и работает для KV-кэша всех вариантов (q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1). Я прогнал пару тестов Q4_0 на 256к контексте, и сработало не плохо, не хуже чем Q8_0.
Добавили нативную поддержку NVFP4 в GGUF. NVFP4 лучше снижает ошибку квантования чем MXFP4, так как разбивает микроблоки дополнительно в 2 раза, делая их более гранулированными, и используют адаптивный scale factor для этих блоков, повышая точность. Я прогнал пару замеров KLD, и кванты NVFP4 GGUF и правда лучше чем чистые MXFP4.
В llama.cpp завезли поддержку Qwen3.6 MTP. Новые кванты уже создали со слоями MTP. Написал статью что такое MTP, как запустить и какое ускорение получилось. Также проверил исходники llama.cpp, чтобы проверить, качество оригинала сохраняется или искажается:
Еще можно какие-нибудь Q2_K_L от bartowski попробовать - с гарантированно равномерным квантованием экспертов.
Это хороший аргумент, но есть несколько нюансов:
bartowski статические кванты квантует с использованием imatrix, поэтому равномерного квантования там не может быть, неравномерность задается на уровне суперблоков через imatrix.
У него калибровачный датасет 400к токенов, из них только 4к на русском, 1%. И этот 1% не отборных текстов, а каких-то разорванных кусков.
calibration_datav5.txt от Bartowski, отсортирован только русский текст
bartowski тоже не квантует равномерно, часть слоев выше, часть ниже.
Bartowski, qwen3.6-35B-A3B, Q4_K_M и Q2_K_L
Поэтому его кванты не чистые статические классические Q4_K_M, а являются динамическими. Хотя тут, смотря что вы имели ввиду под "гарантированно равномерным".
Вообще, мне нравятся кванты от ubergarm, они весят меньше, что важно когда мало VRAM, используют новые алгоритмы квантования, которые сохраняют больше точности, квантование тоже равномерное, без сильных экспериментов, imatrix содержит уже 2% русского текста.
Но кванты ubergarm сложно рекомендовать, так как требуют понимая ik_llama.cpp, которая не имеет автонастроек fit, не дружит с AMD и тому подобное.
Ещё из интересного для квантов, недавно завезли NVFP4 GGUF в llama.cpp. NVFP4 имеет в 2 раза меньший размер микроблоков, что повышает точность суперблоков, и имеет более детальный scale factor чем у MXFP4, когда внутри в рецептах начнут использовать nvfp4 вместо Q4_K, то это, возможно, не плохо повысит качество.
Чистые NVFP4 тоже работают не плохо, уже в GGUF виде можно запускать.
Это хорошо, что он откатил свой рецепт, я перестал качать его кванты когда он начал, пытаясь выиграть в размере, часть ffn квантовать в Q3_K, что ударяло по качеству Q4_K_M. Если он ещё увеличит процент русского текста в своем imatrix с 1% хотя бы до 5%, то его кванты будут совсем хороши.
Хм, только в чем смысл. Ведь такими действиями по сути уничтожают ru ML сцену, которая и так очень слабо представлена, ни датасетов, ни материалов, лишь одни переводы.
Тоже прислали письмо
Там без подбора, гиперпараметры в nanochat выставляются автоматически, сам Карпатый уже давно занимается оптимизацией параметров обучения, поэтому выставлены по его личному опыту, закону Шиншиллы и так далее. Только на DPO пришлось снижать, но в nanochat вообще нет DPO этапа.
Если в целом на все эксперименты, то ушел где-то месяц, я обучал не только nanochat, обучал и MoE подобные модели, и чистый 0.25B на кастомной архитектуре которую собирал из разных новых архитектур, и даже пытался обучить 7B модельку, которую с помощью многих ухищрений удалось вместить в 32Гб, но скорость обучения была 500 t/s. Выше уже писал про дообучения 1.3B претрейна, в целом dense 1.3B вполне можно дома обучать.
Есть и такое. У меня готова, но не опубликована, статья, где я дообучал старую ruGPT3 XL 1.3B (как раз @efreelancer недавно публиковал статью, где сделал для этой модели конвертацию в современный формат и поддержку gguf). Это pretrain 2020-2021 года обученный на 80B токенов, который умеет только продолжать текст, и выглядит это часто не как ответ, а как повествование:
Создавался этот pretrain во времена, когда ещё не было понимания, как заставить хороший pretrain вести диалог в чате, следовать инструкциям. Это время за 2 года до выхода ChatGPT и первой InstructGPT. И после дообучения на SFT такая модель на 80B токенов куда богаче по возможностям, она больше знает, хорошо следует инструкциям, может работать с текстом, даже решать головоломки:
И чтобы было понятно, какой уровень получился у модели, то сравнил её с Gemma3 1B 2025 года, при чем получилось не всегда в пользу Gemma3.
Задача на внимательность, Gemma3 1B провалил:
Про квантовую причину горения Солнца, Gemma3 1B дал не правильное название явления:
Это не полный датасет хабра, в статье есть ссылка на датасет, которую выше уже продублировали. Датасет собрал @Takagi, его же датасет IlyaGusev/saiga_preferences я использовал для SFT.
Финальный pretrain ~9 часов и ещё пол часа на sft и dpo.
С небольшой теорией по шагам и демонстрацией промежуточных этапов, когда вначале модель не могла связать ни слова:
И до момента как освоила язык, и дальше смогла даже пообщаться в чате, выполнять простые задания, давать ответы на вопросы:
habrGPT. Обучим LLM 0.5B с нуля на статьях Хабра с помощью nanochat от Карпатого. Обучение fp8 дома и сравнение с bf16
Это оказалось 508M токенов, совсем мало. Но всё равно обучил модель, уже по нормальному, и в этот раз результат получился получше:
habrGPT. Обучим LLM 0.5B с нуля на статьях Хабра с помощью nanochat от Карпатого. Обучение fp8 дома и сравнение с bf16
Спасибо, хотел как раз не сразу результат, а для тех кому интересна тема обучения LLM дома, чтобы было побольше материала, тупики, ошибки и гипотезы.
Чекпоинты загрузил, обновил статью. Поддержка gguf только в форках, поэтому запуск через nanochat, нужно только разобраться куда ложить файлы и как запустить.
Выжать больше из локальных LLM. Ollama медленнее llama.cpp в 3 раза. UD_Q4_K_XL лучше чем Q4_K_M, а вес тот же и т.д
Qwen3.6 27B MTP весит на +0.3 Гб больше, а даёт ускорение в ~2 раза. С 60 t/s до 130 t/s без потерь. Что такое MTP
Вот тут я показывал опыт работы с Qwen3.6-35B-A3B, включая UD-Q2_K_XL и REAP урезание до 28B. Если памяти мало, то REAP интересная технология вырезания наименее активных экспертов, которые не нужны для определённых задач, и можно создать более компактную модель. И рядом про как ускорить без потерь за счет MTP.
Проблема в ассиметричных k и v, не все модели поддерживают такую работу на GPU и вычисления переносятся на CPU.
А симметричное q4_0 совсем плохо работает? Ключевая идея турбокванта это поворот Адамара, этот поворот добавили в llama.cpp и он по умолчанию работает для всего квантования KV, что должно давать не плохое качество на q4_0, но на практике не понятно, так это или нет.
Для qwen3.6 на днях добавили поддержку MTP, можно получить еще больше скорости без потери качества. Для Qwen3.6-35B-A3B ускорение не такое большое, как для Qwen3.6 27B, но оно тоже есть.
Вот тут подробнее: Qwen3.6 27B MTP весит на +0.3 Гб больше, а даёт ускорение в ~2 раза. С 60 t/s до 130 t/s без потерь. Что такое MTP
Если согласны потерять сколько-то в качестве, то можно ускориться раза в 1.5. Попробуйте кванты, которые хорошо работают на CPU, это Q4_0 и Q4_1.
Интересная идея и реализация, а есть какой-то результат для примера?
Неделю назад обучал 0.25B LLM с нуля исключительно на статьях с хабра, датасет IlyaGusev/habr, просто посмотреть, что из этого получится. SFT датасет автоматически построен из датасета хабра, чтобы не было примесей из других источников. Токенизатор обучен тоже только на хабре.
Идея была попробовать обучить 1B, но времени было мало, поэтому на коленке обучил только 0.25B за 3 часа. Первый шаг, это pre-train, который умеет только продолжать то, что ему задать как промпт:
Обучение pre-train было всего на 1 эпохе, поэтому знания плохо усвоены, но что-то аппроксимировано. Модель сама выявила паттерны русского языка, родов, склонений и прочего, хотя логика и знания хромают, общее написание фраз вполне корректное.
Для примера как выглядело начало обучения:
Дальше идет обучение SFT, где pre-train учится шаблону чата и умению отвечать на вопросы и уметь разделять где assistant, а где user. Качество общения зависит от качества SFT датасета, его я сделал автоматически и всего на 1к записей, как старт сойдет, но о проработке речи не идет:
Отвечаю сам себе и уточняю для тех, кто сюда забредёт. Это информация устарела, она больше не актуальна. Проблем с черновыми моделями нет.
Спекулятивное декодирование дает идентичный результат без искажений, я специально проверил исходники llama.cpp, чтобы убедиться, что это действительно так. Особенно это актуально для новых методов MTP, Eagle-3, DFlash, которые дают сильно большее ускорение, чем старый метод через маленькие черновые модели.
Подробнее я расписал в статье: Qwen3.6 27B MTP весит на +0.3 Гб больше, а даёт ускорение в ~2 раза. С 60 t/s до 130 t/s без потерь. Что такое MTP
Так не получится сравнить, сделав несколько прогонов, вы оцениваете сэмплинг, а не модель MTP. Модель детерминирована, а сэмплинг стохастичен и сэмплинг это внешняя от модели сущность. Для сравнения надо либо отключить сэмплинг, либо собрать статистику на большом количестве замеров.
Прогнал 100 замеров без MTP и 100 с MTP на вашем задании. Температура 0.8, top_p 0.85.
Вариант с MTP выдал 64% правильных ответов, а без MTP - 57%. Но не стоит цепляться за сами проценты, в следующем прогоне будет наоборот, серия “доехать” может составлять 10 подряд, а потом 5 подряд будет “прогуляться”, один “доехать” и снова 5 “прогуляться”. Главное тут то, что температура 0.8 добавляет слишком много случайности, а top_p 0.85 креативности (значение по умолчанию в 0.95 добавляет ещё больше креативности).
Температура 0.3, процент правильных ответов стремится к 75%:
Температура 0, процент правильных ответов 100%:
Сэмплинг в данном случае вносит слишком много хаоса, модель хоть и может найти правильный ответ на задачу, но внешняя случайность от сэмплинга уводит модель в сторону. MTP тут не при чём, в статье я как раз смотрел исходники llama.cpp чтобы убедиться, что MTP не добавляет от себя ничего и никак не искажает генерацию.
Код скрипта, для тех кто хочет повторить
Скачать кванты с именем MTP:
unsloth/Qwen3.6-27B-MTP-GGUF
unsloth/Qwen3.6-35B-A3B-MTP-GGUF
И запускать:
.\llama-server -m "Qwen3.6-27B-UD-Q4_K_XL.gguf" --spec-type draft-mtp --spec-draft-n-max 4Указать
--spec-draft-n-maxобязательно, по умолчанию будет сильная просадка скорости.Ещё из новостей про llama.cpp:
До сих пор не добавили TurboQuant, но на то есть причина - ощутимая просадка скорости, так как вычисления до сих пор не смогли полноценно перенести на GPU и работа выполняется на CPU. Вместо этого добавили “у нас есть turboquant дома”, а именно Rotate Activations. Это одна из частей турбокванта, вращение активаций через матрицу Адамара. И даже это очень сильно повысило качество квантования KV-кэша в размере Q4_0.
Это улучшение включено по умолчанию, и работает для KV-кэша всех вариантов (q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1). Я прогнал пару тестов Q4_0 на 256к контексте, и сработало не плохо, не хуже чем Q8_0.
Добавили нативную поддержку NVFP4 в GGUF. NVFP4 лучше снижает ошибку квантования чем MXFP4, так как разбивает микроблоки дополнительно в 2 раза, делая их более гранулированными, и используют адаптивный scale factor для этих блоков, повышая точность. Я прогнал пару замеров KLD, и кванты NVFP4 GGUF и правда лучше чем чистые MXFP4.
В llama.cpp завезли поддержку Qwen3.6 MTP. Новые кванты уже создали со слоями MTP. Написал статью что такое MTP, как запустить и какое ускорение получилось. Также проверил исходники llama.cpp, чтобы проверить, качество оригинала сохраняется или искажается:
Qwen3.6 27B MTP весит на +0.3 Гб больше, а даёт ускорение в ~2 раза. С 60 t/s до 130 t/s без потерь. Что такое MTP
Это хороший аргумент, но есть несколько нюансов:
bartowski статические кванты квантует с использованием imatrix, поэтому равномерного квантования там не может быть, неравномерность задается на уровне суперблоков через imatrix.
У него калибровачный датасет 400к токенов, из них только 4к на русском, 1%. И этот 1% не отборных текстов, а каких-то разорванных кусков.
bartowski тоже не квантует равномерно, часть слоев выше, часть ниже.
Поэтому его кванты не чистые статические классические Q4_K_M, а являются динамическими. Хотя тут, смотря что вы имели ввиду под "гарантированно равномерным".
Вообще, мне нравятся кванты от ubergarm, они весят меньше, что важно когда мало VRAM, используют новые алгоритмы квантования, которые сохраняют больше точности, квантование тоже равномерное, без сильных экспериментов, imatrix содержит уже 2% русского текста.
Но кванты ubergarm сложно рекомендовать, так как требуют понимая ik_llama.cpp, которая не имеет автонастроек fit, не дружит с AMD и тому подобное.
Ещё из интересного для квантов, недавно завезли NVFP4 GGUF в llama.cpp. NVFP4 имеет в 2 раза меньший размер микроблоков, что повышает точность суперблоков, и имеет более детальный scale factor чем у MXFP4, когда внутри в рецептах начнут использовать nvfp4 вместо Q4_K, то это, возможно, не плохо повысит качество.
Чистые NVFP4 тоже работают не плохо, уже в GGUF виде можно запускать.
Это хорошо, что он откатил свой рецепт, я перестал качать его кванты когда он начал, пытаясь выиграть в размере, часть ffn квантовать в Q3_K, что ударяло по качеству Q4_K_M. Если он ещё увеличит процент русского текста в своем imatrix с 1% хотя бы до 5%, то его кванты будут совсем хороши.