Nanosamur.ai 实战：在本地搭建可追踪的多模型语音转写流水线
会议录音、客服通话和访谈资料，往往包含不适合上传到第三方 API 的敏感内容。真正麻烦的不只是“把音频转成文字”，还包括说话人区分、实时结果与最终结果的差异、模型切换，以及出错后如何定位是哪一层出了问题。
Nanosamur.ai 是一个 Apache-2.0 许可的开源语音 AI 平台，主打在自己控制的基础设施中处理语音。它提供浏览器界面、Windows 优先的 Electron 包装器、API、Python SDK/CLI、录音存储和持久化能力；同一套系统可以接入实时、半实时和批处理转写模型。
它解决的不是一个“模型调用”问题
Nanosamur.ai 的价值在于把语音处理拆成可观察的流水线。前端通过 HTTP/WebSocket 把音频送到 API 层，后端使用 Kafka 传递音频和转写事件，PostgreSQL 保存会话与文本，S3 兼容存储保存录音。实时服务、精修服务和最终化服务可以分别使用不同模型。
官方仓库列出的模型管线包括：默认启用的 Faster-Whisper/WhisperX，支持实时或精修的 Qwen，实时 Nemotron，以及用于精修和最终结果的 Parakeet。于是一次录音可以同时得到“先出来的实时文本”和“稍后完成的高质量文本”，而不是让一个模型承担所有延迟与质量要求。
| 需求 | 传统单模型脚本 | Nanosamur.ai |
|---|---|---|
| 快速看到实时结果 | 需要自行实现流式接口 | 提供实时处理管线 |
| 比较多个模型 | 往往要写多套脚本 | 支持独立选择模型管线 |
| 保存完整会话 | 通常只输出文本文件 | 录音、会话和转写可持久化 |
| 排查异步问题 | 日志分散，难以串联 | Kafka 事件与可选追踪栈关联 |
用 Docker Compose 跑通第一个会话
官方 README 将 Docker Compose 作为公开评估路径。准备 Docker、Docker Compose v2、可用的 NVIDIA 容器运行时和适合的 GPU；部分模型还需要 Hugging Face Token。先克隆仓库并创建环境文件：
git clone https://github.com/nanosamurai/nanosamurai.git cd nanosamurai cp .env.example .env
把 HF_TOKEN 写入 .env 后启动：
docker compose pull docker compose up -d docker compose ps --all
然后打开 http://127.0.0.1:8000/live，选择 Microphone 和 Record now。实时结果会先出现，精修与最终结果随后异步到达。首次启动下载镜像和模型可能需要几分钟；默认语音服务请求 gpus: all，没有 NVIDIA GPU 时不能把这套默认配置当作“开箱即用的 CPU 方案”。
多模型对照时应该看什么
最有价值的用法不是盲目追求某个模型，而是把模型输出放在同一个会话里比较。比如一场技术会议可以让 Faster-Whisper 负责实时反馈，WhisperX 负责精修和最终结果；对特定语言或噪声环境，再按官方模型指南加入 Qwen、Nemotron 或 Parakeet。
实践中建议记录三个指标：首个可读片段出现的时间、最终文本完成的时间，以及专有名词和说话人标签是否需要人工修正。这样选型依据来自自己的音频，而不是只看模型名称或单次演示。
让异步系统可排查
Nanosamur.ai 的可选可观测性栈可以通过额外的 Compose 文件启动：
docker compose -f docker-compose.yml \\ -f docker-compose.observability.yml up -d
该配置会提供 Grafana，并接入 Prometheus、Loki 和 Tempo；README 还说明，Kafka 中携带 W3C trace context，可把 API、Python 工作进程、持久化服务、Kafka 和 PostgreSQL 中的异步处理串起来。遇到“实时文本正常、最终文本缺失”时，优先沿着同一个会话追踪事件，而不是反复重跑整个录音。
部署边界与安全提醒
这个项目的公开仓库明确把 Docker Compose 定位为评估路径：容器服务可以适配 Kubernetes，但仓库不提供生产 Kubernetes manifests 或 charts。默认端口绑定到 127.0.0.1，评估配置使用固定开发凭据并关闭认证，因此不要直接把它暴露到局域网或公网。正式环境需要自行配置认证、密钥和租户隔离。
此外，仓库虽然说明依赖准备完成后可以在没有云端语音 API 的情况下处理语音，但普通 quickstart 会下载镜像、模型和其他依赖，不能直接等同于完整的离线部署方案。录音、转写文本、.env 和 Token 也不应提交到 Git 仓库。
总结
如果你的核心要求是“敏感音频留在自己的环境中，同时保留实时反馈、模型对照和异步处理可追踪性”，Nanosamur.ai 比一个几十行的转写脚本更合适。它的门槛也很明确：默认路径依赖 GPU、Docker 和较完整的后端组件。先用 Compose 跑通本地会话，再根据模型延迟、最终质量和存储策略决定是否继续做生产化改造。