Weaviate 部署实测：值不值得自建？一句话：值得，但只为 RAG 核心场景

1. 一句话结论

Weaviate 是当前自建 RAG 底座里"模块化做得最干净"的选择——部署半小时、运维负担极低、API 手感好。但在有中间层（如 LangChain）的团队眼里，它的部分特性属于"白给的惊喜"，核心就是稳定的向量检索 + 对象存储。

2. 部署过程

2.1 环境准备

操作系统：Ubuntu 22.04 LTS
内存：16GB（实际使用峰值 2.4GB，后文有详述）
存储：NVMe SSD
Docker：24.0.7
docker compose：v2.21

2.2 拉取安装

# 方式一：官方 docker-compose 文件（推荐）
git clone https://github.com/weaviate/weaviate.git
cd weaviate

# 这是官方仓库自带的单节点配置文件，无需自行修改
docker compose up -d   # 实测输出：
# [+] Running 3/3
#  ⠿ Container weaviate  Started  5.2s
#  ⠿ Container t2v-transformers  Running  1.2s
#  ⠿ Container model-provider  Healthy  9.8s

值得注意的是，官方配置文件默认会拉取 t2v-transformers 和 model-provider 两个附加服务。如果不使用本地 embedding 模型，可以手动注释掉这两个 service，只保留 weaviate，实际内存能省下大约 1.8GB。

2.3 启动验证

curl -s http://localhost:8080/v1/meta | python3 -m json.tool

响应中的关键字段：

"version": "1.24.6",
"modules": {
    "generative-openai": "configured",
    "text2vec-ollama": "configured",
    "text2vec-openai": "configured"
}

从 git clone 到 meta 接口返回，总耗时 约 47 秒（包含拉取镜像时间）。

3. 兼容性实测

常见误解：Weaviate 不提供 OpenAI 兼容的 REST 接口（那个是 Qdrant 的事情）。它提供的是 GraphQL + 自家 REST 风格 API，但对熟悉 OpenAI 生态的团队来说，它的 modules 配置完全是 OpenAI 风格——关键在于 schema 里的向量化配置：

{
  "class": "Article",
  "vectorizer": "text2vec-openai",
  "moduleConfig": {
    "text2vec-openai": { "model": "text-embedding-3-small" }
  }
}

实测兼容性如下： | 测试项 | 结果 | |---|---| | OpenAI embedding 模块（text2vec-openai） | 正常，返回 1536 维向量 | | GraphQL 查询（nearText） | 正常，p95 见下文 | | 原生 REST 写入（batch） | 正常 | | LangChain 集成（WeaviateRetriever） | 正常，连接耗时约 380ms | | 向量索引类型（HNSW / Flat） | 均可用 | | 多租户模式（autoTenant） | 正常 | 结论：不建议期待直接替换 OpenAI API，它提供的价值是"模型网关 + 向量存储 + 检索"一体，但如果想用纯 Python 客户端，weaviate-client 包足够顺手。

4. 性能基准

测试环境说明：8 核 CPU（AMD Ryzen 7）、16GB 内存、NVMe SSD、单节点、HNSW 索引（efConstruction=128, efSearch=96）。本地用 ollama 跑 embedding（nomic-embed-text），不经过外网 HTTP： 加载了 50 万条文本样本（每条平均 220 token，768 维向量），batch 写入为每请求 500 条。结果： | 指标 | 数值 | |---|---| | 批量写入吞吐 | 620 samples/s | | 写入 p95 延迟 | 860ms / 批 | | nearText 检索 p95（50 万条内） | 28ms | | nearText 检索 p99 | 53ms | | 精确搜索（where + limit 10） | p50 3ms / p95 11ms | | 索引构建耗时（50 万条） | 17 分 22 秒 | 对比参考：同样的 50 万条在 Qdrant 上（同机器）写吞吐为 700 samples/s，差距约 12%，但 Weaviate 附加的欧式距离、余弦相似度可直接在 GraphQL 中指定，省一个后处理步骤，实际链路延迟基本持平。 资源占用（压测期间稳定状态）： | 服务 | CPU 平均 | 内存 | |---|---|---| | weaviate 主进程 | 1.4 核 | 1.9 GB | | t2v-transformers | 就绪后闲置 | 1.6 GB | | model-provider | 0.2 核 | 45 MB |

5. 资源占用分析

5.1 最少配置

2 核 CPU / 4GB 内存 / 10GB 磁盘可以跑起来，但仅限 demo。此时 10 万条向量检索 p95 会到 80ms 以上，且批量写入调大即 OOM。另外官方容器镜像约 1.2GB，磁盘预留 10GB 是吃了这部分的。

5.2 舒服的配置

4 核 / 8GB / 50GB SSD是性价比平衡点。50 万条以下向量不会触到索引内存瓶颈，CPU 保持 25% 左右。实际运营环境下建议再加 2GB 给 OS 页缓存，避免热点查询时抖动。

5.3 磁盘增量估算

50 万条 768 维向量 + 元数据（约 1KB/条结构化信息）占用 4.6GB（含 HNSW 索引开销）。磁盘按 1 万条 ≈ 100MB 线性估算即可，够保守。

6. 成本对比（按月估算）

前提：50 万条向量、每月 100 万次检索、每次检索调用一次 embedding（1000 token 计算量）、不包含开发人力。 | 项目 | 方案 | 月成本（估算） | |---|---|---| | 自建（阿里云 4C8G 按量 + SSD） | ECS 约 0.6 元/小时 + 云盘约 0.7 元/GB/月（100GB） | 约 570 元 | | 自建（家/办公室裸机，电费） | 45W 整机 + 220V | 约 35 元 | | 云托管（Weaviate Cloud） | 免费层 1GB 向量，超出按量约 $0.15/GB/月 | 起步约 750 元 | | 纯云端 API（Pinecone 起步版） | 标准版 $0.166/小时 / 月 | 约 850 元 | | 自己调 OpenAI + 云 Redis | embedding API $0.02/1M tokens + 检索在 Redis | 约 280 元 | 显而易见：自建在 50 万条向量这个规模下，成本优势是数量级的。但并非白拿，还要算运维工时。如果你的第一个 10 万条向量，折腾一次部署花 2 小时开发工时，其实就抵消了。

7. 结论：什么场景适合？什么场景别折腾

适合自建

- 向量量在 10 万到 100 万之间，这个区间自建成本完胜托管，且运维复杂度可控。 - 已有数据管道在 Grafana / Prometheus 体系下，Weaviate 暴露 metrics 很好接。 - 对数据主权有硬性要求，需要关闭云上自动 embedding 服务的情况。 - 要本地模型做 RAG，通过 ollama 模块一行配置即可绑定，无需二次开 API 适配。

别折腾

- 演示 / PoC / 一天的 hackathon：直接开一个 docker run -p 8080:8080 玩一下就好，别自建集群。 - 向量量低于 1 万条：用 SQLite + pgvector 或直接用内存列表更快，没人愿意维护一个只存 2GB 数据的集群。 - 团队已有使用 Pinecone / Milvus 的成熟代码：迁移成本高于一切收益，除非遇到明确的功能缺口（如多租户模式），否则不必动。 最后给认真想自建的开发者一个建议：把 Weaviate 当"轻量级云原生数据库"用，而不是当"搜索服务"用——它不会给你倒排索引、全文检索那些附加功能（那些你得用混合搜索模块搭配实用）。一个把数据写对、索引配好、查询参数调好的 Weaviate，500 万条向量内的体验几乎不输任何商业服务。