Faster-Whisper：更快更好的开源Asr模型

Ne0inhk

— 7 min read
Faster-Whisper：更快更好的开源Asr模型

大家好，我是烤鸭：

   半年前写过的whisper，https://blog.ZEEKLOG.net/Angry_Mills/article/details/145556431。其实一度中间换到了whisperX，虽然没有whisper好用(不支持标点符号)，不过效率是真香。最近又遇到类似的需求，就去魔塔上搜了一下，发现了这款 faster-whisper（不过魔塔上没有代码说明 ）。如果你也有asr要求，又不想花钱，机器配置又一般，强烈推荐。

Faster-Whisper模型介绍

魔塔地址：https://www.modelscope.cn/models/XXXXRT/faster-whisper

github：https://github.com/SYSTRAN/faster-whisper

可以看到large模型，在内存差不多的情况下，faster-whisper耗时比whisper快了50%+

在这里插入图片描述

测试环境

  • Python 3.11 or greater
  • CUDA 12.8
  • windows 4070S 12G
  • linux 4090 24G

调用demo

代码没什么好说的，就是官方代码改了下。

from faster_whisper import WhisperModel model_dir = "/data/xxxxx/modelscope/hub/models/XXXXRT/faster-whisper/faster-whisper-large-v3" # Run on GPU with FP16 model = WhisperModel(model_dir, device="cuda", compute_type="float16") # or run on GPU with INT8 # model = WhisperModel(model_dir, device="cuda", compute_type="int8_float16") # or run on CPU with INT8 # model = WhisperModel(model_dir, device="cpu", compute_type="int8") # 2. 配置VAD参数（异常检测核心） vad_options = { "threshold": 0.9, "min_speech_duration_ms": 100, "max_speech_duration_s": 5 } def transcribe(audio_path: str): # 下载远程音频到本地 segments, info = model.transcribe(audio_path,beam_size=5, length_penalty=0.5, # 鼓励更短文本 suppress_tokens=[], # 不抑制任何标点（保留默认标点） word_timestamps=True, no_speech_threshold=0.8, # 更严格的无语音判断 compression_ratio_threshold=2.6, # 更高的压缩率阈值 log_prob_threshold=-0.8, # 更高的日志概率要求 vad_filter=True, # 启用VAD过滤 vad_parameters=vad_options # 应用自定义参数 ) print("Detected language '%s' with probability %f" % (info.language, info.language_probability)) # 关键：将迭代器转换为列表，避免后续遍历耗尽 # 转换为只包含start、end、text字段的字典列表 segments_list = [ { "id": segment.id, "start": segment.start, "end": segment.end, "text": segment.text } for segment in segments ] # 打印处理后的片段信息 for seg in segments_list: print(f"[{seg['start']:.2f}s -> {seg['end']:.2f}s] {seg['text']}") return segments_list # 返回仅包含目标字段的列表 if __name__ == '__main__': transcribe("D:\\dev\\workspace\\python\\chatterbox\\simple_sep_results\\vocals.wav")

文字内容基本和原始音频一致，除了个别的背景干扰音识别失败之外。

不管是linux还是windows环境，使用float16量化，1分钟的音频基本在2~3秒可以返回结果。

结果截图：

在这里插入图片描述

如果不设置vad的话，上面的时间都是连贯的，上一句的end和下一句的start是没有间隔的。

由于我们要求的精度高一些，就调整了vad设置。

vad设置可以参考这篇文章：

https://blog.ZEEKLOG.net/gitblog_00911/article/details/151477552

https://github.com/CheshireCC/faster-whisper-GUI/blob/main/%E5%8F%82%E6%95%B0%E8%AF%B4%E6%98%8E%EF%BC%9A.md

为什么快

faster-whisper is a reimplementation of OpenAI’s Whisper model using CTranslate2, which is a fast inference engine for Transformer models.

This implementation is up to 4 times faster than openai/whisper for the same accuracy while using less memory. The efficiency can be further improved with 8-bit quantization on both CPU and GPU.

faster-whisper是使用CTranslate2对OpenAI的Whisper模型进行的重新实现，CTranslate2是Transformer模型的快速推理引擎。
在保持相同准确率的同时，此实现比openai/whisper快达4倍，且占用内存更少。若在CPU和GPU上均采用8位量化，则效率可进一步提升。

CTranslate2之所以高效快速，主要源于其针对 Transformer 模型推理场景的深度优化，结合了硬件适配、执行策略和架构设计等多方面的改进。具体原因可归纳为以下几点：

