#gan #petproject

#gan #petproject

Памятка видео модель Wan2 (локальненько)

🔗 Основные репозитории
• Wan2.1 GitHub
github.com/Wan-Video/Wan2.1
• ComfyUI Wrapper
github.com/kijai/ComfyUI-WanVideoWrapper

🧩 Модели:
• VAE
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1_VAE_bf16.safetensors
• CLIP Vision
huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/resolve/main/split_files/clip_vision/clip_vision_h.safetensors?download=true
• UMT5 text encoder
huggingface.co/Kijai/WanVideo_comfy/blob/main/umt5-xxl-enc-fp8_e4m3fn.safetensors
huggingface.co/OreX/Models/blob/main/WAN/umt5_xxl_fp8_e4m3fn_scaled.safetensors
• Diffusion models
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-I2V-14B-480P_fp8_e4m3fn.safetensors
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-I2V-14B-720P_fp8_e4m3fn.safetensors
huggingface.co/city96/Wan2.1-I2V-14B-480P-gguf/blob/main/wan2.1-i2v-14b-480p-Q4_K_M.gguf
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-T2V-14B_fp8_e4m3fn.safetensors
huggingface.co/Kijai/WanVideo_comfy/blob/main/Wan2_1-T2V-1_3B_fp8_e4m3fn.safetensors
huggingface.co/city96/Wan2.1-I2V-14B-480P-gguf
civitai.com/models/1299436?modelVersionId=1466629

🛠 Кастомные ноды для ComfyUI:
• NF4/FP4 Loader
github.com/silveroxides/ComfyUI_bnb_nf4_fp4_Loaders
• GGUF Loader
github.com/city96/ComfyUI-GGUF

⚡️ Воркфлоу и примеры:
• wan_t2v_1.3b - текст в видео
github.com/Mozer/comfy_stuff/blob/main/workflows/wan_1.3b_t2v.json
• wan_i2v_14b_nf4_gguf - воркфлоу с квантами
github.com/Mozer/comfy_stuff/blob/main/workflows/wan_14b_i2v.json
• wanvideo_Fun - Fun модель (есть контроль видео)
github.com/kijai/ComfyUI-WanVideoWrapper/blob/main/example_workflows/wanvideo_Fun_control_example_01.json
• wan_1_3B_VACE_v2v_with_depth_and_lora (есть контроль и референс)
github.com/Mozer/comfy_stuff/blob/main/workflows/wan_1_3B_VACE_v2v_with_depth_and_lora.json
• wanvideo_FLF2V_720P - первый и последний кадр
github.com/kijai/ComfyUI-WanVideoWrapper/blob/main/example_workflows/wanvideo_FLF2V_720P_example_01.json

🎨 Лоры:
• Control Loras (spacepxl) - контролим видео
huggingface.co/spacepxl/Wan2.1-control-loras
• Remade-AI - крутой набор лор
huggingface.co/Remade-AI
• Depth LoRA (1.3B) - контролим лорой глубины
huggingface.co/spacepxl/Wan2.1-control-loras/blob/main/1.3b/depth/wan2.1-1.3b-control-lora-depth-v0.1_comfy.safetensors


🔥 Интересное

VACE
Remove/Replace ANYTHING (VACE + Wan2.1):
• Удаление объектов
civitai.com/models/1454934/remove-anything-with-vacewan21
youtube.com/watch?v=vioEox7CKUs
• Замена объектов
civitai.com/models/1470557?modelVersionId=1663316
youtube.com/watch?v=L9OJ-RsDNlY
• VACE GitHub
github.com/ali-vilab/VACE
• Wan+VACE ноды
github.com/kijai/ComfyUI-WanVideoWrapper
• Depth-Anything Nodes
github.com/DepthAnything/Depth-Anything-V2

Wan2.1-Fun-1.3B-InP:
• Модель
huggingface.co/spaces/alibaba-pai/Wan2.1-Fun-1.3B-InP
• Control LoRA
huggingface.co/alibaba-pai/Wan2.1-Fun-1.3B-Control
• FP8 веса Kijai
huggingface.co/Kijai/WanVideo_comfy/tree/main
• Wan2GP (low VRAM)
github.com/deepbeepmeep/Wan2GP

WAN 2.1 Fun ControlNet 1.1 (Alibaba):
• Хаггингфейс
huggingface.co/alibaba-pai/Wan2.1-Fun-V1.1-14B-Control/blob/main/README_en.md
• GitHub
github.com/aigc-apps/VideoX-Fun
• ComfyUI Readme
github.com/aigc-apps/VideoX-Fun/blob/main/comfyui/README.md
До 81 кадра, до 16 fps, до 1024p
Поддержка управления камерой и анимации по референсу

