rPman

Нужны видеокарты, суммарным объемом 1024гб. тут только специализированные, найти в продаже в странах под санкциями нереал, рынок пустой был уже в 2020-ом. Цены тут 5х от мировых.

Квантизация тут тоже есть, vllm самая эффективная реализация, поэтому если тебе не нужно дообучать, а только исполнение, то пойдет 8bit квантизация.
-------

На процессоре с помощью llama.cpp, где-нибудь 10-20 секунд на токен (кстати повышается в несколько раз при batch запросах, когда тебе нужно обработать сразу много prompt-ов).

Тебе нужна серверная материнка (хоть прошлого поколения, важна оперативная память), размер памяти минимум 256гб (4битная квантизация, потеряешь в качестве), лучше 512гб. К сожалению рынок тут только БУ со всеми вытекающими от сюда ценами и гарантиями.
--------

Можно запускать на нескольких десктопах!
Год назад в llama.cpp портировали MPI реализацию, поддержка запуска на нескольких нодах (как пример нам было 8 raspberrypi и llama65b) поэтому приобрести 4 компьютера по 64-128гб не проблема, процессор не самый топовый, какой-нибудь AMD Ryzen 5 9600X/7600X (6-ядерный, лучшая производительность singlethread дешевле $300/$200), на сколько я понял, упирается все в сеть, поэтому сверху 10Gb ethernet адаптеры в придачу (они относительно дешевые).

Каждый из компьютеров обойдется примерно в 100т.р. (можно ужаться и набрать по 70т.р. но там и процессоры по слабее и память по медленнее, но не значительно), и таких нужно 3-4 штуки.

Сетевые карты 10G покупать парами, объединить в круг (это самый дешевый конфиг). Иначе, еще вложиться в свитч примерно такой же стоимости. Если честно я не нашел информации или каких то расчетов, которые скажут требования к сети, очень даже может быть что хватит встроенных в материнку и гигабитного свитча, речь идет об оптимальной утилизации процессора и памяти.
--------

Есть еще один экстремальный вариант, он не требует почти никаких особых затрат, любая даже самая слабая железка с любым количеством RAM (пусть условно 16гб-32гб будет, контекст хранить нужно) но с максимально быстрым ssd nvme диском (или несколькими в raid0). llama.cpp штатно умеет работать с моделями напрямую с диска (mlock режим), будет считывать всю модель по одному разу на каждый токен.

Например 4 ssd диска (проходной apaser за 2.5т.р. но лучше что то по быстрее с pci-e 4.0) на скорости 2гбайта/с (само собой есть быстрее) с соответствующими pci-e контроллерами обойдутся в считанные 16-25т.р., полученный 'монстр' будет считывать всю модель с 8битной квантизацией за 30-15 секунд, и уже вопрос, успеет ли процессор на такой скорости модель считать.

p.s. осторожно, ssd на 'чтение' тоже не бесплатно работает, это тоже изнашивает ресурс, только не так быстро как запись, может в тысячу раз медленнее, может в десятки тысяч.

Главный конкурент openai - Claude2 от anthropic, у них контекст порядка 100к токенов (но хуже chatgpt4, точнее там есть где превосходит, типа питон или математика)

Все остальное создано на основе api openai, и если тебе нужен какой то функционал, лучше использовать api

Эта операция доступна в интерфейсе в настройках самого канала (будет выдан список из контактов и всех пользователей, которые есть на каналах где ты есть)
Код телеграм открытый, модифицируешь его, добавляя свою логику, и автоматизируешь. Или просто кликер пишешь.

Точно помню, когда то давно, работал официальный консольный клиент tg, в нем автоматизация была почти из коробки, но сейчас кажется этот клиент не поддерживается

Еще есть telethon python, на сколько я знаю это самый поддерживаемы и функциональный api клиентской версии телеграм (а не тот официальный кастрированный что только для ботов), но не уверен что там этот функционал реализован

p.s. ты так надеешься собрать в свой канал первоначальную базу клиентов? или пыль в глаза глупым покупателям хочешь закинуть, показав 100500 подписчиков на твоем канале (а по факту это будут мертвые души).

Это так просто не работает. Ты потратишь время и нервы народонаселения, но результата скорее всего не дождешься или он будет минимальный.

чем тебе mega.io не устраивает?

любой торрент клиент и трекер + передавать magnet ссылки
p.s. если надо где то хранить файлы, то у siacoin есть какие то решения для этого, полностью децентрализованно но у обоих тогда должен быть клиент

крупнейших опенсорс со своим сервером и кучи кучи плюшек - это https://jitsi.org/projects/ там и чаты и видео с аудио и сервер и поддержка и опенсорс

Транспортный протокол - websocket и опционально webrtc (для передачи данных между клиентами, например файлы передать или аудио/видео звонок)
Шифрование сам выбирай, и это не питон а javascript клиентская сторона.

Отказоустойчивость это немного не про выбор протокола, а про организацию бакэнда в принципе. Плюс тестирование в различных ситуациях.
К примеру мобильные сети часто банят webrtc (вообще капризный протокол, так что предусмотри откат на классическую передачу через сервер) плюс борьба с nat, stun сервера и т.п.

Текстовый чат это очень простая задача, можно тупо посмотреть готовый на примерах для websocket и webrtc, все нюансы как раз вылезают когда начинаешь добавлять фичи.

Где то в 2007 году появилась технология long pooling (возможно и раньше, но название получила именно тогда).
На бакэнде есть скрипт, который не возвращает (находится в режиме ожидания, т.е. sleep) данных пока не понадобится отправить на клиент сообщение.

В это же время как такового ajax не было (xhtmlrequest появился какраз в 2007г), и чтобы получить данные с сервера проще всего было сгенерировать javascipt константы инициализации этих данных, переданные в функцию, являющуюся колбеком на их получение. Соответственно чтобы запустить ожидание сообщения на клиенте нужно подключить скрипт с соответствующим url в теге script.

Чтобы длинное подключение не закрылось, long poling во время ожидания периодически должен отсылать какие-нибудь данные, например пробел раз в минуту.

в итоге бакэнд формирует с паузой и возвращает скрипт типа:

................................
messageReceived({user:'vasya',message:'Hi!'});

p.s. мелкие чаты не брезговали периодическими апдейтами, на таймере, я видел локальный чат, который список сообщений представлялся в виде html внутри iframe, в котором в meta refresh было прописано обновляться раз в 5 секунд

Ты можешь изменить интерфейс, наложить ограничения, добавить где то автоматизацию, но не можешь изменить логику регистрации (нужен телефон).

По факту клиент телеграм это очень тонкий клиент, запутанно написанный но все же тонкий клиент, где на каждый чих идет запрос на сервер, и сервер держит сессии, следит за тем какие сообщения прочитаны и наличие новых и т.п. Т.е. можно менять в исходниках только логику отображения.

может поискать программные решения - ремап поведения кнопок?

кнопки блютус устройств обычно это системные кнопки так будто это обычная клавиатура, а значит их можно отловить и переназначить.

гуглить android key remap

попробуйте https://play.google.com/store/apps/details?id=io.g...

Если это позволяет бизнес — лучше поэтапное заполнение… с постепенным раскрытием функционала по мере заполнения профайла (об этом нужно будет твердить на 'каждом углу' интерфейса).

Полным функционалом почти наверняка будет пользоваться минимальное количество пользователей, но из-за этого требовать заполнение 'лишних' полей ВСЕХ пользователей как минимум некрасиво.

freenet + frost = распределенная децентрализованная сеть хранения данных (сайты, форумы, блоги — статика) + мессадженер вида nntp/email на ее основе. Заточено на секурность и анонимность (уровня выше tor и анонимные прокси).

Немного тормозной, в начале пару гигов выкачает и 512мб на диске под базу выжрет (минимум), java (кросплатформенно), немного устаревший интерфейс но юзабельно и со своими задачами справляется.

PHP не очень пригоден (точнее не предполагает подобного использования, но формально ничто этому не мешает) для использования как постоянно запущенной службы, вместо режима частых и коротких запусков

Соответственно, можно использовать асинхронные сокеты (см. socket_set_nonblock и socket_set_option, первый же пример в гугле) в php и серверную часть запускать в виде одного процесса (со всеми вытекающими проблемами из-за потенциальных багов в коде, точнее прервутся все соединения, если упадет это приложение), либо на каждое соединение запускать по процессу, с обычными сокетами, но тогда добро пожаловать в мир semaphore и shared memory (конечно, можно и без них, используя типичный LAMP подход, когда за синхронизацию отвечает БД с транзакциями, но производительность будет ужасная и вас засмеют за говнокод).

p.s. Сильно не копал, возможно есть куча готовых фреймворков или даже расширений PHP, добавляющих событийный функционал.