1. 针对性的执行优化技术

CTranslate2 实现了多种高级优化技术，直接提升计算效率：

  • 层融合（Layer Fusion）：将多个连续的计算层（如注意力层、前馈网络层）合并为单次操作，减少层间数据传输和内存访问开销。
  • 移除填充（Padding Removal）：在处理批次数据时，去除输入序列中的填充（padding） tokens，避免无效计算，提高计算密度。
  • 批次重排序（Batch Reordering）：对输入批次按长度或其他特征重新排序，使计算更高效（如减少内存碎片化、提高缓存利用率）。
  • 原地操作（In-place Operations）：尽量在原有内存空间中执行计算，减少不必要的内存分配和拷贝。
  • 缓存机制（Caching Mechanism）：对频繁使用的中间结果或参数进行缓存，避免重复计算或加载。

2. 量化与低精度计算支持

通过支持多种低精度数据类型，在保证精度损失最小的前提下大幅提升计算速度：

  • 支持 FP16（16 位浮点数）、BF16（16 位脑浮点数）、INT16（16 位整数）、INT8（8 位整数）甚至 INT4（4 位整数，AWQ 量化）等格式。
  • 低精度计算不仅减少内存带宽占用（数据传输更快），还能提高硬件计算单元的利用率（如 GPU 对 INT8 的计算吞吐量远高于 FP32）。
  • 量化后的模型体积更小（最多可缩小 4 倍），加载和访问速度更快。

3. 硬件适配与自动优化

  • 多 CPU 架构支持：针对 x86-64 和 AArch64/ARM64 等主流架构，集成了多个硬件优化后端，如 Intel MKL、oneDNN、OpenBLAS、Ruy、Apple Accelerate 等，充分利用硬件特性。
  • 自动指令集调度：单个二进制文件可包含多种指令集（如 AVX、AVX2）和后端，运行时根据 CPU 型号自动选择最优方案，无需手动配置。
  • GPU 高效利用：支持 CUDA 等 GPU 加速，结合量化（如 INT8 + FP16 混合精度）进一步提升 GPU 计算效率，减少显存占用。

4. 并行与异步执行

  • 多批次并行处理：支持多 GPU 或 CPU 核心并行处理多个批次，提高硬件资源利用率。
  • 异步执行：通过异步接口（如 translate_batch_async）允许在等待当前批次计算时预处理下一批次，减少空闲时间，提升吞吐量。

5. 动态内存管理

  • 采用缓存分配器（CPU 和 GPU 均支持），根据输入请求大小动态调整内存使用，避免过度分配或频繁内存申请 / 释放，平衡性能与内存开销。

6. 轻量架构与框架无关性

  • 与原始 CTranslate 相比，CTranslate2 移除了对 LuaTorch 等 deprecated 框架的依赖，核心逻辑与具体深度学习框架解耦，仅在模型转换阶段处理框架相关逻辑，减少运行时冗余。
  • 延迟调用外部库（如 Intel MKL、cuBLAS），避免依赖库的复杂逻辑对执行效率的影响，专注于核心推理优化。

实测数据佐证

从官方 benchmarks 来看，CTranslate2 在相同硬件上的性能显著优于通用深度学习框架（如 TensorFlow、PyTorch）和其他专用工具（如 Marian）：

  • CPU 上：相比 OpenNMT-py（PyTorch），INT8 量化下的 CTranslate2 tokens 处理速度提升约 3 倍，内存占用减少 75%。
  • GPU 上：相比 FP32 精度，INT8 + FP16 混合精度下的 tokens 处理速度提升约 1.4 倍，显存占用降低 30% 以上。

综上，CTranslate2 通过 “算法优化 - 硬件适配 - 资源管理” 的全链路设计，实现了 Transformer 模型推理的高效执行，尤其适合生产环境中的高性能需求。

在这里插入图片描述

文章参考

https://blog.ZEEKLOG.net/gitblog_00911/article/details/151477552

https://github.com/SYSTRAN/faster-whisper/

https://github.com/OpenNMT/CTranslate2/

https://github.com/CheshireCC/faster-whisper-GUI/blob/main/%E5%8F%82%E6%95%B0%E8%AF%B4%E6%98%8E%EF%BC%9A.md

Read more

AI友好型架构-AI时代我们是否还需要DDD

