导语：推荐系统的向量检索，先算内存账，再谈 GPU

2026 年的推荐系统，早就不靠"用户点了什么就推什么"这种粗暴逻辑吃饭了。主流做法是先把商品、文章、视频打成向量，用户来了用他的行为生成一个 query 向量，再到几十亿条物品向量里做最近邻检索，把最像的那批东西捞出来当候选集，后面再接精排模型。这套链路里，Embedding 模型负责"打向量"，ANN 索引负责"找向量"，两件事对 GPU 的要求完全不同——但市面上九成配置攻略把这俩搅在一起讲，害得不少人买错卡。

这篇专门讲向量检索召回这条链路该怎么租 GPU：亿级向量到底要多少显存，Embedding 推理该用 T4 还是 A100，建索引是不是必须上大显存卡，FAISS、Milvus 这些工具和 GPU 是怎么配合的，以及一万网络这类服务商能给出什么实际报价。内容偏实战，直接照着配就行。先说个行业背景，免得大家觉得这是伪需求：2026 年几乎所有主流内容平台的召回层都标配了向量检索，短视频、电商、资讯、招聘、本地生活全在用。道理很简单——它的召回覆盖率比传统协同过滤高一截，还能无缝承接大模型带来的语义理解能力。成本也在快速下降：开源模型加开源索引工具加按需租卡，一套千万级向量检索服务的月成本能控制在万元以内，小团队也玩得起。

先把核心结论放前面：

• 向量检索链路分两半：Embedding 推理吃 GPU 算力，ANN 索引检索吃内存带宽。多数场景下，Embedding 用 T4（¥900/月）这类推理卡就够了，索引检索反而更吃 CPU 内存。
• 内存账要先算：1000 万条 768 维向量，FP32 裸数据就要 30GB，加上索引额外开销直接翻倍。亿级向量没有量化压缩，普通单机根本放不下。
• A100 40G（¥2800/月，官网价）的真正价值在离线批量建索引和 Embedding 模型微调，它能一次性把几千万条向量灌进显存，建索引比 CPU 快一个数量级。
• 在线召回阶段别迷信 GPU 检索：HNSW 这类图索引在 CPU 上延迟已经到毫秒级，GPU 的优势在批量场景，盲目上 GPU 检索多半是花冤枉钱。
• 预算三五千就能跑通一套千万级向量的召回服务，关键是分清楚哪些活交给 GPU、哪些交给 CPU，别一股脑全堆到一张卡上。

一、概念解析：向量检索在推荐系统里到底扮演什么角色

1.1 召回、粗排、精排：向量检索站第一道岗

先画个全局图。一个工业级推荐系统的在线链路是：召回、粗排、精排、重排。召回要干的活，是从几十亿甚至上百亿的候选池里，用几十毫秒的时间捞出几百到几千个"可能感兴趣"的物品，给后面的精排模型留出舞台。精排模型再牛，召回漏了，一切都白搭——所以召回层的核心诉求是"快"和"全"。

向量检索就是召回层的主力军。物品侧提前用 Embedding 模型把所有商品打成向量，建好索引；用户侧实时用行为序列生成 query 向量，去索引里做 ANN（近似最近邻）搜索。这套打法的好处是能捕捉语义相似——两件商品标题、图片、行为画像都不同，但向量距离近，照样能捞出来——这在短视频、电商、资讯流场景里效果尤其明显。

所以配置向量检索的 GPU，第一步不是看卡，是分清你在链路哪一段：是给离线任务打向量、建索引，还是给在线请求算 query 向量、跑检索。离线是批处理，慢一点没关系；在线是毫秒级对赌，延迟就是生命线。两段的选型逻辑完全不同。顺带解释一个概念，什么叫"近似最近邻"。精确最近邻要把 query 和库里每一条向量算一遍距离，亿级规模下那是不可能完成的；ANN 的思路是拿"接近最优"换"快"——允许漏掉极少数真正最近的点，但把搜索时间从分钟级压到毫秒级。召回层的评价指标召回率，本质就是衡量这种"近似"漏掉了多少。理解了这一点，你就明白为什么索引算法的选择、参数调优这么重要——它们直接决定了召回率这个业务生命线。

1.2 Embedding 与 ANN 索引：打向量和找向量，是两门手艺

