2026阿里云国际版Milvus实战教程：CU规格怎么选、香港真实CU单价、AI Hub内置大模型计费与DashVector边界

阿里云国际版的向量检索服务 Milvus 版按 CU 计费，1 CU = 1 核 CPU + 4 GiB 内存，香港地域计算节点单价 43.25 美元/CU/月、存储优化型 39.375 美元/CU/月，一个 16 CU 的计算优化型标准版实例包月 692 美元，存储另按 0.0000416667 美元/GB/小时（约 0.0304 美元/GB/月）单独出账。真正决定账单的不是"买几个 CU"，而是四件事：选 Standard 还是 StandalonePro、选单可用区还是多可用区 HA（HA 直接翻倍）、选计算优化型还是存储优化型（在大陆存储优化型贵 32%，在香港反而便宜 9%）、以及有没有用 AI Hub 把 embedding 和 rerank 也一起计费。这篇把国际站 Milvus 的 CU 规格表、香港与大陆的真实单价、三种部署形态的 SLA 与成本系数、三个可复算的账单、AI Function 的 token 价目、控制台开通与 pymilvus 代码，以及它和 DashVector 的分工边界一次讲透。

Meta Description: 2026阿里云国际版Milvus实战：1CU=1核4G、香港43.25美元/CU/月、16CU算例692美元、HA翻倍、计算型vs存储型在香港报价反转、AI Hub按token计费与DashVector边界。

关键词：阿里云国际版Milvus、Vector Retrieval Service for Milvus、Milvus CU计费、Milvus价格、向量数据库选型、AI Hub计费、DashVector、RAG 向量检索

一、先给结论：Milvus 版选型的五个决策点

搜"阿里云 Milvus 多少钱"的人，实际要回答的是五个有先后顺序的问题。顺序错了，规格一定买错——先买 4 CU 试水、发现内存不够再想升配，会撞上存储优化型"不支持升降配"这条硬限制；先选 StandalonePro、数据涨上来再想扩容，会撞上"不能原地升级到集群版、必须迁数据"。

这五点里，第 4 点最容易踩空：官方给出的容量是按"只有主键 + 向量、没有标量字段"测的，而真实业务几乎一定带标量字段（分类、时间、价格、权限），这些字段同样吃内存和存储。照表上的上限买，上线就打满。

二、它到底是什么：两个版本、三种部署形态

阿里云国际站的 Vector Retrieval Service for Milvus（控制台里叫 AISearch for Milvus）是开源自建 Milvus 的托管版：元数据服务、消息服务、Query Node、索引节点、数据节点都由平台托管，存储落在 OSS（默认同城冗余），你只负责建实例、建 collection、写数据、查数据。

2.1 Standard vs StandalonePro

注意官方文档里有一处口径不一致：FAQ 把这两档叫 "Basic Edition / Standard Edition"，而开通文档叫 "StandalonePro / Standard"，指的都是同一个东西。看到 Basic 不要以为还有第三档。

2.2 三种部署形态：SLA 与成本系数

多可用区基础版和 HA 的关键差别只有一句：基础版只有一份计算资源，主可用区挂了要在备用可用区重新拉起（RTO<1 小时）；HA 有两份计算资源同步加载数据，主备直接切换（RTO<3 分钟）。所以 HA 的成本系数是 2×，不是 1.2×。

两条硬限制写在文档里，选型时容易漏：多可用区 HA 的节点数必须是 2 的倍数（主备各一套）；多可用区 HA 不支持 Milvus 2.4 版本（版本可选 2.4 / 2.5 / 2.6）。

三、CU 怎么算：一张容量表 + 一张性能表

3.1 两种 CU 类型，能力完全不同

存储优化型的卖点是"同样的 CU 数装 4 倍数据"，代价是三条：买定不能改规格（选错只能重建）、索引只能用 DiskANN、向量必须是 float32 且距离算法只有三种。如果你的数据是二值向量、或需要 Inner Product 之外的自定义距离，选型第一步就被排除了。

3.2 容量参考表（官方实测口径）

