CodeFuse开源ModelCache大模型语义缓存
CodeFuse 开源火热进行中！本次开源的是 ModelCache 大模型语义缓存，可大幅降低大模型应用的推理成本，提升用户体验。
CodeFuse-ModelCache 项目地址：
https://github.com/codefuse-ai/CodeFuse-ModelCache
0 背景
在LLM技术浪潮席卷全球的背景下，大型模型快速增长的参数规模，对部署所需的推理资源带来了极大的挑战。为了提高大型模型的推理性能和效率，我们尝试从缓存角度解决当前大模型规模化服务部署的困境。类似传统应用，大模型的用户访问同样具有时间和空间的局部性（例如：热门话题相关内容，热门 GitHub repo）。如果有了缓存层，在遇到相似请求时，就无需调用大模型服务，直接从缓存的数据中返回已有的结果给用户，会大幅降低推理成本，提升用户体验。
1 大模型缓存的意义
当前大模型服务面临一下三个挑战：
- 成本高：大模型参数量千亿级别，单实例就需要多张A10卡，规模化部署成本高昂。因此，当前大模型服务基本按照处理的token数量计费，导致用户侧使用成本也居高不下。
- 速度慢：大型模型的推理速度也是一个关键问题。在许多实时应用中，如对话系统、业务助手，响应时间要求非常高，通常在毫秒级别。然而，大型模型的推理速度往往较慢，在秒级，导致无法实时返回结果，用户体验下降。
- 稳定性无保障：由于单实例部署成本高昂，当前大模型服务接受到大流量请求时，通过限流的方式，防止服务不可用。
2 方案调研
我们对开源方案GPTCache进行了调研，其是致力于构建用于存储 LLM 响应的语义缓存的项目，该项目提供了语义相似度匹配框架，并提供了相对完善的功能模块和接口。具有以下优点：
- 项目的活跃性，它不断引入新功能，使得我们能够紧跟最新的发展动态。
- 具备开放的功能模块，可以进行调整和优化，这为业务的扩展提供了便利。
GPTCache的整体架构如图1所示：
图1. GPTCache架构
但是，GPTCache在落地应用上仍存在诸多不足，包括：
- 架构上将大模型调用和数据回写对用户进行了黑盒处理，使得大模型产品在流式输出、安全审核、问题排查等方面变的复杂。
- 默认采用faiss和sqlite作为存储，不能进行分布式部署，尤其是在关系型数据库方面，SqlAlchemy框架无法支持蚂蚁的OceanBase。
- 数据和资源隔离上，无法处理多模型多版本场景。
- 不支持多轮会话，尤其是当模型有system指令时，无法很好兼容。更多待改进功能会在3.3部分会做详细介绍。
3 ModelCache建设
针对上述问题，我们基于GPTCache进行了二次开发，构建蚂蚁内部缓存产品ModelCache，整体架构见图2，接下来会详细介绍我们的工作，包括：3.1 整体架构；3.2 功能升级。在功能升级部分，会详细介绍ModelCache中新增的功能点。
3.1 整体架构
图2. ModelCache架构及上下游
3.1.1 技术架构
在初始架构中，将大模型调用和数据回写对用户进行了黑盒处理。然而，这种架构导致问题排查繁琐，以及流式输出和数据安全审核等方面难以满足企业级要求。
因此，我们对架构进行了重新调整，ModelCache采用了轻量化的接入方式，不打扰大模型产品的功能实现。我们设计ModelCache为类redis结构，提供了开放式的数据查询、数据回写、数据管理等API，同时解耦了大模型调用，可作为一个独立模块嵌入到大模型产品。通过ModelCache，产品侧能够更加灵活地管理和使用大模型，提高系统的可维护性和可扩展性。
3.1.2 核心模块
在ModelCache中，包含了一系列核心模块，包括adapter、embedding、rank和data_manager等，具体功能如下：
- adapter模块：其主要功能是处理各种任务的业务逻辑，并且能够将embedding、rank、data_manager等模块串联起来。
- embedding模块：该模块主要负责将文本转换为语义向量表示，它将用户的查询转换为向量形式，并用于后续的召回或存储操作。
- rank模块：用于对召回的向量进行相似度排序和评估，可根据L2距离、余弦相似度或者评估模型，对两个向量进行相似度评分，并进行排序。
- data_manager模块：该模块主要用于管理数据库，包括向量数据库和关系型数据库，它负责数据的存储、查询、更新和删除等操作。
-
- 向量数据库（Milvus）：Milvus作为一个高性能、可扩展、多功能的向量数据库，适用于多种需要向量检索的应用场景。
- 关系型数据库（OceanBase）：我们采用蚂蚁的OceanBase数据库，存储用户query、LLM相应、模型版本等信息。
