Тут все сложно))) У меня сейчас в доступе только мой RTX 5060 ti, в котором и памяти всего 16 гиг, и сам он по числу ядер слабоват. Поэтому я сейчас эксперименты ставлю на маленьком qwen, который помещается (вместе с ASR и TTS) в 16 гиг памяти моего rtx. Ну и, в принципе, он отвечает, но там задержки великоваты - от 0,6с до 2,5с. А ребята из InRack дали сервер с Nvidia A100 на 40GB. Я там все поставлю и модельки можно будет разные попробовать, и на время ответа LLM посмотреть, и на зависимость качества ответа от размера модельки тоже.
rtx 5060 ti с 16gb , это consumer-level, для qwen в 7-8b ещё ок, но если хочешь 70b или несколько потоков , будет bottleneck по VRAM и по compute. a100 40gb , совсем другой уровень, там и модельку можно покрупнее держать в памяти, и batch processing нормально работает. задержки в 0.6-2.5с на 7b , это в принципе рабочий вариант для неспешного диалога, но если нужна реакция близкая к realtime , нужен сервер помощнее. для таких экспериментов я бы посоветовал глянуть почасовые GPU-инстансы на regcloud , a100 там тоже есть, и платишь только за время использования. удобно для тестирования разных модельки и конфигов перед тем как железо покупать
Тут все сложно))) У меня сейчас в доступе только мой RTX 5060 ti, в котором и памяти всего 16 гиг, и сам он по числу ядер слабоват. Поэтому я сейчас эксперименты ставлю на маленьком qwen, который помещается (вместе с ASR и TTS) в 16 гиг памяти моего rtx. Ну и, в принципе, он отвечает, но там задержки великоваты - от 0,6с до 2,5с. А ребята из InRack дали сервер с Nvidia A100 на 40GB. Я там все поставлю и модельки можно будет разные попробовать, и на время ответа LLM посмотреть, и на зависимость качества ответа от размера модельки тоже.
Вот тут кстати интересно. у меня по началу примерно одинаковое время ответа было, что на 5060, что на 6000 с 96 гигами)
rtx 5060 ti с 16gb , это consumer-level, для qwen в 7-8b ещё ок, но если хочешь 70b или несколько потоков , будет bottleneck по VRAM и по compute. a100 40gb , совсем другой уровень, там и модельку можно покрупнее держать в памяти, и batch processing нормально работает. задержки в 0.6-2.5с на 7b , это в принципе рабочий вариант для неспешного диалога, но если нужна реакция близкая к realtime , нужен сервер помощнее. для таких экспериментов я бы посоветовал глянуть почасовые GPU-инстансы на regcloud , a100 там тоже есть, и платишь только за время использования. удобно для тестирования разных модельки и конфигов перед тем как железо покупать
Само собой, это просто чтоб проверить, что код работает подходит (хотя, для сингл инстанса тоже можно подкрутить). Так-то надо брать что-то специализированное + выбирать. Собственно, про это тоже расскажу
Само собой, это просто чтоб проверить, что код работает подходит (хотя, для сингл инстанса тоже можно подкрутить). Так-то надо брать что-то специализированное + выбирать. Собственно, про это тоже расскажу
Ну, я про это тоже рассказывать буду. так, что обязательно послушаю)
Это сильно зависит от модели и её настроек. Там места для тюнинга и большего потребления вагон
Есть такое. там даже промт сильно влияет. вообще. прям куча всего. не скажу, что прям все знаю. но экспериментов провел. Но все равно, не считаю, что добился отличного результата, есть куда расти. собственно, даже презу переделываю по 2 раза в день с каждым экспериментом
Есть такое. там даже промт сильно влияет. вообще. прям куча всего. не скажу, что прям все знаю. но экспериментов провел. Но все равно, не считаю, что добился отличного результата, есть куда расти. собственно, даже презу переделываю по 2 раза в день с каждым экспериментом
Да-да, если в начале промта добавить "ответь коротко", то вместо 2.5 секунд на генерацию ответа уходит 0.6 сек
? SIPgram: шлюз между корпоративной АТС и звонками Telegram
У компании уже есть АТС: внутренние номера, очереди, маршрутизация. Но чтобы всё это работало на мобильном, сотруднику нужен отдельный SIP-клиент - его надо установить, настроить и держать в фоне. На практике он то теряет регистрацию, то засыпает вместе с системой, и звонок до человека не доходит. SIPgram делает интерфейсом к этой же АТС мессенджер, который у сотрудника уже стоит. Для Asterisk шлюз выглядит как обычные внутренние номера: входящий приходит обычным звонком в Telegram, исходящий инициируется прямо из чата. Вся логика при этом остаётся на станции - маршруты, очереди, Caller ID, запись, CDR и voicemail.
Проект разворачивается на своём сервере, исходный код открыт, образ собран под amd64 и arm64. В докладе разберём, как устроен такой сценарий, кому он подходит и где у него границы.
Тезисы -Почему отдельный мобильный софтфон не всегда доезжает до сотрудника. -Telegram как интерфейс к существующей АТС, а не её замена и не второй софтфон. -Входящие и исходящие звонки через обычные extensions. -Один Telegram-аккаунт обслуживает нескольких пользователей. -Удержание, переводы, конференции, DTMF и click-to-call. -Почему маршрутизация и бизнес-логика остаются на АТС. -Self-hosted: исходный код открыт, SIP-учётные данные не покидают периметр. -Ограничения Telegram и границы такого решения.
Купить билет на конференцию AsterConf Данный доклад будет 24 сентября в открытой трансляции Asterisk eXPerience
