随着大模型玩家之间的技术路线逐渐趋同，数据管理能力，正逐渐成为大模型竞赛中各个玩家的关键胜负手。

2020年6月发布的GPT-3 ，训练数据还仅有 570GB 的文本数据，模型参数超过 1750 亿个。到了2023年发布的GPT-4 ，模型参数已经达到1.8 万亿，背后的训练数据更是高达13万亿token。

而随着模型尺寸变得越来越大，多模态也在同期成为主流。为此，我们不仅需要更大的计算资源，也对非结构化数据的管理提出了更高的要求，对应的数据存储、处理、传输和检索系统升级已经迫在眉睫。

在这个背景下，头部大模型玩家MiniMax 和 向量数据库领军企业Zilliz 的合作成为了行业的一个重要标杆。

两者的合作不仅仅解决了MiniMax 旗下Talkie 等产品的高并发和精准推荐的问题，更为大模型训练提供了高效、灵活的数据管理架构。

那么这一合作是如何实现的？它又是如何推动数据管理和大模型训练的技术突破的？本文将对以上问题，进行逐一详细拆解。

01 

提升 Talkie AI 的用户体验：精准推荐与高并发处理

在如今的AI产品市场，Talkie 的地位已经不必多说。依托MiniMax全球先进的多模态AIGC技术，Talkie 构建了一个支持用户自由创造和分享AI Agent的交互平台，并入选 a16z 评选的 Top 50 AI-first 网页端产品、Top 50 AI 移动应用双榜单。

面对如此庞大的用户群体，Talkie 的遇到的第一大难关是如何做好推荐物料（类似游戏中的道具）。更进一步，这个问题可以被拆解成三方面：

如何借助语义相似度，做更精准的物料推荐： 在Talkie 中，每一项推荐物料（如角色语音包、互动内容等）都被编码为一个32维的向量，并根据用户历史行为，从物料库中实时筛选出最匹配的内容。

如何快速的将用户需求推送给他：系统的响应速度往往会对用户的购买转化带来直接影响，Talkie 必须在 30 毫秒内返回推荐结果。

如何应对千万级别用户带来的高并发：随着Talkie 的月活不断增加至千万量级，其 QPS（每秒查询次数）有时会达到 5000 次以上。系统必须能够在短时间内响应大量用户的请求，并保证低延迟的服务体验。

起初，MiniMax 依赖 Redis 实现缓存式检索方案，Redis 作为一个内存数据库，快，但贵，也不稳。

尤其是随着物料增长至百万级，Redis 首先会遇到内存限制： 一般情况下，Redis 将数据存储在内存中，这虽然提高了访问速度，但随着数据量的增长，内存开销也大幅增加。

而且 Redis 缺乏原生的向量检索能力，必须通过外部工具或插件来勉强实现embedding 搜索，这在实际工程中往往会引入额外的延迟和复杂性。

因此，Talkie 需要一个能同时满足高性能 + 可扩展性 + AI原生的专业向量数据库产品，于是他们找到了 Zilliz Cloud。而根据这一需求，Zilliz给出了定制化解决方案：

• 用 8 个计算单元（CU）为一个基本配置，配上 7 副本，多副本容灾、负载均衡，从而确保即使某一个副本失效，系统依旧能够继续稳定运行。

• 多副本架构也使得Talkie 在面对大规模并发请求时，保证了其数据查询的高可用性和可靠性，确保查询延迟低至 30 毫秒。

这套新架构不仅支撑了 Talkie 的千万用户扩张，也为其后续产品扩展以及双方更多的合作奠定了基础。

02 

低成本去重百亿文档，加速模型训练

Talkie 的推荐只是前菜，MiniMax 真正重头戏的是大模型训练。

而大模型的数据管理远比表面复杂。最新一代模型动辄十多万亿token的训练数据，意味着仅数据预处理和清洗就可能耗费数周甚至数月工程资源。

更关键的是，这些数据并不是静态的。随着模型不断微调、语料持续演进，系统必须支持对亿级数据的“低成本的增量更新”与“高频次的数据同步”。而这正是传统内存数据库和关系型数据库难以胜任的。

举个简单的例子，大模型训练中，百亿级文档是行业常态。但通常来说，这数百亿文档中会存在大量重复冗余内容，不仅浪费计算资源，更导致大模型反复“咀嚼”相同的知识，在重复内容上过拟合，降低了对新信息的泛化能力。

目前主流的去重方法可以分为三类：

1. 精确匹配：通过对整个文件或者数据块进行哈希计算，找出完全相同的文本；

2. 近似匹配：使用如Jaccard 相似度等算法找出“相似但不完全相同”的文本；

3. 语义匹配：用深度学习模型（如 Transformer）将文本转换为向量嵌入（Embeddings），然后在向量空间中通过聚类或计算余弦相似度等方法，找出那些在语义层面表达相同或相似思想的文本。

随着预训练语料体量达到 TB 甚至 PB 级别，传统的精确匹配（如两两比对）根本无法承载计算负载，并且无法高效查找出一些内容高度相似但表述不同的内容；而语义去重则涉及向量生成和大规模匹配，开销巨大。

基于这一背景，Milvus团队为MiniMax在Milvus2.6版本中构建了专门的MinHash + LSH功能。其中，MinHash 负责将文档压缩为签名（目前，MinHash  向量，需要用户自己生成），LSH 负责高效缩小搜索空间，从而快速定位潜在重复，帮助企业完成百亿级语料下的预处理优化。

此外，Milvus 2.6 还将这一能力原生写入数据库索引系统，API 层面也做了统一，兼容 embedding 插入、索引构建与近似查询。更关键的是，它支持分布式、横向扩展，确保了 TB 甚至 PB 级数据量下的处理能力。

该方案相比于MiniMax此前使用的MapReduce 的方案，在处理速度上提升超过 2 倍，并在成本上实现了 3–5 倍的优化。

当然，这个功能的设计不止可以用于MiniMax的大模型训练数据去重问题，如今已经在网页内容清洗、商品目录管理、抄袭检测等场景，于千行百业落地开花。

结语

放眼未来，随着大模型玩家之间的技术路线逐渐趋同，数据管理能力，将成为大模型竞赛中的关键胜负手。

从传统存储到向量数据湖，是从存数据到用数据的进化；

从MapReduce 去重到 MinHash LSH，是数据质量管理能力的升级；

而从 Redis到专业向量数据库，则是企业从传统数据治理结构向AI原生的转变。

而Zilliz 与 MiniMax 的协作，正是这一趋势的缩影与最佳实践。