博客 | VoicePing

多语言 OCR 基准测试：Hunyuan 与 Qwen 领先准确率，Paddle 领先吞吐量

Thu, 16 Jul 2026 00:00:00 +0000

模型与参考资料：

PaddleOCR PP-OCRv5 — 根据所选语言识别器，活跃参数量为 310万至530万；面向移动端的检测-识别 OCR，可返回多边形和置信度。
EasyOCR — 根据语言 reader，活跃参数量为 2460万至7460万；使用 CRAFT 检测与 PyTorch 识别，返回文本区域和置信度。
docTR — 本次评估的预训练 predictor 含2640万参数；两阶段 PyTorch 文档 OCR，可返回结构化区域和置信度。
GLM-OCR — 13.3亿参数；通过 Transformers 生成方式评估的视觉语言 OCR，用于纯文本和 Markdown 提取。
Granite Docling 258M — 2.575亿参数；紧凑型 Transformers 文档转换模型，生成带版面位置的 DocTags。
HunyuanOCR — 11.2亿参数；面向文字定位、文档解析和语义文档任务的专用 OCR 视觉语言生成模型。
Qwen3-VL-8B-Instruct — 87.7亿参数；用于多语言 OCR 与 Markdown 提取的通用视觉语言生成模型。
Surya OCR 2 — 6.862亿参数；具备版面感知能力的 Transformers 生成模型，可输出带区域坐标的文本或 HTML。

参数量描述的是评估时实际启用的检查点权重，而不是下载文件大小。传统 OCR 的总数包含检测器与该页面所加载的语言专用识别器；生成模型使用公开检查点中的张量数量。

摘要

我们在同一套 900 页数据上评估了八个开源 OCR 系统：五种语言、六类图像，每个“语言×图像类型”单元包含 30 页。所有系统均在一张 NVIDIA RTX PRO 6000 Blackwell Max-Q GPU 上运行，并严格禁止自动回退到 CPU。

大规模说话人识别为何困难？五种模型的多语言开放集基准测试

Fri, 10 Jul 2026 00:00:00 +0000

说话人识别基准往往强调很小的等错误率差异和模型排名。本研究把重点放在开放集系统真正需要作出的判断上：当探测语音的说话人可能未被注册时，排名第一的匹配是否足够强且足够明确，能够被系统接受。

核心结论

当有4秒语音和4个注册样本时，五个模型的实际性能差异很小。在2秒条件下，ReDimNet-B6和w2v-BERT-SV构成领先组。ReDimNet的检查点规模较小，并且在主要留出评估以及干净条件和大图库辅助检验中都表现稳定，因此具有最强的综合研究依据。但这些证据仍不足以决定替换生产模型。

最重要的运营结论是，拒绝判定必须针对每个模型单独校准。统一的余弦阈值比较的不只是说话人区分能力，还会比较尺度不同的嵌入空间。每个检查点都需要使用有代表性的开发身份来选择相似度阈值，以及第一名与第二名的分数间隔（margin）。

下文将依次回答四个问题：语音很短时，哪些模型仍然可靠？有4秒语音时，模型差异是否仍然存在？应该如何拒绝未知说话人？综合准确率、计算量和许可证信息后，证据是否足以支持生产决策？

主要留出评估

哪一项证据应该占据最大权重？身份分离的开放集比较是主要证据，因为它在比较全部五个模型的同时，将校准说话人与最终测试说话人分开。每种语言保留20个身份在图库中，并完全移除10个身份。移除身份中的5个用于选择相似度阈值和前两名分数的margin，另外5个则在设置不变的情况下进行测试。由此得到100人图库、25个开发未知身份，以及与开发集身份分离的25个测试未知身份。所有模型使用由哈希固定的同一组探测语音。

开放集识别包含两个相互关联的判断：哪个注册说话人的相似度最高，以及该匹配是否足够可信、可以接受。本文报告等错误率（EER）、检测与识别率（DIR，即已知探测语音被正确识别且接受的比例），以及未知说话人的误接受率（FAR）。

阈值和margin仅使用开发身份进行选择，要求开发未知身份的FAR不高于1%，然后原样应用于测试群组。置信区间使用2,000次按说话人聚类的bootstrap，另用50个确定性身份划分来测量结果对所选说话人的敏感度。这样的分离使留出评估成为本研究最可信的开放集证据。

使用4个注册嵌入的代表性划分结果如下：

探测时长	模型	EER（95% CI）	DIR（95% CI）	观测测试 FAR
2s	ReDimNet-B6	1.40% (0.54–1.98)	94.80% (91.60–97.60)	1.60%
2s	w2v-BERT-SV	1.05% (0.51–1.53)	92.20% (87.80–96.00)	1.20%
2s	WeSpeaker R221-LM	1.80% (0.75–2.81)	89.60% (85.00–93.60)	0.80%
2s	ECAPA-TDNN	2.20% (1.12–3.31)	84.80% (79.80–89.20)	0.80%
2s	TitaNet-L	2.22% (1.22–3.04)	83.80% (78.20–88.80)	2.00%
4s	TitaNet-L	0.60% (0.15–1.04)	98.80% (97.60–99.80)	2.40%
4s	ReDimNet-B6	0.20% (0.01–0.60)	98.60% (97.20–99.60)	0.00%
4s	w2v-BERT-SV	0.62% (0.11–1.39)	98.40% (96.80–99.80)	0.00%
4s	WeSpeaker R221-LM	0.60% (0.11–1.54)	98.20% (96.20–99.60)	1.20%
4s	ECAPA-TDNN	0.80% (0.20–1.42)	97.80% (96.00–99.20)	1.20%

介绍 VoicePing Diarization v0.1

Tue, 07 Jul 2026 00:00:00 +0000

介绍 VoicePing Diarization v0.1

VoicePing Diarization v0.1 是我们首次公开发布的说话人分离模型：它面向多语言会议进行说话人分段，用来识别谁在什么时候发言，并为后续的说话人身份匹配做准备。

本文通过 2026 年 7 月的一项 42 文件多语言基准介绍该模型。NeMo、pyannoteAI precision-2、AssemblyAI 和 Deepgram 也作为评估背景纳入其中，帮助读者理解 VoicePing Diarization v0.1 相对于常见开源方案和商业说话人标注方案的位置。

有一点需要说明：VoicePing Diarization v0.1 是所选基准行的公开模型身份，并不是对生产模型注册表的实时检查。生产模型选择由运行时配置控制，生产系统还包含该纯说话人分离基准之外的下游说话人身份匹配。

评估设置

该基准包含 42 个文件、约 10.5 小时音频：英语、日语、韩语、越南语和普通话五个单语集合，以及两个代码切换的多语言文件。场景从 30 秒到 1 小时不等，包含 2-9 名说话人和 0-30% 的重叠语音。

这些文件是由真实单人录音拼接成的合成对话。因此它们拥有精确的参考标签和可重复的评分，但也比许多真实会议更干净。结果应被视为受控基准，而不是域外会议评估的替代品。

评估集有意比原始内部导出更窄。NeMo 作为主要本地开源基线，使用重新运行产物中的 NeMo Neural MSDD 结果。pyannoteAI precision-2 作为最清晰的专用商业说话人分离服务。Deepgram 和 AssemblyAI 被纳入，是因为采购者在评估带说话人转写时经常比较它们，但被遮蔽的单元格不用于直接的标题排名。

方法细节：DER 使用 pyannote.metrics 风格的说话人分离错误率计算，采用 fair collar，计入重叠语音，并按语料时长加权聚合。2026 年 7 月的研究评估导出使用了 voiceping-inc/titanet Hugging Face 快照（titanet_finetuned.nemo）中的 VoicePing Diarization v0.1 基准行、NeMo Neural MSDD 基线、pyannoteAI precision-2，以及 AssemblyAI 和 Deepgram 的 transcript 附带说话人标签输出。

VoicePing MT V0.1：英日AI翻译基准测试

Mon, 06 Jul 2026 00:00:00 +0000

Introducing VoicePing Translation Model MT V0.1

对全球团队来说，英语对话只有转成准确、完整、自然的日语，才能在日本真正发挥作用。本基准测试评估的就是这一实际任务：将英语源文本翻译成既保留含义又自然可读的日语。

概览

模型	总分	流畅度（Fluency）	自然度（Naturalness）	准确性（Accuracy）	完整性（Completeness）
DeepL	89.4	91.1	89.0	88.7	89.7
Sakana Translate	88.0	86.7	83.2	88.5	90.4
VoicePing MT v0.1	87.2	90.7	87.5	86.0	86.8
GPT-5 mini	87.0	88.4	85.5	86.9	87.1
Google Translate	86.7	87.1	83.0	86.4	88.6
Qwen3.6-27B-FP8 dequant	86.3	88.0	84.9	86.4	86.2
Azure Translate	79.2	78.5	73.3	79.1	82.6
Llama 3.1 8B	72.2	71.7	65.4	72.8	75.1

评估设置

评估使用100条英语源文本。由于没有可信的日语标准译文，我们采用GPT-5.5逐模型评分。评审每次只看到英语原文和一个日语译文，不会看到其他模型输出或供应商名称。

VoicePing ASR Model V0.1 正式发布

Wed, 01 Jul 2026 00:00:00 +0000

VoicePing ASR Model V0.1 正式发布

今天，我们正式发布 VoicePing ASR Model V0.1——我们面向 VoicePing 中最常用语言打造的多语言语音转文字模型，覆盖英语、日语、韩语、中文和越南语五种语言。

VoicePing 的核心是多语言语音沟通：会议、活动、语音翻译、转写文本、摘要与搜索。在这些工作流程中，自动语音识别（ASR）并不是一个孤立的功能，而是整个产品体验的第一层。如果转写结果不稳定，后续每一个环节的价值都会随之打折。

VoicePing ASR Model V0.1 正是为这一现实而设计。它聚焦于我们服务最多的五种核心语言，目标是为真实对话生成更干净的转写文本。

一个模型，胜任多语言场景

通用语音识别技术进步很快，但真实的多语言音频仍然存在不少难点：

日语、韩语和中文需要针对语言特性的文本处理。
越南语高度依赖准确的声调符号和词语边界。
较长或嘈杂的音频片段容易出现转写不完整、输出为空或文本重复的问题。
云端模型在不同语言上的表现可能差异很大，即使 API 接口看起来是统一的。
在公开基准测试中表现出色的系统，未必最适合会议、活动和语音翻译场景。

