当前位置:   article > 正文

谁说 Python 搞不定 AI 模型微服务?!Towhee 来了!_towhee 本地模型

towhee 本地模型

作者 | 郭人通

“从用 Python 定义流水线,到生成 Docker 镜像,再到启动服务并调用执行,一共不到 30 行代码!?”


想要模型落地,有一连串大坑躲都躲不开:

  • 模型转不了 ONNX,TensorRT。

  • 模型推理搞的飞快之后,发现预处理、后处理才是瓶颈。

  • 除了需要搜寻各种英伟达的算法库,还需要学习各种高性能计算和 CUDA 编程技术,对着图片解码、视频解码、tensor transform、分词之类的操作一顿猛搞。

  • 发现英伟达老爷的东西“又高又硬”,根本装不起来。

  • 不仅要写一堆脚本程序,努力的把一整条处理流水线串起来,更要设计好服务的调用接口。

  • 串完发现流水线各级速度不匹配,想着把慢的阶段起多实例并行,又扯上了负载均衡和流水线优化。

  • 流水线上的算法实例起多了,物理资源又不够了。

  • 一切内容终于准备就绪了,竟然又要去学写 Dockerfile ......

为了解决上面一连串的问题,我们发起了一个开源项目 Towhee(github.com/towhee-io/towhee),任何用户都能够从 Python 代码一键构建面向生产的高性能推理流水线。这个项目提供了一套优雅的函数式 Python 编程接口,以及一组覆盖日常工作所需要的工具集,只需要几行代码,就能够自动的解决上述问题:将推理流水线内出现的代码(模型、算法、数据处理过程等)转换成对应的高性能实现,组织端到端的推理服务代码,一键生成 Docker 镜像。

下面举一个小例子演示如何使用 Towhee:用 CLIP 做图片 embedding 特征提取。从定义流水线到生成 Docker 镜像,再到启动服务并调用执行,一共不到 30 行代码。

首先,用 Python 定义一个“流水线”:

流水线接受图片作为输入,输出图片对应的 embedding 向量。这个流水线包含两个算子 image_decode.cv2_rgb 和 image_text_embedding.clip_image,分别负责图片的解码以及 CLIP 的图片特征提取。

例子里对流水线进行了配置,通过 pipeline_config 的 format_priority 参数给到 Towhee 一个提示,告诉 Towhee 优先把模型转到 TensorRT 的格式去做推理,如果失败就尝试走 ONNX。

