OpenPose, MediaPipe Pose, RTMPose, ViTPose – стек pose-трекинга для видео в 2026

Автор: Николай СапуновОбновлено: август 202630 мин чтения
Содержание статьи +

TL;DR

Pose tracking – определение скелета человека на кадре видео – это вторая по популярности задача компьютерного зрения в видеопродуктах после распознавания лиц. К 2026 году рынок моделей консолидируется вокруг четырёх основных семейств, из которых почти каждая production-команда выбирает одно: OpenPose – оригинальная система 2017 года, заложившая основы терминологии в индустрии; MediaPipe Pose (BlazePose) – мобильная модель от Google, работающая в любом браузере со скоростью 30 FPS; RTMPose – надёжная рабочая лошадка от OpenMMLab, обеспечивающая 70–90 FPS на CPU при точности уровня state-of-the-art; и ViTPose – базовый Vision Transformer, набирающий более 80 пунктов на бенчмарке COCO и оправдывающий использование GPU. Главное решение здесь – не выбор модели, а определение места её запуска: в браузере, на edge-устройстве или на сервере. Топология развертывания влияет на задержку, стоимость и уровень конфиденциальности значительно сильнее, чем выбор конкретного семейства моделей. В статье мы разбираем полный pipeline, четыре семейства моделей, критерии выбора топологии, четыре типичные production-ловушки и архитектурный паттерн, который применяем в Фора Софт при внедрении pose-трекинга в фитнес, телемедицину, видеонаблюдение, спортивную аналитику и e-learning.

Зачем это нужно

Если ваш продукт подключает к человеку веб-камеру или CCTV – фитнес-приложение, оценивающее приседания; телемедицинскую консультацию, измеряющую амплитуду движений; спортивную аналитику, сравнивающую две подачи; систему видеонаблюдения, фиксирующую падение или драку; e-learning-платформу, оценивающую урок танца; ритейл-аналитику, подсчитывающую, сколько покупателей тянутся к верхней полке; детский йога-апп, превращающий практику в игру – рано или поздно вы столкнётесь с необходимостью наложить на тело скелет. Pose tracking – это технология, которая ставит 17, 33 или 133 точки на тело человека и соединяет их правильными отрезками. Она существует с 2017 года, но выбор моделей, паттерны развёртывания, лимиты задержки и последствия для приватности заметно изменились с 2024 года. То, что в 2018-м требовало research-GPU и шестизначного бюджета (например, подсчёт приседаний в приложении на телефоне), сегодня бесплатно работает во вкладке браузера. То, что в 2020-м требовало дообученной модели (например, сигнал о падении в коридоре дома престарелых), сегодня работает на edge-устройстве за 50 долларов с использованием публичного чекпоинта. В этой статье – как выбрать модель, где её запускать и как избежать четырёх типичных режимов отказа, на которых спотыкаются 90 % production-развёртываний.

Что такое pose tracking – и зачем нужен скелет

У тела есть суставы: голова соединяется с шеей, шея – с плечами, плечи – с локтями, локти – с запястьями. Модель pose на вход получает кадр с веб-камеры и выдаёт пиксельные координаты этих суставов, а также значение уверенности (confidence score) для каждой точки. Эти точки называются keypoints. Отрезки, соединяющие их, образуют skeleton. Это осознанное сжатие человеческого тела в компактный, низкоразмерный, структурированный объект, с которым последующий код работает эффективно.

Зачем сжимать? Потому что исходные пиксели – тяжёлые, а координаты суставов – лёгкие. Кадр 1280 × 720 – это около 3 МБ RGB-данных. Оценка позы из 17 двумерных ключевых точек – 68 чисел с плавающей точкой плюс 17 значений уверенности, примерно 300 байт. Скелет в 10 000 раз меньше по объёму, чем кадр. Именно это сжатие делает pose-фичи практичными: любой downstream-алгоритм – детектор падений, счётчик приседаний, распознавание жестов, перевод языка жестов, оценка эргономического риска – работает с этими 300 байтами, а не с 3 МБ, и потому запускается дешево, офлайн и прямо в браузере.

