边缘设备上的文本转语音（TTS）需求正在快速增长，从无障碍阅读助手到车载导航系统，本地化的语音合成能力已成为关键竞争力。然而，传统的 TTS 模型往往体积庞大、算力消耗惊人，难以在移动端或嵌入式设备上实现实时推理。KittenTTS 项目展示了一条在 25MB 以下实现接近 SOTA 语音合成质量的技术路径，其核心思路是将压缩工程与架构设计深度耦合，而非简单地对已有大模型进行事后压缩。本文将从压缩技术选型、架构设计原则和工程落地参数三个层面，梳理边缘设备 TTS 模型压缩的实战要点。
量化是边缘部署中最直接有效的压缩手段。KittenTTS 及同类轻量模型通常将权重从 FP32 压缩至 INT8 或 FP16，在保持语音自然度的前提下将模型体积削减约 50% 至 75%。工程实践中建议采用后训练量化（PTQ）作为快速验证手段，若质量损失可感知，则需切换至量化感知训练（QAT）让模型在训练阶段就适配低精度表示。需要特别注意的是，TTS 的声码器部分对数值精度较为敏感，INT8 量化可能导致高频噪声残留，此时可考虑对声码器单独保留 FP16 或混合精度策略。推理框架层面，主流移动端 GPU/NPU 已对 INT8 提供原生加速支持，配合 NEON（ARM 架构）或 AVX（x86 架构）指令集可进一步释放算力。
剪枝与结构化稀疏是另一条重要的压缩路线。非结构化剪枝虽然理论压缩比更高，但在边缘硬件上往往无法转化为实际的加速收益。KittenTTS 采用了结构化剪枝策略，按通道或注意力头进行裁剪，确保剪枝后的模型仍能充分利用矩阵乘法的硬件加速能力。工程上通常以 30% 至 50% 的剪枝率为起点，通过 MOS（Mean Opinion Score）主观评测或客观指标（如字符错误率 CER）评估质量变化，再逐步调优。若采用知识蒸馏技术，可让剪枝后的小模型模仿原始大模型的中间层输出分布，这种方式在保持语音韵律自然性方面表现尤为突出。
架构层面的轻量化设计是 KittenTTS 区别于简单压缩方案的核心差异。传统 TTS 流水线包含重型的文本分析前端、声学模型和神经声码器三大部分，每一环节都可能成为延迟瓶颈。KittenTTS 采用紧凑的前端模块：基于规则或小型神经网络的图音转换（G2P）引擎通常仅需几百 KB，韵律预测器也控制在 1MB 以内。声学模型部分采用轻量级 Transformer 变体或倒瓶颈（Inverted Bottleneck）卷积块，将参数量压至约 15M。声码器则使用小型神经声码器或参数化声码器（如 WaveRNN 的简化变体），在 3MB 至 5MB 区间内实现实时合成。这种「小前端 + 精中端 + 简后端」的分层设计，确保了各模块的计算负载均衡，避免出现单点瓶颈。
工程落地时需关注三个关键指标：延迟、内存占用和硬件兼容性。延迟方面，边缘 TTS 的端到端延迟目标通常设定在 100ms 以内，其中声码器阶段的原始音频生成占据约 60% 至 70% 的耗时。内存占用需同时考虑模型参数体积和运行时峰值内存，后者可能因注意力机制的中间结果而显著高于静态模型体积，建议在目标设备上进行实际压测。硬件兼容性方面，iOS 设备可利用 Core ML 的量化模型支持，Android 设备推荐通过 NNAPI 调用 DSP/NPU，嵌入式 Linux 则可借助 TensorFlow Lite 或 ONNX Runtime 的轻量推理后端。为确保部署可靠性，建议建立一套自动化回归测试流程，在压缩前后对同一文本集进行合成质量对比，设置 MOS 下降不超过 0.3 分为质量红线。
综合来看，25MB 以下 TTS 模型的压缩路径已趋于成熟：量化提供即时的体积收益，剪枝与知识蒸馏在质量与体积间取得平衡，轻量化架构设计则是长期竞争力的来源。实际项目中建议采用迭代式压缩流程 —— 先确定目标硬件的算力与内存约束，反向推导可接受的模型规模，再选择对应的压缩技术组合进行验证。KittenTTS 的实践表明，在合理的技术选型下，边缘设备完全能够运行高质量的本地语音合成系统，这为下一代离线语音交互应用奠定了工程基础。
资料来源：KittenML/KittenTTS 官方项目页（https://github.com/KittenML/KittenTTS）。