在端侧 AI 交互场景中，如何在保持低延迟的前提下同时处理屏幕视觉信息与麦克风音频信号，是工程实现的核心挑战。BasedHardware 开源的 Omi 项目提供了一套完整的产品级解决方案，其架构设计围绕双模输入（屏幕加麦克风）、本地化 VAD（语音活动检测）以及 OCR 文字提取展开，目标是将端到端延迟控制在 200 毫秒以内。本文从工程落地的角度，剖析 Omi 的核心感知链路、关键模块选型以及可供参考的性能调优参数。
双模输入与分层感知架构
Omi 的感知系统采用分层架构，将端侧设备划分为三层：边缘捕获层、本地处理层与云端推理层。边缘捕获层由 Omi 可穿戴设备（基于 nRF 微控制器与 Zephyr 实时系统）和 Omi Glass（基于 ESP32-S3）组成，负责从物理世界采集原始音频与视频数据。这两层设备通过低功耗蓝牙（BLE）将数据发送至配套的移动端应用或桌面客户端，形成第一道数据入口。
本地处理层是整个架构的性能关键点。桌面客户端采用 SwiftUI 构建前端界面，后端核心逻辑由 Rust 实现（使用 Axum 框架），通过进程内嵌的方式直接运行在用户设备上。这种架构的优势在于能够在本地完成大部分计算密集型任务，避免将原始视频流全部上传至云端，从而显著降低网络往返延迟。本地 Rust 后端负责接收屏幕捕获帧、执行轻量级 OCR 推理、以及管理麦克风音频流的缓冲与分发。
云端推理层则承担语义理解与持久化存储的职责。Omi 的后端采用 Python FastAPI 构建，调用 Deepgram Nova-3 进行实时语音转写（STT），使用 Silero VAD 进行语音活动检测，并通过 LangChain 与 LangGraph 编排多轮 LLM 调用，完成会议摘要、行动项提取与记忆生成等高级任务。存储层则采用多数据库协同策略：Firestore 作为主存储库存储会话记录，Redis 负责缓存用户配置与语音 Profile 元数据，Pinecone 提供向量嵌入的语义检索能力，Neo4j 构建知识图谱关联实体与关系，Typesense 则用于全文搜索。
本地 VAD 实现与音频管道优化
语音活动检测是整个音频管道的第一道过滤器，直接影响后续 STT 调用的频率与计算成本。Omi 采用 Silero VAD（GPU 加速版本）作为核心检测模型，部署在云端处理管道中，但通过参数调优实现了接近本地的响应速度。在实际部署中，VAD 的关键配置参数包括：窗口大小设置为 256 毫秒或 512 毫秒，起始阈值设定为 0.5，结束阈值设定为 0.3，以在灵敏度和误检率之间取得平衡。
音频管道的低延迟设计依赖于 WebSocket 的双向通信机制。Omi 客户端通过 /v4/listen 端点建立持久连接，音频数据以块状流式传输，后端立即将数据转发至 Deepgram 并接收转写结果。Deepgram 的 no_delay 选项被启用，以消除处理队列中的人为等待时间。整个音频管道的设计目标是将声学信号到转写文字的延迟控制在 150 毫秒以内，加上后续 LLM 处理的 50 毫秒，合计约 200 毫秒的端到端延迟。
本地 VAD 的一个重要工程实践是语音 Profile 的使用。当用户预先上传一段语音样本后，系统会将其存储在 Google Cloud Storage 中，并在 Redis 中缓存时长元数据。在实时转写阶段，后端加载语音 Profile 并结合 Deepgram 的说话人分离（Diarization）功能，显著提升多人对话场景下的识别准确率。这一机制在产品层面实现了「记住谁说了什么」的原生能力。
屏幕 OCR 与视觉信息提取
屏幕捕获是 Omi 区别于传统语音助手的关键差异点。其实现逻辑并不依赖单一的端侧 OCR 模型，而是采用了本地捕获、增量处理、云端增强的混合策略。桌面客户端的 Rust 后端持续轮询屏幕内容变化，当检测到显著差异帧（通过像素差异阈值触发）时，触发 OCR 处理流程。
具体而言，Rust 层使用跨平台的屏幕捕获 API 获取位图数据，然后通过 quantization 与硬件加速的轻量级 OCR 模型（如经过 INT8 量化后的 CRNN 模型）在本地完成初步文字检测与识别。识别结果以结构化文本的形式随音频转写一同发送至云端，供后续的 LLM 推理使用。这种设计的核心考量在于：完全在云端处理屏幕视频流的带宽成本与延迟均不可接受，而完全端侧运行大模型又受限于终端算力。
在云端增强阶段，OCR 结果与音频转写通过时间戳对齐，形成「视觉 - 听觉」的交叉验证上下文。例如，当用户在视频会议中共享屏幕展示一份合同文档时，OCR 提取的文档文字与麦克风捕获的讨论内容可以被 LLM 同时读取，从而生成「基于屏幕上某段文字的讨论摘要」。这种多模态融合能力是 Omi 产品差异化的核心技术支撑。
工程落地的关键监控指标
将上述架构投入生产环境时，团队需要关注若干关键的可观测性指标。延迟层面，建议监控三个阶段：音频捕获到 VAD 检测的延迟（目标小于 30 毫秒）、VAD 触发到首字转写返回的延迟（目标小于 120 毫秒）、以及 OCR 帧处理延迟（目标小于 80 毫秒）。任一阶段的异常都可能拉高整体延迟，导致交互体验下降。
资源占用层面，Rust 后端的内存峰值应当控制在 200MB 以内，CPU 占用在中等算力桌面设备上不超过单核满载的 60%。云端的 GPU VAD 实例需要配置自动扩缩容策略，以应对突发的大量并发会话。错误率方面，WebSocket 连接断开率应低于 0.1%，OCR 识别失败率应低于 2%，两者均通过重连机制与降级策略保证整体可用性。
数据存储层面，需要特别关注向量检索（Pinecone）与图数据库（Neo4j）的查询延迟。前者用于语义相似会话的召回，查询耗时应控制在 100 毫秒以内；后者用于构建实体关系网络，写入延迟应控制在 200 毫秒以内。Redis 缓存的命中率应作为用户体验的前置指标进行监控，典型目标值为 95% 以上。
小结与可迁移经验
Omi 的端侧实时感知架构提供了一套可参考的双模输入处理范式，其核心工程经验可以归纳为三点：首先是分层计算 —— 将 VAD 与轻量级 OCR 部署在本地或近端处理，仅将结构化语义结果上传云端；其次是流式管道 —— 通过 WebSocket 实现真正的双向流式通信，而非请求 - 响应式的轮询模式；第三是多数据库协同 —— 根据数据访问模式选择向量数据库、图数据库与关系型存储的组合，避免单一存储介质的性能瓶颈。这些设计原则在构建其他端侧多模态 AI 产品时具有直接的迁移价值。
资料来源：BasedHardware Omi GitHub 仓库（https://github.com/BasedHardware/omi）及 Omi 官方文档（https://docs.omi.me）。