腾讯云国际版 Elasticsearch Service（ES）实战：节点规格 USD 单价、存储与 Serverless 计费、日志检索与向量检索全解析（2026）

Meta Description: 2026 年腾讯云国际版 Elasticsearch Service（ES）计费全解析：13 档节点规格按量单价（京沪穗 1 核 2G 0.049、16 核 64G 1.68 USD/节点/小时）覆盖 9 大地域、开源/基础版与白金版双档，节点存储 Premium 0.0001 / SSD 0.0003 USD/GB/小时，Serverless 流量 0.051 / 存储 0.0021 / API 0.017 USD，官方 1 亿条日志/日算例一天仅 0.675 USD；附存储容量公式、向量内存估算与 int8/bbq 量化调优。

关键词：腾讯云国际版、Elasticsearch Service、ES 计费、节点规格单价、按量计费、Serverless、日志检索、向量检索、KNN、Kibana、X-Pack、容量规划

前言（先给结论）：如果你要在腾讯云国际版上做日志检索、站内搜索，或者给大模型搭一套 RAG 向量库，Elasticsearch Service（ES）大概率是你的第一选择——但它的计价方式有个很反直觉的地方：同一台「2 核 8 GB」的 ES 节点，在广州是 0.21 USD/小时，在新加坡是 0.158，在弗吉尼亚只要 0.118；换个地域，同样的算力能便宜 44%。 再加上「开源版 / 基础版 / 白金版」三档 X-Pack 功能分级、Premium 与 SSD 两种云盘、以及一套几乎没人算过的 Serverless 按量口径，很多人的 ES 账单从一开始就是错的。一句话选型：小流量日志和间歇性检索直接用 Serverless 按量（1 亿条日志/日官方算例一天只要 0.675 USD，比自建 3 节点集群便宜约 22 倍）；稳定高写入的生产日志用 3 节点起步（务必 3 节点以上防脑裂）+ 白金版；上亿向量的 RAG 集群则要先算内存、再谈规格——因为决定成败的不是 CPU，而是「向量能不能全塞进内存」。 本文把每一档节点单价、每一种存储单价、每一项 Serverless 计费公式，以及容量规划与量化调优的官方算例全部拆开讲透。

声明：本文价格与规则数据采集于 2026 年 10 月，取自腾讯云国际版官方文档（产品 845 Elasticsearch Service：计费概览、产品计价页、能力与限制、集群规格与容量评估、Serverless 计费说明、版本支持说明、向量检索指南、智能搜索开发计费说明等页面）。所有单价均为美元（USD），仅供参考——实际价格随地域、版本与活动变动，请以腾讯云国际版官网实时价格与您的实际账单为准。文中出现的「月」一律按 730 小时折算，属于本文的推算值而非官方报价，已单独标注。

一、先划边界：ES 和 CLS、COS、EMR、向量数据库到底谁管谁

买错 ES 的人，九成是没分清它和隔壁几个产品的边界。云上的「搜索 / 日志 / 大数据」不是二选一，而是分层选型：每一层只擅长一段工作负载。把边界搞混，要么多花钱，要么性能上不去。

一句话记住分工：收日志看日志用 CLS，存冷数据用 COS，算离线指标用 EMR，事务数据用 TDSQL，而「全文 + 向量」两件事要一套系统同时干、还要复杂聚合和灵活打分——这时候才轮到 ES。 本文只负责最后这一层，但它往往是整条数据链路里单价最容易失控的一环。

二、产品构成与硬上限：ES 集群 + Kibana + Beats/Logstash

产品构成（官方「能力与限制」）：ES 由核心组件 ES 集群 和可视化分析工具 Kibana 组成；数据采集侧可自行部署 Beats / Logstash，或基于 RESTful API 自研写入客户端。

核心硬上限——这些数字在选型阶段就要记住，否则方案根本落不了地：

节点规格与用途分级（官方「可用配置」页列出 7 档，计价页实际在售 13 档，以计价页为准）：

⚠️ 第一个反常识点：「可用配置」页只列了 7 档规格，但计价页在售 13 档。 选型时必须看计价页，否则你会以为 8 核 16 GB、24 核 48 GB、32 核 128 GB 这些档位不存在——而它们恰恰是向量场景和日志场景的常用档。

三、按量计费（一）：节点规格 USD 单价表（13 档 × 9 大地域 × 双版本）