Число ключевых точек зависит от используемого семейства моделей. Академический бенчмарк COCO Keypoint, стандартизированный с 2017 года, определяет 17 точек: 5 на голове (нос, два глаза, два уха), 6 на верхней части тела (два плеча, два локтя, два запястья) и 6 на нижней (два бедра, два колена, две лодыжки). MediaPipe расширяет этот набор до 33 точек, добавляя кисти, стопы и дополнительные точки на лице. Вариант RTMPose для полного тела, RTMW, идёт ещё дальше – 133 точки, включая фаланги пальцев и плотно расположенные точки на лице. Однако больше ключевых точек – не всегда лучше: это увеличивает вычислительные затраты, усложняет обучение, а большинство задач downstream используют лишь 8–12 точек. О выборе модели мы поговорим позже.

Выход pose-модели разделяется по второй оси: 2D и 3D. 2D-ключевая точка находится на пиксельной позиции (x, y) внутри входного кадра. 3D-ключевая точка задана в координатной системе, привязанной к бёдрам человека, с измерениями в (x, y, z) – модель указывает не только положение сустава на экране, но и его смещение вглубь или вперёд относительно камеры. 3D-поза необходима фитнес-приложениям для анализа бокового выпада, который камера видит сбоку, и телемедицине – для измерения отведения плеча. 2D-поза достаточна для детекции падений, распознавания жестов и видеонаблюдения – разница между ними оказывается меньше, чем может показаться.

Рисунок 1. Pose tracking – это шаг сжатия. Модель преобразует 3 МБ пикселей в 300 байт структурированных координат суставов, с которыми последующие компоненты работают эффективно.

Четыре семейства pose-моделей в 2026

Почти каждый production-деплой в 2026 году выбирает одно из четырёх семейств. Рассмотрим их в хронологическом порядке – каждое последующее решало проблему, унаследованную от предыдущего.

OpenPose – система 2017 года, задавшая стандарт

OpenPose была представлена на CVPR 2017 Чжэ Цао и коллегами из Carnegie Mellon University. Это первая система, способная обнаруживать всех людей на изображении, разметить все суставы и соединить их в отдельные скелеты – даже при перекрытии людей, что в литературе называют multi-person bottom-up pose estimation. Работа системы строится в два этапа. На первом шаге heatmap-сеть для каждого из 17 типов суставов выдаёт пер-пиксельную вероятность того, что данный пиксель соответствует конкретному суставу. На втором этапе вторая сеть для каждой пары суставов генерирует пер-пиксельный двумерный вектор – part affinity field, указывающий направление вдоль конечности от одного сустава к другому. Декодер использует эти поля для сборки суставов в скелеты.

OpenPose – это модель, обученная распознавать позы людей. Почти каждая работа после 2017 года её цитирует. Оригинальная реализация обеспечивает 8–22 кадра в секунду на NVIDIA TITAN X в зависимости от разрешения входного изображения и около 80 % средней точности на тесте COCO Keypoint. Код доступен по адресу github.com/CMU-Perceptual-Computing-Lab/openpose и до сих пор поддерживается.

В 2026 году знание о OpenPose остаётся важным по двум причинам. Первая – это базовый уровень, с которым сравнивают все остальные решения в академической литературе: когда статья 2024 года заявляет, что «обогнала OpenPose на 12 пунктов», она имеет в виду именно этот baseline. Вторая – лицензия OpenPose non-commercial: Carnegie Mellon распространяет модель на условиях, запрещающих коммерческое использование без отдельного соглашения. Это ключевой факт с точки зрения соблюдения лицензионных требований, и его часто упускают из виду – мы в Фора Софт уже переписывали pose-решения для трёх клиентов, внедривших OpenPose в коммерческие продукты без разрешения. Не используйте OpenPose в коммерческих продуктах без соглашения с CMU. Выбирайте любое из трёх других семейств – все они доступны под пермиссивными лицензиями.

MediaPipe Pose (BlazePose) – мобильная модель, работающая в браузере

