Цена на ядра: AMD конечно топ когда тебе нужно дохренища ядер, а с микросервисами это ой как вкусно выглядит.
Но с ценами на AMD сервера в РФ грустно.
Когда у тебя приложения много поточные (phpfpm), но тебе больше важна средняя скорость ответа сайтика за 140, а не 200ms - тут конечно вперает только частота, 3.2-3.6Ghz 24 ядра по отклику на графиках понравятся отделу (QA или кто там) намного сильнее чем 2600 128 ядер "с запасом", но откликом увеличившимся до 250
Но даже если забить на 100ms, допустим у вас не так всё строго и все в адеквате, то слезая с Intel на amd можно словить кучу тупых (именно тупых) проблем на которые придётся потрать не один инженеро-час и забить в архитектуру ни один костыль что бы это заработало.
Как пример: Проект с 6 серверами intel, "А давайте в кластер добавим сервер на AMD"
Посмотрели с умными мордами на ресурсы и цену, всё норм, согласовали с клиентом что "Чел, вроде всё норм но ты должен понимать что это эксперемент и возможны side эффекты.". Пошло в дело.
Через неделю клиент жалуется что часть приложений рандомно падают. Опять же с умными мордами посмотрели в логи, увидели segfault/coredumped и отправили клиента дебажить без задней мысли. Приложение компилируемое - разбирайтесь.
Через пару дней страданий клиент приходит, ну нет бага, но вот заметили что на нодах (как позже выяснилось с intel) приложение работает, а вот на этих (с amd) падает. В мистику не поверили, пошли ковырять как так.
Оказалось что приложенька собираясь тянула python Зависимости (python cgold или какая то такая хрень, сори не вспомню точно) и получалось что автор её в флагах компиляции соптимизировал компиляцию под AVX512 который на сборщике был. Который был на 5 нодах с Intel где это работало, а на сервере amd avx512 нет и на, жуй segfault с трейсом ядра в котором где то в *опе написано про инструкцию которой нет и конечно никто не посмотрел