image_decode.cv2_rgb 的算子配置是 num_instance=4,让 Towhee 在流水线中起4个图片解码的实例提高并发。image_text_embedding.clip_image 的算子配置是 dev_id=0,让 Towhee 在 GPU0 上跑 CLIP 的推理。如果指定了使用 GPU 进行模型推理,Towhee 会自动的选择 GPU 版本的模型前后处理过程,并在同一块 GPU 设备上执行前处理、模型推理、后处理。更多流水线配置能力详见官方文档(https://docs.towhee.io/)。

接下来,我们通过 Towhee 把这个流水线制作成 Docker 镜像,这里选用 Nvidia Triton 作为高性能推理服务框架:

命令执行完毕,我们将得到一个名为 clip_image_embedding:v1  的镜像,使用下面的命令启动服务实例:

在完成了模型服务启动之后,我们在本地编写一个简单的测试程序,通过调用刚才启动的服务,对当前目录下 jpg 图片做 embedding 特征提取:

如果你想进一步做一个基于 CLIP 的 “文本-图像跨模态” 召回服务,我们还可以再添加一个用 “CLIP 提取文本 embedding 特征” 的流水线,并进一步丰富服务的调用代码,完整程序不会超过 100 行 Python 代码。(这里因为和上面的示例代码比较接近,就不展开赘述了,感兴趣的同学可以自行尝试,遇到问题欢迎到 Slack 或微信反馈,链接见文章末尾)

除了对大量工程细节的极致封装,Towhee 在性能方面也有不俗的表现。在我自己的机器上(64核CPU,3080单卡),使用 HuggingFace 的 CLIP 预训练模型和配套工具库实现了同样功能的流水线,并和 Towhee 的流水线进行了性能对比:

HuggingFace 与 Towhee 的流水线性能对比

经过多次实验,HuggingFace 流水线的平均 QPS 67,Towhee 流水线的平均 QPS 328。Towhee 的流水线有接近 5 倍的提速。也就是说,通过使用 Towhee,仅用一块卡就可以达到之前五块卡的服务能力,两个字,省钱!

接下来,继续分享一些 Towhee 中的重要组件和实用工具:Towhee Operator Hub、DataCollection 编程接口、高性能推理服务,以及项目的 Roadmap。

Towhee Operator Hub
 

Towhee 的 Hub 不叫 Model Hub,而是叫 Operator Hub。主要原因在于,Towhee 是面向端到端的流水线构建,不仅仅是聚焦神经网络模型,还更加关注算法模块功能的丰富度、高性能推理、标准的任务接口。

算法模块的丰富度:Towhee 中的算法模块,包括神经网络模型,也包括各种五花八门的数据处理方法,如音视频编解码、图片裁切、文本分词、向量降维、数据库操作等。

Towhee 关注的算法来源主要有四类:

  • 应用场景所需的通用算法或数据处理方法;

  • 各类顶会以及arXiv上受到广泛关注的前沿模型;

  • Paper with Code 关键领域的 benchmark 上榜模型;

  • 业务领域常用的算法库、模型库集成。

目前,Towhee 已经覆盖计算机视觉、自然语言处理、音频、生物医药、多模态五大领域的十多项任务,120多种模型结构,700多个预训练模型。查看 Towhee 支持的 Operator 列表(https://github.com/towhee-io/towhee)。

高性能推理:Towhee Hub 上的算法模块除了提供预训练模型以及Fine-tuning 能力,会更加聚焦流水线落地后的推理性能。Towhee 会为常用算法或前沿模型提供对应的高性能实现,根据 Python 侧流水线的定义,在推理服务的构建期进行自动化替换。这些加速支持包括:

  • 模型转 ONNX、TensorRT;

  • 前后处理的多线程、GPU 加速;

  • 常见的数据处理过程加速,如图片、音频、视频解码加速等。

标准的任务接口:Towhee 会按照任务类型对算子进行模块化组织。任务类型确定了标准的调用接口,并通过算子提供这些接口的不同实现。

在 Towhee Hub 中 Operator 的组织方式类似 PapersWithCode,相同任务的 Operator 会组织在一个分类下,结构目录清晰、方便阅读和使用。目前,Towhee 社区也在尝试逐步覆盖 Papers with Code 上的重点任务,支持用户对 SOTA 模型的快速试用,避免用户在 “读懂论文-看懂论文作者的初版实现-面向工程落地的代码重构-PoC-性能优化” 这个链条上的重复造轮子。Towhee 会对已支持的模型添加 Papers with Code 链接。如果在 Papers with Code 模型页面的 'Code' 部分看到 towhee-io/towhee,就说明在 Towhee 可以对该模型进行试用。例如跨模态视频召回的 CLIP4Clip 模型。

Towhee Hub 上的每一个 Operator repo,既是一个模型的代码仓库,也是一个直接可调用的模块。如前面的例子中用到的 image_text_embedding.clip_image 算子,对应 Hub 上 image-text-embedding/clip_image 这个 repo。这个仓库的用户名和仓库名分别与流水线调用中的包名 image_text_embedding、算子名 clip_image 对应。Towhee 规定了一套 Operator 代码仓库的接口协议。只要代码仓库的组织方式遵守这套协议规范,就可以通过 Towhee 提供的工具,将仓库代码自动化打包,并可以通过 "用户名.仓库名" 的方式对算法模块直接加载调用。

任务接口标准化有一个非常大的优势是可以灵活切换模型,而不用担心引入额外的工程量。这对于快速 PoC 以及流水线升级都很重要。在原型阶段,可以根据业务逻辑确定需要哪些类型的任务,由于相同任务下的不同算子具有一致的调用接口,因此可以乐高积木式的自由组合,进行快速的效果尝试。在生产环境如果需要对流水线的某个 Operator 升级,也只需要在流水线的定义中替换相应的 Operator,通过 Towhee 重新构建 docker image 即可。

目前 Towhee 社区也在收集用户的算子需求,在每个版本中进行汇总并更新实现。有这方面需求的同学可以加项目的Slack/微信群进行讨论或提 github issue。相关链接在文章末尾。

DataCollection 编程接口
 

Operator 是乐高积木,DataCollection 接口则是强力胶,用来连接积木。通过 DataCollecton 接口,Towhee 用户可以轻松构建推理流水线。DataCollection 在逻辑上的定义是一个带 Schema 的非结构化数据表格,每一行对应一个数据实体(Entity),每一列对应一种数据属性。一个流水线对应着一组数据属性操作,每个 Operator 接受一到多个数据属性作为输入,并产生新的数据属性作为输出。

DataCollection 主要有三个作用:

  • 在原型阶段,用于构建可直接本地执行的流水线;

  • 用于定义面向生产部署的 DAG;

  • 作为 driver program 连通业务逻辑与流水线服务。

在文章一开始 CLIP 的例子中,已经简单演示了后两个用法。这里对流水线的本地快速原型构建做一个简单的介绍。CLIP 这个例子的本地可执行版本写出来是这样:

代码中方括号的部分指定了 schema 的相关信息。这个例子中 3 个 Operator 够成了一个收尾相连的链,当然,还可以通过 DataCollection 定义一些比 operator-chain 更复杂的 DAG:

这个例子中,我们先通过 YOLO v5 检测图片中出现的 objects,然后在原图中将这些 objects 裁切出来,并使用 CLIP 分别对这些 objects 的图片进行 embedding feature 的提取。这个 DAG 画出来是这个样子:

CLIP 示例对应的 DAG

高性能推理服务
 

Towhee 项目的目标不是打造一款全新的推理引擎,而是聚焦于让现有的高性能推理引擎更加落地。目前,Towhee 的推理服务适配了 Nvidia Triton 推理框架,主要特性包括:

  • 推理流水线 DAG。相比常见的推理引擎只支持 “单纯的神经网络模型推理”,或 “前处理-模型推理-后处理 三阶段流水线”,DAG 型的流水线可以覆盖更丰富的数据处理组合逻辑。

  • 异构的推理后端。DAG 中的每一个算子节点可以在不同的后端引擎上执行,既包括神经网络推理引擎,如 Pytorch(TorchScript),ONNXRuntime, TensorRT;也包括通用的数据处理过程,如 Python 函数,DALI,或自定义Python/C++后端;还包括数据库/索引连接器,如 Milvus,FAISS。

  • 极致的推理性能。推理服务可在 NVIDIA GPU,x86/ARM CPU 上高效运行,支持多 GPU,支持多模型实例,支持实时、流式、批处理、动态批处理请求,支持流水线自动并行。

  • Docker 与 Kubernetes 部署。推理流水线都以 Docker 镜像的方式进行封装,对外提供 grpc 与 http 接口,隐藏大量内部复杂性。可通过 Kubernetes 轻松部署推理微服务。

在支持上述特性的同时,Towhee 为用户完成了大量自动化工作,包括逻辑图到物理图的映射,物理图到异构执行后端的映射,以及运行期调度。

DAG 的映射与自动优化

上图给出了 CLIP 这个例子从流水线定义到生成推理流水线服务的过程。从上到下,整个自动化构建与执行过程共分三个阶段,分别是逻辑图(编译期),物理图(编译期),以及执行后端(运行期)。逻辑图是通过对 DataCollection 进行 Trace 所获得的关于图定义的完整元信息。物理图会对逻辑图中各个算子节点进行物理实现的绑定,如 image_decode 节点在物理层会以 Python model 的方式执行 OpenCV 程序,CLIP 对应的图片前处理过程在物理层会绑定 DALI 实现,CLIP 模型在物理层会绑定 TensorRT 实现。同时,这些算子节点会在物理层完成 ensemble 的相关配置、实例个数配置、以及物理资源的分配。在运行期,会根据物理图上各个节点的物理绑定,适配执行后端,以及物理内存与计算资源,并根据图上各个算子节点的依赖关系,驱动流水线的自动化执行。

Roadmap
 

Towhee 项目的 Roadmap 可以在官网(https://towhee.io/)查看。目前,Towhee 项目还在快速迭代与重度研发的阶段。项目 Roadmap 上的关键内容有:

前沿算法模型

模型方面,近期会聚焦 CVPR 2022 新出炉的前沿成果,如 CV 大神何恺明的 MAE,香港大学、UC Berkeley、腾讯合作的 MCQ 等。同时,会集成 AutoEncoder ,提供向量降维能力。对于中文跨模态搜索、多模态召回、代码等数据上的任务类型也会有模型更新。

进展详情请关注项目的 Model ChangeLog。

计算机视觉:

  • MAE:Masked Autoencoders Are Scalable Vision Learners CVPR2022 (backbone)

  • SVT:Self-supervised Video Transformer (action recognition)

  • TransRAC:Encoding Multi-scale Temporal Correlation with Transformers for Repetitive Action Counting (repetitive action counting)

  • CoFormer:Collaborative Transformers for Grounded Situation Recognition (action recognition/grounded action counting)

  • MCQ:Bridging Video-text Retrieval with Multiple Choice Question (text video retrieval)

  • STRM:Spatio-temporal Relation Modeling for Few-shot Action Recognition (action recognition)

多模态:

  • CoOp:Conditional Prompt Learning for Vision-Language Models (visual language task)

  • CVNet:Correlation Verification for Image Retrieval (image retrieval)

代码文件:

  • CodeBERT:A Pre-Trained Model for Programming and Natural Languages

  • CodeGen:A Conversational Paradigm for Program Synthesis

Embedding 向量降维:

  • Autoencoder

编程接口与工具

  • 更加统一的 DataCollection 批处理接口与流处理接口。

  • 支持自定义的算子。Towhee 目前给出了比较丰富的标准算子模块,但在常见的业务流程中,通常会引入业务逻辑,自定义算子可以很好的满足这部分需求。Towhee 的自定义算子将会包含两种形态,一种是通过 python 的 lambda 表达式生成,另一种是通过继承 Operator 基类生成。

  • 算子的打包与安装工具升级。支持基于 pip 的打包与安装,并提供基于 AWS S3 的模型参数下载服务,优化本地模型参数缓存。

推理服务优化

  • 支持视频与音频的推理流水线。长视频或长音频的处理往往会耗费大量物理资源,针对这类场景,Towhee 将不再一次性展开帧数据,而是提供流式的帧数据处理,以降低内存/显存需求。

  • 在推理服务构建中完整支持 Schema。

  • 基于 numba 的 python 算子自动优化 (实验阶段)。Towhee 通过自定义算子支持业务相关的逻辑,我们鼓励用户使用 python 来快速构建这些逻辑,同时,Towhee 会在底层对这些 python 代码进行尽可能的优化:基于 numba,使用LLVM编译技术解释字节码,优化 IR 并翻译到目标代码进行执行。

本地执行优化

  • 支持基于 Apache Arrow 的列存数据,提高本地内存利用率,支持连续内存上的向量化执行。

  • Transformer 模型结构的执行性能优化(实验阶段)。

Towhee 项目的相关链接
 

  • Github:

    https://github.com/towhee-io/towhee

  • 项目主页:

    https://towhee.io/tasks/operator

  • Slack:

    https://slack.towhee.io/

阅读原文:https://www.wpsshop.cn/w/2023面试高手/article/detail/423670

推荐阅读
相关标签
  

闽ICP备14008679号