Гайд · TNWS AI
Почему Flax NNX Rngs возвращает новые ключи при каждом вызове
Потоки params и dropout в Flax 0.12.10: счётчик, fold_in, уникальные ключи и воспроизводимость последовательности по seed.
Задача и применимость
Актуальный запрос: «почему Flax NNX Rngs каждый раз новый key». Понять stateful-обёртку NNX над функциональными JAX PRNG keys. nnx.Rngs хранит seed key и счётчик потока; каждый запрос ключа увеличивает счётчик и использует jax.random.fold_in. Разные именованные потоки разделяют назначения параметров и dropout, а новый контейнер с теми же seeds воспроизводит ту же последовательность запросов.
Материал проверен на Flax 0.12.10, JAX/jaxlib 0.11.2 и Python 3.12 на CPU. Используется актуальный API from flax import nnx, а не устаревший экспериментальный import и не Linen. Пример не загружает веса или внешние данные и решает одну изолированную задачу. Численный тест подтверждает контракт кода в указанной версии, но не качество нейросети на рабочем датасете.
Перед запуском установите совместимые версии пакетов в отдельное окружение и выведите flax.__version__, jax.__version__ и jaxlib.__version__. Не смешивайте примеры NNX с похожими по названию конструкциями Linen: у них различаются жизненный цикл Module, представление состояния, инициализация и способы применения transformations. При переносе кода сначала выберите один API и следуйте документации именно его версии.
Пошаговое решение
- Создайте два независимых Rngs с одинаковыми seeds потоков params и dropout.
- Дважды запросите params-key и один раз dropout-key из каждого.
- Проверьте совпадение последовательностей между контейнерами.
- Проверьте различие соседних ключей одного потока и разных потоков.
Готовый проверяемый шаблон
import jax.numpy as jnp
from flax import nnx
rngs_a = nnx.Rngs(params=0, dropout=1)
rngs_b = nnx.Rngs(params=0, dropout=1)
a_p1, a_p2, a_d1 = rngs_a.params(), rngs_a.params(), rngs_a.dropout()
b_p1, b_p2, b_d1 = rngs_b.params(), rngs_b.params(), rngs_b.dropout()
assert jnp.array_equal(a_p1, b_p1)
assert jnp.array_equal(a_p2, b_p2)
assert jnp.array_equal(a_d1, b_d1)
assert not jnp.array_equal(a_p1, a_p2)
assert not jnp.array_equal(a_p1, a_d1)
print(a_p1, a_p2, a_d1)
Вход и ожидаемый результат
Два контейнера с seeds params=0, dropout=1 породили идентичные последовательности при одинаковом порядке запросов. Первый и второй params-key различались; dropout-key отличался от params-key.
Как проверить результат
В regression test воспроизводите не только seeds, но и порядок запросов: дополнительный вызов изменит последующие ключи. Для параллельных экспериментов документируйте именованные потоки и не смешивайте генерацию параметров, dropout и данных.
Перенос в рабочую модель
В рабочем проекте зафиксируйте контракт batch: порядок осей, dtype, диапазон признаков и семантику target. Инициализацию, dropout и генерацию данных разделяйте по именованным RNG streams. Обучаемые nnx.Param, статистическое состояние и optimizer state сохраняйте и проверяйте раздельно. Перед обновлением Flax/JAX прогоняйте небольшой обезличенный regression batch и сравнивайте формы, loss, конечность значений и допустимое численное отклонение.
Критерии приёмки
- Версии Flax, JAX и jaxlib записаны в отчёте.
- Формы входа, параметров и результата совпадают с контрактом.
- Все численные outputs и gradients конечны.
- Train/eval режим задан явно для стохастических и stateful слоёв.
- Результат проверен независимой формулой, состоянием или контрольным вызовом.
- Негативный случай неверной формы или режима включён в тесты проекта.
Регрессионный протокол
Сохраните минимальные входы: один объект, небольшой batch, нулевые значения, несимметричные размеры осей и заведомо несовместимую форму. Сравнивайте массивы через allclose с документированным допуском. Воспроизводимость требует одинаковых seeds и одинакового порядка запросов RNG. Производительность оценивайте после JIT-прогрева и block_until_ready, отдельно от compile time. Один удачный запуск не заменяет validation на независимых данных.
Диагностика расхождений
При расхождении сначала проверьте layout и preprocessing, затем RNG streams, train/eval mode, типы переменных State, forward, loss и optimizer update. Упростите модель до одного слоя, отключите JIT и стохастику, сравните промежуточные shapes. Возвращайте компоненты по одной. Не увеличивайте допуск и не заменяйте NaN нулями до установления причины.
Контроль после внедрения
В эксплуатации ограничьте допустимые shapes и размер batch, чтобы запрос не исчерпал память и не вызвал поток перекомпиляций. Не логируйте исходные пользовательские тензоры, ключи и содержимое обучающих примеров. Храните предыдущий проверенный checkpoint и схему State для отката. После восстановления проверяйте контрольный forward до включения модели в трафик.
Границы применимости
CPU-проверка не доказывает скорость или точную численную идентичность GPU/TPU. Случайная инициализация не является обучением, снижение train loss не гарантирует обобщение, а правильная форма не подтверждает корректность данных. Для важных решений нужны validation/test, мониторинг дрейфа, ограничения входов и человеческий контроль.
Типичные ошибки и чего не делать
- Не ожидать, что повторный вызов потока вернёт тот же key.
- Не считать одинаковый seed достаточным при разном порядке запросов.
- Не использовать поток параметров для всех стохастических операций без явного решения.
Не публикуйте только удачный вывод без версии среды, форм и негативного теста. Не настраивайте модель по test set и не загружайте непроверенное состояние поверх production-модели.
FAQ
Почему ключ меняется?
Счётчик потока увеличивается при каждом запросе.
Воспроизводима ли последовательность?
Да, при тех же seeds и порядке запросов.
Зачем разные потоки?
Чтобы разделить логические источники случайности, например params и dropout.
Официальные источники
Частые вопросы
Почему ключ меняется?
Счётчик потока увеличивается при каждом запросе.
Воспроизводима ли последовательность?
Да, при тех же seeds и порядке запросов.
Зачем разные потоки?
Чтобы разделить логические источники случайности, например params и dropout.
Читайте также
Как накопить средний loss через Flax NNX metrics.Average
Flax 0.12.10: Average учитывает каждый элемент двух batch, compute возвращает общий mean, reset очищает состояние.
Как нормализовать каналы через Flax NNX GroupNorm
Flax 0.12.10: GroupNorm для NHWC, четыре канала и две группы, проверка статистик без зависимости от batch.
Как нормализовать каждый канал через Flax NNX InstanceNorm
Flax 0.12.10: InstanceNorm для NHWC нормирует пространственные значения каждого канала и каждого изображения отдельно.
Комментарии
Пока тихо. Скажите первое слово