Pull to refresh
116
0
Алексей @AlexeyAB

Пользователь

Send message

Да, автор статьи зачем-то занижает относительные числа по России, и уделяет избыточное внимание абсолютным значениям, которые имеют ноль смысла.

А то вроде в США и убийств больше, и наркомании больше, и медицина дорогая и недоступная большинству, но:

Смертей (на 1млн человек) за 2017 год:
- США - 8 700
- Россия - 12 400 (на 43% больше, чем в США)

Средняя продолжительность жизни:

- США - 77 лет
- Россия - 71 год (на 6 лет меньше, чем в США)

Уже 10 лет как North Bridge интегрирован в CPU (Intel/AMD/...). По вашей же ссылке: Modern Intel Core processors have the northbridge integrated on the CPU die, where it is known as the uncore or system agent.

  1. Два CPU соединяются между собой напрямую оптоволоконным PCIe-кабелем длинной 30 метров.

  2. Можно Tree, например, CPU со 128 lanes PCIe4.0 = 256 GB/s = 2048 Gbit/s на CPU, две ветки вниз по 512 Gbit/s и одна вверх 1024 Gbit/s. Но CPU должен поддерживать NTB, иначе PCIe-switch-и нужны. Это может выглядеть или как обычная TCP/IP сеть IPoPCIe, или память всех CPU/GPU может выглядеть как обычные массив/массивы в user-space куда можно писать по raw-указателю: somearray[713] = 123. (Там есть пару нюансов с реальной битностью физической адресации CPU, и нюанс с QPI)

Если не используется PCIe-switch, как было предложено, то GPU и Infiniband физически подключены не напрямую, а через CPU, поэтому не могут обойти CPU в принципе. В этом случае RDMA позволяет обойти RAM и ожидание свободных CPU-Cores, но всегда использует CPU-PCIe-Controller.

CPU состоит из (Cores, Cache L1/L2/L3, North Bridge (PCIe-controller, ...), ...).

  • Без RDMA и Без PLX-PCIe-switch, сигнал идет:

    GPU->PCIe->CPU(PCIe-controller)->CPU(RAM/cache-L3)->CPU(Core)->CPU(PCIe-controller)->PCIe->Infiniband->PCIe->CPU(PCIe-controller)->CPU(RAM/cache-L3)->CPU(Core)->CPU(PCIe-controller)->PCIe->GPU

    (CPU-cache-L3 снупит данные, которые идут из GPU в CPU-RAM)

  • С RDMA и Без PLX-PCIe-switch, сигнал идет:

    GPU->PCIe->CPU(PCIe-controller)->PCIe->Infiniband->PCIe->CPU(PCIe-controller)->PCIe->GPU

  • С RDMA и С PLX-PCIe-switch, сигнал идет:

    GPU->PCIe->PLX-PCIe-switch->PCIe->GPU

    или GPU->PCIe->PLX-PCIe-switch->PCIe->PLX-PCIe-switch->PCIe->GPU

  • С RDMA и Без PLX-PCIe-switch и Без Infiniband:

    GPU->PCIe->CPU(PCIe-controller)->PCIe->GPU

    или GPU->PCIe->CPU(PCIe-controller)->PCIe->CPU(PCIe-controller)->PCIe->GPU->...

    Можно и сотни CPU, GPU и FPGA подключить между собой без Infiniband/Ethernet/PCI-switch/..., расшаривая Mapped Memory Windows через NTB PCIe-Bars. Вот 4 CPU подключены между собой по PCIe без Infiniband/Ethernet/PCI-switch/.... Эти окна физической памяти, в том числе память GPU-RAM по GPUDirect3.0, можно мапить в другой CPU и затем мапить через PT/VMA в виртуальную user-space, которая видна другому GPU по GPUDirect1.0(UVA) http://www.alexeyab.com/2017/04/the-fastest-interconnect-for-hundreds.html

Как видно из top500.org, не все кластеры используют Mellanox Infiniband, есть ещё некоторые стандартные или совсем кастомные интерконнекты: Tofu, Sunway, TH Express-2, Slingshot-10, Atos BXI V2, Aries interconnect, Intel Omni-Path, ...

Раз уж вы строите свои кластеры, то не пробовали пойти ещё глубже и реализовать собственный интерконнект или соединять сервера напрямую по PCI-Express 4.0 x 128 lanes через PLX PCIe-switch, который поддерживает virtual Ethernet NICs, NIC DMA and Tunneled Window Connection (TWC) http://www.alexeyab.com/2017/04/the-fastest-interconnect-for-hundreds.html

