Улучшение вывода ИИ: Продвинутые техники и лучшие практики

Когда речь идет о приложениях с выводом ИИ в реальном времени, таких как самоходные автомобили или мониторинг здравоохранения, даже дополнительная секунда для обработки входных данных может иметь серьезные последствия. Приложения с выводом ИИ в реальном времени требуют надежных GPU и мощности обработки, что было очень дорого и ограничивало многие применения – пока что.

Принимая оптимизированный процесс вывода, бизнес может не только максимизировать эффективность ИИ, но также уменьшить потребление энергии и операционные затраты (до 90%); повысить конфиденциальность и безопасность; и даже улучшить удовлетворенность клиентов.

Общие проблемы вывода

Некоторые из наиболее распространенных проблем, с которыми сталкиваются компании при управлении эффективностью ИИ, включают неиспользуемые кластеры GPU, переход к общим моделям и отсутствие информации о связанных затратах.

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

Кроме того, команды переходят к большим общим моделям (GPT-4, Claude), даже для задач, которые могут работать на меньших, более дешевых открытых моделях. Причины? Отсутствие знаний и крутая кривая обучения при построении пользовательских моделей.

Наконец, инженеры обычно не имеют информации о реальной стоимости каждого запроса, что приводит к большим счетам. Инструменты, такие как PromptLayer, Helicone, могут помочь предоставить эту информацию.

Из-за отсутствия контроля над выбором модели, пакетированием и использованием, затраты на вывод могут увеличиваться экспоненциально (до 10 раз), расточать ресурсы, ограничивать точность и ухудшать пользовательский опыт.

Потребление энергии и операционные затраты

Запуск более крупных моделей LLM, таких как GPT-4, Llama 3 70B или Mixtral-8x7B, требует значительно больше мощности на каждый токен. В среднем 40 до 50 процентов энергии, используемой центром обработки данных, питает вычислительное оборудование, с дополнительными 30 до 40 процентами, выделенными для охлаждения оборудования.

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

Конфиденциальность и безопасность

Согласно исследованию Cisco 2025 года о приватности данных, «64% респондентов беспокоятся о непреднамеренном обмене конфиденциальной информацией публично или с конкурентами, но почти половина признается в вводе личных данных сотрудников или не публичных данных в инструменты GenAI». Это увеличивает риск несоблюдения требований, если данные не регистрируются или кэшируются должным образом.

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

Удовлетворенность клиентов

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

Бизнес-выгоды от управления этими проблемами

Оптимизация пакетирования, выбор правильных моделей (например, переход с Llama 70B или закрытых моделей, таких как GPT, на Gemma 2B, где это возможно) и улучшение использования GPU могут сократить счета за вывод на 60-80 процентов. Использование инструментов, таких как vLLM, может помочь, а также переход на серверную модель оплаты по мере использования для неравномерного рабочего процесса.

Возьмем, например, Cleanlab. Cleanlab запустила доверенный языковый модель (TLM) для добавления оценки достоверности к каждому ответу LLM. Она предназначена для высококачественных выходных данных и повышенной надежности, что имеет решающее значение для приложений предприятий, чтобы предотвратить неограниченные галлюцинации. До Inferless Cleanlabs столкнулась с увеличением стоимости GPU, поскольку GPU работали даже тогда, когда они не были активно использованы. Их проблемы были типичными для традиционных облачных поставщиков GPU: высокая задержка, неэффективное управление стоимостью и сложная среда для управления. С серверным выводом они сократили затраты на 90 процентов, сохраняя при этом уровень производительности. Более важно, что они запустились в течение двух недель без дополнительных затрат на инженерные работы.

Оптимизация архитектуры модели

Основные модели, такие как GPT и Claude, часто обучаются для общности, а не для эффективности или конкретных задач. Не настраивая открытые модели для конкретных случаев использования, бизнес тратит память и время обработки для задач, которые не требуют такого масштаба.

Новые GPU-чипы, такие как H100, быстрые и эффективные. Это особенно важно при запуске крупномасштабных операций, таких как генерация видео или задачи, связанные с ИИ. Больше CUDA-ядер увеличивает скорость обработки, превосходя меньшие GPU; тензорные ядра NVIDIA предназначены для ускорения этих задач в масштабе.

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

