Обычно на ik_llama не должно быть такой просадки при увеличении контекста даже на P40, так как их основная особенность это сохранение производительности на огромном контексте.
Но так как речь идет про GPT-OSS, то ik_llama не лучший вариант для запуска, автор ik_llama решил не доводить поддержку SWA в GPT-OSS до конца.
Вообще, кванты, которые не созданы специально для ik_llama (то есть IQK кванты) я стараюсь запускать на ванильной llama.cpp. По ощущениям после длительного расхождения основной ветки и форка там как будто бы чаще проявляются какие-то разные проблемы для не родных квантов, особенно это проявляется в mxfp4, в котором и есть GPT-OSS.
Попробуйте протестировать ваш сценарий на оригинальной llama.cpp с включенным -cmoe.
Чаще чем на каждом токене. 36 + 1 слоев, в каждом слое свой роутер и свои 128 экспертов, итого 36 роутеров и гора экспертов, прямой проход по нейросети активирует последовательно эти 36 роутеров и каждый выбирает по 4 эксперта своего слоя. И только проделав всё это генерируется 1 новый токен.
Работает за счёт того, что в 36 слоях 36 блоков внимания, за один проход нейросети надо рассчитать все 36 блоков. При активации -cmoe в VRAM загружены не эксперты, а эти тензоры внимания, эксперты же остались на CPU в обычной RAM.
Ускорение происходит за счёт того, что GPU теперь считает только тензоры внимания, а не разреженные слои с экспертами, из-за этого GPU постоянно ускоряет вычисления для каждого слоя, а в классическом варианте GPU бы простаивала как только прошли слои, которые были выгружены целиком.
Ryzen AI Max+ 395 (Strix Halo) же уже давно в продаже и уже давно оттестирован. С такой же унифицированной памятью и объемом в 128 Гб. В таком же форм факторе маленькой коробочки, на озонах по 180к продается.
По бенчмаркам производительность генерации токенов TG плюс-минус такая же как у DGX Spark, но стоит в 2 раза дешевле. Нет CUDA ядер, но для LLM уже давно поддерживается Vulkan или ROCm.
ту же GPT-OSS 120B вы просто не запустите на чем-то меньше 96Гб видеопамяти(работать будет крайне медленно), есть задачи где 64Гб пока хватит, а именно работа с генерацией изображений(stable diffusion) и там лучше иметь чип быстрее.
Так GPT-OSS-120B изначально делали таким, чтобы его на домашних ПК можно было запускать, так что 96 Гб ему не требуется.
Вообще, и для GPT-OSS-120B и для картинок хватит 8 Гб. GPT-OSS-120B не так сложно запустить с хорошей скоростью в 20-30 t/s на обычной видеокарте, тут важнее, чтобы хватило RAM, а не VRAM: https://habr.com/ru/articles/961478/
GPT-OSS-120B
Для тяжеловесной Qwen Image хватает 16 Гб, а Stable Diffusion XL же совсем не требовательна, для её запуска хватает 8 Гб, как и для более тяжелого Flux, для них к тому же есть gguf. Даже для генерации видео в Wan2.2 14B хватает 16 Гб.
Хочу вот ещё одну хорошую moe модельку llama4:16x17b попробовать.
llama4:16x17b - это Llama-4-Scout, очень слабая модель. Попробуйте GLM-4.5-Air-MXFP4, и скоро должна выйти GLM-4.6-Air, эта модель куда интереснее и часто бывает лучше чем GPT-OSS.
Ну вроде vram получается суммируется в 32гб + распараллеливание задач аж на целых два достаточно производительных чипа. Стоит ли игра свеч?
Есть 2 основных способа объединить GPU:
тензорный параллелизм (Tensor Parallelism), тензоры одной операции разбиваются на блоки, и каждая карта параллельно считает свой блок, потом объединяет результат.
конвейерный параллелизм (Pipeline Parallelism), на разные карты уходят разные слои, сначала работает первая карта, потом вторая.
В первом случае вы получаете и распараллеливание вычислений и удвоение объема VRAM, а во втором случае в основном только удвоение VRAM, но в батчинге можно получить ускорение. Для тензорного параллелизма нужно использовать vLLM или ExLlama, но там не получится использовать связку GPU+CPU.
В llama.cpp реализовано что-то похожее через --split-mode row, но работает не очень хорошо, хотя некоторые пишут, что получают ускорение на двух GPU.
Ещё 5080 поддерживает вычисления в fp4, gpt-oss как раз в fp4 (в MXFP4, ещё есть улучшенный NVFP4, который в llama.cpp пока не поддерживается), если добавить карту которая не поддерживает fp4, то скорее всего скорость упадет. И надо будет использовать Vulkan, чтобы объединить Nvidia + AMD, это ещё потери скорости.
Скажите пожалуйста, я могу на llama-server запустить уже скачанную для Ollama модель или так же придётся загружать с hf формат gguf модельки?
У Ollama свой несовместимый формат-обертка, можно попробовать переименовать самый большой файл с хешированным именем, но не факт, что сработает. Проще скачать заново.
Плюс можно сразу взять кванты поинтереснее, например, от Unsloth с их динамическим квантованием UD, или от Ubergarm который выкладывает кванты для ik_llama, которые себя лучше показывают, чем стандартные кванты llama.cpp (создатель ik_llama и есть создатель квантов в llama.cpp, он сделал форк чтобы делать новые кванты). Или взять кванты MXFP4 не только для GPT-OSS, так как они должны быть быстрее на 5080, где есть нативная поддержка fp4.
И можно качать модели которые состоят из множества файлов, вроде 5 файлов GLM-4.5-Air-MXFP4_MOE-00001-of-00005.gguf, при запуске просто указать путь к 1 файлу.
Но как только начинаю играться с параметрами, шаг влево - шаг вправо забивает полностью vram (5080 16гб) и под завязку оперативу (96гб).
В деталях на счёт памяти может ошибаюсь, но смысл примерно такой. В Windows по умолчанию shared memory для GPU, а сам mmap, в отличии от Linux, занимает всю память под модель, и не высвобождает, что ушло на GPU. -ncmoe 8 - это значит, что только 8 слоев пойдут на CPU (не на GPU). Если всего слоев 37, значит 29 пойдут на GPU, то есть потребуется ~50Гб для этого. Windows будет пытаться использовать такое количество памяти для GPU в shared, и сам mmap резервирует всю модель. В итоге двойной перерасход памяти.
как мне задействовать, ну скажем 14гб vram для большей производительности?
Удобного способа нет, поэтому просто какой есть:
Сначала узнать сколько слоев у модели, это показывается в консоли при загрузке. Например, у GLM-4.6 94 слоя, а у GPT-OSS-120B слоев 37.
Выставить в ncmoe число равное количеству слоев и по шагам уменьшат его в сторону 0. Тут работает инвертированный принцип, а не привычный как у ngl.
Смотреть на количество MiB загружаемого на CUDA0 и добиваться нужного количества занятой VRAM.
Надо учитывать размер контекста, там тоже это пишется. Чтобы снизить расход VRAM на контекст, можно использовать -ctk q8_0 -ctv q8_0, это квантование KV-кэша в Q8_0, немного снизит качество, но в 2 раза снизит расход памяти на контекст.
--jinja - это флаг для встроенного в gguf шаблона чата, чтобы текст правильно выводился. На производительность не влияет, но влияет на качество ответа. Нужно указывать не везде, только у квантов где это указано. В рамках одной модели могут варианты с этим флагом и без него.
Главное следить, чтобы память GPU не выходила за пределы своего максимума. Если залезет хоть немного в shared (именно модель, а не работа ОС), то это сильно снизит скорость генерации. Отключение "CUDA: политика резервной системной памяти" больше не помогает, поэтому приходится вручную следить за этим либо через диспетчер задач, либо через nvidia-smi -l 2.
Речь, не про то, что работает, а про то как работает. Спокойной работает даже с диска - это не секрет, вопрос в том с какой скоростью.
Через выгрузку на GPU можно получить ускорение на Dense моделях уже давно, но на MoE моделях это почти не работает, тут нужен другой подход, когда выгружаются на GPU не отдельные слои, а тензоры внимания и часть ffn всех слоев сразу.
Через -cmoe или --cpu-moe можно переключиться на такой режим и получить ускорение по сравнению со стандартным режимом. Это дает ускорение в 1.5-2 раза с меньшим расходом памяти.
Через -ncmoe N можно ещё эффективнее загрузить всю доступную VRAM, например, все 16гб VRAM и получить не 11 t/s, а 16 t/s, прирост ещё в 45%.
Сейчас это можно сделать на llama.cpp, на котором построены все остальные клиенты, включая LM Studio и Ollama, что тоже не секрет, но они предоставляют не полную поддержку всех фич, которая есть в движке. В LM Studio недавно добавили галочку для cmoe, но не ncmoe.
Если нужно десктоп приложение, то фаворита два: LM Studio и Msty Studio.
Оба с закрытым кодом, а открытый Jan.ai им не конкурент. Есть другая популярная опенсорсная полнофункциональная альтернатива Cherry Studio: https://github.com/CherryHQ/cherry-studio
Если лезть в дебри ollama, то есть в консоль, то можно заглянуть и в оригинал. В llama.cpp уже встроен простой и удобный веб-клиент, на котором можно развернуться запуская модели на GPU + CPU через параметры -cmoe или -ncmoe N, которые до сих пор не поддерживаются в ollama. -cmoe позволяет запустить на слабом железе не только GPT-OSS-120b или GLM-4.5-Air 110b, но и более крупные модели, если хватает обычной RAM памяти.
В ежедневных готовых сборках llama.cpp есть llama-server.exe, на huggingface есть команда для скачивания и запуска:
Модель GPT-OSS-120b весит 61гб, в домашние GPU она не лезет, но так как это MoE модель, то с помощью параметра -cmoe её можно разместить равномерно по GPU+CPU, всё что нужно на каждом шагу в GPU, всё остальное на CPU. На 64к контекста нужно всего 8гб VRAM: llama-server -hf ggml-org/gpt-oss-120b-GGUF -c 65536 -fa -cmoe --jinja
Если модель уже скачана, то llama-server -m "D:\mdels\gpt-oss-120b-MXFP4.gguf" -c 65536 -fa -cmoe --jinja
Даже на медленной 4060 можно получить скорость чуть выше 11 t/s на 47к контекста:
Да, содержимое файла модели мапится на память через mmap не загружаясь в память по настоящему. Для программы всё выглядит так, что модель находится целиком в памяти и во время чтения тензоров модели ОС сама подгружает данные с диска и выгружает их.
Всё это работает очень медленно, даже если тензоры внимания и первые общие слоя (у deepseek это первые 3 слоя) вынести на GPU, обычной RAM не совсем уж мало, а nvme не самый медленный, то можно получить 1-2 t/s с диска. У меня на 64гб удавалось выжимать 3.3 t/s на 4090.
В целом EvoPress показывает преимущество над UD при одинаковом среднем числе бит на параметр. Чем ниже показатель PPL, тем лучше.
Unsloth Dynamic - вариант гетерогенного квантования, как и тот, что предложен в статье, только UD использует imatrix для выявления важных тензоров, что требует предварительных вычислений для расчёта imatrix, а EvoPress эволюционный алгоритм без дополнительных датасетов, но с дополнительными циклами.
Ещё стоит упомянуть, что кванты UD отстают от новых квантов ik_llama.
Достаточно зайти в эти 308 файтюнов и посмотреть, что в 99% случаях это учебные проекты, ещё парочка попыток снять цензуру, что обычно снижает и качество, и ничего, чем можно пользоваться, вместо оригинальной модели.
Речь про файнтюны, которыми можно пользоваться на уровне или лучше оригинала, либо в целом, либо в каких-то сферах, не обязательно уровня Hermes (Nouns Research) или Nemotron (Nvidia), но грубо говоря, те файнтюны на которые делают gguf, которые заслуживают хоть какого-то внимания.
Файнтюном Hermes-4-405B до сих пор пользуюсь, когда мне нужен максимально связный ответ по всему контексту. И мне известен только 1 файнтюн MoE модели, который на голову превосходит оригинал и которым многие пользовались - это WizardLM-2, но Microsoft распустила ту команду, часть из них ушла делать свои MoE модели в Tencent-Hunyuan.
Ryzen 395+: NPU ≈50 TOPS, DGX Spark: "до 1 PFLOP" (на FP4). Получается преимущество 20-ти кратное, теоретически. По объёму моделей для 395+ потолок — 70B при ~61 токен/с, хотя на практике можно и до ~128B крутить с ~15 токен/с. У Nvidia DGX Spark потолок до ~200B, а скорость инференса на таких же моделях будет измеряться сотнями токен/с.
Вся эта мощь может остаться не востребованной, если скорость памяти медленная, а у DGX она медленная, на уровне 4060ti. Первый обзор уже появился, и результаты пока не очень.
В Llama 3.1 70B скорость генерации 2.66 t/s в fp8, в GPT-OSS 120B - 11.66 t/s, у людей на Ryzen 395+ на вулкане выдает 49 t/s.
Потому что, это MoE, а MoE это не про качество, а про снижение расходов в 10-20 на обучение и инференс.
Смесь экспертов - это когда 128 экспертов по 5B, каждый хорошо знает свою область, а общий роутер распределяет запросы по этим экспертам мудро и правильно, и на каждый токен вызывает 4 эксперта, которые лучше всего ответят на поставленную задачу. В идеале модель быстрая, но умная, а запустить можно даже на CPU.
Проблемы которые тут возникают:
роутер плохо обучен и некачественно распределяет запросы, распределяет запросы не по 128 экспертам, а лишь по 20
сами эксперты плохо изолированы, много экспертов знают одно и тоже, впустую расходуются параметры
размер одного эксперта слишком мал для комплексной оценки всего запроса, но просто увеличивая размер, один эксперт захватывает на себя всё обучение
Получается ситуация, когда общий размер модели очень большой, но она наполнена либо дублирующими связями, либо часть экспертов просто не используется. Роутер очень сложно обучить, из-за этого сложно изолированно обучить экспертов. Пример с Llama4 хорошо это демонстрирует, где 109B-MoE не мог конкурировать даже с dense 27B, а 402B с трудом дотягивал до 70B.
И поэтому так мало файнтюнов MoE моделей, их сложно дообучать, чтобы получалось хорошо, а вот файнтюны dense-моделей до сих пор выходят, например, отличные свежие Hermes-4-405B и Hermers-4-70B, и файнтюны плотных моделей Mistral Large 123B и Command-A 111B - все они хороши, но запустить локально их уже намного сложнее.
Зато MoE модели позволяют намного быстрее обучать и экспериментировать. Эта модель на 1T как раз такой эксперимент.
А кодовый агент хочется максимально жирный. Чисто попробовать во время разработки и все
Вариантов не так много на такой объем памяти: Qwen3-32B, Qwen3-Coder-30B-A3B, Devstral-Small-2507. Когда выйдет gguf для Qwen3-Next-80B-A3B, то он должен быть получше.
Ещё вариант, это частично запустить модели прям с nvme, например, gpt-oss-120b и GLM-4.5-Air если выгрузить побольше слоев через -ncmoe на GPU, должны работать. Вот тут кто-то запускал gpt-oss-120b на 32gb RAM без GPU с диска и получил 5 t/s.
Мне чисто для демонстрации, так что хотелось бы что-нибудь максимально быстрое, лёгкое и +/- приличное
Для быстрого есть 2 варианта:
Взять старый sd1.5 у которого 512x512, но взять хороший файнтюн, напримпер Deliberate. Запускается легко, работает быстро, веси мало.
Qwen-Image большая модель поддерживающая 1328x1328 и даже частично промпты на русском, для модели есть ускоряющая лора и если генерировать 512x512, будет намного быстрее.
Qwen-Image не влезает в 16гб VRAM, поэтому нужно использовать gguf, для картинок gguf сейчас поддерживает только ComfyUI, и сам gguf будет медленнее чем satetensors fp8. В общем тут только тестировать.
В ComfyUI уже есть шаблон для картинок:
Потом нужно установить ComfyUI-GGUF, для этого проще всего установить ComfyUI-Manager и в нём уже найти GGUF. После этого найти Uner Loader (GGUF) в Nodes и добавить его в воркфлоу, и сменить связь с fp8 на gguf. Потом включить блок с лорой и настроить шаги и cfg, ширину и высоту. В общем сделать примерно как на скриншоте:
Есть 2 ускоряющие лоры Qwen-Image-Lightning-8steps и Qwen-Image-Lightning-4steps, одна 8 шаговая, вторая 4 шаговая, количество шагов надо выставить в 8 или 4, а cfg снизить до 1. Обе лоры снижают качество, но это не обязательно будет заметно.
Harley Quinn, wearing a spacesuit helmet, poses for an alien taking a photo of her on a spaceship. The alien is wearing a T-shirt with the words "4 step demo," ultra realistic.
И проделав всё это, не факт, что будет быстро. На 4090 генерация 512x512 на 8 шагах занимает 2.5 секунды, а gguf занимает 13с. 1328x1328 на fp8 генерируется 16с, а gguf - 27с. 4 шаговая лора ускоряет в ~1.5 раза.
Это не SD3, а HunyuanImage 3.0, которая вышла 2 недели назад. Модель построена на авторегрессии как LLM, и так как внутри там полноценная LLM, она понимает русский для промптов и может сама придумать инфографику. Работает не идеально, поэтому будет интересно посмотреть, как вы справились с этой задачей.
Промпт: Придумай саркастичную инфографику про LLM на русском
Промпт про ведьмака сгенерированный GLM
Create a detailed infographic for the game "The Witcher 3: Wild Hunt" in a dark fantasy style, inspired by Slavic mythology and the game's official concept art, using a color palette of muted earth tones, deep grays, and accents of red and blue. The centerpiece is a radial diagram with Geralt of Rivia at the center; stylized lines connect him to key characters labeled 'Дитя Старшей Крови', 'Чародейка', 'Король Дикой Охоты', and 'Главный антагонист'. These lines should also branch out to major locations labeled 'Белый Сад', 'Новиград', 'Велены', and 'Скеллиге'. Include a section with clean, minimalist icons for key items labeled 'Стальной меч для людей', 'Серебряный меч для монстров', and 'Амулет Медальон Волка'. Add a horizontal timeline at the bottom, divided into four key plot points in Russian: 1. Начало: Поиски Цири с помощью Йеннифэр. 2. Развитие: Путешествие по Веленам, Новиграду и Скеллиге, сбор информации. 3. Кульминация: Противостояние с Дикой Охотой. 4. Финал: Битва за Цири и ее судьба. In a top-right corner, place a statistics block with the following text in Russian: 'Дата выхода: 19 мая 2015 г.', 'Разработчик: CD Projekt RED', 'Награды: Игра года (2015)', 'Количество игроков: 50+ миллионов'. Use a clean, legible font for all Russian text, and ensure the overall layout is balanced, modern, and visually appealing, with a subtle, textured background reminiscent of old parchment.
RTX 5070ti 16gb, 32 gb ddr5 6400 Мне нужны модели для:
Список большой, и как я понял, нужно чтобы это работало на фоне, не забирая все ресурсы.
В качестве llm: Qwen3-30B-A3B-Instruct-2507 загружая через cmoe, чтобы освободить побольше VRAM. Быстрая, много не занимает, с русским языком работает лучше чем gpt-oss-20b, есть маленькая версия для кода и для размышлений.
Будущее уже здесь - Следующее поколение моделей (типа SD3) уже демонстрирует впечатляющие результаты в генерации текста. Но пока они не стали мейнстримом, наш многослойный подход остается самым надежным способом гарантировать безупречный текст в AI-генерациях. Экспериментируйте, комбинируйте и делитесь результатами — вместе мы делаем AI-творчество более точным и профессиональным!
Напомню, что SD3 вышел 1.5 года назад.
Для текста в ходу Flux и Qwen Image. И свежий HunyuanImage 3.0.
Попробуйте GLM-4.6, есть GLM-4.5-Air поменьше, обещали выпустить GLM-4.6-Air. Скорость работы средняя, редко упоминается и в целом недооценена. Многие задачи решает хорошо.
Ещё вариант ускорения, помимо выгрузки moe весов через -cmoe, это спекулятивное декодирование. Qwen3-235B и Qwen3-Coder-480B обычно очень медленные, поэтому можно в качестве ускоряющего черновика использовать малую модель, например, Qwen3-4B-Instruct-2507, ускорение обычно в 1.5 раза. У меня было 4.5 t/s, стало 7 t/s, это зависит от сценария.
По ОС, чтобы выжать проценты скорости, лучше пробовать линукс, но это не для всех моделей работает одинаково, да и сам линукс не для всех. Например, gpt-oss проседает до 25 t/s под виндой, вместо 32 t/s под линуксом, DeepSeek проседает на 1-2 t/s, а вот для Grok2 без разницы, но у меня Windows 10, на 11 может по другому будет работать, это надо тестировать.
Попробовал работу openai_gpt-oss-120b-MXFP4.gguf 63 гб с диска. Таким образом на обычном компьютере MoE модели можно использовать практически неограниченного размера.
Там не всё так просто, ограничение у MoE есть, в основном это количество активных параметров.
В начале года OpenAI проводили опрос, они спрашивали какую модель сделать в открытый доступ, такую компактную и быструю, что можно на телефонах запускать, или уровня o3-mini, но чтобы всё равно на ПК нормально работало. В итоге выпустили оба варианта (20B и 120B).
Они изначально эти модели спроектировали так, чтобы одна работала на обычных ПК, а вторая на телефонах. Там очень мало активных параметров, поэтому и можно запускать с диска, требуется не так много считывать оттуда.
У 120B на каждом шагу генерации активно всего 5.1B. В нативном кванте mxfp4 это примерно 2.5гб, быстрый nvme легко считывает столько. Тензоры внимания этих активных экспертов в рамках одного токена используются, проходя все слои, много раз, поэтому такие тензоры постепенно закэшируются в память. Ещё в таких оптимизированных моделях часто используют общих экспертов, что ещё сильнее ускоряет работу т.д.
По сути это запуск оптимизированной 5.1B модели, и оборудование требуется такое, которое потянет 5.1B, то есть почти любое.
Если gpt-oss-120B запустить CPU-only полностью поместив в DDR5 4800, скорость будет 14 t/s:
CPU Only, 14 t/s
Если использовать 24гб GPU на полную, выгрузив побольше слоев на GPU, то скорость 32 t/s:
CPU + GPU, параметр запуска -ncmoe 25, 32 t/s
В общем модель очень хорошо спроектирована, работает быстро везде и на всём. Но не все MoE спроектированы так, есть много разных вариантов, и среди них есть один безумный вариант, это Grok2, у которого как раз недавно веса выложили в открытый доступ, gguf уже поддерживается.
Если взять минимальный квант grok-2-UD-TQ1_0, его размер примерно где-то рядом ~80гб, и скорость можно ожидать плюс минус такую же, но скорость в 12 раз ниже, всего 1.2 t/s:
grok2, llama.cpp, CPU only
Grok2 это MoE модель, где общих параметров 270B, но в отличии от gpt-oss, активных там 115B, это рекордсмен среди MoE, на втором месте 50B у Ling-1T, модель размером 1000B, на третьем DeepSeek и Kimi K2 у которых активных 37B, потом Qwen3-Coder с 35B, GLM-3.6 с 32B, LongCat с 27, Qwen3 с 22B и т.д. Это всё крупные модели, которые трудно запустить. Но есть маленькие, вроде Qwen3-30B-A3B c 3B или супер маленький granite-4.0-tiny c 1B. Проблема тут из-за того, что чем меньше активных параметров, тем слабее модель.
И поэтому, хоть Grok2 это MoE, но даже если подключить всю мощь 4090 и различные параметры для ускорения, то скорость всего 1.7 t/s:
Экстремальное квантование даёт о себе знать
В общем MoE они разные. Для сравнения, запуск не плохого кванта DeepSeek V3.1 на том же оборудовании дает 7 t/s:
Попробуйте не использовать умные термины и объяснять простыми словами. Если ваше объяснение всё еще будет выглядеть корректным, тогда в нем не будет магии.
Так и получается не правильное представление об обучении, тут не куда упрощать, так как уже идет искажение смысла, как в вашем упрощенном описании.
Если описывать очень упрощенно, то они любую исходную функцию приближают набором ломаных черточек/плоскостей. Поэтому чем больше черточек, тем точнее приближение. Тремя черточками вы линию синуса не опишете.
Смотрите, я обучил нейросеть, где всего 3 нейрона, и случается, ну видимо, "магия" и синус описывается гладко и согласно доказанной универсальной теореме аппроксимации, можно получить любую точность увеличивая количество нейронов. И никаких чёрточек.
Сигмоида как функция активации
Обучил нейросеть с ReLU чёрточками, и этот результат как-то не похож на то, что вы описали, результат скорее хаотичный, где-то точность высокая, а где-то безумно низкая.
ReLU активация, 10 нейронов
Смотря на это и ваше описание, вы никак не отвечаете как работает аппроксимация, потому что, это не упрощенная функция синуса, которая выглядела бы угловато, но равномерно. Это именно аппроксимированная нелинейная функция работающая по своим законам. Нейросеть как-то, каким-то своим способом находит паттерны и выводит из них функцию, функция не линейна, поэтому и такая разная на разных диапазонах.
Даже если взять 10000 нейронов, всё выглядит не так, как ожидается:
ReLU активация, 10000 нейронов
Как ваше описание будет работать, если исходной функции просто нет? Ваше упрощенное объяснение создает ложное представление, как работает обучение и аппроксимация.
При обучении нейросети нет никакой исходной функции, есть только набор входных данных, выходных данных и "магия" аппроксимации. Та самая "магия", которую ведущий разработчик DeepMind описывает как "да кто ж знает как оно работает, но работает же".
Вы думаете если повторить высказывание несколько раз, оно от этого станет более верным?
В смысле вы на полном серьезе думаете, что это буквально "само собой" и усиленно с этим боретесь? Ну такое.
Конечно, какая-то причина под всем этим есть и однажды демон Лапласа её поведает, в конце концов это всё ещё классическая система, а не квантовая.
Собирая карточный домик приложено конкретное известное усилие и был получен ожидаемый результат, не случилось что-то вроде собрав домик из 1000 карт он влезет в воздух. Это не "само собой", а конкретным способом, зная конкретный результат.
В LLM эффект проявляется "сам собой", потому что исследователи не делали для этого ничего конкретного. Да, они увеличивают количество параметров, насыщают датасет, проводят больше эпох - но ждут они каких-то новых свойств, которые должны проявиться "сами собой", в смысле "каким-то неизвестным нам образом", не "магическим".
Эта довольно простая смысловая конструкция, чтобы её на полном серьезе обсуждать в буквальном смысле. Я так понимаю, каждый остается при своём мнении, думаю, тут больше не чего обсуждать, по крайней мере диалог немного наскучил.
Обычно на ik_llama не должно быть такой просадки при увеличении контекста даже на P40, так как их основная особенность это сохранение производительности на огромном контексте.
Но так как речь идет про GPT-OSS, то ik_llama не лучший вариант для запуска, автор ik_llama решил не доводить поддержку SWA в GPT-OSS до конца.
Вообще, кванты, которые не созданы специально для ik_llama (то есть IQK кванты) я стараюсь запускать на ванильной llama.cpp. По ощущениям после длительного расхождения основной ветки и форка там как будто бы чаще проявляются какие-то разные проблемы для не родных квантов, особенно это проявляется в mxfp4, в котором и есть GPT-OSS.
Попробуйте протестировать ваш сценарий на оригинальной llama.cpp с включенным
-cmoe.Чаще чем на каждом токене. 36 + 1 слоев, в каждом слое свой роутер и свои 128 экспертов, итого 36 роутеров и гора экспертов, прямой проход по нейросети активирует последовательно эти 36 роутеров и каждый выбирает по 4 эксперта своего слоя. И только проделав всё это генерируется 1 новый токен.
Работает за счёт того, что в 36 слоях 36 блоков внимания, за один проход нейросети надо рассчитать все 36 блоков. При активации
-cmoeв VRAM загружены не эксперты, а эти тензоры внимания, эксперты же остались на CPU в обычной RAM.Ускорение происходит за счёт того, что GPU теперь считает только тензоры внимания, а не разреженные слои с экспертами, из-за этого GPU постоянно ускоряет вычисления для каждого слоя, а в классическом варианте GPU бы простаивала как только прошли слои, которые были выгружены целиком.
Ryzen AI Max+ 395 (Strix Halo) же уже давно в продаже и уже давно оттестирован. С такой же унифицированной памятью и объемом в 128 Гб. В таком же форм факторе маленькой коробочки, на озонах по 180к продается.
По бенчмаркам производительность генерации токенов TG плюс-минус такая же как у DGX Spark, но стоит в 2 раза дешевле. Нет CUDA ядер, но для LLM уже давно поддерживается Vulkan или ROCm.
Strix Halo против DGX Spark: https://www.youtube.com/watch?v=Pww8rIzr1pg
Так GPT-OSS-120B изначально делали таким, чтобы его на домашних ПК можно было запускать, так что 96 Гб ему не требуется.
Вообще, и для GPT-OSS-120B и для картинок хватит 8 Гб. GPT-OSS-120B не так сложно запустить с хорошей скоростью в 20-30 t/s на обычной видеокарте, тут важнее, чтобы хватило RAM, а не VRAM: https://habr.com/ru/articles/961478/
Для тяжеловесной Qwen Image хватает 16 Гб, а Stable Diffusion XL же совсем не требовательна, для её запуска хватает 8 Гб, как и для более тяжелого Flux, для них к тому же есть gguf. Даже для генерации видео в Wan2.2 14B хватает 16 Гб.
llama4:16x17b - это Llama-4-Scout, очень слабая модель.
Попробуйте GLM-4.5-Air-MXFP4, и скоро должна выйти GLM-4.6-Air, эта модель куда интереснее и часто бывает лучше чем GPT-OSS.
Есть 2 основных способа объединить GPU:
тензорный параллелизм (Tensor Parallelism), тензоры одной операции разбиваются на блоки, и каждая карта параллельно считает свой блок, потом объединяет результат.
конвейерный параллелизм (Pipeline Parallelism), на разные карты уходят разные слои, сначала работает первая карта, потом вторая.
В первом случае вы получаете и распараллеливание вычислений и удвоение объема VRAM, а во втором случае в основном только удвоение VRAM, но в батчинге можно получить ускорение. Для тензорного параллелизма нужно использовать vLLM или ExLlama, но там не получится использовать связку GPU+CPU.
В llama.cpp реализовано что-то похожее через
--split-mode row, но работает не очень хорошо, хотя некоторые пишут, что получают ускорение на двух GPU.Ещё 5080 поддерживает вычисления в fp4, gpt-oss как раз в fp4 (в MXFP4, ещё есть улучшенный NVFP4, который в llama.cpp пока не поддерживается), если добавить карту которая не поддерживает fp4, то скорее всего скорость упадет.
И надо будет использовать Vulkan, чтобы объединить Nvidia + AMD, это ещё потери скорости.
У Ollama свой несовместимый формат-обертка, можно попробовать переименовать самый большой файл с хешированным именем, но не факт, что сработает. Проще скачать заново.
Плюс можно сразу взять кванты поинтереснее, например, от Unsloth с их динамическим квантованием UD, или от Ubergarm который выкладывает кванты для ik_llama, которые себя лучше показывают, чем стандартные кванты llama.cpp (создатель ik_llama и есть создатель квантов в llama.cpp, он сделал форк чтобы делать новые кванты). Или взять кванты MXFP4 не только для GPT-OSS, так как они должны быть быстрее на 5080, где есть нативная поддержка fp4.
И можно качать модели которые состоят из множества файлов, вроде 5 файлов GLM-4.5-Air-MXFP4_MOE-00001-of-00005.gguf, при запуске просто указать путь к 1 файлу.
В деталях на счёт памяти может ошибаюсь, но смысл примерно такой. В Windows по умолчанию shared memory для GPU, а сам mmap, в отличии от Linux, занимает всю память под модель, и не высвобождает, что ушло на GPU.
-ncmoe 8- это значит, что только 8 слоев пойдут на CPU (не на GPU). Если всего слоев 37, значит 29 пойдут на GPU, то есть потребуется ~50Гб для этого. Windows будет пытаться использовать такое количество памяти для GPU в shared, и сам mmap резервирует всю модель. В итоге двойной перерасход памяти.Удобного способа нет, поэтому просто какой есть:
Сначала узнать сколько слоев у модели, это показывается в консоли при загрузке. Например, у GLM-4.6 94 слоя, а у GPT-OSS-120B слоев 37.
Выставить в ncmoe число равное количеству слоев и по шагам уменьшат его в сторону 0. Тут работает инвертированный принцип, а не привычный как у ngl.
Смотреть на количество MiB загружаемого на CUDA0 и добиваться нужного количества занятой VRAM.
Надо учитывать размер контекста, там тоже это пишется. Чтобы снизить расход VRAM на контекст, можно использовать
-ctk q8_0 -ctv q8_0, это квантование KV-кэша в Q8_0, немного снизит качество, но в 2 раза снизит расход памяти на контекст.--jinja- это флаг для встроенного в gguf шаблона чата, чтобы текст правильно выводился. На производительность не влияет, но влияет на качество ответа. Нужно указывать не везде, только у квантов где это указано. В рамках одной модели могут варианты с этим флагом и без него.Чтобы не вбивать каждый раз параметры вручную для каждой модели, есть: https://github.com/mostlygeek/llama-swap
Главное следить, чтобы память GPU не выходила за пределы своего максимума. Если залезет хоть немного в shared (именно модель, а не работа ОС), то это сильно снизит скорость генерации. Отключение "CUDA: политика резервной системной памяти" больше не помогает, поэтому приходится вручную следить за этим либо через диспетчер задач, либо через
nvidia-smi -l 2.Речь, не про то, что работает, а про то как работает. Спокойной работает даже с диска - это не секрет, вопрос в том с какой скоростью.
Через выгрузку на GPU можно получить ускорение на Dense моделях уже давно, но на MoE моделях это почти не работает, тут нужен другой подход, когда выгружаются на GPU не отдельные слои, а тензоры внимания и часть ffn всех слоев сразу.
Кому интересно подробнее, как это работает: https://habr.com/ru/articles/921540/
Через
-cmoeили--cpu-moeможно переключиться на такой режим и получить ускорение по сравнению со стандартным режимом. Это дает ускорение в 1.5-2 раза с меньшим расходом памяти.Через
-ncmoe Nможно ещё эффективнее загрузить всю доступную VRAM, например, все 16гб VRAM и получить не 11 t/s, а 16 t/s, прирост ещё в 45%.Сейчас это можно сделать на llama.cpp, на котором построены все остальные клиенты, включая LM Studio и Ollama, что тоже не секрет, но они предоставляют не полную поддержку всех фич, которая есть в движке. В LM Studio недавно добавили галочку для cmoe, но не ncmoe.
В Ollama реализация поддержки cmoe предложена, но она до сих пор не смержена в основную ветку: https://github.com/ollama/ollama/pull/12333
Также с августа висит запрос на поддержку ncmoe: https://github.com/ollama/ollama/issues/11772
Оба с закрытым кодом, а открытый Jan.ai им не конкурент. Есть другая популярная опенсорсная полнофункциональная альтернатива Cherry Studio:
https://github.com/CherryHQ/cherry-studio
Если лезть в дебри ollama, то есть в консоль, то можно заглянуть и в оригинал. В llama.cpp уже встроен простой и удобный веб-клиент, на котором можно развернуться запуская модели на GPU + CPU через параметры
-cmoeили-ncmoe N, которые до сих пор не поддерживаются в ollama.-cmoeпозволяет запустить на слабом железе не только GPT-OSS-120b или GLM-4.5-Air 110b, но и более крупные модели, если хватает обычной RAM памяти.В ежедневных готовых сборках llama.cpp есть llama-server.exe, на huggingface есть команда для скачивания и запуска:
Модель GPT-OSS-120b весит 61гб, в домашние GPU она не лезет, но так как это MoE модель, то с помощью параметра
-cmoeеё можно разместить равномерно по GPU+CPU, всё что нужно на каждом шагу в GPU, всё остальное на CPU. На 64к контекста нужно всего 8гб VRAM:llama-server -hf ggml-org/gpt-oss-120b-GGUF -c 65536 -fa -cmoe --jinjaЕсли модель уже скачана, то
llama-server -m "D:\mdels\gpt-oss-120b-MXFP4.gguf" -c 65536 -fa -cmoe --jinjaДаже на медленной 4060 можно получить скорость чуть выше 11 t/s на 47к контекста:
Да, содержимое файла модели мапится на память через mmap не загружаясь в память по настоящему. Для программы всё выглядит так, что модель находится целиком в памяти и во время чтения тензоров модели ОС сама подгружает данные с диска и выгружает их.
Всё это работает очень медленно, даже если тензоры внимания и первые общие слоя (у deepseek это первые 3 слоя) вынести на GPU, обычной RAM не совсем уж мало, а nvme не самый медленный, то можно получить 1-2 t/s с диска. У меня на 64гб удавалось выжимать 3.3 t/s на 4090.
Для сравнения, если целиком модель влезает в RAM память, то на 4090 получается 7.5 t/s: Запускаем настоящую DeepSeek R1 671B на игровом ПК и смотрим вменяемая ли она на огромном контексте (160к)
Для тех, кому интересно сравнение с квантованием GGUF по показателю PPL по версии IST-DASLab: https://github.com/IST-DASLab/gptq-gguf-toolkit
В целом EvoPress показывает преимущество над UD при одинаковом среднем числе бит на параметр. Чем ниже показатель PPL, тем лучше.
Unsloth Dynamic - вариант гетерогенного квантования, как и тот, что предложен в статье, только UD использует imatrix для выявления важных тензоров, что требует предварительных вычислений для расчёта imatrix, а EvoPress эволюционный алгоритм без дополнительных датасетов, но с дополнительными циклами.
Ещё стоит упомянуть, что кванты UD отстают от новых квантов ik_llama.
На Wiki2:
На C4:
Обновленные данные с llama.cpp: https://github.com/ggml-org/llama.cpp/discussions/16578
Цифры стали лучше, как и ожидалось pp на cuda работает лучше чем на vulkan, но генерация всё равно упирается в скорость памяти.
Достаточно зайти в эти 308 файтюнов и посмотреть, что в 99% случаях это учебные проекты, ещё парочка попыток снять цензуру, что обычно снижает и качество, и ничего, чем можно пользоваться, вместо оригинальной модели.
Речь про файнтюны, которыми можно пользоваться на уровне или лучше оригинала, либо в целом, либо в каких-то сферах, не обязательно уровня Hermes (Nouns Research) или Nemotron (Nvidia), но грубо говоря, те файнтюны на которые делают gguf, которые заслуживают хоть какого-то внимания.
Файнтюном Hermes-4-405B до сих пор пользуюсь, когда мне нужен максимально связный ответ по всему контексту. И мне известен только 1 файнтюн MoE модели, который на голову превосходит оригинал и которым многие пользовались - это WizardLM-2, но Microsoft распустила ту команду, часть из них ушла делать свои MoE модели в Tencent-Hunyuan.
Вся эта мощь может остаться не востребованной, если скорость памяти медленная, а у DGX она медленная, на уровне 4060ti. Первый обзор уже появился, и результаты пока не очень.
В Llama 3.1 70B скорость генерации 2.66 t/s в fp8, в GPT-OSS 120B - 11.66 t/s, у людей на Ryzen 395+ на вулкане выдает 49 t/s.
Потому что, это MoE, а MoE это не про качество, а про снижение расходов в 10-20 на обучение и инференс.
Смесь экспертов - это когда 128 экспертов по 5B, каждый хорошо знает свою область, а общий роутер распределяет запросы по этим экспертам мудро и правильно, и на каждый токен вызывает 4 эксперта, которые лучше всего ответят на поставленную задачу. В идеале модель быстрая, но умная, а запустить можно даже на CPU.
Проблемы которые тут возникают:
роутер плохо обучен и некачественно распределяет запросы, распределяет запросы не по 128 экспертам, а лишь по 20
сами эксперты плохо изолированы, много экспертов знают одно и тоже, впустую расходуются параметры
размер одного эксперта слишком мал для комплексной оценки всего запроса, но просто увеличивая размер, один эксперт захватывает на себя всё обучение
Получается ситуация, когда общий размер модели очень большой, но она наполнена либо дублирующими связями, либо часть экспертов просто не используется. Роутер очень сложно обучить, из-за этого сложно изолированно обучить экспертов. Пример с Llama4 хорошо это демонстрирует, где 109B-MoE не мог конкурировать даже с dense 27B, а 402B с трудом дотягивал до 70B.
И поэтому так мало файнтюнов MoE моделей, их сложно дообучать, чтобы получалось хорошо, а вот файнтюны dense-моделей до сих пор выходят, например, отличные свежие Hermes-4-405B и Hermers-4-70B, и файнтюны плотных моделей Mistral Large 123B и Command-A 111B - все они хороши, но запустить локально их уже намного сложнее.
Зато MoE модели позволяют намного быстрее обучать и экспериментировать. Эта модель на 1T как раз такой эксперимент.
Вариантов не так много на такой объем памяти: Qwen3-32B, Qwen3-Coder-30B-A3B, Devstral-Small-2507. Когда выйдет gguf для Qwen3-Next-80B-A3B, то он должен быть получше.
Ещё вариант, это частично запустить модели прям с nvme, например, gpt-oss-120b и GLM-4.5-Air если выгрузить побольше слоев через
-ncmoeна GPU, должны работать. Вот тут кто-то запускал gpt-oss-120b на 32gb RAM без GPU с диска и получил 5 t/s.Для быстрого есть 2 варианта:
Взять старый sd1.5 у которого 512x512, но взять хороший файнтюн, напримпер Deliberate. Запускается легко, работает быстро, веси мало.
Qwen-Image большая модель поддерживающая 1328x1328 и даже частично промпты на русском, для модели есть ускоряющая лора и если генерировать 512x512, будет намного быстрее.
Qwen-Image не влезает в 16гб VRAM, поэтому нужно использовать gguf, для картинок gguf сейчас поддерживает только ComfyUI, и сам gguf будет медленнее чем satetensors fp8. В общем тут только тестировать.
В ComfyUI уже есть шаблон для картинок:
Потом нужно установить ComfyUI-GGUF, для этого проще всего установить ComfyUI-Manager и в нём уже найти GGUF. После этого найти Uner Loader (GGUF) в Nodes и добавить его в воркфлоу, и сменить связь с fp8 на gguf. Потом включить блок с лорой и настроить шаги и cfg, ширину и высоту. В общем сделать примерно как на скриншоте:
Есть 2 ускоряющие лоры Qwen-Image-Lightning-8steps и Qwen-Image-Lightning-4steps, одна 8 шаговая, вторая 4 шаговая, количество шагов надо выставить в 8 или 4, а cfg снизить до 1. Обе лоры снижают качество, но это не обязательно будет заметно.
И проделав всё это, не факт, что будет быстро. На 4090 генерация 512x512 на 8 шагах занимает 2.5 секунды, а gguf занимает 13с. 1328x1328 на fp8 генерируется 16с, а gguf - 27с. 4 шаговая лора ускоряет в ~1.5 раза.
Это не SD3, а HunyuanImage 3.0, которая вышла 2 недели назад. Модель построена на авторегрессии как LLM, и так как внутри там полноценная LLM, она понимает русский для промптов и может сама придумать инфографику. Работает не идеально, поэтому будет интересно посмотреть, как вы справились с этой задачей.
Промпт:
Придумай саркастичную инфографику про LLM на русскомПромпт про ведьмака сгенерированный GLM
Create a detailed infographic for the game "The Witcher 3: Wild Hunt" in a dark fantasy style, inspired by Slavic mythology and the game's official concept art, using a color palette of muted earth tones, deep grays, and accents of red and blue. The centerpiece is a radial diagram with Geralt of Rivia at the center; stylized lines connect him to key characters labeled 'Дитя Старшей Крови', 'Чародейка', 'Король Дикой Охоты', and 'Главный антагонист'. These lines should also branch out to major locations labeled 'Белый Сад', 'Новиград', 'Велены', and 'Скеллиге'. Include a section with clean, minimalist icons for key items labeled 'Стальной меч для людей', 'Серебряный меч для монстров', and 'Амулет Медальон Волка'. Add a horizontal timeline at the bottom, divided into four key plot points in Russian: 1. Начало: Поиски Цири с помощью Йеннифэр. 2. Развитие: Путешествие по Веленам, Новиграду и Скеллиге, сбор информации. 3. Кульминация: Противостояние с Дикой Охотой. 4. Финал: Битва за Цири и ее судьба. In a top-right corner, place a statistics block with the following text in Russian: 'Дата выхода: 19 мая 2015 г.', 'Разработчик: CD Projekt RED', 'Награды: Игра года (2015)', 'Количество игроков: 50+ миллионов'. Use a clean, legible font for all Russian text, and ensure the overall layout is balanced, modern, and visually appealing, with a subtle, textured background reminiscent of old parchment.
Список большой, и как я понял, нужно чтобы это работало на фоне, не забирая все ресурсы.
В качестве llm: Qwen3-30B-A3B-Instruct-2507 загружая через cmoe, чтобы освободить побольше VRAM. Быстрая, много не занимает, с русским языком работает лучше чем gpt-oss-20b, есть маленькая версия для кода и для размышлений.
Для картинок: flux на gguf запуская через stable-diffusion-webui-forge, stable diffusion в исполнении Illustrious или Pony (модели ищутся на civitai.com), запускаются на stable-diffusion-webui или Qwen Image через ComfyUI.
Будет всё работать вместе одновременно и вполне быстро, оставляя много ресурсов для работы ПК.
В целом, с таким железом можно даже видео генерировать на wan2.2 через ComfyUI, загружая gguf версии, либо используя оптимизацию на 6гб VRAM.
Напомню, что SD3 вышел 1.5 года назад.
Для текста в ходу Flux и Qwen Image. И свежий HunyuanImage 3.0.
Попробуйте GLM-4.6, есть GLM-4.5-Air поменьше, обещали выпустить GLM-4.6-Air. Скорость работы средняя, редко упоминается и в целом недооценена. Многие задачи решает хорошо.
Ещё вариант ускорения, помимо выгрузки moe весов через
-cmoe, это спекулятивное декодирование. Qwen3-235B и Qwen3-Coder-480B обычно очень медленные, поэтому можно в качестве ускоряющего черновика использовать малую модель, например, Qwen3-4B-Instruct-2507, ускорение обычно в 1.5 раза. У меня было 4.5 t/s, стало 7 t/s, это зависит от сценария.По ОС, чтобы выжать проценты скорости, лучше пробовать линукс, но это не для всех моделей работает одинаково, да и сам линукс не для всех. Например, gpt-oss проседает до 25 t/s под виндой, вместо 32 t/s под линуксом, DeepSeek проседает на 1-2 t/s, а вот для Grok2 без разницы, но у меня Windows 10, на 11 может по другому будет работать, это надо тестировать.
Там не всё так просто, ограничение у MoE есть, в основном это количество активных параметров.
В начале года OpenAI проводили опрос, они спрашивали какую модель сделать в открытый доступ, такую компактную и быструю, что можно на телефонах запускать, или уровня o3-mini, но чтобы всё равно на ПК нормально работало. В итоге выпустили оба варианта (20B и 120B).
Они изначально эти модели спроектировали так, чтобы одна работала на обычных ПК, а вторая на телефонах. Там очень мало активных параметров, поэтому и можно запускать с диска, требуется не так много считывать оттуда.
У 120B на каждом шагу генерации активно всего 5.1B. В нативном кванте mxfp4 это примерно 2.5гб, быстрый nvme легко считывает столько. Тензоры внимания этих активных экспертов в рамках одного токена используются, проходя все слои, много раз, поэтому такие тензоры постепенно закэшируются в память. Ещё в таких оптимизированных моделях часто используют общих экспертов, что ещё сильнее ускоряет работу т.д.
По сути это запуск оптимизированной 5.1B модели, и оборудование требуется такое, которое потянет 5.1B, то есть почти любое.
Если gpt-oss-120B запустить CPU-only полностью поместив в DDR5 4800, скорость будет 14 t/s:
Если использовать 24гб GPU на полную, выгрузив побольше слоев на GPU, то скорость 32 t/s:
В общем модель очень хорошо спроектирована, работает быстро везде и на всём. Но не все MoE спроектированы так, есть много разных вариантов, и среди них есть один безумный вариант, это Grok2, у которого как раз недавно веса выложили в открытый доступ, gguf уже поддерживается.
Если взять минимальный квант grok-2-UD-TQ1_0, его размер примерно где-то рядом ~80гб, и скорость можно ожидать плюс минус такую же, но скорость в 12 раз ниже, всего 1.2 t/s:
Grok2 это MoE модель, где общих параметров 270B, но в отличии от gpt-oss, активных там 115B, это рекордсмен среди MoE, на втором месте 50B у Ling-1T, модель размером 1000B, на третьем DeepSeek и Kimi K2 у которых активных 37B, потом Qwen3-Coder с 35B, GLM-3.6 с 32B, LongCat с 27, Qwen3 с 22B и т.д. Это всё крупные модели, которые трудно запустить. Но есть маленькие, вроде Qwen3-30B-A3B c 3B или супер маленький granite-4.0-tiny c 1B. Проблема тут из-за того, что чем меньше активных параметров, тем слабее модель.
И поэтому, хоть Grok2 это MoE, но даже если подключить всю мощь 4090 и различные параметры для ускорения, то скорость всего 1.7 t/s:
В общем MoE они разные. Для сравнения, запуск не плохого кванта DeepSeek V3.1 на том же оборудовании дает 7 t/s:
Так и получается не правильное представление об обучении, тут не куда упрощать, так как уже идет искажение смысла, как в вашем упрощенном описании.
Смотрите, я обучил нейросеть, где всего 3 нейрона, и случается, ну видимо, "магия" и синус описывается гладко и согласно доказанной универсальной теореме аппроксимации, можно получить любую точность увеличивая количество нейронов. И никаких чёрточек.
Обучил нейросеть с ReLU чёрточками, и этот результат как-то не похож на то, что вы описали, результат скорее хаотичный, где-то точность высокая, а где-то безумно низкая.
Смотря на это и ваше описание, вы никак не отвечаете как работает аппроксимация, потому что, это не упрощенная функция синуса, которая выглядела бы угловато, но равномерно. Это именно аппроксимированная нелинейная функция работающая по своим законам. Нейросеть как-то, каким-то своим способом находит паттерны и выводит из них функцию, функция не линейна, поэтому и такая разная на разных диапазонах.
Даже если взять 10000 нейронов, всё выглядит не так, как ожидается:
Как ваше описание будет работать, если исходной функции просто нет? Ваше упрощенное объяснение создает ложное представление, как работает обучение и аппроксимация.
При обучении нейросети нет никакой исходной функции, есть только набор входных данных, выходных данных и "магия" аппроксимации.
Та самая "магия", которую ведущий разработчик DeepMind описывает как "да кто ж знает как оно работает, но работает же".
В смысле вы на полном серьезе думаете, что это буквально "само собой" и усиленно с этим боретесь? Ну такое.
Конечно, какая-то причина под всем этим есть и однажды демон Лапласа её поведает, в конце концов это всё ещё классическая система, а не квантовая.
Собирая карточный домик приложено конкретное известное усилие и был получен ожидаемый результат, не случилось что-то вроде собрав домик из 1000 карт он влезет в воздух. Это не "само собой", а конкретным способом, зная конкретный результат.
В LLM эффект проявляется "сам собой", потому что исследователи не делали для этого ничего конкретного. Да, они увеличивают количество параметров, насыщают датасет, проводят больше эпох - но ждут они каких-то новых свойств, которые должны проявиться "сами собой", в смысле "каким-то неизвестным нам образом", не "магическим".
Эта довольно простая смысловая конструкция, чтобы её на полном серьезе обсуждать в буквальном смысле. Я так понимаю, каждый остается при своём мнении, думаю, тут больше не чего обсуждать, по крайней мере диалог немного наскучил.