Цікаве дослідження від Meta щодо тенденцій масштабування апаратного забезпечення. Більше відеокарт не завжди означає швидше навчання. Стандартний підхід до масштабування навчання LLM сьогодні залишається додатковим апаратним забезпеченням для вирішення проблеми. Більше акселераторів, більше паралелізму, більше обчислень. Однак існує межа, яку більшість команд не бачать, поки не досягнуть її. Це нове дослідження демонструє, що масштабування загальної кількості акселераторів для навчання великих моделей швидко дає зменшуючий прибуток, навіть при оптимізованому апаратному забезпеченні та стратегіях паралелізації. Дослідники протестували моделі Llama-2 (параметри від 1B до 70B) на 8–2 048 GPU, що охоплюють апаратне забезпечення V100, A100 та H100. Що вони знайшли? При масштабуванні з 128 до 2 048 GPU пропускна здатність знизилася на 37,22%, а споживання енергії на GPU — лише на 5,87%. Винуватець — це накладні витрати на комунікацію. На великих масштабах операції AllGather і ReduceScatter (дві примітиви MPI) стають вузькими місцями. Більшість комунікації стає відкритою, і обчислення більше не можуть приховати затримку. Парадоксально, але стратегії паралелізму моделей (тензорний і конвеєрний паралелізм на ступенях 2-4), які раніше вважалися такими, що зменшують використання апаратного забезпечення, насправді стають кращими на масштабі. Вони зменшують відкриту комунікацію порівняно з чистим паралелізмом даних. На новішому обладнанні використання погіршується, а не покращується. Використання FLOPS моделей знизилося з 59,67% на A100 до 40,77% на H100; Швидші чіпи створюють більше комунікаційних витрат. Чому це важливо: Додавання більшої кількості GPU дає низьку граничну продуктивність на додаткову одиницю потужності або годину GPU. Командам, які масштабуються до тисяч акселераторів, потрібно ретельно переосмислити стратегії паралелізації, а не вважати, що більше обладнання означає швидше навчання.

Це так смачно! 🤯 n8n просто зробив процес MCPіфікації ваших агентських робочих процесів. Ви можете шукати, переглядати та запускати свої n8n робочі процеси з ChatGPT або Claude Code. Дивіться, як я почав використовувати його для оптимізації моїх AI-агентів.

Класна стаття від Meta. І ще одне чудове застосування багатоагентних систем. (зберіть у закладки) Навчання сучасних моделей ШІ вимагає величезних обсягів високоякісних даних. Однак вузьке місце — це не лише кількість. Дані просто недостатньо різноманітні. Окремі моделі, що генерують синтетичні дані, зазвичай дають однорідні результати, повторюються закономірності та не мають тієї тонкої різноманітності, як у створених людиною наборах даних. Це нове дослідження від Meta представляє Matrix — peer-to-peer фреймворк, де кілька агентів ШІ спільно генерують синтетичні навчальні дані через децентралізовані взаємодії. Matrix досягає на 2–15× вищу пропускну здатність даних при ідентичних апаратних ресурсах, не втрачаючи якість вихідних даних. Коротко; DR: Замість того, щоб одна модель створювала дані, спеціалізовані агенти виконують окремі ролі та взаємодіють між собою. Один ставить питання, інший відповідає, третій оцінює якість. Ці багатоповоротні розмови відображають складне мислення та різноманітні точки зору. Що відрізняє Matrix: немає центрального координатора. Агенти спілкуються безпосередньо в повністю децентралізованій архітектурі. Це забезпечує масштабованість без вузьких місць інфраструктури. Фреймворк працює через протоколи розмов на основі ролей, багатоповоротні патерни взаємодії та вбудовану фільтрацію якості на кожному етапі. До фінального навчального набору потрапляють лише дані, що відповідають пороговим вимогам якості. Багатоагентна співпраця створює більш різноманітні синтетичні дані, ніж підходи з однією моделлю. Отримані набори даних покращують продуктивність моделі на основі орієнтирів міркування та виконання інструкцій.