我们做了一个语音待办 App,从录音实时转文字再到本地大模型总结,全程零网络,数据不出手机

先说说我干了个啥事

是的，我们做了一个 Android App：语音待办，全离线环境可用，第一个版本的视频效果放在了文章底部。

它的核心链路只有三步：

1. 按住录音，Sherpa-ONNX 流式语音识别实时出字
2. 松手停止，转录文本送入本地 LLM
3. 大模型输出，总结内容 + 提取待办事项

全程离线。没有云端 API，没有数据上传，没有"请检查网络连接"。

为什么做这件事

两个趋势正在交汇：

• 端侧 ASR 已经成熟。Sherpa-ONNX、Whisper.cpp 等框架让手机上跑流式语音识别不再是实验，这完完全全是工程化可以直接实现的问题了。
• 端侧 LLM 正在爆发。Google 的 LiteRT-LM、Apple 的 On-Device Foundation Models、MLC-LLM……手机上跑 Gemma、Qwen 已经是现实。

但这两件事一直是分开的。ASR Demo 是 ASR Demo，LLM Chat 是 LLM Chat。没有人把它们串起来，做一个真正可用的端到端离线应用。

是的，我给做了，把这个串起来之后，可以用在很多离线场景，也不一定是要总结会议记录，比如警察蜀黍在网络不好的地方治法，是不是也能派上用场，可以进行事件的记录及总结分析。

我实现的整个技术架构如下

整条链路如下：

麦克风 → AudioRecord(16kHz/Mono/PCM16)       → Sherpa-ONNX Online Transducer(流式识别)       → CT-Transformer 标点恢复       → LiteRT-LM Engine(本地大模型推理)       → JSON 解析 → 总结 + 待办事项

语音识别我是这么做的：Sherpa-ONNX 流式 Transducer

我们选择了 Sherpa-ONNX 的 Online Transducer（RNN-T）架构，而非 Whisper 等自回归模型。原因很简单：

• 流式输出：RNN-T 天然支持 streaming，每 90ms 轮询一次结果，用户能实时看到文字冒出来
• 低延迟：编码器 67MB + 解码器 4.9MB + 联合网络 1MB，总共不到 75MB，加载快、推理快
• 中文友好：2002 个 BPE token，覆盖 CJK 字符和字级别片段

音频采集参数严格对齐模型要求：16kHz 采样率、单声道、PCM 16-bit。AudioRecord 每次读取 1024 个采样点，归一化为 [-1.0, 1.0] 的浮点数组后喂入识别器。

标点恢复是一个容易被忽略但极其重要的环节。原始 ASR 输出没有标点，可读性很差。我们加载了一个 72MB 的 CT-Transformer 标点模型，对流式结果（≥24 字符）和最终结果（≥16 字符）分别做后处理。如果标点模型加载失败，优雅降级——没有标点也比崩溃好。

本地大模型推理框架，我选择：LiteRT-LM Engine

这是整条链路中最"不可思议"的部分——在手机上跑 Gemma-4-E2B 这样的模型。

我们使用的是 Google 的 LiteRT-LM（前身是 MediaPipe LLM Inference API），版本 0.11.0。它基于 TensorFlow Lite，提供了 Engine → Conversation → sendMessageAsync() 的简洁 API：

val config = EngineConfig(    modelPath = modelPath,    backend = Backend.CPU(),    maxNumTokens = maxTokens,    cacheDir = context.cacheDir.absolutePath)val engine = Engine(config)engine.initialize()val conversation = engine.createConversation(    ConversationConfig(        systemInstruction = Contents.of(Content.Text(systemPrompt))    ))// 流式推理conversation.sendMessageAsync(contents, callback)

目前支持 9 个 .litertlm 格式模型，用户可按需下载：

模型	大小	最低内存	特点
Gemma-4-E2B-it	2.5 GB	8 GB	多模态，32K 上下文
Gemma-4-E4B-it	3.5 GB	12 GB	多模态，32K 上下文
Gemma-3n-E2B-it	3.5 GB	8 GB	多模态，int4 量化
Gemma-3n-E4B-it	4.7 GB	12 GB	多模态，int4 量化
Gemma3-1B-IT	557 MB	6 GB	轻量纯文本，推荐入门
Qwen2.5-1.5B-Instruct	1.5 GB	6 GB	中文能力强，q8 量化
DeepSeek-R1-Distill-Qwen-1.5B	1.7 GB	6 GB	推理能力强，q8 量化
TinyGarden-270M	276 MB	6 GB	函数调用专用
MobileActions-270M	276 MB	6 GB	手机操作专用

为什么选 LiteRT-LM 而不是 MLC-LLM 或 llama.cpp？

• LiteRT-LM 是 Google 官方方案，与 Android 生态集成最深（Play Services TFLite 自动更新运行时）
• .litertlm 格式已经做了针对移动端的算子优化和量化，开箱即用
• API 设计简洁，Engine + Conversation 的抽象刚好够用

