Тогда вы ограничены deepseek. Оплата за токены не обязательно лучше, вопрос в том, как часто вы используете инструмент. Но оплата при dedicated модели pay-as-you-go, то есть посекундная, где в минуту это 1.5 рублей)
Для использования AI opensource проекта вам в любом случае нужны будут модели. Tabby бесплатен, но бюджет на модели в любом случае нужен. 15к на упрощение разработки кажется вполне приемлемо)
Да, вы правы, все таки упор у нас на задачи, которым нужны как минимум все ресурсы одной gpu, так как, если быть честными, сложно найти сейчас задачи с низкой нагрузкой. Здесь можно использовать поменьше gpu у нас, например, RTX 2000 Ada с 16 vram. По поводу других, все таки, у нас идет ориентир на Gen AI, уже есть no-code деплой, сейчас активно работаем над no-code дообучением
Я понимаю о чем вы говорите, но это было бы применимо, если бы мы запускали несколько тенантов на одном GPU с помощью MIG или мультиплексирования, но это не наш кейс. Правда, не совсем понимаю, почему вы так решили). На одной машине с выбранным кол-во gpu (1-8) запускается только одна задача, соответственно по ресурсам, это также как если бы вы запустили виртуальный сервер с gpu в яндексе.
По ram/cpu, например, L4, которую вы указали, 24 гб ссылается на gpu память (vram), касательно ram для сервера, прямо сейчас это 48 гб и 10 vcpu, но так как у нас нет мультиплексирования, то 128 GB RAM не является необходимостью.
Касатально настройки, идет отсылка не просто к запуску контейнера на машине, что не является продакшн решением, что действительно, можно сделать очень быстро, а именно настройки окружения, которое будет способно выдерживать меняющуюся нагрузку, а именно автомасштабирование в kubernetes со всеми сопутствующими. На это действительно уйдет не пару дней. Более того, большие облака не любят, когда такое происходит, поэтому вводят "санкции" в виде ошибки о том, что все gpu заняты, подталкивая иметь постоянно запущенные машины, чтобы больше тратили.
Опять же просто запустить задачу на одном сервере без автомасштабирвония к нулю, ведет к переиспользованию ресурсов, когда они вам не нужны.
По поводу оплаты, у нас посекундая тарификация с ценами указанными на платформе.
Если у вас остались вопросы, пожалуйста, буду рад ответить ;)
Здравствуйте, вы правы, этот код не жизнеспособен за пределами очень простых моделей и минимального количества пользователей. Но цель этой статьи показать основную идею для тех, кто хотел бы начать или продолжить реализацию Model Serving инструмента. При дальнейшей реализации, разработчики уже смогут добавить очередь, gpu поддержку, репликацию, батчинг и т.д., все, что нужно для полноценной работы. Поэтому, я рекомендовал использвать bentoml и seldon core и не брать этот код в production.
RestAPI здесь нужен затем, что servingml server, работает не зависимо от клиента, где цель клиента только в том, чтобы передать архив проекта на сервер, который уже сам должен распределять задачи. Опять же, это не я придумал, а рассказал, то как работают данные фреймворки, в первую очередь mlrun.
Сам же servingml server может быть доведен до того, чтобы использовать его в kubernetes, добавив в helm.
Очень понравилась статья! Позволяет систематизировать знания и понять, что и как делать дальше.
Единственное, после слов - На схеме это Automated ML Workflow Pipeline (блок D), который запускается по триггерам в каком-либо инструменте оркестрации, приведен блок B, а не D. Но на качетсво статьи, это не влияет)
Добрый день!
Благодарю за обратную связь, добавим фиксы в ближайшее время
Тогда вы ограничены deepseek. Оплата за токены не обязательно лучше, вопрос в том, как часто вы используете инструмент. Но оплата при dedicated модели pay-as-you-go, то есть посекундная, где в минуту это 1.5 рублей)
Для использования AI opensource проекта вам в любом случае нужны будут модели. Tabby бесплатен, но бюджет на модели в любом случае нужен.
15к на упрощение разработки кажется вполне приемлемо)
Да, вы правы, все таки упор у нас на задачи, которым нужны как минимум все ресурсы одной gpu, так как, если быть честными, сложно найти сейчас задачи с низкой нагрузкой. Здесь можно использовать поменьше gpu у нас, например, RTX 2000 Ada с 16 vram.
По поводу других, все таки, у нас идет ориентир на Gen AI, уже есть no-code деплой, сейчас активно работаем над no-code дообучением
Здравствуйте! Спасибо за комментарий.
Я понимаю о чем вы говорите, но это было бы применимо, если бы мы запускали несколько тенантов на одном GPU с помощью MIG или мультиплексирования, но это не наш кейс. Правда, не совсем понимаю, почему вы так решили). На одной машине с выбранным кол-во gpu (1-8) запускается только одна задача, соответственно по ресурсам, это также как если бы вы запустили виртуальный сервер с gpu в яндексе.
По ram/cpu, например, L4, которую вы указали, 24 гб ссылается на gpu память (vram), касательно ram для сервера, прямо сейчас это 48 гб и 10 vcpu, но так как у нас нет мультиплексирования, то 128 GB RAM не является необходимостью.
Касатально настройки, идет отсылка не просто к запуску контейнера на машине, что не является продакшн решением, что действительно, можно сделать очень быстро, а именно настройки окружения, которое будет способно выдерживать меняющуюся нагрузку, а именно автомасштабирование в kubernetes со всеми сопутствующими.
На это действительно уйдет не пару дней. Более того, большие облака не любят, когда такое происходит, поэтому вводят "санкции" в виде ошибки о том, что все gpu заняты, подталкивая иметь постоянно запущенные машины, чтобы больше тратили.
Опять же просто запустить задачу на одном сервере без автомасштабирвония к нулю, ведет к переиспользованию ресурсов, когда они вам не нужны.
По поводу оплаты, у нас посекундая тарификация с ценами указанными на платформе.
Если у вас остались вопросы, пожалуйста, буду рад ответить ;)
Как раз таки замечания @ivankudryavtsev объясняют почему нельзя использовать данный код в production. Он не достаточно надежен для этого
Здравствуйте, вы правы, этот код не жизнеспособен за пределами очень простых моделей и минимального количества пользователей. Но цель этой статьи показать основную идею для тех, кто хотел бы начать или продолжить реализацию Model Serving инструмента. При дальнейшей реализации, разработчики уже смогут добавить очередь, gpu поддержку, репликацию, батчинг и т.д., все, что нужно для полноценной работы. Поэтому, я рекомендовал использвать bentoml и seldon core и не брать этот код в production.
RestAPI здесь нужен затем, что servingml server, работает не зависимо от клиента, где цель клиента только в том, чтобы передать архив проекта на сервер, который уже сам должен распределять задачи. Опять же, это не я придумал, а рассказал, то как работают данные фреймворки, в первую очередь mlrun.
Сам же servingml server может быть доведен до того, чтобы использовать его в kubernetes, добавив в helm.
Очень понравилась статья! Позволяет систематизировать знания и понять, что и как делать дальше.
Единственное, после слов - На схеме это Automated ML Workflow Pipeline (блок D), который запускается по триггерам в каком-либо инструменте оркестрации, приведен блок B, а не D. Но на качетсво статьи, это не влияет)