Пост из отложки. [Часть 1]

Как сделать ROI на GPU, если ты GPU-poor и LLM тебе не нужны

Когда говорят про данные, часто вспоминают «мусор на входе — мусор на выходе». А дальше обычно два сценария: либо «давайте прикрутим технологию покруче, и всё починится», либо игрушечный Data Quality из NOT NULL, UNIQUE и пары range checks.

В реальном enterprise всё может быть сложнее. Есть клики, SAP, CRM, MES, телеметрия, старые DWH, Excel и интеграции, которые пережили людей, их написавших. И самые неприятные проблемы не обязательно выглядят как age < 0. Данные могут оставаться формально валидными, но начать вести себя иначе: schema на месте, NULL'ов нет, объём тот же, pipeline зелёный — а после обновления firmware изменился смысл сигнала, съехал mapping или старый join начал соединять немного не то.

И вот здесь мне интересен GPU за пределами очевидного «давайте крутить LLM».

GPU — это прежде всего большой объём параллельного compute. И structured data умеет использовать его напрямую: [cuDF](https://docs.rapids.ai/api/cudf/stable/) делает на GPU привычные DataFrame operations, а [RAPIDS Accelerator for Apache Spark](https://docs.nvidia.com/spark-rapids/) переносит поддерживаемые Spark SQL и DataFrame workloads на GPU.

Для задач качества данных это важно не потому, что IS NULL внезапно нужно считать на видеокарте. Интереснее другое: дополнительный compute позволяет считать больше свойств данных и делать это чаще.

Можно постоянно пересчитывать codedistributions, quantiles, cardinality, missingness, correlations, categorical combinations и другие статистики — не только по таблице целиком, но и по plant × machine × product × shift × operating mode.

И тут compute довольно прямо превращается в business value. Он работает не только на один DQ job, а на весь поток:

processing → profiling → DQ → feature engineering → ML

Меньше времени на тяжёлую обработку, больше проверяемых гипотез, раньше замеченные проблемы и меньше мусора, который доезжает до аналитики и моделей.

На этом фоне идея прогонять сырые табличные данные через LLM выглядит не всегда оптимальной. Если задача сводится к groupby, статистике и anomaly detection; очистке и статистическому анадизу, разумнее сначала потратить GPU непосредственно на эти вычисления. А LLM оставить на последний километр — например, объяснить аналитику, почему уже найденная аномалия выглядит подозрительно.

Не «GPU вместо LLM», а более приземлённая идея: использовать дорогой compute там, где он максимально прямо превращается в полезный сигнал.

Возможно, одно из самых интересных применений GPU в enterprise — позволить себе гораздо больше паранойи относительно собственных данных.