大模型 Embedding 服务的生产级部署：从批量推理到向量索引的性能优化

一、Embedding 服务的"吞吐瓶颈"：从文本到向量的工程挑战

在企业级 RAG 架构中，Embedding 服务是将文本转化为向量的核心组件。无论是文档入库阶段的批量向量化，还是查询阶段的实时向量化，Embedding 服务的吞吐量和延迟直接影响系统整体性能。一个中等规模的知识库（百万级文档片段），全量入库需要数百万次 Embedding 调用，如果单次推理耗时 50ms，串行处理需要数十小时。

更关键的是，Embedding 服务面临两种截然不同的工作负载：批量离线入库追求吞吐量，在线查询追求低延迟。同一套服务同时承载这两种负载时，资源争用和调度策略成为工程难点。

二、Embedding 推理的架构分层：从模型加载到向量索引

flowchart TD
    A[文本输入] --> B[Tokenization: 分词与截断]
    B --> C[Batch 组装: 动态批处理]
    C --> D[GPU 推理: 模型前向传播]
    D --> E[池化层: CLS/Mean Pooling]
    E --> F[归一化: L2 Normalize]
    F --> G{使用场景}

    G -->|离线入库| H[批量写入向量索引]
    G -->|在线查询| I[实时相似度检索]

    subgraph 向量索引层
        H --> J[Milvus / Qdrant]
        I --> J
    end

    subgraph 性能优化点
        K[动态批处理: 提升吞吐]
        L[FP16/BF16 推理: 降低显存]
        M[ONNX Runtime: CPU 推理优化]
        N[模型蒸馏: 小模型加速]
    end

Embedding 模型的推理流程相对简单：文本经过 Tokenizer 分词后，送入 Transformer 编码器，取 CLS Token 或 Mean Pooling 作为句子向量，再进行 L2 归一化。与生成式模型不同，Embedding 模型只有前向传播、没有自回归解码，因此批处理效率更高。

三、生产级代码实现与最佳实践

/**
 * Embedding 服务封装
 * 支持批量推理和单条推理两种模式
 */
@Service
@Slf4j
public class EmbeddingService {

    private final RestTemplate restTemplate;
    private final EmbeddingConfig config;

    /**
     * 批量向量化——用于文档入库
     * 动态调整 batch size，在显存允许范围内最大化吞吐
     */
    public List<float[]> batchEmbed(List<String> texts) {
        List<float[]> allEmbeddings = new ArrayList<>();
        int batchSize = config.getBatchSize();

        // 分批处理，避免单次请求文本过长导致 OOM
        for (int i = 0; i < texts.size(); i += batchSize) {
            List<String> batch = texts.subList(i,
                Math.min(i + batchSize, texts.size()));

            Map<String, Object> request = Map.of(
                "model", config.getModelName(),
                "input", batch,
                "encoding_format", "float"
            );

            ResponseEntity<EmbeddingResponse> response = restTemplate.postForEntity(
                config.getEndpoint() + "/v1/embeddings",
                request, EmbeddingResponse.class
            );

            if (response.getBody() != null) {
                // 按原始顺序排列结果
                List<float[]> batchResult = response.getBody().getData().stream()
                    .sorted(Comparator.comparingInt(EmbeddingData::getIndex))
                    .map(EmbeddingData::getEmbedding)
                    .toList();
                allEmbeddings.addAll(batchResult);
            }
        }

        return allEmbeddings;
    }

    /**
     * 单条向量化——用于在线查询
     * 使用独立的轻量级端点，避免与批量任务争抢 GPU
     */
    public float[] embed(String text) {
        // 截断超长文本，避免 Token 超限
        String truncated = truncateToMaxLength(text, config.getMaxTokens());

        Map<String, Object> request = Map.of(
            "model", config.getModelName(),
            "input", List.of(truncated),
            "encoding_format", "float"
        );

        ResponseEntity<EmbeddingResponse> response = restTemplate.postForEntity(
            config.getOnlineEndpoint() + "/v1/embeddings",
            request, EmbeddingResponse.class
        );

        if (response.getBody() != null && !response.getBody().getData().isEmpty()) {
            return response.getBody().getData().get(0).getEmbedding();
        }

        throw new EmbeddingException("向量化失败: " + text.substring(0, 50));
    }

