李沐：给文本大模型加入一千万小时语音，开源 Higgs Audio

如果在训练文本大语言模型时加入一千万小时语音，会发生什么？李沐用这个问题开场，随后放了几段模型生成的声音：有带配乐的多人有声书，有调情式的对答，也有用「马老师」口吻吐槽声音模型还不如 B 站鬼畜区、再被回怼「菜就多炼」的戏仿。

他说，去年他们一直盯着文本大语言模型，让智商够高、能听从指示，能陪玩游戏、帮忙写文案，也就是能读能写。今年想让模型也能听、也能说。语音在 AI 里是相对古老的领域，他自己不是语音专家，新手想法很简单：不要去训练单独的语音模型，而是在文本 LLM 训练时加入大量语音数据，大力出奇迹。

目标是让文本模型的智商尽量不下降，同时掌握用语音沟通的能力。这期分享阶段性成果、背后的技术和踩过的坑，也希望开源模型对大家有用。首先要讲的是架构：怎样在一个文本语言模型里面加入语音。

他先回顾文本语言模型怎么工作。本质是给定前面一段话，预测下面一段话。比如问「中国的首都是？」，模型先接「北」，再在问题和「北」之后预测「京」。实际使用时通常不会让它直接做文字接龙，因为不够可控。

更常见的是把一次交互分成三部分。system 告诉模型要干什么，比如回答问题，也可以改成闲聊或写一段文字。user 给出具体任务，比如要问的问题或要写的小说。然后是模型的回复。还可以再接 user 和回复，做成多轮。

让模型支持语音输入输出其实也很简单：给它加一个新任务。系统命令可以是「把下面的文字转录成语音」，用户输入要转的文字，希望模型在回复里输出对应的语音数据。不必另起一套接口，还是同一套对话格式。

为什么要把语言模型改造成这样？以前语音识别或语音生成都是单独的模型，只做文字转语音或语音转文字。他们讲过 Whisper，虽然也基于 Transformer，但只干一件事。统一进文本模型的坏处很明显：为了语音能力，模型会比纯语音模型更大；同样一个文本模型加入语音数据，也很可能让智商变低。

好处同样明显。他举了一个简化的专业录音场景：导演告诉演员，接下来录的是小明和小红在吵架；小明性格急躁，小红比较腼腆；然后才是对白，还可能加上动作和音效。专业演员不仅要把句子读出来，还要符合人设和场景，才能完成表演。

上一代文字转语音模型，很难理解这么复杂的设定。有了语言模型加持，它就更可能听懂你让它干一件复杂的事——文本领域大家一直这么用：给一个很长的设定，ABCDEFG 都列清楚，请你做出来。训练时会尽量让模型遵从人的指示。如果文本能力保留过来，做语音输出时，他也希望能支持这样的指示。这是第一点：对复杂指令的理解。

第二点是，简单的文本到语音已经不够。比如不仅生成一段语音，还希望模型写一首歌、唱出来，配乐也要跟上。理解侧也一样：最简单的是把声音里的人话抓出来；再进一步，分析里面在干什么。

人不看画面，只听声音，也能判断是什么样的人、男性女性、年纪如何、说话场景怎样，他们是在吵架、对话，还是一堂教学。根据环境音，还能猜是在室内还是室外。语音里有大量信号，人能理解整个上下文。有了文本语言模型，就能做这种更复杂的理解和推理。

再复杂一点，就是大家玩过的语音聊天：和模型一来一回。他希望模型不是机械地一轮一轮回复，而能理解你当前的心情，并把情绪表达出来。延迟也要足够低，不要说完一句话等一两秒才答，而要像面对面那样，大概零点几秒的交互。

这些任务都能拆成 system、user、再回复这样的格式，让语言模型统一处理。一个相对固定、简单的配方，处理所有问题。然后通过加更多数据、更多算力，靠 scaling law 大力出奇迹。这就是他们选择这种看起来更复杂的模型的原因。

接下来要回答两个「怎么做」。第一，整个语音或声音信号，怎样让模型理解和输出。第二，训练时要构造怎样的数据，才能把语音信号和文本信号融合起来，让模型理解这段语音到底在表达什么。

