Serving Embeddings at Scale — Your Vector Infra Stack?

Our embedding service went from "a script" to "critical path" and suddenly we're thinking about batching, GPU utilization, and model versioning for something that just turns text into vectors. What does your embedding serving stack look like — dedicated GPUs, shared inference cluster, or a managed API you stopped fighting?

向量服务一旦进入关键路径，建议先把三个问题拆开治，而不是一开始就争论专用卡还是托管接口。第一是批处理：不要按固定条数攒批，要按总 token 数加等待时间上限动态成批，长短文本分桶，避免一条长文本拖住整批；离线批量入库和在线查询要分开队列，否则重建索引的高峰会直接挤占查询延迟。第二是利用率：向量模型本身算力需求远低于生成模型，单请求跑不满卡是常态，关键是并发批处理和多实例共享，监控应看每秒 token 数和批处理平均规模，而不是只看显存占用。第三是版本管理最容易被低估：模型版本、向量维度、归一化方式必须随每条向量一起记录，换模型不能只换服务，要制定旧向量的重算或双写策略，否则新旧向量混在一个索引里，召回质量会无声下滑。我的取舍是：流量稳定且对延迟和成本敏感时用共享推理集群加独立队列；只有当向量服务成为核心收入链路、需要精细的批处理调优时，才值得单独占卡。