MediaPipe Pose, она же BlazePose, была опубликована Google Research в 2020 году. Это первая модель распознавания поз, спроектированная с нуля для мобильных устройств – каждое архитектурное решение ориентировано на одну цель: достичь 30 кадров в секунду на телефоне уровня Pixel. В отличие от OpenPose, которая запускает тяжёлую сеть heatmap на полном кадре, BlazePose сначала использует лёгкий детектор, находящий одного человека, обрезает изображение по bounding box и затем применяет компактную регрессионную сеть, выдающую 33 ключевых точки напрямую как (x, y, z, visibility). Двухстадийный подход – тот же, что MediaPipe использует для распознавания лиц и отслеживания рук – отлично масштабируется: от Pixel 2 (более 30 FPS на CPU) до современных флагманов (супер-реальное время на GPU).

33-точечный набор BlazePose расширяет COCO-17, добавляя центры ладоней и точки у основания ладоней на каждой руке, а также точки пятки и носка на каждой стопе и дополнительные точки на лице. Именно эти дополнительные точки позволяют MediaPipe Pose различать движения в фитнес-приложениях: полуприсед от полного приседа модель отличает по положению пятки, а сжатый кулак – от открытой ладони – по положению основания ладони.

Точность BlazePose на COCO в последнем опубликованном варианте составляет около 78 % – ниже, чем у GPU-моделей, но значительно выше порога, необходимого для применения в фитнес-приложениях, йоге и распознавании жестов. Модель доступна нативно через Tasks API в JavaScript-пакете @mediapipe/tasks-vision – том же, что мы рекомендовали в уроке про background blur – и работает на WebAssembly с ускорением WebGPU в браузерах Chrome, Edge и Safari начиная с версии 17.4.

В 2026 году MediaPipe Pose станет стандартом для любой in-browser, in-app или on-device функции. Лицензия – пермиссивная, JavaScript-биндинги от разработчиков, сервер не требуется.

RTMPose – производственная лошадка OpenMMLab

RTMPose была опубликована в марте 2023 года командой OpenMMLab из Shanghai AI Lab. Исследование ставит один ключевой вопрос: может ли модель распознавания поз достичь уровня state-of-the-art по точности, при этом работать на CPU достаточно быстро для развертывания в любых условиях? Ответ – да, и секрет в замене heatmap на иное представление выходных данных. В отличие от OpenPose и ViTPose, которые генерируют пер-пиксельные тепловые карты для каждого сустава и затем находят argmax, RTMPose использует Simple Coordinate Classification (SimCC): изображение разбивается на два набора одномерных бинов – один для x, другой для y – и сеть определяет, в какой бин попадает каждый сустав. На выходе получаются две распределения вероятностей для каждого сустава, которые декодер преобразует в координаты с плавающей запятой с помощью взвешенной суммы.

Это важно, потому что карта тепла дороги: вход 256 × 192 порождает карту 64 × 48 на сустав, что составляет миллионы чисел с плавающей запятой. Выход SimCC – два одномерных вектора на сустав, сотни чисел с плавающей запятой. RTMPose-m, средняя версия, показывает 75,8 % COCO AP при 90+ FPS на процессоре Intel i7-11700 (CPU) и 430+ FPS на видеокарте NVIDIA GTX 1660 Ti (GPU). RTMPose-s, компактная версия, – 72,2 % AP при 70+ FPS на процессоре Snapdragon 865. Целостная версия RTMW – 67,0 % AP на COCO-WholeBody (с ключевыми точками рук и лица, 133 точки) при 130+ FPS.

Эти цифры и объясняют, почему RTMPose – стандарт по умолчанию в 2026 году для любого серверного или edge-развёртывания, не требующего GPU. Модель доступна в OpenMMLab MMPose под лицензией Apache 2.0; в репозитории github.com/open-mmlab/mmpose/tree/main/projects/rtmpose представлены ONNX-, TensorRT- и TorchScript-экспорты. Там же – предобученная модель для распознавания всего тела (RTMW) и её 3D-версия (RTMW3D).

ViTPose – базовый Vision Transformer, превышающий 80 пунктов на COCO

ViTPose был представлен на NeurIPS 2022 Юфэем Сюем и коллегами, с расширением ViTPose++ в 2024 году. Архитектура модели намеренно проста: берём обычный Vision Transformer – такой же, что используется для классификации изображений, – предварительно обучаем его на ImageNet-22K и добавляем лёгкий декодер, генерирующий тепловые карты для каждого сустава. Архитектурная простота здесь – не недостаток, а преимущество: ViTPose показывает, что структурные приёмы традиционных свёрточных моделей позы (многоступенчатая доработка, поля аффинности частей тела, отдельные головы для тепловых карт) не нужны, если базовый блок достаточно мощный.

