Моделі та платформи ШІ
У Faiss 1.16.0 від Meta додано e-means для швидшої кластеризації великих масивів даних

Супроводжувачі Faiss від Meta випустили версію 1.16.0 10 листопада 2026 року, додавши алгоритм кластеризації e-means від FAIR at Meta з реалізаціями для CPU, GPU та розподілених систем. Дослідники повідомляють, що e-means досягає нижчої функції втрат, ніж k-means Ллойда, за 1,4–2,6 епохи замість 25, а час виконання на GPU скорочується у 10–45 разів порівняно з розглянутими реалізаціями.
Випуск програмного забезпечення відбувся після подання препринту дослідження до arXiv 6 листопада 2026 року, а не став першим публічним представленням алгоритму. Роботу виконали дослідники з FAIR at Meta та École Nationale des Ponts et Chaussées.
У версії 1.16.0 додано еталонні реалізації e-means, розподілене навчання та навчання з розподілом центроїдів між пристроями, бекенди призначення Triton і CuTe, призначення зі зниженою точністю, а також бенчмарки для відтворення результатів дослідження. До випуску також увійшли демонстрації з DINO, у яких дані зберігаються в пам’яті або потоково зчитуються з SSD.
Як e-means оновлює центроїди
Алгоритм k-середніх шукає центроїди, що мінімізують середній квадрат відстані між векторами та найближчими до них центроїдами; його застосовують для пошуку, квантування та впорядкування даних. Алгоритм Ллойда призначає кожну точку найближчому центроїду й заново обчислює суму та кількість точок у кожному кластері на основі всього набору даних. Натомість e-means оновлює експоненційно згасаючі суми й кількості на основі мініпакетів, тож вплив старіших призначень поступово слабшає; кожен центроїд і далі дорівнює відношенню поточної суми векторів до поточної кількості. Якщо використати весь набір даних як один пакет і встановити крок рівним 1, результатом буде одна ітерація алгоритму Ллойда.
Два апроксимовані закони масштабування визначають розмір пакета й початкову величину кроку на основі розміру набору даних, кількості кластерів і бюджету епох, усуваючи потребу в окремому переборі гіперпараметрів, необхідному для попередніх підходів із мініпакетами. За косинусним графіком крок зменшується до однієї десятої початкової величини. За замовчуванням випущений клас виконує п’ять проходів навчання й підтримує дробову кількість проходів.
Автори апроксимували закони масштабування, виконавши 75 000 оптимізаційних запусків на конфігураціях DEEP. За їхніми даними, медіанне відхилення на відкладеному наборі даних — тобто надлишкова похибка порівняно з найкращим налаштуванням у сітці — становить 0,07% для закону масштабування кроку та 0,19% для закону масштабування розміру пакета за замовчуванням. Цей метод також відновлює недостатньо заповнені кластери, розділяючи кластер-донор, а потім на завершення обчислює точне середнє для кожного кластера за призначеннями в останній епосі. Інший варіант завершення, що використовує повільно змінюване ковзне середнє, натомість оптимізує похибку на нових даних.
Бенчмарки охоплюють до десяти мільярдів векторів
У повній статті описано перевірку на наборах даних із вбудовуваннями та синтетичних даних. Основні порівняння на GPU проводилися на H100 із 80 ГБ пам’яті, а експерименти на CPU — на Xeon Platinum 8462Y+ із 64 ядрами. У 11 тестах на вбудовуваннях VIBE e-means, за даними авторів, потребував 1,6–2,6 епохи, щоб досягти похибки алгоритму Ллойда після 25 епох. Прискорення порівняно з Flash-KMeans становило від 8,0 до 22,8 раза на одному H100, а порівняно з Faiss — від 9,0 до 15,0 раза на 64 ядрах CPU; для кожного тесту використовували 20 початкових значень.
На найбільшому масштабі автори повідомляють, що розподілили DINO10B, який містить 10 мільярдів 1024-вимірних вбудовувань патчів DINO, на приблизно 16,7 мільйона кластерів за 2,5 епохи з точним призначенням, досягнувши трохи меншої похибки на тестових даних, ніж базовий варіант алгоритму Ллойда після 25 епох. Цей запуск потребував 779 GPU-годин на 32 машинах. В іншому запуску використовували наближений пошук найближчого центроїда через індекс інвертованих файлів (IVF): базового рівня вдалося досягти після трьох епох, витративши 23,2 GPU-години на одній машині з вісьмома GPU. Підхід IVF виконує пошук у вибраних групах центроїдів, а не порівнює кожну точку з кожним центроїдом.
У статті зазначено, що призначення за допомогою IVF у 34 рази дешевше за точне призначення для наборів із десятьма мільярдами векторів, але не дає переваг для 100 мільйонів векторів. Ця різниця показує, чому сама кількість епох не визначає потреби в інфраструктурі: обсяг апаратних ресурсів для запуску залежить від реалізації та методу призначення.
Доступність і задокументовані обмеження
В офіційному посібнику користувача наведено NumpyEmeans для даних NumPy та Emeans для тензорів PyTorch. Лише Faiss підтримує виконання на CPU; для виконання на GPU потрібен PyTorch із підтримкою CUDA. На H100 і H200 доступні ядра CuTe, а на інших сучасних GPU NVIDIA, що підтримуються, — Triton. На GPU знижена точність використовується лише під час призначення найближчого центроїда, тоді як центроїди, поточні суми та повернуті відстані залишаються у форматі FP32. Класи з реплікованими та розподіленими між пристроями центроїдами підтримують навчання на кількох GPU; у статті зазначено, що суми FP32 для 16 мільйонів центроїдів займають 64 ГіБ, що й обґрунтовує розподіл даних між пристроями на такому масштабі.
Закони масштабування налаштовували для даних із відносно великою розмірністю, і для наборів із дуже малою розмірністю або невеликого обсягу вони не є оптимальними. Тому для розмірності 16 або менше параметри за замовчуванням у випущеній версії обирають закон масштабування розміру пакета, орієнтований на якість, а для розмірності 2 або менше вимикають відновлення кластерів. У посібнику також застерігають, що повернуті навчальні мітки відповідають останньому проходу й не обов’язково є призначеннями до фінальних центроїдів, а шлях виконання на GPU не перевіряє вхідні дані на наявність значень NaN або нескінченності.
Для конвеєрів ШІ, які кластеризують великі набори вбудовувань, цей випуск наочно демонструє компроміс: менша кількість проходів навчання тепер доступна в бібліотеці, що перебуває на підтримці, тоді як найбільше скорочення використання GPU залежить від масштабу, апаратного забезпечення та відповідності наближеного призначення конкретному робочому навантаженню.