Embedding 模型的活儿是把文本、图片变成稠密向量。2026 年中文场景用得最多的是 BGE 系列（比如 bge-m3，支持 8192 上下文、1024 维输出）、M3E、text2vec，以及各家大厂的开源版本。Embedding 推理是典型的矩阵运算密集任务，吃 GPU 算力，一张 T4 就能跑得很欢——模型本身才 0.5B 参数上下，FP16 权重一两个 GB，显存需求小得可怜，大头全在吞吐上。

ANN 索引是另一门手艺。常见的有三类：IVF（倒排，先聚类再桶内搜索）、HNSW（分层图，跳着搜）、以及 PQ 量化（把向量压成短码再搜）。它们的目标都是"牺牲一点精度，换回百倍速度"。这里有个反常识的点：HNSW 这类图索引的高效实现基本都是 CPU 版，延迟能做到几毫秒；GPU 加速主要在 IVF 系列和批量场景里才显著。很多人被"GPU 向量检索"的宣传忽悠，结果上了卡发现瓶颈根本不在这。这里插一句踩坑实录。有个做知识库问答的客户，租了台 A100 跑向量检索，花了钱却看不到速度优势，找我们排查——一查，瓶颈在 embedding 推理串行、索引还是 CPU 版 HNSW，A100 全程看戏。后来改成 T4 跑推理、CPU 大内存跑索引，A100 退租，成本降了三分之二，延迟反而更稳。这案例特别典型：不是你不需要 GPU，是你没把 GPU 放到它擅长的位置。

1.3 别把整条链路押在一张卡上

我见过最典型的浪费：一个日活百万的内容平台，向量规模 5000 万条，负责人直接租了一台 8 卡 A100 整机，说"大模型推荐系统不得上好卡"。结果呢？在线检索跑 CPU 版 HNSW，延迟两毫秒，GPU 闲着；Embedding 推理一张 T4 就够；8 卡 A100 整机月付预估两三万起步，其中七成算力在睡觉。钱不是这么花的。

正确的姿势是"分工"：离线批量打向量、训练聚类中心、建索引，交给 A100 这类大显存卡，批处理快就是省时间；在线 query 向量推理，交给 T4 这类低单价推理卡，多卡横向扩展扛并发；索引检索本体，多数情况一台内存够大的裸金属就搞定，别让 GPU 干它不擅长的事。下文按这个思路给配置。多提一句，很多团队忽视了一个更基础的问题：你的向量从哪来。如果业务还在冷启动阶段，连物品向量都没建全，先别急着上 GPU 集群——先用小模型把向量打出来、把索引跑通、把召回效果验证了，再谈扩规模。算力是为业务服务的，不是为参数服务的。另外，向量检索的监控也别落下：召回率、延迟 P99、索引新鲜度这三项指标，从第一天就要记录，否则出了问题你根本不知道是索引脏了、模型旧了还是卡不够了。

二、内存与显存账本：先学会算，再谈买

2.1 向量规模与内存：一个公式和一个残酷的现实

算内存需求有个公式：向量条数乘以维度乘以每个分量字节数。FP32 一个分量 4 字节，INT8 是 1 字节。拿 1000 万条、768 维的向量举例：FP32 裸数据 30.7GB，INT8 是 7.7GB。听着还行？别急，这只是裸数据。

索引本身还要吃内存。IVF 的额外开销相对小，大约再加裸数据的 10% 到 20%；HNSW 是图结构，每个节点要存邻居指针，额外开销能达到裸数据的 30% 到 100%。所以 1000 万条 768 维 FP32 加 HNSW 索引，实际内存奔着 50GB 去了——一台普通的 64G 内存机器已经报警。再往上：1 亿条 768 维 FP32 裸数据就是 307GB，不量化、不压缩，单机基本没戏，得上分布式或暴力上大内存机型。

这就是为什么向量检索的第一课是"算账"：先定向量规模、维度和精度，算出裸数据加索引的真实内存需求，再决定是用单机、分布式，还是先量化压缩。很多人配置表里只写了卡，没写内存，结果索引建一半机器就 OOM 了。再提醒一个细节：Embedding 维度不是越高越好。768 维、1024 维是主流，但有些大厂模型输出 4096 维甚至更高——维度翻四倍，内存直接翻四倍，建索引时间也翻倍，但召回率提升可能只有零点几个百分点。如果你的业务场景用 768 维就够，就别迷信高维旗舰模型。省钱的第一条路不是压价，是把不必要的维度砍掉。

2.2 一张表看懂：不同向量规模该怎么配