VoicePing ASR Model V0.1 是我们围绕这五种语言的产品场景打造的首个整合模型。下面的基准测试要回答的是一个非常实际的问题：它对用户真正关心的语音，转写效果究竟如何？

它能做什么

VoicePing ASR Model V0.1 可以转写以下语言的语音：

英语
日语
韩语
中文
越南语

其输出的转写文本，是 VoicePing 后续功能的基础，包括翻译、字幕、会议纪要以及可搜索的对话历史。

本文中 ASR 与 STT 可互换使用，两者均指语音转文字（Speech-to-Text）转写。

评测

数据集

本次评测使用 VoicePing 的多语言语音测试集，每种语言 1,000 条音频片段，总时长约 41 小时。这些片段反映了 VoicePing 在实际使用中处理的语音类型：真实对话，而非干净的朗读录音。

语言	片段数
英语	1,000
日语	1,000
越南语	1,000
韩语	1,000
中文	1,000
合计	5,000

所有系统均在同一套音频上进行测试。

VoicePing 为东京 MedTech ROUND Pitch Day 提供实时英日翻译

Wed, 01 Jul 2026 00:00:00 +0000

VoicePing 为东京 MedTech ROUND Pitch Day 提供实时英语到日语翻译

九家医疗器械初创企业用英语进行路演。会场中的日本医生、工程师和制造商代表，则通过自己的手机和现场屏幕实时用日语跟进内容。

主屏幕上是英语路演，左侧第二块屏幕同步显示实时日语翻译。

活动概况

MedTech ROUND Pitch Day 于 2026 年 5 月 28 日星期四在东京中城八重洲（Tokyo Midtown Yaesu）5 层活动空间举行，场地可俯瞰东京站。这是 MedTech ROUND 的 Demo Day。MedTech ROUND 是面向医疗器械初创企业的加速项目，由东京大学 Tokyo Biodesign 项目运营，并获得日本经济产业省（METI）和日本医疗研究开发机构（AMED）支持。

登上这个舞台的门槛很高。约 80 家初创企业报名，12 家入选项目，最终有 9 家在当天进行路演。现场观众包括约 15 家医疗器械企业：既有作为项目企业合作伙伴的日本及全球领先制造商，也有投资人和项目运营团队。会场座无虚席。

该项目由东京大学 Tokyo Biodesign、METI 和 AMED 支持。

面临的挑战

整场活动以英语进行。九家初创企业全部使用英语路演，这是会场中全球制造商和国际嘉宾之间的共同语言。但这些企业最希望直接触达的许多人，包括日本医疗器械制造商、临床医生和投资人，主要用日语思考和工作。如果英语信息没有被充分理解，路演的价值也会随之打折。

医疗器械路演本身也很难翻译。内容高度密集，涉及解剖学、临床操作、器械机制、监管术语，以及疾病和技术名称。这些正是通用翻译工具最容易出错的词。在这个会场里，专业术语就是路演的核心。术语传达准确，路演信息才真正传达出去。

东京中城八重洲 5 层活动空间，观众入场前的现场。

VoicePing 在京都 JPCA 2026 提供实时双语翻译

Wed, 01 Jul 2026 00:00:00 +0000

VoicePing 在京都 JPCA 2026 提供实时双向翻译

来自加拿大的演讲嘉宾使用英语，日本医生使用日语。VoicePing 让会场中的每个人都能用自己的语言实时跟上同一场研讨会。

英语演讲在主屏幕上实时显示日语字幕。

活动概况

第 17 届日本基层医疗联合学会学术大会（JPCA 2026）于 2026 年 5 月 29 日至 31 日在京都国际会议中心举行。大会主题为 “Collaborating for Care. Connecting for Change."。VoicePing 为 5 月 30 日星期六的一场重点研讨会提供支持。

当前，基层医疗在日本的重要性日益突出。日本约三分之一人口为老年人，许多患者同时面对多种健康问题，医疗服务差距也在扩大。因此，一线医生在日常诊疗中的作用比以往任何时候都更关键。日本基层医疗也在积极借鉴海外经验，而加拿大是家庭医学领域经常参考的国家之一。

主舞台屏幕上的大会主题。

面临的挑战

这场研讨会采用双语形式。来自加拿大的教授使用英语发言，日本基层医疗医生使用日语发言。即使是事先准备好的演讲，现场翻译也并不容易。医学术语高度精确，翻译中很小的偏差都可能改变原意。

真正的难点出现在最后。研讨会以英日交替的现场问答和小组讨论收尾。在这种讨论中，语言会不断切换。有人用日语提问，加拿大教授用英语回答，另一位小组成员再加入讨论，没有人能提前知道下一句会是哪种语言。

要在现场准确翻译这样的对话并不简单。单一口译员可能难以跟上快速往返的节奏。只支持单向翻译的工具，也无法应对不断切换语言的讨论。普通翻译工具还可能在关键医学术语上出错，而这些术语恰恰最重要。

VoicePing 的做法

VoicePing 以自动语言识别的双语模式支持整场研讨会。系统不固定为某一个翻译方向，而是自动识别正在使用的语言，并按正确方向进行翻译。英语实时转为日语，日语也实时转为英语。小组讨论来回切换时，不需要任何人手动调整方向。

VoicePing 支持 48 种语言。在这个会场中，真正需要的是英语和日语。

参会者可以选择最适合自己的方式跟进内容。有些人扫描二维码，在自己的手机上用所需语言阅读翻译，无需安装应用；也有人通过会场共享屏幕查看翻译。

加拿大讲座的幻灯片在展示的同时，被实时翻译成日语显示在屏幕上。

现场效果

真正的考验是现场小组讨论，而系统顺利完成了任务。由于系统能够自动识别语言，语言切换时不需要人工介入。用日语提出的问题可以由英语回答，英语回答也能实时以日语显示在屏幕上，整个过程无需调整任何设置。

整场研讨会中，两个方向的翻译都持续运行。加拿大教授发言时，屏幕同步显示实时日语字幕；日本医生发言时，也同样实时显示为英语。参会者不再等待翻译，而是自然地跟上讨论。

主屏幕上的演讲者：会场视角下的研讨会现场。

为什么重要

日本基层医疗正在把世界各地的优秀实践带给服务老龄化社会的一线医生。前提是语言不能成为阻碍。当翻译能够跟上对话节奏时，人们就不再关注语言本身，而是专注于医学内容。

这正是 VoicePing 的价值所在：让同一个会场中的人即使不使用同一种语言，也能彼此沟通。

京都国际会议中心外的大会指示牌。

没有逐字稿的炉边对谈：VoicePing 为 Early-Stage Deep Tech Forum 提供实时日英翻译

Wed, 01 Jul 2026 00:00:00 +0000

没有逐字稿的炉边对谈：VoicePing 为 Early-Stage Deep Tech Forum 提供实时日英翻译

来自海外的机器人和量子领域创始人，与日本投资人、研究人员和政策相关人士同处一室。演讲和开放问答在两种语言之间展开，VoicePing 在发言发生的同时完成现场翻译。

论坛：TIB 的一场早期深科技之夜

从人形机器人到量子技术，再到其他仍在从实验室走向商业化的新兴技术，深科技往往跨越国家和语言。创始人、投资人和研究人员并不总在同一地点，也未必使用同一种语言。对这样的活动来说，重要工作之一就是确保所有人都能跟上同一场对话。

2026 年 5 月 27 日，这场对话在东京丸之内的 Tokyo Innovation Base（TIB）举行，活动名称为 Early-Stage Deep Tech Forum [Robotics, Quantum & Emerging Technologies]。论坛时间为 17:30 至 20:00，由 Deloitte Tohmatsu 和 MFV Partners 主办，并与 Morning Pitch Asia 合作。晚间环节包括主题演讲、演示、炉边对谈、现场问答和交流。

炉边对谈现场，VoicePing 的实时日英翻译显示在旁边的会场屏幕上。

会场中的两块屏幕：一块显示幻灯片，另一块显示 VoicePing 实时翻译。

挑战：没有逐字稿的现场对话

嘉宾需要跨越语言边界展开讨论。Karthee Madasamy（MFV Partners 管理合伙人）担任主持。台上嘉宾包括 Agility Robotics 联合创始人兼董事长 Damion Shelton，以及 Asteria 创始人兼 CEO Yoichiro Hirano：一位美国机器人公司创始人和一位日本软件公司创始人，面对的主要是日本观众。

UNLEASH Insights 2026：为赴印日本投资者代表团提供实时AI翻译

Mon, 29 Jun 2026 00:00:00 +0000

VoicePing · Customer Story · UNLEASH2026

当一家日本风险投资基金带着投资者前往印度参加为期数天的峰会时，现场天然就是双语环境：项目在印度展开，观众则以日本人为主。UNLEASH Capital Partners在UNLEASH Insights 2026上正面临这样的场景，并首次采用了VoicePing的实时AI翻译，覆盖两天的小组讨论、演讲和问答环节。

我们与UNLEASH Capital Partners的Sowmya Arunkumar进行了交流，了解他们为什么选择VoicePing、现场如何使用、哪些地方效果不错，以及坦率地说，哪些方面仍需要改进。我们保留了她直接、真实的反馈，因为她提出的愿望清单，正是我们正在推进的产品路线图。

活动与语言障碍

— 能否先介绍一下自己，以及UNLEASH Insights 2026是什么样的活动？

Sowmya: 我在UNLEASH担任顾问，负责影响力投资论点的构建与报告，同时也参与投资组合管理。我是在2025年12月加入的。我们5月安排了一场活动，大约有30到40位日本代表来到印度，我就是因为这场活动联系了VoicePing。活动主要介绍我们在印度所做的事情，包括我们的投资方向，以及围绕投资组合公司的讨论。整体形式包括小组讨论、一对一演示，以及贯穿全程的问答。

— 语言方面的挑战是什么？

Sowmya: 大多数代表听英语也还可以，但用日语理解起来会更从容。因此，我们希望他们能够跟上各个环节中正在发生和讨论的内容。

为什么选择VoicePing

— 是什么让你们选择了VoicePing？

