Модель, которая не смогла остановиться...

Qwen/Qwen3.5-122B-A10B-FP8, vLLM, temperature=0

Небольшая вводная: есть набор задач, есть входные данные и промпт из них для модели. И модель начинает уходить в бесконечную генерацию на, казалось бы, обычных входных данных

Начали ковырять вход, проблема все воспроизводилась и воспроизводилась, пока случайно не заметили, что дело оказалось в переданном хеше в промпте, который нужно было использовать модели в своем ответе

Да, 2dac9f524a8996e8b5638ac7c29fb89358c311d4 с нулевой температурой приводил модель в ужас и не давал выйти из цикла генерации ответа

Обрезка хеша до фиксированной длины 2dac9f52 исправила ситуацию, проблема решена, можно дальше работать, но интерес почему так произошло не давал покоя

Полезли в токенизатор модели, а у нас тут
- 2dac9f524a8996e8b5638ac7c29fb89358c311d4 -> 2 | dac | 9 | f | 5 | 2 | 4 | a | 8 | 9 | 9 | 6 | e | 8 | b | 5 | 6 | 3 | 8 | ac | 7 | c | 2 | 9 | fb | 9 | 9 | 3 | 5 | 8 | c | 3 | 1 | 1 | d | 4 — 36 токенов
- 2dac9f52 -> 2 | dac | 9 | f | 5 | 2 — 6 токенов

И вот модель начинает генерировать хеш посимвольно — токен за токеном. При temperature=0 (greedy decoding) модель на каждом шаге выбирает самый вероятный следующий токен. Проблема в том, что у таких повторений есть эффект самоподкрепления: чем больше hex-символов уже сгенерировано в контексте, тем выше вероятность, что модель продолжит генерировать еще один hex-символ вместо того, чтобы остановиться. Контекст заполняется однотипными токенами [0-9a-f], и модель буквально не может из этого выбраться — greedy decoding не дает ей шанса случайно выбрать стоп-токен, потому что он каждый раз оказывается чуть менее вероятным, чем очередной hex-символ. Отдельно интересно, что это хорошо согласуется с наблюдениями из литературы

Поэтому решается это проблема и при помощи возвращения модели к дефолт параметрам (temperature > 0)

PS: в комментах для вас подготовили пару скриншотов