ES 当前只支持按量计费（pay-as-you-go），计费项包括节点规格和存储两项。官方给出的总价公式极其简单，但很多人算错：

集群总费用 = 每节点费用（计算费 + 存储费）× 节点数量

注意这里的乘数：不是只乘一次数据节点，而是「每节点」整体乘以节点数——所以加节点是线性加价，没有规模折扣。

版本分档：节点规格的单价随 Elastic Stack 版本（原 X-Pack）不同而不同，分 开源版（Open Source） 和 基础版（Basic） 一档、白金版（Platinum） 一档。白金版通常贵 6%–11%。

3.1 开源版 / 基础版单价（USD / 节点 / 小时）

3.2 白金版单价（USD / 节点 / 小时）

⚠️ 第二个反常识点（省钱最大的一处）：同规格节点的地域价差最高可达 44%。 以 2 核 8 GB 开源版为例——广州 0.21、香港/新加坡 0.158、弗吉尼亚 0.118。如果你的业务本身就在海外，把 ES 集群放在弗吉尼亚而不是香港，同样的算力成本直接砍掉 25%。但注意：ES 必须和你的写入源（CVM / TKE / 采集器）在同一个 VPC 内，所以地域选择是被业务拓扑绑定的——反过来说，先定 VPC 再定 ES 地域，这个顺序千万别反。

⚠️ 第三个反常识点：白金版不是"贵一点"，而是结构性差异。 看两组数：16 核 64 GB，开源版广州 1.68、白金版 1.866（+11.1%）；但 24 核 48 GB 在东京，开源版 1.312、白金版 1.458（+11.1%）；而首尔的 24 核 48 GB：开源版 1.284、白金版 1.427（+11.1%）——比例稳定在 ~11%。真正的决策依据不是这 11%，而是你是否需要 X-Pack 的告警（Watcher）、SQL JDBC 与机器学习功能——需要就必须买白金版，不需要则开源版/基础版完全够用。特别提醒：基础版从 6.8 起支持集群用户认证，官方强烈建议开启；若购买时未开、事后启用需整集群完全重启，会中断在线业务。

四、按量计费（二）：节点存储单价 + 真实月账单算例

存储项官方计费口径：节点存储费也按「每节点」计入上面的总价公式，即 (计算费 + 存储费) × 节点数。ES 使用 SSD / 高性能云硬盘（Premium） 作为存储介质。

4.1 节点存储单价

单位说明（重要）：官方计价页的存储表格未标注单位。按其与节点规格同页、且节点规格明确为「USD/节点/小时」的口径推断，此处为 USD/GB/小时；换算成月度约为 Premium 0.073 USD/GB/月、SSD/增强型 SSD 0.219 USD/GB/月（×730，推算值）。下单前请以购买页实时价格为准，本文后续算例统一采用该推断口径并已标注。

4.2 三个真实场景的月账单算例（本文推算）

看懂这三行，就看懂了 ES 的成本结构：

1. 存储费不是小钱：场景 B 里存储占了月账单的 48%。1 TB SSD × 3 节点的存储费（672.77）几乎和 3 台 4 核 16 GB 的算力费（718.32）持平。
2. 算力费随规格非线性上涨：从 2 核 8 GB（0.158）到 32 核 128 GB（2.534），节点规格翻了 16 倍，单价涨了 16 倍——但内存只涨了 16 倍、CPU 涨了 16 倍，也就是说没有"大规格更便宜"的规模红利，加节点和大规格是等价的两条路。
3. 场景 C 才是真正的成本黑洞：上亿向量的 RAG 集群月费接近 2 万美元，其中 96% 是算力费。这也解释了为什么下面两节要专门讲「Serverless」和「内存估算」——前者是低负载场景的省钱钥匙，后者是向量场景避免翻车的唯一办法。

五、Serverless 计费：流量 / 存储 / API 三项单价与官方算例

ES Serverless 是整套产品里最被低估的一条路。 它按流量资源、存储资源、服务请求三项实际用量计费，按量付费，每小时结算一次（结算上一小时用量），无需预置节点、无需运维集群。

5.1 三项计费项的官方计算公式

关键规则：被索引字段占比一般按 100% 估算（如 10 个等长同类型字段索引其中 5 个，则为 50%）；占比低于 40% 时，官方默认按 40% 计算。

5.2 Serverless 单价（USD）

5.3 官方算例：1 亿条日志/天，一天只要 0.675 USD

