TurboQuant использует случайное вращение векторов (метод PolarQuant), чтобы размазать крупные выбросы по всем измерениям. Т.е. повезет/не повезет размазать хорошо.
Смысл поворота Адамара в повороте, случайность позволяет перекрутить вектор. “повезет/не повезет” - тут это не применимо, так как мы можем проверить результат. Разница лишь в том, какая часть вектора будет пиком, сглажен он будет целиком и совершенно не важно какая будет итоговая случайная форма, важно только то, что вектор теперь входит в диапазон 3-4 бит.
Проблема квантования - это выбросы в оригинале, для этих выбросов нужен bf16, который имеет огромный динамический диапазон, и такие выбросы причина, почему нельзя просто без потерь квантовать контекст. Контекст очень чувствителен к этим выбросам и нельзя их срезать.
До вращения RMS=9.6
В TurboQuant проблему выбросов решили через вращение Адамара. Изначальный вектор переводится в другую систему координат, сохраняя его энергию, но распределяя значения уже более равномерно. Такой новый сглаженный вектор не имеет выбросов и может иметь лучшую математическую стабильность, и плюс хорошо поддается квантованию почти без потерь.
Пик сглажен без потерь. После вращения RMS=9.6
В общем есть теоретическое обоснование, почему TurboQuant может быть стабильнее чем bf16, как это на практике - нужно больше тестов. Вращение Адамара уже реализовано в llama.cpp, поэтому, например, квантовать в Q8_0 на основной ветке стало вполне приемлемо, по сравнению с тем, что было раньше.
Через аналогию. Аналогично TubroQuant, у ik_llama улучшение за счет новых алгоритмов квантизации, за счет уплотнения всех данных, а не просто за счет перебора и выбора, что оставлять, а что выкинуть.
Я скорее про то, что это всё еще поиск рецепта, и этот рецепт не универсальный. Dynamic это путь перебора, который завязан на магическом калибровочном датасете, который они не показывают, не указывают длину контекста подбора, процент представление других языков, помимо английского и т.д. Не факт, что этот датасет совпадает с вашим сценарием или языком, что может выражаться в нестабильности ответов, зацикливании или сломанной согласованности с увеличением контекста.
Если выбирать между TurboQuant и выборочным перебором, где определяется какая часть контекста важна, а какая нет на основе собранного кем-то сценарии, то мало кто выберет второй вариант, если будет знать, что TurboQuant дает математическое решение снижения веса контекста в 2-3 раза без значимых потерь. И ik_llama дает математическое уплотнение, уплотняя упаковку самих данных.
Dynamic это не название фреймворка, и даже не алгоритм квантования, а обозначение их рецепта динамического квантования, когда разные тензоры квантуются по разному плюс используется imatrix для суб-динамического квантования внутри тензора. Всё это делается скриптом llama.cpp по кастомной схеме, вместо заранее созданных вроде “Q4_K_M”. В llama-quantize указывается --custom-q "$custom", а сам --custom-q уже может быть динамически настроенным:
Матрица важности задается через --imatrix, и качество динамического квантования напрямую зависит от imatrix датасета. Сейчас imatrix используют даже для статического квантования Q4_K_M.
Проблема чужих imatrix в том, что они не оптимизированы для русского языка, основной упор делается на английский язык. Создать свой датасет для imatrix под свой сценарий может быть не плохим решением, позволяя сжать модель сильнее, но сохраняя качество для вашего сценария.
И если цель минимальный размер, то стоит смотреть в сторону ik_llama, вот у них как раз именно новые математические алгоритмы квантования, позволяющие тоже качество засунуть в меньший размер. Кванты вроде Q4_K_M или IQ4 созданы не llama.cpp, а ikawrakow, который сейчас в ссоре с ggerganov и поэтому ikawrakow создал форк ik_llama.cpp, где продолжает улучшать алгоритмы квантования и новые SOTA кванты показывают отличные результаты.
Да, это так и будет, я обучал nanochat d24 размером 1.3B и по качеству это несколько уверенных уровней вверх. Правда ценность ruGPT3 в том, что они потратили компьют на 400B (80B*4 + 80B) токенов обучения, а не в архитектуре.
В ruGPT3 архитектура ближе к gpt3 за счет Sparce Attention, но всё равно MHA это тяжелая и прожорливая технология внимания, поэтому обучать GPT2-like архитектуры с нуля сейчас не особо имеет смысл. Даже GPT2-like habrGPT 0.5B я обучал на nanochat только, чтобы был материал про обучение на известном nanochat на ру сцене.
В 2026 современная архитектура это:
Mamba-2 (SSM) вместо квадратичного внимания, 75% слоев делают на mamba ради линейного внимания, чтобы вмещать 1м контекста, затраты тут O(n) на обучение и O(1) на инференс. Остальные 25% допустим MLA или GQA.
MLA с латентным низкоранговым пространством вместо разреженного внимания, работать с Sparse Attention у которого O(n²) тяжело. У MLA тоже O(n²), но он преобразует полные матрицы в низкоранговое пространство, тем самым экономия получается в разы.
GQA с той же сложностью как у Sparse Attention, но эффективнее, позволяет обучать весь контекст без безумных расходов памяти. Сюда же можно добавить Sliding Window, как в Gemma (iSWA), который снизит сложность с квадратичной до линейной, будет намного легче чем Sparse Attention. Обучать проще чем MLA, но тяжелее.
Другие современные методы: нормализация Pre-RMSNorm вместо Pre-LayerNorm, FFN активация SwiGLU вместо GELU, RoPE+YaRN, токенизатор на 150к, вместо 50к, для уплотнения на 20-30% информации, добавление SoftCap, чтобы стабилизировать обучение.
Value Residual и всё связанное SVFormer, ResFormer, PLE, value_embeds. В случае value_embeds снижение сложности на 50%.
Для самого обучения мало простого torch.compile(), что за счет компиляции ядер triton дает ускорение 50%, нужно добавить ещё разное:
Muon вместо чистого AdamW, это снижает расход памяти и стабилизует обучение.
Zero gradient checkpointing, для экономии памяти без потерь на forward, позволяет вместить больше батчей или параметров.
AdamW делит вычисления на мелкие шаги и для каждой части запускает своё CUDA-ядро. Можно объединять (fused) все эти операции в одно ядро, это сэкономит много памяти и ускорит обучение.
Можно объединить RMSNorm и SwiGLU, объединенное ядро для RoPE.
Вместо стандартного Cosine Annealing лучше Warmup-Stable-Decay, что создает качество лучше у pretrain.
Вместо Warmup-Stable-Decay можно попробовать взять Schedule-Free AdamW, чтобы не подбирать гиперпараметры, или попробовать μP для подбора, у которого подбор гиперпараметров решается математически.
Собрать такую архитектуру замороченее, но не сложнее, по сути это уже реализовано в transformers от huggingface или где-то рядом, что-то хорошо реализовано в Unsloth Train. Можно обучить дома в размере Dense 1.5B с value_embeds или MoE 6B-A0.6B без value_embeds, контекст допустим не 1м, а 32-64к за счет ssm. Тут скорее был бы полноценный датасет.
Спасибо. В рамках статьи цели объяснить, что такое PLE не было, цель была показать, что это своеобразный математический трюк, который работает, но как именно работает не так важно. К тому же в nanochat даже не тот PLE, что у Gemma, и чтобы объяснить отличие и изменение идеи в nanochat, сначала нужно глубоко погрузится в идею Gemma.
Можно относиться к этому как к форме “статичного” MoE, только вместо выбора между разными трансформерными слоями, тут для каждого токена заранее заготовлены смысловые векторы. И слой через гейт решает, сколько от этой заготовки взять к вычисляемому value. По мере продвижения по слоям заготовки усложняются, расширяя диапазон понимания без необходимости их вычислять.
Не думаю, что можно новичкам объяснить эту идею как-то сразу понятно, так как нужно понимать как работает MoE и эмбеддинги.
В целом да, можно классификатор сделать, довольно гибкий, например, комментарии группировать. Можно попробовать сделать суммаризатор статьей, или детектор чего-то что есть в статьях. Такого размера достаточно, чтобы сделать хороший переводчик, если не делать 200 пар, а десяток, или узконаправленный переводчик для игр.
Хм, только в чем смысл. Ведь такими действиями по сути уничтожают 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 как агент доработала код майнкрайфта в браузере, добавила новые блоки с алмазами и создала постройку
Смысл поворота Адамара в повороте, случайность позволяет перекрутить вектор. “повезет/не повезет” - тут это не применимо, так как мы можем проверить результат. Разница лишь в том, какая часть вектора будет пиком, сглажен он будет целиком и совершенно не важно какая будет итоговая случайная форма, важно только то, что вектор теперь входит в диапазон 3-4 бит.
Проблема квантования - это выбросы в оригинале, для этих выбросов нужен bf16, который имеет огромный динамический диапазон, и такие выбросы причина, почему нельзя просто без потерь квантовать контекст. Контекст очень чувствителен к этим выбросам и нельзя их срезать.
В TurboQuant проблему выбросов решили через вращение Адамара. Изначальный вектор переводится в другую систему координат, сохраняя его энергию, но распределяя значения уже более равномерно. Такой новый сглаженный вектор не имеет выбросов и может иметь лучшую математическую стабильность, и плюс хорошо поддается квантованию почти без потерь.
В общем есть теоретическое обоснование, почему TurboQuant может быть стабильнее чем bf16, как это на практике - нужно больше тестов. Вращение Адамара уже реализовано в llama.cpp, поэтому, например, квантовать в Q8_0 на основной ветке стало вполне приемлемо, по сравнению с тем, что было раньше.
Через аналогию. Аналогично TubroQuant, у ik_llama улучшение за счет новых алгоритмов квантизации, за счет уплотнения всех данных, а не просто за счет перебора и выбора, что оставлять, а что выкинуть.
Я скорее про то, что это всё еще поиск рецепта, и этот рецепт не универсальный. Dynamic это путь перебора, который завязан на магическом калибровочном датасете, который они не показывают, не указывают длину контекста подбора, процент представление других языков, помимо английского и т.д. Не факт, что этот датасет совпадает с вашим сценарием или языком, что может выражаться в нестабильности ответов, зацикливании или сломанной согласованности с увеличением контекста.
Если выбирать между TurboQuant и выборочным перебором, где определяется какая часть контекста важна, а какая нет на основе собранного кем-то сценарии, то мало кто выберет второй вариант, если будет знать, что TurboQuant дает математическое решение снижения веса контекста в 2-3 раза без значимых потерь. И ik_llama дает математическое уплотнение, уплотняя упаковку самих данных.
Для тех, кому интересно попробовать:
Сборки ik_llama под Win: https://github.com/Thireus/ik_llama.cpp
Квант ik_llama Qwen3.8 27B: https://huggingface.co/ubergarm/Qwen3.8-27B-GGUF
Dynamic это не название фреймворка, и даже не алгоритм квантования, а обозначение их рецепта динамического квантования, когда разные тензоры квантуются по разному плюс используется imatrix для суб-динамического квантования внутри тензора. Всё это делается скриптом llama.cpp по кастомной схеме, вместо заранее созданных вроде “Q4_K_M”. В llama-quantize указывается
--custom-q "$custom", а сам --custom-q уже может быть динамически настроенным:Матрица важности задается через
--imatrix, и качество динамического квантования напрямую зависит от imatrix датасета. Сейчас imatrix используют даже для статического квантования Q4_K_M.Проблема чужих imatrix в том, что они не оптимизированы для русского языка, основной упор делается на английский язык. Создать свой датасет для imatrix под свой сценарий может быть не плохим решением, позволяя сжать модель сильнее, но сохраняя качество для вашего сценария.
И если цель минимальный размер, то стоит смотреть в сторону ik_llama, вот у них как раз именно новые математические алгоритмы квантования, позволяющие тоже качество засунуть в меньший размер. Кванты вроде Q4_K_M или IQ4 созданы не llama.cpp, а ikawrakow, который сейчас в ссоре с ggerganov и поэтому ikawrakow создал форк ik_llama.cpp, где продолжает улучшать алгоритмы квантования и новые SOTA кванты показывают отличные результаты.
habrGPT. Обучим LLM 0.5B с нуля на статьях Хабра с помощью nanochat от Карпатого. Обучение fp8 дома и сравнение с bf16
Да, это так и будет, я обучал nanochat d24 размером 1.3B и по качеству это несколько уверенных уровней вверх. Правда ценность ruGPT3 в том, что они потратили компьют на 400B (80B*4 + 80B) токенов обучения, а не в архитектуре.
В ruGPT3 архитектура ближе к gpt3 за счет Sparce Attention, но всё равно MHA это тяжелая и прожорливая технология внимания, поэтому обучать GPT2-like архитектуры с нуля сейчас не особо имеет смысл. Даже GPT2-like habrGPT 0.5B я обучал на nanochat только, чтобы был материал про обучение на известном nanochat на ру сцене.
В 2026 современная архитектура это:
Mamba-2 (SSM) вместо квадратичного внимания, 75% слоев делают на mamba ради линейного внимания, чтобы вмещать 1м контекста, затраты тут O(n) на обучение и O(1) на инференс. Остальные 25% допустим MLA или GQA.
MLA с латентным низкоранговым пространством вместо разреженного внимания, работать с Sparse Attention у которого O(n²) тяжело. У MLA тоже O(n²), но он преобразует полные матрицы в низкоранговое пространство, тем самым экономия получается в разы.
GQA с той же сложностью как у Sparse Attention, но эффективнее, позволяет обучать весь контекст без безумных расходов памяти. Сюда же можно добавить Sliding Window, как в Gemma (iSWA), который снизит сложность с квадратичной до линейной, будет намного легче чем Sparse Attention. Обучать проще чем MLA, но тяжелее.
Другие современные методы: нормализация Pre-RMSNorm вместо Pre-LayerNorm, FFN активация SwiGLU вместо GELU, RoPE+YaRN, токенизатор на 150к, вместо 50к, для уплотнения на 20-30% информации, добавление SoftCap, чтобы стабилизировать обучение.
Value Residual и всё связанное SVFormer, ResFormer, PLE, value_embeds. В случае value_embeds снижение сложности на 50%.
Для самого обучения мало простого torch.compile(), что за счет компиляции ядер triton дает ускорение 50%, нужно добавить ещё разное:
Muon вместо чистого AdamW, это снижает расход памяти и стабилизует обучение.
Zero gradient checkpointing, для экономии памяти без потерь на forward, позволяет вместить больше батчей или параметров.
AdamW делит вычисления на мелкие шаги и для каждой части запускает своё CUDA-ядро. Можно объединять (fused) все эти операции в одно ядро, это сэкономит много памяти и ускорит обучение.
Можно объединить RMSNorm и SwiGLU, объединенное ядро для RoPE.
Вместо стандартного Cosine Annealing лучше Warmup-Stable-Decay, что создает качество лучше у pretrain.
Вместо Warmup-Stable-Decay можно попробовать взять Schedule-Free AdamW, чтобы не подбирать гиперпараметры, или попробовать μP для подбора, у которого подбор гиперпараметров решается математически.
Собрать такую архитектуру замороченее, но не сложнее, по сути это уже реализовано в transformers от huggingface или где-то рядом, что-то хорошо реализовано в Unsloth Train. Можно обучить дома в размере Dense 1.5B с value_embeds или MoE 6B-A0.6B без value_embeds, контекст допустим не 1м, а 32-64к за счет ssm. Тут скорее был бы полноценный датасет.
Спасибо. В рамках статьи цели объяснить, что такое PLE не было, цель была показать, что это своеобразный математический трюк, который работает, но как именно работает не так важно. К тому же в nanochat даже не тот PLE, что у Gemma, и чтобы объяснить отличие и изменение идеи в nanochat, сначала нужно глубоко погрузится в идею Gemma.
Можно относиться к этому как к форме “статичного” MoE, только вместо выбора между разными трансформерными слоями, тут для каждого токена заранее заготовлены смысловые векторы. И слой через гейт решает, сколько от этой заготовки взять к вычисляемому value. По мере продвижения по слоям заготовки усложняются, расширяя диапазон понимания без необходимости их вычислять.
Не думаю, что можно новичкам объяснить эту идею как-то сразу понятно, так как нужно понимать как работает MoE и эмбеддинги.
В целом да, можно классификатор сделать, довольно гибкий, например, комментарии группировать. Можно попробовать сделать суммаризатор статьей, или детектор чего-то что есть в статьях. Такого размера достаточно, чтобы сделать хороший переводчик, если не делать 200 пар, а десяток, или узконаправленный переводчик для игр.
В соседней статье дообучил эту модель на датасете ru-big-russian-dataset, и модель научилась новым навыкам, один из них переводить:
Статья про это дообучение: Дообучим старый ruGPT3 XL 1.3B (~2020 год) до уровня LLM. ChatGPT выйдет только через 2 года. Сравним с Gemma3 2025 года
Да, маска накладывается так же, как и для других датасетов, тренировка только на последнем ответе ассистента:
Хм, только в чем смысл. Ведь такими действиями по сути уничтожают 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.