Cue 的听写功能有一个润色步骤：它将包含填充词和缺失标点的原始转写文本，转换为读起来符合说话者原意的文本。该步骤在哪里运行是由一次测量决定的，而该测量是公开的。本文遵循 Google DeepMind 的案例研究，数据截至 2026 年 5 月，未添加该页面未说明的任何内容。
最初的设计
该步骤最初设计为使用云端模型，并以本地模型作为备用，其假设是更大的模型能更准确地进行润色。团队为该步骤设定的目标是，让文本读起来像用户本人而不是像模型：恢复标点，切分句子，移除填充词，而不强加一种内部风格。
测量
团队在 227 个真实的语音样本上对该步骤进行了基准测试，涵盖了英语、其他语言和混合语言输入。在该基准测试中，通过 Ollama 在 Apple Silicon 上本地运行的 Gemma 4 E4B 被选为首选模型。润色步骤的延迟中位数从 876 ms 降至 488 ms，该页面称这在团队为该步骤设定的预算之内，即必须感觉比打字更快。
反转
基准测试后，架构被反转：本地模型成为默认选项，云端模型成为备用选项。桌面应用在启动时检查 Ollama 是否正在运行；如果未运行，润色步骤将路由到云端模型，听写功能继续进行。
根据该页面，用户体验有哪些变化
- 在切换前后的四周内，活跃测试用户的平均听写量增加了约 30%；之前只听写短消息的用户开始听写更长的内容。
- 该步骤的边际推理成本降至零，该页面称这就是为什么所有套餐（包括免费套餐）的听写功能都没有限制的原因。
声明的边界
只有润色步骤被转移了。转写是在润色步骤之前由云端语音转文本服务完成的，而 Cue 的智能体模式依赖于云端模型。该页面报告了对 Gemma 4 在独立智能体任务中函数调用能力的早期评估，并称其为早期阶段。因此，我们的主页上说润色在用户设备上运行，但没有提及智能体在本地运行；平台页面记录了同样的边界。