Комментарии 22
>ризонинговая
А точно русскоязычная-то?
Выглядит как "якобы технический" маркетинговый текст, через термины и тезисы которого невозможно прорваться
Для меня "прорыв" в моделях случился, когда Гемини сразу смогла объяснить, в чём тут цимес:
как у коня сказала зоя
олег зарделся ну а то
и принялся с любовью гладить
пальто
Жду следующего "прорыва" — у "домашних" моделей :)
Ваша (T-pro-it-2.0-GGUF:Q8_0) пока "не решилась":
Ещё вариант: "Как у коня сказала Зоя" — возможно, Зоя сказала "Как у коня хвост — длинный и тонкий", а потом Олег, смутившись, начал гладить пальто, потому что "хвост" и "пальто" звучат похоже? Но "хвост" и "пальто" — не рифма, но возможно ассоциация.
Если я правильно понимаю, это зависит от объёма данных, на которых модеть натаскивали. Конечно, говорим "Гугл" — подразумеваем "данные", но вот интересно, дойдут ли до такого уровня локальные модели?.. Или для юмора, особенно нижнепоясного, нужны триллионы параметров?
Как запустить эту модель с контекстом 128К?
Достаточно ли просто в параметрах llama.cpp написать этот параметр или надо каким-то образом активировать RoPE scaling?
Интересно было прочесть чей то опыт! Спасибо за статью! Глядя как развиваются модели ИИ, предполагаю что столкнемся ещё и с запретами использования тех или иных моделей ))
T-Pro 2.0 — это не "прорывная русскоязычная LLM", а форк Qwen с русским тюнингом, раздутый маркетингом.Факты на лицо:слабая оригинальность, зависимость от чужих моделей и сомнительные метрики делают ее посредственной. Если Т-Банк хочет впечатлить, пусть покажут реальные кейсы без хайпа — иначе это просто шум в экосистеме LLM.
Протестировал модель T-Pro 2.0 в квантованной GGUF-версии на 23 Гб и столкнулся с серьёзными проблемами:
Потеря контекста: Модель не удерживает тему. На вопрос «Чем похожи карандаш и ботинок» (без знака вопроса) она начала генерировать похожие по структуре, но другие вопросы («Чем похожи замок и ключ?»), так и не дав ответа.
Галлюцинации и зацикливание: На более сложном вопросе по истории физики модель полностью «сломалась». Она ушла в 20-минутную генерацию несвязанного текста в виде чата редакторов Википедии, пока я не остановил её вручную. Даже простое «привет» на старте вызвало поток несвязного текста.
Похоже, у данной версии есть фундаментальные проблемы с удержанием контекста, что приводит к бесконтрольной генерации нерелевантного контента.
Привет, спасибо за фидбэк. Подскажи, пожалуйста, точное название кванта, который ты использовал и какие были параметры генерации?
Неквантованная модель на 1-ый вопрос отвечает нормально (для таких простых запросов /no_think режим может вести себя даже лучше чем /think), вторая проблема скорее всего лечится более высокой температурой и presence_penalty
Мы перепроверим поведение различных квантов
Я взял модель T-pro-it-2.0-Q5_K_M.gguf. Для быстроты тестирования я использую свой проект https://github.com/HardAndHeavy/ollama-open-webui, его клонирую и набираю make run-cuda, а затем make seed-t-pro. Дальше я просто в интерфейсе Open WebUI добавил системный промт на всякий случай, как это я делаю для других моделей: «Ты рассудительный и честный собеседник, который разговаривает на русском языке». И всё. Больше ничего не настраивал.
Скорее всего, в этом случае используется temperature 0, что может приводить к зацикливаниям. Мы загрузили кванты в ollama напрямую https://ollama.com/t-tech/T-pro-it-2.0, в ней мы задали дефолтную температуру 0.6, можно использовать их.
Спасибо большое за комментарий. Протестировал загруженную в Ollama t-tech/T-pro-it-2.0:q4_K_M в сравнении с qwen3:32b. Всё на уровне, моё вам уважение. Мнение по вашей модели кардинально изменил. Это здорово, что вы такое делаете! Спасибо вам.
Единственное, начал пробовать подобрать температуру для T-pro-it-2.0-Q5_K_M.gguf. На 0.6 получше отвечать стала, но всё равно бред. Попробовал поменять ещё температуру, и у меня сломался жёсткий диск. На этом я эксперимент закончил... Но самый важный вывод я сделал — всё на уровне qwen3!
В статье утверждается, что несмотря на отрицательную производительность (~2% деградации), бессмертные объекты были внедрены в CPython из-за их значимости для архитектуры субинтерпретаторов и free-threading. Однако, если учесть потенциальные проблемы, такие как «accidental immortality» и особенно «accidental de-immortalizing» при использовании стабильного ABI, не считаете ли вы, что текущая реализация бессмертности недостаточно безопасна без строгой валидации сторонних C‑расширений и потенциально требует дополнительных механизмов обнаружения таких сценариев на этапе исполнения (например, через runtime-валидатор счетчика ссылок)? Планируется ли развитие в эту сторону, в частности, в связи с обсуждаемым PEP 797?
Скорей всего вы хотели ответить в моей статье про бессмертные объектоы, но почему-то написали здесь. Предлагаю продолжить там, если что.
Мне не понятно, что вы имеете в виду под "runtime-валидатор" - предлагаю вам раскрыть свой вопрос там.
Спасибо за ответ и извините за путаницу! Действительно, комментарий был адресован вашей статье про бессмертные объекты (T-Pro 2.0 — открытая гибридно-ризонинговая русскоязычная LLM), но я по ошибке оставил его не там.
По поводу runtime-валидатора: Я имел в виду механизм, который мог бы во время выполнения программы (runtime) отслеживать потенциально опасные операции с бессмертными объектами, особенно те, что могут привести к их "случайному разбессмерчиванию" (accidental de-immortalizing). Например:
Детектирование
Py_DECREFна бессмертных объектах: Это самая критичная операция, которая может сломать инвариант бессмертности. Валидатор мог бы перехватывать такие вызовы (через отладочные хуки, санитайзеры, или специализированный режим сборки) и выдавать предупреждение/ошибку, лог или даже крешнуть интерпретатор в отладочном режиме.Контроль целостности счетчиков ссылок: Проверять, что счетчик ссылок бессмертного объекта действительно имеет "магическое" значение (например,
PyIMMORTAL_REFCNT), а не был случайно изменен.Анализ операций через Stable ABI: Особый фокус на операциях, выполняемых через Stable ABI, где риск "accidental de-immortalizing" выше из-за непрямого доступа к внутренностям CPython.
Цель такого валидатора — не замена строгому аудиту кода расширений, а предоставление дополнительного инструмента для:
Отладки: Помощь разработчикам расширений в выявлении скрытых багов при миграции на Python с бессмертностью.
Тестирования: Включение в CI/CD пайплайны для проверки совместимости расширений.
Проактивного обнаружения проблем: Выявление потенциально небезопасных паттернов использования до того, как они приведут к трудноотлавливаемым сбоям в продакшене.
Связь с PEP 797 (Python Runtime Audit Hooks): Именно этот PEP показался мне идеальной платформой для реализации такого мониторинга! Audit hooks предоставляют механизм для подписки на события внутри интерпретатора. Можно было бы ввести новые события типа:
"object.deimmortalize_attempt"(с аргументами: объект, источник вызова - расширение/модуль)"immortal_refcnt_mismatch"
Тогда внешний "валидатор" (отдельный инструмент или встроенный отладочный режим) мог бы подписываться на эти события и реагировать соответствующим образом (логировать, алертить, крешнуть).
Потестил Q5_K_M:
Мой тест "на какой реке находится Йошкар-Ола" так и не проходит :) YandexGPT проходит.
Частенько игнорирует /no_think токен и рандомно может переключаться в reasoning (после чего уже не выходит из reasoning) <= самый серьёзный баг и хз как его решить. Видимо файн-тюнинг сломал гибридный вывод.
Тест на API вроде прошло, не поломано (tool calls).
"Расскажи длинную историю" (в среднем) T-pro: 19.3 сек Qwen3: 23 сек Побыстрее, но не сильно существенно, конечно.
В тесте "расскажи длинную историю" ChatGPT o3 больше понравилась IT-pro
IT-pro ещё любит слишком много текста жирным шрифтом делать (ну прям каждое четвёртое слово), а Qwen3 этим не страдает.
Судя по всему, тренировали на выводах от ChatGPT, т.к. теперь иногда говорит, что она ChatGPT, а не Qwen3. Ванильная Qwen3 так у меня не делала.
Из-за бага с рандомным переходом в reasoning пока не могу взять на вооружение :(
Ещё заметил, что T-pro любит побольше болтать. Т.е. допустим если на краткий ответ типа "спасибо" Qwen3 тоже кратко ответит типа "я здесь, чтобы помочь, обращайся!", то T-pro может неожиданно ещё 10 параграфов нагенерировать, переформулируя то, что уже было до этого сказано.
С perplexity что-то не то: Qwen3-32B-UD-Q4_K_XL на русском тексте даёт ~4.5, а T-pro-it-2.0-Q5_K_M даёт аж ~9 (через llama-perplexity). Или у Unsloth намного лучше кванты, или в модели оно само по себе ухудшилось.
T-Pro 2.0 — открытая гибридно-ризонинговая русскоязычная LLM