向量化服务的特点
向量化模型的调用模式与生成模型不同：输入一段文本、输出一个定长向量，没有逐 token 生成的过程，因此单次延迟低、吞吐高。部署上通常用专门的推理服务框架，容器内监听固定端口，提供向量接口与兼容接口。它与检索链路直接挂钩，换模型意味着向量空间变化，索引必须重建。
容器部署示例
容器部署示例
# 启动向量化服务：指定模型、映射端口与数据卷
docker run -d --gpus all -p 8080:80 \
-v /data/embed:/data \
ghcr.io/huggingface/text-embeddings-inference:latest \
--model-id BAAI/bge-large-zh-v1.5
# 验证接口
curl http://127.0.0.1:8080/embed -H 'Content-Type: application/json' \
-d '{"inputs": "你好，世界"}'基本信息
| 服务形态 | 专门的向量化推理服务，容器内监听 80 端口 |
|---|---|
| 接口 | 原生向量接口与兼容的向量端点，以版本为准 |
| 显存占用 | 小于生成模型，但仍需按批量与序列长度估算 |
| 部署位置 | 常与生成模型分卡或分实例，避免互相挤占 |
| 关键元数据 | 向量维度与归一化方式必须记录 |
落地要点
| 要点 | 说明 | 疏漏的后果 |
|---|---|---|
| 维度与归一化 | 记录模型输出维度与是否归一化 | 相似度计算口径不一致，检索结果错乱 |
| 批量大小 | 批量与序列长度共同决定显存 | 批量过大导致溢出 |
| 换模型流程 | 同步重建向量索引 | 新旧向量混库，检索质量崩塌 |
| 服务分离 | 与生成模型分卡或分实例 | 互相挤占显存，两侧延迟同时上升 |
| 版本记录 | 记录模型版本与索引版本 | 无法回溯检索质量变化的原因 |
典型使用场景
- 知识库构建：把文档切块后批量向量化入库
- 在线检索：用户提问即时向量化后做相似度召回
- 多语言场景：选择支持目标语言的向量模型
- 检索质量优化：更换向量模型并重建索引后对比召回效果
- 批量重建：模型升级后离线重跑全部语料，避免在线等待
向量服务请求量大且延迟敏感，常与生成模型分卡部署：混在一张卡上时，生成请求的长占用会拖慢检索环节。
不同模型的向量维度与归一化方式不同：切换模型必须同步重建索引并回归检索质量，否则表现的退化很难归因。