1. Делаю демки и выкладываю, когда появляется запрос от коллег и есть свободное время (например, из недавнего - статья с издержками multilora инференса https://habr.com/ru/articles/922290/). Можешь еще на телеграм канал перейти (там можно в комментах задать вопрос или тему на обсуждение) или тут прожать "подписаться". Как будет новая статья, узнаешь)
2. Вряд ли проблемы возникают повсеместно, но с новыми моделями часты Из того, как просто сломать лицо - вот тут в посте писал про конвертацию слоя внимания.
Тут скорее была задача понять реальность запуска на игровых картах. Думал, что будет вполне реально пользоваться. Но не особо(
Если касательно использования в целом - qwen2.5-coder32b вполне хороша для рутины и изолированных применений. Много качественного кода без изощрений вряд ли какая-нибудь модель напишет.
Тут смотря для чего использовать) По комментам уже записал себе, что не хватило объяснения, зачем и кому использовать такой путь. Буду поправлять в следующих статьях
На мой взгляд, ollama уровнем абстракции выше У ollama есть бэкенд llama.cpp. Хочется ли вам запускать в прод golang, который дергает c++ - отдельный важный вопрос
По этой же причине возникают треды, типа такого на реддите. То есть какие-то оптимизации доезжают с лагом из ollama в llama.cpp, а у кого-то что-то тяжелее заводится. И тд
Ну и "запустил докер в проде" - это верхушка айсберга. Кому-то нужны свои сетевые фреймворки для выдерживания нагрузки, кому-то портативность, чтобы на мобилках этот же код запускать, кому-то - реализовать свои оптимизации, типа эффективной квантизации кешей
В этом плане, если в момент решения какой фреймворк задеплоить, вы не видите разницы между ollama и llama.cpp в контексте вашей задачи, а видите только сложности - наверное лучше взять то, что проще)
По зависимостям питона - их нет и в llama.cpp, это просто с++ бинарь. Ну, то есть, чисто технически, докер, собранный в статье их содержит, но это пример как супер быстро начать. Вы можете собрать через cmake код, что достаточно просто (я в последний момент вырезал эту секцию из статьи, подумав, что это не будет интересно. Но судя по накиданным минусам на статье за слабую техническую часть, стоило оставить)
Да, согласен, хороший вариант. Особенно, если основная рабочая машина на винде
С llama.cpp мне нравится вариант потому, что образ можно развернуть на сервере и ребята с команды смогут с ним взаимодействовать. Хоть через UI для быстрого теста, хоть через openai-compatible api с микросервиса Ну и потом этот же llama.cpp в проде развернуть на железе мощнее
2080 Ti 12gb для простенького запроса. --n-gpu-layers 20 DeepSeek-R1-Distill-Qwen-7B-F16
prompt eval time = 232.39 ms/24 tokens (9.68 ms per token, 103.28 tokens per second) eval time = 143668.70 ms/1246 tokens (115.30 ms per token, 8.67 tokens per second) total time = 143901.08 ms/1270 tokens
Обратите внимание, что эти цифры будут меняться от размера промпта. "вполне норм" - вполне норм, чтобы протестировать качество модели, имея под рукой +- любую не слишком старую видеокарту. Речь в туториале не идет об инференсе под нагрузкой
nvidia 2080 12Gb llama.cpp умеет в офлоадинг на RAM, нужно подобрать значение --n-gpu-layers при запуске докера. Для 32b модели генерит слишком медленно, для 7-8b вполне норм
Да, действительно, нужно проверить. Но делается это за один forward на все спекулятивные токены, а не авторегрессионно b - base d - drarf авторегрессия меняется так: bbbbbb -> dddddb
Другими словами, если t_base/t_draft - время генерации одного токена базовой/драфт моделью n - количество принимаемых токенов (оно не фиксированно, но для формулы и понимания сути - пойдет)
то мы получаем ускорение (n+1) * t_base/ (t_base + n * t_draft)
что приближает скорость алгоритма к скорости draft модели по мере увеличения среднего значения n
Это +- устоявшаяся терминология в контексте алгоритмов спекулятивного инференса 1. Base model (или просто model) - модель, которую хочется ускорить 2. Draft model - алгоритм (строго говоря, даже не обязательно нейросеть. В lookahead ее нет), который позволяет получать новые токены на порядок быстрее. Эта модель существенно хуже по качеству сама по себе, но подходит для генерации осмысленных связок наперед (что и приводит к ускорению). И выход этого алгоритма уже целиком анализируется Base model и частично принимается или отклоняется ею
Честно, сложно понять что-то о конкретной модели, опираясь на слухи (если я правильно Вас понял и ЧатИИ - это Openai ChatGPT) Могу сказать только, что обучение подобной модели - это сложная работа с множеством трюков, костылей и идей
По поводу самосознания - смотря что под этим понимать. Если сильно захотеть, можно и увидеть чего 🙂 Но вообще говоря llm просто предсказывает следующий токен по контексту и делает это хорошо, в том числе за счет дообучения на обратной связи (RLHF), так что нет
Вы правы. Спрос планировать нельзя. Однако, если у Вас производство, или же Вы закупаете продукцию/сырье из другой страны, например, то необходимо заранее решать (за 1-6 месяцев,
как правило), что именно произвести и закупить, несколько позже — как распределять между складами и планировать логистику.
При этом у таких компаний не менее 50 постоянных партнеров и не менее 20-30 позиций.
И, как правило, ничего лучше, чем «давайте посчитаем, как было раньше» (скользящее среднее) применительно ко всем озвученным в статье задачам, не придумано.
Какие данные они собираются пропускать через нейронные сети
Действительно, над данными необходимо работать, но не все так плохо. Правда, пока лучше себя показывает метрический ML и методы на деревьях (они же интерпретируемы и более устойчивы).
«комбинировать алгоритмы, строить эвристики»
Это было в разделе про интерпретируемость алгоритмов. Никто не хочет доверять алгоритму, который может работать нестабильно. Потому необходимо вводить ограничения, метрики, отслеживать изменения в данных и т. д. (эвристики). И дело тут даже не в количестве данных.
В случае, если компания заинтересована в разработке решения внутренними силами
(в том числе разработке алгоритмов) и собирается самостоятельно его поддерживать — такой подход может оказаться верным. Или, если никакие сложные алгоритмы не нужны, а достаточно просто визуализации
Цели что-либо предлагать у меня не было. Однако, не вижу ничего плохого в экспериментах, если
они позволяют с минимальными издержками (или без них) на практике понять необходимость ПО (или ее отсутствие).
Это снижает риски.
К тому же, каждая компания самостоятельно решает, какой способ решения проблемы больше подходит в ее случае
Запросы принял, спасибо за обратную связь)
1. Делаю демки и выкладываю, когда появляется запрос от коллег и есть свободное время (например, из недавнего - статья с издержками multilora инференса https://habr.com/ru/articles/922290/).
Можешь еще на телеграм канал перейти (там можно в комментах задать вопрос или тему на обсуждение) или тут прожать "подписаться". Как будет новая статья, узнаешь)
2. Вряд ли проблемы возникают повсеместно, но с новыми моделями часты
Из того, как просто сломать лицо - вот тут в посте писал про конвертацию слоя внимания.
Тут скорее была задача понять реальность запуска на игровых картах. Думал, что будет вполне реально пользоваться. Но не особо(
Если касательно использования в целом - qwen2.5-coder32b вполне хороша для рутины и изолированных применений.
Много качественного кода без изощрений вряд ли какая-нибудь модель напишет.
Тут смотря для чего использовать)
По комментам уже записал себе, что не хватило объяснения, зачем и кому использовать такой путь. Буду поправлять в следующих статьях
На мой взгляд, ollama уровнем абстракции выше
У ollama есть бэкенд llama.cpp. Хочется ли вам запускать в прод golang, который дергает c++ - отдельный важный вопрос
По этой же причине возникают треды, типа такого на реддите. То есть какие-то оптимизации доезжают с лагом из ollama в llama.cpp, а у кого-то что-то тяжелее заводится. И тд
Ну и "запустил докер в проде" - это верхушка айсберга. Кому-то нужны свои сетевые фреймворки для выдерживания нагрузки, кому-то портативность, чтобы на мобилках этот же код запускать, кому-то - реализовать свои оптимизации, типа эффективной квантизации кешей
В этом плане, если в момент решения какой фреймворк задеплоить, вы не видите разницы между ollama и llama.cpp в контексте вашей задачи, а видите только сложности - наверное лучше взять то, что проще)
По зависимостям питона - их нет и в llama.cpp, это просто с++ бинарь. Ну, то есть, чисто технически, докер, собранный в статье их содержит, но это пример как супер быстро начать.
Вы можете собрать через cmake код, что достаточно просто (я в последний момент вырезал эту секцию из статьи, подумав, что это не будет интересно. Но судя по накиданным минусам на статье за слабую техническую часть, стоило оставить)
И вам хорошего дня и счастливой жизни. Весь текст написан автором, без использования llm
Прикладываю скрин с карточки модели (https://huggingface.co/deepseek-ai/DeepSeek-R1)
Если вас смущают цифры, предоставленные deepseek, можете обратиться к ним. Если есть конструктивные вопросы, можем обсудить тут 😊
Понимаю, что на ваших задачах может быть не так. Я добавлю отсылку на материал, на основании которого сделан вывод, в статью
Да, согласен. Если нужно просто пользоваться моделью самому - приложение точно удобнее. Тем более под винду
Про расцензуренные модели - спасибо, читателям будет полезно)
Хотя, если модель разворачивать для компании, возможно, цензура не помешает)
Да, согласен, хороший вариант. Особенно, если основная рабочая машина на винде
С llama.cpp мне нравится вариант потому, что образ можно развернуть на сервере и ребята с команды смогут с ним взаимодействовать. Хоть через UI для быстрого теста, хоть через openai-compatible api с микросервиса
Ну и потом этот же llama.cpp в проде развернуть на железе мощнее
2080 Ti 12gb для простенького запроса. --n-gpu-layers 20
DeepSeek-R1-Distill-Qwen-7B-F16
prompt eval time = 232.39 ms/24 tokens (9.68 ms per token, 103.28 tokens per second)
eval time = 143668.70 ms/1246 tokens (115.30 ms per token, 8.67 tokens per second)
total time = 143901.08 ms/1270 tokens
Обратите внимание, что эти цифры будут меняться от размера промпта.
"вполне норм" - вполне норм, чтобы протестировать качество модели, имея под рукой +- любую не слишком старую видеокарту. Речь в туториале не идет об инференсе под нагрузкой
nvidia 2080 12Gb
llama.cpp умеет в офлоадинг на RAM, нужно подобрать значение --n-gpu-layers при запуске докера.
Для 32b модели генерит слишком медленно, для 7-8b вполне норм
спасибо)
Да, действительно, нужно проверить. Но делается это за один forward на все спекулятивные токены, а не авторегрессионно
b - base
d - drarf
авторегрессия меняется так: bbbbbb -> dddddb
Другими словами, если
t_base/t_draft - время генерации одного токена базовой/драфт моделью
n - количество принимаемых токенов (оно не фиксированно, но для формулы и понимания сути - пойдет)
то мы получаем ускорение
(n+1) * t_base/ (t_base + n * t_draft)
что приближает скорость алгоритма к скорости draft модели по мере увеличения среднего значения n
Это +- устоявшаяся терминология в контексте алгоритмов спекулятивного инференса
1. Base model (или просто model) - модель, которую хочется ускорить
2. Draft model - алгоритм (строго говоря, даже не обязательно нейросеть. В lookahead ее нет), который позволяет получать новые токены на порядок быстрее. Эта модель существенно хуже по качеству сама по себе, но подходит для генерации осмысленных связок наперед (что и приводит к ускорению). И выход этого алгоритма уже целиком анализируется Base model и частично принимается или отклоняется ею
Честно, сложно понять что-то о конкретной модели, опираясь на слухи (если я правильно Вас понял и ЧатИИ - это Openai ChatGPT)
Могу сказать только, что обучение подобной модели - это сложная работа с множеством трюков, костылей и идей
По поводу самосознания - смотря что под этим понимать. Если сильно захотеть, можно и увидеть чего 🙂
Но вообще говоря llm просто предсказывает следующий токен по контексту и делает это хорошо, в том числе за счет дообучения на обратной связи (RLHF), так что нет
как правило), что именно произвести и закупить, несколько позже — как распределять между складами и планировать логистику.
При этом у таких компаний не менее 50 постоянных партнеров и не менее 20-30 позиций.
И, как правило, ничего лучше, чем «давайте посчитаем, как было раньше» (скользящее среднее) применительно ко всем озвученным в статье задачам, не придумано.
Действительно, над данными необходимо работать, но не все так плохо. Правда, пока лучше себя показывает метрический ML и методы на деревьях (они же интерпретируемы и более устойчивы).
Это было в разделе про интерпретируемость алгоритмов. Никто не хочет доверять алгоритму, который может работать нестабильно. Потому необходимо вводить ограничения, метрики, отслеживать изменения в данных и т. д. (эвристики). И дело тут даже не в количестве данных.
(в том числе разработке алгоритмов) и собирается самостоятельно его поддерживать — такой подход может оказаться верным. Или, если никакие сложные алгоритмы не нужны, а достаточно просто визуализации
Цели что-либо предлагать у меня не было. Однако, не вижу ничего плохого в экспериментах, если
они позволяют с минимальными издержками (или без них) на практике понять необходимость ПО (или ее отсутствие).
Это снижает риски.
К тому же, каждая компания самостоятельно решает, какой способ решения проблемы больше подходит в ее случае