Очень странные претензии, и не менее странные хотелки.
Под ваш велосипед софт собирать будет два землекопа. Разве не лучше иметь возможность использовать обширную пакетную базу того же дебиан/рхел/альпайн..
А/Б и readonly вполне реализованы в rpi, почти без велосипедов
Recall есть только на snapdragon винде. Ну и в целом функция бесполезна, безотносительно вопросов безопасности. Как и в целом, все встроенные в винду ai приколы помимо шумодава и улучшайзеров для вебки.
Да, тут.. преимущества от масштабирования разбиваются об ollama. Да и если использовать облачные решения, узким местом будет не производительность вашего сервиса, а скорость генерации облака. Собственно по этой причине мне кажется что микросервисы тут являются переусложнением.
Мне eino не особо понравился, просто потому что он куда сложнее налезает на голову. Плюс он использует нативный tool call от ollama, а не парсит ответы модели как это делает langchaingo. Это еще больше уменьшает пул моделей которые можно использовать
Из статьи не понял какой сервис за что отвечает и в чем практическая польза от размазывания такого приложения на отдельные микросервисы.
Хочется сказать что помимо langchaingo есть еще eino. Который как будто бы более серьезный, но с своими нюансами. Также хочется заметить что в этой задаче весьма удобно отделять rag часть в MCP модуль, представляющий из себя отдельный сервис.
Я ваял rag приложение -ассистента для ответов с учетом данных в базе знаний confluence, самое печальное что ембеддинг моделей с большим контекстом, которые могут в русский прям не густо. Да и в целом gguf варианты моделей, у ml энтузиастов как то не особо популярны.
В текущем виде mcp это баловство. Ставить питон, node и возиться с конфигом для подключения.. Плюс все это еще может быть несовместимо между собой, потому лучше все это в докер, а у юзера винда. Значит что докер в wsl а он тормозной..
В общем, жизнеспособны только mcp не требующие установки каких то зависимостей. Работающие на винде и мак, и настраивающие "подключение" к условному claude desktop самостоятельно (не ломая то что уже настроено).
Интересно, эта игрушка сможет вырубить уведомления от "центра безопасности"?
А если серьезно, то практическая польза от npu пока отсутствует. Qnn runtime работает не адекватно, постоянно создаёт нагрузку даже если ничего не генерирует. Qnn моделей кот наплакал.
Спасибо, как раз думаю над рефакторингом мониторинга.
В пару к прометею стоит добавить мимир, это позволит хранить данные в s3, возможно даже от самого прометея можно отказаться если коллектор может пушить метрики в пром. Также можно использовать mimir alertmanager что позволит рулить алертами через графану.
Еще за забором остался момент про организацию сервис-дискавери, который позволяет не трогать конфигурацию прометея при добавлении нод (не актуально если можно избавиться от прометея )
Рабочие данные по хорошему не должны покидать зону ответственности работодателя. Тащить что-то домой на чвою тачку чтобы это переварить, ну как минимум странно.
Поражаюсь с людей которые хранят три бекапа "домашних данных". Но не могу понять причем тут отвал канала до облака. Как отвалился так восстановится. Когда восстановится тогда и зальется.
Мне кажется что бекапить бекапы это несколько избыточно... думаю что если уже поставил NAS то его и использовать, а если нет то варианты с облаками вполне себе имеют право на жизнь.
PS. история про то как можно неудачно попытаться заменить диски в sinology у меня тоже есть. Процесс все же немного шире чем просто купить и поставить.
Однажды родственники попали на то что один из дисков собранных в raid0 (в купленном ими NAS) сдох. Собственно это привело к необходимости обращаться к специалистам по восстановлению. Так что ситуация знакома, и наглядно показывает что мало иметь NAS, его нужно уметь готовить и иметь того кто готов подпрыгивать для своевременной замены дисков.
Я склонен считать что хранение данных в S3 Glacier надежнее, не говоря о том что это удовольствие весьма доступно. При этом отпадает необходимость думать про железо, чего не сказать про софт.
Обслуживание на прямую зависит от ценности вашего времени.
Куча экспериментов интересны только тем кто еще не наигрался.
В целом не вижу смысла держать нечто под названием "домашний сервер", интернет позволяет доставать все достаточно быстро чтобы не держать это локально, а vps стоит достаточно дешего.
Если что, mcp не обязан работать локально, и вполне седе есть серверы доступ к котором происходит через сеть.
Вообще mcp это шикарная штука позволяющая отделить "инструменты" от mcp хоста и переиспользовать серверы. Собственно появление множества mcp серверов скорее всего связано и с тем что код инструментов давно уже готов, нужно было просто обернуть его в mcp обертку.
Очень странные претензии, и не менее странные хотелки.
Под ваш велосипед софт собирать будет два землекопа. Разве не лучше иметь возможность использовать обширную пакетную базу того же дебиан/рхел/альпайн..
А/Б и readonly вполне реализованы в rpi, почти без велосипедов
После radxa zero, такие кирпичики называть nano, прям как то странно.
Было бы интересно почитать сравнение langchaingo vs eino.
Просто а настройках выключается, без танцев с бубном
Recall есть только на snapdragon винде. Ну и в целом функция бесполезна, безотносительно вопросов безопасности. Как и в целом, все встроенные в винду ai приколы помимо шумодава и улучшайзеров для вебки.
Да, тут.. преимущества от масштабирования разбиваются об ollama. Да и если использовать облачные решения, узким местом будет не производительность вашего сервиса, а скорость генерации облака. Собственно по этой причине мне кажется что микросервисы тут являются переусложнением.
Мне eino не особо понравился, просто потому что он куда сложнее налезает на голову. Плюс он использует нативный tool call от ollama, а не парсит ответы модели как это делает langchaingo. Это еще больше уменьшает пул моделей которые можно использовать
Из статьи не понял какой сервис за что отвечает и в чем практическая польза от размазывания такого приложения на отдельные микросервисы.
Хочется сказать что помимо langchaingo есть еще eino. Который как будто бы более серьезный, но с своими нюансами. Также хочется заметить что в этой задаче весьма удобно отделять rag часть в MCP модуль, представляющий из себя отдельный сервис.
Я ваял rag приложение -ассистента для ответов с учетом данных в базе знаний confluence, самое печальное что ембеддинг моделей с большим контекстом, которые могут в русский прям не густо. Да и в целом gguf варианты моделей, у ml энтузиастов как то не особо популярны.
В текущем виде mcp это баловство. Ставить питон, node и возиться с конфигом для подключения.. Плюс все это еще может быть несовместимо между собой, потому лучше все это в докер, а у юзера винда. Значит что докер в wsl а он тормозной..
В общем, жизнеспособны только mcp не требующие установки каких то зависимостей. Работающие на винде и мак, и настраивающие "подключение" к условному claude desktop самостоятельно (не ломая то что уже настроено).
Конечно. Диски тоже могут отказывать внезапно, не объясняя причин, просто потому что. И это не зависит от бренда или места их установки.
Можно патриотично поддерживать отечественные решения, а в случае чего можно будет даже заявление написать.
Если бы умел, то вероятно рантайм от Qualcomm не использовался бы. В любом случае, я пока не вижу чтобы девайсы с npu обладали каким то преимуществом.
Интересно, эта игрушка сможет вырубить уведомления от "центра безопасности"?
А если серьезно, то практическая польза от npu пока отсутствует. Qnn runtime работает не адекватно, постоянно создаёт нагрузку даже если ничего не генерирует. Qnn моделей кот наплакал.
Спасибо, как раз думаю над рефакторингом мониторинга.
В пару к прометею стоит добавить мимир, это позволит хранить данные в s3, возможно даже от самого прометея можно отказаться если коллектор может пушить метрики в пром. Также можно использовать mimir alertmanager что позволит рулить алертами через графану.
Еще за забором остался момент про организацию сервис-дискавери, который позволяет не трогать конфигурацию прометея при добавлении нод (не актуально если можно избавиться от прометея )
Рабочие данные по хорошему не должны покидать зону ответственности работодателя. Тащить что-то домой на чвою тачку чтобы это переварить, ну как минимум странно.
Поражаюсь с людей которые хранят три бекапа "домашних данных". Но не могу понять причем тут отвал канала до облака. Как отвалился так восстановится. Когда восстановится тогда и зальется.
Мне кажется что бекапить бекапы это несколько избыточно... думаю что если уже поставил NAS то его и использовать, а если нет то варианты с облаками вполне себе имеют право на жизнь.
PS. история про то как можно неудачно попытаться заменить диски в sinology у меня тоже есть. Процесс все же немного шире чем просто купить и поставить.
специально сходил и посмотрел цены на извлечение. 0.02$ за гб из deep archive. И то если не использовать пакетное извлечение (0,0025 $ за гб).
Я конечно могу представить как можно накрутить такую сумму, но это надо постараться
Однажды родственники попали на то что один из дисков собранных в raid0 (в купленном ими NAS) сдох. Собственно это привело к необходимости обращаться к специалистам по восстановлению. Так что ситуация знакома, и наглядно показывает что мало иметь NAS, его нужно уметь готовить и иметь того кто готов подпрыгивать для своевременной замены дисков.
Я склонен считать что хранение данных в S3 Glacier надежнее, не говоря о том что это удовольствие весьма доступно. При этом отпадает необходимость думать про железо, чего не сказать про софт.
Обслуживание на прямую зависит от ценности вашего времени.
Куча экспериментов интересны только тем кто еще не наигрался.
В целом не вижу смысла держать нечто под названием "домашний сервер", интернет позволяет доставать все достаточно быстро чтобы не держать это локально, а vps стоит достаточно дешего.
Если что, mcp не обязан работать локально, и вполне седе есть серверы доступ к котором происходит через сеть.
Вообще mcp это шикарная штука позволяющая отделить "инструменты" от mcp хоста и переиспользовать серверы. Собственно появление множества mcp серверов скорее всего связано и с тем что код инструментов давно уже готов, нужно было просто обернуть его в mcp обертку.