On-prem инфраструктура для скоринга и антифрода: что важнее в железе

Задержка и качество моделей: где упирается железо

Скоринг и антифрод почти всегда работают в режиме «ответь сейчас». Нужно не просто посчитать вероятность, а успеть: принять запрос, собрать фичи, выполнить инференс, применить правила, вернуть решение и записать событие в лог.

Главная ловушка - смотреть только на среднюю задержку. Пользователя и бизнес бьет хвост распределения: p95 и особенно p99. Если p99 скачет, появляются редкие, но заметные «зависания»: платеж не проходит, клиент звонит в колл-центр, включается лишняя проверка или падает конверсия.

Железо влияет не только на миллисекунды, но и на качество решений. Когда инфраструктура перегружена, сервисы начинают «резать углы»: фичи приходят с таймаутами, берутся устаревшие значения из кэша, часть источников недоступна. Модель формально та же, но входные данные хуже - растут ошибки и плывут метрики. Важна и воспроизводимость: одинаковый запрос при одинаковых данных должен давать одинаковый результат, без случайных отклонений из-за плавающих таймаутов и нагрузки.

Обычно узкие места повторяются:

• CPU - не хватает частоты на один поток или начинается конкуренция за ядра в пике.
• RAM и кэши - промахи в кэше, сборщик мусора, страничные ошибки.
• Сеть - лишние переходы между сервисами, перегруженные интерфейсы, задержки до хранилищ фич.
• Диск - медленный доступ к фичам, очереди на запись логов, неудачная конфигурация NVMe.

До закупки стоит договориться с бизнесом о простых вещах: какой целевой SLA по p95 и p99, какой максимальный RPS в пике, что делать при деградации (отказать, упростить проверку, перейти на запасную модель), и какие данные обязательны для решения. Эти ответы задают бюджет задержек и подсказывают, где on-prem-инфраструктура для скоринга и антифрода должна быть сильнее всего.

Соберите бюджет задержек по шагам

Пока скоринг не разложен на этапы, спор про CPU, RAM и NVMe идет «вслепую». На on-prem это особенно заметно: проще один раз собрать бюджет задержек и закрепить его как контракт - что должно укладываться в p50, p95 и p99 при реальной нагрузке.

Возьмите цепочку одного запроса и измеряйте шаги по отдельности. Обычно это:

• вход и разбор запроса (API, сериализация, валидация)
• получение фич (кэш, БД, key-value, очереди)
• инференс (подготовка признаков, вызов рантайма)
• правила и постобработка (пороги, explain, объединение с бизнес-логикой)
• логирование и аудит (синхронно или асинхронно)

Дальше задайте цели не только по «среднему», а по хвостам. p50 отвечает за ощущение скорости, p95 - за стабильность, p99 - за реальную боль пользователей и потери в антифроде. Обязательно добавьте профиль нагрузки: средний RPS, пик и характер всплесков (например, 3-5 минут с 5x трафиком).

Отдельно учитывайте внешние источники данных. Любой поход во внешний сервис, бюро, процессинг или даже «соседнюю» систему делает p99 менее предсказуемым. Уже на пилоте фиксируйте поведение при деградации: кэшируете, режете фичи, снижаете точность или уходите в фолбэк на правила.

Заранее договоритесь, что считается отказом: таймаут (например, 50-100 мс на весь скоринг), превышение p99, рост доли фолбэков или пропуск логирования. И определите метрики пилота: распределение задержек по этапам, RPS при заданном p99, долю таймаутов, очереди, загрузку CPU и память, а также время ответа фичестора.

CPU для инференса: частота, ядра и NUMA

Для скоринга и антифрода важнее стабильная низкая задержка, чем рекордная суммарная производительность. Поэтому часто выигрывает CPU с высокой частотой на ядро и современной архитектурой: один запрос инференса обычно идет по цепочке операций, где важнее ускорять один поток, а не «все ядра сразу».

Больше ядер становится критично, когда запросов много одновременно, на одном узле живет несколько моделей или вместе с моделью работают правила, обогащение фич и валидации. Но есть цена: при высокой конкуренции растут очереди и переключения задач, и p99 уезжает.