FLF2V (first-last-frame):
• Модель
huggingface.co/Wan-AI/Wan2.1-FLF2V-14B-720P
• Wan2.1 сайт
wan.video/
• Workflow пример
github.com/kijai/ComfyUI-WanVideoWrapper/blob/main/example_workflows/wanvideo_FLF2V_720P_example_01.json

🕹 Специализированные проекты

ReCamMaster:
• Код
github.com/KwaiVGI/ReCamMaster
• Workflow
drive.google.com/file/d/1E8fxHIhM9qI9YeeAxdTf3SmfqktZAN2W/view
• Видеотуториал
youtube.com/watch?v=TzkBJHu2P4s

Гугл опубликовал пост-мортем по позавчерашнему падению. Обычные ошибки, только на инфраструктуре планетарного масштаба.

У них есть внутренний сервис, который проверяет доступы (бабки, квоты и т. д.) перед тем, как API запрос доходит до любого продукта.

Эта программа берет из специальной глобальной базы данных правила, по которым проверяет каждый запрос и отвечает, пропускать его или нет.

В эту программу добавили поддержку нового типа квот. Программист допустил небрежность в новом коде и не проверял, насколько корректно записано это правило в базе, перед тем, как пытаться положить его в память. Обращение к несуществующей памяти — смертный грех, за такое программа мгновенно завершается (если программист не предусмотрел, что такое может случиться, а это не наш случай). При этом я бы не назвал это ошибкой, все мы люди, мы не идеальны и поэтому придумываем механизмы защиты от своей природы. В этом суть инженерного подхода.

Экземпляр этой программы работает в каждом регионе Гугла. Так как это серьезный, ключевой сервис, его выкатывают не во все регионы сразу, а по одному, внимательно отслеживая, не внесли ли программисты новые ошибки.

Более того, весь новый функционал специально помечают и сначала запускают только для внутреннего пользования, чтобы, даже при наличии ошибки, она не задела внешних клиентов. Этот механизм называется фича-флагами.

К сожалению, программист забыл настроить фича-флаги для этого кода. Кусочек программы с ошибкой запустился на всех пользователей сразу. Удивительно, что это не заметили на этапе code review!

Итак, проходит время, и вот программа с ошибкой запущена во всех регионах для всех пользователей. Кто-то добавляет в базу данных новое правило с новым типом квот, с пустым полем. Эта запись в течение десятков миллисекунд копируется во все регионы, и в каждом регионе программа проверки считывает новое правило, пытается обратиться к несуществующей памяти, падает, перезапускается и снова падает.

Тут в дело вступает, на мой взгляд, первая ошибка (а не просто человеческая небрежность) инженеров — система контроля доступа настроена так, что при отсутствии ответа от программы проверок она отклоняет запрос. Так называемый fail closed. Хорошо для замков на банковских сейфах, плохо для пожарных выходов.
В нашем случае система не пропускает ни один запрос.

Дежурные инженеры замечают проблему в течение 2 минут, за 10 минут находят причину (дежурная система и дежурные инженеры у Гугла достойны восхищения) и нажимают большую красную кнопку, которая должна выключить эту часть программы (ее программисты сделали). Ее включение занимает еще 30 минут. (Не понятно, почему этот механизм занимает 30 минут, а не 20 миллисекунд, но движемся дальше).

Система заработала, но из-за того, что она лежала 40 минут, накопилось много желающих отправить запрос еще раз, и они создали эффект толпы, которая набежала и перегрузила остальные соседние сервисы через наш сервис проверок. Оказалось, что он не ждет какое-то время, если нужный сервис отказывается ответить на запрос (для этого есть красивая схема exponential back off), а долбит до упаду, тем самым не давая системе возможности восстановиться. Пришлось руками ограничивать число запросов. На постепенную, ручную разгрузку очередей ушло еще 2 часа.

Ко всему прочему, Гугл час не мог опубликовать уведомление о проблеме, потому что сервис публикации статус-страниц зависит от системы, которая упала.

Как вывод, Гугл обещает пройтись по всем сервисам и убедиться, что они, во-первых, fail open, то есть пропускают запросы, когда падают, во-вторых, реализуют exponential back off, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!

Первые два пункта можно и нужно использовать в каждом проекте, даже если ты не Гугл.

О бедном т-тесте замолвите слово. Подробный разбор метода, в том числе "легендарное" требование нормальности распределения для использования т-теста.