Sowmya: 我们调研了印度本地可用的很多工具。主要担心的是，在小组讨论中，很多工具通常无法准确拾取每位发言人的声音和表达，因此翻译结果并不正确。这也是我们在用户评价里看到的主要问题。也有头戴式耳机或耳机方案，但给35到40个人分发这些设备，对我们来说并不合理，所以我们需要一个符合需求的软件方案。

— 其他方案如何？

Sowmya: 收费模式不适合我们。对一天的活动来说价格偏高，而且大多是订阅制，例如50小时或100小时套餐。对于一次性活动来说，这没有意义。这是一个年度活动，我们只在那个时候需要翻译，并不是日常使用。

— 你们是怎么找到我们的？

Sowmya: 是通过推荐。我们的Managing Partner Natsuki Sugai先生从一位在日本用过VoicePing的朋友那里听说了这款产品。那位朋友说，VoicePing在过去两年进步很大，建议我们试试看。于是我就联系了VoicePing团队。

现场如何使用

— 现场翻译在两天会议期间，通过主屏幕旁边的会场显示器实时展示。团队在设置过程中是否有帮助？

Sowmya: 有，团队从头到尾都很支持。他们帮助我们下载软件，也和场地的AV团队一起在会场里做了几次测试。活动当天，Aaron也整天在现场协助我们。

— 价格方案是否容易配合你们的需求？

Sowmya: 是的。第一次通话时，团队解释了适用于一天或两天活动的套餐，这非常有帮助。我们也在那次通话中看了演示，这让我们确信它适合我们。

活动当天：有效之处与不足之处

— 翻译质量如何？

Sowmya: 英语到日语还可以。但有一场会议中，有人用日语发言，需要翻译成英语，那部分确实没有达到预期。我不懂日语，所以完全依赖翻译内容。有些时候，出来的英文内容并不准确。

— 屏幕上的显示方式呢？

Sowmya: 一个短语一旦翻译出来，就不应该再被反复改写。我读完一句并理解了它，但当我准备看下一句时，前一行已经变了，意思就丢失了。这让人困惑，而且节奏太快，很难跟上。

— 这是非常合理的反馈。日语和英语的语序几乎相反，日语句子的意思往往要等到句尾动词出现后才完全确定。因此，早期生成的英文译文可能会在句子中途被修正。这是我们已经认识到的限制，我们正在开发一个减少文字闪动的新模型。在通话中，我们也展示了分屏视图，可以把已经稳定下来的内容固定在实时文本旁边。

— 观众整体反馈如何？

Sowmya: 比什么都没有要好。参会者用日语会更舒服，翻译也帮助他们跟上现场正在发生的内容。

情感 TTS 基准测试：Qwen3-TTS、CosyVoice、IndexTTS-2、Fish Audio 与 VoxCPM 在日语和中文上的表现

Fri, 26 Jun 2026 00:00:00 +0000

模型与参考资料：

Qwen3-TTS CustomVoice 1.7B - 支持显式情绪提示的自定义音色 TTS。
CosyVoice 300M Instruct / CosyVoice2 - instruction 风格 TTS 基线，带日语和中文内置说话人。
Fish Audio S1-mini - 使用内联情绪标记的表现力 TTS 模型。
VoxCPM2 - 多语言提示驱动 TTS 模型。
IndexTTS-2 - 本文作为日语/中文实验对比对象评估的情感零样本 TTS 模型。

摘要

本文评估了五个面向日语和中文的情感文本转语音系统，目标情绪包括 neutral、happy、sad、angry、fear 和 disgust。评估使用语义中性的提示句，因此模型必须通过语音风格表达情绪，而不是依赖文本本身的情绪词。每个模型生成120个样本，五个完成模型共形成600个 WAV 文件的主基准语料。

综合表现最均衡的候选模型是 Qwen3-TTS CustomVoice 1.7B：在日语和中文文本输出可信的模型中，它拥有最好的综合 SenseVoice 准确率、最低平均 CER、最佳锚点命中率，以及较强的 NISQA-TTS 自然度。CosyVoice 300M Instruct 是自然度领先者，但情绪识别较弱，尤其是在日语中。IndexTTS-2 的综合 SenseVoice 分数较高，但日语 CER 过高，因此不能把该结果视为可靠的日语 TTS 证据。

最重要的模式是语言和情绪的不平衡：在该自动评估设置下，中文始终比日语更容易，而 fear 和 disgust 在所有被评估模型中仍未解决。

动机

情感 TTS 不只是自然度问题。模型可以听起来流畅、悦耳，却无法表达指定风格。对于多语言虚拟人、客服语音、训练模拟、富表现力语音翻译等产品场景，我们需要确认 TTS 系统能否同时保持三件事一致：

消除与韩国子公司的语言壁垒：支持Brave group全球VTuber业务扩展的实时翻译 - Brave group × VoicePing

Thu, 23 Apr 2026 00:00:00 +0000

株式会社Brave group以VTuber业务为核心，同时开展受托开发、硬件企划与销售、集换式卡牌游戏等多元业务。该公司在欧洲、英语圈、泰国等世界各地设有据点，并运营多家子公司。2025年7月，Brave group与韩国最大级别的VTuber经纪公司StelLive完成经营整合。由此，公司在日常工作中需要进行韩语实时沟通，并因此引入了VoicePing。

本次我们采访了主导VoicePing导入的集团管理本部信息系统部部长西晃生先生，了解导入背景、具体使用场景以及未来展望。

案例要点

课题： 与StelLive完成经营整合后，Brave group需要应对韩语实时翻译和多语言会议。
解决方案： 使用VoicePing在韩语、日语、英语、泰语等会议中进行实时翻译和会议转录。
效果： 口译负责人的负担降低，员工参加海外会议的心理门槛也下降。
适用场景： 韩语实时翻译、多语言会议、海外子公司沟通、VTuber活动的多语言支持。

对于正在评估韩语实时翻译或多语言会议转录的团队，本案例也可以作为会议和活动实时翻译以及面向全球协作的虚拟办公室的参考。

株式会社Brave group 集团管理本部信息系统部部长西晃生先生

以IP为核心进行全球扩展的娱乐企业

首先，请介绍一下您的职位以及Brave group的业务。

西先生： 我是株式会社Brave group的西。现在担任控股公司集团管理本部信息系统部部长。我们有很多子公司，最知名的业务是拥有VTuber的IP（知识产权）业务。我们运营着"ぶいすぽっ！“和"StelLive"等VTuber经纪公司。此外，还有受托开发业务、利用IP企划和销售键盘等硬件的业务，最近也开展了集换式卡牌游戏业务。业务范围很广，所以如果被问到"这是一家什么样的公司？“很难用一句话概括，但总体来说，我们是一家以IP为核心、以多种形式展开业务的公司。

与韩国企业的经营整合成为契机，实时翻译变得迫切

请介绍一下导入VoicePing的契机。

西先生： 2025年7月，我们与韩国的StelLive（ステライブ）这家VTuber业务公司进行了经营整合。此前，我们已经在欧洲、英语圈、泰国等地设立海外据点，并主要使用英语运营，但韩国的情况有很大不同。实时交流时的主要语言不是英语，而是韩语。

因此，我们开始寻找能够支持韩语的同声传译和转录工具，这就是最初的契机。

市面上还有很多翻译工具。当时的课题是什么？

西先生： 首先，我们使用Google Workspace，所以也尝试过生成式AI的翻译功能。如果已经有文本，再让它读取并翻译，准确度非常好，但实时应对比较困难。

另外，我们试用了几个工具后发现，很多工具会先把日语翻译成英语，再从英语翻译成韩语，也就是所谓的两阶段翻译。界面上看起来像是从日语直接翻译成韩语，但我们团队中也有会说韩语的成员，他们看翻译结果时，经常会觉得"语感好像有点别扭”。

选择VoicePing的决定因素：不同语言使用不同AI模型

Brave group标志

在这些工具中，为什么选择VoicePing？

西先生： 在听VoicePing说明时，我们了解到调整语言时会使用不同的模型。我们认为这样应该不会出现此前感受到的两阶段翻译感，这成为了选择VoicePing的重要理由。

实际请会说韩语的成员确认后，与其他工具相比，翻译的自然度也更好。

从后台部门到跨业务部门，在多语言交织的现场使用

VoicePing双语模式中进行日语和韩语实时翻译的画面。图片提供：株式会社Brave group

具体在哪些场景中使用？

西先生： 母公司Brave group控股公司本身负责后台业务和活动支持，是支持子公司的立场。有些IP来自海外，很多时候会由日本人成员在中间推进沟通。

在这类会议中，不仅是韩语，我们也会在日语和英语组合的场景中使用VoicePing。例如，交易对象中有英语圈人士，日本的我们以及IP公司的工作人员也参加会议。当我们作为现场工作人员的沟通中介时，会议中就会出现多种语言。我们经常在这样的场景中使用。

也在韩语以外的语言中使用，是吗？

西先生： 是的。似乎也有人在泰语场景中使用。虽然反馈还没有全部收集完，但在各种语言场景中的使用正在扩大。

口译成员负担大幅降低：“可以不再畏惧地参加会议”

导入后的效果如何？

西先生： 最大的效果是会说韩语的成员负担降低了。以前需要请他们实时口译，但导入VoicePing后，会先转成文字，再只请他们指出语感不同的地方。可以说工时和负担都明显降低了。

另外，对日本员工来说也有很大变化。只要有账号，即使没有会说韩语的成员在场，也可以有一种前提：使用工具至少能够完成最低限度的沟通。因此，大家可以不再畏惧地参加海外会议。能够把注意力集中在会议的重要要点上推进，我认为这一点非常有效。

VoicePing在SusHi Tech Tokyo 2026 GLOBAL × SCALEUP TOKYO创业展示会上提供实时翻译

Fri, 10 Apr 2026 00:00:00 +0000

VoicePing在SusHi Tech Tokyo 2026 GLOBAL × SCALEUP TOKYO上提供实时翻译

VoicePing在作为SusHi Tech Tokyo 2026 – Gathering Day一部分、于Tokyo Innovation Base举办的**「GLOBAL × SCALEUP TOKYO SU生态系统：Global VC Insights & Startup Showcase」**上提供了实时AI翻译支持。来自世界各地的风险投资机构、企业VC以及东京最具前景的创业公司齐聚一堂，通过无缝多语言沟通实现了跨境对话。