NUMA простыми словами

На двухпроцессорных серверах память «ближе» к своему процессору. Если процесс крутится на CPU0, а память выделена на «чужой» половине, доступ к RAM медленнее, и задержка начинает прыгать. Обычно это хорошо видно на p95-p99.

Практичное правило для пилота: один сервис инференса - один NUMA-узел (и его память). Либо четко разделяйте модели по узлам. На on-prem это нередко дает больший эффект, чем покупка CPU с большим числом ядер.

Энергосбережение, turbo и стабильность

Режимы энергосбережения и агрессивный turbo могут улучшить средние цифры, но ухудшить стабильность. Под нагрузкой возможны троттлинг и «пила» частоты, из-за чего плывет время ответа.

На пилотном стенде проверьте:

• загрузку по ядрам (нет ли одного «забитого» ядра при простое остальных)
• контекстные переключения (всплеск часто означает конкуренцию потоков или слишком много процессов)
• частоту и троттлинг (держится ли частота ровно на длительном прогоне)
• NUMA-локальность (не уезжает ли память в удаленный узел)
• p95 и p99 (сравните до и после привязки по CPU и памяти)

Если антифрод-сервис на двухсокетном сервере иногда «прыгает» с 8 мс до 25 мс, сначала проверьте NUMA-привязку и частоту под длительной нагрузкой. И только потом решайте, нужно ли добавлять ядра.

RAM и кэш: то, что часто недооценивают

В on-prem-инфраструктуре для скоринга и антифрода RAM часто решает больше, чем кажется. Когда памяти «впритык», система долго выглядит нормальной, а затем ловит редкие, но очень длинные задержки. Это и есть хвост p99: сборщик мусора, переполнение очередей, выделение больших буферов, подгрузка страниц с диска.

Кэш CPU и локальность данных важны потому, что модели и фичи читаются много раз и маленькими кусками. Если фичи разложены так, что процессор постоянно ходит в RAM вместо L3, время инференса растет и становится менее предсказуемым. То же происходит, когда вы тянете «широкие» фичи из разных структур, делаете много мелких обращений и часто создаете новые объекты.

Скорость памяти и число каналов заметны, когда инференс упирается в пропускную способность RAM: много параллельных запросов, большие вектора фичей, несколько моделей одновременно. В таких режимах память становится узким местом даже при сильном CPU.

Чтобы прикинуть объем, сложите: модель(и) в памяти, фичи (кэш на горячие ключи), рабочие буферы, очереди, служебные расходы и запас. Простой ориентир: держите 30-50% свободной RAM, чтобы пики не толкали систему к свопу.

На пилоте полезно смотреть:

• есть ли своп и были ли обращения к нему
• major page faults и рост задержек на пиках
• L3 cache miss rate и IPC (признаки «память-лимит»)
• давление на память в моменты p99 (очереди, аллокации)
• стабильность после нескольких часов под нагрузкой

Если пилот идет на сервере класса GSE S200, фиксируйте метрики до и после изменения объема RAM и политики кэширования фичей. Часто это сильнее улучшает p99, чем замена CPU на более дорогой.

CPU или GPU: как выбрать для скоринга и антифрода

Выбор между CPU и GPU упирается не в «кто быстрее», а в то, как вы меряете успех. В антифроде обычно важнее предсказуемый p99 и короткая задержка одного запроса. В скоринге иногда важнее пропускная способность в пике.

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

GPU уместен, когда модель тяжелая, много матричных операций и вы умеете держать высокую загрузку устройства. Типичный кейс - потоковая проверка транзакций с большим числом признаков и одинаковым графом вычислений, где батчинг дает выигрыш по стоимости и throughput.

Компромисс почти всегда в батчинге. Он ускоряет обработку пачки запросов, но может ухудшить задержку одного запроса: запрос ждет, пока наберется батч или освободится очередь. Если SLA - «каждую транзакцию за 20 мс», агрессивный батчинг легко ухудшит p99, даже если среднее станет лучше.

На пилоте проверяйте не только максимум, а стабильность:

• холодный старт и прогрев (сколько времени нужно до стабильных p50/p99)
• переключение версии модели (есть ли всплески задержек и ошибки при hot reload)
• очереди и батчинг (как меняется p99 при росте QPS и разных размерах батча)
• влияние окружения (драйверы GPU, версии CUDA, режимы питания, частоты)
• деградация при фоне (логирование, сбор метрик, фоновые джобы)

Хороший тест - прогнать одинаковый трафик на CPU-only и на CPU+GPU и сравнить не «лучший результат», а худшие 1% запросов. Для антифрода чаще выигрывает вариант, где p99 ровный даже в пике, пусть и с меньшей пиковой пропускной способностью.

Сеть и время: как не потерять миллисекунды

Даже если модель и CPU быстрые, сеть часто делает p99 непредсказуемым. Для скоринга и антифрода опасны хвосты: короткие всплески очередей на коммутаторе, переполненные буферы, микроперегрузка в часы пик. В итоге «нормальные» 5-10 мс превращаются в 50-150 мс на части запросов.

На уровне NIC смотрите не только на гигабиты, но и на задержку и стабильность. Offload-функции иногда помогают, но их стоит включать и выключать на пилоте и сравнивать p95/p99. Если на одном хосте несколько сервисов, проверьте, что драйверы и настройки очередей не создают конкуренцию за CPU.

Чтобы сеть меньше «шумела», заранее разделите типы трафика: онлайн-скоринг, доступ к фичам и хранилищам, админка и мониторинг, бэкапы и репликации. Так снижается шанс, что ночной бэкап внезапно поднимет задержки скоринга утром.

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

На пилотном стенде проверьте:

• потери пакетов и ретрансмиты под нагрузкой
• джиттер между узлами
• RTT между сервисами в одном сегменте и между сегментами
• влияние фонового трафика на p99

Полезный сценарий: запустите нагрузку скоринга и параллельно добавьте «шум» (логирование, репликацию, бэкап). Сравнение p99 до и после сегментации быстро показывает, где теряются миллисекунды еще до закупки.

Хранилище и доступ к фичам: NVMe, кэш и логирование

В скоринге и антифроде задержка часто «просыпается» не в модели, а в доступе к данным: фичи, профили клиента, списки (blacklist, whitelist), последние события по карте или устройству. Если чтения попадают на медленное хранилище, p95 и p99 растут даже при быстром CPU.

NVMe нередко дает больший эффект, чем большой RAID на медленных дисках. Скоринг обычно делает много мелких случайных чтений. Здесь важны IOPS и стабильная задержка, а не только гигабайты и «пиковая скорость» в спецификации.

Чаще всего диск затрагивается в трех местах: онлайн-хранилище фичей (key-value или локальная база), профили и состояния (например, счетчики по клиенту), журналы событий для разборов и обучения. Если все это живет на одном томе, логирование может незаметно съесть очередь I/O и испортить задержку чтения.

Чтобы не ловить холодный старт после перезапуска, нужен план прогрева кэша: держите горячие фичи и списки в памяти, а на старте прогоняйте типовые ключи. Заранее оцените, сколько RAM нужно под кэш, а сколько - под модель и сервис.

Логи лучше писать так, чтобы они не тормозили скоринг: отделяйте онлайн-решение от подробного аудита, буферизуйте и отправляйте пачками, по возможности храните логи и фичи на разных NVMe или томах. Отдельно следите за fsync и частотой записи - это частый источник проблем с p99.

На пилоте смотрите не только среднее:

• latency чтения фичей p95/p99
• глубину очереди I/O и рост на пике
• просадки при одновременной записи логов
• поведение после перезапуска (сколько длится прогрев)
• стабильность на реальных ключах, а не на синтетике

Если собираете пилот на платформе класса S200 и аналогичных, просите замеры по времени доступа к фичам, а не только по скорости инференса. В антифроде миллисекунды чаще теряются по пути к данным.

Надежность и изоляция: чтобы p99 не прыгал

В скоринге и антифроде решает не средняя задержка, а p99. В on-prem это часто упирается не в «сильнее CPU», а в запас по мощности, надежность и то, с кем сервис делит ресурсы.

