100% используется. Сталкивался с подобной проблемой изнутри несколько раз, руками (до эпохи ЛЛМ). Не только непосредственно запись в видео, а просто сам по себе захват рабочего стола.
В общем случае чтобы это работало быстро и меньше грузило комп, нужно, чтобы максимум работы делалось аппаратно (видеокартой например). В очень упрощённом виде картинка рабочего стола в ОС лежит либо в видеопамяти, либо в общей памяти (если ноут/разделяемая память) в формате RGB. Для видео её надо:
Опционально — отмасштабировать (если разрешение записи отличается от разрешения экрана)
Перегнать из RGB в YCbCr (яркость + дельта красного + дельта синего) — видео в RGB редкость
Сделать субдискретизацию — инфа о яркости в оригинальном разрешении, а о цвете (дельты красного/синего) — в 1/4. Бывает видео и без этой штуки, но оно очень редкое
Закодировать кодеком (H264/H265/AV1 и прочие)
Записать полученную порцию данных на диск
То есть у нас тут участвует куча железяк (проц, оперативка, видеочип, видеопамять, диск) и то, про что все любят забывать — каналы связи между ними.
Если всё делать аппаратно, будет хорошо. Но если выбирать, то самое тяжёлое тут — кодек.
Однако помимо самих вычислений есть ещё проблема перекачки данных между памятью через PCIe — это касается компов где RAM (основная оперативная память) и VRAM (память видеокарты) разделены. Типовой рабочий стол будет создавать поток данных в 1,5 Гбит/с (1920 * 1080 * 30 к/с * 3 канала * 8 бит в байте = 1,492992 гбит/с). Впрочем, компов с общей памятью это тоже касается: просто так копировать такой поток тоже небесплатно.
Так вот. Если реализация всего этого конвейера корявая — она уже на 1 этапе будет копировать всё в RAM, что нагрузит шину, и далее будет грузить CPU предобработкой и кодированием. Если реализация более‑менее вменяемая — она будет делать копирование из VRAM в другую область VRAM (копия рабочего стола), потом делать предобработку, потом копировать в RAM, потом из RAM обратно в VRAM (1,5 + 1,5 гбит/с = 3 гбит/с нагрузки) и там пинать аппаратный кодек. А результат обратно в RAM (впрочем, он уже мелкий) и оттуда в диск.
То есть даже если используется аппаратный кодек там всё равно есть чему положить слабый CPU. Шина памяти узкая (за раз копируется мало), операций копирования нужно вызвать много, всё, приехали. Поток данных толстый — любой лишний мув съедает ресурсы.
И вот если всё делается на месте без копирований — цепляемся напрямую к буферу рабочего стола, не копируем, сразу преобразуем, субдискретизируем и пихаем его в аппаратный кодек тут же на видеокарте, и только потом сжатый поток крошечного размера скидываем в RAM чтобы проц просто скинул его на диск — вот тогда получается вкусно.
Судя по всему — софт автора — это оно.
Но засунуть весь этот конвейер в видеокарту и предусмотреть все возможные конфигурации железа пользователей (разделяемая/общая память, nvenc, quick sync и прочие; разные ОС) — довольно геморное занятие. И автоперебор на тему «что прокатит то юзаем» — это один из вариантов. Правда, нужно чтобы автоматом остальная часть конвейера собиралась под удавшуюся реализацию.
Железо это еще не всё. Как правило (не всегда но чаще всего) у Apple с завода хорошая калибровка цвета. И не только у мониторов - айфоноайпады тоже хороши.
PS. Сам ушёл от мониторов, юзаю телики. Цвета не точные, но в остальном сплошные плюсы.
Потому что она стоит на месте. Герцы раскрываются в движении.
Если эта лампочка будет быстро двигаться мимо Вас в темноте со скоростью например 40 км/ч и Вы попытаетесь сопроводить её взглядом — она рассыпется на двадцатисантиметровые пунктиры на фоне размытого окружения, а не будет статичным объектом вокруг которого движется окружение, как это ожидается.
Если днем смотреть на едущую мимо машину — она статично проецируется на сетчатку, а окружение вокруг двигается назад. Если бы машина не двигалась, а дискретно 50 раз в секунду телепортировалась на 20 см вперед — то сопроводить взглядом бы ее не получилось, потому что глаз ожидает, что если он крутится то на сетчатке статичная машина на фоне размытого фона. При 50 Гц глаз вращается плавно, а проекция машины дрожит на сетчатке вперед‑назад.
Так вот, на мониторах объекты не двигаются — они как раз так дискретно телепортируются. Поэтому чем больше герц, тем меньше дрожь на сетчатке при сопровождении взглядом.
Модельку выложил на Sketchfab и просто вставил ссылку в «Медиаэлемент» — насколько я понимаю, штука довольно универсальная. То, что так можно делать, выявил чисто эмпирически, что она ещё умеет не знаю, но подозреваю что много чего :)
Решил поковырять задачу локально. Предварительно перегнал в фотореализм через flux2dev (надпись он сохранил), потом сунул в Hunyuan-3D-2.1. Надпись уничтожена, остальное на троечку. Впрочем, я ожидал худшего:)
3DAiStudio кстати заработал и даже выдал что-то вменяемое, но лимиты у них конченые, это да
Имхо — 3д генераторы заточены под восстановление геометрии из фотореализма, где светотень подсказывает сетке, где выпкулость/вогнутость. Мультик для них это боль.
Тут фокус в том что то что есть сейчас (почти) достигло потолка. У нас сейчас уже те самые «микросхемы с ручками для переноски» — посмотрите как ставят Threadripper в сокет. Видеокарта весит 4 кг. Для датацентров планируют карты в 15квт делать. Чипы уже такие есть (и они размером с тарелку). Дальнейшее увеличение производительности требует физического увеличения размера устройства и его потребления. Даже Microsoft вспомнил что пихать браузерный движок в блокнот это возможно не самый лучший подход.
Поэтому если горизонты не видны — их придётся найти, если мы хотим избежать стагнации/упадка прогресса. Текущий подход себя исчерпывает.
Когда узнал про принцип работы RAG представлял его себе как большое многомерное пространство с точками‑смыслами, и когда LLM хочет оттуда что‑то дернуть она вычленяет общие смыслы того что надо, и по их координатам дергает ближайшие точки из этого пространства и сцепленные с ними цитаты.
И была идея воткнуть в это пространство смыслов кротовые норы, которые бы отражали логические связи между смыслами. Логические связи по задумке надо было обнаруживать на этапе формирования БД. Идея в том, что если два смысла имеют логическую связь, но при этом находятся на большом декартовом расстоянии, то добавление такого вот портала рядом с ними создавало бы аномалию с существенно меньшим расстоянием между ними.
Типо вот
Но идея уперлась в то, что такое искривленное неравномерное пространство считать гораздо сложнее, чем прямое. Ну то есть наверно можно засунуть RAG в какое‑нибудь гиперболическое пространство (Пуанкаре‑эмбеддинги, привет) но при решении в лоб это будет жрать столько, что все плюсы будут нивелироваться, плюс поверх этого отвалятся стандартные плюшки вроде индексов faiss/hnsw. Хотя можно вместо искривлённого пространства просто насовать туда точек‑телепортов, наподобие входов в пв‑туннели у Буджолд. Только тут вместо пятимерности пятитысячемерность, которая немножечко более ресурсоёмка.
И вот эта штука из статьи имхо решает эту задачу, и решает круто, красиво и изящно.
Нейросети жрут видеопамять большой ложкой. 32 Гб это минимум на котором можно запускать жирные LLM (120b+) с более‑менее приемлемой скоростью; всякие толстые генераторы картинок с вменяемым качеством (которое может и пахнет нейрослопом, но не так сильно). Flux2dev 8bit например, или Wan2.2. А ещё есть такая штука как файнтюнинг.
Есть 3ds maxы и blenderы, которые на хорошей видеокарте могут рендерить трассировкой пути (не та которая в играх а полноценной) чуть ли не в реалтайме, или в разрешениях 130 МПикс+. Видеокартой. Можно даже запрягать несколько рендерингов одновременно. Можно грузить одновременно генерацию видео и монтажную программу: пока рендерится одно, монтируешь другое.
Плюс есть вот такие вот конфигурации мониторов
в которых современные недооптимизированные игры на человеческой видеокарте выдадут, в лучшем случае, 10 фпс. Если вообще запустятся.
В общем, смысл в том, что граница между профессиональным использованием и игровым нечёткая, она размыта — это раз, два — есть особо тяжелые игровые сетапы с большой площадью экранов и/или высокими требованиями к fps, которые обычные видеокарты просто не потянут.
Какие модели? Какой движок? Какие gpu? Сколько vram? Какой CPU? Версия PCIe? От этих факторов все зависит. Чем выше интенсивность обмена и хуже скорость этого pcie, тем меньше будет пользы.
mmap это вообще пакость. Она нужна вроде как чтобы модель быстрее стала доступна для использования даже пока все веса еще не загрузились, на деле только хуже делает и замедляет всё. На качество она влиять не должна.
Попробуйте всё запихнуть в GPU
То есть мы все слои пихаем в VRAM («Передача на GPU»), KVCache тоже туда. Всё что можно.
Длину контекста можно поставить любую, лишь бы в VRAM влезло. Для комфортной работы лучше 65к или 128к, хотя выше 48к у подобных моделей может начать ухудшаться мышление, особенно на низкой квантизацией (4K_M передаёт привет).
Я думаю речь о сообразительности. Всё таки опусосоннеты посуровей раз в 20, чем даже 122b/397b локальные модельки. Я тоже среди прочих гонял Qwen 3.6 35b a10b 4k_m. Она работает конечно как ракета, там под 10–15 строк в секунду вылетает. Но она, во‑первых на thinking может запросто потратить 10–30 секунд, а то и минуту, что немного портит впечатление от скорости, во‑вторых, может зациклиться, если ее заставлять читать какие‑нибудь консольные выводы при работе ffmpeg или установки пакетов питона. В‑третьих с некоторыми простыми задачами она тупо иногда не справляется. У 27b dense в этом плане получше конечно, но она в ~3 раза медленнее.
Я понимаю что можно взять другой рантайм, можно температуру покрутить и TopK, и ещё что‑нибудь, но когда ты практически решаешь задачу на это не хочется тратить время.
Локальные ЛЛМ на сегодняшний день, ИМХО про рутину и про бизнес‑логику, про установку настройку пакетов. Средние и сложные технические и/или нетривиальные задачи лучше им не давать, если нервы дороги.
Самый простой путь — в LMStudio открыть окно скачивания моделей. Там как магазин приложений на смартфоне. Ищите штуки которые поместятся в комп, смотрите число лайков и скачиваний, описание. Нажимаете «Download» — качается в фоне, пока качается одна или несколько моделей можно использовать текущие.
Зато dense может решать такую сложную и нетривиальную задачу как «Дай командную строку ffmpeg чтобы вытащить каждый 30 кадр из видео». И не уходит в зацикливание, и без thinking на 10к токенов. В отличие от 35ba3b. Скорость ниже раза в 3, это да (60 т/с вместо 180 т/с), но лучше получать медленнее результат, чем быстрее чушь)
Спойлер от Qwen 3.8 27b NVFP4
100% используется. Сталкивался с подобной проблемой изнутри несколько раз, руками (до эпохи ЛЛМ). Не только непосредственно запись в видео, а просто сам по себе захват рабочего стола.
В общем случае чтобы это работало быстро и меньше грузило комп, нужно, чтобы максимум работы делалось аппаратно (видеокартой например). В очень упрощённом виде картинка рабочего стола в ОС лежит либо в видеопамяти, либо в общей памяти (если ноут/разделяемая память) в формате RGB. Для видео её надо:
Опционально — отмасштабировать (если разрешение записи отличается от разрешения экрана)
Перегнать из RGB в YCbCr (яркость + дельта красного + дельта синего) — видео в RGB редкость
Сделать субдискретизацию — инфа о яркости в оригинальном разрешении, а о цвете (дельты красного/синего) — в 1/4. Бывает видео и без этой штуки, но оно очень редкое
Закодировать кодеком (H264/H265/AV1 и прочие)
Записать полученную порцию данных на диск
То есть у нас тут участвует куча железяк (проц, оперативка, видеочип, видеопамять, диск) и то, про что все любят забывать — каналы связи между ними.
Если всё делать аппаратно, будет хорошо. Но если выбирать, то самое тяжёлое тут — кодек.
Однако помимо самих вычислений есть ещё проблема перекачки данных между памятью через PCIe — это касается компов где RAM (основная оперативная память) и VRAM (память видеокарты) разделены. Типовой рабочий стол будет создавать поток данных в 1,5 Гбит/с (1920 * 1080 * 30 к/с * 3 канала * 8 бит в байте = 1,492992 гбит/с). Впрочем, компов с общей памятью это тоже касается: просто так копировать такой поток тоже небесплатно.
Так вот. Если реализация всего этого конвейера корявая — она уже на 1 этапе будет копировать всё в RAM, что нагрузит шину, и далее будет грузить CPU предобработкой и кодированием. Если реализация более‑менее вменяемая — она будет делать копирование из VRAM в другую область VRAM (копия рабочего стола), потом делать предобработку, потом копировать в RAM, потом из RAM обратно в VRAM (1,5 + 1,5 гбит/с = 3 гбит/с нагрузки) и там пинать аппаратный кодек. А результат обратно в RAM (впрочем, он уже мелкий) и оттуда в диск.
То есть даже если используется аппаратный кодек там всё равно есть чему положить слабый CPU. Шина памяти узкая (за раз копируется мало), операций копирования нужно вызвать много, всё, приехали. Поток данных толстый — любой лишний мув съедает ресурсы.
И вот если всё делается на месте без копирований — цепляемся напрямую к буферу рабочего стола, не копируем, сразу преобразуем, субдискретизируем и пихаем его в аппаратный кодек тут же на видеокарте, и только потом сжатый поток крошечного размера скидываем в RAM чтобы проц просто скинул его на диск — вот тогда получается вкусно.
Судя по всему — софт автора — это оно.
Но засунуть весь этот конвейер в видеокарту и предусмотреть все возможные конфигурации железа пользователей (разделяемая/общая память, nvenc, quick sync и прочие; разные ОС) — довольно геморное занятие. И автоперебор на тему «что прокатит то юзаем» — это один из вариантов. Правда, нужно чтобы автоматом остальная часть конвейера собиралась под удавшуюся реализацию.
PS. Софт огонь, попробую устроить ему стресс‑тест
Железо это еще не всё. Как правило (не всегда но чаще всего) у Apple с завода хорошая калибровка цвета. И не только у мониторов - айфоноайпады тоже хороши.
PS. Сам ушёл от мониторов, юзаю телики. Цвета не точные, но в остальном сплошные плюсы.
Потому что она стоит на месте. Герцы раскрываются в движении.
Если эта лампочка будет быстро двигаться мимо Вас в темноте со скоростью например 40 км/ч и Вы попытаетесь сопроводить её взглядом — она рассыпется на двадцатисантиметровые пунктиры на фоне размытого окружения, а не будет статичным объектом вокруг которого движется окружение, как это ожидается.
Если днем смотреть на едущую мимо машину — она статично проецируется на сетчатку, а окружение вокруг двигается назад. Если бы машина не двигалась, а дискретно 50 раз в секунду телепортировалась на 20 см вперед — то сопроводить взглядом бы ее не получилось, потому что глаз ожидает, что если он крутится то на сетчатке статичная машина на фоне размытого фона. При 50 Гц глаз вращается плавно, а проекция машины дрожит на сетчатке вперед‑назад.
Так вот, на мониторах объекты не двигаются — они как раз так дискретно телепортируются. Поэтому чем больше герц, тем меньше дрожь на сетчатке при сопровождении взглядом.
https://habr.com/ru/articles/682140/#Частота
Глаз может и 10000 Гц увидеть. Обычный. Ваш тоже.
С кулак они были во времена HD/FullHD, сейчас вполне ок
24 дюйма 4К с расстояния 50 см это то же самое, что 55 дюймов 4К с 114 см — угловой размер пикселя одинаковый
Как монитор оно очень удобное
Вот это ключевое. А если говорить про качественные — то там все поголовно смарт.
Модельку выложил на Sketchfab и просто вставил ссылку в «Медиаэлемент» — насколько я понимаю, штука довольно универсальная. То, что так можно делать, выявил чисто эмпирически, что она ещё умеет не знаю, но подозреваю что много чего :)
Решил поковырять задачу локально. Предварительно перегнал в фотореализм через flux2dev (надпись он сохранил), потом сунул в Hunyuan-3D-2.1. Надпись уничтожена, остальное на троечку. Впрочем, я ожидал худшего:)
3DAiStudio кстати заработал и даже выдал что-то вменяемое, но лимиты у них конченые, это да
Имхо — 3д генераторы заточены под восстановление геометрии из фотореализма, где светотень подсказывает сетке, где выпкулость/вогнутость. Мультик для них это боль.
Тут фокус в том что то что есть сейчас (почти) достигло потолка. У нас сейчас уже те самые «микросхемы с ручками для переноски» — посмотрите как ставят Threadripper в сокет. Видеокарта весит 4 кг. Для датацентров планируют карты в 15квт делать. Чипы уже такие есть (и они размером с тарелку). Дальнейшее увеличение производительности требует физического увеличения размера устройства и его потребления. Даже Microsoft вспомнил что пихать браузерный движок в блокнот это возможно не самый лучший подход.
Поэтому если горизонты не видны — их придётся найти, если мы хотим избежать стагнации/упадка прогресса. Текущий подход себя исчерпывает.
Когда узнал про принцип работы RAG представлял его себе как большое многомерное пространство с точками‑смыслами, и когда LLM хочет оттуда что‑то дернуть она вычленяет общие смыслы того что надо, и по их координатам дергает ближайшие точки из этого пространства и сцепленные с ними цитаты.
И была идея воткнуть в это пространство смыслов кротовые норы, которые бы отражали логические связи между смыслами. Логические связи по задумке надо было обнаруживать на этапе формирования БД. Идея в том, что если два смысла имеют логическую связь, но при этом находятся на большом декартовом расстоянии, то добавление такого вот портала рядом с ними создавало бы аномалию с существенно меньшим расстоянием между ними.
Но идея уперлась в то, что такое искривленное неравномерное пространство считать гораздо сложнее, чем прямое. Ну то есть наверно можно засунуть RAG в какое‑нибудь гиперболическое пространство (Пуанкаре‑эмбеддинги, привет) но при решении в лоб это будет жрать столько, что все плюсы будут нивелироваться, плюс поверх этого отвалятся стандартные плюшки вроде индексов faiss/hnsw. Хотя можно вместо искривлённого пространства просто насовать туда точек‑телепортов, наподобие входов в пв‑туннели у Буджолд. Только тут вместо пятимерности пятитысячемерность, которая немножечко более ресурсоёмка.
И вот эта штука из статьи имхо решает эту задачу, и решает круто, красиво и изящно.
Нейросети жрут видеопамять большой ложкой. 32 Гб это минимум на котором можно запускать жирные LLM (120b+) с более‑менее приемлемой скоростью; всякие толстые генераторы картинок с вменяемым качеством (которое может и пахнет нейрослопом, но не так сильно). Flux2dev 8bit например, или Wan2.2. А ещё есть такая штука как файнтюнинг.
Есть 3ds maxы и blenderы, которые на хорошей видеокарте могут рендерить трассировкой пути (не та которая в играх а полноценной) чуть ли не в реалтайме, или в разрешениях 130 МПикс+. Видеокартой. Можно даже запрягать несколько рендерингов одновременно. Можно грузить одновременно генерацию видео и монтажную программу: пока рендерится одно, монтируешь другое.
Плюс есть вот такие вот конфигурации мониторов
в которых современные недооптимизированные игры на человеческой видеокарте выдадут, в лучшем случае, 10 фпс. Если вообще запустятся.
В общем, смысл в том, что граница между профессиональным использованием и игровым нечёткая, она размыта — это раз, два — есть особо тяжелые игровые сетапы с большой площадью экранов и/или высокими требованиями к fps, которые обычные видеокарты просто не потянут.
Какие модели? Какой движок? Какие gpu? Сколько vram? Какой CPU? Версия PCIe? От этих факторов все зависит. Чем выше интенсивность обмена и хуже скорость этого pcie, тем меньше будет пользы.
Я не автор если что)
mmap это вообще пакость. Она нужна вроде как чтобы модель быстрее стала доступна для использования даже пока все веса еще не загрузились, на деле только хуже делает и замедляет всё. На качество она влиять не должна.
Попробуйте всё запихнуть в GPU
То есть мы все слои пихаем в VRAM («Передача на GPU»), KVCache тоже туда. Всё что можно.
Длину контекста можно поставить любую, лишь бы в VRAM влезло. Для комфортной работы лучше 65к или 128к, хотя выше 48к у подобных моделей может начать ухудшаться мышление, особенно на низкой квантизацией (4K_M передаёт привет).
Я думаю речь о сообразительности. Всё таки опусосоннеты посуровей раз в 20, чем даже 122b/397b локальные модельки. Я тоже среди прочих гонял Qwen 3.6 35b a10b 4k_m. Она работает конечно как ракета, там под 10–15 строк в секунду вылетает. Но она, во‑первых на thinking может запросто потратить 10–30 секунд, а то и минуту, что немного портит впечатление от скорости, во‑вторых, может зациклиться, если ее заставлять читать какие‑нибудь консольные выводы при работе ffmpeg или установки пакетов питона. В‑третьих с некоторыми простыми задачами она тупо иногда не справляется. У 27b dense в этом плане получше конечно, но она в ~3 раза медленнее.
Я понимаю что можно взять другой рантайм, можно температуру покрутить и TopK, и ещё что‑нибудь, но когда ты практически решаешь задачу на это не хочется тратить время.
Локальные ЛЛМ на сегодняшний день, ИМХО про рутину и про бизнес‑логику, про установку настройку пакетов. Средние и сложные технические и/или нетривиальные задачи лучше им не давать, если нервы дороги.
Самый простой путь — в LMStudio открыть окно скачивания моделей. Там как магазин приложений на смартфоне. Ищите штуки которые поместятся в комп, смотрите число лайков и скачиваний, описание. Нажимаете «Download» — качается в фоне, пока качается одна или несколько моделей можно использовать текущие.
Более умный начал душнить. Про проветривание. Я нахожу эту ненамеренную постсамоиронию очень человечной :)
Нынче уже лучше, чем год назад. Они по‑прежнему тупые, но простые задачи решать уже могут.
Просто надо трезво на это смотреть, без «Локальная qwen 4b a1b обогнала Claude Opus 4.7 в 99% тестов, облака больше не нужны!!1»
Зато dense может решать такую сложную и нетривиальную задачу как «Дай командную строку ffmpeg чтобы вытащить каждый 30 кадр из видео». И не уходит в зацикливание, и без thinking на 10к токенов. В отличие от 35ba3b. Скорость ниже раза в 3, это да (60 т/с вместо 180 т/с), но лучше получать медленнее результат, чем быстрее чушь)