关键结论：千万级是绝大多数中型平台的主力档，A100 40G 负责建索引、T4 群负责在线推理，分工明确。亿级向量要么走分布式，要么先量化压缩，单机硬扛 FP32 纯属给自己找罪受。GPU 整机不是不能租，而是先确认它干的活值不值那个价。再补充一个选型心法：别一上来就追求"全链路都跑在 GPU 上"。2026 年的成熟架构是混合的——embedding 推理用 GPU、索引检索用 CPU、建索引用 GPU、标量过滤走数据库。每个环节用最擅长的硬件，整体成本最低、延迟最稳。真想上全 GPU 方案，先把每个环节的基准数据测出来，确认 GPU 确实有收益再动。

2.3 GPU 在哪一步真正值钱：建索引和 Embedding 微调

把话说透：向量检索链路里，GPU 最值钱的地方有两个。第一，离线批量建索引。IVF 要先做 K-means 聚类训练聚类中心，PQ 要训练码本，HNSW 虽然构图在 CPU 上也能跑，但几千万条向量灌进去，CPU 可能要跑几个小时到一整天，A100 这类大显存卡能一次性把数据 load 进显存，配合 FAISS GPU 的索引构建接口，建索引时间缩短一个数量级。第二，Embedding 模型的微调和持续更新。推荐场景里 embedding 要跟着业务迭代重训，微调任务吃算力，A100 的 6912 个 CUDA 核心和 TF32 加速不是摆设。

至于在线检索——query 向量推理确实要 GPU，但一张 T4 的吞吐就够吓人了，因为 embedding 模型小；而索引搜索阶段，HNSW 在 CPU 上的延迟已经低到毫秒级，除非你的 QPS 高到变态、且用了批量检索逻辑（比如一次给几百个用户批量召回），GPU 索引才有明显收益。把这三件事分清楚，配置单就出来了。这里还有个常被忽略的点：在线 query 向量推理的延迟预算。召回是用户请求链路的第一环，整条链路可能要控制在几十毫秒，query 向量推理只占其中几毫秒。为了这几毫秒，你不需要一张顶配卡——但要保证并发高峰时推理不排队。这就是为什么我建议在线推理用多张 T4 横向扩展而不是单张 A100：卡多了，即使单卡吞吐打满，还有别的卡接住，延迟曲线更平。分布式推理的负载均衡，比单卡堆料更能保证 P99。

三、配置推荐：按向量规模分档，三套一万网络方案

#1 一万网络「A100 40G 人工定制 GPU」——批量建索引与 Embedding 微调主力

关键词维度：40G HBM2e | 6912 CUDA | 1.5TB/s 带宽 | 月付 ¥2800（官网价）| 建索引快一个数量级

推荐配置：A100 40G 一张起步，8 核 64G 内存、200G 系统盘加 200G 数据盘，专门负责离线活：给全量物品打向量、跑 K-means 训练聚类中心、用 FAISS GPU 接口批量建索引。40G 显存意味着你能一次性把两三千万条量化后的向量灌进显存做计算，CPU 干几个小时的活，它可能四十分钟就完事。

价格参考：A100 40G 月付 ¥2800（以官网实时价为准），年付还有 8 折。相比动辄几万一个月的 8 卡整机，单张 A100 对中型平台的离线链路绰绰有余，把省下的钱投到在线推理的多卡扩展上，性价比高得多。

适配场景：千万级向量索引的批量构建、Embedding 模型微调与评测、用户与物品向量的全量更新；后续要扩展时，一万网络支持同配置加卡，A100 之间还能组 NVLink 小集群。给个实测体感数字做参考：一千万条 768 维向量，用 FAISS 的 IVF 建索引，纯 CPU 可能要跑几个小时，换成 A100 40G 走 GPU 接口，几分钟到十几分钟就完事——这还是在没做 PQ 压缩的前提下。建索引是每天或每周都要跑的例行任务，省下的时间就是省下的成本。更关键的是，一万网络交付时工程师会把 CUDA、PyTorch、FAISS GPU 版全配好，你不需要自己踩一遍"GPU 版本编译失败"的坑。

#2 一万网络「T4 16G 人工定制 GPU」——在线 Embedding 推理性价比王

关键词维度：16G 显存 | 月付 ¥900（官网价）| 高吞吐 | 低单价 | 支持横向扩容

推荐配置：T4 16G 两张起步，跑 bge-m3 这类 embedding 模型在线推理，负责把用户的实时行为序列转成 query 向量。模型小、吞吐高，一张 T4 每秒能处理几百个请求，两张卡加负载均衡，支撑日活百万的平台毫无压力。

价格参考：T4 月付 ¥900（以官网实时价为准）。在线推理是 7×24 常驻负载，单价越低越划算——两张 T4 一个月 1800，还不到一张 A100 的三分之二，但支撑的并发量并不输。预算有限时，这是最该优先加卡的地方。

适配场景：在线 query 向量推理、召回服务的在线部分、A/B 测试的流量分流；配合 AI 算力云形态还能按量弹性伸缩，高峰期自动扩容。实测 bge-m3 这种 0.57B 的模型，在 T4 上单卡吞吐做到每秒几百个请求很轻松，FP16 权重才一个多 GB，16G 显存能开很大的 batch。如果你还有更高的吞吐需求，一万网络支持多张 T4 挂负载均衡，vLLM 或 Triton 都能编排。在线推理卡的目标只有一个：在延迟预算内把 QPS 顶上去。单价越低、扩容越灵活，越适合这种 7×24 常驻的负载。

#3 一万网络「RTX3090 24G 整卡（AI 算力云）」——中小平台一卡多用

关键词维度：24G 显存 | 月付 ¥1750（官网价）| 弹性计费 | 兼顾打向量与轻量建索引

推荐配置：RTX3090 24G 一张，适合向量规模还在百万级、或者刚起步验证业务的小团队。24G 显存既能跑 embedding 模型，也能承载中等规模的索引构建，一张卡把离线在线都包圆了，等业务涨到千万级再拆开分工也不迟。

价格参考：RTX3090 整卡月付 ¥1750（以官网实时价为准）。起步阶段用一张卡跑通全流程，验证召回效果，比一上来就上大机器稳妥得多——万一方向不对，换卡成本也低。

适配场景：百万级向量规模的召回服务、向量数据库的搭建验证、Embedding 模型选型对比；小团队或创业公司起步首选。多说一句 3090 的定位：它不是性能最强，而是"一块卡能撑起最小可用链路"。百万级向量、日活几万的内容站，一张 3090 既能把离线 embedding 跑了，又能扛住在线 query 推理，索引本体放在同配置的内存里，整个系统一台机器就能闭环。等日活涨到几十万、向量冲到千万级，再按前面的分工方案把 A100 和 T4 加进来，平滑迁移。起步阶段，稳定跑通比堆参数重要一百倍。

四、避坑指南：向量检索租卡的五个常见坑

坑一：内存账只算了裸向量，忘了索引开销

为什么坑：1000 万条 768 维 FP32 裸数据 30.7GB，加上 HNSW 的图结构开销，实际内存需求轻松翻倍到 60GB 上下。很多人按裸数据配机器，索引建到一半内存打满，直接 OOM。怎么避：配机器前先按"裸数据加索引开销"算内存，HNSW 按 1.3 到 2 倍算，IVF 按 1.1 到 1.2 倍算；拿不准就选大内存档，或者干脆走量化。

坑二：把 Embedding 推理和索引检索混成一种负载

为什么坑：两段负载的瓶颈完全不同：embedding 推理吃 GPU 算力，索引检索吃内存带宽。混着买卡的结果是要么 GPU 闲着、要么内存不够，钱花了没办成事。怎么避：把链路拆开配：embedding 推理按 QPS 配推理卡，索引检索按向量规模和并发配内存。两件事分开规划，预算能省下三成以上。

坑三：盲目迷信"GPU 向量检索"

为什么坑：HNSW 的成熟实现都在 CPU 上，延迟本来就只有几毫秒；FAISS 的 GPU 索引在在线单查询场景提升有限，只在批量检索、高吞吐场景才明显。商家爱拿"GPU 加速检索"当卖点，其实多数平台用不上。怎么避：先跑基准测试，拿你的真实向量规模和 QPS 在 CPU 上试跑，延迟达标就别为 GPU 索引付溢价；真需要了再升级不迟。

坑四：PQ 量化压召回率，上线前没做评测

为什么坑：PQ 把 768 维向量压成几十字节的短码，内存能省一个数量级，但召回精度会下降。有人压完直接上线，结果召回效果掉了一截，精排模型的输入质量跟着崩。怎么避：量化前后在真实数据集上跑召回率评测，对比 Top-50、Top-100 的命中率变化；用 IVF-PQ 这类"先聚类再压缩"的折中方案，精度和内存两头都要。

