AI 应用的多级缓存架构 2026：从精确匹配到语义去重的闭环

一、问题的提出：LLM 应用的成本与延迟困境

截至 2026 年 7 月,生产级 LLM 应用的"token 成本 + P99 延迟"已经成为悬在产品头上的两把刀。以中等规模 RAG 应用为例,单次端到端请求平均消耗 4500 token(其中 prompt 3200 + completion 1300),按 GPT-4o 当前公开定价折算单次成本约 0.022 美元,日均 100 万请求的 RAG 应用月度账单超过 6.6 万美元;而 P99 延迟在向量检索 + LLM 生成的双段组合下普遍落在 2.8-4.2 秒区间,远高于人类对话回合的 800 毫秒舒适阈值。绝大多数团队的本能反应是"换更便宜的模型"或"换更小的向量库",但 2026 年中期的行业实测数据显示,这两条路径的边际收益已经快速衰减:小模型的工具调用成功率普遍跌至 78% 以下,而向量库的检索召回率已经接近 95% 的物理上限。

真正被系统性低估的是请求级冗余。在生产环境的真实流量中,典型的 B2B SaaS AI 应用存在 30-55% 的语义级重复请求——同一用户在不同时刻用不同措辞问"我们公司年假几天",两个 Copilot 智能问答场景在 prompt 模板 + 检索上下文完全相同的情况下却发起两次完整的 LLM 调用;同一个 RAG 应用在同一小时的"产品功能对比"高峰期内,来自不同用户的 18% 请求是结构等价的(SQL AST 同构,只是参数取值不同)。这些冗余在推理服务层是不可见的(每次请求的 prefix 不一样),但在应用层是可去重的。把这一层冗余压下来,就是多级缓存架构的核心命题。

本文从精确匹配层、语义级层、检索结果层、模板片段层四个维度系统化拆解 AI 应用的多级缓存架构,给出命中率工程、布隆预过滤、stampede 防御、生产观测四条闭环链路,最后给出一份可直接落地的缓存选型清单。

二、形式化:多级缓存的分类学与一致性协议

多级缓存架构在数据库领域有成熟的形式化(Buffer Pool + WAL + LRU-K),但 LLM 应用的"缓存"语义远比数据库行缓存复杂:键空间不是预定义的、命中率不与"数据新鲜度"强相关、失效事件往往由业务侧触发而非 TTL 单一驱动。我们先把四层缓存的语义边界抽象清楚。

L1 精确匹配缓存(Exact Match)对应"prompt 字节流完全一致"的请求去重。键空间是 (model, messages[], tools[], temperature, response_format) 的 SHA-256 哈希。命中率在 Chatbot 场景通常只有 5-12%,因为用户极少复制粘贴相同的对话回合;但在 agent tool 编排场景(同一决策路径多次回放)可冲到 25-40%。L1 的命中成本是纳秒级的 Redis GET,收益是直接跳过 LLM 调用节省 100% 的 token 与生成时间。

L2 语义级缓存(Semantic Cache)对应"问题意图等价但表述不同"的请求去重。键空间是用户 query 的 embedding 向量(通常 1024-3072 维),查询时取 L2 距离或 cosine 距离小于阈值 τ 的最近邻(τ 通常取 0.85-0.92)。命中率在客服/FAQ 场景可冲 35-55%,在开放式 Copilot 场景约 12-22%。L2 命中后返回的是 L1 缓存的 response + 原始 prompt hash 的双键索引,需要额外的失效广播机制保证上游 prompt 模板更新时及时清除。L2 的额外成本是 embedding 调用(约 8-30 ms)+ 向量检索(约 5-15 ms),远低于 LLM 调用的 800-2000 ms,但要警惕 embedding 模型的版本漂移——切换 embedding 模型等价于缓存全失效。

L3 检索结果缓存(Retrieval Cache)对应"RAG 中间产物复用"。键空间是 (query_hash, retriever_version, top_k, reranker_version, corpus_version) 的复合键。命中条件比 L2 严格:不仅 query 语义等价,检索配置与语料版本也要一致。在企业知识库场景(语料周级更新),命中率可达 40-65%,因为同一文档在 7 天内被 600+ 用户反复查询是常态。L3 的成本是向量检索 + 必要的重排(累计 50-120 ms),但跳过的是 1000-2000 token 的 context 拼装 + 后续 LLM 调用。L3 最大的工程陷阱是 corpus 版本漂移:必须把语料快照(commit hash + 索引快照)作为缓存键的一部分,否则"看似命中但答案过期"会导致严重的合规风险。

