Оглавление

Масштабирование инференса больших языковых моделей — это не просто покупка дополнительных видеокарт, а сложная инженерная эквилибристика между доступностью системы и ее стоимостью. Как сообщает Databricks в своем новом техническом отчете, компания обрабатывает более 120 триллионов токенов ежемесячно, сталкиваясь с резкими скачками трафика в рабочие часы. Для поддержания стабильности систем, питающих таких гигантов, как Superhuman и Fox Sports, инженерам пришлось пересмотреть классические подходы к распределению ресурсов.

Основная сложность заключается в том, что стандартные метрики вроде загрузки CPU или объема оперативной памяти практически не коррелируют с реальной производительностью GPU при работе с нейросетями. В мультиарендных системах, где на одном оборудовании работают разные заказчики, одна тяжелая задача с длинным контекстом может замедлить работу всех остальных пользователей, превращая «быстрый» ИИ в бесконечное ожидание первого токена.

Абстракция модельных единиц и умное масштабирование

Для решения проблемы неопределенности Databricks ввела концепцию «модельных единиц» (model units) — виртуальную надстройку, напоминающую привычные облачные виртуалки, но адаптированную под нужды нейросетей. Каждая единица представляет собой фиксированную вычислительную мощность, а стоимость конкретного запроса рассчитывается через многомерную функцию, учитывающую количество входных и выходных токенов, а также их нелинейное влияние на производительность системы.

Внедрение этой системы позволило реализовать балансировщик нагрузки Dicer, который распределяет запросы не по количеству обращений, а по реальной загрузке серверов в этих самых единицах. Это не только предотвращает появление «горячих точек» в кластере, но и позволило авторам решения добиться экономии на GPU более 80% по сравнению со статическим выделением ресурсов, поскольку система теперь гибко подстраивается под нужды клиентов в реальном времени.

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

Борьба с «тихими» сбоями и мультимодальными узкими местами

Надежность на уровне среды выполнения — еще один фронт работ, где инженеры столкнулись с неожиданным поведением оборудования. Одной из самых коварных проблем стали «тихие зависания» (silent hangs), когда сервер перестает отвечать на запросы, но формально остается в рабочем состоянии. Для борьбы с этим были внедрены приоритетные проверки работоспособности (health checks), которые проходят вне общей очереди, позволяя системе автоматически перезагружать зависшие узлы менее чем за 5 минут.

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

  • Стандартные библиотеки обработки изображений (PIL) могут быть в 10 раз медленнее специализированных решений вроде Torchvision.
  • Неправильная настройка переменной OMP_NUM_THREADS в контейнерах приводит к избыточному количеству потоков, что вызывает троттлинг процессора.
  • Перенос тяжелых операций в отдельные потоки и оптимизация окружения позволили увеличить пропускную способность системы более чем в 3 раза на том же железе.

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