Если узел один, отказ равен простою. Для продакшена нужен кластер из нескольких узлов и понятный сценарий: что происходит при падении сервера, сети или диска. Лучше заранее решить, что важнее при аварии: продолжить скоринг с урезанной мощностью или остановить часть функций, но сохранить качество и консистентность.

Запас по мощности напрямую влияет на p99. Когда сервер постоянно живет на 80-90% CPU, любой всплеск (GC, фоновые задачи, прерывания, очередь запросов) превращается в длинные хвосты. Практичнее планировать рабочую загрузку ниже и держать headroom под пики и деградацию при отказе одного узла.

Изоляция соседних нагрузок обязательна. Скоринг не должен делить хост с тяжелыми задачами вроде обучения моделей, отчетов, бэкапов или сканирований безопасности. Даже редкие фоновые процессы способны забрать диск, кэш и CPU на секунды.

На пилоте проверьте:

• отказ узла (p95/p99, очередь запросов, время восстановления)
• деградацию хранилища (теряются ли фичи и логи)
• «шумного соседа» (как меняется p99)
• перезапуск сервиса (сколько занимает прогрев кэшей)
• аудит и доступы (кто и как получает доступ, есть ли журналирование действий)

Практичный тест для банка: смоделируйте пик транзакций и одновременно падение одного узла. Если p99 растет в разы, значит не хватает запаса или неправильно настроена изоляция.

Пилот шаг за шагом: как проверить железо до закупки

Пилот нужен не для красивых графиков, а чтобы поймать то, что потом ломает p99: пики, редкие тяжелые запросы, конкуренцию за CPU и память. Начните с исходных цифр: целевые запросы в секунду (с запасом на рост), доля сложных кейсов (например, «подозрительные» 5-10% с большим числом правил и фичей), средний и максимальный размер фичей и ответа.

Соберите тестовый контур, максимально похожий на боевой, но небольшой: 1-2 модели, слой правил (если он есть), источник фичей (кэш или хранилище) и обязательное логирование. Цепочка должна быть честной: получение фичей, препроцессинг, инференс, постобработка, запись событий.

Нагрузку генерируйте не «ровной линией», а как в жизни: утренние пики, короткие всплески, ночные окна, смесь легких и тяжелых запросов.

На каждом прогоне фиксируйте: p50/p95/p99 по всей цепочке и отдельно по инференсу, загрузку CPU по ядрам и частоту, контекстные переключения и очереди, поведение памяти, сети и I/O. Отдельно записывайте ошибки: таймауты, деградации, рост латентности на прогреве.

Дальше сравните 2-3 конфигурации на одном и том же тесте: CPU-ориентированную (высокая частота и правильная NUMA-привязка) и вариант с GPU, если модели реально выигрывают от батчинга. Часто решение смешанное: железо меняют точечно (например, добавляют RAM или NVMe), а остальное добирают настройками (пулы потоков, pinning, кэш фичей, таймауты).

Если пилот делаете с интегратором, договоритесь о критериях «прошел/не прошел» по p99 и ошибкам. В проектах подобного типа GSE.kz может помочь собрать стенд на базе серверов S200 и зафиксировать измерения так, чтобы их можно было повторить перед закупкой.

Пример сценария: пилот антифрода в банке с пиковыми нагрузками

Банк запускает on-prem-инфраструктуру для скоринга и антифрода платежей в реальном времени. В обычные дни поток стабильный, но в зарплатные даты нагрузка легко вырастает в 3 раза. Требования по задержке при этом не меняются: p99 не выше 60 мс на решение, включая получение фичей и запись события в журнал.

Пилот собирают как мини-копию продакшена: сервер для инференса, отдельный сервис фичей и имитация внешних зависимостей (очередь, API, логирование). Сразу тестируют не среднее, а хвосты p95/p99, потому что в антифроде именно они превращаются в таймауты и потерю транзакций.

Прогоняют два режима инференса: одиночные запросы (честнее для задержек) и микробатчи (когда входящий поток высокий). Параллельно сравнивают два подхода к фичам: кэш в RAM на горячие ключи и чтение с диска при промахе.