Tokyo Innovation Base的活动议程 — 包括Global Strategy Talk、Tokyo Startup Showcase以及深科技和绿色创业公司路演。

活动概览：全球VC与东京创业生态系统的交汇

GLOBAL × SCALEUP TOKYO活动精心设计了丰富的议程，旨在将日本的创业生态系统与国际投资者和合作伙伴连接起来：

Global Strategy Talk（下午2:30） — 为跨境合作奠定基础的开场环节
小组讨论：“从海外VC/CVC视角看日本创业投资与全球扩张” — Pegasus Tech Ventures、Alumni Ventures和Woven Capital的全球VC分享了对日本创业环境的坦率见解
Tokyo Startup Showcase（下午3:30） — 聚焦创新日本创业公司
路演环节：Deep Ecosystem / Green Startups（下午3:55） — 展示深科技和可持续发展领域的企业
SusHi Tech Tokyo 2026主要发布（下午5:00） — SusHi Tech Tokyo整体重要公告
社交活动（下午5:40~7:00） — 创始人与投资者跨越语言直接交流

本活动由Startup Ecosystem Tokyo Consortium与东京都政府合作，作为SusHi Tech Tokyo 2026计划的一部分举办。

VoicePing在JETRO Startup Alumni Meetup 2026上提供实时翻译 — 连接2,000多家初创企业

Wed, 08 Apr 2026 00:00:00 +0000

VoicePing在JETRO Startup Alumni Meetup 2026上提供实时翻译

VoicePing在日本最大规模的创业生态系统活动**「JETRO Startup Alumni Meetup 2026」**上提供了实时AI翻译技术。2,000多家初创企业、风险投资机构和支持组织齐聚一堂，VoicePing的实时翻译消除了小组讨论、演讲和交流活动中的语言障碍。

活动概要：日本创业生态系统大集结

JETRO Startup Alumni Meetup 2026汇聚了JETRO旗舰加速器项目的校友——包括AlchemistX、500 Global和硅谷扩展计划——以及广泛的风险投资机构、企业合作伙伴和政府组织。

活动举办了以AI、深科技、生物技术、融资和全球扩张为主题的高水平小组讨论，并设有大规模交流环节。来自不同国家和语言背景的参与者齐聚一堂，实时翻译对于确保每位参与者深度参与至关重要。

JETRO Startup Alumni Meetup 2026会场。2,000多家初创企业、风险投资机构和支持组织共同活跃日本创业生态系统。

挑战：大规模活动中的语言障碍

在2,000多名来自日本国内外的参与者齐聚的活动中，多个会议同时进行，需要实时多语言沟通。AI和深科技等前沿主题的小组讨论要求翻译具有准确性和细微差别，能够跟上专家之间快节奏的对话。

传统的口译方式难以覆盖多个舞台和分会场，同时保持创业交流所必需的临场感和即时性。

VoicePing的解决方案：全场实时翻译

作为JETRO加速器项目的骄傲校友，VoicePing承担了本次活动的实时翻译支持。参与者可以在自己的设备上访问实时翻译，无论演讲者使用何种语言，都能通过即时字幕观看小组讨论和演讲。

VoicePing的翻译技术被部署在主舞台的演讲和小组讨论中，确保日本创业者与国际参与者能够双向无缝交流。

以「创新变革：应对挑战与全球扩张之路」为主题的小组讨论。VoicePing提供实时翻译支持。

活动现场运行的VoicePing实时AI翻译，为参与者即时提供多语言字幕。

成果：2,000多人跨越语言障碍交流

2,000多名参与者在日本最大规模的创业活动中跨越语言障碍交流
AI、深科技、生物技术、融资、全球扩张小组讨论可供所有参与者实时理解
日本创业者与国际参与者在交流和问答环节中无缝对话
零停机——VoicePing的翻译在多个会议中持续不间断运行

VoicePing作为JETRO加速器校友的历程

VoicePing是JETRO的AlchemistX、500 Global和硅谷扩展计划的校友。这些项目在VoicePing从日本初创企业成长为全球实时翻译平台的过程中发挥了重要作用。

在Alumni Meetup上提供翻译支持，是利用JETRO生态系统诞生的技术连接下一代走向全球市场的初创企业的一个意义深远的回归原点。

“看到我们的技术消除语言障碍，将日本创业者与全球参与者连接在一起——这正是我们创建VoicePing的原因。没有什么比看到自己的产品在实时中拉近人与人的距离更令人欣慰的了。”

▼活动详情

活动名称：JETRO Startup Alumni Meetup 2026

主办方：JETRO（日本贸易振兴机构）

地点：东京，日本

参与者：2,000多家初创企业、风险投资机构和支持组织

活动详情：https://luma.com/9zq2jvid

用VoicePing将您的活动打造成「无语言障碍的国际盛会」！

VoicePing通过快速、准确的实时翻译消除语言障碍，为来自不同国家和文化的参与者创造无缝交流的环境。

📱 只需扫描二维码！在智能手机上轻松查看翻译内容。无论是演讲、路演还是交流活动，VoicePing都能确保顺畅沟通。

使用VoicePing的优势：

🌍 多国参与者以母语理解内容——所有会议中，参与者都能无语言障碍地深入理解。

⚡ 简单操作与高精度翻译减轻负担——直观的界面和快速翻译大幅减少运营工作量。

💡 提升参与者满意度和活动评价——利用翻译支持提高活动整体质量，获得参与者的积极反馈。

离线语音翻译应用：iOS/Android 跨平台端侧转写、翻译与 TTS

Mon, 16 Feb 2026 00:00:00 +0000

源代码：

ios-android-offline-speech-translation — 集成 ASR、翻译、TTS 和系统音频捕获的 iOS/Android 跨平台离线语音翻译应用（Apache 2.0）

摘要

我们开发了一款开源跨平台移动应用，可在 iOS 和 Android 上实现完全离线的语音翻译。该应用将端侧自动语音识别（SenseVoice Small，通过 sherpa-onnx）、神经机器翻译（Apple Translation / Google ML Kit）和文本语音合成集成为统一管线。两个平台都支持麦克风和系统音频捕获——在平台捕获限制范围内，可以翻译来自其他应用（视频通话、媒体等）的音频，无需云端连接。端侧 ASR 在 iPad Pro（A12X）上达到 23.6 tok/s，在 Samsung Galaxy S10 上达到 33.6 tok/s（RTF < 0.1）。翻译和 TTS 阶段使用平台原生引擎，本次发布未进行单独基准测试。

研究动机

完整的语音翻译管线（ASR、机器翻译、TTS）能否在 2018-2019 年的消费级手机上可靠地离线运行？端侧 AI 研究的基准测试通常单独评估各个模型，但实际应用需要将多个阶段串联起来，在平台沙箱限制下管理系统音频捕获，并处理完整的生命周期（持久化、导出、后台处理）。

本项目验证的是系统可行性：整个管线能否在真实的消费级硬件上不依赖网络连接端到端运行。应用已开源，开发者可以直接评估架构设计。

应用概览

iOS

首页	转写 + 翻译	演示

SenseVoice Small 搭配 Apple Translation（英语 → 日语）和 TTS。

Android

转写 + 翻译	演示

SenseVoice Small 搭配 ML Kit 翻译和 TTS。

语音翻译：英日双向翻译中 Qwen3-ASR 与 Whisper 的对比

Mon, 16 Feb 2026 00:00:00 +0000

模型（Hugging Face）：

voiceping-ai/qwen3-asr-ja-en-speech-translation — 针对 EN↔JA 双向语音翻译微调的 Qwen3-ASR（1.7B 参数，评估中质量最高）
voiceping-ai/whisper-ja-en-speech-translation — 用于 EN↔JA 双向语音翻译的 Distilled Whisper（756M 参数，快 4 倍）

推理代码（GitHub）：

qwen3-asr-ja-en-speech-translation — 推理脚本、评估流水线和模型使用示例
whisper-ja-en-speech-translation — 推理脚本、评估流水线和模型使用示例

训练脚本未包含在这些仓库中。

摘要

本研究提出两个英日双向语音翻译模型：(1) Qwen3-ASR EN-JA（1.7B 参数），基于 Qwen3-ASR-1.7B 使用约 127 万个翻译对进行全参数 SFT 微调，EN→JA 评分 4.2/5，JA→EN 评分 4.0/5；(2) Whisper EN-JA（756M 参数），从 Whisper large-v2 蒸馏而来，采用 4 层解码器，推理速度达 212 tok/s，是 Qwen3-ASR 的 4.6 倍。两个模型均在 FLEURS 测试集上与 OpenAI Whisper large-v3 和 Meta SeamlessM4T v2 Large 进行了对比评估。质量由 LLM 评审（Claude Opus 4.6）评分。各仓库独立进行评估，表格间的分数不可直接比较。

离线 TTS 基准测试：在 Android/iOS 上评测 18 个模型

Sun, 15 Feb 2026 00:00:00 +0000

源代码：

android-offline-tts-eval — 搭载 7 个模型的 Android TTS 基准测试应用（sherpa-onnx 和系统 TTS）
ios-offline-tts-eval — 搭载 11 个模型的 iOS TTS 基准测试应用（含 AVSpeech）

摘要

我们在 Android（7 个模型）和 iOS（11 个模型）上对 18 个端侧 TTS 模型进行了基准测试，覆盖 2 个推理引擎，测量合成速度（tok/s）、实时系数（RTF）和内存使用量。所有测试均使用英文文本提示。结果显示，Android System TTS 和 Piper VITS 合成速度最快（Android 上 33~42 tok/s），而 Kokoro 在两个平台上均未达到实时速度。iOS 上 Apple 内置的 AVSpeechSynthesizer 凭借极低的内存开销获得最高综合评分，但在开源模型中，Matcha + Vocos 在速度和资源效率之间提供了最佳平衡。本基准未进行正式的听感测试（MOS/ABX），仅测量速度和资源使用情况，不评估感知音质。

研究动机

在移动和边缘应用中集成 TTS 的开发者面临三重权衡：合成延迟（能否跟上实时交互？）、内存占用（能否与 ASR 等其他 AI 模型在内存受限的设备上共存？）和音质（输出对于应用场景是否可接受？）。TTS 模型的速度从 440ms 的系统 TTS 到 15 秒的 Kokoro 相差 35 倍，内存则从 21MB 到 833MB 不等。

