Инференс в продакшне: Владислав Танков о том, что реально ломается при масштабировании LLM-сервисов

Автор: Владислав Танков · Podlodka Podcast

Владислав Танков — директор по AI в JetBrains. Это второй его выпуск на Podlodka (#452): первый (#444) был про внутреннее устройство LLM на уровне трансформеров и аттеншенов. Этот — про то, что происходит, когда модель нужно не просто запустить, а запустить в продакшне под реальной нагрузкой.

Большинство разговоров про LLM в продакшне сводятся к «берём OpenAI API и готово». Танков рассказывает про другой класс задач: когда API не подходит — из-за данных, задержки, стоимости или политики безопасности — и нужно думать об инфраструктуре самому. Локальный инференс vs облачный — это не просто вопрос цены, это вопрос контроля над latency, privacy и зависимостью от внешнего провайдера. В JetBrains этот выбор делается для каждого продукта отдельно, и критерии нетривиальны.

Кому смотреть: инженерам и архитекторам, которые строят или планируют строить продукты поверх LLM и хотят понять инфраструктурную сторону вопроса — не теорию трансформеров, а что конкретно потребляет память, откуда берётся latency и где узкое место при масштабировании.

Из этого можно взять в работу: если вы сейчас используете LLM только через API — составьте список требований к задержке, приватности данных и стоимости для вашего конкретного use case. Это займёт час, но может изменить архитектурное решение.

Танков начинает с анатомии inference-запроса. Два этапа: prefill (обработка prompt — параллельная операция, быстро) и decode (генерация токенов — последовательная, медленно). Именно decode определяет видимую пользователем задержку, и именно здесь возникают узкие места при масштабировании. KV-cache — механизм, который позволяет не пересчитывать attention для уже обработанных токенов — критичен для производительности, но требует значительной GPU-памяти.

Выбор модели: Танков предлагает думать в координатах размер/качество/стоимость/задержка. Большие модели (70B+) дают лучшее качество, но требуют multi-GPU и имеют высокую стоимость инференса. Маленькие модели (7B-13B) умещаются на одной GPU, работают быстро и дёшево, но имеют потолок качества. Для многих задач разрыв в качестве меньше, чем кажется — особенно при хорошем prompt engineering и fine-tuning.

Квантизация — практический инструмент уменьшения требований к памяти. FP16 → INT8 → INT4: каждый шаг уменьшает размер модели вдвое, но деградация качества нелинейна и зависит от задачи. Танков говорит о том, как в JetBrains оценивают trade-off: для code completion INT8 практически неотличим от FP16, для reasoning-задач разница ощутима.

Облако vs локальный инференс: у каждого свои узкие места. Облако — это управляемый сервис, но vendor lock-in, cold start у serverless-вариантов и цена при высокой нагрузке. Локальный инференс — полный контроль и предсказуемая latency, но капитальные затраты на GPU и операционная нагрузка. В JetBrains часть моделей гоняется локально на серверах компании, часть — в облаке, выбор зависит от требований конкретного продукта.