Несколько преимуществ оптимизации архитектуры модели включают экономию времени и денег. Во-первых, переход от плотного трансформера к LoRA-оптимизированным или FlashAttention-основанным вариантам может сэкономить от 200 до 400 миллисекунд на время ответа на запрос, что имеет решающее значение в чат-ботах и играх, например. Кроме того, квантованные модели (например, 4-битные или 8-битные) требуют меньше VRAM и работают быстрее на более дешевых GPU.

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

Оптимизация архитектуры модели включает следующие шаги:

• Квантование — уменьшение точности (FP32 → INT4/INT8), экономия памяти и ускорение времени обработки
• Обрезка — удаление менее полезных весов или слоев (структурированных или неструктурированных)
• Дистилляция — обучение меньшей «студенческой» модели для имитации выхода более крупной модели

Сжатие размера модели

Меньшие модели означают более быстрый вывод и менее дорогую инфраструктуру. Большие модели (13B+, 70B+) требуют дорогих GPU (A100s, H100s), высокого VRAM и больше мощности. Сжатие их позволяет запускать их на более дешевом оборудовании, таком как A10s или T4s, с гораздо меньшей задержкой.

Сжатые модели также имеют решающее значение для запуска на устройстве (телефонах, браузерах, IoT) вывода, поскольку меньшие модели позволяют обслуживать больше одновременных запросов без масштабирования инфраструктуры. В чат-боте с более чем 1 000 одновременными пользователями переход от 13B до 7B сжатой модели позволил одной команде обслуживать более чем в два раза больше пользователей на GPU без скачков задержки.

Использование специализированного оборудования

Общие CPU не предназначены для тензорных операций. Специализированное оборудование, такое как NVIDIA A100s, H100s, Google TPUs или AWS Inferentia, может предложить более быстрый вывод (в 10-100 раз) для LLM с лучшей энергоэффективностью. Срезание даже 100 миллисекунд на запрос может иметь значение при обработке миллионов запросов в день.

Рассмотрим этот гипотетический пример:

Команда запускает LLaMA-13B на стандартных GPU A10 для своей внутренней системы RAG. Задержка составляет около 1,9 секунды, и они не могут пакетировать много из-за ограничений VRAM. Итак, они переключаются на H100 с TensorRT-LLM, включают FP8 и оптимизируют ядро внимания, увеличивая размер пакета с 8 до 64. Результатом является сокращение задержки до 400 миллисекунд с пятикратным увеличением пропускной способности.
В результате они могут обслуживать запросы в пять раз на том же бюджете и освободить инженеров от навигации по инфраструктурным узким местам.

Оценка вариантов развертывания

Разные процессы требуют разных инфраструктур; чат-бот с 10 пользователями и поисковая система, обслуживающая миллион запросов в день, имеют разные потребности. Полный переход на облачные сервисы (например, AWS Sagemaker) или DIY-GPU-серверы без оценки соотношения стоимости и производительности приводит к расточительному расходованию средств и плохому пользовательскому опыту. Обратите внимание, что если вы привязываетесь к закрытому облачному поставщику, миграция решения позже будет болезненной. Однако ранняя оценка с моделью оплаты по мере использования дает вам варианты в будущем.

Оценка включает следующие шаги:

• Бенчмарк задержки модели и стоимости на платформах: запуск тестов A/B на AWS, Azure, локальных GPU-кластерах или серверных инструментах для репликации.
• Измерение производительности холодного старта: это особенно важно для серверных или событийно-ориентированных рабочих нагрузок, поскольку модели загружаются быстрее.
• Оценка наблюдаемости и пределов масштабирования: оценка доступных метрик и определение максимальных запросов в секунду до ухудшения.
• Проверка поддержки соблюдения требований: определение того, можно ли обеспечить соблюдение географических правил данных или аудиторских журналов.
• Оценка общей стоимости владения. Это должно включать часы GPU, хранилище, пропускную способность и накладные расходы для команд.

Итог

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