AlexMorozov
New member
Когда мы только выкатили нашу первую LLM-фичу в прод, я искренне считал, что самое сложное позади. Прототип работал, метрики качества радовали, бизнес хлопал в ладоши. А потом пришёл первый счёт за инференс, и я минут пять сидел, глядя в него, как в некролог собственному бюджету. С тех пор прошло около полутора лет, и я прошёл путь от «платим как за крыло самолёта» до вполне вменяемых цифр. Хочу поделиться тем, что реально помогло, а что оказалось пустой тратой времени.
Главная ошибка была концептуальной. Мы взяли самую крупную и модную модель просто потому, что она была самой крупной и модной. Никто не спросил, нужна ли нам такая мощность для классификации обращений в поддержку и генерации коротких ответов. А оказалось, что восемьдесят процентов наших задач прекрасно закрывает модель в разы меньше и в разы дешевле. Я до сих пор считаю, что первое правило экономии инференса звучит так: сначала измерь задачу, потом выбирай модель, а не наоборот. Звучит банально, но на практике через это спотыкаются почти все.
Второй рывок мы сделали на кэшировании. Люди задают одни и те же вопросы удивительно похожими словами. Мы прикрутили семантический кэш на входе: если запрос близок к тому, что уже обрабатывали, отдаём сохранённый ответ, не трогая модель вообще. Это дало нам порядка тридцати процентов экономии практически бесплатно, потому что проверка похожести стоит копейки по сравнению с полным проходом по большой модели. Параллельно мы занялись батчингом: вместо того чтобы гонять запросы по одному, собираем их в пачки. Пропускная способность выросла заметно, а стоимость запроса упала.
Третий блок — это квантизация и правильный выбор железа. Когда мы перевели часть моделей на пониженную точность, качество на наших задачах просело в пределах погрешности, которую никто из пользователей не заметил, а потребление ресурсов сократилось ощутимо. Но тут важная оговорка: квантизация не бесплатна и не универсальна. На генерации кода и на длинных цепочках рассуждений она иногда бьёт больнее, чем хотелось бы. Поэтому мы завели отдельный набор тестов именно под этот сценарий и прогоняем его перед каждым изменением конфигурации.
Отдельная боль, о которой почему-то мало говорят, это наблюдаемость. Пока вы не видите, сколько токенов уходит на каждый эндпоинт, какой у вас средний размер контекста и сколько запросов вообще не нужно было отправлять в модель, вы оптимизируете вслепую. Я настоял на том, чтобы мы логировали стоимость каждого вызова с привязкой к фиче и к пользователю. Через неделю выяснилось, что один внутренний сервис молотил модель в фоновом режиме круглосуточно и давал ноль полезного результата. Его просто забыли выключить после эксперимента. Такие находки окупают всю работу по метрикам мгновенно.
Ещё одна вещь, которая нас спасла, это маршрутизация запросов. Мы поставили перед большой моделью маленькую, роль которой — быстро понять, насколько задача сложная. Простые вещи она закрывает сама, а тяжёлые уходят дальше, к мощной модели. Получилась эдакая сортировка: дорогой ресурс тратится только там, где он действительно нужен. Мы также честно посчитали, когда выгодно держать собственную модель на своих серверах, а когда продолжать платить за API. Для нас порог оказался довольно высоким: своё железо начинает окупаться только при стабильной и большой загрузке, а при рваном трафике API почти всегда выигрывает.
Если сформулировать коротко, то мой список для тех, кто только заходит в продакшен с нейросетями, выглядит так. Считайте деньги с первого дня, а не после первого шока от счёта. Выбирайте модель под задачу, а не под хайп вокруг неё. Ставьте кэш и батчинг прежде, чем думать о чём-то более экзотическом. Логируйте каждый вызов, иначе будете гадать. И обязательно держите запасной путь: если внешний провайдер поднимет цены или отвалится, у вас должен быть план Б, а не паника в чате дежурных.
Самое приятное во всей этой истории то, что экономия и качество почти не конфликтуют. Почти все найденные нами улучшения не только снизили расходы, но и сделали систему быстрее и предсказуемее. Мы стали отвечать за доли секунды там, где раньше секунды тянулись, и пользователи это заметили раньше, чем бухгалтерия. А теперь вопрос к вам, коллеги: какой приём оптимизации инференса дал лично вам самый большой эффект, и что из модных советов у вас на практике не сработало совсем? Буду рад почитать ваш опыт, потому что в этой области мы все учимся буквально на ходу.
Главная ошибка была концептуальной. Мы взяли самую крупную и модную модель просто потому, что она была самой крупной и модной. Никто не спросил, нужна ли нам такая мощность для классификации обращений в поддержку и генерации коротких ответов. А оказалось, что восемьдесят процентов наших задач прекрасно закрывает модель в разы меньше и в разы дешевле. Я до сих пор считаю, что первое правило экономии инференса звучит так: сначала измерь задачу, потом выбирай модель, а не наоборот. Звучит банально, но на практике через это спотыкаются почти все.
Второй рывок мы сделали на кэшировании. Люди задают одни и те же вопросы удивительно похожими словами. Мы прикрутили семантический кэш на входе: если запрос близок к тому, что уже обрабатывали, отдаём сохранённый ответ, не трогая модель вообще. Это дало нам порядка тридцати процентов экономии практически бесплатно, потому что проверка похожести стоит копейки по сравнению с полным проходом по большой модели. Параллельно мы занялись батчингом: вместо того чтобы гонять запросы по одному, собираем их в пачки. Пропускная способность выросла заметно, а стоимость запроса упала.
Третий блок — это квантизация и правильный выбор железа. Когда мы перевели часть моделей на пониженную точность, качество на наших задачах просело в пределах погрешности, которую никто из пользователей не заметил, а потребление ресурсов сократилось ощутимо. Но тут важная оговорка: квантизация не бесплатна и не универсальна. На генерации кода и на длинных цепочках рассуждений она иногда бьёт больнее, чем хотелось бы. Поэтому мы завели отдельный набор тестов именно под этот сценарий и прогоняем его перед каждым изменением конфигурации.
Отдельная боль, о которой почему-то мало говорят, это наблюдаемость. Пока вы не видите, сколько токенов уходит на каждый эндпоинт, какой у вас средний размер контекста и сколько запросов вообще не нужно было отправлять в модель, вы оптимизируете вслепую. Я настоял на том, чтобы мы логировали стоимость каждого вызова с привязкой к фиче и к пользователю. Через неделю выяснилось, что один внутренний сервис молотил модель в фоновом режиме круглосуточно и давал ноль полезного результата. Его просто забыли выключить после эксперимента. Такие находки окупают всю работу по метрикам мгновенно.
Ещё одна вещь, которая нас спасла, это маршрутизация запросов. Мы поставили перед большой моделью маленькую, роль которой — быстро понять, насколько задача сложная. Простые вещи она закрывает сама, а тяжёлые уходят дальше, к мощной модели. Получилась эдакая сортировка: дорогой ресурс тратится только там, где он действительно нужен. Мы также честно посчитали, когда выгодно держать собственную модель на своих серверах, а когда продолжать платить за API. Для нас порог оказался довольно высоким: своё железо начинает окупаться только при стабильной и большой загрузке, а при рваном трафике API почти всегда выигрывает.
Если сформулировать коротко, то мой список для тех, кто только заходит в продакшен с нейросетями, выглядит так. Считайте деньги с первого дня, а не после первого шока от счёта. Выбирайте модель под задачу, а не под хайп вокруг неё. Ставьте кэш и батчинг прежде, чем думать о чём-то более экзотическом. Логируйте каждый вызов, иначе будете гадать. И обязательно держите запасной путь: если внешний провайдер поднимет цены или отвалится, у вас должен быть план Б, а не паника в чате дежурных.
Самое приятное во всей этой истории то, что экономия и качество почти не конфликтуют. Почти все найденные нами улучшения не только снизили расходы, но и сделали систему быстрее и предсказуемее. Мы стали отвечать за доли секунды там, где раньше секунды тянулись, и пользователи это заметили раньше, чем бухгалтерия. А теперь вопрос к вам, коллеги: какой приём оптимизации инференса дал лично вам самый большой эффект, и что из модных советов у вас на практике не сработало совсем? Буду рад почитать ваш опыт, потому что в этой области мы все учимся буквально на ходу.