离线语音转写基准测试：在 Android/iOS/macOS/Windows 上评测 16 个模型

Sun, 15 Feb 2026 00:00:00 +0000

源代码：

android-offline-transcribe — 搭载 16 个 ASR 模型和 6 个推理引擎的 Android 基准测试应用
ios-mac-offline-transcribe — 搭载 17 个 ASR 模型和 9 个推理引擎的 iOS/macOS 基准测试应用
windows-offline-transcribe — 搭载 12 个 ASR 模型的 Windows 基准测试应用（仅 CPU）

摘要

我们在 Android、iOS、macOS 和 Windows 全平台上对 16 个端侧语音识别模型进行了基准测试，覆盖 9 个推理引擎，测量推理速度（tok/s）、实时系数（RTF）和内存占用。本基准仅测量速度，不评估转写准确率（WER/CER）。主要发现：推理引擎的选择可使同一模型的性能差异达 51 倍（Android 上 sherpa-onnx vs whisper.cpp）；Moonshine Tiny 和 SenseVoice Small 在所有平台上实现最快推理；WhisperKit CoreML 在 4GB 的 iOS 设备上运行 Whisper Tiny 以上模型时会崩溃。所有基准测试应用和结果均已开源。

研究动机

开发音频相关的边缘应用时，开发者面临组合选择难题：数十个 ASR 模型（从 31MB 的 Whisper Tiny 到 1.8GB 的 Qwen3 ASR）、多种推理引擎（ONNX Runtime、CoreML、whisper.cpp、MLX）以及 4 个以上目标平台——每种组合产生截然不同的速度和内存特征。已发布的模型基准通常是在服务器 GPU 上测试的结果，而非模型实际部署的消费级手机和笔记本电脑。

Whisper 生产实践：实时双语切换的踩坑经历与最终架构

Wed, 21 Jan 2026 00:00:00 +0000

VoicePing 目前已在生产环境的会议中运行双语转录，支持日语、英语、普通话、粤语、韩语和越南语在句中自由切换。用户的期望很简单：无论语码转换多么频繁，语音识别和翻译都应无缝衔接。本文介绍我们如何设计了双语模式（Bilingual Mode）——基于定制化 Whisper V2 模型，在单条 WebSocket 流中实现自动、低延迟的语言切换。

1. 单语基线
2. 为什么"双语模式"是刚需
- 演示：双语模式实际效果
3. 初始方案：外部语言检测（及其失败原因）
4. 突破：让 Whisper 自己告诉我们语言
- 4.1 Whisper 原生语言检测
- 4.2 基于 Whisper 原生检测的架构
5. 稳定语码转换边界
6. 通用填充解决短音频不稳定问题
7. 运营约束：GPU、MPS 与并发
8. 总结
参考文献

1. 单语基线

我们从传统的实时 ASR 架构出发：

客户端流式传输 16 kHz PCM 音频。
VAD 将音频切分为滑动窗口（可配置重叠，约 X 秒）。
Whisper V2 派生模型以固定的 language=ja 进行解码。
后处理阶段对部分假设去重、文本修正，并通过 WebSocket 流式推送更新。

这一滑动窗口+拼接的流水线借鉴了 “Streaming Whisper: Enhanced Streaming Speech Recognition”（https://arxiv.org/abs/2307.14743）中描述的 Streaming Whisper 方法，为我们在叠加双语能力之前提供了稳定的基线。

图 1：单语基线（单一固定语言）

说话人分离模型实战对比评估

Mon, 15 Dec 2025 00:00:00 +0000

测试配置：6 个场景，5 种语言（EN、JA、KO、VI、ZH），3 个模型硬件：NVIDIA GeForce RTX 4090 日期：2025年12月

摘要

我们在 6 个场景中评估了 3 个说话人分离模型：

模型	说明	平均 DER	平均 RTF
NeMo Neural (MSDD)	带神经网络精炼的多尺度分离解码器	0.081	0.020
NeMo Clustering	不含 MSDD 的纯聚类方法	0.103	0.010
Pyannote 3.1	端到端分离流水线	0.181	0.027

核心发现：

NeMo Neural 兼具最佳准确度和快速处理能力
日语在较长上下文中表现改善：30分钟以上音频性能提升
不含日语的多语言处理表现优异（DER: 0.050）

1. 引言

为了选择生产环境中使用的分离模型，我们设计了 6 个反映实际运行条件的测试场景：

不同音频时长（10分钟至1小时）
不同说话人数（4至14人）
不同重叠程度（0%至40%）
多语言音频混合

2. 测试模型

NeMo Neural (MSDD)

使用 TitaNet-large 生成 192 维说话人嵌入
在 5 个时间尺度（1.0秒~3.0秒窗口）上处理音频
MSDD 神经网络对初始聚类结果进行精炼
平均 RTF：约 0.015~0.032

NeMo Clustering（纯聚类）

使用相同的嵌入模型（TitaNet-large）
仅使用谱聚类，不含 MSDD 精炼
跳过神经网络精炼，速度显著更快
平均 RTF：约 0.014~0.028

Pyannote 3.1

包含 VAD、分割和聚类的端到端流水线
使用 pyannote/segmentation-3.0 和 wespeaker 模型
平均 RTF：约 0.018~0.043

3. 评估设置

3.1 测试场景

场景	时长	说话人数	重叠率	目的
长音频	10分钟	4~5	15%	标准生产场景
超长音频	30分钟	10~12	15%	压力测试
1小时音频	60分钟	12~14	15%	极限时长测试
高重叠	15分钟	8~10	40%	最差重叠场景
多语言（5种）	15分钟	8	20%	EN+JA+KO+VI+ZH
多语言（4种）	15分钟	8	20%	EN+KO+VI+ZH（无日语）

3.2 评估指标

准确度指标：

通过 Go 重写将 WebSocket 代理效率提升 100 倍

Thu, 20 Nov 2025 00:00:00 +0000

概述

我们将 WebSocket 代理服务器从 Python 重写为 Go，将 CPU 使用率降低到 1/10，内存消耗降低到 1/100。

这个项目不仅提升了资源效率，还让我们学到了一个关于并发的重要经验：

锁越小越好，越少越好。

背景

VoicePing 的系统是一个实时 STT（语音识别）和翻译流水线。每个客户端设备将音频流式传输到后端，进行多语言的语音识别和翻译。

WebSocket 代理服务器位于流水线的中间层：

每个客户端与 STT 代理维持一个持久的 WebSocket 会话
代理将音频数据包转发到多个 GPU 推理服务器之一
等待转录文本并以流式方式返回部分转录结果和翻译

该架构必须以亚秒级延迟处理数千个并发实时音频会话。

然而，我们之前基于 Python 的代理成为了瓶颈。

改进前：Python 代理（低效）

第一版代理服务器使用 Python（FastAPI + asyncio + websockets）实现，通过 Gunicorn 的多工作进程部署。

在小规模下运行正常，但在生产流量下很快达到了资源上限：

指标	Before (Python)	After (Go)
CPU 使用率	约 12 核 × 40~50%	约 12 核 × 4~5%
内存使用量	约 25 GB	约 10 MB

Python 遇到瓶颈的原因

尽管是异步模式，Python 的架构仍存在多个系统性瓶颈：

Part 2：扩展翻译推理：吞吐量 +82%

Sat, 15 Nov 2025 00:00:00 +0000

回顾：问题所在

在 Part 1 中，我们找到了瓶颈：FastAPI 服务使用多进程工作器和 IPC 队列来分发翻译任务，导致了以下问题：

队列序列化开销
工作进程间的 GPU 计算资源争用
尖峰状 GPU 使用率

基线：25 个并发请求时 2.2 RPS

改进方向：去掉多进程，利用 vLLM 的批量推理能力。

尝试 2：静态批处理

在现有工作进程中实现了静态批处理。

实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


# 工作进程内
MAX_BATCH_SIZE = 16
BATCH_TIMEOUT = 0.05 # 50ms

while True:
 batch_keys = []
 batch_tasks = []

 # 获取第一个任务（阻塞）
 first_key = queue.get()
 batch_keys.append(first_key)
 batch_tasks.append(tasks[first_key])

 # 尝试收集更多任务（带超时的非阻塞）
 batch_start = time.time()
 while len(batch_keys) < MAX_BATCH_SIZE:
 time_remaining = BATCH_TIMEOUT - (time.time() - batch_start)
 if time_remaining <= 0:
 break
 try:
 key = queue.get(timeout=time_remaining)
 batch_keys.append(key)
 batch_tasks.append(tasks[key])
 except Empty:
 break

 # 使用 vLLM 批量处理
 results = translation_provider.translate_batch(
 texts=[t.text for t in batch_tasks],
 source_langs=[t.source_lang for t in batch_tasks],
 target_langs=[t.target_lang for t in batch_tasks]
 )

要点：

Part 1：翻译推理服务器扩展的瓶颈

Mon, 10 Nov 2025 00:00:00 +0000

问题

我们使用 FastAPI 和 vLLM 运行翻译微服务。在高负载下，服务器出现了延迟问题，但 GPU 使用率指标无法解释这一现象。

GPU 使用率呈现出不稳定的模式：急升至 93%，跌至 0%，再次急升。完全不是我们预期的持续高使用率。

核心问题：如果 GPU 存在空闲期，瓶颈究竟在哪里？

本文介绍了我们如何在 FastAPI + 多进程架构中找到阻碍高效 GPU 利用的架构问题。

系统架构

翻译服务以多台 API 服务器的形式在负载均衡器后运行。

客户端：Web、移动端、后端服务
代理：根据语言对和服务器健康状态路由请求
API 服务器：多个 FastAPI 实例，每个运行 vLLM

本文重点关注单台 API 服务器的内部架构和瓶颈。

API 服务器架构

以下是一台 API 服务器的内部结构。

组件

1. FastAPI 主进程

1
2
3
4
5


# 单线程异步事件循环
@app.post("/translate")
async def translate_endpoint(request: TranslateRequest):
 result = await translation_service.translate(request)
 return result

使用 async/await 处理 HTTP 请求
单个 Python 进程，一个事件循环
非阻塞 I/O 实现并发请求处理

2. TranslationService

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


