rPman

Удостоверься что смартфон действительно подключился к локальной сети, а не к примеру, гостевой на роутере. Посмотри его 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 секунд на токен.

Скачай майкрософтовский sysinternals autoruns и вдумчиво изучи все что там прописано в автозагрузку. Так же изучи все задачи в task scheduler (в пуск - служебные) там много майкрософтовской телеметрии но чужие видно сразу.