端到端语音对话模型

发表于 更新于 分类于 本文字数： 2.3k 阅读时长 ≈ 4 分钟

0-前言

端到端语音对话模型的github项目：
GLM-4-Voice、mini-omni2、LLaMA-Omni2

端到端语音对话模型是指一种直接从原始语音输入生成对应语音或文本响应的完整人工智能系统。它的核心思想是用一个统一的模型处理整个对话流程，而不是依赖多个独立的模块拼接

注：omni代表“全模态”；拉取镜像最好用socks5协议或者proxychains

“Omni” 模型的不同之处在于： 它把所有模态（听、说、读、写、看）全部塞进了一个大脑里进行端到端（End-to-End）处理。它直接理解音频信号，直接生成音频流。

一块30系列的8G显卡正好能运行量化版本int4或者Q4_K_M的量化。

湖南电力2025年信息安规题库

1-mini-omni2

conda拉取完直接跑就行服务和网页即可

优点：

回答迅速，有现成的客户端能直接实现快速应答

缺点：

国内使用，目前听得懂中文，但生成不了中文

2-GLM-4-Voice

#自己的单卡显卡性能跑这玩意回复要15s左右

部署出现较多环境错误，记录部分版本如下：

python3.10

1
2
3
4
pip install transformers==4.45.0 accelerate==0.34.0 bitsandbytes==0.43.3
#强制对齐版本
pip install torchaudio --index-url https://download.pytorch.org/whl/cu121
pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu121 --force-reinstall
库名称 **版本 **
transformers 4.45.0
huggingface_hub 0.24.7
ruamel.yaml <0.18.0
torchaudio 与 torch 匹配

2-LLaMA-Omni2

#比较适用，现成的客户端还支持流式更新，推荐客户端：llama.cpp-omni(全双工语音交互客户端)

因为它属于基于 LLM 的多模态语音模型，所以可以给 LLaMA-Omni2 添加向量数据库（RAG, 检索增强生成）可以让模型基于个人的知识库回答问题，而不需要重新训练模型，可以在客户端跑检索条件，避免浪费服务器算力。

1>身份赋予

①**process_messages** 是将“对话列表”转换为模型能理解的“数字序列（Tokens）”的核心中转站

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#/LLaMA-Omni2/llama_omni2/serve/model_worker.py：
def process_messages(self, messages):
    # 1. 验证对话完整性
    assert len(messages) % 2 == 1, "Number of history messages must be odd"
    
    # 2. 应用聊天模板 (关键步骤)
    input_ids = self.tokenizer.apply_chat_template(
        messages, 
        add_generation_prompt=True, 
        return_tensors="pt"
    )[0]
    
    # 3. 语音标识符替换
    input_ids[input_ids == self.tokenizer.convert_tokens_to_ids(DEFAULT_SPEECH_TOKEN)] = SPEECH_TOKEN_INDEX
    
    return input_ids

②每段前插入一个系统用户的文字

1
2
3
4
5
6
7
8
9
10
11
12
# --- 在这里插入你的个性化身份 ---
    custom_messages = [
        {"role": "system", "content": "你是一个名为'xxxx'的私人助手"}
    ] + messages 
    # -----------------------------
    
    # 2. 应用聊天模板 (关键步骤)
    input_ids = self.tokenizer.apply_chat_template(
        custom_messages, 
        add_generation_prompt=True, 
        return_tensors="pt"
    )[0]

2>添加向量数据库

①后台同步转写

输入（如果是语音，需转为文本—多一个步骤）拿去向量数据库检索，检索出来的内容拼接到Prompt里面

②语义向量直接匹配

非常炸裂，将概念的文字转换成抽象的感觉再去匹配

两者方案对比

下面的处理速度来自ai的推测：

**CLAP (纯向量方案)**：处理 5 秒音频大约需要 20-50ms。

**Whisper Tiny (转写方案)**：处理 5 秒音频大约需要 50-100ms。

语义向量直接匹配 语音文字转写匹配
优点 极快，超越语言范畴 延迟高，通用性强
缺点 构建难度高、纯电子音匹配低 现有项目成熟、多语言要提升硬件

待续。。。