Снова возвращаюсь к тому, что 10% успешных АБ-тестов считается нормой. Уже говорил, что в таком случае эксперименты становятся вместо инструмента тестирований гипотез инструментом оценки качества гипотез. Иногда некоторые компании рассказываю, что у них показатель успешных достигает 20-25%. Снимаю шляпу в таких случаях.

Качество гипотез страдает часто из-за отсутствия системности в работе с гипотезами, да и продуктами в целом. К сожалению, приходилось такое наблюдать. При этом, даже прохождение нашей гипотезы через простой чек-лист поможет откинуть большое количество мусора и сэкономить кучу времени и денег. Такие тоже встречал.

Итак, простой чек-лист. Гипотеза должна быть:

✅ Тестируема. У нас есть возможности протестировать данную гипотезу.
✅ Решает конкретную проблему. Гипотеза помогает решить заранее определенную и конкретную проблему.
✅ Есть набор изменений. Мы определили, какие изменения нужно внести, чтобы протестировать данную гипотезу.
✅ Есть обоснование. Мы можем обосновать, за счет чего и почему решение может решить проблему. Хорошая гипотеза сможет пройти допрос с пристрастием и ответить на вопросы типа «а с чего ты взял, что это поможет», «за счет чего метрика увеличится настолько». Необходимо, чтобы обоснование было подкреплено фактами, числами, а не фантазиями и чуйками, типа «я уверен в этом, зуб даю». Не нужно никому давать свой зуб, лучше показать чиселки.
✅ Измерима, выбраны метрики. Мы понимаем, как измерить эффект, выбрали метрики, изменение которых поможет нам понять, решается проблема или нет.
✅ Определены ожидаемые величины изменения метрик. Нежелательно запускать эксперимент, не предполагая, на какую величину может увеличиться метрика.
✅ Эта гипотеза — часть цепочки среди других гипотез. Гипотеза не должна существовать в вакууме отдельно от других гипотез. У нас есть понимание, что будет происходить в зависимости от результатов конкретного теста. Исследование текущей гипотезы должно вести к следующей и т.д. (в этом месте гуглим про цикл HADI)
✅ Есть полные текущие данные (количественные и качественные). Мы можем собрать текущие данные (просмотры, события и проч.) по метрикам, которые будем наблюдать при проведении АБ теста.
✅ Ведет к дополнительному знанию. В результате теста мы получим какую-то новую информацию.

Принятие сложного решения:

Значимые изменения почти никогда не проходят без рисков и боли в моменте.

– А что, если мы перепишем сервис X на стэке Y? Текущий становится всё сложнее поддерживать, мы замедляемся
– Звучит круто, но..вот эту часть логики может оказаться очень сложно переписать

– А что, если мы из этих двух команд соберем одну? Они явно работают над общей целью и цепочки коммуникаций сейчас искусственно разделены
– Интересно, но вот эти двое разработчиков могут расстроиться

Важные решения обычно решают серьёзные проблемы или несут существеный профит. И почти всегда находятся мелкие неприятности, которые сильно затрудняют их принятие.

Попытки найти абсолютно безрисковое решение сложной задачи заканчиваются успехом реже, чем приводят к параличу. И руководитель, с одной стороны, проблему в итоге не решает, а с другой – попадает в ситуацию внутреннего конфликта, чувствуя, что мог бы что-то сделать, но не делает.

––

Как не попадать в эту ловушку?

Мне помогает мысленный эксперимент, который можно провести не более, чем за единицы дней, выделив себе время и лист бумаги:

Представь, что:

1. Решение было принято
2. Риски реализовались
3. Ты потратил 4-6 месяцев упорной работы на то, чтобы справиться с их последствиями
4. Будущее, в котором ты оказался после этого – лучше или хуже настоящего?

Пункт (3) стоит сразу декомпозировать:

– Я распределю обязанности по таким-то членам команды. Открою найм такого-то человека.
– Логику X временно оставим в отдельном сервисе на стэке Y, если сходу не заведётся
– и т.д.

Очень часто в результате этого эксперимента можно увидеть, что:

(а) Негативные последствия несмертельны
(b) Часть негативных последствий можно нивелировать прямо сейчас, взявшись за пункты из декомпозиции шага (3)
(c) Картинка, которую ты видишь через полгода, оправдывает несколько месяцев борьбы с проблемами (которых ещё может и не возникнуть)

И решение, внезапно, принимается :)

Если же это не так – можно спокойно его отбросить, имея хорошую аргументацию, что стоимость рисков слишком высока.

––

Пользуйся и не застревай.

Дисклеймер: более одного-двух сложных решений впараллель принимать не стоит. Тебе ведь, возможно, и правда предстоит много работы :)

#llm #security

#agents #security

#llm #agents