官方给出的场景：App 访问日志平均 100 字节/条，每天 1 亿条（约 9.3 GB 原始数据/天），数据保留 7 天，全字段建索引，用广州的 ES Serverless 分析。

这个数字值得单独回味：官方算例的 Serverless 月账单约 20.25 USD；而同样的日志量若用 3 节点 2 核 8 GB 的 PaaS 集群承载（第四节场景 A，含 1.5 TB 存储），月费是 455 USD——高出约 22 倍。 为什么差这么多？因为日志负载的写入速率是平稳的，PaaS 集群却要 24 小时按峰值规格付费，闲置算力全部由你买单。 结论很硬：低到中等且平稳的日志量，优先 Serverless；只有当写入量持续高于单集群能力、或需要复杂聚合与自定义插件时，才值得上 PaaS 集群。

六、智能搜索（Intelligent Search / AI Search）：解析、分块、向量化、重排单价

ES 还内置了 智能搜索开发服务（Intelligent Search Development，AI Search）——一套把「文档 → 解析 → 分块 → 向量化 → 重排 → 入库」全流程原子化的服务，专门服务 RAG / 企业知识库场景。这部分的计费独立于集群，单独按原子服务用量计费。

6.1 按量（后付费）单价

计费细则（官方）：DOC / DOCX / PPT / PPTX / PDF 按页计费；JPEG / PNG 等图片格式每张算一页；XLSX / TXT / MD / CSV 每个文件算一页；TXT / MD / XLSX / XLS 走 doc-chunk 只有工程解析不收费（但分块仍按 token 计费）。

6.2 资源包（预付费）价格

结算顺序：免费额度 > 资源包 > 后付费。开启原子服务后，每个通过实名认证的主账号共有 100 次免费测试额度（所有原子服务共享），用完自动转为后付费（除非买了资源包）。调用失败不计费。 后付费开关每月最多变更 5 次，约 10 秒生效。

⚠️ 注意「抵扣系数」这个坑：资源包消耗量 ≠ 实际用量，而是 实际用量 × 抵扣系数。例如 doc-chunk 的系数是 0.00066667（极低，等于几乎不耗包），而 doc-tree-chunk 是 1。官方算例：用 10 亿 tokens 的 doc-chunk + 100 万 tokens 的 doc-tree-chunk，实际扣除 = 10 亿 × 0.00066667 + 100 万 × 1 = 166.667 万 tokens。买资源包前先算清楚你要用的模型系数，否则买错规格会浪费大半。

七、容量规划：存储公式、写入能力、向量内存估算（含官方算例）

这一节是全文最"值钱"的部分——因为 ES 选型翻车几乎都不是"买小了"，而是"没算过"。

7.1 存储容量公式（文本搜索 / 日志场景）

官方影响因素：副本数（默认且推荐 1）+ 数据膨胀（索引、列存等，一般膨胀 10%）+ 内部任务开销（段合并、Translog、日志，约占 20%）+ OS 预留（Linux 默认 5%）。

实际占用空间 = 源数据 × (1 + 副本数) × (1 + 数据膨胀) ÷ (1 − 内部任务开销) ÷ (1 − OS 预留)
            ≈ 源数据 × (1 + 副本数) × 1.45

官方再要求预留至少 15% 存储空间，因此申请容量：

申请容量 = 源数据 × (1 + 副本数) × 1.45 × (1 + 15%) ≈ 源数据 × (1 + 副本数) × 1.67

记住这个 1.67：1 主 1 副本时，你的原始数据每 1 GB，实际要买 1.67 GB。 这是所有 ES 容量估算的起点。

7.2 算力容量评估（写入能力经验值）

关键结论：实例性能随总算力线性扩展——日志场景官方示例：8 核 32 GB 可支撑 20,000 写入/秒。文本搜索场景反过来：先按存储选规格，再压测调优，因为查询复杂度差异太大，公式化预测不可靠。

7.3 向量场景的内存估算（RAG 成败的关键）

向量检索的核心不是 CPU，是内存。 官方明言：内存不足导致检索频繁落盘时，性能可下降 10 倍以上。 计算分两步：

第 1 步 向量内存（堆外）
向量内存 = (单个向量大小 × 向量维度) × 向量数 × (1 + 副本数) × 1.1
          （系数 1.1 = 预留 10% 图索引临时空间）