这张表的两个前提必须记住：测试数据集只有主键和向量，没有标量字段；主键是从 0 开始自增的正整数转成的字符串。真实业务里的 category、created_at、price、tenant_id 这些标量字段既占存储也参与过滤索引，实际可存向量数会明显低于表内数字。做容量规划时按表内数值打七折，是比"照表买满"更稳的起点。

3.3 性能参考表（topk 与 QPS 的关系）

数据来自 1000 万条 768 维的 Cohere 数据集，RT_p99 是顺序跑 1000 次查询取 99 分位。同样 16 CU，计算型在 topk=100 上是 1200 QPS，存储型是 550 QPS——便宜 9% 的单价，换来的是不到一半的吞吐，这就是存储优化型真正的定价逻辑：它卖的是容量，不是性能。

还有一条容易被忽略的时序特性：Milvus 会在后台周期性优化向量索引，数据写入后通常要 3 小时内才达到最佳性能。也就是说"刚导入完就压测"得到的 QPS 数字是偏低的，压测前先等索引收敛。

3.4 节点数：1 到 50，QPS 线性增长

Query Node 数量可配 1 到 50，QPS 随节点数线性增长。生产环境建议至少 2 个节点——不只是为了吞吐，也是为了节点级故障时还有一半算力。这条和第 2.2 节的 HA 是两件事：多节点解决"单节点挂"，多可用区 HA 解决"整个机房挂"，两者可以叠加，成本也叠加。

3.5 官方算例：2000 QPS、2000 万张图，到底要几个 CU

文档给了一个完整推导，值得抄下来当模板：

• 目标：2000 万张图，每张 768 维向量，2000 QPS，topk=100，延迟 <10ms。
• 延迟过滤：只有计算优化型能满足 <10ms，存储型直接出局。
• 容量倒推：16 CU 计算型可撑 1200 万条 960 维，2000 万条 768 维至少要 2 个这样的节点，合计 32 CU。
• 吞吐校验：topk=100 时单节点 1200 QPS，要 2000 QPS 得再翻一倍节点数。
• 结论：4 个 16 vCPU 64 GiB 节点，合计 64 CU。

按后面第四节的香港单价，64 CU 计算型的 CU 部分就是 64 × 43.25 = 2768 美元/月，还没算存储。这就是"向量检索不便宜"的真实量级——它贵在常驻内存，不在磁盘。

3.6 资源计算器：8M×768 的例子和一处口径差

官方给了在线资源计算器（milvus.console.alibabacloud.com 的 sizing 页），输入向量条数、维度、索引类型、HNSW 的 M 值、是否带标量字段，实时给推荐配置。文档里的示例是：800 万条 768 维、HNSW、M=4，估算需要 31.2 GB 内存、原始数据 22.9 GB，推荐 40 核 160 GB。

这里有一处需要自己动手算的口径差：文档紧接着列出的分项是"元数据服务 1×4 核 16 GB、Proxy 1×2 核 8 GB、Query Node 2×4 核 16 GB、索引节点 1×4 核 16 GB、数据节点 1×2 核 8 GB"，把这些加起来是 20 核 / 80 GB，正好是 40 核 / 160 GB 的一半。差额不是笔误，而是 HA 副本——文档另一处明写"开启高可用会让资源需求翻倍"。所以读这张表时要先确认自己看的是"开了 HA 的总量"还是"分项之和"，照着分项买会少买一半。

另外 22.9 GB 这个数字可以自己验：800 万 × 768 维 × 4 字节 = 24.58 GB（十进制）= 22.89 GiB，对得上。按香港存储单价 0.0304 美元/GB/月算，这 22.9 GB 原始数据一个月的存储费只有 0.70 美元——再次说明 Milvus 的钱花在内存，不花在盘上。

四、真实单价：国际站 Milvus 的完整价目表

下面所有单价取自阿里云国际站帮助中心 Milvus 版的 Billing 与 Storage billing 两页（页面标注更新时间 2026 年 10 月），币种美元，未含任何促销折扣。注意：Milvus 版没有独立的 /product/milvus/pricing 页，产品页只讲能力，价格只写在帮助中心这两页里——所以网上很多"Milvus 多少钱"的文章其实是拿开源自建的成本在估，不是托管版的价格。

4.1 计算资源：按 CU 包月

