选模型只看价格？延迟和吞吐量才是生产环境的瓶颈
很多开发者选AI模型的时候，打开定价页比一下价格就完事了。输入多少、输出多少、折算一下每百万token多少钱，选个最便宜的。但真到生产环境跑起来，用户嫌慢、并发撑不住、长文本截断，这些问题全冒出来了。
价格只是其中一个维度。真正决定用户体验的，是延迟、吞吐量和上下文窗口这三个容易被忽略的指标。
延迟：用户等不等的分界线
延迟分两种。首token延迟（TTFT，Time To First Token）决定用户看到第一个字的等待时间。生成速度（tokens/second）决定后续内容流式输出的快慢。
用户对延迟的容忍度其实很低。根据Akamai 2017年的研究，页面加载时间从1秒增加到3秒，跳出率增加32%。虽然这是网页数据，但对话式AI产品的预期更苛刻。用户发了消息，3秒内没反应就会觉得”是不是挂了”。
不同模型的TTFT差异很大。根据Artificial Analysis 2024年的独立评测，GPT-4o的TTFT中位数约0.5秒，Claude 3.5 Sonnet约0.8秒，而一些托管在GPU上的开源模型可能超过2秒。生成速度方面，GPT-4o约80-100 tokens/秒，Claude 3.5 Sonnet约70-80 tokens/秒。
对于实时聊天场景，TTFT低于1秒是基本要求。对于后台批处理任务，这个指标就不那么关键。选模型之前想清楚你的场景对延迟的敏感度。
吞吐量：并发请求怎么扛
吞吐量指模型同时处理多个请求的能力。这跟API提供商的基础设施直接相关。
OpenAI和Anthropic的API有速率限制。GPT-4o的Tier 1用户每分钟只能发500次请求，Tier 2是5000次。如果你的产品突然来了一波流量，超限的请求直接429错误。用户看到的是”请稍后重试”，然后流失。
应对并发限制有几种思路。最简单的是请求队列，把超出的请求排起来等。但用户等不了太久。更好的方案是多模型路由，主模型限流后自动降级到备用模型。比如GPT-4o限流时切到Claude 3.5 Haiku，速度差不多但不会报错。
自建部署的开源模型吞吐量取决于GPU配置。一张A100大概能同时跑20-30个7B模型的并发请求（vLLM优化下）。成本算下来可能比API便宜，但运维复杂度上去了。
上下文窗口：不是越大越好
现在的趋势是上下文窗口越搞越大。Gemini 1.5 Pro支持100万token，Claude 3.5支持20万，GPT-4o支持12.8万。听起来越大越好，但实际使用中有两个坑。
第一个坑：长上下文的注意力衰减。Needle In A Haystack测试显示，当上下文超过一定长度后，模型对中间位置信息的检索准确率明显下降。Anthropic自己的技术报告也提到，Claude在20万token上下文的中段信息检索准确率比首尾低10%-15%。
第二个坑：成本随上下文线性增长。每次请求都把整个对话历史发过去，token消耗快速膨胀。一个10轮对话，如果每轮平均500 token，到第10轮时单次请求就要处理5000 token的输入。用GPT-4o的话，光输入成本就是0.0125美元/次。100个用户每天聊10轮，月成本就是375美元，还只是输入部分。
所以上下文窗口不是用来塞满的，是个安全边界。实际应该尽量控制上下文长度，用摘要压缩历史对话，只在必要时保留关键信息。
一个实用的选型框架
别一上来就选模型。先回答三个问题。
第一，你的场景对延迟多敏感？实时聊天要求TTFT低于1秒，批处理可以接受10秒以上。这直接排除了部分慢模型。
第二，预估峰值并发量。日活用户数乘以同时在线比例（通常5%-10%），再乘以平均每用户每分钟请求数。如果峰值超过单一模型的速率限制，提前规划多模型路由。
第三，单次请求的实际上下文长度。不是模型支持多少，而是你的业务需要多少。RAG场景通常4K-8K token够用，代码分析可能需要3.2万以上。按实际需求选模型，不要为用不到的上下文窗口付溢价。
回答完这三个问题，再去看价格。这时候你会发现，便宜0.5美元/百万token的模型，如果TTFT慢1秒、并发限制低一半，在生产环境里反而更贵。
成本优化的三个方向
选好模型之后还能继续省钱。
缓存是第一优先。相同问题的回答直接返回缓存结果，不经过模型。Anthropic 2024年推出了Prompt Caching功能，对重复的system prompt和长上下文自动缓存，缓存命中的输入token价格降至原来的十分之一。OpenAI也有类似的缓存机制。
模型降级是第二招。简单问题用小模型，复杂问题才用大模型。用GPT-4o-mini处理80%的日常请求，只有遇到复杂推理才路由到GPT-4o。实际测试中，gpt-4o-mini对常见问答的质量已经够用，成本只有GPT-4o的十五分之一。
第三个方向是压缩prompt。去掉冗余的system prompt描述，精简指令用词。一个500 token的system prompt如果能压缩到200 token，每次请求省60%的输入成本。日积月累很可观。
别让价格成为唯一标准
选模型这件事，价格是显性成本，延迟和吞吐量是隐性成本。隐性成本最后都会变成用户流失率。
先定场景需求，再选模型，最后优化成本。这个顺序别搞反了。
