# Liquid выпускает LFM2.5-24B-A2B: расширение tokenizer и проверка миграции Изменение tokenizer LFM2.5-24B-A2B делает идентичность входа частью миграции: прежний текст не обязательно сохраняет последовательность токенов и её бюджет. Автор: Редакция Retrivium Language: ru Разбор опубликован: 2026-11-03 Дата события: 2026-10-13 Первоисточник новости: https://www.liquid.ai/blog/lfm2-5-24b-a2b Канонический URL: https://retrivium.ai/ru/retrospectives/retro-liquid-24b-tokenizer-contract/ Изменение tokenizer LFM2.5-24B-A2B делает идентичность входа частью миграции: прежний текст не обязательно сохраняет последовательность токенов и её бюджет. ## Различие уровня релиза [Анонс](https://www.liquid.ai/blog/lfm2-5-24b-a2b) описывает расширенный tokenizer вместе с выпуском модели. Это не только упаковка. Tokenizer определяет преобразование видимого входа в обрабатываемую последовательность, поэтому новая карта меняет предположения приложения при тех же символах. Если промежуточное представление сохранено отдельно, его связь с определённой версией преобразователя становится необходимой частью правильной интерпретации, а не необязательной подробностью эксперимента. ## Предыдущие предположения семейства Более ранние [гибридный релиз](https://www.liquid.ai/blog/lfm2-5-8b-a1b) и [компактный релиз](https://www.liquid.ai/blog/lfm2-5-230m) дают предыдущий контекст. Они не устанавливают тождество токенов позднейшей модели. Сохранение старого tokenizer из-за знакомого имени семейства создаёт внутренне несогласованный входной конвейер. При этом сам запрос может выглядеть совершенно правильным в пользовательском интерфейсе, потому что ошибка возникает после отображения текста, на этапе подготовки вычислительного представления. Поэтому сравнение имеет два уровня: понятную человеку задачу и её кодирование. Неизменность одного не доказывает неизменность другого. Это важно при хранении количества токенов или заранее закодированных данных как постоянного свойства текста. Подобные сведения относятся к сочетанию текста и преобразователя; потеря второй части делает старые записи ненадёжным основанием для новых ограничений входа и расчёта его размера. ## Многоязычный контрольный пример Представим хранилище документов на нескольких языках с размерами входа от прежнего tokenizer. После миграции документы не изменились, но записанные бюджеты больше не обязательно описывают вход новой модели. Обрезка по старым отметкам удалит неверный объём свидетельств. Ошибка станет видна как ухудшение ответа по документу, хотя первопричина находится в переносе устаревшей метрики предварительной обработки. Представление нужно пересчитать для нового артефакта, а не незаметно применять прежние идентификаторы. Исходный текст сохраняют для проверки миграции. Кеш токенов полезен, только пока с ним связана идентичность tokenizer. Если эта связь потеряна, нельзя уверенно определить, какие данные действительно получила модель, даже при наличии полного списка численных идентификаторов из старого запуска или промежуточного сохранённого файла. ## Шаблоны и границы Видимое содержание составляет лишь часть запроса. Внешний шаблон и обработка специальных токенов тоже меняют кодирование. Поэтому повтор прежней строки с другой оболочкой меняет эффективный вход ещё до генерации. Такой эффект не доказывает изменение способности модели решать задачу: сначала нужно установить, что сама задача была представлена совместимым и ожидаемым для выбранных весов способом. Контрольный пример сохраняет видимый разговор и применённое представление. При неожиданном ответе запись отделит изменение качества от несоответствия предварительной обработки. Без неё ошибка интеграции tokenizer выглядит общей регрессией релиза. Сохранённое основание позволяет локализовать причину и не приписывать модели проблему, возникшую в программе, которая подготовила для неё последовательность из исходного пользовательского текста и служебной структуры запроса. ## Исторический урок Изменение tokenizer напоминает о включении предварительной обработки в идентичность модели. Преемственность архитектуры не отменяет согласования весов, tokenizer и оформления запроса как совместимого набора. Для ретроспективы это конкретное отличие миграции, а не повод объявлять любой старый клиент непригодным: проверять следует именно те предположения, которые связаны с кодированием и его использованием в приложении. Вывод состоит в версионировании закодированных предположений вместе с исходным артефактом. Текст остаётся прежним при изменении идентификаторов и бюджета токенов. Надёжная миграция учитывает различие до повторного использования кешей, ограничений и исторических сравнений другого представления. Тогда наблюдаемое поведение можно связать с реальным входом модели, а не только с внешне одинаковым текстом пользовательского запроса. Дополнительный разбор: [Воспроизводимый стек инференса: как сохранить результат GPU-пилота](/ru/journal/software-stack-reproducibility/); [GPU-хостинг для мультимодальных моделей: считайте не только текст](/ru/journal/multimodal-gpu-hosting/).