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

TL;DR

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

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

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

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

У тела есть суставы. Голова соединяется с шеей, шея с плечами, плечи с локтями, локти с запястьями. Pose-модель принимает на вход кадр с веб-камеры и выдаёт пиксельные координаты этих суставов плюс confidence-скор каждой точки. Эти точки называются keypoints. Отрезки, соединяющие их, образуют skeleton. Это сознательное сжатие тела человека в маленький, низкоразмерный, структурированный объект, с которым downstream-код работает дёшево.

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

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

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

Нажмите, чтобы увеличить

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

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

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

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

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

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

MediaPipe Pose (BlazePose) – mobile-first модель, идущая в браузере

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

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

Точность BlazePose на COCO в последнем опубликованном варианте – около 78 %, ниже GPU-моделей, но сильно выше порога для production-фитнеса, йоги и распознавания жестов. Модель идёт нативно как 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-бинды first-party, сервер не нужен.

RTMPose – production-лошадка OpenMMLab

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

Это важно, потому что heatmap дороги: вход 256 × 192 порождает 64 × 48 heatmap на сустав, миллионы float. SimCC-выход – два одномерных вектора на сустав, сотни float. 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. Whole-body вариант RTMW – 67,0 % AP на COCO-WholeBody (с keypoints рук и лица, 133 точки) на 130+ FPS.

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

ViTPose – Vision Transformer baseline, переваливающий 80 пунктов на COCO

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

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

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

Нажмите, чтобы увеличить

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

Production pose-система – это больше, чем одна модель. Полный pipeline – четыре стадии, каждую из которых можно пропустить или упростить в зависимости от use-case.

Первая стадия – person detection. Большинство production pose-моделей – MediaPipe, RTMPose, ViTPose – top-down: они ждут на входе обрезанное изображение одного человека и выдают скелет внутри этого crop. Перед запуском кто-то должен найти людей. Детектор – лёгкий object detector, обученный искать только класс person; в 2026-м дефолт – это RTMDet-tiny из того же OpenMMLab или вариант YOLOv8-person из production lineage YOLO. Детектор выдаёт по одной bounding box на человека; pose-модель крутится по разу на каждый box. (OpenPose – единственное mainstream-исключение bottom-up: сначала находит все суставы, потом собирает в людей, отдельный детектор не нужен.)

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

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

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

Пропускать стадию можно, когда use-case позволяет. Browser-side фитнес-апп, отслеживающий одного человека на коврике, не нуждается в стадии 1 (детектор), потому что MediaPipe Pose уже включает person detector в первой стадии, и не нуждается в стадии 3 (трекер), потому что человек один. Surveillance-системе, смотрящей в коридор, нужны все четыре. Подгоняйте pipeline под деплой.

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

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

Детекция (RTMDet-tiny, вход 320 × 320): около 6 мс/кадр. Pose (RTMPose-m, вход 256 × 192, один человек): около 8 мс/кадр. Tracking (ByteTrack по bounding box-ам): около 0,3 мс/кадр. Smoothing (One-Euro по 17 keypoints): около 0,05 мс/кадр.

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

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

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

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

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

Решение о топологии доминирует над всем остальным, потому что место запуска модели определяет стоимость, латентность, privacy-постуру и offline-поведение фичи. Одна и та же модель деплоится в трёх разных местах с очень разными trade-off-ами.

Browser deployment

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

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

Edge deployment

Pose-модель крутится на маленьком боксе рядом с камерой – NVIDIA Jetson Orin Nano, Intel NUC или Raspberry Pi 5 с Coral USB-ускорителем. RTMPose – дефолт здесь: 70+ FPS на Snapdragon 865 и аналогичные числа на GPU Jetson Orin Nano. Стоимость – цена edge-бокса, амортизированная на срок жизни (обычно 3–5 лет). Латентность – низкая (single-digit миллисекунды плюс LAN round-trip, если сервер участвует в ответе). Privacy: кадры остаются в локальной сети, что – правильная постура для surveillance, retail-аналитики и индустриальных кейсов, где заказчик не хочет слать сырое видео в облако. Trade-off: вы шипите и админите железо, что операционно тяжелее cloud-only деплоя.

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