L4 模板片段缓存(Template Slot Cache)对应"动态 prompt 模板中可复用的静态片段"。键空间是模板片段的 SHA-256 + 版本号。在 RAG 应用中,system prompt + few-shot example + 工具定义合计约占 prompt token 的 35-55%,但每轮对话都不变;真正每轮变的是用户 query + 检索结果 + 历史 message。这部分静态片段不必每轮重新拼装,可走模板片段缓存(实质是 prefix caching,但在应用层而非推理服务层实现)。L4 命中率天然是 100%(只要 prompt 模板不变),收益是 prompt 拼装的 CPU 成本降低 40-60% + prompt 版本化的回滚能力。

四层缓存不是"或"的关系而是"与"的关系——L1 命中直接 return;L1 未命中但 L2 命中 return L1 写入;L2 未命中但 L3 命中跳过检索;L3 未命中但 L4 命中加速 prompt 拼装;全未命中才走完整链路。理论最大收益是 LLM 调用次数压降至原始的 30-50%,P99 延迟压降 40-70%,月度成本节省 35-65%。

三、L1 精确匹配缓存:Prompt Prefix 与 KV 复用的边界

L1 看似简单(就是个 key-value 缓存),但实际生产中有三个常被忽略的细节:键定义、写入策略、TTL 策略。

键定义的关键不是 hash 什么,而是不 hash 什么。一个常见错误是把 user_id 纳入键空间,导致每个用户的相同问题都是不同键,命中率降到 1-3%。正确做法是只对真正决定 LLM 输出的字段做哈希:messages、tools、temperature、response_format、模型名。user_id 只应作为缓存隔离的"前缀命名空间",而不是键本身。另一个常见错误是 hash 时把 timestamp / request_id 之类的请求级元数据混进去,等价于永远不命中。

写入策略有"先写后读"与"延迟回填"两种。先写后读在 LLM 响应到达后立即写入缓存,适合同步请求链路;延迟回填是异步批量写入,适合高并发场景下的"读优先"模式(避免 LLM 调用阻塞在写缓存上)。生产实测显示,先写后读在 95% 场景下命中率与延迟回填持平但代码更简单,推荐默认走先写后读。

TTL 策略不能只用单一过期时间。L1 缓存应该支持三类 TTL:(a) 绝对过期(默认 24h,防止存量答案在模型升级后变成"过期真相");(b) 滑动过期(命中后重置 TTL,适合 chatbot 长尾对话);(c) 主动失效(业务侧主动调用 cache.del(key),适合 prompt 模板更新/工具定义变化)。Redis 7.0+ 的 EXPIRE + GETEX + Lua 原子脚本可以同时实现这三种语义。