文档里服务节点和计算节点在计算优化型下同价（大陆 23.5、香港 43.25），所以做预算时不用分开算——但存储优化型只在计算节点上提供，服务节点没有这个选项。

4.2 存储：按 GB 小时出账

存储费有三条容易漏的规则：第一，它独立于计算计费方式——哪怕你买的是包年包月的 CU，存储仍然按上述小时价单独出账，所以账单里永远有一条存储流水；第二，自动备份的存储用量也按这个单价收，并且已经并入存储费，不会单独列一项"备份费"；第三，实例所在地域创建后不可更改，想换地域只能新建实例迁数据。

4.3 两个反直觉的价差

价差一：香港比大陆贵 1.84 倍（计算型），但存储型只贵 1.27 倍。

• 计算优化型：43.25 ÷ 23.50 = 1.840
• 存储优化型：39.375 ÷ 31.125 = 1.265

同样搬到香港，存储优化型的涨幅只有计算型的七成。如果你的场景本来就适合 DiskANN（大容量、延迟容忍度高），香港地域的相对溢价反而更小。

价差二：计算型 vs 存储型，谁便宜在香港是反的。

在大陆，为了 4 倍容量你要多付 32% 的 CU 钱；在香港，同样的 4 倍容量反而少付 9%。原因很简单：香港的计算优化型单价被抬得更高（43.25 vs 23.5，+84%），存储优化型的涨幅只有 +26.5%，两条线交叉了。结论：在大陆选存储优化型要算清楚容量能不能吃满，在香港它几乎是默认更优选项——前提是你的延迟预算能接受 DiskANN 的吞吐水平（回到 3.3 节的表：同 16 CU，topk=100 只有 550 QPS）。

五、三个可复算的账单

以下算例全部按香港地域、包年包月、每月 730 小时，存储按 100 GB 估算，可以直接拿计算器验。

5.1 算例 A：最小生产可用（16 CU 计算型、单可用区）

这 695 美元买到的能力是：6400 万条 128 维（或 1200 万条 960 维）的 HNSW 索引常驻内存，topk=100 下约 1200 QPS，SLA 99.9%，单可用区——机房级故障无容灾能力。

5.2 算例 B：同一套改成多可用区 HA

HA 要两份计算资源，节点数必须是偶数，16 CU 直接变 32 CU：

从 A 到 B，多花 692.61 美元/月（+99.6%），换来的是 RTO 从"无"变成"<3 分钟"、SLA 从 99.9% 升到 99.95%。这笔钱该不该花，取决于业务能不能忍 1 小时不可用——如果不能忍，多可用区基础版（RTO<1 小时、计算不翻倍）是个被低估的中间档，很多团队直接跳过了它。

5.3 算例 C：存储优化型 16 CU（DiskANN）

对比算例 A：容量从 6400 万条（128 维）涨到 2.4 亿条，月费反而少 62.00 美元。代价是吞吐腰斩（topk=100 从 1200 掉到 550 QPS）、延迟从 <10ms 变成 <20ms、索引只能用 DiskANN、规格买定不能改。对"归档型语义搜索""商品库全量召回"这类场景，这是国际站最划算的一档；对实时推荐这种每秒几千次查询的场景，选它等于给自己埋雷。

5.4 算例 D：官方 2000 QPS 场景的真实月账单

按 3.5 节的结论，2000 万张 768 维图、2000 QPS、topk=100、P99<10ms，需要 4 个 16 CU 计算型节点，合计 64 CU：

存储只占账单的 0.06%。这一条彻底解释了 Milvus 的定价结构：你付的是"把索引常驻在内存里"的钱，不是"把数据存起来"的钱。所以任何"用对象存储 + 冷启动加载"的省钱思路在这里都不成立，能省的只有"把 CU 用在刀刃上"——减少副本、压 QPS 峰值、把非关键 collection 挪到存储型。

同样的 64 CU 放在中国大陆地域是 64 × 23.5 = 1,504 美元/月，只有香港的 54.3%。

5.5 按量付费：官方文档没给 CU 小时价，别硬编

