用 Rust/WASM 构建 LLM 的开源边缘语义缓存——对架构的合理性检查？[D]

嘿，大家好。我正在规划一个新的开源基础设施项目，希望能从那些在生产环境中运行高负载 LLM 工作负载的人那里获得关于架构和用例有效性的犀利反馈。**问题：** 基于 Python 的代理/网关会为实时流式 agent 步骤或快速 UI 补全引入过多的延迟开销。此外，集中式语义缓存仍然存在跨区域网络延迟（例如，从伦敦到 us-east-1），而企业 API 成本对于重复/可预测的用户查询（如客户支持或结构化数据提取）来说仍然是一个巨大的瓶颈。**提议的架构：** 目标是构建一个轻量级、零依赖的语义缓存，直接使用从 Rust 编译的 WebAssembly (WASM) 在 CDN 边缘运行，而不是依赖笨重的集中式网关。流程如下：1. **入站提示：** 到达最接近用户的边缘节点（例如，Cloudflare Workers / Fastly Compute）。2. **边缘嵌入：** Rust/WASM 模块拦截原始文本提示，并使用边缘原生轻量级模型（例如，`bge-small-en-v1.5`）立即生成向量。3. **相似度索引检查：** 对边缘向量数据库（如 Cloudflare Vectorize）执行快速的余弦相似度检查，以找到最相似的语义邻居。4. **缓存命中：** 如果相似度 >= 阈值（例如，0.88），则从边缘 KV 存储中拉取完整的生成响应文本，并在约 5 毫秒内返回。主 LLM 提供商永远不会被计费或触及。5. **缓存未命中：** 将流式请求代理到 OpenAI/Anthropic/vLLM，将结果流式返回给客户端，并异步更新边缘向量索引和 KV 存储。**为什么选择 Rust/WASM？** 为了实现代理本身亚毫秒级的执行开销，避免垃圾回收暂停，并保持内存占用极小，适合传统数据库或 Python 脚本无法运行的边缘运行时约束。**我对社区的疑问：** 1. 对于那些在生产环境中运行 LLM 的人（尤其是客户支持、内部 RAG 或自主 agent），你们实际上的语义缓存命中率是多少？在你们的领域中，重复查询的幂律规律是否足够高，足以证明此方案的合理性？2. 在边缘进行语义缓存的最大陷阱是什么？（例如，缓存失效策略、处理系统提示更新或嵌入模型漂移）。3. 你们是否会实际使用一个即插即用的开源模板/CLI，让您可以在自己的边缘账户上快速部署，还是更喜欢集中式 API 网关？