若启用量化（通常向量数 > 1 亿时考虑）：
向量内存 = (单个向量大小 × 量化压缩比 × 向量维度 + 量化额外内存) × 向量数 × (1 + 副本数) × 1.1
          （int8 压缩比 1/4，bbq 压缩比 1/32；bbq_hnsw 的额外内存 float/bfloat16 时取 14，其他可忽略）

第 2 步 总内存
总内存 = 向量内存 + 堆内存
          （单机内存 ≤ 32 GB 时堆内存按 1:2 估；单机 > 32 GB 时固定 32 GB）

官方算例：1 亿条 1024 维 float 向量，1 主 1 副本

这张表的杀伤力在于：同样的 1 亿向量，开不开量化决定了你要买 10 台还是 3~4 台 32 核 128 GB 节点——按第四节场景 C 的单价，10 节点是 19,245 USD/月；3~4 节点只需 5,774–7,698 USD/月，一年差距 13.9–16.2 万美元。 这就是为什么下一节要专门讲量化。

八、高可用：多可用区部署、副本与分片规划

8.1 多可用区（Multi-AZ）灾备

• 前提：启用多 AZ 灾备必须先开至少 3 个专有主节点，因此需选择支持多 AZ 的至少 3 个数据中心；当前仅在部分主力地域支持（如北京、上海、广州），其他地域逐步开放。
• 自动行为：选定多 AZ 后，数据节点数量会按 AZ 数量自动等比调整，专有主节点默认强制开启（可选 3 或 5 个），并均匀分布在 3 个 AZ——保证任一 AZ 故障时，不会出现"过半节点不可用"，始终有可选举节点组成法定人数（quorum）。
• 生效原则（两条硬要求）：

1. 数据节点数必须是 AZ 数量的整数倍（2 AZ 灾备则用 2、4、6、8… 个数据节点）；
2. 每个索引分片至少设 1 个副本，确保始终有 >2 份数据副本。

• 流量层：ES 在 VPC 内提供 VIP 负载均衡，绑定所有数据节点；带健康检查，节点连续多次无响应会被临时摘除，AZ 级故障可做到业务无感切换（imperceptible failover）。

8.2 分片规划阈值（官方经验值）

实操建议：数据量大时不要把所有数据塞进一个索引——否则每次查询都要扫描整个索引。建议按类别拆分索引（按部门、按产品类型等），并提前评估数据量与未来增长。

九、日志检索实战：索引进数据、Kibana 看数据、Watcher 告警

日志场景是最典型的 ES 用法：写多读少、算力主要消耗在写入。落地四步：

① 开启前先算存储：源日志量 × (1 + 副本) × 1.67 = 申请容量。建议先按存储定规格，再用 7.2 节的「2 核 8 GB ≈ 5,000 写入/秒」反推算力够不够。

② 建索引时按上表设分片，例如 10 个数据节点、预估 300 GB 数据：

PUT /app-logs-000001
{
  "settings": {
    "index": {
      "number_of_shards": 10,
      "number_of_replicas": 1
    }
  },
  "mappings": {
    "properties": {
      "@timestamp": { "type": "date" },
      "level":      { "type": "keyword" },
      "service":    { "type": "keyword" },
      "message":    { "type": "text" }
    }
  }
}

分片数 10 = 数据节点数 10（1:1，便于均匀分布）；单分片约 30 GB，落在 20–50 GB 的官方推荐区间。

③ 采集写入：官方支持两种路径——用 ES 自带的 Beats 直投，或经 Logstash 做自定义转换与解析后再入集群；也可用 RESTful API 自研客户端。注意：集群在 VPC 内，采集器必须同 VPC，公网调试需走 VPN / 专线。

④ 可视化与告警：

• Kibana 随集群免费附赠（1 核 2 GB），可走公网访问，但务必设强密码 + IP 黑白名单；
• Kibana Watcher 告警可推送到企业微信机器人（官方有专门教程）；
• 需要类 SQL 查询时，直接用官方的 SQL Support（Platinum 版含 SQL JDBC）。

"一句话"排障顺序：查询慢先看分片 → 分片过大（>50 GB）就先拆分片或加节点；写入慢先看算力 → 对照 5,000 写入/秒/2 核 8 GB 判断是不是规格不够；磁盘爆先看副本 → 冷数据下沉 COS 或改冷热分离。

十、向量检索实战：mapping、写入、KNN 查询、量化与调优

ES 8.x 起内置向量检索，官方推荐 8.16 及以上版本使用混合（向量 + 文本）检索。核心流程如下。