class TranslationService:
 def __init__(self, worker: TranslationWorker):
 self.worker = worker

 async def translate(self, request: TranslateRequest) -> TranslateResponse:
 # 创建翻译任务
 event_task = self.worker.add_translation_task(
 text=request.text,
 source_lang=request.source_lang,
 target_lang=request.target_lang,
 timeout=30
 )

 # 异步等待结果
 await event_task.event.wait()
 return TranslateResponse(translation=event_task.result.translation)

创建翻译任务
管理带有 asyncio.Event 的 EventTask 对象
在 async/await 和多进程之间架起桥梁

3. TranslationWorker（主进程）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


class TranslationWorker:
 def __init__(self):
 self.ctx = multiprocessing.get_context("spawn")
 self.translation_queue = None # 在 run() 中创建
 self.event_queue = None
 self.event_tasks: Dict[str, EventTask] = {}

 def _initialize(self):
 # 在主进程中创建队列
 self.translation_queue = self.ctx.JoinableQueue(maxsize=300)
 manager = self.ctx.Manager()
 self.translation_tasks = manager.dict() # 共享状态
 self.event_queue = self.ctx.Queue()

 def add_translation_task(...) -> EventTask:
 key = "t_" + generate_random_key(10)
 # 存储到共享字典
 self.translation_tasks[key] = TranslationTask(...)

 # 通过队列发送给工作进程
 self.translation_queue.put(key) # 序列化

 # 创建异步等待事件
 event_task = EventTask(key)
 self.event_tasks[key] = event_task
 return event_task

在主进程中创建队列（与工作进程共享）
用于任务分发的 JoinableQueue
用于共享任务状态的 manager().dict()
用于结果返回的 Event queue

4. 工作进程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


def run(self):
 for worker_id in range(self.num_workers):
 worker = self.ctx.Process(
 target=self.process_queue,
 args=(worker_id, ready_event)
 )
 worker.start()

def process_queue(self, worker_id, ready_event):
 # 每个工作进程加载自己的 vLLM 实例
 translation_processor = TranslationProcessor(
 worker_id=worker_id,
 model_key=self.model_key,
 gpu_memory_utilization=self.gpu_memory_per_worker
 )

 # 从共享队列处理任务
 while True:
 key = self.translation_queue.get() # 反序列化
 task = self.translation_tasks[key]

 # 使用 vLLM 翻译
 result = translation_processor.translate(
 task.text,
 task.source_lang,
 task.target_lang
 )

 # 返回结果
 self.event_queue.put((key, EventType.completed, result)) # 序列化

作为独立进程启动（ctx.Process）
每个工作进程加载自己的 vLLM 模型实例
从共享 translation_queue 中拉取任务
通过共享 event_queue 返回结果

5. EventTask（异步同步机制）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


class EventTask:
 def __init__(self, key: str):
 self.key = key
 self.event = asyncio.Event() # 异步同步
 self.event_type = EventType.waiting
 self.result = None

 def update(self, event_type, result):
 self.event_type = event_type
 self.result = result
 self.event.set() # 唤醒等待中的协程

在多进程和 async/await 之间架起桥梁
为每个请求分配 EventTask
await event.wait() 阻塞协程直到工作进程完成

请求流程

以下是单个翻译请求的完整处理流程。

构建面向大规模数据采集的可扩展异步 Web 爬虫

Sun, 15 Sep 2024 00:00:00 +0000

摘要

本项目开发了一个可扩展的异步 Web 爬虫，用于高效的大规模数据采集。系统基于 Python 的 asyncio、aiohttp 和 BeautifulSoup 构建，能够在遵守 robots.txt、处理 JavaScript 渲染内容以及控制请求频率的同时完成网站爬取。该爬虫成功处理了超过 110 万个内部 URL 和 1900 万个外部引用链接。

核心特性：

异步并发请求处理
robots.txt 合规与速率限制
通过 Playwright 支持 JavaScript 渲染
重复 URL 检测与过滤
错误处理与重试机制
基于 SQLite 的数据持久化

1. 引言

Web 爬虫是现代数据采集的基础技术，为搜索引擎、数据分析和机器学习流水线提供数据支撑。本项目实现了一个可在生产环境使用的 Web 爬虫，在速度与合规爬取之间取得了良好的平衡。

为什么选择异步爬取？

传统的同步爬虫每次只能处理一个 URL，导致 CPU 和网络利用率低下。基于 Python asyncio 的异步爬取具有以下优势：

并发性：同时处理多个 URL
资源效率：非阻塞 I/O 操作
可扩展性：支持数千个并发连接
速度：显著缩短爬取时间

项目目标

构建遵守网站策略（robots.txt）的爬虫
处理静态内容和 JavaScript 渲染内容
实现健壮的错误处理和重试逻辑
高效存储和去重爬取数据
在保持礼貌访问的同时实现高吞吐量

2. 方法论

2.1 系统架构

爬虫由五个主要组件构成：

组件	技术	用途
HTTP 客户端	aiohttp	异步 HTTP 请求处理
HTML 解析器	BeautifulSoup4	提取链接和内容
JS 渲染器	Playwright	处理动态内容
数据库	SQLite	存储已爬取的 URL 和元数据
队列管理器	asyncio.Queue	管理爬取队列

2.2 核心实现

异步请求处理器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


import aiohttp
import asyncio
from bs4 import BeautifulSoup
from urllib.parse import urljoin, urlparse

class AsyncCrawler:
 def __init__(self, max_concurrent=100, delay=1.0):
 self.max_concurrent = max_concurrent
 self.delay = delay
 self.session = None
 self.visited = set()
 self.queue = asyncio.Queue()

 async def fetch(self, url):
 """Fetch a single URL asynchronously"""
 try:
 async with self.session.get(url, timeout=10) as response:
 if response.status == 200:
 return await response.text()
 else:
 print(f"Error {response.status}: {url}")
 return None
 except asyncio.TimeoutError:
 print(f"Timeout: {url}")
 return None
 except Exception as e:
 print(f"Error fetching {url}: {e}")
 return None

 async def parse(self, html, base_url):
 """Extract all links from HTML"""
 soup = BeautifulSoup(html, 'html.parser')
 links = []

 for link in soup.find_all('a', href=True):
 href = link['href']
 absolute_url = urljoin(base_url, href)
 links.append(absolute_url)

 return links

robots.txt 合规

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


from urllib.robotparser import RobotFileParser

class RobotsChecker:
 def __init__(self):
 self.parsers = {}

 async def can_fetch(self, url, user_agent='*'):
 """Check if URL can be crawled per robots.txt"""
 parsed = urlparse(url)
 robots_url = f"{parsed.scheme}://{parsed.netloc}/robots.txt"

 if robots_url not in self.parsers:
 parser = RobotFileParser()
 parser.set_url(robots_url)
 try:
 parser.read()
 self.parsers[robots_url] = parser
 except:
 # If robots.txt doesn't exist, allow crawling
 return True

 return self.parsers[robots_url].can_fetch(user_agent, url)

速率限制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


import time

class RateLimiter:
 def __init__(self, requests_per_second=10):
 self.delay = 1.0 / requests_per_second
 self.last_request = {}

 async def wait(self, domain):
 """Enforce rate limit per domain"""
 now = time.time()

 if domain in self.last_request:
 elapsed = now - self.last_request[domain]
 if elapsed < self.delay:
 await asyncio.sleep(self.delay - elapsed)

 self.last_request[domain] = time.time()

2.3 JavaScript 渲染

对于大量使用 JavaScript 的网站，我们采用 Playwright 进行渲染：

面向人脸与情绪识别的视频和音频数据预处理与分析

Sun, 15 Sep 2024 00:00:00 +0000

摘要

本项目构建了一个自动化流水线，用于预处理视频和音频数据，为视频生成模型的训练提取关键信息。该流水线涵盖人脸检测、情绪分类、姿态估计和音频处理。

核心功能：

自动检测和分离唯一人脸
头部姿态估计（yaw、pitch、roll）
基于深度学习的情绪分类
音频分类与语音分离
片段生成（3~10 秒）

1. 引言

随着基于视频的生成模型快速发展，经过良好预处理的视频数据集需求日益增长。本项目自动化了以下视频和音频数据的预处理工作：

自动分类和识别唯一人脸
沿时间轴检测面部情绪和头部姿态
对背景音乐进行音频分类并分离语音
裁剪和精炼视频，以供生成模型使用

2. 方法

流水线概述

预处理流水线由五个主要阶段组成：

阶段	功能
音频分类	识别语音并从背景噪声中分离
人脸检测	检测和识别视频中的唯一人脸
人脸裁剪	生成以人脸为中心的片段（3~10 秒）
姿态估计	估计头部方向（yaw、pitch、roll）
情绪分类	在每一帧中检测情绪

2.1 视频处理

使用 yt-dlp 下载视频，逐帧处理：

1
2
3
4
5
6
7


def download_video(url, output_dir):
 ydl_opts = {
 'format': 'best',
 'outtmpl': os.path.join(output_dir, '%(title)s-%(id)s.%(ext)s'),
 }
 with yt_dlp.YoutubeDL(ydl_opts) as ydl:
 ydl.download([url])

2.2 音频分类

使用 Audio Spectrogram Transformer 模型对音频进行分类：

大语言模型机器翻译与幻觉问题的缓解

Thu, 15 Aug 2024 00:00:00 +0000

摘要

大语言模型（LLM）在自然语言处理任务中展现出卓越的性能。本研究探索了对 Llama 3.1 进行中译英机器翻译的微调，并通过训练和解码策略来应对幻觉问题。

主要成果：

微调模型在文档级数据上达到 BLEU 40.8（基线 19.6）
COMET 0.891（基线 0.820）
成功缓解长上下文翻译中的幻觉现象
在提升文档级性能的同时保持了句子级质量

1. 背景

大语言模型

以 Llama 为代表的 LLM 正在革新自然语言处理领域，在理解和生成类人文本方面展现出非凡的能力。由于能够针对特定任务进行微调，LLM 非常适合用于提升机器翻译水平。

参数高效微调（LoRA）

LoRA（Low-Rank Adaptation）能够在不更新全部模型参数的情况下实现微调：

冻结预训练模型参数
插入可训练的低秩矩阵
大幅降低训练成本和时间

神经机器翻译与幻觉

NMT 中的幻觉是指不忠实、虚构或无意义的输出内容：

