你的上下文是有质量的：数据重力与“计算向数据移动”的回归
Agent 循环在每一轮都会跨越 VPC 和云边界传输数 MB 的上下文，而这笔运费从未出现在模型账单上。为什么 Hadoop 时代的“计算向数据移动”原则正在回归，以及如何审计你推理栈的重力。
GPU 调度是一个排队问题，而不是资源配置问题
LLM 终端响应慢通常是排队失败，而非硬件短缺。了解连续批处理、KV 缓存限制以及 Prefill/Decode 调度如何决定你的尾部延迟 —— 以及为什么增加 GPU 无法解决此问题。
你的编程代理基于落后 Main 分支三周的代码版本重建的代码库索引
当编程代理的语义索引与其工作树发生漂移时，代理会基于已不存在的代码提出自信的主张 —— 而这种失败模式往往隐藏在看似平常的 PR 之中。
KV Cache 驱逐：供应商称其为“缓存压力”，而你的账单则称其为“双倍前缀费用”
Prompt 缓存看起来像是一种配置好的折扣，但在共享 LLM 基础设施上的 KV Cache 驱逐使其变成了一种概率性的折扣 —— 在不更改任何代码的情况下，同一个对话在繁忙时段的成本可能会高出数倍。
供应商将你的模型标识符重定向到特定租户的微调模型，而其他人使用的却是基础模型
如果将 LLM 模型标识符视为权重的名称而非路由决策的标签，那么供应商可能会在评估套件仍保持“绿色”通过状态时，静默地将你的租户从微调模型切换回基础模型，导致客户最先察觉到问题。
被反向代理剥离的 SSE Keep-Alive，以及你支付了两次费用的 Prompt
LLM 流式响应看起来像是从模型到用户的通畅管道 —— 直到一次 35 秒的工具调用导致反向代理断开连接，你的客户端针对无状态 API 重试整个 Prompt，最终用户的账单为同一个响应支付了两次费用。
批处理负载挤占了你的实时路径：GPU 预留的惨痛教训
在夜间训练和晨间推理之间共享同一个 GPU 池看起来是提高了利用率，直到 p99 仪表板揭示了其负外部性的代价。为什么 GPU 分区必须是物理的，资源核算必须遵循延迟类别，以及早晨的尾部延迟问题无法通过软件层面修复。
供应商配额在你的全球流量从未选中的时区重置
供应商配额按照供应商的时间重置，而不是客户的时间。当周期的临界结束点与你的流量峰值时区重叠时，429 错误看起来就像是随机噪声 —— 而 UTC 仪表板掩盖了背后的真相。
你增加的 Reranker：对召回率的拖累超过了对精准度的提升
离线 nDCG 显示你的交叉编码器 Reranker 提升了四个点。但生产环境的 p99 指标显示这是一次倒退。评估标准从未对截止时间、批处理窗口或超时引起的回退路径进行建模 —— 而这个差距正是精准度提升消失的地方。
你的后端基础设施并非为流式响应而设计
流式传输在传输层赢得了用户的信任，但同时也悄然改写了你的负载均衡器、追踪流水线、自动伸缩器和成本模型原本遵循的契约。
按摄入日期分片的向量索引
按摄入日期分片的向量索引隐藏了一个聚合指标无法察觉的召回失败：评估集的采样往往带有与架构本身相同的时间偏差。
那个直到触发时你才察觉的 Token 预算
提供商的 API 会暴露每分钟速率限制响应头，但绝不会透露你的集群实际上需要依此规划的每月上限 —— 这导致消费者必须在第 26 天 429 错误到来之前，自行构建计量器、层级抽象和资源饥饿规则。