Latency 和 cost，才是 AI 产品上线的真实难点
一句话总结
不是模型能力不够，而是你的账单和延迟在杀死用户体验。不是prompt engineering决定成败，而是工程架构决定了产品能不能活过第一个月。不是"先上线再优化"，而是latency和cost必须在设计第一天就写入PRD的非功能性需求。
适合谁看
这篇文章写给三类人：正在把LLM功能塞进现有产品的PM，发现demo很炫但生产环境跑不动的工程师，以及总觉得"换个大模型就好了"的高管。如果你上周还在用GPT-4做prototype，这周被CTO追问为什么p99延迟到8秒——你就是这个文本的精确目标。
如果你认为"我们先用着，cost不是问题"，你尤其需要往下看。硅谷AI PM的base现在在$130K-$220K，RSU $80K-$300K/四年，bonus 0-20%，但拿这个package的人里，能把latency和cost讲清楚的不到一半。
为什么 demo 和生产环境是两个世界
2023年Q3，某家B轮SaaS公司的产品VP在all-hands上播放了一个customer support agent的demo。CEO当场拍板："下个月上线。
"三个月后，这个agent在production里的p99延迟是12秒，用户留存曲线比baseline还低。不是模型变差了，是demo时用的是OpenAI的turbo endpoint，生产里为了"质量"切到了GPT-4，再加上RAG pipeline的检索、重排序、上下文拼接——每一次调用都在叠加延迟。
这不是个案。我参加过的一个debrief会议上，engineering lead把监控大屏投出来：median latency 2.1秒，p99 11.7秒。PM说"2秒还行吧"，lead打断她："median是缓存命中的，p99是缓存miss走完整pipeline的。
你的用户有20%在走p99。"会议室沉默。这个PM的失误不是技术盲区，是她把demo的happy path当成了生产的guarantee。
不是"模型越聪明越好"，而是"每100ms延迟对应一个转化率漏斗的断裂点"。Netflix在2016年公开过数据：每增加100ms延迟，用户流失率上升1%。LLM产品的阈值更残酷——Anthropic内部测试显示，超过3秒的首次token延迟（TTFT），用户放弃率陡增。这不是"慢一点点"，是"用户已经点了关闭"。
cost的隐蔽性更强。某fintech公司的AI feature，pilot阶段每天$200，full rollout后账单$47,000/天。CFO的slack message在凌晨1点发到产品群："what the fuck is this"。
问题是这个feature的unit economics从未被计算过——不是没人想到，是pilot阶段故意没算，怕算完不敢做。这不是 negligence，是组织层面的 willful blindness。
> 📖 延伸阅读：Google PM H1B抽签费报销值得等吗？价值分析
延迟到底吃掉的是什么
latency分解开来不是单一数字。TTFT（Time To First Token）决定用户是否觉得"它在思考"还是"它卡住了"。inter-token latency决定阅读流畅度。total time决定任务完成率。大多数PM只盯着total time，这是错误的优先级。
一个具体场景：你在做文档总结功能。方案A，流式输出，TTFT 800ms，但每token间隔不稳定，用户看到文字一顿一顿跳。方案B，TTFT 2.5秒，但输出如打字机般平滑。A/B测试里，方案B的完成率高17%。不是用户喜欢等，而是人类对"不确定性"的厌恶超过对"等待"的厌恶。卡顿的流式输出比稳定的延迟更消耗认知资源。
不是"延迟低就够了"，而是"延迟的可预测性比延迟的绝对值更重要"。这解释了为什么pre-computed summary在某些场景击败实时生成——用户宁愿点一下等3秒，也不愿盯着空白屏幕猜0.5秒。
另一个insider场景来自某hiring committee的讨论。候选人在system design面试里设计了一个multi-agent research tool。HC member追问："如果用户问一个复杂问题，三个agent并行，最坏情况延迟多少？"候选人说"大概5秒"。追问："如果第一个agent失败了要retry呢？"候选人愣住。
追问："你的fallback策略是降质还是降级？降质怎么保证用户体验一致性？降级又怎么定义？"候选人没有通过。这个面试的考察点不是让候选人背出所有数字，而是看ta是否理解latency不是feature spec，是系统设计的核心约束。
硅谷AI PM面试现在普遍包含system design轮，重点就是latency/cost tradeoff。典型流程： recruiter screen 15分钟，HM screen 30分钟，product sense 45分钟，system design 45分钟，coding/technical 45分钟（非必须），cross-functional 30分钟。system design轮里，"设计一个LLM-powered feature"的标准预期是：明确token budget、定义SLI/SLO、画出fallback路径。
说不出口的候选，package直接掉一档。base $150K和$180K的区别，往往就在这45分钟。
cost 为什么总是超支，而且超得悄无声息
LLM的pricing模型是token-based，但产品的cost结构是函数式的。输入token、输出token、context window、embedding存储、vector DB查询、重排序服务、缓存命中率——每个变量都是乘法关系。
一个真实对话。某infra PM和finance开会，finance问："这个feature的COGS是多少？"PM说："大概每次调用0.003美元。"finance追问："月度呢？"PM说："日活乘以平均调用次数。
"finance摇头："你的assumption是线性的，但LLM的cost是超线性的。context长了，同样的query更贵；用户发现'好用'之后调用频次翻倍；你下个月加function calling，每次调用额外加20% overhead。"这个PM的模型漏掉了engagement elasticity——用户行为会响应产品变化，而cost模型是静态的。
不是"算出unit cost乘以用量就行"，而是"cost model必须包含用户行为的二阶效应"。这在传统SaaS里不常见，因为SaaS的marginal cost趋近于零，LLM的marginal cost是线性的，而且斜率不固定。
更隐蔽的是storage cost。某AI coding assistant存储了所有用户的code context embedding，最初设计是"提升质量"。六个月后vector DB账单超过LLM调用费用。
团队被迫做aggressive eviction策略，但eviction本身需要计算资源，形成新的cost center。这不是设计失误，是架构选择时只看到收益端、没建模全生命周期cost。
还有一个点：模型的price-performance frontier在移动。GPT-4-turbo发布时比GPT-4便宜60%、快一倍，但你的产品如果locked in在GPT-4的prompt tuning和eval suite，切换cost是多少？某团队算过：重新跑eval需要2个engineer周，prompt迁移需要1周，regression testing需要1周。
按loaded cost算，$15,000的人力投入，需要运行8个月才能从token savings收回。这个计算必须做，但大多数团队不做，因为"先上线"的压力压倒一切。
> 📖 延伸阅读：New RelicAI产品经理岗位职责与面试要点2026
工程架构的决策树，PM 必须参与
很多PM把latency和cost当成"engineering problem"。错误。这些是产品设计约束，和"支持移动端"没有区别。
一个必须参与的决策：streaming vs batch。某content generation tool，PM坚持要streaming"为了用户体验"。engineering lead反对：streaming的infrastructure complexity高30%，而且我们的use case是"用户离开后回来取结果"，不是实时对话。
最终妥协是batch with progress notification。这个决策如果PM不参与，engineering可能直接上streaming——因为"这是标准做法"，而标准做法在这个场景是错的。
不是"PM要懂技术细节"，而是"PM必须能翻译业务价值和技术约束"。具体说，你需要能问出：缓存策略的hit rate target是多少？cache miss的fallback时间预算？降级后的用户体验和原生体验的差异是否在acceptance range？这些不是技术问题，是产品定义问题。
另一个关键决策：model routing。不是每个query都需要最强模型。某客服agent的设计是：先用cheap model分类意图，简单query直接回答（cost $0.0001），复杂query升路由到strong model（cost $0.005）。
这个routing layer的设计是PM和engineering的协作产物，PM定义"简单"和"复杂"的业务标准，engineering实现classifier。没有PM参与，engineering可能用纯技术阈值（如token count）；没有engineering input，PM可能定义无法实现的分类标准。
面试中这个点常被考察。某candidate在system design里提出"所有query走GPT-4以保证质量"。面试官追问cost，candidate说"quality first"。
面试官再问："如果 competitor 用model routing把cost压到你的1/10，定价是你的60%，你的quality premium能支撑多少用户流失？"candidate没有通过。这个考察点的本质是：product decision不是在真空中做，必须考虑competitive dynamics和unit economics的交互。
组织层面的阻力：为什么明知有问题还是不改
延迟和cost问题不是没被看见，是被优先级系统systematically deprioritized。
一个debrief场景。QBR上，data scientist展示了一个A/B test：优化latency从p99 8秒到4秒，转化率提升12%。engineering lead说"需要2个sprint"。CPO说"放Q2吧，Q1要ship new feature"。
Q2来了，同样的对话重复。root cause不是资源不足，是组织的incentive alignment问题：feature ship有visible milestone，latency优化没有；PM的promotion case写"launched X"比"reduced latency by 50%"更有冲击力。
不是"组织短视"，而是"激励结构奖励可见产出，惩罚隐性债务"。这和tech debt同理，但LLM的latency/cost debt accumulation更快，因为模型迭代速度超过代码重构速度。
另一个组织阻力来自"AI Lab"和"Product Engineering"的割裂。某公司的AI Lab负责模型研发和调优，Product Engineering负责上线。Lab的KPI是benchmark score，Engineering的KPI是feature delivery。
Lab把model丢过来时，没有latency target，没有cost budget，只有"这个model在eval set上比上个版本高3个点"。Engineering接过来发现推理延迟翻倍，但"优化模型"不在任何一方的OKR里。这个gap需要PM填补，但多数PM没有这个awareness，或者有这个awareness但没有political capital去推动。
hiring manager的视角：我在面试中会问候选人"描述一个你推动non-feature工作的经历"。希望听到的不是"我发现了问题然后fixed it"，而是"我构建了case，找到了sponsor，改变了优先级"。后者的package可以高一个level。base $160K vs $190K，RSU差$100K，往往就是这个能力的定价。
准备清单
- 在PRD中明确写入latency SLO（如p99 < 2s）和cost budget（如每次user session <$0.05），不是optional，是blocking requirement
- 建立分层的fallback策略：理想模型降级到fast model再降级到cached response，每层定义用户体验差异的可接受范围
- 设计阶段就建模全生命周期cost，包括用户行为变化（engagement elasticity）、模型切换cost、storage eviction cost
- 系统性拆解面试结构（PM面试手册里有完整的AI系统设计和成本建模实战复盘可以参考），特别是system design轮中如何讨论latency/cost tradeoff
- 在团队内建立latency和cost的visible dashboard，和业务metric同等地位，避免"隐性债务"持续累积
- 在面试或晋升case中，准备至少一个"推动non-feature priority"的具体故事，包括你构建的量化case和政治筹码
- 评估每个use case的real-time necessity，对抗性地质疑"为什么必须streaming"或"为什么不能用pre-computation"
常见错误
BAD： "我们的GPT-4 integration延迟有点高，看看能不能优化一下。"
GOOD： "GPT-4的TTFT中位数是1.2s，p99是4.5s。我们的SLO是p99 < 2s。
gap在RAG检索环节，计划用hybrid search把检索从800ms降到200ms，同时评估是否对summary quality有影响。如果优化后仍不达标，fallback到GPT-3.5-turbo的routing threshold从70% confidence调到60%。"
BAD： "先上线，cost后面再优化。"
GOOD： "pilot阶段每天$200，按当前engagement推算full rollout是$18,000/天。我们已经和finance确认过unit economics：ARPU $50，COGS per user per month $3.2，margin健康。
但engagement doubling scenario下COGS会到$6.4，触发我们预设的review threshold，届时启动model routing优化项目。"
BAD： "这个feature用户反馈很好，我们全面推广。"
GOOD： "pilot cohort的NPS +15，但p99延迟8.5秒的用户sub-cohort的NPS是-3。计划把延迟优化作为推广prerequisite，而不是并行进行。推广节奏：延迟<3s的地区先发，8.5s的地区暂缓。"
FAQ
Q：小公司没有infra team，怎么解决latency问题？
不是"等有钱了再优化"，而是"选择约束你的架构"。某5人startup的做法是：product里只集成一个fast endpoint（Claude Haiku级别），所有功能设计围绕这个约束。他们的product是异步workflow tool，用户不期待实时反馈，这个约束反而成为product differentiation——"我们不像其他工具那样给你即时幻觉，我们给你经过验证的结果"。
两年后他们有钱了， architecture演进路径清晰：在关键节点插入stronger model，而不是 retrofit fast path进慢架构。另一个3人团队的做法更激进：完全放弃real-time generation，只做pre-computed content suggestion， latency问题被定义 away。这两个case的共性是：把constraint变成design parameter，而不是technical debt。
Q：怎么向non-technical stakeholder解释为什么要花2个sprint优化latency而不是做新feature？
用他们已经理解的analogy，但不要止于analogy。某PM对CFO说："我们的latency相当于零售店的排队时间。现在顾客平均排2分钟，20%的顾客排12分钟。我们知道排12分钟的顾客里一半会离开。优化不是让店看起来更好，是把已经进店的顾客的转化率提上来。"然后展示数字：当前funnel里，p99用户的conversion rate是1.2%，median用户是4.5%。
如果能把p99拉到和median一样，revenue impact是$X/month，2个sprint的cost是$Y。CFO说"做"。关键是把technical metric翻译成business outcome，而且这个数字必须是你事先算好的，不是现场编的。另一个技巧：把latency优化和某个已承诺的feature挂钩。"Q2的personalization feature需要实时recommendation，这需要sub-second latency，我们现在8秒，gap必须close。"把infra work包装成feature enabler，是组织politics的必要技能。
Q：面试中如何展示对latency和cost的理解？
不是"我了解这些概念"，而是"我在具体场景中做过tradeoff"。一个 strong answer 的结构：situation（什么产品、什么约束）、tradeoff space（有哪些选项、各选项的latency/cost/quality profile）、decision criteria（为什么选这个）、follow-up impact（上线后的实际数据）。例如："我在上一家公司做code review assistant。选项A是每次diff调用GPT-4，quality高但latency 6秒、cost $0.02/次。选项B是先用cheap model分类diff复杂度，简单diff用fast model，complex diff用GPT-4，average latency降到2秒，cost降70%。
我们选了B，quality在complex diff上没有损失，simple diff的slight quality drop通过rule-based post-processing补偿。上线后developer satisfaction 4.2/5，cost在budget内。"如果面试官追问"如果simple diff的quality drop导致用户不信任整个product怎么办"，准备好你的monitoring和rollback策略。这就是$180K base和$220K base candidate的区别：不是知道更多，而是想得更深。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。