类型	说明
内在幻觉	输出包含与原文不符的错误信息
外在幻觉	模型生成与原文无关的额外内容
扰动幻觉	输入轻微变化导致输出截然不同
自然幻觉	源于训练数据集中的噪声

解码策略

方法	说明
贪心搜索	每步选择概率最高的 token
束搜索	同时考虑概率最高的 N 个序列
温度采样	调整概率分布的锐度
Top-p 采样	从累积概率超过阈值的 token 中采样
Top-k 采样	从概率最高的 k 个 token 中采样

2. 实验

数据集

数据集	文档数	句子数	词数（源/目标）
NewsCommentary-v18.1	11,147	443,677	1,640万/970万
Ted Talks	22	1,949	5.1万/3.2万

评估指标

BLEU：Bilingual Evaluation Understudy — 将译文 n-gram 与参考译文进行比较
COMET：与人工评判相关性最高的神经网络评估框架

实验环境

模型：Llama 3.1 8B Instruct
GPU：NVIDIA A100（80GB）
框架：Unsloth 加速训练

微调配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


model = FastLanguageModel.from_pretrained(
 model_name="unsloth/Meta-Llama-3.1-8B-Instruct",
 max_seq_length=max_seq_length,
 dtype=dtype,
 load_in_4bit=load_in_4bit
)

model = FastLanguageModel.get_peft_model(
 model,
 r=16, # LoRA rank
 target_modules=["q_proj", "k_proj", "v_proj",
 "o_proj", "gate_proj", "up_proj", "down_proj"],
 lora_alpha=16,
 use_gradient_checkpointing="unsloth"
)

3. 结果

分布内性能（文档级）

训练样本数	BLEU	COMET
10	35.8	0.885
100	36.9	0.889
1,000	39.7	0.890
10,000	40.8	0.891
基线	19.6	0.820

要点： 微调使文档级翻译的 BLEU 相比基线提升了 100% 以上。

使用 Bert-VITS2 构建中文（普通话）语音合成系统

Thu, 15 Aug 2024 00:00:00 +0000

摘要

本研究介绍了使用 Bert-VITS2 框架开发快速且自然的普通话语音合成（TTS）系统的工作。该系统专为会议场景设计，旨在生成清晰、富有表现力且符合语境的语音。

核心成果：

在对比模型中取得最低 WER 0.27
语音自然度 MOS 2.90
成功合成最长 22 秒的语音
基于 AISHELL-3 数据集训练（85小时，218名说话人）

1. 引言

什么是语音合成

语音合成（TTS）技术将书面文字转换为自然流畅的语音。现代 TTS 系统借助深度学习生成越来越自然、富有表现力的语音，应用领域包括：

智能助手
无障碍阅读方案
导航系统
自动化客户服务

为什么选择中文

普通话是全球使用人数最多的语言，拥有超过十亿使用者。然而，由于其声调特性和复杂的语言结构，普通话为 TTS 带来了独特的挑战。

什么是 Bert-VITS2

Bert-VITS2 将预训练语言模型与先进的语音合成技术相结合：

BERT 集成：深度理解语义和上下文细微差异
GAN 风格训练：通过对抗学习生成高度逼真的语音
基于 VITS2：最先进的语音合成架构

2. 方法

2.1 数据集选择

本研究选用了 AISHELL-3 数据集：

85 小时音频数据
218 名说话人
每位说话人平均约 30 分钟
高质量转录文本

注意： 最初使用 Alimeeting（118.75 小时）进行实验，但由于转录质量不佳和每位说话人音频时长不足，生成了空白音频。

2.2 模型架构

Bert-VITS2 框架由四个主要组件构成：

组件	功能
TextEncoder	使用预训练 BERT 处理输入文本以理解语义
DurationPredictor	带有随机变化的音素时长估计
Flow	使用归一化流对音高和能量建模
Decoder	合成最终语音波形

2.3 训练过程

损失函数

重建损失：使生成语音匹配真实语音
时长损失：最小化音素时长预测误差
对抗损失：促进生成逼真语音
特征匹配损失：对齐中间层特征

模式崩溃缓解

用于稳定判别器的 Gradient Penalty
生成器和判别器的 Spectral Normalization
逐步增加复杂度的渐进式训练

超参数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "train": {
 "batch_size": 20,
 "learning_rate": 0.00001,
 "epochs": 100,
 "bf16_run": true
 },
 "data": {
 "sampling_rate": 44100,
 "n_speakers": 174
 }
}

提示： 训练在单张 RTX 4090 GPU 上使用 bfloat16 精度进行。

使用 RAFT（检索增强微调）提升英中翻译性能

Thu, 15 Aug 2024 00:00:00 +0000

摘要

本研究探索使用 RAFT（Retrieval-Augmented Fine-Tuning：检索增强微调）来提升 Llama 3.1-8B 的英中双向翻译能力。RAFT 将检索机制与微调相结合，在训练过程中提供上下文示例。

主要发现：

基准微调在整体上取得了最佳结果
RAFT 在特定指标上显示出小幅改进
随机 RAFT 在某些情况下优于基于相似度的 RAFT
翻译质量高度依赖训练数据的相关性

1. 引言

背景

大语言模型擅长语言任务，但可以通过领域特定的优化进一步提升性能。本研究探索 RAFT——一种在训练时用检索到的示例进行增强的技术——能否提高翻译质量。

研究问题

RAFT 能否相比标准微调改进翻译效果？
基于相似度的检索是否优于随机检索？
不同的 RAFT 配置如何影响双向翻译？

2. 方法

RAFT 概述

RAFT（Retrieval-Augmented Fine-Tuning）通过以下方式增强训练过程：

检索：为每个训练样本从语料库中检索相关示例
增强：用检索到的示例丰富训练上下文
微调：在这一丰富的上下文中对模型进行微调

实验设置

组件	配置
基础模型	Llama 3.1-8B Instruct
微调方法	LoRA (r=16, alpha=16)
数据集	News Commentary v18.1 (zh-en)
GPU	NVIDIA A100 80GB

数据集准备

News Commentary 数据集包含英中平行句对：

训练集：10,000 个句对
评估集：TED Talks 语料
经过预处理以确保质量和长度的一致性

RAFT 配置

配置	说明
基准	不使用检索的标准微调
相似度 RAFT	使用嵌入向量检索 top-k 相似示例
随机 RAFT	从语料库中随机采样 k 个示例

3. 结果

英语 → 中文翻译

方法	BLEU	COMET
基线（未微调）	15.2	0.785
基准微调	28.4	0.856
相似度 RAFT (k=3)	27.1	0.849
随机 RAFT (k=3)	27.8	0.852

中文 → 英语翻译

方法	BLEU	COMET
基线（未微调）	18.7	0.812
基准微调	31.2	0.871
相似度 RAFT (k=3)	30.5	0.865
随机 RAFT (k=3)	30.9	0.868

注意： 在本实验中，基准微调始终优于 RAFT 配置。这可能是由于 News Commentary 数据集的同质性特点所致。

说话人分离性能评估：Pyannote.audio vs Nvidia NeMo 及 GPT-4 后处理

Mon, 15 Apr 2024 00:00:00 +0000

摘要

本文评估并比较了两个先进的开源说话人分离框架：Pyannote.audio 和 Nvidia NeMo。评估重点关注不同音频场景下的 Diarization Error Rate（DER）、执行时间和 GPU 资源使用情况。此外，还探索了使用 OpenAI GPT-4-Turbo 进行后处理以提高分离准确率的方法。

主要结果：

Nvidia NeMo 在 2 人说话人场景中 DER 低约 9%
Pyannote.audio 在多说话人（9人以上）场景中表现更优
GPT-4-Turbo 后处理展现出潜力，但需要集成音频上下文
展示了实时说话人分离 Web 应用

1. 引言

什么是说话人分离？

说话人分离是根据不同的说话人对音频进行分段和标注的过程，回答"谁在什么时候说了什么"这一问题。它与自动语音识别（ASR）结合使用，是对话分析的关键工具。

说话人分离系统由以下部分组成：

语音活动检测（VAD） - 识别语音出现的时间戳
音频嵌入模型 - 从带时间戳的片段中提取嵌入向量
聚类 - 对嵌入向量进行分组以估计说话人数量

Pyannote.audio

Pyannote.audio 是基于 PyTorch 的开源 Python 工具包，用于说话人分离和说话人嵌入。

Nvidia NeMo

Nvidia NeMo 采用了不同的方法，使用多尺度分割和 Neural Diarizer（MSDD 模型）来处理说话人重叠语音。

多尺度分割

NeMo 解决了说话人识别质量与时间粒度之间的权衡问题：

较长片段 → 说话人表征质量更高，但时间分辨率较低
较短片段 → 说话人表征质量较低，但时间分辨率较高

基于自注意力模型的音节级发音重音检测

Wed, 15 Nov 2023 00:00:00 +0000

注：已在 arXiv 发表：arXiv:2311.00301

摘要

有效口语交流的前提之一是单词发音清晰，这对非母语者尤为重要。单词重音是清晰准确英语的关键，音节重音的错误放置可能导致误解。因此，了解重音级别对英语使用者和学习者至关重要。

本文提出了一种自注意力模型，用于识别英语口语中每个音节的重音级别。

主要成果：

最简单的模型在一个数据集上达到 88% 以上的准确率
在另一个数据集上达到 93% 以上的准确率
更高级的模型实现了更高的准确率

1. 引言

有效的口语交流需要清晰的发音，对于英语非母语者来说更是如此。单词重音的位置对于语言的可理解性至关重要——音节重音放错位置可能导致误解或沟通障碍。

本研究致力于解决音节级别重音的自动检测问题，在以下领域具有应用前景：

在线会议 — 实时发音反馈
英语学习 — 帮助学习者改善重音模式
语音分析 — 英语口语的自动评估

2. 方法

特征分析

模型分析了多种韵律特征和类别特征：

特征类型	说明
音高水平	音节的基频
强度	音节的响度/振幅
时长	音节的时间长度
音节类型	音节结构的分类
音核特征	各音节中元音（音核）的属性

自注意力架构

自注意力机制使模型能够：

考虑单词内音节之间的关系
对不同韵律特征的重要性进行加权
捕捉重音分配中的上下文模式

输入：每个音节的韵律特征
 ↓
