Категория: Несоответствие входного буфера программы
Тип: Среда выполнения
Пример журнала ошибок
XlaRuntimeError: INVALID_ARGUMENT: Executable(jit_embedding_pipeline_step_fn) expected parameter 2482 of size 5242880 (bf16[16,1280,40]{2,1,0:T(8,128)(2,1)}) but got buffer with incompatible size 1638400 (bf16[16,1280,40]{1,2,0:T(8,128)(2,1)}): while running replica 0 and partition 0 of a replicated computation (other replicas may have failed as well).
Почему это происходит?
Эта ошибка возникает, когда среда выполнения XLA обнаруживает несоответствие между размером буфера памяти, ожидаемым скомпилированной программой, и размером буфера, фактически предоставленного во время выполнения. В сообщении об ошибке указаны как ожидаемый, так и фактический размеры, а также формы и макеты тензора.
Обратите внимание, что эти ошибки могут возникать, даже если два тензора имеют одинаковую форму, но их размер в памяти может быть разным, если их физическая компоновка (то, как данные размещены и организованы на оборудовании) различна.
Эти ошибки в основном вызваны: - Несоответствием контрольной точки и конфигурации XLA - Модель обучается, и контрольная точка сохраняется. Физическая схема весов в этой контрольной точке определяется точной версией и конфигурацией XLA (например, флагами XLA) на тот момент. Позже эта контрольная точка загружается в другую среду, где конфигурация изменилась. Новый флаг, другое значение по умолчанию или изменение в коде модели/XLA могут привести к тому, что среда выполнения будет ожидать другую физическую схему для весов. Когда старый буфер из контрольной точки передается в новую скомпилированную программу XLA, среда выполнения выдает ошибку. - Аппаратные/топологически-специфические схемы - Компилятор XLA может выбирать различные физические схемы для тензоров для оптимизации производительности на различном оборудовании. Схема, оптимальная для TPU v4, может отличаться от TPU v5 или даже для различных фрагментов pod одного и того же чипа (например, 4x4x4 против 4x8). Ошибка возникает, когда модель компилируется с предположением о компоновке одной топологии, но во время выполнения она запланирована на другую топологию, или в логике компоновки компилятора для конкретного оборудования есть ошибка.
Как пользователь может исправить свою программу, если такое произошло?
- Обеспечьте согласованность конфигурации между экспортом модели и повторными запусками из контрольных точек:
- Избегайте использования старых контрольных точек с новым кодом, если вы не уверены в том, что не были внесены изменения, влияющие на компоновку.
- Повторно экспортируйте сохраненную модель: если вы подозреваете несоответствие контрольной точки/конфигурации, наиболее надежным решением будет повторный экспорт сохраненной модели с использованием точно такой же (и текущей) кодовой базы и конфигурации, которые вы используете для вывода или точной настройки.
- Проверьте наличие изменений конфигурации (например, флагов XLA) между двумя запусками.
- Схемы, специфичные для оборудования/топологии:
- При переключении оборудования или топологии проверьте несоответствие версий оборудования и топологии.