算力存储系列第三篇。前两篇聊了计量和存储，今天聊一个更隐蔽的成本项——带宽（出流量）。它在 AI 应用里的存在感极低，涨起来的速度极快，我见过它超过算力成本的案例，而且当事人几个月都没发现。
为什么 AI 应用的出流量结构不同
传统 Web 应用的出流量 = 页面和图片给用户，量级可控。AI 应用的出流量结构完全不同，三个放大器：
- 生成内容回吐：LLM 生成的长回答、流式输出的每个 chunk、翻译后的整篇文档——这些都是从你的服务出去的流量，而且 AI 生成的内容量常常是用户输入的十倍（输入一页指令，输出十页报告）
- 多端同步：用户在网页看一半、手机接着看——同一份生成内容出流量翻倍
- 导出与分享：PDF 下载、双语对照文件导出——AI 应用的高频动作全是「把大文件发出去」
三个流量黑洞（我们都踩过）
流式输出的心跳包：SSE 长连接的心跳/保活帧如果带数据，一条挂一小时的会话能默默吃掉可观的出流量。心跳帧必须零载荷。
重复生成不缓存：用户对同一篇文档反复翻译/重新生成（改一个词再翻一次），每次都是全新出流量。生成结果的内容寻址缓存（同输入哈希直接回缓存）能砍掉大比例重复流量。
文件直出不过 CDN：生成的 PDF/EPUB 从源站直接给用户下载。静态化+CDN 分发在文件类出流量上的成本差是数量级的——这是最值得做的一项改造。
计量与归因
带宽账的基础还是计量（系列第一篇的原则）：出流量按「产品功能维度」归因——生成回吐、文件下载、流式会话分开记。归因清楚了，上面三个黑洞自然现形：看不清哪个功能在吃流量，就谈不上优化。
结语
AI 应用的成本管理，算力是明面上的大头，但出流量是增长最快的一项——内容生成量的天花板比用户量的天花板高得多。把带宽账拉出来和算力账并排放着看，你的成本地图才算完整。