В принципе, даже в одну PCIe сеть можно объединить множество CPU и GPU без Ethernet/Infiniband, гораздо больше, чем 8.

Чтобы использовать

GPU-nVLink-GPU-CPU -> PCIe -> CPU-GPU-nVLink-GPU или

GPU-nVLink-GPU -> PCIe -> GPU-nVLink-GPU

вместо

GPU-nVLink-GPU-CPU -> PCIe -> Infiniband -> PCIe -> CPU-GPU-nVLink-GPU

OpenCV >= 4.5.4 и также поддерживает все эти Scaled-YOLOv4 модели: https://github.com/AlexeyAB/darknet#pre-trained-models

Несколько полезных ссылок:

Pytorch-YOLOv4 (Python):

Darknet (C/C++) cfg/weights - https://github.com/AlexeyAB/darknet#pre-trained-models

Pytorch-YOLOR (Python): https://github.com/WongKinYiu/yolor

nVidia Transfer Learning Toolkit (training and detection) for YOLOv4: https://docs.nvidia.com/metropolis/TLT/tlt-user-guide/text/object_detection/yolo_v4.html

OpenCV-dnn for yolov4.cfg/weights and yolov4-tiny.cfg/weights (Python): https://colab.research.google.com/gist/AlexeyAB/90d2203cda30e85030374cb91192ef81/opencv-python-cuda.ipynb

Сравнение на Microsoft COCO dataset:

Сравнение на Waymo open dataset 2D (беспилотные авто): https://waymo.com/open/challenges/2021/real-time-2d-prediction/#

Пожалуйста ) А в какой задаче используете?
Я вижу много недостатков в MS COCO датасете и метрике AP, но пока что это самый лучший из имеющихся способов для сравнения сетей. Если ты хочешь сравнивать сети друг с другом, то у тебя нет другого варианта, т.к. все самые большие компании Apple/Google/Facebook/Microsoft/Intel/Baidu для самых лучших нейронных сетей используют этот датасет и эту метрику.

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

Минусы:
* MSCOCO датасет — слишком много ошибок, например, много людей в датасете не размечено
* метрика AP — усредняет по классам, т.е. если в датасете из 2х классов одна сеть нашла 100000 из 100000 человек и 0 из 1 сумок, а другая сеть нашла 0 из 100000 человек и 1 из 1 сумок, то у обеих сетей будет одинаковая точность 50%.

Плюсы:
* MSCOCO датасет — неизменен, т.е. новую сеть можно сравнить с сетями созданными 5 лет назад.
* метрика AP — усредняет по Precision-Recall-кривой, т.е. не зависит от подбора confidence_threshold, т.е. можно успешно сравнивать сеть с большими TP и FP и сеть с малыми TP и FP

Спорные моменты:
* MSCOCO датасет — наличие ошибок в обучающем (но не в valid/test) некоторые считают хорошим тестом на возможность сети обходить взаимоисключающие ошибочные метки. Ошибки в реальных датасетах или RL-подходах будут всегда, и сеть должна эффективно их обходить.
* метрика AP — усреднение по классам некоторые считают хорошим тестом на решение проблемы дисбаланса количества объектов разных классов (т.е. сеть может обучаться и на большом количестве изображений одного объекта, и на малом количестве изображений другого объекта)

То что в датасете рука обозначена как человек (в датасете нет отдельного класса рука) — это не ошибка, человек там почти точно есть. Например, если автопилот или производственный робот видя торчащую из-за препятствия руку не среагирует должным образом, то могут быть серьёзные травмы.
Пока что да, пока мы ещё чего то не выпустили )
Есть нюансы, что некоторые модели лучше для очень маленьких или сильно перекрывающихся объектов, какие-то лучше для запуска на смартфонах. Я могу и Scaled-YOLOv4 для этих задач настроить и обучить, но пользователям проще другую модель выбрать.

Как правильно в комментариях заметили, большинству компаний дешевле взять чужую сеть и увеличить точность за счет сбора хорошего датасета, чем за счет улучшения или разработки своей сети, особенно в таких высоко-конкурентных задачах как ImageNet Classification или MS COCO Object detection, где постоянно соревнуются Топ-10 IT компаний мира.
Да, каждый год становится сложнее выжимать большую точность из нейронных сетей, больше компаний этим занимаются, больше денег вкладывается, исследования дорожают, другим компаниям остается только наблюдать за прогрессом на сайте paperswithcode.com/sota

