Forwarded from Data Secrets
Learning without training: разбираем новую крайне интересную статью от Google
Смотрите, все мы знаем, что если модели в промпте показать несколько примеров решения похожих задач, то она может легко подхватить паттерн, и качество ответов станет лучше. При этом веса модели, естественно, не меняются.
Это называется in‑context learning (ICL), но вот вам fun fact: никто до сих пор до конца не знает, почему это работает, и как трансформер это делает.
И вот в этой статье авторы предлагают почти революционную гипотезу – что на самом деле веса меняются, просто иначе, чем мы привыкли.
То есть на самом деле внутри блока трансформера происходит нечто похожее на файнтюнинг, только не через градиенты, а за счёт самой механики self‑attention и MLP. Идея сводится к следующему:
1. Контекст порождает локальные изменения активаций, и когда вы добавляете примеры в промпт, self‑attention пересчитывает эмбеддинги токенов так, что после этого они зависят от всего контекста. Разницу между «чистыми» активациями и активациями с учётом примеров можно назвать контекстным сдвигом. Это все известные вещи.
2. А вот дальше зарыта собака: оказывается, MLP превращает этот контекстный сдвиг в ранг‑1 обновление весов. Иначе говоря, если посмотреть на первый линейный слой MLP (матрицу W), то влияние дополнительных примеров эквивалентно тому, что эту самую матрицу дополняют маленькой поправкой ранга 1.
Причем эта поправка описывается достаточно простой формулой. То есть если мы берем оригинальные веса и вручную добавляем к ним эту поправку, модель без контекста выдаст то же самое, что и оригинал с контекстом. Но всё это происходит во время инференса, без обратного прохода и без изменения глобальных моделей параметров.
Получается, Google буквально дают ключ к возможному обучению без градиентного спуска. Если такие ранг‑1 апдейты научиться усиливать или контролировать, это может быть началом абсолютно новых архитектур.
Почитать полностью можно тут -> arxiv.org/abs/2507.16003 (осторожно, много математики)
Смотрите, все мы знаем, что если модели в промпте показать несколько примеров решения похожих задач, то она может легко подхватить паттерн, и качество ответов станет лучше. При этом веса модели, естественно, не меняются.
Это называется in‑context learning (ICL), но вот вам fun fact: никто до сих пор до конца не знает, почему это работает, и как трансформер это делает.
И вот в этой статье авторы предлагают почти революционную гипотезу – что на самом деле веса меняются, просто иначе, чем мы привыкли.
То есть на самом деле внутри блока трансформера происходит нечто похожее на файнтюнинг, только не через градиенты, а за счёт самой механики self‑attention и MLP. Идея сводится к следующему:
1. Контекст порождает локальные изменения активаций, и когда вы добавляете примеры в промпт, self‑attention пересчитывает эмбеддинги токенов так, что после этого они зависят от всего контекста. Разницу между «чистыми» активациями и активациями с учётом примеров можно назвать контекстным сдвигом. Это все известные вещи.
2. А вот дальше зарыта собака: оказывается, MLP превращает этот контекстный сдвиг в ранг‑1 обновление весов. Иначе говоря, если посмотреть на первый линейный слой MLP (матрицу W), то влияние дополнительных примеров эквивалентно тому, что эту самую матрицу дополняют маленькой поправкой ранга 1.
Причем эта поправка описывается достаточно простой формулой. То есть если мы берем оригинальные веса и вручную добавляем к ним эту поправку, модель без контекста выдаст то же самое, что и оригинал с контекстом. Но всё это происходит во время инференса, без обратного прохода и без изменения глобальных моделей параметров.
Получается, Google буквально дают ключ к возможному обучению без градиентного спуска. Если такие ранг‑1 апдейты научиться усиливать или контролировать, это может быть началом абсолютно новых архитектур.
Почитать полностью можно тут -> arxiv.org/abs/2507.16003 (осторожно, много математики)
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
#собесы #BaseLLM
За последний год прошел много собеседований и удивился, что на русском языке нет(или почти нет) методичек LLM Q&A собеседований на русском. В каждом из тем(пока планируется 15), я постараюсь понятным языком ответить на вопросы, а затем составить общую методичку LLM собеседований.
В чем разница между предиктивным(Predictive) и генеративным(Generative) ИИ?
В предиктивном мы не создаем новые данные, а делает предсказания или классификации по существующим входным данным. То есть учится границам между классами(LogReg, RF, Catboost).
В генеративном мы генерируем новые данные на основе распределения(LLM, GAN, Stable Diffusion).
Что такое LLM и как она тренируется?
Large Language Model - продвинутая вычислительная модель, способная анализировать и генерировать тексты на любую тематику. Она работает по принципу нейронных сетей и может образовывать сложные шаблоны и взаимосвязи между изученными языковыми данными.
Примеры: GPT, Gemini, Claude
В классическом понимании у LLM есть несколько стадий обучения:
1️⃣ Pre-training, для понимания того, как работает язык
2️⃣ Fine-tuning, для обучения на определенной задаче или домене
3️⃣ Prompt-tuning, использование инструкций и подсказок для лучших ответов модели
4️⃣ Reinforcement learning with human feedback(RLHF), после получения ответов, человек их оценивает и меняет параметры LLM.
Что такое токен в языковой модели?
Токен - минимальная единица текста, с которой работает языковая модель. В LLM это обычно части слов, слова и знаки, зависящие от алгоритма токенизации.
Как рассчитать стоимость пользования готового сервиса LLM(GPT, Deepseek) и open-source решения(LLAMA, Qwen)?
В первом случае все зависит от количества входных и выходных токенов: примерно 0.03 доллара за 1К входных и 0.06 за 1К выходных. При этом стоимость может меняться от сложность модели. Общая формула будет примерно такой:
Все остальные затраты будут на стороне провайдера. В наших реалиях придется платить за прокси, но это буквально 250-300 рублей в месяц.
Для развертывания своей модели придется платить за ресурсы, devops поддержку, хранение информации и энергопотребление. Общая формула:
В целом, использование SaaS намного более удобный, чем локальная LLM, использовать второй случай нужно лишь когда нам нужен полный контроль над моделью и данными.
Что такое температура и на что она влияет?
Температура - это гиперпараметр генерации текста, который контролирует степень случайности (креативности) в выборе следующего токена.
Модель вычисляет вероятности токенов
- Если T < 1, распределение становится резче (концентрируется на top токенах).
- Если T > 1, распределение становится более равномерным (выбор менее вероятных токенов возрастает)
Нравится ли вам такой формат?) Разбирать ли более сложные вопросы или сначала базу?) Какие еще темы вы хотели бы разобрать?) Обязательно ставьте реакции и пишите комментарии💗
За последний год прошел много собеседований и удивился, что на русском языке нет(или почти нет) методичек LLM Q&A собеседований на русском. В каждом из тем(пока планируется 15), я постараюсь понятным языком ответить на вопросы, а затем составить общую методичку LLM собеседований.
В чем разница между предиктивным(Predictive) и генеративным(Generative) ИИ?
В предиктивном мы не создаем новые данные, а делает предсказания или классификации по существующим входным данным. То есть учится границам между классами(LogReg, RF, Catboost).
В генеративном мы генерируем новые данные на основе распределения(LLM, GAN, Stable Diffusion).
Что такое LLM и как она тренируется?
Large Language Model - продвинутая вычислительная модель, способная анализировать и генерировать тексты на любую тематику. Она работает по принципу нейронных сетей и может образовывать сложные шаблоны и взаимосвязи между изученными языковыми данными.
Примеры: GPT, Gemini, Claude
В классическом понимании у LLM есть несколько стадий обучения:
Что такое токен в языковой модели?
Токен - минимальная единица текста, с которой работает языковая модель. В LLM это обычно части слов, слова и знаки, зависящие от алгоритма токенизации.
Как рассчитать стоимость пользования готового сервиса LLM(GPT, Deepseek) и open-source решения(LLAMA, Qwen)?
В первом случае все зависит от количества входных и выходных токенов: примерно 0.03 доллара за 1К входных и 0.06 за 1К выходных. При этом стоимость может меняться от сложность модели. Общая формула будет примерно такой:
Общая стоимость = (число prompt токенов * цена за 1K prompt токенов / 1000) + (число completion токенов * цена за 1K completion токенов / 1000)
Все остальные затраты будут на стороне провайдера. В наших реалиях придется платить за прокси, но это буквально 250-300 рублей в месяц.
Для развертывания своей модели придется платить за ресурсы, devops поддержку, хранение информации и энергопотребление. Общая формула:
Общая стоимость = Стоимость GPU (аренда или амортизация) + Стоимость CPU RAM Storage + DevOps зарплата + Сопутствующие расходы (электричество, сеть)
В целом, использование SaaS намного более удобный, чем локальная LLM, использовать второй случай нужно лишь когда нам нужен полный контроль над моделью и данными.
Что такое температура и на что она влияет?
Температура - это гиперпараметр генерации текста, который контролирует степень случайности (креативности) в выборе следующего токена.
Модель вычисляет вероятности токенов
p_i. При температуре T:
p_i_new ∝ exp(log(p_i) / T)
- Если T < 1, распределение становится резче (концентрируется на top токенах).
- Если T > 1, распределение становится более равномерным (выбор менее вероятных токенов возрастает)
Нравится ли вам такой формат?) Разбирать ли более сложные вопросы или сначала базу?) Какие еще темы вы хотели бы разобрать?) Обязательно ставьте реакции и пишите комментарии
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from дAI потестить!
Media is too big
VIEW IN TELEGRAM
Меняем фон на видео - параллельно отапливаем жилище теплом от видеокарты.
P.S. Все еще Wan2GP и Pinokkio
P.S. Все еще Wan2GP и Pinokkio
Forwarded from Душный NLP
В Вене проходит 63-я ежегодная конференция ассоциации компьютерной лингвистики — ACL 2025
А мы как всегда следим 👀 и делимся с вами самым интересным. Мы уже публиковали занимательную статистику c конференции в канале ML Underhood (кстати, подписывайтесь!), а теперь настало время поговорить о статьях.
Конференцию открыл часовой кейноут Люка Зеттлемойера, профессора Paul G. Allen School of Computer Science & Engineering в Университете Вашингтона, старшего научного руководителя Meta* и президента ACL. Он рассказал о том, как стандартный пайплайн обучения LLM: токенизация, претрейн и элаймент, несмотря на невероятный успех, почти наверняка имеет множество возможностей улучшения, которые мы упускаем. Доклад был построен вокруг трех векторов исследования:
— повышения эффективности обработки данных после обучения;
— новых методов извлечения большего количества сигналов из данных претрейна, включая новые иерархические архитектуры для языковых моделей байтового уровня (BLT), которые не требуют использования токенизаторов и масштабируются лучше, чем традиционные методы на основе BPE;
— одного из подходов к MoE — FlexOLMo.
Все три темы были интересными! А вот ещё н несколько докладов, которые отметили яндексоиды:
Human-LLM Coevolution: Evidence from Academic Writing
Довольно ожидаемо авторы утверждают, что с появлением Chat GPT частотность употребления некоторых слов в научных статьях резко изменилась. Затем исследователи делают ещё один шажок и говорят, что это не обязательно означает, что LLM пишут статьи. Скорее мы наблюдаем, как люди, много взаимодействующие с LLM, оказываются под их влиянием и изменяют свои паттерны словоупотребления.
From Words to Worlds: NLP for Game Creation and Interaction
Индустриальный рассказ об Epic Games об использовании LLM для NPC в играх. Пользователь, играя, может задать произвольный вопрос и персонаж будет отвечать (естественно, со своим характером и т. п.). Это выглядит здорово и меняет опыт взаимодействия с игровым миром. Решение внедрили в Fortnite пару месяцев назад, она работает поверх чужих API и позволяет поговорить с Дартом Вейдером. Также они делают свой code completion и анимацию персонажей с помощью AI.
Understanding Impact of Human Feedback via Influence Functions
Исследователи оценили влияние фидбека человека, введя понятие функции влияния, и пришли к выводам, что это влияние превосходит показатели базовой LLM. Ещё более сильным негативным влиянием обладает ошибочный фидбек. Авторы разработали подход, который позволяет это детектировать и, следовательно, убирать или исправлять.
* Компания Meta признана экстремистской организацией в России.
Наблюдениями делились❣ Алексей Березникер и Александр Николайчик
#YaACL25
Душный NLP
А мы как всегда следим 👀 и делимся с вами самым интересным. Мы уже публиковали занимательную статистику c конференции в канале ML Underhood (кстати, подписывайтесь!), а теперь настало время поговорить о статьях.
Конференцию открыл часовой кейноут Люка Зеттлемойера, профессора Paul G. Allen School of Computer Science & Engineering в Университете Вашингтона, старшего научного руководителя Meta* и президента ACL. Он рассказал о том, как стандартный пайплайн обучения LLM: токенизация, претрейн и элаймент, несмотря на невероятный успех, почти наверняка имеет множество возможностей улучшения, которые мы упускаем. Доклад был построен вокруг трех векторов исследования:
— повышения эффективности обработки данных после обучения;
— новых методов извлечения большего количества сигналов из данных претрейна, включая новые иерархические архитектуры для языковых моделей байтового уровня (BLT), которые не требуют использования токенизаторов и масштабируются лучше, чем традиционные методы на основе BPE;
— одного из подходов к MoE — FlexOLMo.
Все три темы были интересными! А вот ещё н несколько докладов, которые отметили яндексоиды:
Human-LLM Coevolution: Evidence from Academic Writing
Довольно ожидаемо авторы утверждают, что с появлением Chat GPT частотность употребления некоторых слов в научных статьях резко изменилась. Затем исследователи делают ещё один шажок и говорят, что это не обязательно означает, что LLM пишут статьи. Скорее мы наблюдаем, как люди, много взаимодействующие с LLM, оказываются под их влиянием и изменяют свои паттерны словоупотребления.
From Words to Worlds: NLP for Game Creation and Interaction
Индустриальный рассказ об Epic Games об использовании LLM для NPC в играх. Пользователь, играя, может задать произвольный вопрос и персонаж будет отвечать (естественно, со своим характером и т. п.). Это выглядит здорово и меняет опыт взаимодействия с игровым миром. Решение внедрили в Fortnite пару месяцев назад, она работает поверх чужих API и позволяет поговорить с Дартом Вейдером. Также они делают свой code completion и анимацию персонажей с помощью AI.
Understanding Impact of Human Feedback via Influence Functions
Исследователи оценили влияние фидбека человека, введя понятие функции влияния, и пришли к выводам, что это влияние превосходит показатели базовой LLM. Ещё более сильным негативным влиянием обладает ошибочный фидбек. Авторы разработали подход, который позволяет это детектировать и, следовательно, убирать или исправлять.
* Компания Meta признана экстремистской организацией в России.
Наблюдениями делились
#YaACL25
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from BOGDANISSSIMO
При разработке приложения я нахожу удобным визуализировать карту приложения, которая является одновременно и todo-листом (буквально):
колонки - фичи, примерно в порядке онбординга / user journey / логики экранов в меню внизу
строки - слои приложения, от того что пользователь видит (UI), логики (UX) - и до сети, бекенда, LLM штук
Будучи фуллстеком, мне удобнее не закапываться в отдельные части, а работать вертикально, *вдоль*. Взял какую-то фичу, и прогрызаешь всю её имплементацию (часто начинаю с того, что видит пользователь, с UI и потом UX)
Мне лично так сразу понятно, что сделано, что от чего зависит, куда дальше продвинуть экспансию "области того, что уже сделано", какой следующий самый важный кусок приложения
Намного легче ориентироваться в приоритетах и объеме работы, чем безликие текстовые буллеты в каком-либо таск-трекере. В принципе, фреймворк подходит и для любых web-сервисов
А как вы декомпозируете новые проекты?
колонки - фичи, примерно в порядке онбординга / user journey / логики экранов в меню внизу
строки - слои приложения, от того что пользователь видит (UI), логики (UX) - и до сети, бекенда, LLM штук
Будучи фуллстеком, мне удобнее не закапываться в отдельные части, а работать вертикально, *вдоль*. Взял какую-то фичу, и прогрызаешь всю её имплементацию (часто начинаю с того, что видит пользователь, с UI и потом UX)
Мне лично так сразу понятно, что сделано, что от чего зависит, куда дальше продвинуть экспансию "области того, что уже сделано", какой следующий самый важный кусок приложения
Намного легче ориентироваться в приоритетах и объеме работы, чем безликие текстовые буллеты в каком-либо таск-трекере. В принципе, фреймворк подходит и для любых web-сервисов
А как вы декомпозируете новые проекты?
Forwarded from BOGDANISSSIMO
1/2. Как не терять фокус, когда много проектов?
Буду потихоньку нарезать вебинар на посты
Поступил вопрос "как не терять фокус и не распыляться, если много проектов?". У меня на пике было 4 проекта (основная работа, книга, 2 курса). Сейчас у меня проектов, требующих моего внимания тоже больше одного (мы не берём в расчёт консультации). Чтобы за всем успевать, я тогда и сейчас распределяю проекты по дням недели, кажется, это называется Day Theming.
Идея в чём: когда ты Maker, т.е. работаешь руками (разработчик, дизайнер, контент-creator), ты продуктивен, когда у тебя есть большое количество часов (4-6 подряд или больше), во время которых ты можешь заниматься одной задачей, погрузиться в нирвану Deep Work✨. Тебе важно не отвлекаться, иметь один контекст. Тебе клёво видеть в календаре пустой день или половину дня – ты можешь заняться своим делом и сделать его хорошо
Когда ты Manager, ты по-другому смотришь на свой календарь. Тебе ок созваниваться, переключаться между десятью контекстами. Каждые незаполненные полчасика в календаре для тебя впустую потраченное время. Для Maker наоборот, свободные полчаса-час-два – это настолько мало для того, чтобы что-то сделать полезное, что за важные задачи лучше и не браться, максимум, пофиксить баги, почитать статьи
Подробнее про Maker Schedule vs Manager Schedule в знаменитом эссе Пола Грэма, также есть классный видос от Алекса Хормози If You Struggle with Focus, Try My Productivity System с более бизнесовым пересказом Пола Грэма
Я инженер, поэтому мой контрибьюшн – почти всегда через deep work. Мне важно иметь Maker Schedule, когда есть большие куски времени без отвлечений. Если у меня больше одного проекта, которые конкурируют за мое внимание каждый день, каждый час, мне нужно придумать, как предотвратить context switching, переключение контекста
Буду потихоньку нарезать вебинар на посты
Поступил вопрос "как не терять фокус и не распыляться, если много проектов?". У меня на пике было 4 проекта (основная работа, книга, 2 курса). Сейчас у меня проектов, требующих моего внимания тоже больше одного (мы не берём в расчёт консультации). Чтобы за всем успевать, я тогда и сейчас распределяю проекты по дням недели, кажется, это называется Day Theming.
Идея в чём: когда ты Maker, т.е. работаешь руками (разработчик, дизайнер, контент-creator), ты продуктивен, когда у тебя есть большое количество часов (4-6 подряд или больше), во время которых ты можешь заниматься одной задачей, погрузиться в нирвану Deep Work✨. Тебе важно не отвлекаться, иметь один контекст. Тебе клёво видеть в календаре пустой день или половину дня – ты можешь заняться своим делом и сделать его хорошо
Когда ты Manager, ты по-другому смотришь на свой календарь. Тебе ок созваниваться, переключаться между десятью контекстами. Каждые незаполненные полчасика в календаре для тебя впустую потраченное время. Для Maker наоборот, свободные полчаса-час-два – это настолько мало для того, чтобы что-то сделать полезное, что за важные задачи лучше и не браться, максимум, пофиксить баги, почитать статьи
Подробнее про Maker Schedule vs Manager Schedule в знаменитом эссе Пола Грэма, также есть классный видос от Алекса Хормози If You Struggle with Focus, Try My Productivity System с более бизнесовым пересказом Пола Грэма
Я инженер, поэтому мой контрибьюшн – почти всегда через deep work. Мне важно иметь Maker Schedule, когда есть большие куски времени без отвлечений. Если у меня больше одного проекта, которые конкурируют за мое внимание каждый день, каждый час, мне нужно придумать, как предотвратить context switching, переключение контекста
Forwarded from BOGDANISSSIMO
2/2. Как не терять фокус, когда много проектов?
Решение: оба этих вводных приводят нас к логичной идее выделять целые дни под тот или иной контекст, кажется, это называется Day Theming. Я коммуницирую, мол, такие-то дни недели я занимаюсь таким-то проектом, в остальные дни по этому проекту я недоступен (максимум, могу в конце дня посмотреть, прочитать, отписаться). У меня в календарике прям заведены регулярные Full Day ивенты под каждый. Важно что это эксплицитно проговаривается, чтобы контролировать ожидания всех, с кем работаешь (например, мои последние начальники и кого я консультирую подтвердят, что все созвоны я ставлю на понедельники, чтобы все остальные дни я мог фокусироваться на deep work)
Если, когда я не занят каким-то проектом что-то ломается, случается какой-то пожар – это подождёт как минимум до конца дня, как максимум, несколько дней, пока я не вернусь обратно к этому проекту (чаще всего "пожары", если внимательно на них посмотреть, не такие критичные и срочные, какими кажутся на первый взгляд)
В крайнем случае, если это действительно необходимо, можно бить дни на пополам (4-6 часов первая половина дня на один проект, зал/обед, 4-6 часов половина дня на другой проект) или выделять 1-2 часа в начале или в конце дня на какую-то определённую активность (контент/книга/курс)
P.S. Знаю, такой стратегии придерживается Илон у которого 5+ компаний (SpaceX, Tesla, X, xAI, DOGE, Neurolink). Львиная доля времени у него выделена под SpaceX, Tesla, где пока он ими занимается, он прилетает на завод, погружается в текущие дела, находит главный боттлнек прямо сейчас и в считанные дни его решает (крайне советую посмотреть https://www.youtube.com/watch?v=FQ4wBv0w9ew), после чего он переключается на другие компании и не мешает гениальным инженерам продолжать работу
Решение: оба этих вводных приводят нас к логичной идее выделять целые дни под тот или иной контекст, кажется, это называется Day Theming. Я коммуницирую, мол, такие-то дни недели я занимаюсь таким-то проектом, в остальные дни по этому проекту я недоступен (максимум, могу в конце дня посмотреть, прочитать, отписаться). У меня в календарике прям заведены регулярные Full Day ивенты под каждый. Важно что это эксплицитно проговаривается, чтобы контролировать ожидания всех, с кем работаешь (например, мои последние начальники и кого я консультирую подтвердят, что все созвоны я ставлю на понедельники, чтобы все остальные дни я мог фокусироваться на deep work)
Если, когда я не занят каким-то проектом что-то ломается, случается какой-то пожар – это подождёт как минимум до конца дня, как максимум, несколько дней, пока я не вернусь обратно к этому проекту (чаще всего "пожары", если внимательно на них посмотреть, не такие критичные и срочные, какими кажутся на первый взгляд)
В крайнем случае, если это действительно необходимо, можно бить дни на пополам (4-6 часов первая половина дня на один проект, зал/обед, 4-6 часов половина дня на другой проект) или выделять 1-2 часа в начале или в конце дня на какую-то определённую активность (контент/книга/курс)
P.S. Знаю, такой стратегии придерживается Илон у которого 5+ компаний (SpaceX, Tesla, X, xAI, DOGE, Neurolink). Львиная доля времени у него выделена под SpaceX, Tesla, где пока он ими занимается, он прилетает на завод, погружается в текущие дела, находит главный боттлнек прямо сейчас и в считанные дни его решает (крайне советую посмотреть https://www.youtube.com/watch?v=FQ4wBv0w9ew), после чего он переключается на другие компании и не мешает гениальным инженерам продолжать работу
Forwarded from Tensor Banana
T-one STT (распознавание речи на русском) под виндой (без WSL и докера) на CPU
- размер очень маленький - 71M параметров (whisper large - 1500M), поэтому быстрый.
- по первым ощущениям, уровень ошибок на уровне whisper-large.
- но по метрикам превосходит все существующие модули распознавания речи для русского.
- по умолчанию работает на CPU и довольно быстро. Намного быстрее виспера на cpu
- на ГПУ запускать лень, надо triton-inference-server поднимать. Пишут, что для GPU нужно 8 GB vram
- не ставит знаки препинания (а виспер ставит)
- обычное голосовое сообщение умеренного качества, записанное на улице, длиной 74 секунды он распознал за 12 секунд на CPU. Работает потоково. Первая фраза появилась уже через 1 секунду. Итого: 10 ошибок, в основном, пропуск слов, которые плохо слышно, иногда неверные окончания.
Установка под виндой
(для linux или wsl - используйте официальную инструкцию)
По умолчанию демо работает на CPU. Чтобы запустить на GPU нужно ставить TensorRT и triton-inference-server. Там свои сложности, под винду есть только некоторые версии сервера. Официальная инструкция (я не тестил) https://github.com/voicekit-team/T-one/blob/main/docs/triton_inference_server.ru.md
гитхаб: https://github.com/voicekit-team/T-one
HF: https://huggingface.co/t-tech/T-one
- размер очень маленький - 71M параметров (whisper large - 1500M), поэтому быстрый.
- по первым ощущениям, уровень ошибок на уровне whisper-large.
- но по метрикам превосходит все существующие модули распознавания речи для русского.
- по умолчанию работает на CPU и довольно быстро. Намного быстрее виспера на cpu
- на ГПУ запускать лень, надо triton-inference-server поднимать. Пишут, что для GPU нужно 8 GB vram
- не ставит знаки препинания (а виспер ставит)
- обычное голосовое сообщение умеренного качества, записанное на улице, длиной 74 секунды он распознал за 12 секунд на CPU. Работает потоково. Первая фраза появилась уже через 1 секунду. Итого: 10 ошибок, в основном, пропуск слов, которые плохо слышно, иногда неверные окончания.
Установка под виндой
(для linux или wsl - используйте официальную инструкцию)
git clone https://github.com/voicekit-team/T-one.git
cd T-one
python -m venv .venv
.venv\Scripts\activate
в файле pyproject.toml удаляем или комментируем (#) строчку 16:
"kenlm (>=0.2.0,<1.0.0)",
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
bootstrap-vcpkg.sh
vcpkg integrate install
vcpkg install kenlm
cd ..
pip install poetry
poetry lock
poetry install -E demo
pip install kenlm
uvicorn --host 127.0.0.1 --port 8081 tone.demo.website:app --reload
открываем 127.0.0.1:8081 в браузере
По умолчанию демо работает на CPU. Чтобы запустить на GPU нужно ставить TensorRT и triton-inference-server. Там свои сложности, под винду есть только некоторые версии сервера. Официальная инструкция (я не тестил) https://github.com/voicekit-team/T-one/blob/main/docs/triton_inference_server.ru.md
гитхаб: https://github.com/voicekit-team/T-one
HF: https://huggingface.co/t-tech/T-one