Сработало. ViTPose-H, самый крупный вариант из оригинальной статьи, показывает 80,9 % AP на тестовом наборе MS COCO Keypoint test-dev; ансамбль различных версий ViTPose – 81,1 %, что стало SOTA на момент публикации и остаётся в пределах одного пункта от лучших результатов 2026 года. Меньшие версии тоже демонстрируют хорошие показатели: ViTPose-S – 75,8 AP, ViTPose-L – 78,3 AP. Архитектуру Vision Transformer мы подробно разбираем в готовящемся ViT-уроке; кратко – глобальный механизм самовнимания трансформера улавливает долгосрочные зависимости между частями тела, которые поля восприимчивости CNN пропускают, а именно это и важно для оценки позы.

ViTPose – правильный выбор, если у вас есть GPU и важна каждая единица точности: спортивная аналитика, трансляция в реальном времени, медицинские системы захвата движения. Модель тяжелее RTMPose и не поместится в бюджет CPU, но на одной A10 или L4 работает со скоростью 30–60 кадров в секунду в зависимости от конфигурации.

Рисунок 2. Четыре семейства pose-моделей занимают четыре угла пространства «точность – скорость – развёртывание». Правильный выбор зависит не от того, у кого выше цифра в статье, а от того, где модель будет работать.

Pipeline – детекция, поза, трекинг, сглаживание

Production pose-система – это не просто одна модель, а полноценный конвейер из четырёх стадий. Каждая из них может быть пропущена или упрощена в зависимости от задачи.

Первая стадия – обнаружение людей. Большинство моделей для анализа позы в реальных условиях – такие как MediaPipe, RTMPose, ViTPose – топ-даун: они требуют на входе обрезанное изображение одного человека и возвращают скелет в пределах этого кадра. Перед запуском позовой модели необходимо предварительно найти людей. Для этого используется лёгкий детектор объектов, обученный распознавать только класс person; в 2026 году по умолчанию применяется RTMDet-tiny из OpenMMLab или вариант YOLOv8-person из production lineage YOLO. Детектор выдаёт одну ограничивающую рамку на каждого человека; позовая модель запускается один раз для каждой рамки. (OpenPose – единственное массовое исключение боттом-ап: сначала он находит все суставы, а затем группирует их в людей, так что отдельный детектор не нужен.)

Вторая стадия – сама pose-модель из одного из четырёх вышеперечисленных семейств. Она принимает кадр с человеком и выдаёт ключевые точки.

Третья стадия – tracking. Скелет на кадре 1 и скелет на кадре 2 – никак не связанные объекты, если их не связать: multi-объектный трекер должен присвоить один и тот же track_id одному и тому же человеку на протяжении кадров, чтобы последующий код мог оперировать единой траекторией. Современные системы используют ByteTrack или OC-SORT, применяя их либо к bounding box’ам со стадии 1, либо напрямую к ключевым точкам. Подробно алгоритмы трекинга мы разбираем в уроке про multi-объектный трекинг; для задач, специфичных для позы, по умолчанию используется ByteTrack по bounding box’ам.

Четвёртая стадия – сглаживание. Сырые per-frame оценки keypoints дрожат. То же самое запястье, находящееся в неподвижном состоянии, будет смещаться на 3–4 пикселя от кадра к кадру, поскольку модель чувствительна к шуму на входе. Эта дрожь разрушает downstream-фичи: например, счётчик приседаний, ожидающий пересечения углом между бедром и коленом порога в 90°, срабатывает и сбрасывается десятки раз за одно движение, если положение бедра и колена скачет. В production-системах применяют темпоральный фильтр – обычно One-Euro или фильтр Калмана – к каждому keypoint отдельно. One-Euro – выбор по умолчанию, потому что он отслеживает быстрое движение без задержек, одновременно подавляя низкочастотный шум; официальный pipeline MediaPipe Pose использует его на сервере в качестве финального шага.