Но, например, DPT-monodepth имеет намного лучшую zero-shot точность, чем любой другой алгоритм, и в реальных задачах zero-shot точность важнее, чем точность на конкретном датасете, но нет общепринятого теста для zero-shot, и соответственно нет такого раздела на paperswithcode.
У Интеловской DPT результаты ещё лучше по всем параметрам на обоих датасетах Kitti и NYU )

А вот за несколько месяцев до этого (28 Nov 2020) незаметно вышла ещё одна статья по mono-depth, тоже с использованием трансформеров — AdaBins arxiv.org/abs/2011.14141, и там результаты на Kitti лучше, но на NYU хуже, чем у Интеловской DPT arxiv.org/abs/2103.13413

Можно посмотреть прикольные примеры работы связки MiDaS+Inpainting: shihmengli.github.io/3D-Photo-Inpainting
После замены MiDaS на DPT, должно быть ещё намного лучше.
Хороший разбор всевозможных применений трансформеров. Как всегда в тренде )
В целом, если сравнивать два конкретных стандартных решения Convolutional networks (ResNet50/152) и Visual Transformers (ViT-B/L-32), то:

1. Convolutional networks (ResNet50/152) — дают лучшую точность на маленьких датасетах, за счет лучшей обобщающей способности из-за трансляционной инвариантности и наличия локальных корреляций, которые ты упомянул

2. Visual Transformers (ViT-B/L-32) — дают лучшую точность для больших датасетов (или auto/meta/pseudo-labeling/distillation), за счет рационального использования емкости сети из-за внимания только к нужным деталям

Page 6 — Figure 4: arxiv.org/pdf/2010.11929.pdf

По поводу 5:45 youtu.be/xQFeeh5DqeY?t=345

Да не сказать, чтобы Detr или Deformable-Detr прям рвал COCO:
* Table-1 — DETR-DC5-R101 — 10 FPS — 44.9 AP% — 26 May 2020 arxiv.org/pdf/2005.12872.pdf
* Table-1 — two-stage Deformable DETR — 19 FPS — 46.2% AP — 8 Oct 2020 arxiv.org/pdf/2010.04159v4.pdf
* Table-2 — Cascade Mask R-CNN Swin-B — 11 FPS — 51.9% AP — arxiv.org/pdf/2103.14030v1.pdf
* Table-2 — EfficientDet-D6 — 10 FPS — 52.6 AP% — 20 Nov 2019 arxiv.org/pdf/1911.09070.pdf
* Table-11 — YOLOv4-P6 — 30 FPS — 54.5% AP — 16 Nov 2020 arxiv.org/pdf/2011.08036.pdf

Тот же EfficientDet вышел и раньше, и точнее, и быстрее, чем Detr/Deformable DETR.

Новый Swin Transformers для тех моделей где указан FPS, тоже не лучшее, чем EfficientDet. А для самых больших и медленных моделей, где FPS не указан — то превосходит EfficientDet по точности (58.0% AP с Test-time-data-augmentation Multi-scale-inference).

Но в целом тренд есть, статей вышло много (CaiT,PiT,ViViT,ViL,CvT,CrossViT,Swin Transformer,STAM,DPT,DeepViT,CeiT,HVT,ConViT,PVT,CPVT,T2T-ViT) и трансформеры допилят до нужного состояния.

1. Точность по датам выхода алгоритма: paperswithcode.com/sota/object-detection-on-coco


2. Соотношение точности к времени задержки (V100, batch=1, no TensorRT, no TTA):
1. Про координаты x,y:
Раньше bx=σ(tx)+cx; by=σ(ty)+cy;
Теперь bx=2*σ(tx)-0.5+cx; by=2*σ(ty)-0.5+cy;
Раньше требовало бесконечно больших значения для tx или ty чтобы объект поместить на границу ячейки. Теперь же достаточно чтобы tx ~= 1 или ty ~= 1. Page 8, para 4.3 arxiv.org/pdf/2004.10934.pdf



2. Про координаты w,h:
Раньше bw=pw*e^tw; bh=ph*e^th
Теперь bw=pw*(2*σ(tw))^2; bh=ph*(2*σ(th))^2

Раньше, производная была слишком большая при tw>1 или th>1 — экспоненциальная зависимость. Из-за этого вся сеть оптимизировалась в основном только под W и H.
— В YOLOv3 этой проблемы почти не было, т.к. использовался только 1 ближайший анкер, поэтому tw и th были близки к 1.
— В YOLOv4 используются несколько анкеров для одного объекта, если IoU > 0.2 (20%), поэтому может быть tw~=4 th~=4 — это генерирует дельту exp(4)=54.6, в то время как остальные дельты около [0 — 1]. Поэтому ширина и высота объекта перетягивает одеяло на себя.

