Эдгар, спасибо большое за статью! Мне очень импонирует уклон в твоей работе в сторону практики. Спасибо, что втянул меня в мир LLM и теперь я не могу пройти мимо и тоже тестирую на досуге модели :) Конечно, ограниченность и дороговизна памяти на GPU намекает, что нужно искать решения запуска на CPU, но насколько пока лично смог убедиться - вычислительные мощности несоизмеримы. Мне наконец-то удалось нормально запустить Codestral:22b, тормозила на RTX 3060, но с 24Gb "новой" 3090 стало отлично!
Субъективно - небо и земля, без видеокарты на моем железе не имеет смысла, инициализация модели идет несколько минут. С видеокартой - 10с и сам вывод значительно быстрее.
Думаю, что тема интересная и заслуживает отдельной статьи с измерениями и большим числом моделей. Я лично не увидел какую-либо корреляцию размера модели с конкретным железом и объемом видеопамяти. Специальных замеров я, к сожалению, не делал, могу только субъективно расставить в порядке производительности, начиная от самой быстрой модели: starcoder2:latest, starcoder2:15b, deepseek-coder:6.7b, codestral:22b.
Спасибо большое за отличный комментарий! Действительно моделей гораздо больше, чем я описал, более того я лично попробовал лишь малую часть. Предлагаемая Вами модель больше относится к общим языковым моделям, думаю, что тоже справится с кодом, но это не ее специфика. Стоит так же обращать внимание на лицензию и компанию разработчика модели, оценить сможете ли Вы ее использовать.
Да, согласен, тоже отличное решение! В моем же случае мне была еще важна внешняя видеокарта и для обычных повседневных задач, интегрированная карта ноутбука не тянула (большое разрешение, куча программ с аппаратным ускорением и тп). Более того, перестав использовать интегрированную карту (на одном кристалле с CPU) немного остудил CPU.
Спасибо большое за хороший комментарий! Есть поле для исследования. Действительно размер образа codestral:22b - 12Gb, при использовании модели nvtop показывает загрузку видеопамяти 11.635 из 12Gb (размер видеопамяти моей карты), прям впритык. При использовании модели загрузка GPU 10-20%, CPU примерно 30%, но нет увеличения использования обычной памяти.
Спасибо большое за отличный вопрос! О каких-то явных ограничениях мне не известно. Порт Thunderbolt не ограничивается подключением одного устройства. Ollama может работать с несколькими ускорителями, docker тоже может прокидывать несколько карт в контейнер. Полагаю, что узким местом может стать пропускная способность Thunderbolt, например при подключении через hub, что возможно скажется на производительности.
Спасибо большое за плюс! Вы все правильно поняли, в китайский адаптер egpu вставлена видеокарта, туда же подключается блок питания ATX. От адаптера egpu идет шлейф M2, в который вставляется в SSD-ный (Nvme) переходник, который в свою очередь имеет порт Thunderbolt, который в итоге вставляется в ноутбук. Изначально тестировал с видеокартой от стационарного домашнего компьютера (старая Nvidia GTX 760), так не был уверен, что все взлетит. Когда все заработало, то уже смело заказал видеокарту. Когда подключал M2 в тот порт под LTE/GPRS модем, адаптер egpu и видеокарта стартовали (вентиляторы на видеокарте начинали крутиться, индикаторы на egpu переключались), но ноутбук зависал с тем информационным сообщением, что я описал.
Спасибо большое за хороший комментарий! Так как ollama выставляет 1 порт, то действительно можно собрать на отдельном устройстве (мини сервер) и сделать доступ по сети. Быстрая работа с ollama - это конечно большой плюс, но и для повседневных задач мне лично хотелось иметь на рабочем ноутбуке видеокарту побыстрее. После установки работа стала намного комфортнее со всеми приложениями, любящими аппаратное ускорение (Chrome, electron и тп). Еще из важных плюсов то, что встроенная видеокарта на одном кристалле с самим CPU, и когда она перестала использоваться, то температура процессора снизилась.
Мне, к сожалению, не на чем попробовать, но почти уверен, что будет работать и ресурсов хватит, а вот оценить скорость работы поможет только эксперимент. Попробуйте сначала модель пошустрее deepseek-coder:6.7b. На Mac возможно имеет смысл запускать ollama как нативное приложение (можно скачать на официальном сайте), будет выигрыш по производительности 50%, тк, докер скорее всего GPU в контейнер не пробросит (возможно уже пофиксили).
Действительно на данный момент под Windows (в меньшей степени под Mac) больше готовых инструментов "ограничивающих" кислород, субъективно предполагаю, что тренд будет все же в сторону линуксового ПО, тк лицензии покупать стало сложнее. Мне лично удобнее разрабатывать под Linux, тк среда разработки похожа на продуктив.
Спасибо большое за крутой комментарий, тема безопасности это как раз основной мотиватор использования локальных моделей! Специально по хостам не мониторил, но какой-то необычной активности не наблюдал. Думаю для реальных проектов для контейнера с ollama необходимо создавать контейнер в другой сетке без интернета в докере.
В Вашем случае нагрузка сравнительно небольшая, выдержит практически любой движок. Вопрос в истории и сложности бизнес-процессов. В случае транзакционных bpmn, требуется сразу подумать об очистке (полной или частичной) истории. Лично я, видя Ваши показатели по нагрузке, выбрал бы Zeebe (Camunda Platform). Во-первых сразу заложиться на развитие системы, во-вторых - проект живой, регулярно улучшается и обновляется, в третьих - используются передовые, на данный момент, технологии и интеграционные решения. Если же нужно быстрое решение (завтра в прод), то, видимо, Camunda 7.X (но быть готовым, что поддержка проекта заканчивается и нужно думать о периодических чистках и оптимизации бд). In-memory бд, в Вашем случае пока не имеет смысла.
Мы в проде, обновились до 8й версии. Сам движок Zeebe стал стабильнее, улучшается от версии к версии. От нативного DMN от Camunda пришлось отказаться, нам нужно быстрее, написали свой совместимый по-проще. Так же сделали свой фронт с редактором BPMN, DMN, упрощенный Optimize и пользовательские задачи. Пока довольны.
Подскажите, пожалуйста, предполагается ли в будущем какая-то визуальная часть - фронт? Основным достоинством Camunda, Zeebe является возможность нарисовать процесс, согласовать его с бизнесом, а потом в сockpit увидеть визуально, где находится процесс, где ошибки, просматривать контекст и многое другое. Если основная задача была в декомпозиции, не смотрели ли на существующие аналоги - Spring Integration, Apache Camel ?
Спасибо большое за статью! Вы пишете про SAP, что "большая база данных требует десятков терабайтов оперативной памяти". Подскажите, пожалуйста, на какое ориентировочное кол-во пользователей рассчитаны столь невероятные ресурсы? Какую примерную конфигурацию серверов 1С можно сопоставить, чтобы справится с аналогичной нагрузкой?
Flowable обогнал только Zeebe. Результаты хуже, чем у Camunda примерно в 2 раза. Без экспорта результат проигрывает Camunda почти в 4 раза. Код проекта добавил к существующей группе проектов - pure-flowable.
Эдгар, спасибо большое за статью! Мне очень импонирует уклон в твоей работе в сторону практики. Спасибо, что втянул меня в мир LLM и теперь я не могу пройти мимо и тоже тестирую на досуге модели :) Конечно, ограниченность и дороговизна памяти на GPU намекает, что нужно искать решения запуска на CPU, но насколько пока лично смог убедиться - вычислительные мощности несоизмеримы. Мне наконец-то удалось нормально запустить Codestral:22b, тормозила на RTX 3060, но с 24Gb "новой" 3090 стало отлично!
Спасибо большое за комментарий! Про установку дополнительных пакетов для докера я писал во второй части статьи:
https://habr.com/ru/companies/ozonbank/articles/848064/
Субъективно - небо и земля, без видеокарты на моем железе не имеет смысла, инициализация модели идет несколько минут. С видеокартой - 10с и сам вывод значительно быстрее.
Думаю, что тема интересная и заслуживает отдельной статьи с измерениями и большим числом моделей. Я лично не увидел какую-либо корреляцию размера модели с конкретным железом и объемом видеопамяти. Специальных замеров я, к сожалению, не делал, могу только субъективно расставить в порядке производительности, начиная от самой быстрой модели: starcoder2:latest, starcoder2:15b, deepseek-coder:6.7b, codestral:22b.
Спасибо большое за отличный комментарий! Действительно моделей гораздо больше, чем я описал, более того я лично попробовал лишь малую часть. Предлагаемая Вами модель больше относится к общим языковым моделям, думаю, что тоже справится с кодом, но это не ее специфика. Стоит так же обращать внимание на лицензию и компанию разработчика модели, оценить сможете ли Вы ее использовать.
Да, согласен, тоже отличное решение! В моем же случае мне была еще важна внешняя видеокарта и для обычных повседневных задач, интегрированная карта ноутбука не тянула (большое разрешение, куча программ с аппаратным ускорением и тп). Более того, перестав использовать интегрированную карту (на одном кристалле с CPU) немного остудил CPU.
Спасибо большое за хороший комментарий! Есть поле для исследования. Действительно размер образа codestral:22b - 12Gb, при использовании модели nvtop показывает загрузку видеопамяти 11.635 из 12Gb (размер видеопамяти моей карты), прям впритык. При использовании модели загрузка GPU 10-20%, CPU примерно 30%, но нет увеличения использования обычной памяти.
Я думаю можно, поискал, нашел официальную инструкцию у докер через wsl2:
https://docs.docker.com/desktop/gpu/
Все верно, спасибо за уточнение!
Спасибо большое за отличный вопрос! О каких-то явных ограничениях мне не известно. Порт Thunderbolt не ограничивается подключением одного устройства. Ollama может работать с несколькими ускорителями, docker тоже может прокидывать несколько карт в контейнер. Полагаю, что узким местом может стать пропускная способность Thunderbolt, например при подключении через hub, что возможно скажется на производительности.
Спасибо большое за плюс! Вы все правильно поняли, в китайский адаптер egpu вставлена видеокарта, туда же подключается блок питания ATX. От адаптера egpu идет шлейф M2, в который вставляется в SSD-ный (Nvme) переходник, который в свою очередь имеет порт Thunderbolt, который в итоге вставляется в ноутбук. Изначально тестировал с видеокартой от стационарного домашнего компьютера (старая Nvidia GTX 760), так не был уверен, что все взлетит. Когда все заработало, то уже смело заказал видеокарту. Когда подключал M2 в тот порт под LTE/GPRS модем, адаптер egpu и видеокарта стартовали (вентиляторы на видеокарте начинали крутиться, индикаторы на egpu переключались), но ноутбук зависал с тем информационным сообщением, что я описал.
Спасибо большое за хороший комментарий! Так как ollama выставляет 1 порт, то действительно можно собрать на отдельном устройстве (мини сервер) и сделать доступ по сети. Быстрая работа с ollama - это конечно большой плюс, но и для повседневных задач мне лично хотелось иметь на рабочем ноутбуке видеокарту побыстрее. После установки работа стала намного комфортнее со всеми приложениями, любящими аппаратное ускорение (Chrome, electron и тп). Еще из важных плюсов то, что встроенная видеокарта на одном кристалле с самим CPU, и когда она перестала использоваться, то температура процессора снизилась.
Мне, к сожалению, не на чем попробовать, но почти уверен, что будет работать и ресурсов хватит, а вот оценить скорость работы поможет только эксперимент. Попробуйте сначала модель пошустрее deepseek-coder:6.7b. На Mac возможно имеет смысл запускать ollama как нативное приложение (можно скачать на официальном сайте), будет выигрыш по производительности 50%, тк, докер скорее всего GPU в контейнер не пробросит (возможно уже пофиксили).
Действительно на данный момент под Windows (в меньшей степени под Mac) больше готовых инструментов "ограничивающих" кислород, субъективно предполагаю, что тренд будет все же в сторону линуксового ПО, тк лицензии покупать стало сложнее. Мне лично удобнее разрабатывать под Linux, тк среда разработки похожа на продуктив.
Спасибо большое за крутой комментарий, тема безопасности это как раз основной мотиватор использования локальных моделей! Специально по хостам не мониторил, но какой-то необычной активности не наблюдал. Думаю для реальных проектов для контейнера с ollama необходимо создавать контейнер в другой сетке без интернета в докере.
В Вашем случае нагрузка сравнительно небольшая, выдержит практически любой движок. Вопрос в истории и сложности бизнес-процессов. В случае транзакционных bpmn, требуется сразу подумать об очистке (полной или частичной) истории.
Лично я, видя Ваши показатели по нагрузке, выбрал бы Zeebe (Camunda Platform). Во-первых сразу заложиться на развитие системы, во-вторых - проект живой, регулярно улучшается и обновляется, в третьих - используются передовые, на данный момент, технологии и интеграционные решения. Если же нужно быстрое решение (завтра в прод), то, видимо, Camunda 7.X (но быть готовым, что поддержка проекта заканчивается и нужно думать о периодических чистках и оптимизации бд). In-memory бд, в Вашем случае пока не имеет смысла.
Мы в проде, обновились до 8й версии. Сам движок Zeebe стал стабильнее, улучшается от версии к версии. От нативного DMN от Camunda пришлось отказаться, нам нужно быстрее, написали свой совместимый по-проще. Так же сделали свой фронт с редактором BPMN, DMN, упрощенный Optimize и пользовательские задачи. Пока довольны.
Подскажите, пожалуйста, предполагается ли в будущем какая-то визуальная часть - фронт? Основным достоинством Camunda, Zeebe является возможность нарисовать процесс, согласовать его с бизнесом, а потом в сockpit увидеть визуально, где находится процесс, где ошибки, просматривать контекст и многое другое. Если основная задача была в декомпозиции, не смотрели ли на существующие аналоги - Spring Integration, Apache Camel ?
Спасибо большое за статью! Вы пишете про SAP, что "большая база данных требует десятков терабайтов оперативной памяти". Подскажите, пожалуйста, на какое ориентировочное кол-во пользователей рассчитаны столь невероятные ресурсы? Какую примерную конфигурацию серверов 1С можно сопоставить, чтобы справится с аналогичной нагрузкой?
Flowable обогнал только Zeebe. Результаты хуже, чем у Camunda примерно в 2 раза. Без экспорта результат проигрывает Camunda почти в 4 раза. Код проекта добавил к существующей группе проектов - pure-flowable.