做AI生图的团队，十有八九会盯着扩散模型那一步做优化。换个小模型，换种调度策略，省一点GPU租赁费，这没什么不对。但Photoroom内部一查账，发现整条流水线里最贵的，居然不是跑生成用的那几台A100。
Photoroom的产品图生成流程，可以拆成三步：先用一个视觉语言模型看一遍原始商品图，输出结构化的描述文字；第二步让一个大语言模型把用户写的提示改写一遍，改得让扩散模型更好消化；最后才轮到搭载内部精调模型的SDXL在自有A100上出图。他们原本以为，生成这一步会是最大的成本黑洞，结果2024年第一季度的数字显示，Claude和Gemini Vision这两次调用合起来的开销，比同样工作负载下的GPU租赁费还要高。视觉理解和提示改写层，占了推理总支出的58%。
问题出得很隐蔽。团队一直用一个Python服务直接调用模型厂商的接口，没有做任何缓存。同一张产品图、同一个用户请求，重复触发的时候，依然每次都付费重新调用。也就是说，一个月里有大量请求在重复获取一模一样的描述和改写结果，钱就这么悄无声息地流走了。
拿到这个发现之后，团队开始看各种API网关方案。他们先评估了LiteLLM和Portkey。LiteLLM如果放在一个现有FastAPI服务里，属于阻力最小的选择，它的模型供应商覆盖面很不错；Portkey则提供了一个打磨得很精细的托管界面和非常清晰的分析仪表盘。但最终，他们选了Bifrost。这里的取舍，完全取决于团队自己那个有些特殊的部署环境。
Bifrost以Go二进制的方式运行，这样一来，网关进程就不会和同样跑在那台CPU上的Python推理服务争抢GIL，这点对延迟敏感的任务很重要。语义缓存是Bifrost的内建功能，不需要额外拼接。而且它提供了一个兼容OpenAI接口的端点，团队不需要改动任何SDK调用代码，直接把请求打到Gateway上就能复用现有逻辑。当然他们也很坦率地比较了另外两个选项：如果技术栈以Python为主，LiteLLM的生态位会让人更舒服；而Portkey的数据看板，用他们的话说，比Bifrost开箱自带的要漂亮不少。
在Photoroom的部署里，Bifrost作为边车跑在提示改写服务旁边，所有图片描述和提示改写请求都统一打到http://bifrost:8080/v1/chat/completions。配置并不复杂，核心是三个地方。第一是语义缓存的相似度阈值，定在0.94。这个数字不是拍脑袋来的，而是拿5000条真实请求做测试集慢慢调出来的。试过0.97，结果漏掉了太多一眼就能看出来应该复用的重复调用；而降到0.90时，已经开始出现描述相似但颜色错误的结果，这种误差在电商场景里是绝对不能容忍的。第二是预算控制，两个虚拟密钥分别给描述团队和改写团队设置了每月800美元和400美元的硬上限。第三是回落策略，主路线走Anthropic的Claude，备用走Google Vertex的Gemini，这套切换也不是装样子——他们在三月里实测到Anthropic有0.4%的5xx错误率，切换真的会被触发。
上线三周之后，语义缓存把这部分的账单砍掉了大约62%。团队回过头看这件事，最深的感受或许是：算力最密集的那个环节，未必就是成本最密集的那个环节。如果没有逐层查账，很难想到两次看似轻量的接口调用，竟然会比长时间吃GPU的生成过程还要费钱。而一个小的架构调整——把请求从直连改为经过带缓存的网关——就释放出了空间。
回头想，这不只是个技术选择，更是一种提问方式的转换。过去大家围在一起例行做性能剖析的时候，总是默认把跑扩散的GPU看作优化靶心。直到有人问了句，每一步各自花了多少钱，格局才被重新打开。
热门跟贴