Можно было использовать (4*σ(x)) вместо (2*σ(x))^2, но во втором варианте функция проходит через 1 при x=0, что лучше, т.к. x изначально инициализируется 0+-малое значение, и w,h тогда будут равны анкеру — а анкеры это наиболее часто встречаемые размеры объектов.

Как работает iou_thresh: У нас используется iou_thresh=0.2, т.е. если предположим
— ground_truth w=100 h=100 (square area=10000)
— и anchor w=45 h=45 (square area=2025)
то IoU = 2025/10000 = 0.2025 — это значение проходит порог iou_thresh=0.2, а значит этот anchor будет использоваться для этого ground_truth. Но анкеры с w и h ниже этих значения — не будут использоваться.

Соответственно для ground_truth(w=100 h=100) нам надо увеличить анкер
— для квадратных объектов (w=45 h=45) максимум в ~2.2 раза (увеличить w и h)
— для прямоугольных (w=90 h=23) максимум в ~4.3 раза (увеличить h) — вот здесь может быть небольшая проблема, т.к. 4.3 > 4.0

В нем есть ссылкочки на Branch-и. Добавил их в статью.
1. Он приватный.

2. Много TFlite маленьких моделей для детекторов у Katsuya Hyodo PINTO0309. Но какие из них 10 FPS на RpI4 уже не помню (смотрите quantized). Чтобы скачать в 3-й колонке Link на 3 синих квадратика жмите: github.com/PINTO0309/PINTO_model_zoo#2-2d-object-detection

А почему именно RPi4 хочется использовать?
Rpi4 — 5 — 10тр
За те же 14тр можно уже JetsonNano купить.
Или смартфон использовать, там уже встроенные GPU/DSP/NPU: nplus1.ru/news/2020/08/27/openbot
Xiaomi mi6 GPU (TFlite) за 14тр примерно такой же по скорости как JetsonNano GPU (TensorRT) за 14тр. И раз в 5 быстрее, чем RPi4.
Много разработчиков знают только Pytorch и много проектов, кода и кастомных слоев написано на Pytorch. Поэтому исследования проще проводить на Pytorch.
Поэтому пока что оптимальный вариант — это реализовать только inference-часть на TensorFlow, обучать на Pytorch и переносить только веса из Pytorch в TensorFlow.
А когда Facebook в Pytorch доделает: Graph-mode-quantization, Pytorch-mobile, Pytorch-TRT и поддержку Intel GPU/NPU, то можно будет не выходить за пределы Pytorch.

И свою статью про то как устроены embedding системы в последнее время.
И то и то уже немного неактуально, ведь всё быстро-быстро меняется;)

Я бы даже сказал: DeepLearning меняется непредсказуемо, где-то очень быстро, а где-то очень медленно:

— Например ResNext вышла в 2016 году arxiv.org/abs/1611.05431 а в Keras Grouped-Convolutional, которые используются в ResNext были добавлены только в начале 2020 года github.com/tensorflow/tensorflow/pull/36773 при том, что ResNext в 2019 года была топ4 по точности на Imagenet, и до сих пор в 2020 году в топ10: paperswithcode.com/sota/image-classification-on-imagenet

— В Pytorch в 2020 году до сих пор нет Padding=SAME: github.com/pytorch/pytorch/issues/3867 из-за этого приходится создавать костыли github.com/rwightman/gen-efficientnet-pytorch/blob/master/geffnet/conv2d_layers.py которые потом косвенно мешают конвертации и квантизации. Не релизнута обычная int8 квантизация: в eager только в бете, а в graph вообще её нет и т.д.
На неё даже Yolov4 спортировано. И в целом, AlexeyAB очень позитивно отзывался.


Да, Tencent-NCNN хороша тем, что в нее конвертятся модели из ONNX и запускать можно везде где есть Vulkan. В TFlite есть много проблем при конвертации из ONNX. Но нативные-TensorFlow модели работают на TFlite быстрее, чем на NCNN.

YOLOv4 где только нету, на TensorFlow / TensorFlow-Lite устанавливается просто pip install yolov4 и поддерживает обучение, инференс и любые конвертации.