自注意力层
 ↓
输出：每个音节的重音级别预测

3. 结果

性能概要

模型版本	数据集 1	数据集 2
最简单模型	88% 以上	93% 以上
高级模型	更高	更高

要点： 实验证明自注意力架构在重音检测方面效果显著，能够捕捉决定重音模式的音节间上下文关系。

提升机器翻译中的 In-Context Learning 性能

Sun, 15 Oct 2023 00:00:00 +0000

1. 引言

大语言模型（LLM）通过以输入-标签对作为条件，在下游任务中展现出了出色的能力。这种推理方式被称为 In-Context Learning（Brown et al. 2020）。GPT-4 无需微调，仅通过提供特定任务示例即可提升翻译能力。

In-Context Learning 的有效性源于隐式贝叶斯推断（Xie et al. 2022）。随机选择示例无法有效帮助 GPT-4 理解提示的概念。本研究的主要目标是基于用户输入，策略性地选择合适的示例。

2. 方法

本方法假设可以访问包含翻译对的数据集 Ds。文本检索器（Gao 2023）从中定位并选取与用户提示语义最相似的前 K 个句子。

检索器由两个组件构成：

TF-IDF 矩阵 — 衡量词频和逆文档频率
余弦相似度 — 计算 TF-IDF 向量之间的相似度

TF-IDF 分数

TF-IDF 分数衡量词语在文档中的重要程度：

TF（词频）：词语在文档中出现的频率
IDF（逆文档频率）：词语在整个语料库中的重要性

余弦相似度

余弦相似度通过考量两个向量表示之间的夹角来评估相似性。分数越高，表示用户提示与数据集文档之间的相似度越大。

3. 实验设置

3.1 实验流程

实验涵盖三种场景：

无 ICL：不使用 In-Context Learning 示例的 GPT-4 翻译
随机 ICL：随机选择翻译示例
本文方法：TF-IDF 检索器根据相似度分数选取前 4 个示例

评估指标

BLEU 分数：将翻译片段与参考译文进行对比（Papineni et al. 2002）
COMET 分数：与人工判断达到最先进相关性的多语言机器翻译评估神经框架（Rei et al. 2020）

3.2 数据集

选择 OPUS-100（Zhang et al. 2020）的原因：

机器翻译精度评估与改进方法

Tue, 15 Aug 2023 00:00:00 +0000

摘要

我们致力于解决机器翻译质量的准确评估问题，同时努力将翻译精度提升至人工翻译水平。本研究采用5个不同的基准翻译模型，通过3种评估指标对其性能进行衡量，并结合先前研究的成果不断优化模型精度。

引言
数据集
机器翻译精度评估方法
- 3.1. BLEU 分数
- 3.2. BLEURT 分数
- 3.3. COMET 分数
五个基准机器翻译模型及其精度
- 4.1. Azure 基线模型
- 4.2. Azure 自定义模型
- 4.3. DeepL 模型
- 4.4. Google 翻译
- 4.5. GPT-4 模型
- 4.6. 对比与结论
提升机器翻译精度
- 5.1. GPT-4 的上下文学习
- 5.2. 混合模型
- 5.3. GPT-4 作为数据清洗工具
结论
参考文献

1. 引言

随着 AI 技术的进步，特别是 OpenAI 推出 ChatGPT 之后，人们对 AI 行业的信任度不断提升。作为自然语言处理领域的核心技术，机器翻译正变得愈发重要。

本文重点评估了5个基础翻译模型的性能，采用多种评估指标进行对比，同时深入探讨了尽可能提升模型精度的方法。

2. 数据集

本研究使用 Hugging Face 上的 Opus100（ZH-EN）数据集。该数据集包含100万条跨领域的中英翻译实例，是训练翻译模型的理想选择。

注意： 必须指出，数据集中存在翻译错误。虽然这些错误看似会降低训练精度，但同时也有助于防止过拟合问题。

此外，在将数据集整合到 Azure AI 平台之前，需要进行预处理以去除每个句子中的异常符号。

日语与越南语 ASR 模型微调

Tue, 15 Aug 2023 00:00:00 +0000

摘要

在通信技术快速发展的背景下，以 OpenAI Whisper 模型为代表的最新突破显著提升了多语言语音转文字的准确性和可及性。然而，在识别精度方面仍有提升空间。本研究专注于越南语和日语的自动语音识别（ASR）模型性能优化。

我们采用标准指标进行评估：越南语使用词错误率（WER），日语使用字符错误率（CER）。

核心结果：

越南语（FOSD + Common Voice + Google Fleurs + Vivos）：WER 9.46%
日语（ReazonSpeech + Common Voice + Google Fleurs）：CER 8.15%

1. 背景介绍

在当今社会，通信与技术已不可或缺，但在可及性、包容性和高效知识传播方面仍面临诸多挑战。自动语音识别（ASR）技术的进步正在简化人机交互，尤其体现在在线会议场景中。

ASR 是将语音信号转换为对应文本的过程。近年来，随着大规模语音数据集及其转录文本的可用性提高，各大企业纷纷关注这一领域。

OpenAI Whisper 是一个基于 Transformer 的编码器-解码器模型，采用 sequence-to-sequence 架构设计。它以音频频谱图特征作为输入，将其转换为文本 token 序列。具体过程如下：

特征提取器将原始音频转换为 log-Mel 频谱图
Transformer 编码器生成编码器隐藏状态序列
解码器通过 cross-attention 机制预测文本 token

2. 环境搭建

Whisper 微调有两种方式：使用 Google Colab，或在本地 PC 上运行代码。

自动语音识别大语言模型的训练、评估与部署

Tue, 15 Aug 2023 00:00:00 +0000

作者：Linchuan Du 单位：The University of British Columbia 数学系日期：2023年8月

摘要

自动语音识别（ASR），也称为语音转文字（STT），利用深度学习技术将含有语音的音频转录为文字。大语言模型（LLM）模拟人脑处理词语和短语的方式，具备理解和生成文本数据的能力。LLM 通常包含数百万个权重，并使用各类数据集进行预训练。ASR LLM 通过特征提取和分词（tokenization）将音频输入转换为所需的输入格式。

为了定制具有理想性能的 ASR LLM，我们首先在 Google Colaboratory 上测试了 OpenAI 开发的 Whisper 微调流程。随后将较大模型部署到配备 GPU 的 Windows 环境中，以加速训练并缓解 Colab 和 macOS 上的 GPU 限制问题。我们基于音频质量和转录准确性等信息对音频数据的可靠性进行了评估，并通过数据预处理和超参数调优技术改进和优化了模型。当常规微调无法解决 GPU 内存问题时，采用了基于 LoRA 的参数高效微调（PEFT），冻结大部分参数以节省内存，同时尽量减少性能损失。

我们还探索了利用 Neural Speaker Diarization 为 Whisper 添加多说话人支持的可能性。通过 Pipeline 和 WhisperX 实现了与 Pyannote 的集成。WhisperX 提供了词级时间戳和语音活动检测（VAD）等额外功能。

除 Whisper 外，我们还安装并比较了具有 ASR 功能的其他模型，包括 Meta AI 的 MMS、PaddleSpeech、SpeechBrain 和 ESPNet。使用中文数据集进行了 CER 指标的比较评估。此外，还引入了 Azure AI 的 Custom Speech 进行实时 STT 性能对比（主要针对普通话）。

通过 Voice Activity Detection 降低语音识别使用量和成本

Fri, 10 Feb 2023 00:00:00 +0000

本文详细介绍了 VoicePing 中 Speech to Text 的实现细节，以及开发团队如何最大限度地提高云服务的使用效率。

VoicePing 功能丰富，是远程团队的理想解决方案！我们目前提供为期一年的免费高级订阅，前往 https://voiceping.net/ 即可开始使用！

摘要

从零开始实现 Speech-to-Text 并获得良好的识别精度非常困难。因此，许多企业和开发者选择使用已有的 SaaS 方案，这些方案具有出色的识别效果，并支持多种语言。

根据使用量的不同，这可以是一个低成本的解决方案，因为收费方式是"按量付费"。但这也意味着使用量过多时成本会很高。最终取决于使用方式和使用量。

在这篇文章中，我们将介绍 VoicePing 用来降低会议中用户音频 STT 处理高成本的策略。这一策略之所以可行，是因为在会议中大多数用户只是在听，会议大部分时间并不发言。该策略基于使用 Voice Activity Detection（VAD）库来避免将无声音频流传输到 STT 服务。

我们还将展示在实现这一策略过程中遇到的所有问题及其解决方法。

引言

Speech-to-Text（STT），也称为自动语音识别（ASR），是一项有着广泛应用场景的功能。例如 YouTube 上的自动字幕生成、Siri、Alexa 和 Cortana 等个人虚拟助手，以及许多其他类型的语音应用。

在 VoicePing 中，我们用它来在会议中展示实时转写，使得在转写基础上显示实时翻译成为可能。还可以设置自动将这些转写同步到 Slack 工作区的公共或私有频道，安全保存公司所有工作相关讨论的通信记录。

同步到 Slack 的转写可以利用 Slack 提供的各种功能，例如将会议中分配给你的任务相关消息加书签，将特定讨论事项固定在频道中确保团队不会忘记，或者在会议提前结束、时间不够的情况下在 Slack 线程中继续讨论。

实现

实现一个能够将音频转换为文本的 AI 系统并不容易，需要大量带有转写文本的音频文件来训练和验证 AI 模型，支持的语言越多，工作量就越大。

幸运的是，现有许多可用的服务，而且这些服务的质量每天都在提高，在某些情况下其准确度可以与专业的人工转写人员相媲美。但根据应用的用户数量和收入情况，这些费用可能过高且不可持续。我可以建议两种解决成本问题的方案：

第一种方案是最便宜的选择，使用免费服务。大多数服务都有免费层级，对并发使用量和使用时长有限制。如果免费层级不够用，我不知道有任何不收费的 SaaS 方案，但有一个实验性的 Web Speech API。一些浏览器已经实现了它，如 Google Chrome 和 Microsoft Edge。

这些都很好，但仍有局限性。作为实验性 API，并非所有浏览器都支持，要求用户使用其他浏览器可能会影响应用声誉。另一个限制是 API 本身，目前无法选择使用哪个输入设备，调用 .start() 后总是从默认输入设备开始录音。