Стадию можно пропускать, если use-case это позволяет. Например, браузерное фитнес-приложение, отслеживающее одного человека на коврике, не нуждается в стадии 1 (детектор), поскольку MediaPipe Pose уже включает детектор человека на первой стадии, и не требует стадии 3 (трекер), так как человек только один. А системе видеонаблюдения, следящей за коридором, потребуются все четыре стадии. Подбирайте pipeline под условия развертывания.

Числовой пример – стоимость pose на одном потоке 1280 × 720 при 30 FPS

Вот арифметика для одного потока 1280 × 720 при 30 FPS на современной серверной Intel-CPU.

Детекция (RTMDet-tiny, вход 320 × 320): около 6 мс/кадр. Определение позы (RTMPose-m, вход 256 × 192, один человек): около 8 мс/кадр. Трекинг (ByteTrack по bounding box-ам): около 0,3 мс/кадр. Сглаживание (One-Euro по 17 ключевым точкам): около 0,05 мс/кадр.

Итого на кадр: 14,35 мс.

За секунду: 14,35 × 30 = 430,5 мс CPU-времени.

В одном CPU-ядре доступно 1000 мс в секунду, то есть один поток «съедает» около 43 % одного ядра, оставляя запас производительности для остальных задач приложения. Два потока – это уже нагрузка на второе ядро. Шестнадцать потоков – 16-ядерный сервер. Стоимость на облачном инстансе 2026 года (например, AWS c7i.4xlarge – 16 vCPU, около $0,71/час по on-demand тарифу) составляет примерно $0,045 за поток-час. Именно эта цифра имеет значение в бюджетных расчётах: всё остальное – хранение, дополнительные функции, интерфейс – стоит значительно меньше, чем вычислительные ресурсы самой модели.

Если нужно больше потоков на сервере, не переходите на более лёгкую модель – снижайте частоту pose. Счётчику приседаний не нужны 30 кадров в секунду; 10 FPS вполне достаточно, поскольку угловые скорости движений невелики. Снижение частоты с 30 до 10 FPS позволяет сократить затраты в три раза.

Где запускать – браузер, edge или сервер

Решение о топологии имеет приоритет над всем остальным, потому что место запуска модели определяет стоимость, задержку, уровень защиты конфиденциальности и поведение функции в автономном режиме. Одну и ту же модель можно развернуть в трёх разных местах – с совершенно разными компромиссами.

Развертывание в браузере

Pose-модель крутится во вкладке браузера пользователя, на WebAssembly с WebGPU-ускорением. MediaPipe Pose – единственное семейство из четырёх с first-party браузерной поддержкой через @mediapipe/tasks-vision; остальные можно запустить в браузере через ONNX Runtime Web, но с худшим tooling и большим трением. Стоимость для вас – ноль, compute платит пользователь. Латентность – минимально возможная, кадр не уходит с устройства. Privacy: кадры не покидают устройство, что снимает большую часть GDPR Article 9 поверхности у фитнес-, йога- и gesture-tracking приложений. Trade-off: вы ограничены тем, что может железо пользователя, не можете использовать модель тяжелее ~30 МБ (практический предел для страницы, которая должна загружаться за пару секунд), и не можете обрабатывать много людей на бюджетном устройстве.

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

Развертывание на границе сети

Pose-модель работает на компактном устройстве рядом с камерой – например, NVIDIA Jetson Orin Nano, Intel NUC или Raspberry Pi 5 с Coral USB-ускорителем. RTMPose – стандартный выбор здесь: более 70 кадров в секунду на Snapdragon 865 и сопоставимые показатели на GPU Jetson Orin Nano. Стоимость – это цена edge-устройства, распределённая на срок службы (обычно 3–5 лет). Затраты на задержку – минимальны (единицы миллисекунд плюс время прохождения сигнала по локальной сети, если сервер участвует в обработке). Конфиденциальность: видео остаётся в локальной сети – это идеально для систем видеонаблюдения, аналитики в рознице и промышленных задач, где клиент не хочет отправлять необработанные кадры в облако. Компромисс: вы сами обслуживаете и администрируете оборудование, что с операционной точки зрения сложнее, чем развертывание исключительно в облаке.