1. Vibe Coding 带来的效率提升和问题 从Vibe Coding火了之后，我就一直在不断的在使用AI写一些自己感兴趣的小项目，有试过人机共写，但更多的还是只下命令，代码怎么写，技术栈用什么全由AI自己决定。这两年用AI写了大大小小一二十个项目，但是体验下来最大的感受就是刚开始AI的开发速度确实很快，但是随着想要的功能越来越多和业务规则越来越复杂，AI的上下文窗口似乎总是不够用，不管是claude还是gpt codex系列，在系统体量大了之后让AI再进行功能改动的时候AI总是顾此失彼，往往一个功能要改动两三次，并且代码审查下来非常痛苦，能够感觉开发效率明显的降低。 正巧前几天看到一篇很有意思的文章：《什么是AI友好型架构》。里面核心观点就是喂给AI丰富的领域上下文，并且这个领域上下文也易于被人类工程师理解，方便人机合作。 在看到这篇文章之后，我脑子中第一个想法就是：这不就是DDD的思想吗? 正巧我也算是在DDD领域小有经验，我就结合自身的开发经历和大家做一些小小的探讨，欢迎大家一起讨论。 2.让AI做自己擅长的事情 AI擅长的是“写代码”，而非“理解业务”。它可以

By Ne0inhk

SpringBoot 接口性能优化：从接口慢到毫秒级响应实战

一、核心认知：接口慢的本质的是什么？ 优化的前提是“找准问题”，很多开发者在优化时陷入“头痛医头、脚痛医脚”的误区，核心原因是没有看透接口慢的本质。根据 Spring 官方性能白皮书及阿里、京东等企业的性能优化实践，SpringBoot 接口响应慢，本质是“资源消耗过高”或“资源调度不合理”，主要集中在 4 个核心层面。 1.1 接口慢的 4 大核心诱因（权威总结） 结合 Spring 官方对 Web 接口性能的分析，以及工业界大量实战案例，接口慢的诱因按影响权重排序如下，也是后续优化的重点方向： 1.1.1 数据层瓶颈（占比 60%+） 这是最常见、影响最大的诱因，主要体现在数据库操作上：比如不合理的 SQL 查询、未建立索引、

By Ne0inhk
Flutter 三方库 servicestack 的鸿蒙化适配指南 - 实现企业级 Message-based 架构集成、支持强类型 JSON 序列化与跨端服务调用同步

Flutter 三方库 servicestack 的鸿蒙化适配指南 - 实现企业级 Message-based 架构集成、支持强类型 JSON 序列化与跨端服务调用同步

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 servicestack 的鸿蒙化适配指南 - 实现企业级 Message-based 架构集成、支持强类型 JSON 序列化与跨端服务调用同步 前言 在进行 Flutter for OpenHarmony 的大型企业级应用开发时，如何确保端侧（鸿蒙应用）与后端服务之间的契约（Contract）高度一致，避免由于字段拼写错误导致的运行时异常？ServiceStack 是一套成熟的企业级消息驱动（Message-based）通讯框架。它能让你在鸿蒙端以极其严谨、类型安全的方式调用后端 API。本文将指导大家如何在鸿蒙系统下构建坚如磐石的服务通信层。 一、原理解析 / 概念介绍 1.1 基础原理 与传统的 REST 接口依靠手动编写 Model 不同，ServiceStack 倡导“契约先行”

By Ne0inhk
快速学习GO语言总结

快速学习GO语言总结

干货分享，感谢您的阅读！备注：本博客将自己初步学习GO的总结进行分享，希望大家通过本博客可以在短时间内快速掌握GO的基本程序编码能力，如有错误请留言指正，谢谢！（持续更新） 一、初步了解Go语言 （一）Go语言诞生的主要问题和目标 1. 多核硬件架构： 随着计算机硬件的发展，多核处理器成为主流，使得并行计算变得普遍。然而，传统的编程语言在处理多核并行性时可能面临困难，因为它们缺乏合适的原生支持。Go语言通过引入轻量级的协程（goroutine）和通道（channel）机制，使得并发编程变得更加容易。开发者可以轻松地创建数千个并发执行的协程，而无需担心线程管理的复杂性。 2. 超大规模分布式计算集群： 随着云计算和分布式系统的崛起，构建和维护超大规模的分布式计算集群变得越来越常见。这些集群需要能够高效处理大量的请求、数据共享和协调。Go语言的并发特性和通道机制使得编写分布式系统变得更加容易，开发者可以使用协程和通道来处理并发任务、消息传递和协调工作。 3. Web模式导致的开发规模和更新速度增加： Web应用的兴起带来了前所未有的开发规模和持续更新的需求。传统的编程语言在

By Ne0inhk