在 Serverless 架构中部署语义搜索系统，本质上是一场与资源约束的持续博弈。Cloudflare Workers 提供了全球分布式的无服务器执行环境，但其 128MB 内存上限和 10ms 至 5 分钟的 CPU 时间限制，对向量密集型应用构成了显著挑战。本文以 Studio Ghibli 电影帧语义搜索项目 anini 为案例，探讨在内存受限环境下实现高效语义搜索的工程路径。
内存约束下的向量操作策略
Cloudflare Workers 的内存模型与传统的容器化部署存在根本性差异。每个 Worker 隔离的内存上限为 128MB，这包括 JavaScript 堆内存和 WebAssembly 显式分配的内存。语义搜索的核心操作 —— 向量相似度计算 —— 恰恰是内存密集型任务。一个 1536 维的浮点向量占用约 6KB 内存，理论上可以存储约 21,000 个向量。然而，实际可用的内存远低于这个理论值，因为 Worker 运行时、应用程序代码、依赖库和临时缓冲区都会消耗内存。
anini 项目采用的策略是将向量计算外置到 Cloudflare AI Search 服务，本地 Worker 仅负责路由和结果聚合。这种设计将内存压力转移到托管服务，Worker 本身仅需处理请求转发和响应格式化。实测表明，即使在高峰期，Worker 的内存占用也能稳定在 30MB 至 50MB 之间，为突发流量预留了充足的缓冲空间。
对于必须在本地处理向量的场景，建议采用流式处理模式。例如，在处理用户上传的搜索图像时，应先将图像上传至 R2 存储，获取对象键后再调用 Workers AI 的图像描述模型生成向量，而非将整个图像缓冲在内存中。这种模式的关键参数是单次处理的最大图像尺寸，Cloudflare Workers AI 对图像输入的限制为 4MB，超出此限制的图像应先在客户端压缩或分块处理。
AI Search 与 R2 的协同架构设计
anini 的技术栈选择体现了 Cloudflare 平台能力的深度整合。Cloudflare AI Search（基于 AutoRAG 技术）负责语义索引和相似度匹配，R2 存储原始图像数据，Workers 作为编排层处理业务逻辑。这种分离架构的优势在于：AI Search 自动处理图像到向量的转换、索引构建和查询重写，开发者只需关注应用层逻辑。
R2 与 AI Search 的集成遵循数据源连接模式。在 anini 的配置中，R2 桶以特定命名规范组织图像文件，AI Search 索引直接挂载该桶作为数据源。当新图像上传至 R2 时，AI Search 会自动检测并触发索引更新，无需额外的同步机制。这种设计的关键参数是文件命名规范：anini 采用 (年份) 电影名/场景描述.png 的格式，既便于人工管理，也为 AI Search 提供了语义丰富的元数据。
从成本角度考量，AI Search 的定价在公开测试期间免费，正式收费后将基于向量存储量和查询次数计费。R2 的存储成本低于 AWS S3 且无 egress 费用，适合存储大量图像素材。Workers 的请求成本同样按调用次数计费，高并发场景下需关注 AI Search 的速率限制。当前 AI Search 的默认限制为每个账户 10 个索引实例，每个索引最多 100,000 个文件。
关键配置参数与阈值指南
在 Cloudflare Workers 环境中部署语义搜索系统时，以下参数值得特别关注。
内存管理方面，Worker 的 128MB 限制是硬性约束。建议将单个请求的峰值内存控制在 64MB 以下，以留出运行时开销和 GC 缓冲。具体实践中，应避免在请求处理路径中加载大型模型或数据集，所有模型调用应通过 Workers AI 的远程 API 完成。对于需要本地缓存数据的场景，可使用 KV 存储或 Durable Object，但需注意 KV 的读取延迟通常在 10ms 至 100ms 之间。
速率限制方面，Workers AI 的文本嵌入模型（@cf/baai/bge-large-en-v1.5）限制为每分钟 1500 次请求，普通嵌入模型为 3000 次每分钟。在设计搜索接口时，应实现请求队列或令牌桶机制，避免触发限流。文本生成模型（如 Llama）的限制更为严格，通常为每分钟 300 次请求，不适合用于高并发的搜索响应生成。
超时控制方面，Workers 的 CPU 时间限制默认为 30 秒，可付费提升至 5 分钟。语义搜索请求的端到端延迟主要取决于 AI Search 的查询时间，实测 anini 的搜索请求在 500ms 至 2000ms 之间完成。Worker 代码应设置合理的 fetch 超时（建议 10 秒至 30 秒），并实现优雅降级 —— 当 AI Search 响应超时时，返回缓存结果或友好的错误提示而非 500 错误。
索引配置方面，AI Search 的单文件大小限制为 4MB。对于高分辨率电影帧，建议预处理为 1920x1080 分辨率的 JPEG 格式，文件大小通常在 500KB 至 2MB 之间，既能保持视觉质量又符合索引限制。索引命名应包含业务标识和版本号，便于多环境管理和灰度发布。
监控指标与优化方向
生产环境的语义搜索系统需要关注三类核心指标：系统健康度、搜索质量和成本效率。
系统健康度指标包括 Worker 的内存使用率、请求错误率、响应延迟分布以及 AI Search 的可用性状态。Cloudflare Workers Analytics 可通过 Dashboard 或 API 获取这些数据，建议配置告警规则：当内存使用率持续超过 80%、错误率超过 1% 或 P99 延迟超过 5 秒时触发通知。日志记录应包含请求 ID、搜索查询和结果数量，便于问题排查和用户反馈关联。
搜索质量指标关注查询结果的准确性和相关性。anini 之类的项目可通过用户反馈机制收集隐式信号，例如点击率、平均查看时长和重搜率。在没有用户数据的冷启动阶段，可使用预定义的测试查询集（如 "飞行的场景"" 雨天街道 " 等电影场景描述）定期评估搜索结果的多样性和相关性。
成本优化的核心在于减少不必要的 AI Search 调用。常见的优化策略包括：结果缓存（对相同查询复用历史结果，缓存时间建议 5 分钟至 1 小时）、查询去重（在 API 网关层合并相同时间的重复请求）、以及预计算热门查询的向量。对于电影图像库这类更新频率较低的场景，可考虑预生成常用查询的搜索结果并存储在 KV 中，查询时直接返回缓存。
工程实践的权衡取舍
在 Cloudflare Workers 环境下构建语义搜索系统，本质上是在功能完整性和资源效率之间寻找平衡点。anini 项目的选择 —— 将向量计算完全外置 —— 牺牲了一定的架构灵活性，但换取了可靠的内存安全和简化的运维负担。对于有更强定制需求的场景，可考虑在 Worker 中集成轻量级向量库（如 LanceDB 的 Wasm 版本），但这要求开发者对内存使用有更精细的控制。
另一个值得权衡的问题是图像搜索的实现方式。anini 同时支持文本查询和图像上传搜索。图像搜索的实现有两种路径：一是上传图像后由 AI Search 自动提取向量，二是由 Workers AI 的图像描述模型生成文本描述再进行文本搜索。前者精度更高但调用成本更大，后者延迟更低但可能丢失图像的细粒度特征。具体选择应根据业务场景的优先级 —— 如果用户主要搜索特定视觉元素（如 "龙猫"" 天空之城 "），图像搜索的精度至关重要；如果用户意图较为宽泛（如" 温馨的家庭场景 "），文本搜索通常足够。
总体而言，Cloudflare Workers 为中小规模的语义搜索项目提供了极具吸引力的基础设施方案。其全球分布的边缘网络、零运维成本和按需付费模式，特别适合验证想法的原型阶段和中小流量的生产应用。随着 AI Search 正式商业化和 Workers AI 能力的持续增强，这一技术栈的适用场景还将进一步扩展。
资料来源：anini 项目 GitHub 仓库（github.com/aninibread/ghibli-search）、Cloudflare AI Search 文档、Cloudflare Workers 平台限制说明。