先回顾文字在语言模型里怎么表示：用 token，也就是词元。中文一个字、英语一个词根，都可以看成一个 token。一段文字会表示成一串 token，语言模型看到的是这个序列，再输出下一个 token。

token 是离散的，有一本词典告诉你一共有几万个。之所以这么做，是因为语言模型的输出是 softmax，本质是多分类：每次在词表里选一个作为输出。语音麻烦在于它是连续信号，怎样表示成离散 token？

最简单的做法：一秒钟语音按 100 毫秒切开，得到 10 段。再假设世界上的声音在很细的粒度上不断重复——中文也就那么多音节——于是挑出一些有代表性的常见片段当模板，把每一小段用最近似的模板来表示。

他用 45 个这样的片段当模板。来了一秒语音，切成 10 小段，每段在 45 个模板里找最相近的那一个。这一秒就变成长度为 10 的序列，每个位置只是一个编号，比如第一个 100 毫秒用的是第 5 个模板。这样，语言模型就能像处理文本一样处理语音，无论输入还是输出。

事情当然没那么简单，语音并不容易被表示。他给了一组数字：一小时语音用 128kbps 的 MP3 存储，大约 60MB。128kbps 已经只是中等水平，听歌可能要 192 甚至 320，或者无损。所以这已经是质量一般的 MP3。

如果用 token 表示，假设词表有 64000 个，已经接近实际常用的词典大小；一秒钟音频用 24 个 token，也是常见做法。每个 token 只需记下编号，也就是 log2(64K)。于是一秒音频大约 384 bit，一小时就压到约 0.16MB，相当于在 128kbps MP3 上又做了约 375 倍压缩。

压成这样，质量肯定糊得一塌糊涂。怎样做好 tokenizer，是非常关键的技术。他问：在丢掉绝大部分东西的情况下，应该优先保留声学信号，比如说话的音调，好在生成时还原；还是尽量保住语义，也就是这段话到底在说什么？

他们的发现是：应该优先保持语义。声学上有一点点就行，说话风格保留一些，后面可以用别的手段还原。语义则千变万化，同一个声音在不同场景里说的东西会不一样。尽量让语义 token 里包含大量语义信息，使语音和文本 token 的语义很早就联系起来，模型才能流利地在文本和语音之间互换。

这期不在语音 token 上讲太深，有兴趣可以看他们发布的代码，以及和别人的 tokenizer 对比。重点是：必须把语音信号表达好、压缩好，后面生成或处理的声音才可能让你满意。

声音表示成 token 进入模型之后，接下来是怎样理解和生成。声音转文字或文字转声音，本质是模态之间的转换：让语言模型把同一件事的语音表示和文字表示映射起来。既然已经用了文本大语言模型，文本能力很强，就可以考虑把语音的语义尽量映射回文本，好利用它在文本空间里的大量能力。

有人会问：做实时语音助手，听上去是我说一句、模型回一句，是不是直接在语音空间做？以现在的技术，其实还是会回到文本空间。因为人设是什么、什么该做不该做，是用文字控制的。实时互动时也很可能在文本空间操作：问今天天气怎么样，模型可能先在文本里搜一下，把结果映射回语音。核心是打通文本和语音，而不是在语音上另圈一套。

简单来说，模型要理解：某个概念的文字 token 和语音 token，只是同一种意思的两种表达。有了这个目标，就可以谈要什么样的数据、数据怎么表达。数据反正是越多越好。

大家猜没猜到，他们有没有用 B 站或 YouTube 的数据？答案是没有。不是数据不好，那些数据应该挺好，但网站说了不允许爬。为了尽量避免版权问题，做法是要么买，价格不能太贵；要么在允许抓取的网页里找有没有音频文件。

这样抓来的数据自然可能非常差，也许要删掉 90% 才能留下一点点能用的。为了凑齐一千万小时训练数据，可能要先抓取约一亿小时才够。有了数据之后，下一步才是怎样把它送进模型训练。

他给了一个对话例子。训练时会表达成：在系统层面写出这段声音的声学特征、语义上在聊什么、有哪些人、这些人说话有什么特点，也就是对场景的描述。用户输入是要说的文字，模型输出对应的音频。任务是：根据场景描述和要生成的文字，输出符合场景的真实语音。