— yolov4-tiny на TensorFlow-Lite где-то в 1.25 раза быстрее, чем на NCNN на CPU RaspberryPi4
— TensorFlow-Lite (2 threads) где-то в 2 раза быстрее, чем Pytorch-mobile на CPU iPhone 11.
— TensorFlow-Lite умеет ускорять на GPU в 2 раза и на NPU в 4 раза на iPhone11, Pytorch-mobile пока этого не умеет.
Но это конечно сильно зависит от модели, есть которые совсем плохо ускоряются на GPU/NPU.
— в Pytorch-е есть Eager-mode-квантование только в бетте, а Graph-mode-квантование пока вообще не реализовано.
— а в TensorFlow-lite не все модели из TF могут быть сконвертированы в TFlite, например, в TFlite не поддерживаются Grouped-Conv — известная воспроизводимая проблема: github.com/tensorflow/tensorflow/issues/40044 и приходится городить массив из кучи conv-слоев и итоговая модель очень медленная. Но DepthWise-conv (частный случай GroupedConv когда input_channels==groups) поддерживается в TFlite.

Я пока что выбрал TFLite для инференса на мобильных устройствах.
Но проблема в том, что большинство разработчиков обучают модель на Pytorch, а хотят inference на TFlite и есть проблемы в конвертации из Pytorch в TFLite. Есть 3 пути конвертации:

1. Pytorch->ONNX->TensorFlow(pb)->TensorFlowLite(tflite) но в этом случае наши полученные модели основанные на обычном resnet50
— (iPhone11) либо вообще не запускаются на GPU/NPU
— (SnapDragon 865) либо работают на GPU/NNAPI даже медленнее, чем на CPU

2. Pytorch->ONNX->OpenVINO->TensorFlow(pb) / TensorFlow-lite После того, как 1-й путь оказался плохим, решено было сделать конвертер OpenVINO-> TensorFlow-NHWC(tflite/tfjs/tf-trt/tf-edge) github.com/PINTO0309/openvino2tensorflow полученные модели на скорость на смартфонах ещё не тестировал, но на PC работает: github.com/PINTO0309/PINTO_model_zoo/issues/15#issuecomment-714441709

3. Pytorch->TensorFlow требует использовать идентичные нативные модели в обоих фреймворках и конвертировать только веса. Полученная модель очевидно будет самая быстрая и без мусора, который добавляют конвертеры и этот мусор видимо не поддерживается GPU/NPU. Я реализовал и использую этот метод.

В итоге удалось ускорить модель на смартфоне в 100 раз на GPU/NPU (на Snapdragon 865 GPU было 0.2 FPS, стало 22 FPS), при сохранении точности:
— в 10х раз ускорить за счет использования моего конвертера (3) вместо (1)
— в 10х раз ускорить за счет оптимизации/изменения модели и параметров обучения
Около 42 FPS работает yolov4-tiny на CPU Intel Core i7 7700HQ используя OpenCV-dnn, если скомпилировано с OpenVINO backend: github.com/opencv/opencv/wiki/Intel's-Deep-Learning-Inference-Engine-backend

Без OpenVINO-backend — 28 FPS.

— YOLOv4-tiny: accuracy 40.2% AP50 on Microsoft COCO dataset:

1770 FPS — on GPU RTX 2080Ti — (416x416, fp16, batch=4) tkDNN/TensorRT

1353 FPS — on GPU RTX 2080Ti — (416x416, fp16, batch=4) OpenCV

39 FPS — 25ms latency — on Jetson Nano — (416x416, fp16, batch=1) tkDNN/TensorRT

290 FPS — 3.5ms latency — on Jetson AGX — (416x416, fp16, batch=1) tkDNN/TensorRT

42 FPS — on CPU Core i7 7700HQ (4 Cores / 8 Logical Cores) — (416x416, fp16, batch=1) OpenCV-dnn (compiled with OpenVINO backend) github.com/AlexeyAB/darknet/issues/6067#issuecomment-656693529

20 FPS on CPU ARM Kirin 990 — Smartphone Huawei P40 (416x416, GPU-disabled, batch=1) Tencent/NCNN

120 FPS on nVidia Jetson AGX Xavier — MAX_N (416x416, fp16, batch=1) — Darknet framework

371 FPS on GPU GTX 1080 Ti — (416x416, fp16, batch=1) Darknet framework

More: github.com/AlexeyAB/darknet/issues/6067
Ещё 2 года назад меня звали в Xnor-ai, когда они отказались от открытых разработок. А затем этика, патенты, продажа, неразглашение. Сейчас он может позволить себе заниматься общественной деятельностью вместо computer vision.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity