rPman

Llama31-8b можно запустить на видеокарте nvidia 12..16gb с отличной скоростью, контекстное окно 128к токенов, характер и прочее можешь описать в стартовом промпте. На cpu так же работает с помощью llama.cpp.

Такую сеть можно за разумные деньги тюнить под свои задачи.

Есть ещё китайская qwen, у нее неплохие характеристики.

Старшие версии llama31-70b и qwen близки а топу, но требуют много оперативной памяти, с использованием квантизации 64..96гб ram на скорости 1-2 токена в секунду можно решить сложные интеллектуальные задачи, например адекватно допридумывать рассказы...

Настоятельно рекомендую нести диск на восстановление, но шансов у вас мало.

Основной рабочий пока первый, с 7кой.
...
После этого ребутнулся в 10ю винду и запустил проверку первого диска.

Об этом моменте все забывают, что в windows 10 (начиная с win8) есть механизм ускорения загрузки, который при использовании последовательно нескольких ОС может угробить ваши данные (полагаю это сделано специально, как одна из миллиона мер борьбы с linux конкуренцией, иначе об этом бы везде писали большими буквами). Принцип следующий - windows 10 при выключении, закрывает рабочие приложения (делает быстрый logout) а затем вызывает гибернацию (hibernation), сброс оперативной памяти и состояния устройств (включая gpu) на диск в файл hiberfil.sys в корне диска, т.е. не завершая процессы, не закрывая файлы, не сбрасывая кеши записи на диски и кучу всего, что могло бы замедлить этот процесс... при включении, данные очень быстро и эффективно считываются с диска (линейная скорость даже медленных дисков hdd - сотня мбайт/с), включение занимает считанные десяток секунд, после чего идет login и запуск процессов пользователя.

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

Но вот винда ругнулась на этот диск и я решил его проверить. Забекапил что нужно и на 2й и на 3й диски.

Что это была за ругань, сообщение в подробностях скорее всего раскроет подробно, что случилось.

p.s.

эту фичу зовут Fast Startup (включена в win10 и 11 по умолчанию) можно не выключать всю гибернацию, а вручную выключать компьютер в правильном режиме:
shutdown -s -t 0

отключается в Панели управления, электропитание, действия кнопок питания, изменение параметров которые сейчас недоступны, выключить быстрый запуск.
либо отключить гибернацию полностью, выполнив в командной строке:
powercfg /h off

Удостоверься что смартфон действительно подключился к локальной сети, а не к примеру, гостевой на роутере. Посмотри его ip адрес в подключении wifi, попингуй в обе стороны (комп -> смартфон и наоборот).

Удостоверься что на смартфоне не включен vpn или не используется прокси (например ускорялки от гугла и опера).

Удостоверься, что ты указал правильный протокол (http но не https), так как браузера могут автоматически выбирать https.

Любые прослойки, включая многоуровневые - это значительные затраты на процессор... Нужно четко понимать, за что ты платишь эту цену.

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

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

p.s. Один раз получив серьезную нагрузку и попробовав bare metall железо без даже lxc/docker , назад возвращаться не захочешь.

Напоминаю, наилучшая производительность современных (уже лет 10 как) процессоров достигается только при попадании необходимых данных и кода в кеш процессора, причем если это не так, то производительность падает на порядок буквально (в 10 раз)... когда на одном железе мешаешь разные сервисы, они делят один процессор и его кеш,.. .. База данных может дать основную нагрузку на процессор, поэтому и выделить в этом случае для нее отдельное железо... даже если это не топовый процессор, правда точный ответ может дать только эксперименты на реальных данных и типовых ситуациях.

Очень жаль что датацентры не практикуют 'узкие лезвия' (очень компактные небольшие сервера, размером с ладонь), из-за чего из стоимость на столько неадекватна, что эффективнее собирать неэффективные конфигурации

имена переменных бери из строки:

const connectionString = `postgresql://${process.env.POSTGRES_USER}:${process.env.POSTGRES_PASSWORD}@${process.env.POSTGRES_HOST}:${process.env.POSTGRES_PORT}/${database}`;

Хост у тебя судя по скрину - localhost, в крайнем случае используй то что возвращает консоль по команде hostname

чтобы понять что происходит, назначение ключей psql смотри в документации или по команде psql --help
p.s. смотри внимательно сообщение об ошибке
в особо извращенных случаях сервер может быть не локальным, а его адрес прописан у пользователя в домашнем каталоге в .pgpass или pg_service.conf

syncting или rsync (если подойдет ручное управление) и git (не смешивая их).

syncting хорошо работает с большими данными и любыми схемами передачи данных (вплоть до источник -> смартфон пользователя offline, смартфон -> целевая машина, и так же обратно, т.е. без интернета)

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

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

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

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

Кстати, собственно сбор оперативных данных не обязательно делать в ОДНОЙ физической базе, это могут быть разные БД, а вот последующий анализ уже делать следующим сервисом (так же может быть несколько нод), собирающим данные из разных первичных источников в какой то единый или еще в какой то форме... именно подготовка данных к последующему их использованию и есть вопрос реализации.

Настоятельно не советую городить зоопарк из разных баз данных типа редис и sql-db.. когда sql база используется без индексов (и тем более без транзакций) на последовательную запись у нее нет конкурентов (ну только что совсем низкоуровневым программированием заняться)

https://huggingface.co/models?other=speaker-recognition как отправная точка для поиска готовых моделей (можно поиграть с поисковым запросом)

Да, уже считал, и это действительно реально, с относительно небольшими затратами (16-20т.р.) если тебя устроит скорость исполнения в 15-30 секунд на токен (на твоем железе llama31-70b на процессоре и 64гб оперативке будет работать токен в 1-1.5 секунд).

Необходимо собрать самый дешевый pcie nvme ssd программный raid0, купив контроллер pcie-x16 3.0 или 4.0 из четырех разъемов nvme либо четыре pcie-4x дешевых 3.0 и закупить самые дешевые nvme ssd диски от 128гб (со скоростями чтения от 2гбайт/сек).

Затем собрать из них raid0 с чередованием (win/linux это поддерживают) и разместить на нем gguf файл. llama.cpp поддерживает загрузку файла с весами с диска, без выделения оперативной памяти (но она нужна на контекстное окно, в зависимости от его размера это будут десятки гигабайт). Файл будет считываться по кругу целиком, по разу на токен, а значит скорость будет определяться именно этим. 2гб/с*4 диска = 8гб/с, 256гб 4бит квантизация будет считываться за 32 секунды.

Есть еще ограничения в скорости исполнения из-за процессора, но по уму, если бы была оперативная память то типовой десктопный процессор работал бы на скорости 15-20 секунд на токен.