文档只公布了包年包月的 CU 单价（第 4.1 节）和按小时的存储单价，没有公布按量的 CU 小时价。这意味着"按量跑多少小时比包月便宜"这个平衡点，在公开文档里是算不出来的——它只在下单页按地域实时显示。所以正确的做法是：先在购买页把同一规格的按量月价和包月价都调出来，再算平衡点；任何号称"跑满 470 小时/700 小时就回本"的固定数字，在没有按量 CU 单价的前提下都是猜的。

六、AI Hub：把 embedding 和 rerank 也托管掉，按 token 计费

Milvus 版和自建 Milvus 最不一样的地方，是它内置了一层 AI Function（控制台叫 AI Hub）：你不需要自己在外面跑 embedding 模型、也不需要自己接 rerank 服务，直接在 collection 上声明"这个字段由某个模型生成向量"，写入和查询时平台自动调模型。代价是这层能力按 token 单独计费，和 CU 账单分开出。

6.1 18 种 AI Function，分四类

这层能力直接改变了架构：传统做法是"应用侧调 embedding API → 拿到向量 → 写入 Milvus → 查询时再调一次 embedding → 召回后调 rerank"，四段网络往返、三套密钥、两处重试逻辑；用 AI Function 之后，应用只跟 Milvus 说话，中间三步在平台内部完成。代价是模型可选项受服务端 Provider 配置限制——文档明确写了"可用模型以服务端 Provider 配置为准"，不是价目表上列了就能用。

6.2 token 单价（美元 / 百万 token）

这里又出现一次"价差方向不一致"：文本 embedding 在海外组更便宜（0.084 vs 0.0864），rerank 在海外组更贵（0.12 vs 0.0828，+45%）。所以"迁到香港会更贵"这个直觉，对 CU 成立（1.84 倍），对 token 计费不成立——要看具体调的是哪个模型。价目表里图像 / 视频 token 的单价是文本的 3.7 倍（0.3096 ÷ 0.084），多模态检索的成本结构和纯文本完全不是一回事。

6.3 两个算例：一次性向量化 vs 持续 rerank

一次性向量化（1,000 万篇文档，每篇 300 token）：3,000 百万 token × 0.084 = 252 美元，一次性支出，相对 630~692 美元/月的 CU 费并不算大头。所以"用内置 embedding 会不会很贵"这个问题，对离线建库场景的答案是：不贵。

持续 rerank（每天 10 万次查询，每次精排 top-20 候选、每候选 100 token）：单次 2,000 token，每月 300 万次查询 = 6,000 百万 token × 0.12 = 720 美元/月——已经超过一个 16 CU 存储优化型实例的 CU 费（630 美元）。如果把候选数从 20 放大到 100，token 量直接 ×5，月费变成 3,600 美元，是 CU 费的 5.7 倍。

结论很反直觉但很实用：在线 embedding 便宜，在线 rerank 贵。省钱的三条具体做法是：召回阶段用向量 + 标量过滤先把候选压到 20 条以内再 rerank；对重复 query 加一层应用侧结果缓存；能用 AI_EMBEDDING_CACHE 的地方一定开，它用 Redis 精确匹配挡掉重复文本的模型调用。

七、从零开通：八步 + 一段能跑的代码

7.1 开通步骤

1. 登录阿里云国际站控制台，搜索 "AISearch for Milvus" 或 "Vector Retrieval Service for Milvus" 进入产品页。
2. 创建实例：依次选计费方式（包年包月 / 按量）、地域（创建后不可改）、版本（2.4 / 2.5 / 2.6，多可用区 HA 不支持 2.4）、部署形态（单可用区 / 多可用区基础版 / 多可用区 HA）、实例类型（Standard / StandalonePro）、CU 规格（4/8/16/32 CU）。
3. 配网络：选 VPC 和 vSwitch。建议先用内网端点，公网端点只在你确实需要从本地调试时开。
4. 填实例名、选资源组，勾选服务协议。
5. 确认订单并支付。包年包月的 CU 费用在这一步一次性出，存储费仍然按小时后续出账。
6. 等待实例创建完成（分钟级），状态变为"运行中"。
7. 在实例详情页拿内网端点 / 公网端点，端口是 19530（Milvus 的标准端口）。
8. 如果要用公网端点，必须先在实例的公网访问白名单里加入你的出口 IP，否则连接会被直接拒绝——这一步漏了会以为是端口不通。