这些标是怎么打出来的？如果是学生做研究，他推荐把语音交给 OpenAI 的 GPT 或 Google 的 Gemini 打标。他们做不了，有两个原因。第一，人家明令禁止拿模型输出再去训练别的模型。第二，成本太贵：要处理的根本不止一千万，可能是上亿小时丢进去，这点 API 费用承受不来。

他们的做法是：用同样的模型架构，另训一个语音理解模型。生成时是告诉你场景、用户要说哪些话，你输出语音。现在反过来：用户给你一段语音，请你分析场景、有哪些人、这些人什么样、在说什么、当时情绪如何，然后输出所有这些。等价于把生成模型的输入输出对调。

他打了个比方：要教徒弟拳脚功夫，一次教不来，就先教两个徒弟，一个会打拳，一个会踢腿，让他们天天对打，打着打着共同进步，最后都学会拳脚。故事这样就圆回来了。训练出来的模型，代码发布在 GitHub 的 boson-ai/higgs-audio 仓库。

仓库里有链接。不安装的话可以去 playground 玩，也有 Hugging Face 的 playground：虽然要跑在 GPU 上，但每人每天好像有三分钟免费，点一下会调 Hugging Face 自己的 GPU。他放了一句演示：「The sun rises in the east and sets in the west。」这个频道当然还是要自己动手，于是跳到安装。

如果已经有 GPU 版的 PyTorch，直接按说明安装。没有的话，他推荐 NVIDIA 提供的 Docker：本地只要装了 NVIDIA 驱动和 Docker 就能跑，省去装 CUDA 和 PyTorch 那一套麻烦。他们用的还是三年前那台 3090。

先 git clone 这个仓库，再跑 PyTorch 的 Docker，把自己的 home 目录映射进去。下载解压要等很久。进入 clone 好的目录后直接安装，又是漫长等待——他吐槽大家写包时依赖乱写，彼此关系错综复杂。

装完回到 README，复制一段样例来跑。例子是用 belinda 这个人的声音，温度 0.3。想要更稳定就温度低一点，想要表现力更丰富就温度高一点。要生成的文本和 playground 里是同一句。复制下来运行，又要等模型下载；有 GPU 就会默认在 GPU 上跑。

生成的声音可以听。仔细看，它干的事情是：在 example 的 voice prompt 下面，把 belinda 这个人的文字和语音找出来，文字作为上一轮用户输入，语音作为上一轮系统输出；你再给一段新文字，它就能输出与这个人声音一致的语音。这期前面展示的所有语音片段，都是这样生成的。

主页上还有更离谱的：把一个人的声音从一种语言转到另一种。演示里，英文问「Any good places that I should go?」，同一把声音用中文聊下星期去首尔、要待多久。到这里大概能猜出，为什么这个模型的声音克隆这么强——即使这些声音多半来自 B 站或 YouTube 这类视频，模型并没有大规模见过，因为训练没用过那些视频。

他们抓的是纯音频，统计分布和视频数据差别还挺大。原因有两点。第一，见过那么多数据，什么样的声音多多少少都见过。第二，看数据构造方法：做声音克隆时，把用来克隆的那整段声音做成上一轮的用户输入和系统输出。

训练数据中间有一段连续性，里面是很多轮。给定前面几轮对话，接下来的对话在语义和场景上应有连续性。所以模型能从你提供的克隆参考里，抓取整个场景信息、说话人的特点，以及一定的语义，再在你新提供的文字上做匹配和延续。

这也提示：要生成某一场景的文字时，最好找到类似场景里那个人说话的语音，比如吵架、放松、大笑，会更合适。对人来说也是这样：你提供一本正经说话的声音，却要模仿这把声音去做 talk show，肯定更难。

如果找不到完全匹配的参考，还有一个补救：修改系统信息，在系统里说明你需要克隆出来的声音场景是什么样，希望模型把你提供的声音和系统指示合起来，合成你要的东西。他认为，这就是这种多模态语音文本大语言模型该怎么做 prompt engineering。

这期到此结束。这算一个新方向，他们想分享创业中遇到的有意思的问题、做过的工作和学到的东西，希望对大家有帮助。最后欢迎去试试他们开源的模型，希望能给大家带来快乐。