И правда, совсем распоясались уже! А если по сути, классная тема на самом деле, так как показывает что для диффузных моделей кол-во измерений не проблема. Вопрос только в обучающий выборке, и в том может ли эта модель создавать что-то помимо одного дженеиичного домика как в этой демке. Ну и как оно скейлится на большие объемы, кубически по сложности, или там какие-то хаки применены. Эх, ушла эпоха...
Посмотрите в сторону SpaceTime DB в качестве бекенда, сэкономит вам кучу времени, и повысит вероятность того что не утонете в разработке собственного реалтаймового сервера.
Я вроде как про качество источника спросил а не про Китай. Вы когда подобные сомнительные изображения вставляете в свой материал, вы проверяете их достоверность? Или просто доверяете авторитетности источника?
А какие-то более авторитетные источники помимо ньюсвик имеются? Они только картинки с иероглифами у себя разместили, и "ууу какой плохой и страшный китай и рф" по всему тексту, а ссылок на патент, или его номер, ни чего нет. Я тоже могу прикольных картинок нарисовать.
С приходом llm'ок я решил что буду общаться с ними только на английском, и как можно больше рутинных задач решать через них. За пол года уровень письма и легкость чтения улетела в небеса. По этому да, всеми руками подтверждаю, что регулярность повышает погруженность, а она в свою очередь, эффективность обучения.
Сколько по времени и деньгам уходит на создание сета скажем из 10 изображений? В целом это можно все и локально провернуть при наличии мощной видеокарты. Но ваш вариант конечно удобнее будет для большинства и проще чем тот же comfyui и локальное обучение лоры.
Имхо. Как и все поделки на расте, эта выглядит так же шапкозакидательно как и всё остальное "написаное на раст btw". На мой взгляд у tauri слишком много минусов чтобы делать на нём сколь нибудь серьёзный проект.
Отсутствие гарантии наличия web view на компе у конечного пользователя
Отсутствие гарантии что через пару лет сам microsoft не решит выпилить webview из дефолтной поставки, или что будет продолжать его обновлять
Зоопарк браузерных движков на разных платформах, с разным подмножеством поддерживаемых фичь
Rust. Я уж лучше буду на плюсах писать чем на этом творении великого сумрачного гения. Сколько там людей на рынке, кто согласиться писать на расте нативные расширения не связанные с криптой, и прочим модным молодёжным?
Короче говоря, если это не пет проект, и жизненный цикл продукта больше чем 5 лет, electron будет сильно лучше и надёжнее. Плюс ко всему старые билды будут запускаться, и что самое главное работать, вне зависимости от того что там снаружи.
Было бы здорово в начале статьи привести пару примеров, где собственно эти собственные числа и векторы применяются. В чем их практический смысл. Чтобы у человека в первый раз их встречающего сформировалась более плотная ассоциация, и ему было проще вспомнить про вашу статью. В остальном, спасибо за материал.
Причина тряски сеньор помидор? А если серьёзно, вот вы как опытный, взрослый и критически мыслящий человек, хорошо разбирающийся в своей предметной области, почему не можете различить маркетинг и реальность? Понятно ведь что ни какое это не ии, а просто цветастый буклетик с обещаниями. И problem solving'ом там даже не пахнет. А все кто только сегодня приходит в профессию, так же неизбежно пройдут все те же самые когнитивные трудности усвоения профессии, прежде чем станут профессионалами. Единственное отличие будет лишь в том, что им будет проще чем нам с вами, потому что у них теперь есть более крутые инструменты.
Zig Roadmap 2024, первоисточник так сказать, тут интересный сегмент начинается на 4:00 и заканчивается в районе 20:00.
Вы не подумайте, я не спора ради, а скорее про то что изначальная причина в моём понимании немного другая.
Про последнее где LLVM's lack of ability to optimize them. Да, очевидно что проблемы с LLVM есть, и вероятно далеко не последние. Просто масштаб этих проблем не сопоставим. Да llvm не умеет чего-то делать так как им нужно. Но написать адаптер, который будет транспайлить код на Zig в тот же C, и затем скомпилировать это с помощью того же LLVM всё ещё сильно проще чем писать что-то своё. Опять таки, речь и в стриме и в релиз ноутах идёт именно про Debug сборки, для десктопов.
По вашей же ссылке чуть ниже написано:
These problems are surmountable, but it will take time.
В общем причины для отказа есть, но я готов поставить все $7 на то что они от него не откажутся, пока LLVM будет актуален в других местах и будет развиваться.
В остальном держу кулачки за Zig, классная штука. Пусть я на нём и не пишу но тулчейн для своих поделок на С++ использую. Спасибо что занимаетесь популяризацией данного проекта в рунете!
Про собственный компилятор Эндрю говорил на одном из последних стримов немного в другом ключе. Они собираются его выкатить для того чтобы ускорить дебажные сборкии, чтобы начать быстрее разгребать беклог, который растет сильно быстрее чем они могут с ним справиться. Одной из главных причин он называл медленную итерацию из-за скорости llvm при сборке промежуточных билдов. Собственный компилятор должен дать супер быструю сборку в debug режиме, на одной десктопной платформе, не более того. А отказываться от llvm совсем, они точно не собираются, поскольку для сборки тех же релизных билдов, да еще и под пару десятков железных архитектур они точно никогда такой компилятор не осилят. Так же терять interop с С/C++, который прям киллер фича, тоже такая себе затея.
Не рассказал, потому что текущий вариант реализации плохо применим на практике.
TensorRT штука интересная, потому что позволяет в 2+ раз ускорять генерацию изображений. Как Proof of Concept норм, но у неё слишком много минусов чтобы рекомендовать её:
Для каждого чекпоинта приходится создавать отдельную модель которая занимает 1гб+
Модели-ускорители создаются под конкретное разрешение
Не работают Lora. А чтобы заработали их нужно смерджить с чекпоинтом, что долго, не удобно, занимент много места. А учитывая то что Lora часто не одна, и хочется покрутить её вес в промпте, это прям совсем для любителей.
Довольно проблематично установить
В текущей реализации оно подходит разве что для чат-ботов, которые аватарки генерят, где пайплайн максимально фиксирован, а машинное время дорогое. Для ручной генерации изображений, да и тем более новичкам, оно точно не нужно.
Прироста точно не будет, так как драйвер для видеокарты у вас всё равно будет виндовый. По мимо этого WSL требует для своей работы дополнительной оперативной памяти. И если у вас в системе не 20гб+ ram, это будет ощутимо при работе с XL моделями, в особенности в моменты их загрузки в память.
SD устанавливается в одну папку, и не особо мусорит в системе т.к. все зависимости устанавливаются в venv. Так же будет проще с загрузкой моделей, каждый чекпоинт весит 2гб+ (для 1.5) и 6гб+ (для XL), и его может быть накладно копировать в файловую систему WSL. Либо придётся сразу загружать из терминала с помощью того же wget'a.
В общем явных преимуществ нет, а вот неудобств вероятно добавится.
По мимо самого gpu на производительность так же сильно влияет объём памяти. И
Опять таки, что считать комфортным каждый определяет для себя сам, и тут нужно понимать какой предполагается сценарий использования. Если в рекреационных целях, раз в неделю погенерить аниме или каких-то весёлых картинок, тут да, не так важно в целом. Но если рассматривать SD как один из инструментов применивых в работе, то тут же чем быстрее, тем лучше.
2 серия нвидий и правда сравнима по скорости с 3 сериией на генерации мелких изображений. Но тут ещё нужно брать во внимание объём памяти у самой видеокарты. Если её будет недостаточно, то скорость генерации будет падать в разы из-за свопинга. И происходить это будет на последних этапах работы над изображением, когда разрешение уже относительно высокое (1500px+). Так же будет проблематично использовать XL модели, так как у них требования к памяти ещё выше.
В моей практике, для создания чего-то интересного обычно приходится запускать процесс генерации десятки а то и сотни раз (начальный процесс, плюс все последующие доработки), и если бы генерация занимала не 5-10-15 секунд, а скажем 1-2 минуты, пользоваться этим для полезных практических применений было бы затруднительно.
По этому я бы ориентировался скорее на объём памяти (8гб ок, но лучше 12), если SD применяется в качестве инструмента для работы. 3060 с 12гб не сильно ударит по карману, и даст хороший экспириенс в плане времени иттерации.
PS. Товарищи с THG сделали сравнение разных видеокарт на генерации маленького изображения. Получилось следующее:
Но опять таки, это маленькие изображения, если бы сравнение проводилось на больших (этап доработки), были бы совсем другие результаты.
В общем и целом согласен. Спасибо что потратили время на уточнение моих неточностей.
Я в некоторых моментах сознательно допускал неточности чтобы донести "качественую" характеристеку и не зарываться при этом в детали. В процессе работы с инструментом пытливый человек всё-равно будет пробовать разные подходы, и обнаружит для себя более эффективные и действенные методы. Я постарался дать отправную точку, чтобы глаза не разбегались.
Единственное что хотелось бы уточнить - про экспериментальность ComfyUI. Да безусловно, возможностей влезть в процесс inferenca там больше и как следствие, контроля над происходящим. Но начинать я бы с него всё-же не стал, так как нужно иметь большой багаж знаний и хорошо понимать что происходит внутри SD чтобы иметь возможность своими руками собрать нужный граф. И в разряд экспериментальных он в моём представлении попадает именно потому что в нём реализуют самые сложные и нетривиальные workflow. Для 95% задач не требуется слишком сложного начального этапа. Да и постобработка, что после ComfyUI, что после Automatic1111 в большинстве сулчаев необходима.
Тогда на помощь приходит скриптинг...
Что интересно могло бы быть аналогом в мире LLM'ок?
И правда, совсем распоясались уже!
А если по сути, классная тема на самом деле, так как показывает что для диффузных моделей кол-во измерений не проблема. Вопрос только в обучающий выборке, и в том может ли эта модель создавать что-то помимо одного дженеиичного домика как в этой демке. Ну и как оно скейлится на большие объемы, кубически по сложности, или там какие-то хаки применены.
Эх, ушла эпоха...
Посмотрите в сторону SpaceTime DB в качестве бекенда, сэкономит вам кучу времени, и повысит вероятность того что не утонете в разработке собственного реалтаймового сервера.
Я вроде как про качество источника спросил а не про Китай. Вы когда подобные сомнительные изображения вставляете в свой материал, вы проверяете их достоверность? Или просто доверяете авторитетности источника?
А какие-то более авторитетные источники помимо ньюсвик имеются? Они только картинки с иероглифами у себя разместили, и "ууу какой плохой и страшный китай и рф" по всему тексту, а ссылок на патент, или его номер, ни чего нет. Я тоже могу прикольных картинок нарисовать.
С приходом llm'ок я решил что буду общаться с ними только на английском, и как можно больше рутинных задач решать через них. За пол года уровень письма и легкость чтения улетела в небеса. По этому да, всеми руками подтверждаю, что регулярность повышает погруженность, а она в свою очередь, эффективность обучения.
Сколько по времени и деньгам уходит на создание сета скажем из 10 изображений?
В целом это можно все и локально провернуть при наличии мощной видеокарты. Но ваш вариант конечно удобнее будет для большинства и проще чем тот же comfyui и локальное обучение лоры.
Имхо. Как и все поделки на расте, эта выглядит так же шапкозакидательно как и всё остальное "написаное на раст btw". На мой взгляд у tauri слишком много минусов чтобы делать на нём сколь нибудь серьёзный проект.
Отсутствие гарантии наличия web view на компе у конечного пользователя
Отсутствие гарантии что через пару лет сам microsoft не решит выпилить webview из дефолтной поставки, или что будет продолжать его обновлять
Зоопарк браузерных движков на разных платформах, с разным подмножеством поддерживаемых фичь
Rust. Я уж лучше буду на плюсах писать чем на этом творении великого сумрачного гения. Сколько там людей на рынке, кто согласиться писать на расте нативные расширения не связанные с криптой, и прочим модным молодёжным?
Короче говоря, если это не пет проект, и жизненный цикл продукта больше чем 5 лет, electron будет сильно лучше и надёжнее. Плюс ко всему старые билды будут запускаться, и что самое главное работать, вне зависимости от того что там снаружи.
Было бы здорово в начале статьи привести пару примеров, где собственно эти собственные числа и векторы применяются. В чем их практический смысл. Чтобы у человека в первый раз их встречающего сформировалась более плотная ассоциация, и ему было проще вспомнить про вашу статью. В остальном, спасибо за материал.
А что за софт у вас на скринах? Это кастом, или что-то с github'a?
Если не затруднит, дайте пожалуйста пару ссылок, на попробовать / изучения темы
Причина тряски сеньор помидор?
А если серьёзно, вот вы как опытный, взрослый и критически мыслящий человек, хорошо разбирающийся в своей предметной области, почему не можете различить маркетинг и реальность? Понятно ведь что ни какое это не ии, а просто цветастый буклетик с обещаниями. И problem solving'ом там даже не пахнет. А все кто только сегодня приходит в профессию, так же неизбежно пройдут все те же самые когнитивные трудности усвоения профессии, прежде чем станут профессионалами. Единственное отличие будет лишь в том, что им будет проще чем нам с вами, потому что у них теперь есть более крутые инструменты.
Zig Roadmap 2024, первоисточник так сказать, тут интересный сегмент начинается на 4:00 и заканчивается в районе 20:00.
Вы не подумайте, я не спора ради, а скорее про то что изначальная причина в моём понимании немного другая.
Про последнее где
LLVM's lack of ability to optimize them. Да, очевидно что проблемы с LLVM есть, и вероятно далеко не последние. Просто масштаб этих проблем не сопоставим. Да llvm не умеет чего-то делать так как им нужно. Но написать адаптер, который будет транспайлить код на Zig в тот же C, и затем скомпилировать это с помощью того же LLVM всё ещё сильно проще чем писать что-то своё. Опять таки, речь и в стриме и в релиз ноутах идёт именно про Debug сборки, для десктопов.По вашей же ссылке чуть ниже написано:
В общем причины для отказа есть, но я готов поставить все $7 на то что они от него не откажутся, пока LLVM будет актуален в других местах и будет развиваться.
В остальном держу кулачки за Zig, классная штука. Пусть я на нём и не пишу но тулчейн для своих поделок на С++ использую. Спасибо что занимаетесь популяризацией данного проекта в рунете!
Про собственный компилятор Эндрю говорил на одном из последних стримов немного в другом ключе. Они собираются его выкатить для того чтобы ускорить дебажные сборкии, чтобы начать быстрее разгребать беклог, который растет сильно быстрее чем они могут с ним справиться. Одной из главных причин он называл медленную итерацию из-за скорости llvm при сборке промежуточных билдов. Собственный компилятор должен дать супер быструю сборку в debug режиме, на одной десктопной платформе, не более того. А отказываться от llvm совсем, они точно не собираются, поскольку для сборки тех же релизных билдов, да еще и под пару десятков железных архитектур они точно никогда такой компилятор не осилят. Так же терять interop с С/C++, который прям киллер фича, тоже такая себе затея.
Не рассказал, потому что текущий вариант реализации плохо применим на практике.
TensorRT штука интересная, потому что позволяет в 2+ раз ускорять генерацию изображений. Как Proof of Concept норм, но у неё слишком много минусов чтобы рекомендовать её:
Для каждого чекпоинта приходится создавать отдельную модель которая занимает 1гб+
Модели-ускорители создаются под конкретное разрешение
Не работают Lora. А чтобы заработали их нужно смерджить с чекпоинтом, что долго, не удобно, занимент много места. А учитывая то что Lora часто не одна, и хочется покрутить её вес в промпте, это прям совсем для любителей.
Довольно проблематично установить
В текущей реализации оно подходит разве что для чат-ботов, которые аватарки генерят, где пайплайн максимально фиксирован, а машинное время дорогое. Для ручной генерации изображений, да и тем более новичкам, оно точно не нужно.
Прироста точно не будет, так как драйвер для видеокарты у вас всё равно будет виндовый. По мимо этого WSL требует для своей работы дополнительной оперативной памяти. И если у вас в системе не 20гб+ ram, это будет ощутимо при работе с XL моделями, в особенности в моменты их загрузки в память.
SD устанавливается в одну папку, и не особо мусорит в системе т.к. все зависимости устанавливаются в venv. Так же будет проще с загрузкой моделей, каждый чекпоинт весит 2гб+ (для 1.5) и 6гб+ (для XL), и его может быть накладно копировать в файловую систему WSL. Либо придётся сразу загружать из терминала с помощью того же wget'a.
В общем явных преимуществ нет, а вот неудобств вероятно добавится.
По мимо самого gpu на производительность так же сильно влияет объём памяти. И
Опять таки, что считать комфортным каждый определяет для себя сам, и тут нужно понимать какой предполагается сценарий использования. Если в рекреационных целях, раз в неделю погенерить аниме или каких-то весёлых картинок, тут да, не так важно в целом. Но если рассматривать SD как один из инструментов применивых в работе, то тут же чем быстрее, тем лучше.
2 серия нвидий и правда сравнима по скорости с 3 сериией на генерации мелких изображений. Но тут ещё нужно брать во внимание объём памяти у самой видеокарты. Если её будет недостаточно, то скорость генерации будет падать в разы из-за свопинга. И происходить это будет на последних этапах работы над изображением, когда разрешение уже относительно высокое (1500px+). Так же будет проблематично использовать XL модели, так как у них требования к памяти ещё выше.
В моей практике, для создания чего-то интересного обычно приходится запускать процесс генерации десятки а то и сотни раз (начальный процесс, плюс все последующие доработки), и если бы генерация занимала не 5-10-15 секунд, а скажем 1-2 минуты, пользоваться этим для полезных практических применений было бы затруднительно.
По этому я бы ориентировался скорее на объём памяти (8гб ок, но лучше 12), если SD применяется в качестве инструмента для работы. 3060 с 12гб не сильно ударит по карману, и даст хороший экспириенс в плане времени иттерации.
PS. Товарищи с THG сделали сравнение разных видеокарт на генерации маленького изображения. Получилось следующее:
Но опять таки, это маленькие изображения, если бы сравнение проводилось на больших (этап доработки), были бы совсем другие результаты.
Ох, боюсь это тема для отдельной статьи...
В общем и целом согласен. Спасибо что потратили время на уточнение моих неточностей.
Я в некоторых моментах сознательно допускал неточности чтобы донести "качественую" характеристеку и не зарываться при этом в детали. В процессе работы с инструментом пытливый человек всё-равно будет пробовать разные подходы, и обнаружит для себя более эффективные и действенные методы. Я постарался дать отправную точку, чтобы глаза не разбегались.
Единственное что хотелось бы уточнить - про экспериментальность ComfyUI. Да безусловно, возможностей влезть в процесс inferenca там больше и как следствие, контроля над происходящим. Но начинать я бы с него всё-же не стал, так как нужно иметь большой багаж знаний и хорошо понимать что происходит внутри SD чтобы иметь возможность своими руками собрать нужный граф. И в разряд экспериментальных он в моём представлении попадает именно потому что в нём реализуют самые сложные и нетривиальные workflow. Для 95% задач не требуется слишком сложного начального этапа. Да и постобработка, что после ComfyUI, что после Automatic1111 в большинстве сулчаев необходима.