① 建向量索引（官方示例结构）：

PUT /book-index
{
  "settings": {
    "index": {
      "number_of_shards": 3,
      "number_of_replicas": 1,
      "refresh_interval": "1s"
    }
  },
  "mappings": {
    "properties": {
      "id":            { "type": "keyword" },
      "category":      { "type": "keyword" },
      "price":         { "type": "integer" },
      "title_text":    { "type": "text" },
      "title_vector":  {
        "type": "dense_vector",
        "dims": 768,
        "similarity": "cosine",
        "index_options": { "type": "hnsw", "m": 16, "ef_construction": 100 }
      }
    }
  }
}

关键参数：

• dims 必须严格匹配写入向量的维度，最大 4096；维度越高信息越丰富、精度越高，但存储与计算成本也越高。建议先用 384 或 768 维测试召回，不达标再升维，达标了就试着降维。
• index_options.type 默认值随版本变化：8.13 为 hnsw、8.16 为 int8_hnsw、9.1.3 为 bbq_hnsw。hnsw 建议用于向量数少于 1 亿的场景。

② KNN 查询与参数调优：

GET /my-index/_search
{
  "size": 3,
  "knn": {
    "field": "title_vector",
    "query_vector": [-5, 9, -12, "..."],
    "k": 10,
    "num_candidates": 100
  },
  "fields": ["category"],
  "_source": false
}

• k：要召回的结果数；
• num_candidates：每个分片上搜索的候选向量数，必须 ≥ k，一般设为 k 的 5–10 倍以平衡召回与延迟；量化或带过滤时提高它可改善召回；
• 避免返回向量字段：向量字段通常很大——只需少量非文本字段时用 fields 显式指定（走 doc_values / stored 值，免解析 _source）；需返回大量字段或文本字段时用 _source: false 或排除向量字段，减少网络与序列化开销。

③ 量化（Quantization）——上亿向量的必选项

官方定义：向量规模达到上亿甚至数十亿时，内存占用高、计算慢，量化是此阶段的重要优化策略——本质是有损压缩，把 32 位浮点（float）转成低精度表示（如 8 位整数 int8）。

官方实例：40 GB 的 float 向量用 int8 量化，会额外占 10 GB 磁盘（总占 50 GB），但内存降到 10 GB。

两阶段检索机制：粗排（用量化向量在 HNSW 图上搜，每分片返回 num_candidates 个候选）→ 精排（通过 rescore_vector 指定过采样倍数，从磁盘读原始 float32 向量重算，选出 top k）。

⚠️ 向量场景三大坑：

1. 内存不足 → 性能掉 10 倍以上（官方原话）。先按 7.3 节算内存，再选规格。
2. 复杂度量化的精度损失与数据规模强相关：数据集越大，量化的召回损失越小——务必在尽可能大的数据集上验证最终召回，小数据集上调好的参数到大集群可能翻车。
3. script_score 暴力向量检索要谨慎用（官方有专文警告），优先走 knn + HNSW 索引路径。

十一、避坑指南：版本生命周期、VPC 不可改、六条硬规则

ES 版本生命周期（官方表，截至 2026-10 采集）：

新集群选版建议：直接上 GA 版本——向量/混合检索选 8.16.1（官方推荐 8.16+），追求最新特性选 9.1.3（默认 bbq_hnsw，省内存）；已有 7.5.1 / 8.8.1 / 8.11.3 / 8.13.3 的尽快升级或迁移（这些都已 EOM 或临近 EOS，官方有专门的《升级 ES 集群》《迁移 ES 集群》文档）。

相关阅读

• 腾讯云国际版日志服务 CLS 实战：日志采集、检索与告警全解析
• 腾讯云国际版 EMR 弹性 MapReduce 大数据集群实战
• 腾讯云国际版 CKafka 消息队列实战指南（2026）
• 腾讯云国际版云监控与可观测性实战：指标、日志、告警一体化
• 腾讯云国际版成本优化与架构选型实战

🚀 需要腾讯云国际版 Elasticsearch Service 的选型建议与专属折扣？ 无论是每天几百万条日志的 Serverless 按量方案，还是上亿向量的 RAG 检索集群，我们都能按你的真实数据量、写入速率与查询画像，给出节点规格、存储容量与月度预算的组合方案——把每一美元都花在刀刃上。

本文由 4.chengzicloud.cloud 提供，点击访问首页了解更多。