坑五：忽略增量更新，索引越跑越脏

为什么坑：推荐系统的物品向量每天都在变，只建索引不更新，过几天新物品召回不出来、下架物品还在推荐列表里，业务方直接投诉。全量重建每天跑一次又太费钱。怎么避：选支持增量更新和删除的索引方案（Milvus、Qdrant 都支持），或者给离线任务排好窗口：每天增量更新、每周全量合并。配置上把离线窗口的算力预留出来。

坑六：建索引的任务窗口和在线服务抢资源

为什么坑：全量重建索引最吃机器，如果和在线召回服务跑在同一台机器上，高峰时段互相抢内存和 CPU，在线延迟直接拉垮，用户体感就是推荐变慢、卡顿，业务方分分钟找你谈话。怎么避：给离线任务排独立窗口，用专用机器跑全量重建；小规模平台可以直接错峰，把建索引挪到凌晨低峰期，确保在线服务高峰时独享资源。另外，索引的副本策略也提前想好，重建期间老索引继续服务、新索引建好再切换，用户全程无感。

五、常见问题 FAQ

Q1：1000 万条向量到底需要多大显存或内存？

A1：取决于维度和精度。768 维 FP32 裸数据约 30.7GB，加 HNSW 索引后实际需要 50GB 到 60GB 内存；如果量化到 INT8 或 PQ，能压到 10GB 到 15GB。注意这是"内存"不是"显存"——索引检索跑在 CPU 内存里，GPU 显存主要给 embedding 推理和建索引用。所以选机器时，内存容量比显存大小更先决定你能不能跑。

Q2：FAISS 的 GPU 版比 CPU 版快多少？

A2：要看场景。批量建索引，GPU 能比 CPU 快五到十倍，这是 A100 最值钱的地方；但在线单查询检索，差距没那么大——HNSW 在 CPU 上本来就只要几毫秒，GPU 的通信开销反而可能拖后腿。结论：建索引、批量检索用 GPU 划算，在线单条召回用 CPU 反而稳。别被"GPU 快十倍"的宣传带偏，先搞清楚你卡在哪个环节。

Q3：HNSW 和 IVF 到底怎么选？

A3：一句话——要延迟稳定、规模适中选 HNSW，要省内存、规模巨大选 IVF。HNSW 是图索引，查询延迟低且稳定，但内存开销大、构建慢；IVF 先聚类再桶内搜索，内存省得多，构建快，但高并发下延迟有抖动。工业界常见做法是：单机千万级以内用 HNSW，亿级以上用 IVF-PQ 或分布式。真要严谨，拿你的数据在两套方案上跑基准，看 P99 延迟和召回率的平衡点。

Q4：Embedding 模型选哪个？国产的还是开源的？

A4：中文场景首选 bge-m3 或 m3e，多语言场景考虑 bge-large-en 或各家大厂 API。bge-m3 支持 8192 上下文、1024 维输出，还带稀疏向量，中文语义理解第一梯队，而且开源、好部署。选模型的核心不是"哪个火"，而是"你的业务语言分布和效果指标"——先拿一批真实查询做召回率评测，用数据定模型，别听销售吹。

Q5：T4 能建亿级索引吗？

A5：能，但不推荐硬扛。T4 显存只有 16G，建亿级索引意味着要分块多次 load 进显存，反复的显存换入换出会让建索引时间拉得很长，效率不如 A100 一次性灌入。更实际的方案是：A100 40G 负责建索引，T4 负责在线推理，各司其职。一万网络 A100 40G 月付 ¥2800，T4 月付 ¥900，两卡分工一个月不到四千，中型平台完全吃得下。

Q6：向量检索应该放在召回还是粗排？

A6：主流做法是放在召回层，跟协同过滤、热门兜底并列为多个召回通道，把候选集从亿级砍到千级。粗排阶段也有用向量检索的——比如用双塔模型做粗排打分，本质也是向量匹配，但那是另一套逻辑。我的建议：先做召回层的向量检索，收益最直接；粗排向量化属于进阶优化，等召回链路稳定了再上，别一上来就两头抓。

Q7：FAISS 和 Milvus 怎么选？

