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

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

Это менее эффектная половина гонки моделей: не только повышать интеллект, но и делать его пригодным для развертывания.

Почему меньшие модели меняют подход к развертыванию

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

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

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

Три метода, лежащие в основе этого сдвига

Квантизация представляет веса модели, а иногда и активации, числами с меньшей разрядностью. Переход от таких форматов, как BF16 или FP16, к 8- или 4-битным представлениям может уменьшить требования к памяти и повысить пропускную способность — в зависимости от оборудования и реализации. Компромисс заключается в том, что меньшая точность может снизить качество или вызвать численные проблемы, поэтому это необходимо проверять, а не считать безвредным.

Дистилляция обучает меньшую модель-ученика воспроизводить полезное поведение более крупной модели-учителя. Ученик может обучаться на выходных данных учителя, промежуточных сигналах или примерах, связанных с конкретной задачей. Ему не нужно воссоздавать все возможности более крупной модели; ему нужно достаточно хорошо выполнять целевую задачу.

Оптимизированный инференс адаптирует выполнение к конкретной среде исполнения и процессору. Это может включать выбор ядер, компиляцию графа, пакетную обработку, планирование памяти, кэширование и аппаратное ускорение с учетом особенностей оборудования. TensorRT Model Connect от NVIDIA, представленный в рамках публичного предварительного просмотра, — один из примеров инструментов, предназначенных для преобразования поддерживаемых контрольных точек Hugging Face или локальных контрольных точек в сквозной инференс TensorRT без промежуточного экспорта в ONNX. Заявленная целевая область включает робототехнику, устройства и платформенные рабочие нагрузки.

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

Полезный результат — это не то же самое, что меньший файл

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

Отчет Liquid AI о дистилляции с учетом квантизации для небольших моделей LFM2.5 хорошо иллюстрирует эту цель. Компания сообщила о сохранении от 96.5% до 97.4% производительности BF16 при сохранении использования памяти и пропускной способности Q4_0. Эти показатели сообщены компанией и относятся к конкретным моделям; их не следует обобщать на любую архитектуру. Но они показывают, какого рода сравнениям следует искать практикам: сохранение качества нужно измерять одновременно с использованием памяти и скоростью, а не ограничиваться одним коэффициентом сжатия.

Для развертывания приемочное тестирование должно включать как минимум:

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

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

Где появляется новая работа

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

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

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

Разделение между облаком и периферией становится проектировочным навыком

Небольшие модели не устраняют облачные модели. Они делают гибридные системы более привлекательными. Устройство может использовать компактную модель для немедленного обнаружения, а затем отправлять выбранные события более крупной модели для объяснения или углублённого анализа. Робот может выполнять критически важное для безопасности восприятие локально, используя облако для обучения на уровне всего парка устройств. Продукт поддержки клиентов может направлять стандартную классификацию небольшой модели, а неоднозначные случаи передавать более мощной.

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

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

Практический путь обучения

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

  1. Установите базовый уровень. Зафиксируйте качество, размер модели, использование памяти, задержку и пропускную способность с помощью воспроизводимого набора тестов.
  2. Квантуйте её. Сравните как минимум одну версию с пониженной точностью с базовой. Задокументируйте, какие примеры изменились и сосредоточены ли ошибки в важной категории.
  3. Попробуйте дистилляцию или дообучение под конкретную задачу. Измерьте, может ли меньшая модель сохранить поведение, действительно необходимое продукту.
  4. Запустите её на целевом оборудовании. Результат тестирования на настольном компьютере ничего не говорит о телефоне, микрокомпьютере, GPU, ускорителе или компьютере робота.
  5. Упакуйте развёртывание. Включите предварительную обработку, последующую обработку, метаданные версии, проверки работоспособности и резервный путь.
  6. Составьте отчёт о компромиссах. Объясните, почему выбранная модель лучше сочетает качество, задержку, использование памяти, энергопотребление, конфиденциальность и стоимость, а не только почему у неё лучший показатель.

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

Карьерный сигнал

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

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

Для карьеры в области ИИ это устойчивый урок: интеллект — лишь одна часть результата. Другая часть — сделать так, чтобы он соответствовал требованиям.