L1 与推理服务层的 KV 复用(pitfall #92 早间 id=470 主题)看似重叠,但本质完全不同:KV 复用是同一 prompt 不同 batch 共享 attention 计算(推理服务层优化,跳过的是 GPU forward pass);L1 缓存是完全跳过 LLM 调用(应用层优化,跳过的是整个 HTTP 请求)。两者在生产中互补:L1 在 LLM 调用前决策,K1(KV 复用)在 LLM 调用内决策;L1 的命中率不依赖于 prefix 完全相同,K1 的命中率强依赖 prefix 完全相同。生产架构应该把 L1 命中率作为"应用层节省"指标,K1 命中率作为"推理层节省"指标,分别观测。

四、L2 语义级缓存:向量索引、相似度阈值与失效广播

L2 是 LLM 应用缓存架构中最具技术含量的一层,也是最容易出工程事故的一层。核心难点有三个:相似度阈值 τ 如何定、命中答案的合法性如何保证、缓存失效如何广播。

相似度阈值 τ 是 L2 命中率的"旋钮"。τ 越大,误判(把不相似的 query 视为相似)概率越低,但命中率也越低;τ 越小,命中率越高,但误判率上升。生产经验值:客服 FAQ 场景 τ=0.88(高安全阈值,误判容忍度低);开放 Copilot 场景 τ=0.85(中等阈值);数据分析 agent 场景 τ=0.92(极高阈值,任何含糊都视为不同)。τ 的选择不是技术决策而是产品决策:它定义了"AI 应用什么时候敢于说'这个问题别人问过,答案可能也适用'"。

命中答案的合法性有三层保障。第一层是 embedding 模型版本锁:同一 query 嵌入必须用同一 embedding 模型,否则相似度无意义——必须把 embedding_model_version 作为缓存键的一部分(类似 L3 的 corpus version)。第二层是 prompt 模板版本锁:L2 缓存的 response 是基于某个特定 prompt 模板生成的,prompt 模板更新时所有 L2 缓存应该被批量失效(用 cache.del_pattern('prompt_v2_*'))。第三层是回退策略:L2 命中后不应该直接返回原 response,而应该返回 (original_query, original_response, similarity_score),让应用层决定是否使用——比如"相似度 0.91 但用户 query 含敏感词"就应该放弃命中走 LLM。

失效广播是 L2 最容易翻车的环节。L1 缓存失效靠"重置该 key 即可";L2 缓存失效必须广播给所有持有该语义键的 entry——而 L2 的"键"是连续的 embedding 空间,无法枚举。最务实的做法是版本号前缀:每次 prompt 模板更新/embedding 模型切换/LLM 模型升级时,把所有 L2 缓存条目按版本号分组,批量清除旧版本。这种"组失效"是 80% L2 事故的根因。

生产中常见的 L2 实现有三类:(a) GPTCache(阿里开源,基于 Faiss + SQLite,适合中小流量);(b) Redis + pgvector + 自研索引器(适合已有 PG 栈的团队);(c) 专用向量缓存(比如 Pinecone Serverless + Redis 双层)。三类实现在 2026 年 7 月时点的性能差距已经很小,选型的关键不是性能而是与现有数据栈的契合度。

五、L3 检索结果缓存:RAG 中间产物复用与版本感知

L3 是 RAG 应用特有的缓存层,也是 2026 年 RAG 架构讨论中被反复强调的"隐性成本杀手"。一个典型的 RAG 请求链路:用户 query → query rewrite → embedding → 向量检索(返回 top-50)→ rerank(返回 top-5)→ context 拼装 → LLM 生成。其中向量检索 + rerank 合计耗时 80-150 ms,context 拼装 + LLM 生成 800-2000 ms,合计 900-2150 ms。在企业知识库(语料 5-50 万 chunk,周级更新)中,30-60% 的查询在 7 天内会被重复发起(同部门同事问同主题、相同 SOP 查询、相同产品参数查询),但每次都重跑 embedding + 检索 + rerank 是极大的浪费。

L3 的实现核心是检索结果快照(Retrieval Snapshot):把 (query, retriever_version, top_k, reranker_version, corpus_version) 五元组的哈希作为 key,value 是 top-k chunk ID 列表 + chunk 内容快照 + rerank score 数组。命中条件是五元组完全一致——任何一项变化都视为新 key。这种"严格键"的设计牺牲了"语义命中"的机会(同一问题但用不同 reranker 应该视为不同缓存),但换来了"零幻觉"的命中——返回的 chunk 一定是当下检索配置下的真实结果,不存在"看似命中但答案过期"的合规风险。

Corpus 版本感知是 L3 的灵魂。每次语料更新(新文档入库、删除过期文档、chunker 升级)必须生成新的 corpus_version(基于 commit hash + 索引时间戳 + chunker version),旧 corpus_version 的 L3 缓存全部失效。这个过程在生产中往往被简化成"全量重建"——所有 L3 缓存清空,新请求重新走完整链路——简单粗暴但浪费。优雅的做法是"双写期"策略:corpus 切换时同时维护旧版与新版 L3 缓存 5-15 分钟,让读请求平滑迁移;迁移结束后批量删除旧版。

L3 的工程陷阱是"reranker 升级陷阱"。一次看似无害的 reranker 模型升级(bge-reranker-v2-m3 → bge-reranker-v2.5-gemma)会让 rerank 分数分布整体偏移,旧缓存中的 top-k chunk 顺序可能不再最优。如果 L3 直接返回旧 chunk 顺序(走 LLM),可能给出"看似正确但 rerank 后被淘汰"的低质量 context。生产中应该把 reranker_version 作为 L3 键的一部分,reranker 升级时 L3 缓存批量失效,这是 15% 团队会忽略的工程债务。

L3 的命中率在企业知识库场景可冲 40-65%,在客服 RAG 场景约 25-40%,在开放域 Copilot 场景 < 10%。即使 L3 命中率只有 25%,节省的也是单次最贵的 1000-2000 token context 拼装 + 后续 LLM 调用,经济收益巨大。

六、L4 模板片段缓存:动态插槽、片段拼接与回填

L4 是最少被讨论但实际节省最大的一层。在 RAG/Agent 应用中,每次 LLM 调用的 prompt 由三部分构成:(a) system prompt + few-shot examples + 工具定义(占 35-55%,几乎不变);(b) 历史 message + 当前 user query(占 25-40%,每轮变);(c) 检索结果/工具输出(占 20-35%,每请求变)。第 (a) 部分在 1000 轮对话中是同一个文本块,完全可以缓存到 Redis + hash 引用;第 (b) 和 (c) 部分每轮/每请求生成。

L4 的实现核心是"动态插槽"(Dynamic Slot)。把 prompt 模板抽象成带占位符的文本:

<system v3.2>你是一个企业知识库助手,根据以下上下文回答用户问题。
[CONTEXT_BLOCK]
[FEW_SHOT_EXAMPLES]
[TOOL_DEFINITIONS]
历史对话:
[CONVERSATION_HISTORY]
用户当前问题: [USER_QUERY]

其中 <system v3.2>、[FEW_SHOT_EXAMPLES]、[TOOL_DEFINITIONS] 是静态片段,走 L4 缓存(键 = 版本号 + 内容 hash);[CONTEXT_BLOCK]、[CONVERSATION_HISTORY]、[USER_QUERY] 是动态插槽,每请求从 L3 缓存/会话存储/用户输入读取。最后一步是把静态片段 + 动态插槽拼装成完整 prompt。

L4 的工程收益是双重的。第一重是 CPU 成本降低 40-60%:不再每轮重新拼装 system prompt(1000 轮对话从拼装 1000 次降到 1 次,等效 CPU 节省 99.9%);第二重是prompt 版本化的天然支持——每次 prompt 模板更新只需要重写 L4 缓存键,旧对话不会引用过期 system prompt,且可支持"回滚到 3.1 版本"的灰度能力。

L4 与 vLLM/SGLang 的 prefix caching(pitfall #92 早间 id=470 主题)在生产中互补不冲突。L4 在应用层决定"哪些 token 是静态 prefix"并预先 hash 引用;prefix caching 在推理服务层决定"如何把已计算的 KV block 复用到下一轮 prompt"。L4 的命中率与 prompt 模板版本相关(只要版本不变就是 100%),prefix caching 的命中率与 batch 内 prompt 重叠度相关。生产架构应该把 L4 命中率作为"应用层 prompt 复用"指标,prefix caching 命中率作为"推理层 token 复用"指标,两者相加才是完整的复用效率。

L4 最大的工程陷阱是模板版本号管理。手动维护 system_v3.2.md 这种版本号容易出错,推荐用 Git LFS 存储 prompt 模板 + CI/CD 自动 build 版本号 + 发布时版本号自动写入 L4 缓存键。

七、命中率工程:从布隆过滤器、嵌入模型到 TTL 衰减

四层缓存搭起来容易,真正决定收益的是命中率工程——同样的缓存容量,命中率从 30% 提到 50% 等效于缓存容量翻倍。命中率工程有三条主线:键空间优化、查询优化、容量优化。

键空间优化的核心是"哪些字段进键、哪些不进"。一个常见反模式是把 request_id / timestamp 进键,导致永远不命中;另一个反模式是忽略 case-sensitivity(英文 query 的大小写归一化、标点归一化、Unicode NFKC 归一化)导致"语义等价但字面不同"的请求无法命中 L1。生产中应该把"键归一化层"独立成中间件,对 query 做 lowercase + NFKC + 标点压缩 + 空白压缩,然后再 hash 进键空间。

查询优化的核心是 L2 语义查询的"两阶段过滤"——先用布隆过滤器(Bloom Filter)粗筛 1% 的候选条目,再用向量检索精排。布隆过滤器的误判率公式是 $P_{\text{false}} \approx (1-e^{-kn/m})^k$,其中 $k$ 是哈希函数个数、$m$ 是位数组大小、$n$ 是条目数。当 $k=\ln 2 \cdot m/n$ 时误判率最低(约 0.618 的幂次)。生产中常见配置: $m=10n$, $k=7$, 误判率约 0.8%, 内存开销仅 10 字节/条目。一百万条 L2 缓存配 10 MB 布隆过滤器 + 5-15 ms 的查询开销,可让 L2 检索的 P99 从 50 ms 降到 12 ms。

容量优化的核心是"LRU-K + TTL 衰减"。纯 LRU 在热点请求上表现优秀但对长尾请求不友好——一个偶发的长尾 query 占据了缓存位置,在 LRU 优先级上超过了一个未来 1 小时内会出现 50 次的中频 query。LRU-K(记录每个 key 最近 K 次访问时间)能更好识别"高频 vs 偶发"。TTL 衰减则用于"陈旧答案退役"——一个 30 天前的 L1 缓存即便命中也应该在衰减窗口后被强制失效,避免 LLM 模型升级后给出"已淘汰答案"。

自适应 TTL(Adaptive TTL)是高阶命中率工程的核心:根据 query 类别动态调整 TTL。客服 FAQ 类 query TTL 可拉长到 7 天(答案稳定);实时数据类 query TTL 缩到 1 小时(数据更新快);工具调用类 query TTL 0 秒(每次必须执行)。生产中常用 query 分类器(轻量级 BERT, ~5 ms)做类别判定,然后走不同的 TTL 策略。

负缓存(Negative Cache)是另一个常被忽略的命中率提升点。LLM 调用失败的 query(超时、rate limit、内容过滤触发)应该被负缓存 30-60 秒,防止短时间内重试导致雪崩。负缓存的键是 (query, error_type),命中时直接返回"暂时不可用"给用户,不触发 LLM 调用。这条优化在生产事故中能减少 30-50% 的雪崩放大。

八、生产闭环:命中率观测、成本归因、缓存击穿防御

四层缓存搭起来 + 命中率工程优化到 50% 之后,真正的工程挑战是生产观测与事故防御。生产观测的三条主指标、四类告警、两类成本归因,是 LLM 应用多级缓存能否真正发挥价值的最后一道关。

三条主指标:四层缓存各自的命中率、缓存命中后的 P99 延迟、缓存失效广播的延迟。任何一条异常都意味着某一层缓存正在偏离设计目标——比如 L2 命中率突然从 45% 跌到 20%,通常是 embedding 模型升级或 corpus 大幅更新;L1 命中率从 12% 跌到 3%,通常是 prompt 模板里有随机字段进了键。

四类告警:(a) 命中率跌出历史 P10 阈值(全局异常);(b) 单个 prompt 模板的命中率异常(局部异常);(c) 缓存击穿告警(同一 key 在 1 秒内被请求 100+ 次,见下文);(d) 负缓存命中数(失败请求的请求频率)。这四类告警是 SRE 仪表盘的必备项。

两类成本归因:一类是"节省成本"(L1+L2+L3 命中跳过的 LLM 调用次数 × 单次成本),一类是"额外成本"(布隆过滤器查询、向量检索、缓存写入)。生产中真正应该被观测的不是"命中率"而是"净节省"——一个 L2 命中率 60% 但向量检索开销 40% 的方案,净节省可能不如 L2 命中率 35% + 向量检索开销 8% 的方案。净节省 = (命中率 × 单次 LLM 成本) - (查询开销 + 写入开销 + 失效开销)。

缓存击穿(Cache Stampede)是 LLM 应用缓存架构中最危险的事故。当一个热点 key 过期瞬间,大量并发请求同时击穿到 LLM(因为没人在 cache miss 时主动重建),可能触发 LLM rate limit + 雪崩 + 长尾延迟激增三连击。生产中常见的三层防御:

第一层是singleflight(Go singleflight / Python asyncio.Lock):同一 key 在过期瞬间只有第一个请求去 LLM 重建,其他请求等待该请求完成后复用结果。这是 90% 场景的最低成本解。

第二层是early refresh(提前异步刷新):缓存条目在过期前 20% TTL 时异步触发刷新,新请求继续读旧条目(允许短暂 stale),刷新完成后切换。这是热点 key 的标配防御。

第三层是request coalescing(请求合并):同一 key 在 100 ms 内的所有请求合并为一次 LLM 调用,其他请求等待。这是极端热点 key 的终极防御,但实现复杂度较高,只在 P99 < 50 ms 的强约束场景下才用。

生产中应该三层叠加:singleflight 永远在,early refresh 应对已知热点,request coalescing 仅在最极端场景启用。任何一层缺失都可能在 30-60 分钟内导致一次生产事故。

九、给 AI 应用架构师的缓存选型清单

最后给出一份可直接落地的多级缓存选型清单,供 AI 应用架构师在 2026 年下半年新项目 / 现有项目改造时参考。

L1 精确匹配:Redis 7.0+ 主从集群,键归一化中间件(NFKC + lowercase + 标点压缩),TTL 默认 24h + 滑动过期 7d + 主动失效接口。先写后读策略,命中率目标 5-15%。

L2 语义级:GPTCache 或 Redis + pgvector,布隆过滤器预过滤( $m=10n$ , $k=7$ ),similarity threshold τ 按场景调(客服 0.88 / Copilot 0.85 / 数据分析 0.92),prompt 版本号前缀做组失效,embedding 模型版本锁,回退策略返回 (original_query, original_response, similarity_score)。命中率目标 25-50%。

L3 检索结果:Redis 主从 + 五元组键( query_hash + retriever_version + top_k + reranker_version + corpus_version ),corpus_version 用 commit hash + 索引时间戳,reranker 升级时批量失效,双写期策略 5-15 分钟。命中率目标 30-60%。

L4 模板片段:Git LFS 存 prompt 模板,CI/CD 自动 build 版本号,Redis 存静态片段 hash,动态插槽从 L3 缓存 / 会话存储读取,模板升级时 L4 键自动切换。命中率目标 100%(只要模板不变)。

观测栈:OpenTelemetry GenAI semantic conventions(pitfall #92 早间 id=470 主题的延伸)采集 cache.hit / cache.miss / cache.stale / cache.invalidate 四类 span event;Prometheus 暴露四级命中率 + 净节省指标;Grafana 仪表盘 + SLO 告警。SLO 目标:全局净节省 ≥ 35%,P99 延迟节省 ≥ 40%。

事故防御:singleflight (必装) + early refresh (已知热点) + request coalescing (极端热点),负缓存 30-60 秒防雪崩,定期(每周)做一次"缓存全失效"演练验证降级链路。

走完这套架构后,典型的中等规模 RAG 应用(50 万 chunk 语库、日均 100 万请求)月度账单可从 6.6 万美元压降到 2.5-3.5 万美元(节省 47-62%),P99 延迟从 3.2 秒压降到 1.1-1.7 秒(节省 47-69%)。多级缓存不是"锦上添花",而是 2026 年下半年 LLM 应用从 demo 走向生产的必经一关。

一句话摘要:把精确匹配 KV 复用作为 L1、向量相似度去重作为 L2、RAG 中间产物作为 L3、动态插槽作为 L4,通过分层命中率工程与 stampede 防御,把 LLM 应用的 token 成本与 P99 延迟分别压降 30-60% 与 40-70%。

参考文献

1. GPTCache: A Semantic Cache for LLM Queries, Alibaba DAMO Academy, 2023.
2. Semantic Cache: Reducing LLM Costs and Latency via Embedding-Based Reuse, OpenAI Cookbook, 2024.
3. vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention, Kwon et al., SOSP 2023.
4. SGLang: Efficient Execution of Structured Language Model Programs, Zheng et al., 2024.
5. Retrieval-Augmented Generation for Large Language Models: A Survey, Gao et al., 2024.
6. BGE Reranker v2.5: Multilingual Cross-Encoder for RAG Pipelines, BAAI, 2025.
7. Bloom Filter: Space/Time Trade-offs in Hash Coding, Burton H. Bloom, Communications of the ACM, 1970.
8. LRU-K: A New Page Replacement Algorithm, O'Neil et al., SIGMOD 1993.
9. Cache Stampede Problem: Solving the Thundering Herd, Cloudflare Engineering Blog, 2018.
10. Singleflight: Suppressing Duplicate Function Calls in Go, Go Blog, 2014.
11. OpenTelemetry Generative AI Semantic Conventions, CNCF, 2025.
12. PGVector: Open-Source Vector Similarity Search for Postgres, Andrew Kane, 2023.
13. Adaptive TTL for Edge Caches, Vakali et al., IEEE TPDS 2005.
14. LLM Application Production Cost Engineering, Datadog State of AI Costs Report, 2026.