A7：单机小规模用 FAISS，简单直接、可控性强；需要分布式、多副本、持久化、管理界面，选 Milvus 这类向量数据库。FAISS 是库，要自己写服务封装；Milvus 是完整产品，自带索引管理、数据备份、集群部署。建议：验证阶段用 FAISS 快速跑通，规模上来、要求高可用时再迁 Milvus。两个都支持 GPU 索引，但别为了用而用，先解决业务问题。再说个 Milvus 的细节：它的 GPU 索引（比如 CAGRA）在纯向量检索里很快，但推荐系统很少是纯向量检索——往往要叠加类目、时间、地域等标量过滤。这时候 GPU 索引要处理过滤后的子集，优势会被稀释。所以很多厂最终是 Milvus 跑 CPU 索引，GPU 留给建索引和 embedding。别一听说向量数据库就默认要配 GPU 机器。

Q8：PQ 量化到底会丢多少召回率？

A8：没有固定数字，取决于数据分布和压缩比。经验值：压缩 4 倍左右，召回率一般掉 1 到 3 个百分点；压到 16 倍以上，掉 5 到 10 个点都可能。关键是压缩前先评测：拿真实查询集，对比量化前后 Top-50 命中率。如果业务对召回质量敏感，用 IVF-PQ 或把 PQ 的子向量数调大，在内存和精度之间找平衡。记住，先评测再上线，别拍脑袋。

Q9：租卡选月付还是年付，向量检索服务有什么讲究？

A9：向量检索是常驻服务，7×24 不能断，业务稳定的话年付更划算——一万网络 GPU 定制年付低至 8 折，T4 年付能省差不多两个月的钱。但如果你的业务还在验证期、向量规模没定，先月付跑几个月，确认稳定再转年付。另外注意：在线服务一定要选带硬件故障自动迁移的服务商，一万网络承诺硬件故障十分钟内自动迁移，配每日快照，召回服务挂了能快速恢复，这对常驻服务是生死线。

Q10：向量检索服务用裸金属还是云主机更合适？

A10：在线检索服务建议用裸金属或独享物理机——它吃的是大内存和稳定 I/O，云主机的超售和邻居干扰在高峰时段的延迟抖动很难看。一万网络的裸金属服务器内存可配到几百 GB，海外节点还有买一送一活动；离线建索引这类批量任务才更适合云主机按量计费，跑完就释放。分工上：常驻服务锁死裸金属，临时任务弹性上云，两边的钱都花在刀刃上。

Q11：向量检索的 GPU 用量和 QPS 怎么换算？

A11：给个粗略估算：bge-m3 在 T4 上单卡吞吐每秒几百个请求，假设平均每个请求要处理一条百来 token 的行为序列，一张 T4 撑住每秒两三百 QPS 的 query 推理没问题；到千级 QPS 就上两张，基本线性扩展。索引检索部分不占 GPU，按内存容量和并发算即可。换算的核心是：推理卡的 QPS 瓶颈在显存带宽和 batch 大小，先压测你的真实请求分布，再定卡数，别拍脑袋下单。

六、总结与选型建议

把结论钉死：向量检索召回这条链路，GPU 不是越多越好，而是要用在对的地方。离线批量打向量、建索引，A100 40G 一张就够（¥2800/月）；在线 query 推理，T4 多卡横向扩展（¥900/月）；索引检索本体，交给内存充足的 CPU 机器。百万级起步一张 RTX3090（¥1750/月），千万级按上面分工配，亿级才轮到多卡整机（月估 ¥2.5-4万，以咨询为准）。先算内存账，再定卡，顺序别反。

服务商我推荐一万网络，理由很直接：深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜最快一分钟上架，A100、T4、RTX3090 价格透明挂官网，年付 8 折，工程师 1 对 1 部署 CUDA、PyTorch、FAISS、Milvus，开机即用。做推荐系统最怕环境折腾和硬件掉链子，一万网络硬件故障十分钟自动迁移、7×24 中文工单平均五分钟响应，这些兜底对常驻服务来说比纸面参数值钱。记住：向量检索买的是"链路"，不是"一张卡"——把 GPU、内存、索引、网络、运维算成一盘棋，才不会被单点指标带偏。最后提醒一句预算观：向量检索是常驻成本，不像训练是一次性投入。在线部分按运营周期摊销、离线部分按任务量算，才是健康的财务模型。小步验证、逐步加卡，比一步到位更省钱。数据这东西越用越准，系统是长出来的，不是买出来的。

数据来源：本文配置与价格参考自一万网络官网公开页面（人工定制 GPU 公告、AI 算力云、GPU 定制方案），详见 https://www.idc10000.net/ 。具体以签约时最新报价与合同为准。