先交代一下背景。我做了 12 年 Java 后端主要做支付中台和高并发系统每天跟 Spring Cloud、MySQL、Redis、K8s 打交道。今年决定做点不一样的事一个人从 0 到 1 做一款手机 App。不指望一夜暴富就是想验证「一个人 端侧 AI」能不能做出一个真正好用的音频工具。1个月后ToneScoop 上架了 App StoreAndroid 版同步开发中。这篇文章记录整个过程中的技术选型和踩坑希望对同样想做端侧 AI 应用的独立开发者有帮助。前阵子做了一款端侧 AI 音频 App把过程中的技术决策和踩坑整理成文。先说结论移动端跑人声分离模型完全可行但工程细节远比想象多尤其是模型参数与推理后端的匹配。下文按「选型 → 架构 → 踩坑」展开。产品是什么ToneScoop 是一个音频工具包核心功能视频转 MP3支持 MP3 / M4A / WAV / FLAC / OGG / AAC / OPUS 七种格式互转AI 人声分离提取伴奏 / 去人声约 3 秒出结果带卡拉 OK 模式可保留少量引导人声铃声制作一键生成 iPhone 的 m4r 格式裁剪拼接、RNNoise 智能降噪、10 段均衡器、变声器效果链把「降噪 → EQ → 增益」存成工作流批量转换一键复用所有处理都在手机本地完成文件不出设备不联网也能用。核心决策为什么坚持端侧做音频处理 App第一反应是接云端 AI上传文件 → GPU 推理 → 下载结果。但作为一个没有融资的个人开发者我算了一笔账服务器成本云端 GPU 推理按量收费个人开发者扛不住自建 GPU 服务器更不现实。排队体验云端方案普遍要排队一首歌传上去等半天体验很差。隐私音频是私密数据「文件不出手机」是天然的信任加分项也是和竞品最直观的差异。结论全部本地推理。剩下唯一的问题——手机芯片到底跑不跑得动人声分离技术选型人声分离模型Demucs vs SpleeterDemucsMeta 出品音质最好但模型大、手机端推理太慢交互式使用不现实。SpleeterDeezer 开源久经考验2stems 在卡拉 OK / 粗分轨场景质量够用两个 ONNX 文件各约 37MB可以直接打进 App 安装包。我选了 Spleeter 2stems人声 / 伴奏两分轨。没上 4stems——移动端算力预算下不划算。推理运行时ONNX Runtime vs TFLite vs Core MLTensorFlow Lite 转 Spleeter 计算图很痛苦自定义算子多。Core ML 绑死 Apple 生态Android 要另搞一套。ONNX Runtime一套模型双端复用iOS / Android有移动端优化和量化支持同一个 .onnx 文件桌面端手机端都能跑调试效率高。最终选 ONNX Runtime。模型精度int8 → fp16 → fp32 的回归量化是典型的坑。int8 量化后体积减半但分离质量明显劣化——人声残留、高频伪影而且这类劣化很难用指标评估只能一条条歌试听对比。试了几轮后我放弃量化直接用 fp32 原始训练精度两个文件共 74MB对现代手机完全可接受换来零质量损失。推理加速iOS 用 Core ML EPA13 及以上走神经引擎Android 用 NNAPI不可用时自动回退 CPU。架构设计Flutter 跨端 ffmpeg 做音频处理 ONNX Runtime 做 AI 推理UI (Flutter) │ ├── ffmpeg_builder.dart 纯 Dart 命令构建层无 Flutter 依赖可单测 │ └── ffmpeg_service.dart 平台通道封装iOS/Android 原生执行 │ └── onnx_runtime 模型推理CoreML EP / NNAPI / CPU 回退一个值得说的设计ffmpeg 命令构建层用纯 Dart 写、不带 Flutter 依赖所有命令组合都能单测——「裁剪 30 秒 淡入淡出 转 m4r」这类组合命令靠单测保证不写错参数。ffmpeg 的坑太多参数顺序、seek 精度、声道重映射一个不对整条链路就废。踩坑记录1. STFT 参数必须与训练时完全一致最耗时Spleeter 对 STFT 参数极其敏感帧长、hop、窗函数、center 设置必须与训练时一致否则模型能跑、输出也有声音但结果是「微妙地错」——音长漂移、warbling 伪影。这个 bug 最难查模型不报错只能按官方实现逐参数核对n_fft4096、hop1024、75% 重叠、周期 hann 窗、centerFalse再和桌面端参考实现逐样本对比才定位。2. 量化回归难发现见选型部分。教训端侧模型量化后必须做听感回归SNR 之类的指标好看不代表听感没问题。3. 冷启动慢App 启动后第一次分离要加载模型明显卡顿。解法短缓冲预热推理把模型加载挪到后台用户感知的首次分离时间大幅下降。4. iOS / Android 结果不完全一致同一个 ONNX 图在不同后端CoreML / NNAPI输出有细微差异。对工具类 App 可接受但别指望双端 bit-identical自动化测试要按后端分开设阈值。5. ffmpeg seek 与时间轴错位ffmpeg 输出流 seek 会导致淡入淡出afade时间轴错位——试听前半段静音甚至闪退。修法先精确定位输入再做时间轴相关滤镜不依赖 seek 后的流内时间戳。商业化0 服务器成本的独立开发者模式因为全部端侧服务器成本为 0。商业模式是 Freemium免费下载广告 每日转换额度Pro解锁无限转换 去广告付费形态周/年订阅 一次性买断无强制订阅买断制对独立开发者是长期主义用户买断一次之后每次更新都是纯增量没有「不续费就变废」的割裂感。一点感受从立项到 App Store 上架约 1个月Flutter 一套代码双端开发。最大的感受端侧 AI 的体验优势秒出、离线、隐私是用户真实感知得到的卖点而「不花服务器钱」是独立开发者最大的护城河。App 免费下载App Store 搜「ToneScoop」欢迎同行在评论区交流端侧推理、音频处理的问题。
先交代一下背景。我做了 12 年 Java 后端主要做支付中台和高并发系统每天跟 Spring Cloud、MySQL、Redis、K8s 打交道。今年决定做点不一样的事一个人从 0 到 1 做一款手机 App。不指望一夜暴富就是想验证「一个人 端侧 AI」能不能做出一个真正好用的音频工具。1个月后ToneScoop 上架了 App StoreAndroid 版同步开发中。这篇文章记录整个过程中的技术选型和踩坑希望对同样想做端侧 AI 应用的独立开发者有帮助。前阵子做了一款端侧 AI 音频 App把过程中的技术决策和踩坑整理成文。先说结论移动端跑人声分离模型完全可行但工程细节远比想象多尤其是模型参数与推理后端的匹配。下文按「选型 → 架构 → 踩坑」展开。产品是什么ToneScoop 是一个音频工具包核心功能视频转 MP3支持 MP3 / M4A / WAV / FLAC / OGG / AAC / OPUS 七种格式互转AI 人声分离提取伴奏 / 去人声约 3 秒出结果带卡拉 OK 模式可保留少量引导人声铃声制作一键生成 iPhone 的 m4r 格式裁剪拼接、RNNoise 智能降噪、10 段均衡器、变声器效果链把「降噪 → EQ → 增益」存成工作流批量转换一键复用所有处理都在手机本地完成文件不出设备不联网也能用。核心决策为什么坚持端侧做音频处理 App第一反应是接云端 AI上传文件 → GPU 推理 → 下载结果。但作为一个没有融资的个人开发者我算了一笔账服务器成本云端 GPU 推理按量收费个人开发者扛不住自建 GPU 服务器更不现实。排队体验云端方案普遍要排队一首歌传上去等半天体验很差。隐私音频是私密数据「文件不出手机」是天然的信任加分项也是和竞品最直观的差异。结论全部本地推理。剩下唯一的问题——手机芯片到底跑不跑得动人声分离技术选型人声分离模型Demucs vs SpleeterDemucsMeta 出品音质最好但模型大、手机端推理太慢交互式使用不现实。SpleeterDeezer 开源久经考验2stems 在卡拉 OK / 粗分轨场景质量够用两个 ONNX 文件各约 37MB可以直接打进 App 安装包。我选了 Spleeter 2stems人声 / 伴奏两分轨。没上 4stems——移动端算力预算下不划算。推理运行时ONNX Runtime vs TFLite vs Core MLTensorFlow Lite 转 Spleeter 计算图很痛苦自定义算子多。Core ML 绑死 Apple 生态Android 要另搞一套。ONNX Runtime一套模型双端复用iOS / Android有移动端优化和量化支持同一个 .onnx 文件桌面端手机端都能跑调试效率高。最终选 ONNX Runtime。模型精度int8 → fp16 → fp32 的回归量化是典型的坑。int8 量化后体积减半但分离质量明显劣化——人声残留、高频伪影而且这类劣化很难用指标评估只能一条条歌试听对比。试了几轮后我放弃量化直接用 fp32 原始训练精度两个文件共 74MB对现代手机完全可接受换来零质量损失。推理加速iOS 用 Core ML EPA13 及以上走神经引擎Android 用 NNAPI不可用时自动回退 CPU。架构设计Flutter 跨端 ffmpeg 做音频处理 ONNX Runtime 做 AI 推理UI (Flutter) │ ├── ffmpeg_builder.dart 纯 Dart 命令构建层无 Flutter 依赖可单测 │ └── ffmpeg_service.dart 平台通道封装iOS/Android 原生执行 │ └── onnx_runtime 模型推理CoreML EP / NNAPI / CPU 回退一个值得说的设计ffmpeg 命令构建层用纯 Dart 写、不带 Flutter 依赖所有命令组合都能单测——「裁剪 30 秒 淡入淡出 转 m4r」这类组合命令靠单测保证不写错参数。ffmpeg 的坑太多参数顺序、seek 精度、声道重映射一个不对整条链路就废。踩坑记录1. STFT 参数必须与训练时完全一致最耗时Spleeter 对 STFT 参数极其敏感帧长、hop、窗函数、center 设置必须与训练时一致否则模型能跑、输出也有声音但结果是「微妙地错」——音长漂移、warbling 伪影。这个 bug 最难查模型不报错只能按官方实现逐参数核对n_fft4096、hop1024、75% 重叠、周期 hann 窗、centerFalse再和桌面端参考实现逐样本对比才定位。2. 量化回归难发现见选型部分。教训端侧模型量化后必须做听感回归SNR 之类的指标好看不代表听感没问题。3. 冷启动慢App 启动后第一次分离要加载模型明显卡顿。解法短缓冲预热推理把模型加载挪到后台用户感知的首次分离时间大幅下降。4. iOS / Android 结果不完全一致同一个 ONNX 图在不同后端CoreML / NNAPI输出有细微差异。对工具类 App 可接受但别指望双端 bit-identical自动化测试要按后端分开设阈值。5. ffmpeg seek 与时间轴错位ffmpeg 输出流 seek 会导致淡入淡出afade时间轴错位——试听前半段静音甚至闪退。修法先精确定位输入再做时间轴相关滤镜不依赖 seek 后的流内时间戳。商业化0 服务器成本的独立开发者模式因为全部端侧服务器成本为 0。商业模式是 Freemium免费下载广告 每日转换额度Pro解锁无限转换 去广告付费形态周/年订阅 一次性买断无强制订阅买断制对独立开发者是长期主义用户买断一次之后每次更新都是纯增量没有「不续费就变废」的割裂感。一点感受从立项到 App Store 上架约 1个月Flutter 一套代码双端开发。最大的感受端侧 AI 的体验优势秒出、离线、隐私是用户真实感知得到的卖点而「不花服务器钱」是独立开发者最大的护城河。App 免费下载App Store 搜「ToneScoop」欢迎同行在评论区交流端侧推理、音频处理的问题。
