论文解读 OpenVoice: Versatile Instant Voice Cloning

使用meloTTS 本文生成的音频

使用openVoice clone 自己的声音 阅读本文内容

文件直接上传在github中, 暂未走cdn, 缓存比较慢,可下载播放, 下载地址: http://github.com/weedge/paper-speaker/tree/main/multimoding/voices/open_voice_inference


openVoiceV2 tone color clone: base TTS + extra tone color + convert

Base TTS: use meloTTS , 支持TTS模型训练,以及load Pre-Trained ckpt 进行TTS, 在 VITS基础上支持多种语言;

论文地址:OpenVoice: Versatile Instant Voice Cloning

论文主作者:Zengyi Qin (同时是JetMoE的作者,站在巨人的肩膀上创新)

公开的权重:

源码:

训练: MSML dataset 和 训练过程 未公开

附操作笔记https://github.com/weedge/doraemon-nb/blob/main/myshell_ai_OpenVoiceV2.ipynb

论文解读 DeLighT: Very Deep and Light-weight Transformers

在看apple 最近发布的OpenELM 模型,其论文中提到 block-wise scaling 模型结构优化方法,(论文见: OpenELM: An Efficient Language Model Family with Open-source Training and Inference Framework),这里记录下DeLighT论文中的 block-wise scaling,翻译整理下以便对照代码实现,了解背景和原理。DeLighT论文中的实验任务主要是在两个标准的序列建模任务上评估了DeLighT的性能:机器翻译(machine translation)任务 encoder-decoder architecture 和 语言建模( language modeling)decoder architecture,论文中机器翻译任务未对En-Zh(英文译中文)进行实验,可以作为一个复现练习,根据源码实操一下论文中的实验;而语言建模可以作为openELM的来源延伸~ 结合cornet进行复现(也有mxl示例,mxl针对Apple Silicon 硬件进行的优化深度学习框架)。

论文主作者:Sachin Mehta

论文地址:https://arxiv.org/pdf/2008.00623

论文代码: https://github.com/sacmehta/delight (基于当时facebook的 fairseq seq2seq工具库开发)

该论文研究是在作者以前的DeFINE: DEep Factorized INput Token Embeddings for Neural Sequence Modeling 进行改进,模型结构引入更多的GLTs,来学习更宽的权重,并且减少了参数数量。

摘要

我们介绍了一种深度且轻量级的Transformer,名为DeLighT,它在参数数量显著减少的情况下,提供了与标准基于Transformer的模型相似或更好的性能。DeLighT更有效地在每个Transformer块内部(通过DeLighT变换)以及跨块(通过块级缩放)分配参数,允许输入端使用较浅较窄的DeLighT块,输出端使用较宽较深的DeLighT块。总体而言,DeLighT网络比标准Transformer模型深2.5到4倍,但参数和运算量更少。在基准机器翻译和语言建模任务上的实验表明,DeLighT在平均参数数量减少2到3倍的情况下,达到或提高了基线Transformer的性能。

解读论文:Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention

图片来源: https://aiptcomics.com/2024/04/10/transformers-7-2024-review/

摘要: 本文介绍了一种有效的方法,将基于Transformer的大型语言模型(LLMs)扩展到无限长的输入,同时受到内存和计算的限制。我们提出的方法的关键组成部分是一种新的注意力技术,称为Infini-attention。Infini-attention将一种压缩内存集成到了传统的注意力机制中,并在单个Transformer块中构建了掩码局部注意力和长期线性注意力机制。我们通过在长上下文语言建模基准、1M序列长度的口令(keypass)上下文块检索和500K长度的书籍摘要任务中使用1B和8B LLMs,展示了我们方法的有效性。我们的方法引入了最小的有界内存参数,并实现了LLMs的快速流式推理。

:为解决大模型(LLMs)在处理超长输入序列时遇到的内存限制问题,本文作者提出了一种新型架构:Infini-Transformer,它可以在有限内存条件下,让基于Transformer的大语言模型(LLMs)高效处理无限长的输入序列。实验结果表明:Infini-Transformer在长上下文语言建模任务上超越了基线模型,内存最高可节约114倍。

感觉有种外挂存储库(类似向量数据库)嵌入到模型结构中。比如: Memorizing Transformers + code

在论文《Memorizing Transformers》中,作者提出了一种新的注意力机制,称为kNN-augmented attention layer,它结合了局部上下文的密集自注意力和对外部记忆的近似k-最近邻(kNN)搜索。这个机制的关键部分之一是使用了一个门控机制(gating mechanism)来结合局部注意力和外部记忆的注意力。

