VoxDESIGN NOTES 进入工作台 ↗

PART 02 / 从性能目标,到整体架构

高性能,落在这张图里。

左侧看完整架构,右侧读设计。选择维度,再点图中编号。

整体架构

先看全局:业务请求、媒体文件和耗时任务各走自己的路径。

可左右滑动看全图,或点“适应宽度”查看全貌。
Vox 整体架构与性能设计 浏览器经 nginx 访问 API 网关和生词服务。网关通过 gRPC 调用文件服务和任务服务;任务服务通过 RabbitMQ 先派发转码,完成回报后再派发短音频云端转写或长音频本地转写。浏览器和 worker 直接读写对象存储。选择上方维度可高亮模块,编号链接到右侧说明。 媒体直接上传 / 回听 / 读取结果 · 预签名 URL HTTP /api/ /vocab/ gRPC gRPC 签名 URL 签名 / 完成校验 派发 / 推进阶段 转码队列 短转写队列 长转写队列 worker 状态回报 worker 直接读写文件 Vox 工作台 录音 / 上传 阅读 · 回听 · 导出 web · nginx 静态页 / 反向代理 01 API 网关 Gin · JWT userdb · PostgreSQL 05 生词服务 HTTP · ECDICT 英文候选与释义 02 文件服务 归属 / 元数据 / 签名 filedb · PostgreSQL 03 任务服务 阶段编排 / 长短分流 taskdb · PostgreSQL RabbitMQ exchange vox.tasks transcode transcribe-short transcribe-long 对象存储 原始媒体 / 标准音轨 转写结果 JSON 06 转码 worker ffmpeg → 16 kHz WAV 独立进程 · 可增实例 04 云端转写 ElevenLabs · Scribe v2 短音频 · 默认 ≤10 分钟 04 本地转写 whisper.cpp 长音频 · 部署机器运行 1 2 3 4 4 4 5 6
业务调用 / 状态回报媒体文件直传任务队列点击编号 → 右侧说明

处理顺序:上传 → 转码 → 回报任务服务 → 长短转写分流 → 保存结果。图示为逻辑架构,云端 worker 需按部署启用。

继续深入 / 方案取舍相比直接接 API 或单体应用,取舍在哪里?

识别 API 提供语音识别能力,单体也可以实现完整产品。这里比较的是三种实现范围与资源组织方式;Vox 的价值在于把这些能力接成了可持续使用的工作流。

左右滑动,查看完整方案对比 →

最小 API 接入、同步单进程实现与 Vox 的范围和取舍
关注点 仅接入转写 API最小接入方式 同步单进程应用Web 与耗时处理同部署 Vox归档 + 回听 + 异步处理
转写之后 得到识别结果;个人内容库与回听交互需继续建设。 可以实现归档与阅读,体验取决于额外的产品设计。 文件、结果、时间戳和生词在同一工作台中关联,支持再次使用与导出。
等待长任务 调用方负责管理等待、状态和结果保存。 同步处理会延长请求等待,并与 Web 共享运行资源。 任务创建与执行分开;阶段与结果可查询,前端定期更新。
增加处理能力 受服务提供方配额和调用预算约束。 通常以整个应用为部署单位;也可进一步拆分后台任务。 按转码、短转写、长转写分别增加消费者,针对积压分配资源。
引擎与成本选择 采用选定提供方的能力与计费方式。 同样可以集成不同引擎,但需自行设计切换与结果适配。 以统一接口接本地与云端引擎,按时长分流;成本取舍可继续调优。
需要承担的复杂度 接入轻;仍需补齐用户、内容管理与异常处理。 部署和本地调试简单,适合较小规模或早期验证。 增加了跨服务通信、队列、部署与一致性治理成本。

适合 Vox 的场景:希望长期积累音视频资料、经常按句复听,且转码与转写负载需要分别安排资源。

继续深入 / 验证与代码依据这些设计已经做到什么,又该怎样验证?
已在代码中实现

从用户输入到结果复用的完整链路

  • 录音试听、文件上传、异步转写与历史内容读取。
  • 时间戳定位、同步高亮、生词候选及 TXT / SRT 导出。
  • 账户归属检查、对象存储直传、阶段队列与两类转写引擎。
  • Chromium 回归使用模拟 API 和麦克风,覆盖录音、播放、跳转、失败恢复与移动布局。
后续工程验证

下一步:测量性能,补齐可靠性

  • 独立扩展路径已具备;并发吞吐、延迟与成本仍需压测,尚无容量数字承诺。
  • KEDA 配置是待更新的示例,仍需对齐当前队列并验证自动扩缩容。
  • 继续完善任务幂等、失败重试、死信与数据库/消息一致性。
  • 补齐备份恢复、用户配额、服务访问边界与监控告警;持久存储不等于永久保存承诺。

用同一组任务,分别测量准确率、效率与速度

固定音频、任务目标、模型版本、硬件与并发条件,先记录基线,再比较优化后的表现。以下是测量计划,目前尚无量化基准结果。

效率 · 用户投入
完成一次转写和定位回听所需的操作次数、主动操作时间、查找时间与校对时间。
速度 · 端到端耗时
分别记录上传、排队、转码和转写耗时,再看端到端耗时的中位数与 P95。
准确率 · 识别质量
在人工标注的相同样本上统计字词错误率,并记录人工校对时间。回听方便不等于模型识别率更高。
效率 · 有效产出
检查关键内容能否被正确找回、定位与导出,观察后续任务是否真正复用了这些结果。
展开实现依据与当前边界

以下链接指向仓库实现,便于继续追问设计细节。没有用未经测量的性能数字或“零丢失”承诺代替验证。

两类转写引擎已有实现;当前 Compose 没有包含云端 worker,需按实际部署启用。任务阶段与结果可查询,处理中的状态回报仍需完善。搜索目前针对文件名与 ID;段落定位依赖已有时间戳。未提交的录音草稿只保存在当前页面,提交成功后才进入服务器端内容管理。真实设备、线上存储及 Safari/iOS 仍需联调验证。

设计回到使用中,才有意义

用真实任务,检验这些选择。

体验录音、转写与按句回听,或回到性能理念继续了解产品目标。

进入 Vox 工作台 ↗