    /**
     * 文本截断策略
     * 优先保留文本头部和尾部，中间用省略标记替代
     * 语义信息在首尾分布最密集，中间截断损失最小
     */
    private String truncateToMaxLength(String text, int maxTokens) {
        // 简化实现：按字符数估算（中文约 1 字符 = 1-2 Token）
        int maxChars = maxTokens * 2;
        if (text.length() <= maxChars) {
            return text;
        }
        int headLen = (int) (maxChars * 0.6);
        int tailLen = maxChars - headLen - 3;
        return text.substring(0, headLen) + "..." +
               text.substring(text.length() - tailLen);
    }
}

/**
 * 向量索引管理
 * 封装 Milvus 操作，提供集合创建、写入和检索能力
 */
@Service
public class VectorIndexService {

    private final MilvusClient milvusClient;

    /**
     * 批量写入向量——离线入库
     * 使用异步写入，不阻塞文档处理主流程
     */
    @Async("indexWriteExecutor")
    public CompletableFuture<Void> batchUpsert(String collectionName,
                                                 List<Long> ids,
                                                 List<float[]> vectors,
                                                 List<String> texts) {
        // 构建写入数据
        List<InsertParam.Field> fields = List.of(
            new InsertParam.Field("id", ids),
            new InsertParam.Field("vector", vectors),
            new InsertParam.Field("text", texts)
        );

        milvusClient.insert(InsertParam.newBuilder()
            .withCollectionName(collectionName)
            .withFields(fields)
            .build());

        return CompletableFuture.completedFuture(null);
    }

    /**
     * 向量检索——在线查询
     * 返回 TopK 最相似文档片段
     */
    public List<SearchResult> search(String collectionName,
                                      float[] queryVector,
                                      int topK) {
        List<String> outputFields = List.of("text");

        R<SearchResults> result = milvusClient.search(SearchParam.newBuilder()
            .withCollectionName(collectionName)
            .withVectors(List.of(queryVector))
            .withTopK(topK)
            .withOutputFields(outputFields)
            .withConsistencyLevel(ConsistencyLevelEnum.BOUNDED)
            .build());

        return result.getData().getResults().stream()
            .map(hit -> new SearchResult(
                hit.getEntity().get("text").toString(),
                hit.getScore()
            ))
            .toList();
    }
}

四、Embedding 服务的部署权衡：GPU 独占 vs 共享、精度 vs 速度

GPU 资源分配。Embedding 模型推理对 GPU 的利用率远低于生成式模型。一个 BERT-Large 级别的 Embedding 模型在 A10G 上推理，GPU 利用率通常不到 30%。将在线查询和批量入库部署在同一 GPU 上，批量任务会挤占在线查询的算力。建议采用"在线 GPU 独占 + 离线 CPU/Spot GPU"的分离部署策略。

精度与速度。FP16 推理在精度损失可忽略（余弦相似度偏差 < 0.001）的前提下，推理速度提升约 40%。INT8 量化对 Embedding 模型的精度影响更大，可能导致检索召回率下降 2%-5%，需在具体数据集上评估后决策。

模型选择。大模型 Embedding（如 text-embedding-3-large）的维度通常为 1024-3072，存储和检索成本随维度线性增长。Matryoshka Representation Learning 允许在推理后截断向量维度（如从 1024 截断到 256），在检索精度和存储成本之间灵活权衡。

适用边界：Embedding 服务的优化重点因场景而异。离线入库场景关注吞吐量和成本，可接受较高延迟；在线查询场景关注 P99 延迟，需要 GPU 独占保障。两者不应混部在同一推理引擎上。

五、总结

Embedding 服务的生产级部署需要区分离线入库和在线查询两种工作负载，分别优化吞吐量和延迟。核心优化手段包括动态批处理、FP16 推理、模型维度截断和 GPU 资源隔离。向量索引层的选择（Milvus/Qdrant/Weaviate）取决于数据规模和检索延迟要求。工程实践中，建议将在线和离线 Embedding 服务分离部署，在线服务独占 GPU 保障延迟 SLA，离线服务使用 CPU 或 Spot GPU 控制成本。