共计 6867 个字符，预计需要花费 18 分钟才能阅读完成。
本我的项目将 Whisper 与 Stable Diffusion 模型联合，能够间接实现语音生成图像的工作。用户能够语音输入一个短句，Whisper 会主动将语音转化为文本，接着，Stable Diffusion 会依据文本生成图像。
本我的项目基于 Jina AI MLOps 平台搭建，通过应用 DocArray 逾越了不同数据类型之间的鸿沟，缩小了利用的数据传输老本。同时应用 Jina 搭建了一个云原生的基于微服务的 Pipeline，并且很容易就能部署到 Kubernetes 零碎中。咱们都习惯了用 Siri、天猫精灵等智能语音助手来设置闹钟，播报天气，甚至它也会给咱们讲一些冷笑话。然而怎样才能更进一步呢？咱们怎样才能用本人的声音作为桥梁，和世界以及机器进行更加深刻、乏味的交互呢？目前的智能语音助手都是基于单模态的，即输出咱们的声音会输入它们的声音，与此同时，智能语音助手还会执行咱们的指令。这种单模态的工作模式就像是钢铁侠的 Mark I。尽管对于现有的工作，智能语音助手曾经实现得很好了，然而随着技术的一直变革，咱们冀望它能有更多的翻新。将 AI 技术赋能于语音识别系统，能够使得机器生成精美的画面，这就像是为 Alexa（亚马逊旗下的智能语音助手）拆卸上激光炮和火箭靴。咱们也能够借此实现更加简单的利用。不同于单模态的智能语音助手 Alexa、Siri，通过 Jina，咱们将关上多模态世界的大门。咱们能够利用文本生成图像，语音生成视频，甚至是任何一种模态信息生成（或者检索）另一种模态信息。与此同时，咱们不须要成为钢铁侠这样的蠢才，甚至无需领有浩克一样的智力，仅仅应用 90 行代码就能使魔法变为事实。咱们能够利用云原生的微服务框架实现跨模态转换工作，并将其部署在 Kubernetes 上。
初步调研
过来的几年里，人工智能技术呈爆发式倒退，咱们的钻研也从单模态模型（例如，用于文本的 Transformers，用于图像的 Big Image Transfer）迅速转向能够同时解决不同状态数据的多模态模型。遗憾的是，即便咱们的模型曾经转向多模态，这也仍然过期了。就在往年，咱们发现文本生成图像的工具急剧增长，例如 DiscoArt, DALL-E 2 和 Stable Diffusion。还有一些其余的模型甚至能够实现文本生成视频，图像生成 3D 模型的工作。Stable Diffusion 能够用来生成图像（咱们曾经用它生成了以下图像）：
美队骑摩托的照片!
钢铁侠和 Luke Skywalker 跳舞的照片!
用活泼的色调，Artstation 的风行趋势画一张蜘蛛侠在纽约上空飞檐走壁的 4K 数字插画。
当初热门的不仅是多模态的文本图像生成，就在几周前，OpenAI 公布了一个主动语音识别系统 Whisper。在解决口音、背景噪声以及技术术语方面，Whisper 简直达到了人类的水准。本文将 Whisper 与 Stable Diffusion 联合，能够间接实现语音生成图像的工作。用户能够语音输入一个短句，Whisper 会主动将语音转化为文本，接着，Stable Diffusion 会依据文本生成图像。
现有解决方案
语音生成图像并不是一个新的概念，许多学者曾经写过相干的论文：
S2IGAN: Speech-to-Image Generation via Adversarial LearningDirect Speech-to-Image TranslationUsing AI to Generate Art – A Voice-Enabled Art Generation ToolBuilt with AssemblyAI – Real-time Speech-to-Image Generation
与以上计划不同的是，咱们的示例基于最前沿的模型，并且齐全可扩大。咱们的应用程序是利用微服务架构搭建的，非常容易就能够部署到 Kubernetes。更重要的是，相比于上述的解决方案，咱们须要的代码量更小。
要害挑战
当思考能够用最新的多模态模型搭建什么时，你的设想可能会天马行空，然而理论的搭建不同于设想，存在几个关键问题：
- 依赖天堂，构建一个单片机集成系统绝对简略，但如果将前沿的深度学习模型绑定在一起就会导致依赖抵触。因为这些模型在搭建时为了炫技，而疏忽了兼容性。这就像钢铁侠的火箭靴和激光炮并不兼容一样，当他在地面击中齐塔瑞后，火箭靴就会隐没，他则像岩石一样从地面坠落。而咱们将冲破兼容技术，援救钢铁侠的生命！
- 抉择数据格式，如果要解决多模态信息，只抉择一种数据类型在不同模态的数据间互操作十分麻烦，而当咱们只须要解决单模态信息时，文本就能够用字符串，图像就能够应用 Tensor。然而在咱们的示例中须要同时解决语音和图像，如何为不同的数据类型提供一站式的解决方案是一个辣手问题。
- 打包所有模型，最大的挑战还是在于混合不同的模型并且构建一个齐全成熟的利用。当然你也能够将模型打包成容器，部署到云端并提供 API。然而一旦你想将两个模型连贯在一起，创立一个略微简单的利用，就会呈现凌乱。尤其是当你想构建一个基于微服务架构的利用时，例如，复用局部 Pipeline（流水线）以防止停机，此时该如何在不同的模型之间进行通信呢？更不用说在 Kubernetes 这样的云原生平台上部署，或者监控、观测你的 Pipeline 了。Jina 的解决方案作为目前最先进的多模态 AI 的 MLOps 平台，Jina 生态帮忙开发者和企业解决跨模态生成工作（比方：语音图像生成）面临的挑战。为了以污浊、易扩大、可部署的形式整合 Whisper 和 Stable Diffusion，咱们将：
应用 Jina 将深度学习模型封装成 Executors。将 Executors 组合后失去 Jina Flow（可复用、分片的云原生 AI 利用）。应用 DocArray 将数据发送至 Flow，用 Jina Hub 上的 Executor 顺次解决数据。将利用部署到 Kubernetes/JCloud，并实现可观测性。
Pipelines 和 building blocks 不仅仅只是概念，Flow 是一个云原生利用，每个 Executor 都是一个微服务。Jina 通过将每个 Executor 作为微服务，将 building blocks 组合（通过模块、类拆散）转化为云原生组合。这些微服务能够无缝复用和分片。Flow 和 Executors 都是由最先进的网络工具提供反对，并且依赖于双流网络。这解决了以上提到的 3 个问题：
- 依赖天堂 -> 每个模型都被封装成独自的微服务 Executor，因而相互不烦扰。
- 抉择数据格式 -> DocArray 能够解决咱们输出的任何数据，无论是语音、文本、图像还是其它数据格式。
- 打包所有模型 -> Jina 将模型封装成微服务 Executor 后，Jina Flow 协调所有的微服务并给用户提供接口。基于 Jina 的云原生性能，咱们还能够轻松将利用部署到 Kubernetes 或 JCloud，并察看和监控利用。
- 构建 Executors
多模态检索或者生成工作都须要一些步骤构建 Executors，具体取决于你的工作。在咱们的语音生成图像工作中，步骤如下：
在界面中输出用户的声音。用 Whisper 将语音转换为文本。将输入的文本输出到 Stable Diffusion 中即可生成图像。在界面中显示图像。
因为咱们更关注后端算法，所以咱们将聚焦于步骤 2、3，并将每一个模型都封装成一个个 Executor：
WhisperExecutor – 将用户的声音转化为文本。StableDiffusionExecutor – 依据文本生成图像。
在 Jina 中，Executor 是能够执行单个工作的微服务。所有 Executor 都应用 Documents 作为根本数据类型。详见“流数据”局部。通过编写 Executors（模块 / 类拆散）使得每个 Executor 都能够无缝地分片、复用，并部署在 Kubernetes，并且他们都是可观测的。WhisperExecutor 代码见以下代码段，其中每个函数都有本人的 @requests 装璜器，用户能够通过调用函数指定网络端口。因为咱们没有指定端口，所以拜访任何端口时都会调用 transcribe()。
class WhisperExecutor(Executor): def __init__(self, args, kwargs): super().__init__(args, kwargs) self.model = whisper.load_model(‘base’) @requests def transcribe(self, docs: DocumentArray, **kwargs): for (i, doc_) in enumerate(docs): model_output = self.model.transcribe(doc_.uri if doc_.tensor is None else doc_.tensor) doc_.text = model_output[‘text’] doc_.tags[‘segments’] = model_output[‘segments’] doc_.tags[‘language’] = model_output[‘language’] return docs
- 构建 Flow
Flow 是将 Executors 组合后失去的能够用于多 / 跨模态模型的 Pipeline，Documents 会进入 Pipeline，并且由 Executors 解决。Flow 相当于配置和启动微服务架构的接口，其它的工作则是由 Executors 实现。每个 Flow 都会登录 Gateway（网关）服务，因而能够通过自定义的 API 连贯其余服务。Gateway 将所有的 Executor 连贯在一起，并且依据 Flow 的拓扑构造 确保每个申请都能通过不同的 Executor（例如，它在 ExecutorB 之前进入 ExecutorA）。语音图像生成利用的 Flow 的拓扑构造绝对简略，只有两个 Executor，WhisperExecutor 和 StableDiffusionExecutor。上面的代码定义了 Flow，并且为用户提供了连贯和传输数据的端口。Flow 能够通过 flow.plot()可视化。
Flow 拓扑构造
- 流数据
进出 Flow 的所有内容都必须是 Document，Document 是 DocArray 包中的一个类。DocArray 为多模态数据（咱们的示例中有语音、文本、图像）提供了一个通用的 API，能够将不同模态的数据，对立成同一种数据结构。这就意味着无论应用什么模态的数据，Document 都能够存储。并且因为所有的 Executor 应用的数据类型都是 Documents 和 DocumentArrays，因而能够确保一致性。在咱们的语音图像生成工作中，输出的 Document 是用户声音的采样。Document 将采样失去的语音数据存储成 Tensor。如果咱们把输出 Document 视为 doc：
首先会通过前端页面创立 doc，接着，用户输出的声音会存储为 doc.tensor。通过调用 gRPC 接口，能够将 doc 从前端发送到 WhisperExecutor。WhisperExecutor 会将接管到的 tensor 转换成 doc.text。之后，doc 会被发送到 StableDiffusionExecutor。StableDiffusionExecutor 会读取 doc.text 并依据文本内容生成两张图像，图像将会保留在 doc.matches 中。紧接着，前端会接管来自于 Flow 的 doc。最终，前端会获取输入的 Document，并且在界面上显示出生成的图像。
4. 连贯 Flow
用户能够通过 Flow 将 Jina 客户端和 第三方客户端 连接起来，在咱们的 示例中，Flow 启动了 gRPC 端口。并且只需一行代码，就能够轻松地将 gRPC 端口代替成 RESTful、WebSockets 或者 GraphQL 端口。此外，Gateways 被部署在 Deployment 中，用来将申请发送至 Executors。更重要的是，这些转换都是由 Jina 实时实现的。
- 部署 Flow
Jina 作为云原生框架，和 Kubernetes 的联合最为夺目。“用 Kubernetes 部署”的 [1] 文档 解释了如何在 Kubernetes 上部署 Flow，接下来让咱们一起揭开帷幕，深刻理解底层的原理吧。就像之前提到的，Executor 是一个容器化的微服务。咱们应用程序中的两个 Executor 都是作为 Deployment 独立部署在 Kubernetes 零碎中。此外，Gateway 部署在 Deployment 中，以便申请通过 Executor。这就意味着 Kubernetes 能够解决它们的生命周期、机器调度等。更重要的是，你只须要用 Python 定义 Flow，Jina 就会即时帮你实现部署工作。当然你也能够在 JCloud 上部署 Flow，JCloud 也能够实现上述内容，同时它还提供了一个便捷的监督 dashboard。你只须要将 Python Flow 转换为 YAML Flow（蕴含一些 JCloud 的特定参数），之后就能够部署：
jc deploy flow.yaml
最终成果当初，就是见证奇观的时刻！输出一些测试查问：
启动监督后（默认开启），Flow 外部产生的所有都能够在 Grafana dashboard 中可视化。
监督的劣势在于它能够帮忙你优化应用程序，并且通过检测性能瓶颈使得你的应用程序更加经济高效。例如，以下监督结果显示：在咱们的利用中，StableDiffusionExecutor 存在性能瓶颈：
这意味着负载过重会导致延时飙升。为了进步运行效率，咱们能够复用 StableDiffusionExecutor，并将图像生成工作散布在不同的机器上。
f = (Flow(port=54322).add(uses=WhisperExecutor).add(uses=StableDiffusionExecutor, uses_with={‘auth_token’: hf_token}, replicas=2))
或者能够批改 JCloud YAML 文件：
– name: diffusion uses: jinahub+docker://StableDiffusionExecutor uses_with: auth_token: YOUR_TOKEN timeout_ready: -1 # slow download speed often leads to timeout replicas: 2 jcloud: resources: gpu: 1 memory: 16
论断
本文咱们用最前沿的 AI 模型和 Jina AI MLOps 平台搭建了一个云原生的语音图像生成的应用程序。咱们通过应用 DocArray 逾越了不同数据类型之间的鸿沟，缩小了利用的数据传输老本。同时应用 Jina 搭建了一个原生的基于微服务的 Pipeline，并且它很容易就能部署到 Kubernetes 零碎中。因为 Jina 是一个模块化的架构，所以很容易就能将相似的计划利用到不同的用例中，例如：
搭建多模态的 PDF 搜索引擎，用户能够应用文本或图像来搜寻匹配的 PDF。构建一个多模态的时尚搜索引擎，用户能够依据文本或图像来搜寻商品。用于电影场景设计的 3D 生成模型。基于 GPT-3 的博客生成模型。
这些利用都是云原生、易扩大的，并且非常容易部署到 Kubernetes 集群中。
援用链接
[1] 多模态世界: https://jina.ai/news/paradigm…
[2] DiscoArt: https://colab.research.google…
[3] Whisper: https://openai.com/blog/whisp…
[4] request 装璜器: https://docs.jina.ai/fundamen…
[5] Gateway: https://docs.jina.ai/fundamen…
[6] Flow 的拓扑构造: https://docs.jina.ai/fundamen…
[7] 可视化: https://docs.jina.ai/fundamen…
[8] Jina 客户端: https://docs.jina.ai/fundamen…
[9] 第三方客户端: https://docs.jina.ai/fundamen…
[10] 用 Kubernetes 部署文档: https://docs.jina.ai/how-to/k…