Сервировка моделей (model serving)
Сервировка моделей (model serving) заставляет ещё раз внимательно поглядеть на происходящее в интеллект-стеке:
-- в deep learning озаботились выдачей моделей внешним потребителям
-- в GPU неминуемо создание чего-то типа "многозадачной и многопользовательской операционной системы для GPU".
-- в системное мышление нужно срочно добавлять работу с коннективистскими моделями, вплоть до заимствования терминологии
Речь идёт об ещё одном специфическом уровне интеллект-стека: model server (сервер модели) как программный слой, предоставляющий доступ к обученной модели со стороны других модулей когнитивной архитектуры. Коннективистскую модель нужно сначала обучить, потом компилировать для какой-то аппаратной архитектуры (например, использовав NVIDIA TensorRT), потом её нужно сделать доступной извне для запросов на исполнение -- сервировать. Об этом уже появился ряд статей и презентаций: январская 2018 "The Rise of the Model Servers. New Tools for Deploying Machine Learning Models to Production" (https://medium.com/@vikati/the-rise-of-the-model-servers-9395522b6c58), мартовская 2018 презентация Model Serving for Deep Learning от AWS (https://www.slideshare.net/hornsby/model-serving-for-deep-learning) и т.п.. Это очень хороший тренд, он крайне радует. Его появление означает, что обученные нейронные сети/коннективистские модели стали полезными и нужно выдавать внешним пользователям (а не только самим разработчикам, обучающим модели) интерфейс сервиса по запуску этих моделей на исполнение. Нейросетки выходят в люди, буквально. Ешьте ваши модели, сервировано.
Пикантность ситуации задаёт то, что в deep learning для сервировки моделей набирают силу serverless architectures (коротко в https://martinfowler.com/bliki/Serverless.html и более глубоко в https://martinfowler.com/articles/serverless.html). Так что по факту речь идёт о serverless model serving (мне это напомнает ещё один такой же странный термин про model-free learning и результирующим model-free models).
Термины были известны давно, но всплеск использования терминологии пришёл от сотрудников Amazon, которые занялись проблемой в октябре-ноябре 2017 -- использование Lambda на AWS для нейронных сеток. Вот "Serving deep learning models in a serverless platform" (октябрь 2017, апдейт февраль 2018), https://arxiv.org/abs/1710.08460. Вот пример типичной работы октября 2017, Serving PyTorch Models on AWS Lambda with Caffe2 & ONNX, https://machinelearnings.co/serving-pytorch-models-on-aws-lambda-with-caffe2-onnx-7b096806cfac. Вот буквально через месяц в ноябре 2017, Serverless serving of TensorFlow models with AWS lambda, https://github.com/Vetal1977/tf_aws_lambda. Сервировка моделей и сегодня активно продвигается специалистами Amazon, так что этот термин не забудется. Вот самое свежее их выступление по model serving, от 24 апреля 2018 -- https://www.youtube.com/watch?v=x1yvKogYAB4
Конечно, ключевая (enabling) тут технология -- ONNX (и, возможно, когда-нибудь будет и NNEF, но о нём что-то последнее время не слышно -- https://ailev.livejournal.com/1395131.html). Сервировка моделей в глубоком обучении -- это как раз и есть оформление массового доступа к откомпилированной сетке-модели. Если есть стандарт, в котором можно передать модель с серверов, на которых она обучалась на сервера, где она будет сервирована, то дальше всё просто -- речь идёт о хорошо оформленном уровне технологического интеллект-стека.
Важная технологическая задача тут -- погружение model serving на современную аппаратуру, то есть в GPU. В связи с особенностями GPU, там можно запускать сразу много моделей, и model serving должно это учитывать. Оригинальная статья от Amazon AWS как раз затрагивает этот вопрос, рассматривая возможные пути развития бессерверной сервировки моделей -- https://arxiv.org/abs/1710.08460. Текущая задача, похоже, научиться использовать одну железку GPU как для обучения, так и для сервировки множества моделей. Вот только парочка работ из этой области:
-- обучение через нейроэволюцию: все игры Атари за 4 часа на декстоп-компьютере с видеокартой (нейроэволюционеры из Uber продолжают жечь: https://eng.uber.com/accelerated-neuroevolution/, прошлая серия этого приключения была в "Эра глубокой нейроэволюции, с 2017г" https://ailev.livejournal.com/1395639.html). Рецепт один и тот же: сначала сажаем вычисления на GPU уж как можем, а потом оптимизируем эту посадку: подхакиваем весь технологический стек, чтобы он лучше учитывал особенность аппаратуры самого нижнего уровня. Результат: на одной видеокарточке NVIDIA обучается сразу множество моделей. Всё это уже в opensource.
-- Nv-Wavenet, отданная NVIDIA в open source reference implementation of a CUDA-enabled autoregressive WaveNet inference engine, https://devblogs.nvidia.com/nv-wavenet-gpu-speech-synthesis/. Результат -- речь с частотой дискретизации 24kHz может одновременно (партией, batch) генерироваться в одном GPU на 26 моделях. Это работа такого же типа, что и по предыдущей ссылке на разгон нейроэволюции: просто адаптация к нижележащему аппаратному уровню.
Так что оптимизирующая компиляция моделей для эффективного исполнения на GPU с последующей сервировкой этих моделей для исполнения по внешним вызовам -- это текущий мейнстрим, открывающий дорогу результатам коннекционистского моделирования к потребителям. Текущая архитектурная задача программной инженерии -- эффективная инфраструктура как по компиляции нескольких моделей в GPU, так и по сервировке этих моделей по индивидуальным запросам. Это нетривиально сделать (по факту, речь идёт об операционной системе для GPU -- или как сейчас бы сказали, "системы виртуализации GPU"), но без этого никуда.
Системный подход -- это прежде всего работа с разнородными моделями. Чтобы из дисциплины он стал практикой, нужно поддержать его инструментарием. Инструмент системного мыслителя -- это моделер, и чаще всего это связывалось с "классическими" системными моделями:
-- системная динамика, system dynamics (упрощённый язык моделирования систем, в которых много откликов/feedbacks с задержками -- а соответствующие дифуры решает компьютер), https://en.wikipedia.org/wiki/System_dynamics.
-- системное моделирование как имитационное моделирование (simulation) мультифизики на акаузальных языках вроде Modelica (http://modelica.org/). Мультифизика это и есть "системность": множество разных моделей одной системы, все модели работают взаимосвязанно. Акаузальность означает, что каждая разная "физика" (и прочие view) на систему моделируются своим набором дифуров, а компьютер решает получающуюся систему дифуров. Тем самым в моделях возможны модули, в которых разрабатываются отдельные "физики" (электрические, механические модели как системы дифуров), и полную мульти-модель из всех систем дифуров сделает компьютер. Ограничение системной динамики на виды дифуров тут снято, появился полнотьюринговый универсальный язык моделирования, который включает в себя работу со временем -- важнейшее свойство для системного моделирования. Этот подход продолжает развиваться в направлении как отказа от Modelica и постепенному переходу к программированию на обычных расширяемых языках программирования -- Julia (https://ailev.livejournal.com/1366789.html), так и наоборот -- использованию "системных моделей" на Modelica из обычного языка, например Wolfram (с версии 11.3, см. раздел "системное моделирование" в https://habr.com/company/wolfram/blog/353972/). Первый подход снимает ограничение по языку, второй подход позволяет использовать множество уже наработанных в Modelica инженерных/физических библиотек.
-- моделирование MBSE, которое сводится к архитектурному моделированию на языках прежде всего SysML и AADL, а далее Capella и даже ArchiMate 3.0 (https://ailev.livejournal.com/1422923.html). Чтобы не держать основные архитектурные решения в голове, их оформляют как графические или текстовые (AADL имеет штатное текстовое представление, не только графическое!) модели. Правда, в отличие от системной динамики и системного моделирования на Modelica, эти модели нельзя передать на исполнение -- их нельзя сервировать (model serving). Много лет разговоры про "исполняемые архитектуры" остаются разговорами, а хотелки -- хотелками.
Вот эта сервировка моделей, которая недоступна для моделей MBSE и является предметом бурного развития на ещё одном сорте моделей -- коннективистских моделей из deep learning. В отличие от "системных моделей" любого сорта их не разрабатывают/программируют/составляют/моделируют, а их "выучивают" (train). А затем их задействуют в выводе (inference). Для обеспечения запросов к модели её нужно засунуть в какой-то сервер (server), чтобы она смогла выдать полезное поведение на внешнем интерфейсе -- это и есть "сервировка модели", буквально "подача на блюдечке с голубой каёмочкой". Как написано в Oxford dictionary, serving -- a quantity of food suitable for or served to one person. И хотя в model serving явно отглагольное существительное, обозначающее обёртку модели в какой-то сервер, все эти значения связаны: одно вычисление с моделью может быть отгружено/сервировано для кого-то одного запросившего это вычисление.
У меня был когда-то список критериев оценки софта для моделирования http://ailev.livejournal.com/1041274.html. Его давно пора бы обновить, ибо современные моделеры уже более-менее полно этим критериям соответствуют (см., например, https://www.visual-paradigm.com/editions/). Но вот можно начинать добавлять к этим критериям возможности по сервировке моделей -- и отнюдь не только публикацию текстовых или графических моделей в интернете, но и какой-то запуск моделей на исполнение (в простейшем случае -- проверка корректности модели, в более сложных случаях какие-то другие вычисления по модели -- при этом для одной модели возможно ведь много разных запросов, много разных вычислений, плюс вычисления делаются с какими-то входными параметрами).
Итого:
-- терминология моделирования (обучение, компиляция моделей), понимание исполнимости моделей (разделение работ по model training и compilation от работ по inference), инструментарий для обеспечения модульности моделей (доступа к исполнимым моделям как к сервисам, т.е. model serving) сегодня развиваются быстрее всего в machine/deep learning.
-- когнитивные архитектуры будут не столько монолитными сервисами, сколько реализуемыми по бессерверной архитектуре, но с активным использованием концепции model serving. Всяческие lifelong learning и multitask learning никак этого не меняют, хотя и привносят свои нюансы.
-- новая вычислительная архитектура с GPU (https://ailev.livejournal.com/1416697.html) потребует перетряхивания всего софтверного стека, придётся подумать о многозадачной многопользовательской операционной системе -- хотя не факт, что это именно так будет называться.
-- в системном мышлении и системной инженерии нужно всячески заимствовать эти современные наработки по моделированию. Опора только на работы группы AtlanMod/Model-driven engineering (http://web.imt-atlantique.fr/x-info/atlanmod/index.php?title=Main_Page) и прочих любителей "формального моделирования" с игнорированием новых коннективистских моделей -- это путь в тупик истории. Напомню, что я уже писал про коннекционистскую проблематизацию системного подхода https://ailev.livejournal.com/1252230.html, и понимание происходящего с модульностью коннекционистских моделей (а сервировка модели-модуля имеет к этому непосредственное отношение) ключевое для становления очередной версии системного подхода. Ну, или системные мыслители в ближайшую пару лет хлопнут ушами, и очередная версия мышления с использованием многомасштабного (уровни системы) мегамоделирования (мета-модели -- это использование priors, http://ailev.livejournal.com/1305176.html, мультимоделирование -- это междисциплинарность с merge онтологий в многомерном пространстве смыслов) на всём спектре мышления (https://thpectrum.livejournal.com/8785.html, https://ailev.livejournal.com/1390318.html) уже будет называться не системным подходом, а как-нибудь иначе. Ну, мы за термины не держимся, просто нужно понимать, где фронтир мыслительных практик. И этот фронтир не в хитрых способах мышления человека, в хитрых способах мышления коллектива людей и машин. Жизнь опять поменялась.
-- в deep learning озаботились выдачей моделей внешним потребителям
-- в GPU неминуемо создание чего-то типа "многозадачной и многопользовательской операционной системы для GPU".
-- в системное мышление нужно срочно добавлять работу с коннективистскими моделями, вплоть до заимствования терминологии
Речь идёт об ещё одном специфическом уровне интеллект-стека: model server (сервер модели) как программный слой, предоставляющий доступ к обученной модели со стороны других модулей когнитивной архитектуры. Коннективистскую модель нужно сначала обучить, потом компилировать для какой-то аппаратной архитектуры (например, использовав NVIDIA TensorRT), потом её нужно сделать доступной извне для запросов на исполнение -- сервировать. Об этом уже появился ряд статей и презентаций: январская 2018 "The Rise of the Model Servers. New Tools for Deploying Machine Learning Models to Production" (https://medium.com/@vikati/the-rise-of-the-model-servers-9395522b6c58), мартовская 2018 презентация Model Serving for Deep Learning от AWS (https://www.slideshare.net/hornsby/model-serving-for-deep-learning) и т.п.. Это очень хороший тренд, он крайне радует. Его появление означает, что обученные нейронные сети/коннективистские модели стали полезными и нужно выдавать внешним пользователям (а не только самим разработчикам, обучающим модели) интерфейс сервиса по запуску этих моделей на исполнение. Нейросетки выходят в люди, буквально. Ешьте ваши модели, сервировано.
Пикантность ситуации задаёт то, что в deep learning для сервировки моделей набирают силу serverless architectures (коротко в https://martinfowler.com/bliki/Serverless.html и более глубоко в https://martinfowler.com/articles/serverless.html). Так что по факту речь идёт о serverless model serving (мне это напомнает ещё один такой же странный термин про model-free learning и результирующим model-free models).
Термины были известны давно, но всплеск использования терминологии пришёл от сотрудников Amazon, которые занялись проблемой в октябре-ноябре 2017 -- использование Lambda на AWS для нейронных сеток. Вот "Serving deep learning models in a serverless platform" (октябрь 2017, апдейт февраль 2018), https://arxiv.org/abs/1710.08460. Вот пример типичной работы октября 2017, Serving PyTorch Models on AWS Lambda with Caffe2 & ONNX, https://machinelearnings.co/serving-pytorch-models-on-aws-lambda-with-caffe2-onnx-7b096806cfac. Вот буквально через месяц в ноябре 2017, Serverless serving of TensorFlow models with AWS lambda, https://github.com/Vetal1977/tf_aws_lambda. Сервировка моделей и сегодня активно продвигается специалистами Amazon, так что этот термин не забудется. Вот самое свежее их выступление по model serving, от 24 апреля 2018 -- https://www.youtube.com/watch?v=x1yvKogYAB4
Конечно, ключевая (enabling) тут технология -- ONNX (и, возможно, когда-нибудь будет и NNEF, но о нём что-то последнее время не слышно -- https://ailev.livejournal.com/1395131.html). Сервировка моделей в глубоком обучении -- это как раз и есть оформление массового доступа к откомпилированной сетке-модели. Если есть стандарт, в котором можно передать модель с серверов, на которых она обучалась на сервера, где она будет сервирована, то дальше всё просто -- речь идёт о хорошо оформленном уровне технологического интеллект-стека.
Важная технологическая задача тут -- погружение model serving на современную аппаратуру, то есть в GPU. В связи с особенностями GPU, там можно запускать сразу много моделей, и model serving должно это учитывать. Оригинальная статья от Amazon AWS как раз затрагивает этот вопрос, рассматривая возможные пути развития бессерверной сервировки моделей -- https://arxiv.org/abs/1710.08460. Текущая задача, похоже, научиться использовать одну железку GPU как для обучения, так и для сервировки множества моделей. Вот только парочка работ из этой области:
-- обучение через нейроэволюцию: все игры Атари за 4 часа на декстоп-компьютере с видеокартой (нейроэволюционеры из Uber продолжают жечь: https://eng.uber.com/accelerated-neuroevolution/, прошлая серия этого приключения была в "Эра глубокой нейроэволюции, с 2017г" https://ailev.livejournal.com/1395639.html). Рецепт один и тот же: сначала сажаем вычисления на GPU уж как можем, а потом оптимизируем эту посадку: подхакиваем весь технологический стек, чтобы он лучше учитывал особенность аппаратуры самого нижнего уровня. Результат: на одной видеокарточке NVIDIA обучается сразу множество моделей. Всё это уже в opensource.
-- Nv-Wavenet, отданная NVIDIA в open source reference implementation of a CUDA-enabled autoregressive WaveNet inference engine, https://devblogs.nvidia.com/nv-wavenet-gpu-speech-synthesis/. Результат -- речь с частотой дискретизации 24kHz может одновременно (партией, batch) генерироваться в одном GPU на 26 моделях. Это работа такого же типа, что и по предыдущей ссылке на разгон нейроэволюции: просто адаптация к нижележащему аппаратному уровню.
Так что оптимизирующая компиляция моделей для эффективного исполнения на GPU с последующей сервировкой этих моделей для исполнения по внешним вызовам -- это текущий мейнстрим, открывающий дорогу результатам коннекционистского моделирования к потребителям. Текущая архитектурная задача программной инженерии -- эффективная инфраструктура как по компиляции нескольких моделей в GPU, так и по сервировке этих моделей по индивидуальным запросам. Это нетривиально сделать (по факту, речь идёт об операционной системе для GPU -- или как сейчас бы сказали, "системы виртуализации GPU"), но без этого никуда.
Системный подход -- это прежде всего работа с разнородными моделями. Чтобы из дисциплины он стал практикой, нужно поддержать его инструментарием. Инструмент системного мыслителя -- это моделер, и чаще всего это связывалось с "классическими" системными моделями:
-- системная динамика, system dynamics (упрощённый язык моделирования систем, в которых много откликов/feedbacks с задержками -- а соответствующие дифуры решает компьютер), https://en.wikipedia.org/wiki/System_dynamics.
-- системное моделирование как имитационное моделирование (simulation) мультифизики на акаузальных языках вроде Modelica (http://modelica.org/). Мультифизика это и есть "системность": множество разных моделей одной системы, все модели работают взаимосвязанно. Акаузальность означает, что каждая разная "физика" (и прочие view) на систему моделируются своим набором дифуров, а компьютер решает получающуюся систему дифуров. Тем самым в моделях возможны модули, в которых разрабатываются отдельные "физики" (электрические, механические модели как системы дифуров), и полную мульти-модель из всех систем дифуров сделает компьютер. Ограничение системной динамики на виды дифуров тут снято, появился полнотьюринговый универсальный язык моделирования, который включает в себя работу со временем -- важнейшее свойство для системного моделирования. Этот подход продолжает развиваться в направлении как отказа от Modelica и постепенному переходу к программированию на обычных расширяемых языках программирования -- Julia (https://ailev.livejournal.com/1366789.html), так и наоборот -- использованию "системных моделей" на Modelica из обычного языка, например Wolfram (с версии 11.3, см. раздел "системное моделирование" в https://habr.com/company/wolfram/blog/353972/). Первый подход снимает ограничение по языку, второй подход позволяет использовать множество уже наработанных в Modelica инженерных/физических библиотек.
-- моделирование MBSE, которое сводится к архитектурному моделированию на языках прежде всего SysML и AADL, а далее Capella и даже ArchiMate 3.0 (https://ailev.livejournal.com/1422923.html). Чтобы не держать основные архитектурные решения в голове, их оформляют как графические или текстовые (AADL имеет штатное текстовое представление, не только графическое!) модели. Правда, в отличие от системной динамики и системного моделирования на Modelica, эти модели нельзя передать на исполнение -- их нельзя сервировать (model serving). Много лет разговоры про "исполняемые архитектуры" остаются разговорами, а хотелки -- хотелками.
Вот эта сервировка моделей, которая недоступна для моделей MBSE и является предметом бурного развития на ещё одном сорте моделей -- коннективистских моделей из deep learning. В отличие от "системных моделей" любого сорта их не разрабатывают/программируют/составляют/моделируют, а их "выучивают" (train). А затем их задействуют в выводе (inference). Для обеспечения запросов к модели её нужно засунуть в какой-то сервер (server), чтобы она смогла выдать полезное поведение на внешнем интерфейсе -- это и есть "сервировка модели", буквально "подача на блюдечке с голубой каёмочкой". Как написано в Oxford dictionary, serving -- a quantity of food suitable for or served to one person. И хотя в model serving явно отглагольное существительное, обозначающее обёртку модели в какой-то сервер, все эти значения связаны: одно вычисление с моделью может быть отгружено/сервировано для кого-то одного запросившего это вычисление.
У меня был когда-то список критериев оценки софта для моделирования http://ailev.livejournal.com/1041274.html. Его давно пора бы обновить, ибо современные моделеры уже более-менее полно этим критериям соответствуют (см., например, https://www.visual-paradigm.com/editions/). Но вот можно начинать добавлять к этим критериям возможности по сервировке моделей -- и отнюдь не только публикацию текстовых или графических моделей в интернете, но и какой-то запуск моделей на исполнение (в простейшем случае -- проверка корректности модели, в более сложных случаях какие-то другие вычисления по модели -- при этом для одной модели возможно ведь много разных запросов, много разных вычислений, плюс вычисления делаются с какими-то входными параметрами).
Итого:
-- терминология моделирования (обучение, компиляция моделей), понимание исполнимости моделей (разделение работ по model training и compilation от работ по inference), инструментарий для обеспечения модульности моделей (доступа к исполнимым моделям как к сервисам, т.е. model serving) сегодня развиваются быстрее всего в machine/deep learning.
-- когнитивные архитектуры будут не столько монолитными сервисами, сколько реализуемыми по бессерверной архитектуре, но с активным использованием концепции model serving. Всяческие lifelong learning и multitask learning никак этого не меняют, хотя и привносят свои нюансы.
-- новая вычислительная архитектура с GPU (https://ailev.livejournal.com/1416697.html) потребует перетряхивания всего софтверного стека, придётся подумать о многозадачной многопользовательской операционной системе -- хотя не факт, что это именно так будет называться.
-- в системном мышлении и системной инженерии нужно всячески заимствовать эти современные наработки по моделированию. Опора только на работы группы AtlanMod/Model-driven engineering (http://web.imt-atlantique.fr/x-info/atlanmod/index.php?title=Main_Page) и прочих любителей "формального моделирования" с игнорированием новых коннективистских моделей -- это путь в тупик истории. Напомню, что я уже писал про коннекционистскую проблематизацию системного подхода https://ailev.livejournal.com/1252230.html, и понимание происходящего с модульностью коннекционистских моделей (а сервировка модели-модуля имеет к этому непосредственное отношение) ключевое для становления очередной версии системного подхода. Ну, или системные мыслители в ближайшую пару лет хлопнут ушами, и очередная версия мышления с использованием многомасштабного (уровни системы) мегамоделирования (мета-модели -- это использование priors, http://ailev.livejournal.com/1305176.html, мультимоделирование -- это междисциплинарность с merge онтологий в многомерном пространстве смыслов) на всём спектре мышления (https://thpectrum.livejournal.com/8785.html, https://ailev.livejournal.com/1390318.html) уже будет называться не системным подходом, а как-нибудь иначе. Ну, мы за термины не держимся, просто нужно понимать, где фронтир мыслительных практик. И этот фронтир не в хитрых способах мышления человека, в хитрых способах мышления коллектива людей и машин. Жизнь опять поменялась.