Это стандарт для ИИ-камер видеонаблюдения, intelligent video analytics, in-store ритейл-аналитики и индустриального компьютерного зрения.

Развертывание сервера

Pose-модель работает на GPU или CPU в вашем облаке, получая данные с камер. По умолчанию RTMPose используется на CPU, а ViTPose – на GPU. Стоимость рассчитывается по облачному счёту и линейно зависит от количества потоков. Задержка в основном определяется сетевым round-trip (обычно 30–100 мс) плюс время обработки моделью. Конфиденциальность: кадры поступают в ваше облако, поэтому вы должны рассматривать их как персональные данные по GDPR – в биометрических сценариях, таких как распознавание походки, или как обычные персональные данные – в анонимных случаях, например, при подсчёте людей. Компромисс: полная операционная гибкость, но вы платите за каждую минуту каждого потока.

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

Выбор между тремя вариантами редко бывает близким. Use-case определяет топологию, топология – модель.

ТопологияМодель по умолчаниюКто платитPrivacy-постураLatency-бюджет
BrowserMediaPipe PoseУстройство пользователяКадры остаются на устройстве16 мс (бюджет 60 FPS)
EdgeRTMPose-m / -sOne-time hardwareКадры остаются в LAN50 мс (RTT + модель)
ServerRTMPose-m (CPU) / ViTPose-L (GPU)Облачный счёт за потокКадры идут в облако100 мс (RTT + модель)

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

Рисунок 3. Одну и ту же модель позы можно использовать в трёх разных топологиях. Выбор топологии определяет модель, а не наоборот.

Четыре ловушки в продакшене, губящие pose-фичи

Мы в Фора Софт внедрили достаточно pose-фич в видеопродукты. Четыре режима отказа повторяются снова и снова. Это не технические новости – это хорошо известные ловушки, которые каждая production-команда заново открывает, проходя один и тот же болезненный цикл отладки. Вот они.

Первая ловушка – использовать OpenPose в коммерческом продукте без лицензии CMU. OpenPose – модель, на которой большинство команд осваивало pose-детекцию, потому что она повсеместно фигурирует в туториалах, а в README GitHub-репозитория non-commercial-ограничение не выделяется сразу. Оно находится в третьем абзаце файла LICENSE. Мы переписывали pose-функциональность для трёх клиентов, которые обнаружили эту клаузу во время due diligence-аудита – спустя 18 месяцев после запуска. Для коммерческого использования по умолчанию выбирайте MediaPipe Pose, RTMPose или ViTPose. Разница в точности на 2–5 пунктов не стоит юридического риска.

Вторая ловушка – забыть про сглаживание. Сырой per-frame выход дрожит на 3–4 пикселя даже у неподвижного человека. Downstream-фичи, основанные на пороговых срабатываниях – счётчик приседаний, отслеживающий угол в колене; детектор падений, следящий за высотой головы; триггер «рука поднята», реагирующий на положение запястья – ложноположительно срабатывают десятки раз в секунду на необработанных данных. Решение – один фильтр One-Euro на каждый keypoint на последнем этапе pipeline. 15 строк кода, и все downstream-метрики становятся стабильными.

Третья ловушка – работать с моделью на каждом кадре вместо каждого четвёртого. Большинству задач с позой не нужен 30 FPS. Счётчик приседаний, детектор падения, напоминалка об осанке, триггер «рука поднята» – всё это нормально работает на 7–10 кадрах в секунду. Запуск модели раз в четыре кадра и интерполяция скелета между ними сокращают вычислительную нагрузку на 75 % без заметной потери качества. Команды требуют 30 FPS, потому что это нативная частота камеры, а потом удивляются, как растёт облако вычислений без реальной пользы.

Четвёртая ловушка – считать, что 3D keypoints с одной камеры подходят для клинических измерений. Они не подходят. 3D-координата, которую выдаёт MediaPipe Pose, RTMPose-3D или ViTPose-3D, – это оценка глубины по одной камере (monocular depth estimate): модель предсказывает, насколько каждый сустав выступает в сторону камеры, опираясь на паттерны из обучающей выборки. Такая оценка достаточна для анализа приседаний или поз в йоге, где приблизительная глубина сустава не критична. Но она недостаточно точна для измерения угла отведения плеча в физиотерапевтическом отчёте. Если нужны клинически точные 3D-замеры, требуется система из нескольких синхронизированных камер (обычно 2–4) и конвейер триангуляции. Однокамерная оценка глубины – хороший инструмент для обратной связи с пользователем, но не для точных измерений.