对于Prompt 工程：这个案例我让小模型输出结构化 JSON

端侧模型的指令遵循能力远不如云端大模型。我们用了一个简单但有效的策略：

系统提示词（中文）：

你是一个中文语音转文字的智能助手。用户会给你一段语音识别的文本，你需要：1. 对文本进行总结，提炼核心内容2. 从中提取待办事项（如果有的话）请严格按照以下JSON格式输出，不要输出其他内容：{"summary":"总结内容","todos":["待办1","待办2"]}如果没有待办事项，todos为空数组。

解析策略：用 substringAfter("{").substringBeforeLast("}") 提取 JSON 主体，再用 Gson 反序列化。这比正则匹配更鲁棒——小模型偶尔会在 JSON 前后加废话，这个策略能容忍。

降级策略：如果 JSON 解析失败，直接把原始 LLM 输出作为总结，待办列表为空。用户不会看到崩溃，只是没有结构化的待办提取。

关于推理模型下载这里，为了优化体验，我做了断点续传 + 完整性校验

大模型文件动辄几个 GB，所以不方便直接打包在 apk 中，所以初始化时需要下载，因此下载体验很关键：

• 断点续传：检测本地已有部分文件大小，通过 HTTP Range 头从断点继续
• 重定向处理：HuggingFace 的下载链接会经过 CDN 重定向，我们手动跟随最多 10 次 301/302/307/308
• 完整性校验：下载完成后，isModelDownloaded() 不仅检查文件存在，还校验 file.length() == expectedSize。中途退出导致的部分文件不会被误判为已下载
• Wi-Fi 提醒：首次下载时检查网络类型，非 Wi-Fi 给出建议但不阻断（小模型用流量也合理）
• 速度显示：每 500ms 上报一次进度，包含下载速度

在数据数据持久化上：我选择Room + SharedPreferences

• Room 数据库存储转录记录：原文、总结、待办列表（JSON 序列化）、时间戳
• SharedPreferences 存储当前激活的模型路径、maxTokens、文件大小，App 重启后自动加载

整体看看视频效果

已关注

关注

重播分享赞

视频详情

这个地方在说一说踩过的一些坑

Sherpa-ONNX 的 AssetManager 陷阱

Sherpa-ONNX 的 OnlineRecognizer 构造函数接受一个 AssetManager 参数用于从 assets 加载模型。但我们的模型是从 assets 复制到 filesDir 后再按文件路径加载的。如果传入 Activity 的 AssetManager，它会尝试从 assets 目录找文件，路径对不上。

解决方案：传 null 作为 AssetManager，强制走文件路径加载模式。这个坑在 k2-fsa 的 issue #2562 里有记录。

ONNX Runtime 和 TFLite 的 JNI 冲突

Sherpa-ONNX AAR 自带 libonnxruntime.so，而 LiteRT-LM 依赖的 Play Services TFLite 也带了 libtflite_jni.so。两个库在 merge 阶段会冲突。

解决方案：Gradle packaging.jniLibs.pickFirsts 配置 pickFirst 策略。

部分下载文件被误判为完整

最初 isModelDownloaded() 只检查 file.exists() && file.length() > 0。用户下载到一半退出 App，下次进来系统认为模型已下载——因为那个不完整的文件确实存在且非空。

解决方案：用 file.length() == expectedSize 精确校验。每个模型的预期大小在 ModelConfig 中硬编码，下载完成和 App 重启时都会校验。

性能数据

在 Snapdragon 8 Gen 2（12GB RAM）设备上实测：

指标	Gemma3-1B-IT	Qwen2.5-1.5B-Instruct
模型加载时间	~3s	~5s
100 字转录总结	~8s	~12s
ASR 实时出字延迟	<200ms	<200ms
内存占用（ASR+LLM）	~1.2 GB	~1.8 GB

Gemma-4-E2B 在 12GB+ 内存的旗舰机上也能跑，但推理速度明显更慢，如我这个视频效果，适合对质量要求高、不介意等待的场景。

我们认为这只是一个开始

语音待办只是一个切入点。端侧 ASR + 端侧 LLM 的组合，可以做的事情远不止"总结 + 提待办"：

• 会议纪要：长录音 → 分段转写 → 逐段总结 → 生成完整纪要
• 实时翻译：ASR 识别 → LLM 翻译 → 目标语言输出，全程离线
• 语音助手：ASR → LLM 意图识别 → 本地 Action 执行（TinyGarden/MobileActions 就是为此设计的）
• 隐私场景：医疗问诊记录、法律咨询记录——数据绝不能离开设备

当 ASR 和 LLM 都能在手机上离线运行时，"语音 AI"不再等于"云端语音 AI"。

这才是我们觉得最兴奋的地方。

开源吗，后面可能会开源，但是只会在我的小群中