背景：向量，AI 理解语义与组织信息的核心
在当前的大模型、推荐系统和 AI Agent 等热门技术中，"向量"成为了实现落地的关键。传统的搜索依赖关键词匹配 。例如，搜索"新能源车"可能错过提到"电动车"或"绿色出行"的内容。这种方式的局限在于检索引擎看不懂语义。
而向量 不同。当文本被转化为向量时，其含义被编码在高维空间中。在这个语义空间里，"新能源车"和"电动车"的向量会非常接近，即使字面上完全不同。这意味着机器第一次具备了理解"意思"的能力，而不仅仅是字面匹配。在 AI 世界，这种"理解"正是通过向量来实现的。一段文字、一张图片、甚至一段音频，被转化为向量后，它们被放进同一个"语义空间"。AI 通过比较这些向量的距离，就能判断"哪些东西相似"，从而判断"哪些更符合你的需求"。
技术路径：向量检索的算法与产品生态
在向量检索的世界里，最直观也最基础的方法是 KNN（K-Nearest Neighbors）。当你输入一个向量时，系统会在数据库里暴力搜索------即和所有向量逐一计算距离，然后把最近的 K 个结果返回给你，就像在一堆书里逐本翻阅，找到最接近你心中那本的候选答案。KNN 的优点是准确率极高，几乎没有误差，但当数据量达到百万甚至亿级时，全量比对会异常缓慢，难以满足实时应用需求。于是，人们提出了 ANN（Approximate Nearest Neighbors），也就是近似最近邻搜索，它不再追求绝对精确，而是通过巧妙的索引结构、向量分片和压缩技术，在毫秒级时间里快速找到"足够接近"的结果。虽然 ANN 的结果可能与真实最近邻略有偏差，但在大多数应用场景中几乎无感，却能带来数十倍甚至上百倍的性能提升。
HNSW 结构
这就是近似最近邻（ANN， Approximate Nearest Neighbor）检索要解决的核心难题。为了加速向量搜索，学术界和工业界提出了很多索引算法，并结合量化技术优化查询速度：
-
IVF：最早期的分桶检索方法，把向量分到不同的"桶"里，查询时只在部分桶中搜索，大大提升了速度。
-
HNSW：近年来最火的检索算法之一。它基于图结构，每个向量是一个节点，通过分层网络快速找到近邻。特点是速度快、精度高，如今已经成为许多向量数据库的"标配"。
-
DiskANN：当数据量达到数十亿、甚至百亿级时，内存已经放不下所有向量。微软的 DiskANN 就是专门为超大规模场景设计的算法，把数据存储在磁盘上，同时保证检索性能。这让"海量向量检索"成为可能。
-
PQ / SQ ：向量维度往往很高（上百、上千），直接存储代价极大。量化方法通过"压缩"向量来降低存储成本，同时在检索时依然能保证较高的精度。比如 PQ（Product Quantization） 就是最广泛应用的压缩技术，最常见的组合 IVF+PQ， IVF 先选候选簇，再用 PQ 压缩的子向量做距离估计，内存占用大幅下降，速度也更快。
-
RabitQ：一种全新的随机二值量化（Randomized Bi-valued Quantization）方法。它将每个 D 维向量量化成 D 比特的二进制码串，通过随机正交变换将数据映射到单位超球面上，从而得到理论上有保证的误差界限。与传统的 PQ 不同，RaBitQ 在理论上是无偏估计，已被证明是渐近最优的。
新方案：基于对象存储构建向量
开源版本的向量数据库实现了上述算法，通常 CPU、内存、磁盘 三者存算一体，追求低时延常把索引常驻于内存或磁盘，容量上限与节点 RAM/SSD 成本强耦合。通常需要提前规划所购买实例的内存和磁盘空间大小，并以此创建集群并付费。当大规模的业务量突发时，其往往需要紧急扩容内存与磁盘，再待流量低峰时缩容。另外由于云盘的成本较高，往往存储冷数据的成本大于收益，冷数据通常不会存储在存算一体的产品中。
随着 AI Agent 和 SaaS 应用的出现，向量业务形态从"大规模知识库" 转向 "小规模海量多用户"。在新的业务形态下，往往用户查询频率低，查询延时不敏感。这导致存算一体的架构下存储海量向量时面临严峻的成本问题。基于此如何将低频数据存储到更廉价的存储服务中成为了新的挑战，每个产品都在探索基于分层存储的新方案。
S3 的云原生存储能力为 toc 的海量向量数据提供了存储可能。为了追求弹性和大规模的向量存储，创业公司涌现出一种新的设计思路------通过结合S3 的存储能力，将向量持久化存放在 S3 中，实现近乎无限的存储扩展能力，同时结合内存/SSD 缓存与分布式 ANN 索引，实现冷热数据分层与按需调度。通过牺牲查询速度和召回率，来换取大规模存储容量和低存储成本。对 ToC 产品而言，这意味着可以在 知识问答、个性化推荐、智能搜索、对话式 AI 等应用中，稳定支撑上亿甚至上百亿级别的用户向量与交互数据，从而真正把向量数据库的能力带到大众消费者手中。
-
Pinecone 索引数据（向量）持久化存储在 S3，在查询时按需加载到计算资源中，极大降低运行成本且支持弹性伸缩。WAL + Memtable 快速承接写请求，WAL 直接基于 S3 构建 WAL。向量索引结构通过后台 Compaction 生成高质量的 slab 加速查询性能。
-
TurboPuffer 是一个 "对象存储优先"（Object-Storage-First），其设计核心是在 AWS S3 上直接存储和管理索引与数据。Turbopuffer 的架构中，SPFresh 是主要向量索引，设计上面向插入、更新、删除向量场景有更好的增量更新能力。namespace 有一个 2.5 亿文档限制，大小不超过 512gb。然后单 namespace 限制写入 1w 每秒，32MB/s。主打 toc 场景，即用户数很多，但每个用户的向量不多。
S3 vectors 定位
而随着 AI 应用的全面爆发，一个新的现实问题摆在了面前：海量向量需要更强大的存储与检索基础设施。换句话说，只有一个能支撑 大规模、低成本 的向量产品，才能真正让 AI 从实验室走进大规模的商业与产业场景。基于此 S3 推出了一种全新的 bucket 类型------ S3 vectors。它提供了一款专门构建的向量存储解决方案，宣称可将存储向量的总成本降低 90%。根据 re:invent 上公布的数据，在短短四个多月内，AWS 用户创建了超过 25 万个向量索引，存储了超过 400 亿个向量，执行超过 10 亿次查询。
S3 vectors 为向量数据提供了云原生的向量语义，作为是整个方案的 vector 存储层，经过 Embedding Model 后的向量数据都会被写入并持久化在 Amazon S3 中。它提供了一种新的向量方案，能够以极低的存储成本存储大规模的向量，同时利用对象存储的高可靠性和弹性扩展特性来满足不断增长的数据量需求。实现从 S3 向量桶中快速找到与查询语义最接近的结果。
3.1 产品定位
S3 Vectors 提供了完整的 vector 存储能力，用户可以基于 S3 vectors 构建分层存储服务，将 向量业务与向量存储解耦。存储层用 S3 Vectors 来保证海量数据的持久化与低成本，计算层则通过索引和缓存来加速查询路径，从而既能承载 TB/PB 级的数据规模，又能在语义检索场景中保证较低延迟与较高准确率。
在正式版本中，每个向量索引最多可存储 20 亿个向量，大幅降低了大规模向量存储的复杂度。这意味着既可以可以将整个向量数据集整合到一个索引中进行公共数据集的查询，也可以通过合理的向量索引划分策略，以支持海量的多租户独立查询。相比传统方案，用户无需再在 S3 文件语义层面自行构建复杂的写入和更新 I/O 链路，也不必设计复杂的冷热分层存储架构，更无需在后台进行异步的 Compaction 编排。这些复杂性都被 S3 vectors 服务所屏蔽，使得大规模向量管理更加高效、简洁。
3.2 定价分析
定价是 S3 vectors 最受关注的点。AWS 设计上将存储和计算两者分开，分别独立收费。以 us-east-1 为例，成本主要由三部分构成 PUT 成本、存储成本 和 查询成本。S3 Vectos 存储采用按需付费的模式，只需要为实际存储空间付费。计算费用分为两部分，向量上传费用与向量查询费用。查询费用基于已存储的实际向量索引大小收费。这种定价理念的转变意味着不再需要仅为了存储向量而支付集群实例的费用，所以存储费用相比于 AWS OpenSearch 等向量数据库产品显著低。
不过，S3 Vector 的按次计费模式在实际使用中也存在一定缺点。首先，PUT 请求（向量上传）费用较高，尤其在批量写入或频繁更新向量的场景下，这部分成本会显著增加。与传统自建或托管向量数据库不同，S3 Vector 每次上传操作都单独计费，导致在高频数据写入任务（如实时更新 Embedding）中成本不易控制。即使单次数据量很小，依然会产生 128KB 的最小费用。
其次，查询费用与索引大小和调用次数直接挂钩，在高并发或复杂检索场景下成本增长较快。由于每次查询都会按请求量计费，而不是像自建数据库那样按实例资源占用计算，当检索请求频繁、向量维度高或需要多次 top-K 查询时，费用会显著上升。这种"按查询量计费"的模式在推理调用或用户交互密集的应用（如聊天、推荐系统）中，可能导致查询成本超过存储成本本身。
3.3 组合的向量方案
S3 Vectors 成本与使用场景息息相关。冷数据的存储成本对比同存储规格的实例型向量数据库相比，其成本可节省 90% 的成本。相反，对于"热路径"或超低延迟的应用程序而言，其成本可能会更高。对于用户而言，既希望有极速的向量查询性能，又能有超低成本的向量存储成本。S3 Vectors 和 AWS OpenSearch 都无法单独满足这两个需求。
S3 Vectors 支持采用分层存储策略，在 成本 与 性能 之间取得平衡。长期的、低频访问的向量数据可以经济高效地保存在 Amazon S3 中，而对 高优先级 或 实时查询 场景的向量，则可以导出到 OpenSearch，以获得高 QPS 和低延迟的性能。与 OpenSearch 集成，用户能够灵活地将不常用的向量保留在 S3 Vectors 中，而在需要实时、低延迟搜索时，再快速迁移到 OpenSearch，从而既保障了性能，又显著降低了整体存储成本。
TOS vector bucket 定位
S3 Vectors 的定位非常明确：面向 大规模、长周期存储 与 弹性、低频查询 的场景，提供高性价比的解决方案。它与 AWS OpenSearch 等高性能数据库组合后，不仅补足了高频/低频数据的分层需求，还显著提升了 AWS 在向量场景的覆盖度和整体竞争力。
TOS Vectors 的产品形态与定位也参考了 S3 Vector 的思路，通过与火山引擎高性能向量数据库的协同组合，打造更完整的方案竞争力；同时进一步与 火山方舟 Embedding API 等能力深度结合，增强生态黏性，为用户提供从 向量生成、存储到检索 的一站式体验。
-
与火山方舟结合：多模态应用场景下，用户调用 方舟 Embedding 模型 后，可以直接将生成的向量数据存入 TOS Vector Bucket，以便后续的检索和查询，从而支撑各种跨文本、图像、音频的视频等的多模态内容检索需求。
-
与火山向量数据库产品结合：TOS Vector 不仅支持从高性能向量数据库 Import 导入数据，也支持将数据 Export 导出 到高性能数据库，实现冷热数据之间的灵活迁移。比如，在一个典型的业务场景中，用户可以借助 Vector Bucket 获得原生的向量语义能力：高频向量数据存放在 云搜索服务 或 VikingDB 中，用于实时查询；而历史数据则沉淀到 TOS Vector，以更低的成本进行长期存储和低频检索。这样一来，既能保证系统在实时业务中保持高性能，随时调取沉淀在 TOS Vector 中的低频数据，做到 性能与成本的双重优化。
-
与火山 AI agent 结合：对于 Agent 应用而言，往往需要同时依赖 对象存储 与 向量数据库 才能顺利落地。然而，当 Agent 规模较小时，即便只是购买一台 1 core 的实例型产品，成本依然不容小觑。Vector Bucket 提出了全新的 Serverless 形态，让开发者可以基于 TOS 快速构建 Agent 应用：按需调用、灵活扩缩容，不必为闲置资源买单，从而显著降低了早期试错和规模扩展的成本。
展望未来：向量驱动的智能社会
回望历史，向量曾经只是数学公式中的抽象符号，而如今，它已经成长为 AI 的语义基石，并正迈向重构整个信息社会的未来。向量不仅是一种技术，更是一种全新的信息组织方式，它让 AI 不再只是冷冰冰的工具，而是能够与人类真正对话、协作、乃至共生的智能体。S3 Vectors 是大规模 AI 基础设施发展历程中的一个重要转折点。通过 Vector bucket 可以保留更多历史数据，扩展到更大的向量数据集。Tos vectors 将在下篇文章中讲解技术实现，敬请期待。