В измерениях обычно видно следующее. При росте QPS хвост p99 появляется из-за конкуренции за CPU и скачков NUMA, даже если среднее время хорошее. При агрессивном и особенно синхронном логировании хвост резко растет из-за I/O - и тут помогают NVMe и асинхронная запись. Кэш фичей в RAM часто дает больший эффект, чем попытки ускорить модель. Микробатч снижает загрузку CPU, но может ухудшить задержку, если размер батча выбран без учета пикового трафика.

Итог пилота обычно формулируют не как «нужен самый мощный сервер», а как предсказуемый набор: достаточная частота CPU для однопоточной части, запас RAM под кэш фичей, NVMe под журналы и локальные данные, низколатентная сеть между сервисами. Это позволяет удерживать p99 в пределах даже в пиковые дни, без переписывания модели - за счет конфигурации и режимов работы. Если тестируете на сервере класса GSE S200, зафиксируйте настройки BIOS, NUMA и профили питания, чтобы результат повторился при закупке и внедрении.

Частые ошибки при выборе on-prem железа и тестах

Чаще всего пилот проваливается из-за веры в среднюю задержку. В скоринге и антифроде важны хвосты: p95 и особенно p99. Именно они превращают «быстро» в «пользователь ждет» и бьют по конверсии, а в антифроде - по пропущенным атакам и лишним блокировкам.

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

Типовые ошибки при выборе on-prem-инфраструктуры для скоринга и антифрода:

• берут CPU «побольше ядер», но с низкой частотой - и один запрос выполняется дольше
• недооценивают сеть (очереди на коммутаторе, неверные настройки MTU, редкие потери пакетов)
• делают выводы по холодному старту (кэш не прогрет, модель и фичи не в памяти)
• тестируют на синтетике без пиков и без реальных данных

Пример из практики пилотов: при 200 RPS все выглядит хорошо, но при коротких всплесках до 800 RPS p99 вырастает в 3 раза. Причина часто оказывается не в модели, а в конкуренции за CPU и очередях на сетевом пути к хранилищу фич.

Хорошая привычка: отдельно замерять прогретый и холодный режим, добавлять реальные пики и фиксировать не только латентность, но и утилизацию CPU по ядрам, память, сетевые очереди и I/O.

Короткий чеклист и следующие шаги

On-prem-инфраструктуру для скоринга и антифрода лучше строить от измеримых метрик. Один короткий пилот часто полезнее, чем месяцы обсуждений конфигураций.

Пилот: что обязательно проверить

Сделайте пилот похожим на реальную жизнь: те же таймауты, те же пики, те же «плохие» запросы. Минимальный набор:

• p50/p95/p99 по всему пути и отдельно по инференсу, фичам и сети
• поведение на пиках (всплески RPS, очереди, деградация p99)
• холодный старт (после перезапуска сервиса, прогрев кэшей, загрузка модели)
• отказ одного узла (переключение, рост задержек, потери запросов)
• контроль времени (event time, таймзоны, рассинхрон часов)

После таких проверок обычно быстро видно, куда уходит время: в NUMA и кэши CPU, в нехватку RAM, в ожидание диска или в сетевые переходы между сегментами.

Что зафиксировать перед закупкой

Чтобы закупка не была гаданием, подготовьте короткий набор решений и запас по росту:

• 2-3 подтвержденные конфигурации с расчетом запаса по CPU/RAM/IOPS и целевым p99
• требования к CPU (частота, правила NUMA-привязки)
• требования к RAM (модель, фичи, кэши без свопа) и к NVMe под логи и фичестор
• требования к сети (NIC, сегментация, где стоят шлюзы и балансировщики)
• план масштабирования: когда добавляете узлы и как подтверждаете, что p99 не «прыгает»

Если нужен внешний взгляд, системный интегратор может помочь с подбором оборудования, сборкой пилотного стенда и поддержкой. У GSE.kz, например, есть линейка серверов S200 для стойки и рабочие станции/ПК для команд - это удобно, когда пилот нужно быстро превратить в рабочий контур на оборудовании одного производителя.