Рисунок 4. Четыре ловушки, топящие pose-деплои. Технически ни одна не нова; все они до сих пор переоткрываются каждой командой.

Как выбрать модель – пошаговое руководство

Вот дерево решений, которое мы в Фора Софт используем, когда проект требует pose-фичу. Пять вопросов.

Первый – это коммерческий продукт? Если да – не используйте OpenPose. Лицензия non-commercial закрывает эту возможность. Рассмотрите один из трёх других вариантов.

Второй – где модель работает? Если ответ «в браузере, на устройстве пользователя, для фитнес-, йога- или gesture-control фичи» – это MediaPipe Pose. First-party JavaScript-бинды, 33 keypoints и WebGPU-ускорение делают его единственным разумным выбором для браузера в 2026-м. Если ответ «на маленьком боксе рядом с камерой, для surveillance, retail или индустриального CV» – это RTMPose-m или RTMPose-s на Jetson Orin Nano или эквиваленте. Если ответ «на сервере в нашем облаке, batch или streaming» – переходите к вопросу 3.

Третий – сколько одновременных потоков? Если «более 10 на сервер» – выбирайте RTMPose-m на CPU: 90+ FPS на ядро означают, что 16-ядерный сервер справится с десятками потоков. Если «менее 10 на сервер, но важна каждая единица точности» – ViTPose-L на одной GPU.

Четвёртый вопрос – нужны ли whole-body keypoints? Если в downstream-задаче используются пальцы (например, для распознавания языка жестов), плотные точки лица (для анализа мелких эмоций или внимания) или полный набор из 133 точек – используйте RTMW по умолчанию. Если же достаточно COCO-17 или BlazePose-33 (например, для подсчёта приседаний, детекции падений или триггеров жестов) – не платите за более тяжёлую модель.

Пятый – нужны ли точные 3D-замеры? Если да – потребуется многокамерная система с триангуляцией, а не однокамерная модель. Если же нужна «примерно 3D» – например, для UX-обратной связи – подойдут 3D-режим MediaPipe Pose или RTMW3D.

Дерево принимает решение за 90 секунд. Остальной инженеринг – выбор детектора, трекера, фильтра – зависит от этих пяти ответов.

Где Фора Софт вписывается

Мы в Фора Софт внедряли pose-фичи в полудюжину продуктовых категорий. Паттерны – те, что описаны в этой статье.

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

В e-learning – MediaPipe Pose для уроков танца и йоги, где модель полностью вращается во вкладке студента.

В телемедицине – RTMPose на сервере для измерения диапазона движений (range of motion) с использованием многокамерной системы, когда консультации требуют клинических 3D-данных высокого качества.

В OTT и вещательной аналитике – ViTPose для спортивной аналитики: у вещателей, которым нужно накладывать pose-данные на спортсменов, есть бюджет на GPU и высокие требования к точности.

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

Выбор модели всегда зависит от архитектуры развёртывания и конкретного use-case; архитектурные решения, описанные в статье, мы применяем на каждом старте проекта.

Ключевые выводы

  • В 2026 году выделяются четыре ключевых семейства: OpenPose, MediaPipe Pose, RTMPose и ViTPose.
  • OpenPose – некоммерческий проект; использовать его в платных продуктах без лицензии CMU нельзя.
  • MediaPipe Pose – стандартный выбор для браузеров; RTMPose – для CPU и edge-устройств; ViTPose – для GPU и серверных решений.
  • Архитектура развёртывания определяет выбор модели, а не наоборот.
  • Всегда применяйте One-Euro-фильтр для сглаживания ключевых точек – иначе пороги в последующих этапах будут срабатывать из-за дрожания.
  • Однокамерная 3D-реконструкция – это фича пользовательского опыта, а не клинический измерительный инструмент.

Что читать дальше

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.