翻译模型 inference 和 微调

image-20240328231303644

想把 HuggingFaceTB/cosmopedia 英文数据中的prompt和text 翻译成 中文, 然后看了下python库 deep_translator的实现, 翻译调用的是三方接口集成库, 于是使用这个库封装的谷歌翻译接口来翻译,但是三方平台接口多会有限流和接口调用频率限制,即使在代码中有容错处理, 比如常规的sleep下再调用,不影响整理处理流程,但是整体处理时间受接口限制,即使用批处理也如此,这个在大规模数据处理中使用三方接口时,经常会遇到的问题,用的三方服务,如果不升级接口服务,在技术上不太好解决; 于是选择另外一种方案,看是否有开源的翻译模型,底层模型结构一般也是Transform架构 Encoder-Decoder model ,也称sequence-to-sequence model; 比如 谷歌的T5模型, 但是推理速度受硬件条件影响,比较慢,而且原始模型不支持英文翻译成中文。

然后看了下meta nllb 模型,专门用来处理翻译的模型,单个 AI 模型中支持 200 种语言,开源地址: https://github.com/facebookresearch/fairseq/tree/nllb 模型相对现在的LLM参数量小一些,也在huggingface的Transforms库中集成 nllb-200-distilled-600M,直接可以load使用, 等等。。。 既然llm推理可以通过想llama.cpp通过加载ggml格式进行量化,在性能有少许折损的情况下降低推理成本,但是ggml gguf格式还不支持nllb模型权重文件(貌似llama.cpp只支持Transform Decoder模型结构);那就直接用Transforms库来加载facebook/nllb-200-distilled-600M 模型来批量翻译试试看;后续还尝试使用 Helsinki-NLP/opus-mt-en-zh 模型,进行了简单对比。

使用Gemma LLM构建RAG应用程序

img

介绍

随着大型语言模型的不断发展,构建 RAG(检索增强生成)应用程序的热潮与日俱增。谷歌推出了一个开源模型:Gemma。众所周知,RAG 代表了两种基本方法之间的融合: 基于检索的技术和生成模型。基于检索的技术涉及从广泛的知识库或语料库中获取相关信息以响应特定的查询。生成模型擅长利用训练数据中的见解从头开始创建新内容,从而精心制作原始文本或响应。

目的:使用开源模型gemma来构建 RAG 管道并看看它的性能如何。

通过chatGPT聊天解决rust线程安全问题

发现一个有趣玩法,针对rust 编译检查的问题(这个在编写代码逻辑的时候经常会遇到,逻辑是OK,但是通不过rust的安全检查),可以直接发给 chatGPT (其他通过代码库进行PT的模型,或者SFT的模型), 会给出修改意见,并且可以根据它的提示继续追问怎么解决; 如果直接通过传统的搜索引擎比如google, 也很难找出好的解决方法,而且还要去筛选,去尝试这个方法,如果不是权威网站,可能还被坑。来来回回折腾,效率太低了。像最近的AI程序员 david: introducing-devin ,其实类似思路,也是通过聊天来解决问题,只不过更加的专业,归根结底还是需要专业数据去PT/SFT底层的模型,上层应用通过pipeline对应框架去整体系统调优。(不知是否满足类似这种rust场景的解决方案pipeline,直接给它代码,帮忙修改)

Redis和GCP AI服务搭建RAG参考架构解决方案

本文主要是讲解一个快速搭建比如RAG pipeline相关应用参考方案,结合云厂商GCP AI服务,以及redis stack | vector index,借助 Google Cloud Platform 上易用的开发SDK, 以及使用redislabs 提供的免费30M内存空间服务;GCP新用户前三个月好像是免费使用一些服务,而且提供 $300 的赠金使用,对于前期学习和使用体验服务还是不错的选择,而且个人感觉学习文档很齐全,不会很零散。但是解决方案相对AWS要少些,毕竟AWS做的很深入,搭建解决方案很方便,集成开发工具比较齐全,特别是serverless lambda服务,可以看下以前写的文章『 用户行为分析方案设计』通过CDK构建解决方案stack(用于前期架构推演,不要YY,要动手,节约成本是干出来的)。

image-20240314215720290

以前注册的,忘记用了。。。

笔记地址:https://github.com/weedge/doraemon-nb/blob/main/Google_BigQuery_Palm_Redis.ipynb

:这里使用redis作为向量索引数据库,也可以结合其他向量索引库来搭建相应方案。主要目的是熟悉GCP服务和redis cloud服务。