⏱️ Lectura: 10 min
transcribe.cpp acaba de llegar a su versión 0.1.0 con soporte para 16 familias de modelos de reconocimiento de voz, más de 60 modelos individuales y aceleración por GPU vía Vulkan, Metal, CUDA y TinyBLAS. La librería, escrita en C/C++ sobre ggml, apunta a convertirse en el reemplazo directo de whisper.cpp que el ecosistema de transcripción local venía necesitando.
📑 En este artículo
Detrás del proyecto está cjpais, autor y mantenedor de Handy, una aplicación de dictado por voz multiplataforma. transcribe.cpp nació de un problema muy concreto: distribuir un motor de transcripción confiable en Windows, macOS y Linux sin depender de un mosaico de librerías con mantenimiento incierto.
TL;DR
- transcribe.cpp llegó en versión 0.1.0 en abril de 2026, creado por cjpais, autor y mantenedor de la app Handy.
- Soporta 16 familias de modelos ASR y más de 60 modelos individuales de la organización handy-computer en Hugging Face.
- Acelera inferencia vía Vulkan, Metal, CUDA y TinyBLAS, con benchmarks publicados en un Ryzen 4750U y en un Mac M4 Max.
- Cada modelo pasa validación numérica y pruebas de WER contra la implementación de referencia antes de publicarse.
- Funciona como reemplazo directo de whisper.cpp, incluida compatibilidad con archivos .bin existentes.
- Ofrece bindings mantenidos oficialmente en Python, JavaScript/TypeScript, Rust y ObjC/Swift.
- Soporta transcripción en modo streaming y en modo batch.
- Es una versión v0.1.0: el propio autor pide reportar los bordes ásperos que aún tiene.
Introducción a transcribe.cpp
El stack de inferencia para ASR (reconocimiento automático de voz, por sus siglas en inglés) local es, en palabras del propio autor, un terreno complicado. Hasta ahora las opciones reales eran básicamente dos: whisper.cpp y ONNX. Sumar MLX para dispositivos Apple implica mantener un tercer motor y portar modelos a cada uno por separado.
ONNX le permitió a Handy sumar soporte de modelos rápido, pero dejaba mucho rendimiento sobre la mesa al quedar limitado en varios escenarios sin GPU. Existen otras librerías que dicen soportar muchos modelos, pero con autores anónimos y sin pruebas documentadas: no queda claro si siguen mantenidas, si tienen bindings reales o si alguna vez compararon su salida contra la referencia oficial.
transcribe.cpp busca cerrar esa brecha: una librería con un solo binario embebible, que corra en GPU en las tres plataformas de escritorio principales y cuya salida esté verificada modelo por modelo.
Qué pasó con transcribe.cpp
El anuncio se publicó en abril de 2026 en el blog de cjpais, junto con el lanzamiento de la librería. transcribe.cpp queda posicionado como el motor de inferencia detrás de la próxima versión de Handy, que hasta ahora corría sobre whisper.cpp.
La versión 0.1.0 ya soporta 16 familias de modelos ASR, más de 60 modelos en total, publicados bajo la organización handy-computer en Hugging Face. El propio autor advierte que faltan algunos modelos por sumar y que, al ser una primera versión, habrá bordes ásperos: pide a la comunidad reportarlos para resolverlos en conjunto.
Contexto e historia
ggml es la librería de inferencia en C que popularizó Georgi Gerganov con llama.cpp y whisper.cpp: tensores cuantizados, sin dependencias de Python ni PyTorch, pensada para correr en CPU y GPU con un binario liviano. Ese mismo enfoque es el que adopta transcribe.cpp para resolver el problema de distribución que describe su autor.
whisper.cpp lleva años siendo la puerta de entrada más popular para correr modelos Whisper de OpenAI de forma local, y por eso buena parte del ecosistema, incluida Handy, construyó sus integraciones alrededor de sus archivos .bin. transcribe.cpp mantiene compatibilidad con ese formato para no romper instalaciones existentes, mientras suma soporte a familias de modelos que whisper.cpp nunca cubrió.
La decisión de construir sobre ggml en lugar de mantener un fork de whisper.cpp o adoptar ONNX responde directamente a la experiencia de mantener Handy: cjpais necesitaba un único motor con buena historia de distribución multiplataforma, y ggml ya tenía comunidad y herramientas maduras alrededor.
Detalles técnicos y rendimiento
El soporte de aceleración cubre cuatro backends: Vulkan, Metal, CUDA y TinyBLAS. Cada modelo publicado en la organización handy-computer trae benchmarks corridos en dos máquinas de referencia: una laptop con Ryzen 4750U usando CPU y Vulkan sobre Fedora, y una Mac con chip M4 Max.
| Backend | Hardware objetivo | Cuándo usarlo | Limitación |
|---|---|---|---|
| Vulkan | GPU AMD, Intel o NVIDIA | Linux y Windows sin depender de CUDA propietario | Rendimiento variable según drivers |
| Metal | Apple Silicon (M1 a M4) | macOS con chips propios de Apple | Exclusivo de macOS |
| CUDA | GPU NVIDIA | Servidores o workstations con tarjetas NVIDIA | Requiere drivers y toolkit propietarios |
| TinyBLAS | CPU sin GPU dedicada | Equipos sin GPU compatible, como respaldo | Más lento que las rutas por GPU |
El criterio central del proyecto es la validación numérica: cada modelo se compara matemáticamente contra la implementación de referencia antes de publicarse, y además se corre contra sweeps de WER (word error rate, la métrica estándar para medir errores de transcripción) con miles de audios de prueba. Los resultados de esas corridas quedan publicados tanto en el repositorio de transcribe.cpp como en la ficha de cada modelo en Hugging Face.
flowchart TD
A["Archivo de audio"] --> B["transcribe.cpp (motor ggml)"]
B --> C{"Backend disponible"}
C --> D["Vulkan, Metal o CUDA"]
C --> E["TinyBLAS (solo CPU)"]
B --> F["Bindings: Python, JS/TS, Rust, Swift"]
F --> G["Handy y otras apps"]💭 Clave: la validación no es solo funcional. Cada modelo se compara número por número contra la implementación de referencia antes de publicarse, no solo se prueba que produzca texto legible.
Esa doble verificación, numérica y de WER, es la respuesta directa al problema que describe cjpais con los modelos ONNX sueltos que circulan en Hugging Face: sin ese proceso, no hay forma de saber si una conversión a otro formato introdujo errores silenciosos en la salida.
Cómo empezar con transcribe.cpp
El repositorio oficial del proyecto, enlazado en Referencias, sigue el mismo flujo de build con CMake que el resto del ecosistema ggml (llama.cpp, whisper.cpp). Los pasos son equivalentes en Windows, macOS y Linux; solo cambia el flag del backend de aceleración que actives.
# Linux / macOS, con soporte Vulkan
cd transcribe.cpp
cmake -B build -DGGML_VULKAN=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build -j
./build/bin/transcribe -m modelo.bin -f audio.wav# Windows (PowerShell), con soporte CUDA
cd transcribe.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release
.\build\bin\Release\transcribe.exe -m modelo.bin -f audio.wavEl binario resultante acepta un modelo .bin compatible con whisper.cpp o uno de los modelos verificados de handy-computer, más un archivo de audio. Para integrarlo en una app en lugar de usar el CLI, los bindings oficiales exponen la misma funcionalidad:
from transcribe_cpp import Transcriber
modelo = Transcriber.from_pretrained("handy-computer/whisper-large-v3-turbo-ggml")
resultado = modelo.transcribe("reunion.wav", language="es")
print(resultado.text)Ese fragmento carga un modelo publicado por handy-computer y transcribe un archivo de audio en español, devolviendo el texto plano. El mismo patrón se repite en los bindings de JavaScript/TypeScript, Rust y ObjC/Swift, con la firma adaptada a cada lenguaje.
⚠️ Ojo: al ser v0.1.0, transcribe.cpp todavía no soporta algunos flags avanzados que sí tiene whisper.cpp. Para la mayoría de los casos de uso el autor lo considera equivalente en rendimiento, pero conviene revisar la lista de flags soportados antes de migrar una integración compleja.
Impacto y análisis
Para cualquiera que distribuya una app de escritorio con transcripción local, el problema que resuelve transcribe.cpp es real y conocido: soportar Windows, macOS y Linux con aceleración por GPU obliga hoy a elegir entre whisper.cpp (rápido pero limitado en modelos), ONNX (amplio pero flojo en GPU) o mantener dos motores en paralelo.
Los bindings mantenidos por el propio equipo en Python, JavaScript/TypeScript, Rust y ObjC/Swift son la otra pieza clave. cjpais eligió esos cuatro lenguajes porque, según explica, representan razonablemente bien dónde termina usándose este tipo de librería: scripts y notebooks en Python, apps web y de escritorio en JS/TS, backends y CLIs en Rust, y apps nativas de Apple en Swift.
El respaldo de Handy le da al proyecto algo que las librerías ASR alternativas mencionadas por el propio autor no tienen: un mantenedor con incentivo directo para seguir sosteniendo el código, porque su propia aplicación depende de él en producción.
Qué sigue
El plan inmediato es cerrar la lista de modelos ASR que todavía faltan por soportar. El propio anuncio deja la puerta abierta a que la comunidad contribuya bindings adicionales, siempre que se haga cargo del mantenimiento de esa integración.
A mediano plazo, cjpais adelanta que su intención es sostener transcribe.cpp con la misma continuidad con la que mantiene Handy: no lo plantea como un experimento de fin de semana, sino como la base sobre la que construir transcripción local accesible para más aplicaciones, no solo la suya.
📖 Resumen en Telegram: Ver resumen
Probalo vos: cloná el repositorio de transcribe.cpp enlazado en Referencias y corré tu primer archivo de audio contra un modelo de handy-computer hoy mismo.
Preguntas frecuentes
¿Qué es transcribe.cpp?
Es una librería de transcripción de voz a texto escrita en C/C++ sobre ggml, que soporta más de 60 modelos ASR con aceleración por GPU en Windows, macOS y Linux.
¿Reemplaza completamente a whisper.cpp?
Funciona como reemplazo directo en la mayoría de los casos, incluida compatibilidad con archivos .bin existentes, aunque todavía no cubre algunos flags avanzados de whisper.cpp por ser una versión 0.1.0.
¿Qué backends de aceleración soporta?
Vulkan, Metal, CUDA y TinyBLAS, cubriendo GPU de AMD, Intel, NVIDIA y Apple Silicon, además de una ruta optimizada para CPU sin GPU dedicada.
¿En qué lenguajes tiene bindings oficiales?
Python, JavaScript/TypeScript, Rust y ObjC/Swift, todos mantenidos directamente por el equipo del proyecto.
¿Cómo se valida la precisión de los modelos?
Cada modelo se compara numéricamente contra la implementación de referencia y se somete a pruebas de WER con miles de audios, con los resultados publicados en el repositorio y en Hugging Face.
¿Quién mantiene el proyecto?
cjpais, autor y mantenedor de Handy, la aplicación de dictado por voz que motivó la creación de transcribe.cpp.
Referencias
- Fuente original: el anuncio de cjpais con la motivación, features y roadmap de transcribe.cpp.
- Hugging Face: handy-computer: organización donde se publican los modelos ASR verificados numéricamente.
- GitHub: whisper.cpp: el proyecto de referencia con el que transcribe.cpp mantiene compatibilidad de archivos .bin.
- GitHub: ggml: la librería de inferencia en C sobre la que está construido transcribe.cpp.
- Wikipedia: Word error rate: definición de la métrica WER usada para validar cada modelo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios