Buckets:

hf-doc-build
/

doc

Files

xet

hf-doc-build/doc / diffusers /main /ru /training /distributed_inference.md

mishig

3 days ago

preview code

download

raw

5.14 kB

# Распределённый вывод

Распределённый вывод распределяет нагрузку между несколькими GPU. Это полезно для размещения более крупных моделей в памяти и для обработки большего количества запросов одновременно.

Diffusers поддерживает четыре стратегии. У каждой из них есть собственное руководство, а эта страница поможет вам выбрать нужную.

## Выбор стратегии

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

| Стратегия | Разделения | Уменьшает | Задержка для одного запроса | Лучше всего |
|---|---|---|---|---|
| [Параллелизм данных](../optimization/data_parallelism) | prompts между репликами | ничего, так как на каждом GPU хранится полная копия | без изменений | модель уже помещается в память, а у вас много промптов |
| [device_map](../optimization/device_map) | компоненты на разных устройствах | память весов | чуть хуже | модель не помещается в память, а межпроцессорное соединение медленное |
| [Параллелизм контекста](../optimization/context_parallelism) | входная последовательность | память активаций | ниже | последовательности длинные, например, изображения высокого разрешения или видео |
| [Параллелизм тензоров](../optimization/tensor_parallelism) | матрицы весов | память весов | ниже | веса одного компонента не помещаются, а межсоединение быстрое |

Некоторые практические рекомендации:

- Если модель уже помещается в память, а промптов много, используйте параллелизм данных. Он масштабирует пропускную способность в зависимости от количества GPU, не затрагивая модель, и не влияет на задержку для одиночного промпта. Настройте его с помощью [Accelerate](../optimization/data_parallelism#accelerate) или [PyTorch Distributed](../optimization/data_parallelism#pytorch-distributed).
- Если веса одного компонента не помещаются в память, сначала попробуйте тензорное параллелизм, так как он снижает как потребление памяти, так и задержку. Тензорное параллелизм требует обмена данными на каждой границе блока, поэтому для него необходим быстрый интерфейс, например NVLink. На PCIe трафик на каждый слой может превысить вычислительную выгоду, и в этом случае `device_map` становится лучшим выбором. `device_map` также решает проблему, когда компоненты по отдельности помещаются, но их совокупный размер слишком велик.
- Если проблема в активациях, а не в весах, используйте контекстный параллелизм. Это помогает при работе с длинными последовательностями, например, с крупными изображениями и видео, содержащими много кадров. Выберите бэкенд на основе бенчмарков из руководства [Context parallelism](../optimization/context_parallelism).
- Если и веса, и последовательность слишком велики, Diffusers не может применить тензорный и контекстный параллелизм к одной и той же модели. `ParallelConfig` вызывает ошибку, если передать оба конфигурации, а `enable_parallelism` нельзя вызвать второй раз для модели, которая уже распараллелена.

Интеграции сообщества [xDiT](../optimization/xdit) и [ParaAttention](../optimization/para_attn) предлагают собственные реализации контекстного параллелизма.

Xet Storage Details

Size:: 5.14 kB
Xet hash:: 4e1eeaef111480ce64776938b5856a304c79148a437548c4dec7dd0ca8aaf1d0

Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.

	# Распределённый вывод

	Распределённый вывод распределяет нагрузку между несколькими GPU. Это полезно для размещения более крупных моделей в памяти и для обработки большего количества запросов одновременно.

	Diffusers поддерживает четыре стратегии. У каждой из них есть собственное руководство, а эта страница поможет вам выбрать нужную.

	## Выбор стратегии

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

	\| Стратегия \| Разделения \| Уменьшает \| Задержка для одного запроса \| Лучше всего \|
	\|---\|---\|---\|---\|---\|
	\| [Параллелизм данных](../optimization/data_parallelism) \| prompts между репликами \| ничего, так как на каждом GPU хранится полная копия \| без изменений \| модель уже помещается в память, а у вас много промптов \|
	\| [device_map](../optimization/device_map) \| компоненты на разных устройствах \| память весов \| чуть хуже \| модель не помещается в память, а межпроцессорное соединение медленное \|
	\| [Параллелизм контекста](../optimization/context_parallelism) \| входная последовательность \| память активаций \| ниже \| последовательности длинные, например, изображения высокого разрешения или видео \|
	\| [Параллелизм тензоров](../optimization/tensor_parallelism) \| матрицы весов \| память весов \| ниже \| веса одного компонента не помещаются, а межсоединение быстрое \|

	Некоторые практические рекомендации:

	- Если модель уже помещается в память, а промптов много, используйте параллелизм данных. Он масштабирует пропускную способность в зависимости от количества GPU, не затрагивая модель, и не влияет на задержку для одиночного промпта. Настройте его с помощью [Accelerate](../optimization/data_parallelism#accelerate) или [PyTorch Distributed](../optimization/data_parallelism#pytorch-distributed).
	- Если веса одного компонента не помещаются в память, сначала попробуйте тензорное параллелизм, так как он снижает как потребление памяти, так и задержку. Тензорное параллелизм требует обмена данными на каждой границе блока, поэтому для него необходим быстрый интерфейс, например NVLink. На PCIe трафик на каждый слой может превысить вычислительную выгоду, и в этом случае `device_map` становится лучшим выбором. `device_map` также решает проблему, когда компоненты по отдельности помещаются, но их совокупный размер слишком велик.
	- Если проблема в активациях, а не в весах, используйте контекстный параллелизм. Это помогает при работе с длинными последовательностями, например, с крупными изображениями и видео, содержащими много кадров. Выберите бэкенд на основе бенчмарков из руководства [Context parallelism](../optimization/context_parallelism).
	- Если и веса, и последовательность слишком велики, Diffusers не может применить тензорный и контекстный параллелизм к одной и той же модели. `ParallelConfig` вызывает ошибку, если передать оба конфигурации, а `enable_parallelism` нельзя вызвать второй раз для модели, которая уже распараллелена.

	Интеграции сообщества [xDiT](../optimization/xdit) и [ParaAttention](../optimization/para_attn) предлагают собственные реализации контекстного параллелизма.