Kimi k2.1 — новая модель от Moonshot Полное имя билда: Kimi K2 0905.
Лучше не выдумывать наименования моделям, и не следовать за теми, кто так делает. Официально релиз назвали Kimi-K2-0905, а не K2.1, а предыдущий релиз они теперь называют Kimi-K2-0711. 0905 и 0711 - это дата релиза, самый распространенный способ именования у моделей.
Когда вышел DeepSeek V3-0324, его люди назвали 3.1 и на многих сайтах он был записан как 3.1, но 2 недели назад вышел настоящий V3.1 и до сих пор в обсуждениях не все могут понять, о какой версии идет речь.
Новая версия с 256к контекстом уже доступна: https://www.kimi.com/ Работает с текстом целой книги на 250к токенов вполне нормально:
Основная сложность вылезает с плавающими запятыми и делением. Умножение еще хоть как то у нее получается, это по сути сложение
Это не важно, деление, плавающая запятая или что угодно, хоть самые сложные и замороченные формулы, всё это можно упростить и вывести примерную формулу, например, как jpg упрощает оригинал и сжимает его, но разницу на глаз можно и не заметить. Внутри LLM умножение не выводится из сложения, аппроксимация не про это.
У LLM во время обучения, какие бы числа и действия на вход вы не дали, за счет свойств внутренних скрытых слоев, происходит автоматическая попытка вывести новую функцию из входящих данных и ожидаемого результата. Эта выведенная функция будет упрощенной версией изначальной функции, она будет работать очень быстро, но не точно, это и есть аппроксимация.
Может термин "аппроксимировать" слишком нетипичен для восприятия, но это математический и научный метод, именно он работает внутри LLM. И в контексте статьи позволяет понять, например, почему модель не может умножить 2 больших числа с полной точностью. Мало кто в контексте LLM этот термин упоминает, поэтому кажется, что это вообще не про LLM.
Если задавать вопрос модели так, чтобы она дала ответ сразу, без разбивки на шага, то это будет именно работа аппроксимации как есть.
Сколько будет: 5215356.236 / 45335.21616584581. Правильный ответ 115.0398, ответ модели 115.04
Маленькая локальная модель тоже дает верный ответ:
Сколько будет: 552215356.2546736 / 45365435.216169284581. Правильный ответ 12.172601312504357, ответ модели 12.172576878624986
И тут легко увидеть, что чем ответ ближе к 0, тем лучше работает аппроксимирование, чем дальше от 0, тем больше расхождение. Это можно компенсировать расширенным датасетом, но так как перед LLM не стоит задача быть калькулятором, то этим никто не занимается.
Правильный ответ: 1215500.2223413868, ответ модели: 1215077.242, разница 0.03%
Так или иначе, эта особенность глубоких скрытых слоев и называется deep learning, а не просто machine learning. Особенность автоматически "учит" модель математике, программированию, языкам и так далее. Модель "сама" выводит правила и зависимости, находит признаки. Чем больше связей внутри скрытых слоев, тех самых параметров, тем больше возможностей для этой внутренней работы. Та самая знаменитая гифка от OpenAI как раз про это. А дальше уже начинают играть роль механизмы внимания, самовнимания, проявляются эмерджентные свойства.
мой посыл был про то, что LLM не обрабатывают сырую картинку. Ок, будет это не tesseract, а кастомное решение на OpenCV. Это все равно подмодуль, а не сама LLM
В своей сути вы правы, но не совсем.
Бывают мультимодальные модели, где обработкой изображений занимаются отдельные тензоры целой модели, например, визуальный трансформер (ViT), который обучен обрабатывать сырую картинку, но он выдает не какую-то конкретную информацию, а создает по картинке скрытый вектор, покрывающий её признаки. Этот скрытый вектор напрямую передается в текстовую LLM, и уже LLM может извлекать оттуда нужные признаки в зависимости от запроса. То есть это не внешний модуль, это некая гибридная архитектура, поэтому сравнивать одни мультимодальные модели можно с другими, на то как хорошо обучили ViT, как текстовая часть хорошо работает со скрытым ViT вектором и т.д.
Поэтому мультимодальная модель может давать любые ответы по картинке, а не строго заданные через внешний модуль, вроде распознания текста.
Llama-4-Maverick запущенный локально
DeepSeek - это не мультимодальная модель, в веб-интерфейсе распознанием текста занимается внешний модуль, который выдирает текст и просто передает его в контекст. В случае gpt-4o заявлено, что она мультимодальная.
Помимо изображений, мультимодальные могут обрабатывать звук, видео, голос, принцип у них одинаковый, создается латентное представление, с которым уже работает текстовая часть.
Примеров мультимодальных моделей много, в основном они конечно двумодальные, но бывают и более разнообразные:
Gemma3, Llama4, V-версии - работают и с текстом и с изображениями, на выходе текст
Janus-Pro-7B может принимать на вход и картинку и текст, выдавать картину или текст на выходе
Qwen2.5-Omni-7B может принимать звук, изображение, видео, текст на вход, на выходе выдает голос и текст
Добавим следующий результат: 287040000 + 2990000 = 289030000
Тут как раз тот самый сдвиг на 1 разряд, про который я писал. Поэтому модель сложила со смещением.
Не очень понятно почему никак нельзя встроить калькулятор в ллм, она ведь состоит из разных частей, не только основных слоев но и всяких там токенайзеров, почему там нет места для обычного калькулятора.
И токенизатор, и сэмплер с температурой - это 2 внешние для LLM системы, которые не встроены в LLM и находятся вне влияния LLM.
Тут есть интересный факт, складывать(и отнимать) огромные цифры гпт уже давно умеет без инструментов(калькулятора) то есть в уме по сути. Умножать не умеет.
В контексте статьи правильнее сказать, во время обучения не удалось полностью аппроксимировать умножение, то есть построить во внутренних слоях такое упрощение функции, которая, имея только входные данные, давала бы точный результат сразу. Какое-то приближение есть, так как ответ не рандомный, а приблизительно точен, как раз в рамках аппроксимирования.
Свойство скрытых глубоких слоев аппроксимировать (universal approximation theorem), в данном случае функцию f(a, b) = a * b на основе данных обучения, работает до определенных пределов за единицу вычислительных ресурсов на обучение, дальше уже требует непропорционально больших ресурсов. Cкорее всего если задаться этим целенаправленно, то умножение в модели можно аппроксимировать очень далеко, но врядтли такая задача перед обучением стоит.
А если говорить про умножение вообще, то есть разрешить модели делать всё по шагам, то умножение им дается.
Ответ 290403152 правильный
Только надо учитывать, что чем больше разряд, тем чаще модели имеют проблему нулей разрядов. Толи токенизации, толи температуры, толи всего вместе, тут надо глубже это изучать, и в итоге они путают разряды.
Пример
Умножение 48541234624*59513251238, ответ не правильный:
Должно быть 2888846691580816464512
Если попросить перепроверить модель, где она ошиблась, то ответ как раз будет с разрядами:
Если нули разрядов вернуть в правильный вид и сложить - то ответ будет правильный. Усложняя промпт, чтобы модель учитывала эту проблему с разрядами, можно дойти и до умножения 14-15-значиных чисел, может и дальше.
Я не понял, для чего "Force Model Expert Weights onto CPU". Скорость всегда падает, при этом расход VRAM очень низкий - 1 с чем то ГБ.
В этом и есть смысл. Скорость падает потому, что модель маленькая и почти влезает в VRAM, но таким подходом вы можете запускать большие MoE-модели и вам нужна будет не VRAM, а RAM, при этом получая ускорение с 1 GPU.
Падение скорости можно компенсировать даже на маленькой модели, просто в LM Studio пока добавили только поддержку параметра --cpu-moe, не доделав поддержку --n-cpu-moe N, чтобы заполнять свободную VRAM. Но и в таком виде это освобождает память под контекст, например, у qwen3 каждые 16к это +1.5гб VRAM с flash-attention.
Чтобы было нагляднее. На 4060 имитирую наличие только 10гб VRAM. У модели Qwen3-30b всего 49 слоев, параметр -ngl N указывает сколько слоев выгрузить на GPU.
Так как модель на половину влезает в 10гб, то во 2 варианте происходит просадка, но если снова заполнить тот же объем памяти, то происходит ускорение по сравнению с обычным режимом. И чем крупнее будет модель, тем увереннее 2 вариант будет уходить в ускорение.
Таким подходом можно ускорить, например, openai_gpt-oss-120b с 7.6 t/s до 16 t/s.
Мне кажется это извращением. Конкретно дипсик в мелких размерах всегда работал отвратно. И какая та изначально мелкая Gemma 3 27b размажет и на 70б дистил, и эту ужатую.
Как-то не особо размазал, скорее наоборот.
Современное квантование не просто усечение точности, это длинный путь по поиску алгоритмов квантования, динамическое квантование слабо затрагивает тензоры внимания, используется imatrix для выявления суперблоков которые надо слабее квантовать и т.д.
Экстремально квантованный дипсик, хоть и сильно глупеет, но всё еще остается дипсиком, а 27B никак не превратить в 671B.
Пример 1:
У Марии 5 сестер и 1 брат. Сколько сестёр у брата Марии? Подумай и дай ответ
Пример 2:
Напиши качественный эффект матрицы, только вместо символов используй 10 эмодзи-предметов, а сам эффект должен быть виден только внутри круга без рамки по центру. В одном index.html
Или это фэйк, или модель обучали на русском с опечатками.
Это не оригинальное качество, это запуск экстремально малого кванта. Русский язык достаточно сильно страдает от квантования из-за imatrix без примеров на русском языке. И выше просто был пример, что даже такой 1-битный квант, у которого качество -58%, может быть лучше, чем не квантованный дистиллят.
Квантование это не архивирование, это способ уменьшить вес модели за счет снижения качества. Чем крупнее модель, тем лучше она переносит квантование. В случае DeepSeek её размер 671 млрд параметров (671B), есть запас прочности, а, например, 8B уже будет полностью разрушена при таком экстремально низком квантовании:
Экстремально низкий квант маленькой модели Qwen3-8B-UD-IQ1_S
LM Studio успешно завелась и уже видит Vulkan GPU Немного упомяну про LM Studio – здесь ситуация хуже, скорость работы моделей примерно в 1,5 – 2 раза меньше, чем в ollama. Например, qwen3:8b-q4_K_M выдает здесь около 14 ток/с вместо 28 в ollama.
После установки патченых драйверов не удается сменить runtime в LM Studio на cuda версию? У вас же сейчас Vulkan в LM Studio и cuda в ollama.
gpt-oss:20b (37%/63%) выдает 10 ток/с, а dolphin-mixtral:8x7b (69%/31% - бОльшая часть на CPU) всего 7,2 ток/с. Но и нагрузка на GPU составляет всего около 10%, основная часть работает на CPU, поэтому такие тормоза.
Для MoE-моделей в свежей версии LM Studio добавили выгрузку moe-весов на CPU, оставляя все остальные на GPU. Испытайте галочку "Force MoE expert weights onto CPU", указав полную выгрузку слоев на GPU. На одной GPU с этой галочкой можно запускать и Qwen3-30B-A3B, и openai_gpt-oss-120b, и GLM-4.5-Air 110B, если обычной RAM памяти хватает, то и Qwen3-235B-A22B.
Вообще однобитные кванты существуют очень давно, но они же тупые как тюменский лодочник. То есть опять, запустить можно, но такая хрень получится. Те же дистилляты и то лучше работать будут, скорее всего.
DeepSeek-R1-Distill-Llama-70B ещё надо умудриться запустить. 70B это Dense-модель, для запуска приличного кванта нужно ~42gb VRAM, это в отличии от оригинального MoE, где для запуска хватит одной видеокарты для ускорения, остальное можно крутить в RAM. По сути сейчас все эти тяжелые MoE (gpt-oss-120b, GLM-4.5, Qwen3, DeepSeek, Kimi K2, LLama 4) запускать в разы проще, чем крупные монолитные dense варианты.
Но главная проблема дистиллятов deepseek в том, что они не deepseek.
Есть даже более экстремальный квант 1.71-битный v3.1 весом 133 ГиБ, он сильно теряет в качестве, на -58% по PPL, но даже такое качество остается пригодным для использования, и это всё еще тот же deepseek, а не имитация.
Во время рассуждения и ответа смесь непонятных слов, сам стиль ответа другой, качество ответа ниже. Так что дистиллят не будет лучше даже в сравнении с таким экстремальным квантом.
Если есть 192гб RAM, можно уже запускать DeepSeek-V3.1-IQ2_KS весом 193 ГиБ (новые кванты IQK, тоже динамическое квантование как у unsloth, только используют новые и лучшие алгоритмы квантования доступные только в ik_llama.cpp), это 2.472-битный квант, потеря качества 18% по PPL.
Скорость далека от идеальной, но 5 t/s можно условно считать уровнем комфортного использования. PP в 200 t/s позволяет обрабатывать большие контексты за минуты, а не за часы.
Поэтому и назвал это "практика показывает", видимо не точно выразился. На старших чипсетах в среднем лучше схематехника материнки, поэтому шансы завести память на высоких частотах выше.
Ещё там есть поддержка MTP (Multi-Token Prediction) для DeepSeek, это вариант спекулятивного декодирования, где специальный модуль который обучается вместе с моделью, в теории дающий ускорение до 1.8 раза. В llama.cpp недавно кто-то начал пытаться добавить поддержку, но пока только для GLM-4.5: https://github.com/ggml-org/llama.cpp/pull/15225
Как же вы надоели плодить эти сказки про потерю производительности на 4 плашках. У меня 4 х 24 работают даже быстрее чем 2 х 24.
Проблема с 48gb и новыми 64gb модулями, а не с 24, чем ниже объем, тем проще их разгонять. В целом завести 4 модулями 48gb не проблема, проблема сохранить скорость чтения памяти, которая важна для llm генерации.
У меня 2x48gb заводятся на XMP-6400 на i7-14700 + чипсете z790, это топовый чипсет предыдущего поколения, практика запуска 4x48gb показывает, что важен не только проц, но и чипсет.
2x48gb DDR5 6400
На 4x48gb тоже железо тянет только 5200 с плохими таймингами.
4x48gb DDR5 5200
Из-за неудобного расположения pcie слотов на MSI, что 2 видеокарты не влезают, пришлось перейти на Gigabyte, тоже на чипсете z790, и тут уже еле еле завелось на 4800 с плохими таймингами, по умолчанию сбрасывалось на 4000. Да, Gigabyte славится плохим разгоном памяти, и всё это уже скатывается в не просто "пошел и купил", а кучу нюансов, которые на сайте производителя не увидеть.
4x48gb DDR5 4800
Для генерации токенов важна линейная скорость чтения памяти, поэтому скорость генерации CPU-only просела на 31% на 4 модулях, по сравнению с 2 модулями.
вспомнить тот факт, что никакие ЯМ не могут правильно складывать и умножать любые наперед заданные числа без использования сторонних средств Т.е. ЯМ не могут на любой выборке из сети обучиться и выработать универсальную процедуру сложения и умножения чисел на конечном числе примеров, которые в них имеются. То чему могут обучиться среднестатистические школяры уже в начальных классах. Когда-то и такие числа могут быть востребованы, и что это будет за ИИ, который не может правильно обучиться достаточно простой для человеческого интеллекта задаче обобщения?
По вашему утверждению выходит, что школяр способен умножить 15580146 на 550624703 без калькулятора и не ошибиться ни в одной из цифр.
Многие ошибочно считают, что модель это большая коробка, где внутри она думает, размышляет как лучше ответить и на выходе просто выдает слова. Модель называется моделью не просто так, это не база данных, не коробка с мозгом, это моделирование какого-то процесса.
Люди собирали статистику, им больше доверия. Если проверять, то корректно.
Проверять корректно это не сказать "умножь 2 гигантских числа и выдай ответ".
Недавнее золото на олимпиаде от LLM показало, что модель способна делать куда более сложные вычисления, без сторонних средств, нужно "всего-лишь" 10 страниц детальных инструкций в системный промпт. Сам промпт уже выкладывали.
Для корректной проверки утверждения "ЯМ не могут на любой выборке из сети обучиться и выработать универсальную процедуру сложения и умножения чисел на конечном числе примеров" пойти хотя бы похожим путём:
### Выведи правило умножения чисел по шагам.
### Выведи правило складывая чисел по шагам.
### Умножай числа по всем шагам правила умножения.
### Cкладывай числа по всем шагам правила сложения.
### Если число большое, делай разбивку на большее количество шагов.
Умножь 15580146 и 550624703. Финальный ответ напиши в \boxed{}
Модель приступает к умножению
Модель приступает к сложению
8578776499523438 - ответ модели 8578813263946638 - правильный ответ
Ответ не правильный, хотя в общих чертах выглядит похоже, ошибка в нескольких разрядах. Тут нет проблемы с тем, что модель не может вывести универсальную процедуру, процедура выведена верно, следование процедуре тоже верное. Проверим вручную, где возникла ошибка.
Промежуточный результат умножения. С учётом сдвига, все числа правильные:
Внимательно приглядевшись, видно, что проблема тут начинается на 3 разряде. Вместо двух 0, добавлен 1 ноль. Если вручную сложить все числа с правильным добавлением 0 разрядов, то ответ будет правильный.
И это проблема не модели, а проблема токенизатора.
Даже если у LLM будут рекурсивные вычисления внутри, ещё до вывода наружу, это не поможет умножать столь гигантские числа без ошибок в паре цифр просто по статистике, потому что остается фактор температуры и токенизатора - внешние для модели факторы. Это как оценивать возможности модели по тому, может ли она подсчитать количество r в strawberry, игнорируя фактор токенизатора.
Снизим температуру до 0 и попробуем рассказать модели, что у неё есть проблема токенизатора. Во всех случаях запуск локально на модели Qwen3-Coder-480B-A35B-Instruct-UD-Q2_K_XL, каждый раз новый чистый чат, чтобы не было фактора кэширования или ещё чего-то.
Изменим промпт так:
### Выведи правило умножения чисел по шагам.
### Выведи правило складывая чисел по шагам.
### Умножай числа по всем шагам правила умножения.
### Cкладывай числа по всем шагам правила сложения.
### Если число большое, делай разбивку на большее количество шагов.
Учти, что у тебя проблема с токенизатором, когда ты добавляешь разрядные 0, может быть ошибка с их количеством. Тебе нужно придумать другой способ сложения после умножения.
Умножь 15580146 и 550624703. Финальный ответ напиши в \boxed{}
Модель считает с учётом проблемы токенизатора
8578813263946638 - ответ модели 8578813263946638 - правильный ответ
Это помогло избавиться от двух внешних факторов и теперь результат правильный.
Это не означает, что модель всегда будет считать правильно даже так, это чтобы показать, что "если проверять, то корректно", то внешние от модели факторы играют большую роль.
Чтобы это понять не нужно даже проводить специальных исследований, а вспомнить тот факт, что никакие ЯМ не могут правильно складывать и умножать любые наперед заданные числа без использования сторонних средств, см. 1, 2 с примерами. Т.е. ЯМ не могут на любой выборке из сети обучиться и выработать универсальную процедуру сложения и умножения чисел на конечном числе примеров, которые в них имеются. То чему могут обучиться среднестатистические школяры уже в начальных классах.
По 1 ссылке как раз противоположное говорится, что модели могут это сделать. По 2 ссылке не корректный эксперимент, поэтому там даже 5-значные числа не складывались, промпт автора требовал в ответ только число.
Более правильный промп был бы такой, который при этом легко парсить:
Ты получаешь на вход арифметическое выражение.
Проведи все необходимые вычисления и в конце напиши ответ в блоке \boxes{}.
Само выражение:
5234535646 * 654 + 5243564363456456
Ответ 5246987749768940 правильный
Конечно LLM это не калькулятор, на больших числах точность не будет 100% в любом случае, но вывести какие-то правила и следовать им они могут, могут "прикинуть" ответ, если числа большие, чтобы потом сделать более точные вычисления:
Пример деления больших чисел
62 правильный ответ
И так как модель это не калькулятор, она может складывать и гигантские BigInt числа, которые не укладываются в стандартный диапазон js чисел или калькулятора. Модель будет долго высчитывать это по шагам по правилам сложения и в итоге выдаст правильный ответ:
Для запуска нормальной модели нужна видео карточка за 1500$ и памятью на 32гига. Нормальные модели начинаются от 30B.
Для запуска 30B из статьи нужно всего 2 гб VRAM и будет работать на скорости 10+ t/s.
В статье Qwen3-Coder-30B, но полное название модели Qwen3-Coder-30B-A3B. A3B - означает, что это MoE модель, где на каждый токен активных параметров всего 3B.
В llama.cpp есть оптимизация для работы с MoE моделями через --override-tensor exps=CPU или просто --cpu-moe. Этот параметр отправляет MoE-веса на CPU, а тензоры внимания и общие ffn тензоры всех слоев на GPU. Это работает так, что даже настоящую большую DeepSeek R1 671B можно запустить на игровом ПК и особо не заскучать дожидаясь ответов.
Несколько дней назад в LM Studio 0.3.23 добавили возможность активировать этот параметр. Во время загрузки модели нужно включить "Force MoE expert weights onto CPU" и выставить полную выгрузку всех слоёв несмотря на предупреждение о том, что памяти не хватит. Flash Attention тоже стоит включить, это сэкономит много памяти контекста.
LM Studio 0.3.23
Нужно всего 2 Гб VRAM + контекст. Например, на 32к контекста потребуется +2 Гб. Скорость работы на 4060ti + i7-14700 получилась 14 t/s.
LM Studio Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf
Скорость можно повысить, если воспользоваться параметром --n-cpu-moe и заполнить VRAM до отказу, сколько есть. Этого параметра пока нет в LM Studio, поэтому нужно запускать llama.cpp напрямую. llama-server создает и веб-клиент и openai completions api, как и LM Studio Local Server, поэтому для работы с Continue ничего не изменится.
И на таких маленьких моделях лучше брать квант побольше, не тот, что в LM Studio предлагается по умолчанию. По умолчанию там Q4_K_M, лучше взять Q5_K_M или сразу Q6_K. Ещё лучше обратить внимание на имя авторов квантов и поискать среди них Unsloth, у них выбрать кванты с припиской XL, это динамическое квантование UD, при том же размере дает выше качество.
Сейчас много разных MoE-моделей. Можно запустить и openai_gpt-oss-120b, там тоже всего 5.1B активных параметров, для запуска нужно 4гб VRAM и 62гб RAM. Скорость просядет, так как объем модели куда выше, и уже много тензоров считается на CPU, но всё еще приемлемая.
Лучше не выдумывать наименования моделям, и не следовать за теми, кто так делает. Официально релиз назвали Kimi-K2-0905, а не K2.1, а предыдущий релиз они теперь называют Kimi-K2-0711.
0905 и 0711 - это дата релиза, самый распространенный способ именования у моделей.
Когда вышел DeepSeek V3-0324, его люди назвали 3.1 и на многих сайтах он был записан как 3.1, но 2 недели назад вышел настоящий V3.1 и до сих пор в обсуждениях не все могут понять, о какой версии идет речь.
Новая версия с 256к контекстом уже доступна: https://www.kimi.com/
Работает с текстом целой книги на 250к токенов вполне нормально:
Это не важно, деление, плавающая запятая или что угодно, хоть самые сложные и замороченные формулы, всё это можно упростить и вывести примерную формулу, например, как jpg упрощает оригинал и сжимает его, но разницу на глаз можно и не заметить. Внутри LLM умножение не выводится из сложения, аппроксимация не про это.
У LLM во время обучения, какие бы числа и действия на вход вы не дали, за счет свойств внутренних скрытых слоев, происходит автоматическая попытка вывести новую функцию из входящих данных и ожидаемого результата. Эта выведенная функция будет упрощенной версией изначальной функции, она будет работать очень быстро, но не точно, это и есть аппроксимация.
Может термин "аппроксимировать" слишком нетипичен для восприятия, но это математический и научный метод, именно он работает внутри LLM. И в контексте статьи позволяет понять, например, почему модель не может умножить 2 больших числа с полной точностью. Мало кто в контексте LLM этот термин упоминает, поэтому кажется, что это вообще не про LLM.
Если задавать вопрос модели так, чтобы она дала ответ сразу, без разбивки на шага, то это будет именно работа аппроксимации как есть.
Маленькая локальная модель тоже дает верный ответ:
И тут легко увидеть, что чем ответ ближе к 0, тем лучше работает аппроксимирование, чем дальше от 0, тем больше расхождение. Это можно компенсировать расширенным датасетом, но так как перед LLM не стоит задача быть калькулятором, то этим никто не занимается.
Так или иначе, эта особенность глубоких скрытых слоев и называется deep learning, а не просто machine learning. Особенность автоматически "учит" модель математике, программированию, языкам и так далее. Модель "сама" выводит правила и зависимости, находит признаки. Чем больше связей внутри скрытых слоев, тех самых параметров, тем больше возможностей для этой внутренней работы. Та самая знаменитая гифка от OpenAI как раз про это. А дальше уже начинают играть роль механизмы внимания, самовнимания, проявляются эмерджентные свойства.
В своей сути вы правы, но не совсем.
Бывают мультимодальные модели, где обработкой изображений занимаются отдельные тензоры целой модели, например, визуальный трансформер (ViT), который обучен обрабатывать сырую картинку, но он выдает не какую-то конкретную информацию, а создает по картинке скрытый вектор, покрывающий её признаки. Этот скрытый вектор напрямую передается в текстовую LLM, и уже LLM может извлекать оттуда нужные признаки в зависимости от запроса. То есть это не внешний модуль, это некая гибридная архитектура, поэтому сравнивать одни мультимодальные модели можно с другими, на то как хорошо обучили ViT, как текстовая часть хорошо работает со скрытым ViT вектором и т.д.
Поэтому мультимодальная модель может давать любые ответы по картинке, а не строго заданные через внешний модуль, вроде распознания текста.
DeepSeek - это не мультимодальная модель, в веб-интерфейсе распознанием текста занимается внешний модуль, который выдирает текст и просто передает его в контекст. В случае gpt-4o заявлено, что она мультимодальная.
Помимо изображений, мультимодальные могут обрабатывать звук, видео, голос, принцип у них одинаковый, создается латентное представление, с которым уже работает текстовая часть.
Примеров мультимодальных моделей много, в основном они конечно двумодальные, но бывают и более разнообразные:
Gemma3, Llama4, V-версии - работают и с текстом и с изображениями, на выходе текст
Janus-Pro-7B может принимать на вход и картинку и текст, выдавать картину или текст на выходе
Qwen2.5-Omni-7B может принимать звук, изображение, видео, текст на вход, на выходе выдает голос и текст
Тут как раз тот самый сдвиг на 1 разряд, про который я писал. Поэтому модель сложила со смещением.
И токенизатор, и сэмплер с температурой - это 2 внешние для LLM системы, которые не встроены в LLM и находятся вне влияния LLM.
В контексте статьи правильнее сказать, во время обучения не удалось полностью аппроксимировать умножение, то есть построить во внутренних слоях такое упрощение функции, которая, имея только входные данные, давала бы точный результат сразу. Какое-то приближение есть, так как ответ не рандомный, а приблизительно точен, как раз в рамках аппроксимирования.
Свойство скрытых глубоких слоев аппроксимировать (universal approximation theorem), в данном случае функцию f(a, b) = a * b на основе данных обучения, работает до определенных пределов за единицу вычислительных ресурсов на обучение, дальше уже требует непропорционально больших ресурсов. Cкорее всего если задаться этим целенаправленно, то умножение в модели можно аппроксимировать очень далеко, но врядтли такая задача перед обучением стоит.
А если говорить про умножение вообще, то есть разрешить модели делать всё по шагам, то умножение им дается.
Только надо учитывать, что чем больше разряд, тем чаще модели имеют проблему нулей разрядов. Толи токенизации, толи температуры, толи всего вместе, тут надо глубже это изучать, и в итоге они путают разряды.
Пример
Умножение 48541234624*59513251238, ответ не правильный:
Если попросить перепроверить модель, где она ошиблась, то ответ как раз будет с разрядами:
Если нули разрядов вернуть в правильный вид и сложить - то ответ будет правильный. Усложняя промпт, чтобы модель учитывала эту проблему с разрядами, можно дойти и до умножения 14-15-значиных чисел, может и дальше.
Есть gguf для SDXL, Flux, Flux Kontext. Запускать проще всего в WebUI Forge.
Замеры скорости на flux1-dev-Q6_K.gguf для сравнения:
Для Flux нужно 4 файла:
models\Stable-diffusion\flux1-dev-Q6_K.gguf
models\text_encoder\t5xxl_fp8_e4m3fn.safetensors
models\VAE\ae.safetensors
models\VAE\clip_l.safetensors
Примерно вот так должно выглядеть:
Вариант 1 это запуск моделей (Qwen3-30B-A3B-Instruct-2507-UD-Q5_K_XL, openai_gpt-oss-120b-MXFP4) по умолчанию. Запуск напрямую через llama.cpp.
нужно скачать llama-LASTVER-bin-win-cuda-12.4-x64.zip там будет llama-server.exe
скачать cudart-llama-bin-win-cuda-12.4-x64.zip и разархивировать в папку с llama.cpp
запуск из консоли llama-server, после запуска будет написан url, который надо открыть в браузере, команды запуска написаны выше.
В этом и есть смысл. Скорость падает потому, что модель маленькая и почти влезает в VRAM, но таким подходом вы можете запускать большие MoE-модели и вам нужна будет не VRAM, а RAM, при этом получая ускорение с 1 GPU.
Падение скорости можно компенсировать даже на маленькой модели, просто в LM Studio пока добавили только поддержку параметра
--cpu-moe, не доделав поддержку--n-cpu-moe N, чтобы заполнять свободную VRAM. Но и в таком виде это освобождает память под контекст, например, у qwen3 каждые 16к это +1.5гб VRAM с flash-attention.Подробнее как это работает можно почитать тут: Запускаем настоящую DeepSeek R1 671B на игровом ПК и смотрим вменяемая ли она на огромном контексте (160к)
Чтобы было нагляднее. На 4060 имитирую наличие только 10гб VRAM. У модели Qwen3-30b всего 49 слоев, параметр
-ngl Nуказывает сколько слоев выгрузить на GPU.3 варианта запуска:
.\llama-server.exe -m "Qwen3-30B-A3B-UD-Q5_K_XL.gguf" -fa -ngl 22.\llama-server.exe -m "Qwen3-30B-A3B-UD-Q5_K_XL.gguf" -fa -cmoe -ngl 99.\llama-server.exe -m "Qwen3-30B-A3B-UD-Q5_K_XL.gguf" -fa -ncmoe 30 -ngl 99Так как модель на половину влезает в 10гб, то во 2 варианте происходит просадка, но если снова заполнить тот же объем памяти, то происходит ускорение по сравнению с обычным режимом. И чем крупнее будет модель, тем увереннее 2 вариант будет уходить в ускорение.
Таким подходом можно ускорить, например, openai_gpt-oss-120b с 7.6 t/s до 16 t/s.
Как-то не особо размазал, скорее наоборот.
Современное квантование не просто усечение точности, это длинный путь по поиску алгоритмов квантования, динамическое квантование слабо затрагивает тензоры внимания, используется imatrix для выявления суперблоков которые надо слабее квантовать и т.д.
Экстремально квантованный дипсик, хоть и сильно глупеет, но всё еще остается дипсиком, а 27B никак не превратить в 671B.
Пример 1:
Пример 2:
Это не оригинальное качество, это запуск экстремально малого кванта. Русский язык достаточно сильно страдает от квантования из-за imatrix без примеров на русском языке.
И выше просто был пример, что даже такой 1-битный квант, у которого качество -58%, может быть лучше, чем не квантованный дистиллят.
Квантование это не архивирование, это способ уменьшить вес модели за счет снижения качества. Чем крупнее модель, тем лучше она переносит квантование. В случае DeepSeek её размер 671 млрд параметров (671B), есть запас прочности, а, например, 8B уже будет полностью разрушена при таком экстремально низком квантовании:
После установки патченых драйверов не удается сменить runtime в LM Studio на cuda версию? У вас же сейчас Vulkan в LM Studio и cuda в ollama.
Для MoE-моделей в свежей версии LM Studio добавили выгрузку moe-весов на CPU, оставляя все остальные на GPU.
Испытайте галочку "Force MoE expert weights onto CPU", указав полную выгрузку слоев на GPU. На одной GPU с этой галочкой можно запускать и Qwen3-30B-A3B, и openai_gpt-oss-120b, и GLM-4.5-Air 110B, если обычной RAM памяти хватает, то и Qwen3-235B-A22B.
DeepSeek-R1-Distill-Llama-70B ещё надо умудриться запустить. 70B это Dense-модель, для запуска приличного кванта нужно ~42gb VRAM, это в отличии от оригинального MoE, где для запуска хватит одной видеокарты для ускорения, остальное можно крутить в RAM. По сути сейчас все эти тяжелые MoE (gpt-oss-120b, GLM-4.5, Qwen3, DeepSeek, Kimi K2, LLama 4) запускать в разы проще, чем крупные монолитные dense варианты.
Но главная проблема дистиллятов deepseek в том, что они не deepseek.
Есть даже более экстремальный квант 1.71-битный v3.1 весом 133 ГиБ, он сильно теряет в качестве, на -58% по PPL, но даже такое качество остается пригодным для использования, и это всё еще тот же deepseek, а не имитация.
Тот же вопрос не квантованному дистилляту 70B на openrouter.
Во время рассуждения и ответа смесь непонятных слов, сам стиль ответа другой, качество ответа ниже. Так что дистиллят не будет лучше даже в сравнении с таким экстремальным квантом.
Если есть 192гб RAM, можно уже запускать DeepSeek-V3.1-IQ2_KS весом 193 ГиБ (новые кванты IQK, тоже динамическое квантование как у unsloth, только используют новые и лучшие алгоритмы квантования доступные только в ik_llama.cpp), это 2.472-битный квант, потеря качества 18% по PPL.
Скорость далека от идеальной, но 5 t/s можно условно считать уровнем комфортного использования. PP в 200 t/s позволяет обрабатывать большие контексты за минуты, а не за часы.
Поэтому и назвал это "практика показывает", видимо не точно выразился. На старших чипсетах в среднем лучше схематехника материнки, поэтому шансы завести память на высоких частотах выше.
Поддержка есть, но на сколько хорошо работает, это надо тестировать.
https://docs.vllm.ai/en/stable/features/spec_decode.html
Ещё там есть поддержка MTP (Multi-Token Prediction) для DeepSeek, это вариант спекулятивного декодирования, где специальный модуль который обучается вместе с моделью, в теории дающий ускорение до 1.8 раза. В llama.cpp недавно кто-то начал пытаться добавить поддержку, но пока только для GLM-4.5: https://github.com/ggml-org/llama.cpp/pull/15225
Проблема с 48gb и новыми 64gb модулями, а не с 24, чем ниже объем, тем проще их разгонять. В целом завести 4 модулями 48gb не проблема, проблема сохранить скорость чтения памяти, которая важна для llm генерации.
У меня 2x48gb заводятся на XMP-6400 на i7-14700 + чипсете z790, это топовый чипсет предыдущего поколения, практика запуска 4x48gb показывает, что важен не только проц, но и чипсет.
На 4x48gb тоже железо тянет только 5200 с плохими таймингами.
Из-за неудобного расположения pcie слотов на MSI, что 2 видеокарты не влезают, пришлось перейти на Gigabyte, тоже на чипсете z790, и тут уже еле еле завелось на 4800 с плохими таймингами, по умолчанию сбрасывалось на 4000. Да, Gigabyte славится плохим разгоном памяти, и всё это уже скатывается в не просто "пошел и купил", а кучу нюансов, которые на сайте производителя не увидеть.
Для генерации токенов важна линейная скорость чтения памяти, поэтому скорость генерации CPU-only просела на 31% на 4 модулях, по сравнению с 2 модулями.
По вашему утверждению выходит, что школяр способен умножить 15580146 на 550624703 без калькулятора и не ошибиться ни в одной из цифр.
Многие ошибочно считают, что модель это большая коробка, где внутри она думает, размышляет как лучше ответить и на выходе просто выдает слова. Модель называется моделью не просто так, это не база данных, не коробка с мозгом, это моделирование какого-то процесса.
Проверять корректно это не сказать "умножь 2 гигантских числа и выдай ответ".
Недавнее золото на олимпиаде от LLM показало, что модель способна делать куда более сложные вычисления, без сторонних средств, нужно "всего-лишь" 10 страниц детальных инструкций в системный промпт. Сам промпт уже выкладывали.
Для корректной проверки утверждения "ЯМ не могут на любой выборке из сети обучиться и выработать универсальную процедуру сложения и умножения чисел на конечном числе примеров" пойти хотя бы похожим путём:
Модель приступает к умножению
Модель приступает к сложению
8578776499523438 - ответ модели
8578813263946638 - правильный ответ
Ответ не правильный, хотя в общих чертах выглядит похоже, ошибка в нескольких разрядах. Тут нет проблемы с тем, что модель не может вывести универсальную процедуру, процедура выведена верно, следование процедуре тоже верное. Проверим вручную, где возникла ошибка.
Промежуточный результат умножения. С учётом сдвига, все числа правильные:
Значит ошибка должна быть на этапе сложения. Посмотрим, что выдала модель:
Внимательно приглядевшись, видно, что проблема тут начинается на 3 разряде. Вместо двух 0, добавлен 1 ноль. Если вручную сложить все числа с правильным добавлением 0 разрядов, то ответ будет правильный.
И это проблема не модели, а проблема токенизатора.
Даже если у LLM будут рекурсивные вычисления внутри, ещё до вывода наружу, это не поможет умножать столь гигантские числа без ошибок в паре цифр просто по статистике, потому что остается фактор температуры и токенизатора - внешние для модели факторы. Это как оценивать возможности модели по тому, может ли она подсчитать количество r в strawberry, игнорируя фактор токенизатора.
Снизим температуру до 0 и попробуем рассказать модели, что у неё есть проблема токенизатора. Во всех случаях запуск локально на модели Qwen3-Coder-480B-A35B-Instruct-UD-Q2_K_XL, каждый раз новый чистый чат, чтобы не было фактора кэширования или ещё чего-то.
Изменим промпт так:
Модель считает с учётом проблемы токенизатора
8578813263946638 - ответ модели
8578813263946638 - правильный ответ
Это помогло избавиться от двух внешних факторов и теперь результат правильный.
Это не означает, что модель всегда будет считать правильно даже так, это чтобы показать, что "если проверять, то корректно", то внешние от модели факторы играют большую роль.
По 1 ссылке как раз противоположное говорится, что модели могут это сделать.
По 2 ссылке не корректный эксперимент, поэтому там даже 5-значные числа не складывались, промпт автора требовал в ответ только число.
Более правильный промп был бы такой, который при этом легко парсить:
Конечно LLM это не калькулятор, на больших числах точность не будет 100% в любом случае, но вывести какие-то правила и следовать им они могут, могут "прикинуть" ответ, если числа большие, чтобы потом сделать более точные вычисления:
Пример деления больших чисел
И так как модель это не калькулятор, она может складывать и гигантские BigInt числа, которые не укладываются в стандартный диапазон js чисел или калькулятора. Модель будет долго высчитывать это по шагам по правилам сложения и в итоге выдаст правильный ответ:
Ответ от LLM и результат в js совпадают
del
Для запуска 30B из статьи нужно всего 2 гб VRAM и будет работать на скорости 10+ t/s.
В статье Qwen3-Coder-30B, но полное название модели Qwen3-Coder-30B-A3B. A3B - означает, что это MoE модель, где на каждый токен активных параметров всего 3B.
В llama.cpp есть оптимизация для работы с MoE моделями через
--override-tensor exps=CPUили просто--cpu-moe. Этот параметр отправляет MoE-веса на CPU, а тензоры внимания и общие ffn тензоры всех слоев на GPU. Это работает так, что даже настоящую большую DeepSeek R1 671B можно запустить на игровом ПК и особо не заскучать дожидаясь ответов.Несколько дней назад в LM Studio 0.3.23 добавили возможность активировать этот параметр. Во время загрузки модели нужно включить "Force MoE expert weights onto CPU" и выставить полную выгрузку всех слоёв несмотря на предупреждение о том, что памяти не хватит. Flash Attention тоже стоит включить, это сэкономит много памяти контекста.
Нужно всего 2 Гб VRAM + контекст. Например, на 32к контекста потребуется +2 Гб. Скорость работы на 4060ti + i7-14700 получилась 14 t/s.
Скорость можно повысить, если воспользоваться параметром
--n-cpu-moeи заполнить VRAM до отказу, сколько есть. Этого параметра пока нет в LM Studio, поэтому нужно запускать llama.cpp напрямую. llama-server создает и веб-клиент и openai completions api, как и LM Studio Local Server, поэтому для работы с Continue ничего не изменится..\llama-server.exe -m "D:\models\lmstudio-community\Qwen3-Coder-30B-A3B-Instruct-GGUF\Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf" --n-cpu-moe 16 -ngl 99 -fa -c 32768Загружено 15гб VRAM, скорость выросла до 38 t/s.
И на таких маленьких моделях лучше брать квант побольше, не тот, что в LM Studio предлагается по умолчанию. По умолчанию там Q4_K_M, лучше взять Q5_K_M или сразу Q6_K. Ещё лучше обратить внимание на имя авторов квантов и поискать среди них Unsloth, у них выбрать кванты с припиской XL, это динамическое квантование UD, при том же размере дает выше качество.
Сейчас много разных MoE-моделей. Можно запустить и openai_gpt-oss-120b, там тоже всего 5.1B активных параметров, для запуска нужно 4гб VRAM и 62гб RAM. Скорость просядет, так как объем модели куда выше, и уже много тензоров считается на CPU, но всё еще приемлемая.
Для Jan-V1 нужно включить не browsermcp, а serper, получив бесплатный ключ.