На hugging face несколько дней назад вышел еще Qwen3.8-27B thinkingcap он делает тоже самое за половину токенов. По крайней мере я за несколько дней тестирования разницы не заметил.
Так с их МоЕ и раньше норм было со слоями в ОЗУ, у них при выгрузке слоев скорость вообще почти не падала, до определенного количества. Тут активных параметров всего 6b т.е. на gpu можно хранить в 4,5 раза меньше кэша чем у 27b без серьезной потери скорости, ну если то что нужно храниться.
Unsloth gguf q1 там 3 файла, 10мб 50гб и 22.5 тот что 50 по идее можно даже на диск, но пока что в оперативу. А 22.5 у вас влезает в видеопамять, и в случае с мое не обязательно всему kv кэшу в видеопамять помещаться, по логике должна не просто запуститься так ещё и скорость давать. Но вот надо ли оно, сам сижу и думаю q1 у нее это 80% top1% Accuracy, 27b я могу в q6k_xl и это около 98%, в swe pro у моделей разница почти никакая 62,5 у flash и 61,7 у 27b. Но по всей видимости будет быстрее, в общем выглядит так как будто эта модель создана именно для того что бы ее исключительно на ОЗУ гонять. Т.к. с видеокартой 27b должна быть сильно умней при том же занимаемом объеме ГПУ.
Я почему спросил, не смог запустить safetensors llm на винде, хотя можно. Но для генерации картинок, flux2 fp8 влезает в мои 32гб, и скорость несоизмерима, gguf раз в 10 медленнее, я пытаюсь понять имеет ли смысл дальше копать т.к. есть нюанс с kv cache, я так понимаю flux быстро работает из за того что видимо без квантов отпадает необходимость в каком то кэше, но это диффузионная модель а не ллм. И не понятно имеет ли смысл ставить Линукс что бы vLLM запустить или sgLang.
Я запускаю на tesla v100 32gb, с учётом выхода недели назад qwen3.8 27b по уровню она между gpt5.5 и 5.6 по сути выше нее в списке только самые последние облачные модели. Кодить одно удовольствие уже 2мес код руками не пишу, по факту ещё с прошлой их модели 3.6 27b для локалки изменилось все, следующая сопоставимая модель весит раз в 10 больше. Софт для ЛЛМ вообще больше под Линукс заточен т.к. серверная инфраструктура и атом числе cuda драйверы, под Винду не все можно запустить особенно то что рассчитано на неквантованные модели. На локалке имеет смысл от 32гб vram иначе просто не хватит контекста что бы нормально задачи ставить, и это прям самый минимум для полноценного кодинга, приходится жертвовать длинной контекста и периодически ловить вылеты из за нехватки память. Меньше придется явно писать что где менять, а так сама раскапывает проект. Для работы я бы просто набрал таких же карт как у меня, пару штук, учитывая что аналог по возможностям только 5090 а за ее стоимость можно купить 6 таких. По скорости получается 5090 в 2 раза быстрей 1 v100, но опять же 2 v100 будут чуть медленнее но по возможностям несоизмеримо круче 5090. Правда новые архитектура позволяет запускать nvfp4 но это опять же для тех у кого памяти нет. На счёт облаков, тут сложно сказать я пробовал SourceCraft от Яндекса они не раскрывают модели, но они явно тупее этого Qwen, у Claude годные, но там лимиты непонятные у остальных дорого, я подсчитывал при моем режиме использования карта за мес окупается. Плюс нервов не хватит смотреть на то как горят твои токены из за того что сеть в цикл ушла, когда уже есть решение а облакам впадлу его внедрять, а может и просто не хочется. Да и по поводу скорости вообще не факт, сервак же не на одного тебя рассчитаны, там тоже крутят то запрос более тупой модели отдадут во время нагрузки, какие настройки, системные просты и шаблоны чатов там тоже хз.
Да только попробуй найди собранный llama с turboquant, aggresivemtp, dflash2 а для некоторых моделей их разрабы прям на HF пишут вот возьми этот комит llama и накоти на него этот гит патч, иначе модель не запустится. Почему так делают, из за cuda, которой миллион версий и большинство несовместимо между собой, а она с чего то вдруг должна иметь клиентскую библиотеку при сборке совпадающую с твоим драйвером. Я вообще в шоке с того как nvidia это поддерживает, вроде все обновляют и по много лет, но нах такие обновления если какая либо совместимость напрочь отсутствует.
Я как начал копать глубже, прошел следующим путем Ollama, LM-Studio, llama.cpp, beellama. И последний самый функциональный и быстрый, и не сталкивается с проблемами, и по факту самый удобный, сильно проще добавить какой то флаг в строку, чем искать где какой то переименованный флаг в настройках клиента, с учётом того что того что ты ищешь в данной реализации может небыть, а ещё лишнее место и потребление ресурсов, ну и самое важно очень часто там где ты взял модель в описании есть готовая команда для llama. Я не хотел во все это лезть но мне пришлось из за того что, разработчикам враперов было в падлу заглянуть чуть глубже и вывести в настройки самые важные параметры. А в итоге вопрос решает только llama и ее форки для разного рода быстрых кэшей и мтп, что для всего остального по факту не доступно, либо под linux.
Только если случилось чудо с Qwen Sparse Attention, вообще мое ведут себя неочень при длинном контексте, по крайней мере с 3.5 и 3.6 так было, там а3б вообще контекст нормально не понимали, вроде 250к а а по ощущениям каждые 30к контекста забывали что происходит.
Эта модель по сути инженерный образец для разработчиков, что бы научили софт с новыми фишками работать до выхода qwen4
Гугл врёт, в реальных задачах разница большая, даже между q8_K_L и q8_K_XL хоть и разница в точности уже какие то десятые процента. Но на деле попадается задача которую не можшь решить нейронкой убираешь 20к контекста, запускаешь модель на 500мб побольше, и она ее не замечает.
Скорей всего тоже самое, я и на 3.6 использовал 1 хотя везде написано что 0.6 Просто потестил и в 10 случаях из 10 это работало хуже. Это фича для тех времён когда для рассуждений и непосредственно изменения кода использовались разные модели. Можно в клиенте сделать что бы для чата 1 было, а для редактирования файлов 0.6. если работаешь без разделения 0.6 очень вредит, тупеет на порядок в сложных задачах.
--reasoning-effort не работает нормально, как я с ним не бился, да xhigh совсем упоротый но ни low ни medium, ни кастомные шаблоны со своими ароматами рассуждений ситуацию не меняют. Я на 3.8 перешёл с 3.6 ThinkingCap, после него это лажа. Только reasoning-budget помог но это костыль. ThinkingCap работал с тем же качеством, но в 5 раз меньше рассуждал без ограничителей. А 3.8 без бюджета вообще не целесообразно.
PS: смотрю у многих проблема с зацикливанием. Используйте вместо llama.cpp форк beellama он мгновенно в фоне их отлавливает.
Заметил что thinkingcap для 3.8 появился, пойду проверять.
На демонстрации так и было, но это была демонстрация возможностей. Судя по этой статье, технология вообще не предназначена для старых игр, dlss5 это замена почти всей части пайплайна DirectX и Vulkan которая выполнялась на видеокарте и в теории отказ от шейдеров и кучи настроек. А может до хейта они и в серьёз пытались скормить людям нейрослоп в 6000 серии, а теперь выкручиваются. Вообще не исключено. Опять же если это первый вариант, то первые нормальные игры с этим чудом мы увидим года через 3.
Люди просто не понимают что тут написано, единственное что понятно большинству это то что работать будет только начиная с 5000 серии и опять нужно денег. Они не знают что такое рендеринг как он работает, даже те кто много в игры играет. А по факту dlss5, это революция в том самом рендеринге сравнить которую можно разве что с появлением 3д графики в кино и играх. Многие ждут этого очень давно. А вообще это маркетологи обосралась, нефиг было это dlss5 называть, тем более с учётом того что эта технология не имеет ничего общего с dlss как и калечный фреймген которые до появления в видеокартах и так 15 лет работал на мобильных процессорах в тв с такими же задержками.
На текущий момент python в основном это для обучения и небольших скриптов, писать на нем крупные апи бизнесовых приложений не лучшая идея, не то что бы нельзя просто премуществ нет, одни недостатки.
Не совсем, на ноде прекрасно себя чувствуют большие проекты. А вот про не быстрое это да. Но скорость в реальности это тоже очень редкий кейс для бэкэнда. В большинстве бизнес приложений узким местом является БД. И по совокупности факторов у ноды очень много преимуществ. TypeScript высокоуровннвый язык и имеет много плюсов в плане времени разработки и при этом обладает типизацией что не типично для интерпритируемых языков но дает огромные плюсы в плане поддержки. Кроме того большинство разработчиков в вебе в какой то степени с ним знакомы. С точки зрения бизнеса на текущий момент, вряд ли какой либо язык обладает таким набором приемуществ. Поэтому на текущий момент, нода это мейнстрим. А вот для Go все очень туманно для хайлоада пришел Rust для скорости разработки Нода. Мне очень нравится Го как язык но к сожалению на мой взгляд для него просто нет места на рынке. Go очень дорогой не супер быстрый, количнство проектов не так велико, кроме того что он приятный в плане читаемости кода больше нечего выделить.
Проекты на python в целом не очень поддерживаются, да и среднее качество кода оставляет желать лучшего. Если вы пишите что то больше чем на 1000 строк кода, просто не делайте это на питоне. Это язык для студентов и дев опсов. В остальных случаях лучше его не использовать. Да на чем угодно можно писать качественный код но на python это гораздо сложнее.
Сейчас дизайнерам и художникам нужна видеокарта, что бы генерить картинки на локалке. NPU в процессоре позволят это делать на ультрабуках на которых они привыкли работать и в которых нет дискретных видеокарт. Уже тот же SDXL можно запустить на core i5 ultra без видеокарты. Когда раньше без дискретки на 8гб минимум твой пк шел лесом.
На hugging face несколько дней назад вышел еще Qwen3.8-27B thinkingcap он делает тоже самое за половину токенов. По крайней мере я за несколько дней тестирования разницы не заметил.
Так с их МоЕ и раньше норм было со слоями в ОЗУ, у них при выгрузке слоев скорость вообще почти не падала, до определенного количества. Тут активных параметров всего 6b т.е. на gpu можно хранить в 4,5 раза меньше кэша чем у 27b без серьезной потери скорости, ну если то что нужно храниться.
Unsloth gguf q1 там 3 файла, 10мб 50гб и 22.5 тот что 50 по идее можно даже на диск, но пока что в оперативу. А 22.5 у вас влезает в видеопамять, и в случае с мое не обязательно всему kv кэшу в видеопамять помещаться, по логике должна не просто запуститься так ещё и скорость давать. Но вот надо ли оно, сам сижу и думаю q1 у нее это 80% top1% Accuracy, 27b я могу в q6k_xl и это около 98%, в swe pro у моделей разница почти никакая 62,5 у flash и 61,7 у 27b. Но по всей видимости будет быстрее, в общем выглядит так как будто эта модель создана именно для того что бы ее исключительно на ОЗУ гонять. Т.к. с видеокартой 27b должна быть сильно умней при том же занимаемом объеме ГПУ.
Я почему спросил, не смог запустить safetensors llm на винде, хотя можно. Но для генерации картинок, flux2 fp8 влезает в мои 32гб, и скорость несоизмерима, gguf раз в 10 медленнее, я пытаюсь понять имеет ли смысл дальше копать т.к. есть нюанс с kv cache, я так понимаю flux быстро работает из за того что видимо без квантов отпадает необходимость в каком то кэше, но это диффузионная модель а не ллм. И не понятно имеет ли смысл ставить Линукс что бы vLLM запустить или sgLang.
Я запускаю на tesla v100 32gb, с учётом выхода недели назад qwen3.8 27b по уровню она между gpt5.5 и 5.6 по сути выше нее в списке только самые последние облачные модели. Кодить одно удовольствие уже 2мес код руками не пишу, по факту ещё с прошлой их модели 3.6 27b для локалки изменилось все, следующая сопоставимая модель весит раз в 10 больше. Софт для ЛЛМ вообще больше под Линукс заточен т.к. серверная инфраструктура и атом числе cuda драйверы, под Винду не все можно запустить особенно то что рассчитано на неквантованные модели. На локалке имеет смысл от 32гб vram иначе просто не хватит контекста что бы нормально задачи ставить, и это прям самый минимум для полноценного кодинга, приходится жертвовать длинной контекста и периодически ловить вылеты из за нехватки память. Меньше придется явно писать что где менять, а так сама раскапывает проект. Для работы я бы просто набрал таких же карт как у меня, пару штук, учитывая что аналог по возможностям только 5090 а за ее стоимость можно купить 6 таких. По скорости получается 5090 в 2 раза быстрей 1 v100, но опять же 2 v100 будут чуть медленнее но по возможностям несоизмеримо круче 5090. Правда новые архитектура позволяет запускать nvfp4 но это опять же для тех у кого памяти нет. На счёт облаков, тут сложно сказать я пробовал SourceCraft от Яндекса они не раскрывают модели, но они явно тупее этого Qwen, у Claude годные, но там лимиты непонятные у остальных дорого, я подсчитывал при моем режиме использования карта за мес окупается. Плюс нервов не хватит смотреть на то как горят твои токены из за того что сеть в цикл ушла, когда уже есть решение а облакам впадлу его внедрять, а может и просто не хочется. Да и по поводу скорости вообще не факт, сервак же не на одного тебя рассчитаны, там тоже крутят то запрос более тупой модели отдадут во время нагрузки, какие настройки, системные просты и шаблоны чатов там тоже хз.
Да только попробуй найди собранный llama с turboquant, aggresivemtp, dflash2 а для некоторых моделей их разрабы прям на HF пишут вот возьми этот комит llama и накоти на него этот гит патч, иначе модель не запустится. Почему так делают, из за cuda, которой миллион версий и большинство несовместимо между собой, а она с чего то вдруг должна иметь клиентскую библиотеку при сборке совпадающую с твоим драйвером. Я вообще в шоке с того как nvidia это поддерживает, вроде все обновляют и по много лет, но нах такие обновления если какая либо совместимость напрочь отсутствует.
Я как начал копать глубже, прошел следующим путем Ollama, LM-Studio, llama.cpp, beellama. И последний самый функциональный и быстрый, и не сталкивается с проблемами, и по факту самый удобный, сильно проще добавить какой то флаг в строку, чем искать где какой то переименованный флаг в настройках клиента, с учётом того что того что ты ищешь в данной реализации может небыть, а ещё лишнее место и потребление ресурсов, ну и самое важно очень часто там где ты взял модель в описании есть готовая команда для llama. Я не хотел во все это лезть но мне пришлось из за того что, разработчикам враперов было в падлу заглянуть чуть глубже и вывести в настройки самые важные параметры. А в итоге вопрос решает только llama и ее форки для разного рода быстрых кэшей и мтп, что для всего остального по факту не доступно, либо под linux.
Подскажи, а bf16 быстрей ггуфов же работает?
Только если случилось чудо с Qwen Sparse Attention, вообще мое ведут себя неочень при длинном контексте, по крайней мере с 3.5 и 3.6 так было, там а3б вообще контекст нормально не понимали, вроде 250к а а по ощущениям каждые 30к контекста забывали что происходит.
Эта модель по сути инженерный образец для разработчиков, что бы научили софт с новыми фишками работать до выхода qwen4
30-60к буд то бы маловато для программирования.
По поводу эндпоинтов он прав, это никакие не методы, именно эндпоинты.
Гугл врёт, в реальных задачах разница большая, даже между q8_K_L и q8_K_XL хоть и разница в точности уже какие то десятые процента. Но на деле попадается задача которую не можшь решить нейронкой убираешь 20к контекста, запускаешь модель на 500мб побольше, и она ее не замечает.
Скорей всего тоже самое, я и на 3.6 использовал 1 хотя везде написано что 0.6 Просто потестил и в 10 случаях из 10 это работало хуже. Это фича для тех времён когда для рассуждений и непосредственно изменения кода использовались разные модели. Можно в клиенте сделать что бы для чата 1 было, а для редактирования файлов 0.6. если работаешь без разделения 0.6 очень вредит, тупеет на порядок в сложных задачах.
--reasoning-effort не работает нормально, как я с ним не бился, да xhigh совсем упоротый но ни low ни medium, ни кастомные шаблоны со своими ароматами рассуждений ситуацию не меняют. Я на 3.8 перешёл с 3.6 ThinkingCap, после него это лажа. Только reasoning-budget помог но это костыль. ThinkingCap работал с тем же качеством, но в 5 раз меньше рассуждал без ограничителей. А 3.8 без бюджета вообще не целесообразно.
PS: смотрю у многих проблема с зацикливанием. Используйте вместо llama.cpp форк beellama он мгновенно в фоне их отлавливает.
Заметил что thinkingcap для 3.8 появился, пойду проверять.
На демонстрации так и было, но это была демонстрация возможностей. Судя по этой статье, технология вообще не предназначена для старых игр, dlss5 это замена почти всей части пайплайна DirectX и Vulkan которая выполнялась на видеокарте и в теории отказ от шейдеров и кучи настроек. А может до хейта они и в серьёз пытались скормить людям нейрослоп в 6000 серии, а теперь выкручиваются. Вообще не исключено. Опять же если это первый вариант, то первые нормальные игры с этим чудом мы увидим года через 3.
Люди просто не понимают что тут написано, единственное что понятно большинству это то что работать будет только начиная с 5000 серии и опять нужно денег. Они не знают что такое рендеринг как он работает, даже те кто много в игры играет. А по факту dlss5, это революция в том самом рендеринге сравнить которую можно разве что с появлением 3д графики в кино и играх. Многие ждут этого очень давно. А вообще это маркетологи обосралась, нефиг было это dlss5 называть, тем более с учётом того что эта технология не имеет ничего общего с dlss как и калечный фреймген которые до появления в видеокартах и так 15 лет работал на мобильных процессорах в тв с такими же задержками.
На текущий момент python в основном это для обучения и небольших скриптов, писать на нем крупные апи бизнесовых приложений не лучшая идея, не то что бы нельзя просто премуществ нет, одни недостатки.
Не совсем, на ноде прекрасно себя чувствуют большие проекты. А вот про не быстрое это да. Но скорость в реальности это тоже очень редкий кейс для бэкэнда. В большинстве бизнес приложений узким местом является БД. И по совокупности факторов у ноды очень много преимуществ. TypeScript высокоуровннвый язык и имеет много плюсов в плане времени разработки и при этом обладает типизацией что не типично для интерпритируемых языков но дает огромные плюсы в плане поддержки. Кроме того большинство разработчиков в вебе в какой то степени с ним знакомы. С точки зрения бизнеса на текущий момент, вряд ли какой либо язык обладает таким набором приемуществ. Поэтому на текущий момент, нода это мейнстрим. А вот для Go все очень туманно для хайлоада пришел Rust для скорости разработки Нода. Мне очень нравится Го как язык но к сожалению на мой взгляд для него просто нет места на рынке. Go очень дорогой не супер быстрый, количнство проектов не так велико, кроме того что он приятный в плане читаемости кода больше нечего выделить.
Проекты на python в целом не очень поддерживаются, да и среднее качество кода оставляет желать лучшего. Если вы пишите что то больше чем на 1000 строк кода, просто не делайте это на питоне. Это язык для студентов и дев опсов. В остальных случаях лучше его не использовать. Да на чем угодно можно писать качественный код но на python это гораздо сложнее.
Сейчас дизайнерам и художникам нужна видеокарта, что бы генерить картинки на локалке. NPU в процессоре позволят это делать на ультрабуках на которых они привыкли работать и в которых нет дискретных видеокарт. Уже тот же SDXL можно запустить на core i5 ultra без видеокарты. Когда раньше без дискретки на 8гб минимум твой пк шел лесом.