Server deployment

Pose-модель крутится на GPU или CPU в вашем облаке, питаемая потоками с камер. RTMPose – дефолт для CPU; ViTPose – дефолт для GPU. Стоимость – облачный счёт, линейно по числу потоков. Латентность – доминируется сетевым round-trip (обычно 30–100 мс) плюс время модели. Privacy: кадры текут в ваше облако, то есть вы оперируете ими как персональными данными по GDPR (для biometric-identifying кейсов вроде gait recognition) или как обычными персональными данными (для анонимных кейсов вроде подсчёта толпы). Trade-off: полная операционная гибкость, но платите за каждую минуту каждого потока.

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

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

Эту табличку мы используем как первое, что выбирает проект. Всё остальное – вариант модели, batch-size, FPS – уточнение поверх.

Нажмите, чтобы увеличить

Четыре production-ловушки, топящие 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-фичи с пересечением порогов – счётчик приседаний, следящий за углом hip-knee; детектор падения, следящий за высотой головы; триггер «рука поднята», следящий за позицией запястья – спуриозно срабатывают десятки раз в секунду на сыром выходе. Фикс – один One-Euro-фильтр на keypoint в последнем шаге pipeline. 15 строк кода, трансформирует все downstream-метрики.

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

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

Нажмите, чтобы увеличить

Как выбрать модель – walkthrough

Вот дерево решений, которое мы в Фора Софт применяем, когда проект просит 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-фича использует пальцы (перевод языка жестов), плотные точки лица (мелкие emotion/attention-фичи) или весь набор 133 точек – RTMW дефолт. Если только COCO-17 или BlazePose-33 (счёт приседов, fall detection, gesture-триггеры) – не платите за более тяжёлую модель.

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

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

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

Мы в Фора Софт шипили pose-фичи в полудюжину продуктовых категорий. Паттерны – те, что в этой статье. В видеоконференциях – MediaPipe Pose для browser-side gesture-триггеров: hand raise, wave-to-acknowledge, – где не важно, кто человек. В e-learning – MediaPipe Pose для уроков танца и йоги, где модель полностью крутится во вкладке студента. В телемедицине – RTMPose на сервере для замеров range of motion, с multi-camera rig, когда консультации нужны clinical-grade 3D-данные. В OTT и broadcast contribution – ViTPose для спортивной аналитики: у вещателей, которые хотят накладывать pose-данные поверх атлетов, есть GPU-бюджет и accuracy-требование. В видеонаблюдении и индустриальном CV – RTMPose на Jetson-edge для детекции падения, драк и эргономического риск-скоринга. Выбор модели всегда downstream от топологии деплоя и use-case; архитектурные решения, описанные в статье, мы принимаем на каждом kickoff проекта.

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

• В 2026-м значимы четыре семейства: OpenPose, MediaPipe Pose, RTMPose и ViTPose.
• OpenPose – non-commercial; не шипьте его в платный продукт без лицензии CMU.
• MediaPipe Pose – дефолт для браузера; RTMPose – для CPU/edge; ViTPose – для GPU/сервера.
• Топология деплоя выбирает модель, а не наоборот.
• Всегда сглаживайте keypoints One-Euro-фильтром – иначе downstream-пороги сработают на дрожи.
• Single-camera 3D – это UX-фича, а не клинический измерительный инструмент.

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

• YOLO production lineage – v8, v9, v10, v11, v12 – детектор человека, питающий top-down pose-модели.
• Multi-object tracking – DeepSORT, ByteTrack, OC-SORT – третья стадия pose-pipeline.
• Латентность, топология деплоя и real-time vs batch – фреймворк выбора топологии, применяемый здесь.