适合谁看：资深的嵌入式系统底层专家。技能栈（C、SoC、Bootloader、驱动、系统移植、DSP优化、Cache调优、功耗分析）是芯片设计的核心和基础，具备从硬件（SoC） 到底层固件（ROM Bootloader）再到操作系统层（驱动、RTOS）的全栈知识和实战经验，希望向嵌入式场景的AI部署方向拓展，寻求新的发展空间。
现在的多模态模型的MIMO没有独立。比如输出的语音和文本是一致的，但是呢，真正交互还是需要同时有格式化输出和语音，这时候需要不同的文本和语音。
所以多模态大模型直接使用不能满足需求。替代方案就是只拿文本输出，然后用TTS模型转语音，把原来的一个步骤分成两个阶段。当然这样做似乎会损失一些请求时间，但交互场景的时间约束没有太严格，暂时能用。
深入的话，这是个输出的锁定问题。
1. 问题核心：为什么多模态模型的输出是“锁定的”？
根本原因就是llm是以文本为中心的。模型在训练时，学习的是如何根据多模态输入（文本、图像）生成最合理、最准确的文本序列。语音输出作为一种表达方式而非原生设计的能力。这样思维源头被锁定了，应用层面也没有提供精细化的控制方式，调控文本和语音的内容，只能拿到一个统一源头的输出，交互性还是不太好。
2. 文本输出 + 独立TTS优势
优势
这个方案其实也很经典，主要有三个优势： 1、控制灵活，单一模型的痛点就是控不便，解耦之后可以精细化控制文本和语音的输出内容，文本模型还能做一些格式化的输出，这也为实现交互设计提供了更多空间。 2、成本控制，目前文本模型token价格显著低于多模态模型，而tts技术相对成熟，甚至有效果很好的免费方案，可以压低前期实验的成本。
3、升级便捷，tts模型可选品类也很多，解耦之后可以很方便地升级替换，提升产品体验。
劣势
1、主要劣势就是延迟增加，从一个步骤变成了两个串行步骤：LLM推理 -> TTS推理。这会增加端到端的响应时间。
2、还可能有潜在的信息损失，如果大模型原生支持语音，它可能在生成文本时就已经隐含了适合语音的韵律、停顿和重音信息。而独立的TTS模型需要根据纯文本去重新预测这些副语言信息，效果可能不如端到端生成。