7.2 用 pymilvus 连上去建库、写入、检索

先装 SDK，注意 MilvusClient 这个高层接口要求 pymilvus 2.4 及以上：

pip install --upgrade pymilvus

下面这段是官方 quickstart 的最小闭环：连实例、建 collection（主键 + 768 维向量 + 一个标量字段）、插入、检索。连接串换成你自己的公网端点即可：

from pymilvus import MilvusClient

client = MilvusClient(
    uri="http://c-xxxx.milvus.aliyuncs.com:19530"
)

client.create_collection(
    collection_name="demo_collection",
    dimension=768
)

res = client.insert(
    collection_name="demo_collection",
    data=[
        {"id": 0, "vector": [0.1] * 768, "color": "red"},
        {"id": 1, "vector": [0.2] * 768, "color": "blue"}
    ]
)

res = client.search(
    collection_name="demo_collection",
    data=[[0.15] * 768],
    limit=2,
    output_fields=["color"]
)

带标量过滤的检索，是把向量召回和业务条件合并的关键写法——filter 里写的是 Milvus 的布尔表达式，等价于 SQL 的 WHERE：

res = client.search(
    collection_name="demo_collection",
    data=[[0.15] * 768],
    filter='color == "red"',
    limit=10,
    output_fields=["color"]
)

三个必须知道的运行时行为：写入是异步的，插入返回成功不代表立刻能被检索到，等几秒到几分钟；索引在后台优化，官方说法是通常 3 小时内达到最佳性能，所以刚导完数据就压测会低估吞吐；collection 创建后索引自动加载进内存，这正是 CU 内存被吃掉的地方，删 collection 才释放。

想可视化看数据，可以本地跑 Attu 连这个端点；不想装客户端就直接用上面的 Python 片段验证连通性。

八、Milvus 版和 DashVector 怎么分工

同一个控制台里有两个向量检索产品，很多人第一次进来都会点错。判断标准不是"哪个更便宜"，而是"你需要多少控制力"。

一句话版：DashVector 是"够用就好"的检索服务，Milvus 版是"要自己调参、要容灾、要上亿条"的数据库。如果你现在只是给一个客服知识库做语义召回（几万到几十万条），用 Milvus 版等于拿电锯切水果——16 CU 起步的 692 美元/月买的是你用不到的能力。反过来，如果已经有千万级商品库、还要按类目 / 价格 / 库存做组合过滤，DashVector 的简单 topk 接口会很快撞墙。

站内《DashVector 向量检索指南》里有 DashVector 的规格与单价，两篇配合看能直接排出"多少条数据该用哪个"的分界线。如果你的检索需求其实来自日志或全文搜索而不是语义召回，那么先读《Elasticsearch 容量与分片规划》更省事——向量检索解决的是"意思相近"，全文检索解决的是"字面命中"，两者不能互相替代。

九、十个容易踩的坑（都来自官方文档本身）

第 9 条值得单独说一句：市面上不少文章直接给"按量跑满 470 小时 / 700 小时就该转包月"这种数字。那套算法的前提是知道按量的小时单价，而 Milvus 的公开文档只给了包月 CU 价，没给按量 CU 价——没有单价就没有平衡点，照抄别家产品的临界小时数会算错。

还有一条采购层面的事实要提醒：Milvus 版官方 FAQ 明确写了"公测期间两个版本都不提供 SLA"，而开通文档又写"Standard 版提供生产级高可用 SLA"。这两句在现网文档里同时存在，如果这个实例要承载核心业务，签合同前务必让商务书面确认 SLA 条款和赔付比例，别只信帮助中心的一句话。

十、推荐方案：三档配置，按阶段买

验证档的 176 美元这个数字是按 4 CU × 43.25 = 173 加 3.04 存储算的，注意 4 CU 只有 16 GiB 内存，装不下千万级索引，它只适合跑通链路。真要验证效果，用 100 万条真实数据 + 8 CU 更接近生产表现。

🚀 需要海外云服务器或阿里云国际版资源？通过 chengzicloud.cloud 购买享专属折扣，支持香港、新加坡、日本、美国多地域开通。