你在网页里整理一小时的采访录音，通常要先把音频上传到服务器，再等云端模型返回文字。parakeet.wgsl 想换一种做法：录音留在设备上，浏览器直接调用本机 GPU 完成转写。它展示的重点不只是“网页也能听写”，而是一条不依赖服务端和现成推理框架的本地语音处理路径。
需要先说明：目前所有性能和兼容性说法都来自项目作者在 Reddit 的自述，尚无独立复测。
浏览器怎样扛起 6 亿参数模型？
项目运行的是 NVIDIA Parakeet TDT 0.6B V2，一款约 6 亿参数的英语语音转写模型。语音转写属于 ASR，即自动语音识别：把录音中的话转换成文字。
作者没有接入现成推理框架，而是做了一套 fully custom、dependency-free 的实现，也就是自行编写完整运行链，并且不依赖第三方运行库。
其中，模型的大量并行计算交给原生 WebGPU compute shaders。WebGPU 是浏览器调用本机 GPU 做图形和通用计算的接口；compute shader 则是直接交给 GPU 执行的计算程序。可以把它理解成：浏览器不再只是展示操作界面，也开始亲自调度显卡干模型推理的重活。
录音进入模型前还要经过音频前处理。项目用 SIMD WebAssembly 完成这一步。WebAssembly 是浏览器能够高效执行的低层代码格式；SIMD 则让一条指令同时处理多份数据，适合音频和矩阵运算。两者结合，是为了让这段准备工作尽量接近原生程序的执行效率。
20 秒处理一小时音频，意味着什么？
据项目作者给出的测试，在 Apple M5 和 Google Chrome 151.0.7922.72 环境下，一小时音频可在 20 秒内完成转写。这个数字如果能被稳定复现，意味着网页里的听写工具不必把计算和录音都交给远端服务器，也可能快速处理长录音。
但目前不能把它理解成所有电脑都能达到这一速度。作者没有交代测试音频、统计方式、预热过程、模型加载时间和功耗，也没有提供 WER——衡量转写文字与标准答案差异的常用错误率指标。因此，我们只能确认项目已经报告了这项速度，不能确认其普遍性能或实际准确率。
项目作者称，只要设备有 GPU，浏览器也支持 WebGPU，就能运行 parakeet.wgsl。不过现实中的可用性还会受到浏览器、操作系统、驱动、GPU 特性和内存限制影响。项目现已提供在线演示、GitHub 源码和 npm 包，开发者可以自行试用或接入网页项目。
为什么值得关注？
这个项目真正有意思的地方，是它把语音识别的完整推理链搬进了浏览器本地。对网页应用来说，这可能减少服务器依赖；对不希望音频外传的场景来说，本地处理也提供了另一种产品设计方向。
作者推测，它可能是首个在浏览器内实现快速且准确本地转写的项目。但原文使用的是“might be”，且目前只有单一信源，所以不能把“首个”当作已经证实的事实。
局限与未知
- 20 秒转写一小时音频的结果仅来自作者测试，尚缺独立复现，也不能外推到其他设备。
- 材料没有提供 WER 等准确率指标，项目所称的“准确”目前无法量化核验。
- 跨设备兼容性的实际边界仍不清楚，需要在不同浏览器、驱动、GPU 和内存条件下验证。