И работает и есть проблемы. Не все модели будут корректно работать если купите самый дорогой mac studio. Оставлю это https://github.com/pytorch/pytorch/issues/141287 - некоторые модели и в том числе для дообучения - будут работать через процессор, что вызывает печаль. Не стал бы на данный момент инвестировать в яблоки, если цель запускать модели и остальные вещи связанные с ML
Считаю статью неполной т.к. нет отдельного пункта про "нескучные обои". Требую на уровне законодательства ввести обязательное требование обозревать обои во всех новых дистрибутивах!
Во многих статьях под словом "домены" - чаще всего подразумевали другие языки, в рамках вашей статьи насколько понял, используется только русский язык, а домены - это наборы данных разного качества и содержимого.
Еще хотел уточнить, делали ли вы гибридную модель, где есть 2 головы - CTC (на быстрое распознавание) и RNNT (на более точное) и как такую модель используете в своих проектах?
И на вопрос, который вы обычно не отвечаете на своих докладах и выступления, ну или говорите фразу типа "бесплатного google colab для этого не хватит" - так все таки, сколько времени и на каких мощностях вы обучили модель которую выложили и с какой попытки получилось? Спасибо.
О, интересно. А можно подушнить? Пишу по факту, давно брали компанией у вас достаточно много серверов и пару штук были глючные, настолько что при после установки дистрибутива были проблемы во время работы - конечно винил только свои кривые руки, а не сервер или неисправный процессор, что также сообщала ваша техническая поддержка, потеряв пару дней, нам заменили сервер и компенсировали 2 дня для данных серверов. С тех пор приходится быть с провайдером связи очень прямолинейным - не работает железка, просто возьмите и замените, зачем мне терять время, которое мне никто не компенсирует. Надеюсь с новыми серверами в случае глюков, вы не заставляете клиентов проводить дебаг за свой счет. Спасибо.
Интересно, а админы clickhouse знают что вы вставляете в distributed table? Помню на старой работе такое не приветствовалось т.к. кластер зукипера чувствовал себя не очень при таких нагрузках?
Странно, почему так мало причин по уходу постгреса в кубернетесь на bare metal или укажите по ресурсам в кубере и какие железяки стали целевыми. Графики по latency до и после будут?
Это получается rsync в кроне. Проверяли ли состояние гонки, когда большой файл не успевает провести синхронизацию за интервал задания? Где система хранит индексы и как справится с условным миллиардом мелких файликов? Думаю что делали тесты и знаете какие есть ограничения.
Господа. Когда делал тесты и решил попробовать ваш дистрибутив SelectOS, то по неизвестной мне причине postgresql и clickhouse показал худший результат по сравнению с Debian11 и Ubuntu22. Может, если выпустили свой дистрибутив сделайте сравнение с другими - будет интересно.
Я, Алексей и пару лет компания отказалась от "Редис как сервис" в облаке cloud.ru на платформе huawei. Вопрос, починили ли ваши китайские коллеги поведение, когда гигабитный порт в редисе при использовании master-replica не совсем гигабитный, а пополам?
Что я имею ввиду - купили редис как сервис на довольно хороших ресурсах 16 cpu 64 gb ram и жили не тужили, тут раз нагрузка - резко увеличилась задержка с стороны приложений. Смотрим на процессоры, утилизируется всего 4, смотрим на память, еще половина свободна, сеть - всего половина утилизировано - около 400 мбит из 1 гбит. Писали тикет, в двери хлопали - "облако" проблем не обнаружило, проблема где то с стороны вашего приложения.....
Предположил, что возможно облако биллингует редис по полной т.е. трафик от мастера к реплике также входит в этот же гигабит. Быстро поднял редис в кубере - переключил - трафик стал 540 мбит до редис и задержки очень уменьшились - ну а редис как сервис решили похоронить и не использовать впредь.
Лень было искать ссылку. Не все так плохо, можно было описать более ёмко "Взаимосвязь жизненных циклов ПО". Удачи в развитии cozystack, фиксируем тот факт, что пока вы не будете делать форк кубера для своих задач, ждем! :-)
Сколько раз уже было, что Google выводило сервисы из обслуживания...
Теперь из обслуживания в случае использования сервисов поверх kubernetes будет выводить сообщество - мы все знаем как в кубе депрекейтят и заносят новые абстракции и абстракции сверху других абстракций. Каким образом это будет работать в cozystack, будет интересно посмотреть и обновления платформы и поддержка обратной совместимости, которая будет выпилена из куба, но вам что то придется оставить или будет свой форк кубера (это вопрос времени, ждём).
Статья из серии "Много языков программирования, придумаю свой - самый лучший...."
Хорошая статья. Жду обзор-разбор как вы боролись с утечками памяти на стороне выполняемого runtime (containerd,runc и др) - будет интересно посмотреть, как в kubevirt получается поднимать толстые машины по ресурсам и по дискам и как накладные расходы становятся еще больше при увеличении сетевого трафика и как тюнить разные компоненты системы, чтобы солянка работала более корректно и ожидаем.
Вариант № 6 - поставить рядом с pod еще один sidecar контейнер, скрейпить данные и пулить данные в victoriametrics или clickhouse и не зависеть от инфраструктурного мониторинга.
И работает и есть проблемы. Не все модели будут корректно работать если купите самый дорогой mac studio. Оставлю это https://github.com/pytorch/pytorch/issues/141287 - некоторые модели и в том числе для дообучения - будут работать через процессор, что вызывает печаль. Не стал бы на данный момент инвестировать в яблоки, если цель запускать модели и остальные вещи связанные с ML
Считаю статью неполной т.к. нет отдельного пункта про "нескучные обои". Требую на уровне законодательства ввести обязательное требование обозревать обои во всех новых дистрибутивах!
Во многих статьях под словом "домены" - чаще всего подразумевали другие языки, в рамках вашей статьи насколько понял, используется только русский язык, а домены - это наборы данных разного качества и содержимого.
Еще хотел уточнить, делали ли вы гибридную модель, где есть 2 головы - CTC (на быстрое распознавание) и RNNT (на более точное) и как такую модель используете в своих проектах?
И на вопрос, который вы обычно не отвечаете на своих докладах и выступления, ну или говорите фразу типа "бесплатного google colab для этого не хватит" - так все таки, сколько времени и на каких мощностях вы обучили модель которую выложили и с какой попытки получилось? Спасибо.
О, интересно. А можно подушнить? Пишу по факту, давно брали компанией у вас достаточно много серверов и пару штук были глючные, настолько что при после установки дистрибутива были проблемы во время работы - конечно винил только свои кривые руки, а не сервер или неисправный процессор, что также сообщала ваша техническая поддержка, потеряв пару дней, нам заменили сервер и компенсировали 2 дня для данных серверов. С тех пор приходится быть с провайдером связи очень прямолинейным - не работает железка, просто возьмите и замените, зачем мне терять время, которое мне никто не компенсирует. Надеюсь с новыми серверами в случае глюков, вы не заставляете клиентов проводить дебаг за свой счет. Спасибо.
Жизненный цикл ПО у AMD короче в 2 раза чем у NVIDIA - эта ситуация многим надоела.
В это время nvidia поддерживает свои старые карты 9-10 лет, а тут amd дала подарок и стала на карты 4х летней давности "продлила" поддержку...
Нужно больше статей про контейнеры..... Но пока лучшая https://habr.com/ru/articles/935178/
Возможно люди просто не желают читать контент сгенерированный нейросетью....
Все описано в доке https://clickhouse.com/docs/ru/guides/sre/keeper/clickhouse-keeper
Акцент на линейность чтения и записи и конечно по ресурсам кипер в отношении памяти менее прожорлив в отличие от zookeeper.
По статье - надеюсь тут говорится про тестовый стенд, а не реализацию в production.
Интересно, а админы clickhouse знают что вы вставляете в distributed table? Помню на старой работе такое не приветствовалось т.к. кластер зукипера чувствовал себя не очень при таких нагрузках?
Странно, почему так мало причин по уходу постгреса в кубернетесь на bare metal или укажите по ресурсам в кубере и какие железяки стали целевыми. Графики по latency до и после будут?
Это получается rsync в кроне. Проверяли ли состояние гонки, когда большой файл не успевает провести синхронизацию за интервал задания? Где система хранит индексы и как справится с условным миллиардом мелких файликов? Думаю что делали тесты и знаете какие есть ограничения.
Отдохните и пишите достойные технические интересные статьи. Удачи!
Господа. Когда делал тесты и решил попробовать ваш дистрибутив SelectOS, то по неизвестной мне причине postgresql и clickhouse показал худший результат по сравнению с Debian11 и Ubuntu22. Может, если выпустили свой дистрибутив сделайте сравнение с другими - будет интересно.
Я, Алексей и пару лет компания отказалась от "Редис как сервис" в облаке cloud.ru на платформе huawei. Вопрос, починили ли ваши китайские коллеги поведение, когда гигабитный порт в редисе при использовании master-replica не совсем гигабитный, а пополам?
Что я имею ввиду - купили редис как сервис на довольно хороших ресурсах 16 cpu 64 gb ram и жили не тужили, тут раз нагрузка - резко увеличилась задержка с стороны приложений. Смотрим на процессоры, утилизируется всего 4, смотрим на память, еще половина свободна, сеть - всего половина утилизировано - около 400 мбит из 1 гбит. Писали тикет, в двери хлопали - "облако" проблем не обнаружило, проблема где то с стороны вашего приложения.....
Предположил, что возможно облако биллингует редис по полной т.е. трафик от мастера к реплике также входит в этот же гигабит. Быстро поднял редис в кубере - переключил - трафик стал 540 мбит до редис и задержки очень уменьшились - ну а редис как сервис решили похоронить и не использовать впредь.
Лень было искать ссылку. Не все так плохо, можно было описать более ёмко "Взаимосвязь жизненных циклов ПО". Удачи в развитии cozystack, фиксируем тот факт, что пока вы не будете делать форк кубера для своих задач, ждем! :-)
Теперь из обслуживания в случае использования сервисов поверх kubernetes будет выводить сообщество - мы все знаем как в кубе депрекейтят и заносят новые абстракции и абстракции сверху других абстракций. Каким образом это будет работать в cozystack, будет интересно посмотреть и обновления платформы и поддержка обратной совместимости, которая будет выпилена из куба, но вам что то придется оставить или будет свой форк кубера (это вопрос времени, ждём).
Статья из серии "Много языков программирования, придумаю свой - самый лучший...."
Хорошая статья. Жду обзор-разбор как вы боролись с утечками памяти на стороне выполняемого runtime (containerd,runc и др) - будет интересно посмотреть, как в kubevirt получается поднимать толстые машины по ресурсам и по дискам и как накладные расходы становятся еще больше при увеличении сетевого трафика и как тюнить разные компоненты системы, чтобы солянка работала более корректно и ожидаем.
Вариант № 6 - поставить рядом с pod еще один sidecar контейнер, скрейпить данные и пулить данные в victoriametrics или clickhouse и не зависеть от инфраструктурного мониторинга.
Зачем?