Классный проект, который вполне может со временем превратиться в продукт. Не знаю, вывезет ли RPi5 нагрузку, но если бы я пилил такое, то на следующем этапе сделал бы память, чтобы модель помнила старые диалоги и предпочтения “клиента”. По диалогам можно сделать RAG, а для запоминания предпочтений можно прикрутить Honcho или нечто подобное. Тогда можно будет задавать не только сиюминутные вопросы, но и говорить что-то вроде: “Помнишь, мы с тобой обсуждали…?” Возможно, для этого придется завести небольшой домашний сервер. :)
У меня немного более мощная система: ЦП AMD RYZEN AI MAX+ 395 w/ Radeon 8060S. Так что никаких теорий, чистая практика. Но если у вас так работает быстрее, значит используйте так.
Что касается раздела “Память”, то все зависит от того, куда вы там смотрите: налево, в столбец с разными метриками, или вправо-вверх, где указано общее количество памяти.
Да, но при чем тут VRAM? Вы же выше писали, что NPU грузит модели во VRAM, а также то, что зажали VRAM через параметры ядра в grub на уровне полугигабайта.
Напишу, как сейчас у меня. Всего 96ГБ общей памяти. При этом 16ГБ выделено под VRAM. И при этом же есть еще общая память графического процессора, выделяемая из RAM. У меня это 64 ГБ и не настраивается. Во всяком случае просто. NPU видит ровно те же 64 ГБ, но уже просто как общую память. Видимо, эта память делится между iGPU и NPU. Еще 16 никому не выделяется и остается под нужды системы. Т.е. у меня разбивка такая: 16 ГБ (система) + 64 ГБ (общая: IGPU, NPU, система) + 16 ГБ VRAM (iGPU).
В вашей цитате, по всей видимости, эти 15.1 ГБ - это и есть размер общей памяти (iGPU/NPU), только на системе с 32 ГБ памяти всего. Осложняется все тем, что и система видит эту память и тоже может занять ее под свои нужды. Т.е. вы бы в любом случае не смогли запустить gpt-oss:20b ни на iGPU, ни на NPU, без выгрузки экспертов или части слоёв в оставшуюся системную часть всей памяти.
Уверен, что вы понимаете, что в любом случае в память там дважды ничего не грузится. Я имею в виду и в VRAM, и в RAM. Видимо, как я писал выше, это особенности линуксовых драйверов. В Windows у меня NPU “видит” в 4 раза больше памяти, чем выделено под VRAM. Вполне себе дисбаланс.
Вспомнил, что в Питере у них есть лаборатория, занимающаяся ИИ. И если они не работают удаленно в кластерах Хуавей, то наверное да. Но лучше все же у того же Селектела уточнить.
Значит у нас одинаковые платформы. Правда, на ней я работаю в Windows. У меня размер общей памяти NPU отображается ровно таким же, как и размер общей памяти GPU. Из этого я делаю вывод, что по крайней мере в Windows, они делят общую память. Но в Linux все может быть иначе, конечно. Не перехожу в этом сетапе на линукс как раз из-за несколько лучшей его поддержки в Windows в настоящее время.
По крайней мере в Windows на вашей платформе, думайте только про совокупный объём памяти, забудьте про деление на RAM/VRAM. Да, это может казаться контринтуитивно, но это так. Поначалу я тоже пытался выделить VRAM побольше, в силу привычки, но это на самом деле не нужно. Оставьте 8ГБ VRAM только под те вещи, которые нужны видеодрайверу (фреймбуфер, кэши всякие), да и все. Модель не должна на вашей платформе умещаться во VRAM чтобы работать на полной возможной скорости.
Отвечал, как будто у вас тоже AMD Strix Point. По всей видимости это не так. Но для этой платформы мой комментарий справедлив.
Справедливости ради, это не GPU, как в заголовке, а NPU. Я хотел взять, чтобы попробовать эти решения. Но отдельные карты за пределами Китая если и можно найти, то только нелегально. В составе решения же минимальный сервер Huawei Atlas 650E с 8 NPU Ascend 950DT стартует от полумиллиона долларов. Дороговато, чтобы попробовать технологию. С интересом жду результатов тестов от кого-то еще. В цене я уверен, т.к. я общаюсь с Huawei напрямую, был у них в кампусах в Шеньджене (на самом деле в соседнем городе Дунгуань, но для простоты даже их работники упоминают Шеньджень, как более известный город) и Шанхае.
Вы можете снизить объем VRAM до 16 ГБ или даже меньше и ничего скорее всего не изменится. Попробуйте. На этой платформе движку инференса все равно, в какой памяти лежит модель или как она делится между ними - память фактически одна и деление на RAM/VRAM там достаточно условное. Если вы работаете на этом компьютере в Windows, откройте диспетчер задач и на вкладке Производительность/Память вы должны увидеть все свои 64 ГБ, несмотря на то, что вы выделили 48 ГБ из нее под VRAM.
Я не вполне понимаю, почему вы сосредоточились именно на NPU. Да, NPU есть, но он тут играет далеко не главную роль. Ryzen AI 9 365 относится к Ryzen AI 300 / Strix Point, а встроенная Radeon 880M поддерживается AMD для LLM-инференса через iGPU. У меня немного более мощная конфигурация: Ryzen AI Max+ 395 с Radeon 8060S, NPU тоже есть, конечно. И тут есть важный нюанс в архитектуре - unified memory. Для инференса на iGPU на самом деле не сильно важно, сколько памяти отдано под VRAM, скорость доступа к VRAM практически идентична скорости доступа к RAM. Ваш NPU точно так же держит модели в той же RAM. Т.е. я хочу сказать, что нужно забыть про объемы RAM или VRAM, оценивая то, поместится модель или нет. У дискретной видеокарты RAM и VRAM - это две разные памяти, и веса модели приходится копировать из одной в другую. У встроенной Radeon память общая: CPU и GPU обращаются к одной и той же физической RAM. Поэтому деление на RAM и VRAM в значительной степени логическое. Очень условно, VRAM нужна для фреймбуфера, чтобы вы картинку на экране монитора видели. А движку все равно, где будет лежать модель, т.е. какая его часть попадет в VRAM, а что останется в RAM. Это одна и та же память.
Я гоняю основные модели именно на iGPU, оставив NPU под второстепенные модели и задачи. Попробуйте. Скорее всего производительность у вас вырастет. У меня Qwen3.6–35B‑A3B (Q4_K_M) стабильно выдает 60+ ток/с на decode, и 800-900 в prefill в LM Studio. У вас цифры будут пониже, но все равно должно быть быстрее, чем на NPU.
Самому стало интересно и я проверил Humo-Coder, т.к. это все же дообученная модель. У Humo-Coder зрение есть: та же архитектура, что у Qwen3.5: vision_config, 333 тензора зрительной части, препроцессоры для картинок и видео. Наше квантование его не трогало: в рецепте зрительная часть исключена.
Но оно не совпадает со зрением базовой Qwen3.5. Я сравнил с инкумбентом: это официальный квант Qwen3.5, зрение у него не сжато, и оно служит образцом базовых весов. Все 333 тензора различаются. Различие не тотальное, а похоже на след дообучения. Веса явно из той же линии, но сдвинуты, и чем глубже слой, тем сильнее. Так выглядит дообучение. Значит, авторы Ornith при своём обучении меняли и зрительный кодировщик. Либо они стартовали не с той контрольной точки Qwen3.5, что лежит в основе официального кванта - по весам этого не различить.
По поводу Humo-Coder - для задач, связанных с программированием, скорее всего да. Все же модель заметно выигрывает на этом поле у всех протестированных. Но тесты - одно, а как она покажет себя в реальной работе - другое. Будем проверять в реальной работе у себя.
Мультимодальность у моделей семейства Qwen3.5/3.6 есть, но в этом исследовании мы это не проверяли. Зрительный кодировщик у всех квантов, которые мы смотрели, оставлен несжатым - его веса такие же, как у базовой модели. Но изображение после кодировщика всё равно обрабатывает языковая часть, а она сжата в четыре бита, так что качество работы с картинками может отличаться - этого мы не измеряли.
Спасибо. Нет, Хумо - не файнтюн, т.е. дообучения не было. Обычная квантизация базавой Ornith-1.5 в GPTQ Int4 со своим калибровочным набором и шаблоном. Самое долгое в этом - сам процесс квантизации. Выложить, конечно, можно. Займет какое-то время на заливку. Тем более я сделал модель не только в safetensors, а еще линейку квантов в GGUF, начиная с IQ3_M до Q5_K_XL, с тем же калибровочным набором. Никогда не публиковал ничего на HF. Разберусь с этим и, вероятно, опубликую модель.
Да, в проде все еще 3.5. 3.8 тоже есть, но я так же хочу сделать собственный квант этой модели. Потом проведу аналогичное сравнение, чтобы определиться с тем, что оставлять на проде. Может быть заменит 3.5, если не будет слишком “дорогой” по токенам.
Её нет в размерности 35B-A3B. А так, мы ей тоже пользуемся, тоже в кванте Int4. Вопрос цены. Многие задачи решаются с тем же качеством и быстрее более слабыми моделями. К тому же это исследование может быть полезно тем, кто просто не может запустить 3.8 из-за ограничений, все же памяти там нужно намного больше для запуска. 3.6 я использую на своем настольном компьютере ежедневно, а вот 3.8 уже не выйдет.
Да, итог размытый. Потому что однозначный не получился. Выбор модели зависит от того, что вам нужно. Но для локального инференса у нас я пока решил оставаться на 3.5.
Что касается набора, то большая часть собрана из публично доступных. GPQA закрыт условиями доступа на Hugging Face и просит не публиковать вопросы в открытом виде. Поэтому его нужно скачивать самостоятельно. Остальное можно опубликовать. Но получится несколько репо. Нужно ли?
Сочувствую. Не так давно тоже прошел через автоматическую блокировку, невозможность выйти на людей и все стадии принятия. У меня там был чат, в котором я прорабатывал одну математическую идею в течение полугода практически в ежедневном режиме. Я бы не стал писать это все, если бы не одна причина - у меня остался локальный кэш Codex, из которого удалось восстановить всю проделанную работу, так что может еще не все потеряно и у вас. Но, конечно, все это заставляет вспомнить последнюю фразу из анекдота “Что там за шум на улице, Бэрримор?”
Согласен, что такое может быть, если шагов в 3 раза меньше, но каждый шаг занимает в 4 раза больше времени. Но в данном случае это не так, число операций в одном шаге сравнимо у обоих методов. Но если хотите, можем замеры и по времени сделать.
Модели выложены на HF:
https://huggingface.co/ooptimum/Humo-Coder-35B-A3B-GGUF
https://huggingface.co/ooptimum/Humo-Coder-35B-A3B-GPTQ-Int4
Все же традиционно файнтюном считают дообучение модели на своих данных.
Классный проект, который вполне может со временем превратиться в продукт. Не знаю, вывезет ли RPi5 нагрузку, но если бы я пилил такое, то на следующем этапе сделал бы память, чтобы модель помнила старые диалоги и предпочтения “клиента”. По диалогам можно сделать RAG, а для запоминания предпочтений можно прикрутить Honcho или нечто подобное. Тогда можно будет задавать не только сиюминутные вопросы, но и говорить что-то вроде: “Помнишь, мы с тобой обсуждали…?” Возможно, для этого придется завести небольшой домашний сервер. :)
У меня немного более мощная система: ЦП AMD RYZEN AI MAX+ 395 w/ Radeon 8060S. Так что никаких теорий, чистая практика. Но если у вас так работает быстрее, значит используйте так.
Что касается раздела “Память”, то все зависит от того, куда вы там смотрите: налево, в столбец с разными метриками, или вправо-вверх, где указано общее количество памяти.
Да, но при чем тут VRAM? Вы же выше писали, что NPU грузит модели во VRAM, а также то, что зажали VRAM через параметры ядра в grub на уровне полугигабайта.
Напишу, как сейчас у меня. Всего 96ГБ общей памяти. При этом 16ГБ выделено под VRAM. И при этом же есть еще общая память графического процессора, выделяемая из RAM. У меня это 64 ГБ и не настраивается. Во всяком случае просто. NPU видит ровно те же 64 ГБ, но уже просто как общую память. Видимо, эта память делится между iGPU и NPU. Еще 16 никому не выделяется и остается под нужды системы. Т.е. у меня разбивка такая: 16 ГБ (система) + 64 ГБ (общая: IGPU, NPU, система) + 16 ГБ VRAM (iGPU).
В вашей цитате, по всей видимости, эти 15.1 ГБ - это и есть размер общей памяти (iGPU/NPU), только на системе с 32 ГБ памяти всего. Осложняется все тем, что и система видит эту память и тоже может занять ее под свои нужды. Т.е. вы бы в любом случае не смогли запустить gpt-oss:20b ни на iGPU, ни на NPU, без выгрузки экспертов или части слоёв в оставшуюся системную часть всей памяти.
Уверен, что вы понимаете, что в любом случае в память там дважды ничего не грузится. Я имею в виду и в VRAM, и в RAM. Видимо, как я писал выше, это особенности линуксовых драйверов. В Windows у меня NPU “видит” в 4 раза больше памяти, чем выделено под VRAM. Вполне себе дисбаланс.
Вспомнил, что в Питере у них есть лаборатория, занимающаяся ИИ. И если они не работают удаленно в кластерах Хуавей, то наверное да. Но лучше все же у того же Селектела уточнить.
Значит у нас одинаковые платформы. Правда, на ней я работаю в Windows. У меня размер общей памяти NPU отображается ровно таким же, как и размер общей памяти GPU. Из этого я делаю вывод, что по крайней мере в Windows, они делят общую память. Но в Linux все может быть иначе, конечно. Не перехожу в этом сетапе на линукс как раз из-за несколько лучшей его поддержки в Windows в настоящее время.
Не знаю. Я не из РФ.
По крайней мере в Windows на вашей платформе, думайте только про совокупный объём памяти, забудьте про деление на RAM/VRAM. Да, это может казаться контринтуитивно, но это так. Поначалу я тоже пытался выделить VRAM побольше, в силу привычки, но это на самом деле не нужно. Оставьте 8ГБ VRAM только под те вещи, которые нужны видеодрайверу (фреймбуфер, кэши всякие), да и все. Модель не должна на вашей платформе умещаться во VRAM чтобы работать на полной возможной скорости.
Отвечал, как будто у вас тоже AMD Strix Point. По всей видимости это не так. Но для этой платформы мой комментарий справедлив.
Справедливости ради, это не GPU, как в заголовке, а NPU. Я хотел взять, чтобы попробовать эти решения. Но отдельные карты за пределами Китая если и можно найти, то только нелегально. В составе решения же минимальный сервер Huawei Atlas 650E с 8 NPU Ascend 950DT стартует от полумиллиона долларов. Дороговато, чтобы попробовать технологию. С интересом жду результатов тестов от кого-то еще. В цене я уверен, т.к. я общаюсь с Huawei напрямую, был у них в кампусах в Шеньджене (на самом деле в соседнем городе Дунгуань, но для простоты даже их работники упоминают Шеньджень, как более известный город) и Шанхае.
Вы можете снизить объем VRAM до 16 ГБ или даже меньше и ничего скорее всего не изменится. Попробуйте. На этой платформе движку инференса все равно, в какой памяти лежит модель или как она делится между ними - память фактически одна и деление на RAM/VRAM там достаточно условное. Если вы работаете на этом компьютере в Windows, откройте диспетчер задач и на вкладке Производительность/Память вы должны увидеть все свои 64 ГБ, несмотря на то, что вы выделили 48 ГБ из нее под VRAM.
Я не вполне понимаю, почему вы сосредоточились именно на NPU. Да, NPU есть, но он тут играет далеко не главную роль. Ryzen AI 9 365 относится к Ryzen AI 300 / Strix Point, а встроенная Radeon 880M поддерживается AMD для LLM-инференса через iGPU. У меня немного более мощная конфигурация: Ryzen AI Max+ 395 с Radeon 8060S, NPU тоже есть, конечно. И тут есть важный нюанс в архитектуре - unified memory. Для инференса на iGPU на самом деле не сильно важно, сколько памяти отдано под VRAM, скорость доступа к VRAM практически идентична скорости доступа к RAM. Ваш NPU точно так же держит модели в той же RAM. Т.е. я хочу сказать, что нужно забыть про объемы RAM или VRAM, оценивая то, поместится модель или нет. У дискретной видеокарты RAM и VRAM - это две разные памяти, и веса модели приходится копировать из одной в другую. У встроенной Radeon память общая: CPU и GPU обращаются к одной и той же физической RAM. Поэтому деление на RAM и VRAM в значительной степени логическое. Очень условно, VRAM нужна для фреймбуфера, чтобы вы картинку на экране монитора видели. А движку все равно, где будет лежать модель, т.е. какая его часть попадет в VRAM, а что останется в RAM. Это одна и та же память.
Я гоняю основные модели именно на iGPU, оставив NPU под второстепенные модели и задачи. Попробуйте. Скорее всего производительность у вас вырастет. У меня Qwen3.6–35B‑A3B (Q4_K_M) стабильно выдает 60+ ток/с на decode, и 800-900 в prefill в LM Studio. У вас цифры будут пониже, но все равно должно быть быстрее, чем на NPU.
Самому стало интересно и я проверил Humo-Coder, т.к. это все же дообученная модель. У Humo-Coder зрение есть: та же архитектура, что у Qwen3.5: vision_config, 333 тензора зрительной части, препроцессоры для картинок и видео. Наше квантование его не трогало: в рецепте зрительная часть исключена.
Но оно не совпадает со зрением базовой Qwen3.5. Я сравнил с инкумбентом: это официальный квант Qwen3.5, зрение у него не сжато, и оно служит образцом базовых весов. Все 333 тензора различаются. Различие не тотальное, а похоже на след дообучения. Веса явно из той же линии, но сдвинуты, и чем глубже слой, тем сильнее. Так выглядит дообучение. Значит, авторы Ornith при своём обучении меняли и зрительный кодировщик. Либо они стартовали не с той контрольной точки Qwen3.5, что лежит в основе официального кванта - по весам этого не различить.
По поводу Humo-Coder - для задач, связанных с программированием, скорее всего да. Все же модель заметно выигрывает на этом поле у всех протестированных. Но тесты - одно, а как она покажет себя в реальной работе - другое. Будем проверять в реальной работе у себя.
Мультимодальность у моделей семейства Qwen3.5/3.6 есть, но в этом исследовании мы это не проверяли. Зрительный кодировщик у всех квантов, которые мы смотрели, оставлен несжатым - его веса такие же, как у базовой модели. Но изображение после кодировщика всё равно обрабатывает языковая часть, а она сжата в четыре бита, так что качество работы с картинками может отличаться - этого мы не измеряли.
Спасибо. Нет, Хумо - не файнтюн, т.е. дообучения не было. Обычная квантизация базавой Ornith-1.5 в GPTQ Int4 со своим калибровочным набором и шаблоном. Самое долгое в этом - сам процесс квантизации. Выложить, конечно, можно. Займет какое-то время на заливку. Тем более я сделал модель не только в safetensors, а еще линейку квантов в GGUF, начиная с IQ3_M до Q5_K_XL, с тем же калибровочным набором. Никогда не публиковал ничего на HF. Разберусь с этим и, вероятно, опубликую модель.
Да, в проде все еще 3.5. 3.8 тоже есть, но я так же хочу сделать собственный квант этой модели. Потом проведу аналогичное сравнение, чтобы определиться с тем, что оставлять на проде. Может быть заменит 3.5, если не будет слишком “дорогой” по токенам.
Её нет в размерности 35B-A3B. А так, мы ей тоже пользуемся, тоже в кванте Int4. Вопрос цены. Многие задачи решаются с тем же качеством и быстрее более слабыми моделями. К тому же это исследование может быть полезно тем, кто просто не может запустить 3.8 из-за ограничений, все же памяти там нужно намного больше для запуска. 3.6 я использую на своем настольном компьютере ежедневно, а вот 3.8 уже не выйдет.
Да, итог размытый. Потому что однозначный не получился. Выбор модели зависит от того, что вам нужно. Но для локального инференса у нас я пока решил оставаться на 3.5.
Что касается набора, то большая часть собрана из публично доступных. GPQA закрыт условиями доступа на Hugging Face и просит не публиковать вопросы в открытом виде. Поэтому его нужно скачивать самостоятельно. Остальное можно опубликовать. Но получится несколько репо. Нужно ли?
Сочувствую. Не так давно тоже прошел через автоматическую блокировку, невозможность выйти на людей и все стадии принятия. У меня там был чат, в котором я прорабатывал одну математическую идею в течение полугода практически в ежедневном режиме. Я бы не стал писать это все, если бы не одна причина - у меня остался локальный кэш Codex, из которого удалось восстановить всю проделанную работу, так что может еще не все потеряно и у вас. Но, конечно, все это заставляет вспомнить последнюю фразу из анекдота “Что там за шум на улице, Бэрримор?”
Согласен, что такое может быть, если шагов в 3 раза меньше, но каждый шаг занимает в 4 раза больше времени. Но в данном случае это не так, число операций в одном шаге сравнимо у обоих методов. Но если хотите, можем замеры и по времени сделать.