ainews
Как я архитектировал SDAR на AWS и почему сознательно не запускал бенчмарки
Автор подробно разобрал алгоритм Self-Distilled Agentic Reinforcement Learning (SDAR) из свежей статьи, спроектировал полную архитектуру на AWS с расчётом инфраструктуры, но сознательно не стал арендовать GPU для бенчмарков. Вместо этого он честно объясняет цепочку инженерных решений: почему нужны четыре копии модели, как считать память под них, где sigmoid-гейт может дать NaN — и почему объяснение механизма важнее фейковой кривой сходимости.
Инженерам, которые хотят реализовывать сложные RL/дистилляционные схемы в продакшене: это редкий пример честного разбора всей цепочки решений — от выбора инстансов до граничных условий в коде. Вместо туториала с фейковыми графиками — инженерный decision log с обоснованиями.
Это аннотация к авторской статье. Мы не публикуем и не пересказываем чужие тексты целиком — полная версия у автора.
О чём статья
- SDAR решает проблему credit assignment в многошаговых агентах через взвешенную дистилляцию: положительные сигналы от учителя берутся с большим весом, отрицательные — с малым, т.к. отказ учителя часто шум, а не истина
- Когда в цикле обучения четыре резидентные модели (actor, reference, rollout, teacher), управляемый fine-tuning AWS Bedrock перестаёт быть опцией — приходится вручную выбирать GPU-инстансы (p4d/p5) и считать HBM-память
- SDAR потребляет на 30–40% больше памяти, чем GRPO той же размерности (из-за длинного KV-кэша учителя); для 7B-модели нужны все восемь 80GB-карт на одном узле
- Отладка гейта на полномасштабной модели нецелесообразна — автор предлагает прототипировать на малых размерах (1.5B–3B с LoRA), где цикл занимает минуты, а не часы
Комментарии