语音转写成本砍到1/6：一个开发者为何弃用Whisper，把Gemini塞进边缘函数

你的日记应用里，用户对着手机碎碎念，后台要把语音变成文字。这条路径的流量最高，成本公式从第一天就得算清楚。

OpenAI Whisper标价0.006美元/分钟，Deepgram Nova-3压到0.0059美元，Groq的Whisper Large v3 Turbo再砍到0.0008美元。一位开发者没选任何一家——他用Gemini 2.5 Flash多模态模型做到了约0.001美元/分钟，成本只有Whisper的六分之一，而且完全消耗他现有的GCP免费额度。

以下是他的完整实现路径，以及为什么拒绝更" obvious "的选择。

先盘一盘手里有什么

选转写服务商之前，他先检查了已接入的基础设施：

Supabase项目：已有，GEMINI_API_KEY已设为密钥（AI功能在用）

GCP免费额度：同个账单账户下还躺着522美元，正好覆盖Gemini API

OpenAI账户：得新建，得绑卡

Groq账户：同上，还得学一套新API

每新增一家第三方SaaS，都是未来的维护成本：新仪表盘、新密钥轮换、新账单——直到信用卡账单来了才想起来。既然Gemini的密钥已经在手，能搞定语音就是最优默认项。

它能。Gemini 2.5 Flash原生接受音频输入作为多模态部件。现有的AI功能用的generateContent端点，加一个携带音频字节的inline_data部件即可。

为什么不用Web Speech API？

浏览器自带SpeechRecognition API，免费。为什么不用？

三个原因直接否决：

浏览器支持：仅限Chrome和Edge。Firefox未实现，Safari部分支持。日记应用的用户大概率用自己顺手的浏览器，这直接出局。

隐私：Chrome的实现会把音频发到Google服务器。虽然日记内容未必敏感，但"本地录音→远程服务器"这个链条，能多一个环节少一个环节。

可控性：无法干预转写质量。Gemini可以塞系统提示词，可以要求"保留语气词"或"过滤填充词"，Web Speech API给什么就是什么。

边缘函数完整代码

部署在Supabase Edge Function，约50行：

核心逻辑：接收前端传来的音频Blob，转base64，塞进Gemini的多模态请求。模型选gemini-2.5-flash-preview-05-20，温度压到0.3保证转写稳定性。

响应时间：30秒音频约2-3秒返回，Groq级速度，Whisper级质量。

成本对比的隐藏项

标价之外还有账：

Whisper的0.006美元是裸价，加上网络出口、存储临时音频文件，实际更高

Gemini的0.001美元是端到端，音频字节直接进模型，无中间存储

GCP免费额度对独立开发者是真实货币，不是"试用金"

更关键的是账户熵减：少一个供应商，少一套监控，少一个凌晨三点的告警。

什么时候不该这么干

这个方案有明确边界：

需要实时字幕：Gemini不是流式响应，延迟2-3秒可接受，实时会议场景不行

多语言混合：测试发现中英夹杂时，Gemini偶尔漏切语言标记，Whisper更稳

合规硬性要求：某些场景指定要Whisper或特定供应商，没得选

但对"录音→稍后整理"的日记场景，够用、够便宜、够省事。

最后一步

他把这套方案开源了。不是框架，就是一个能复制的边缘函数模板，附带前端录音组件。评论区有人在问：Gemini Pro能不能用？他说能，但Flash够用了，省下的额度够跑一年AI总结功能。

技术选型有时候不是选最好的，是选最不妨碍你睡觉的。