我在金融科技公司用Docker跑Embedding踩过的那些坑

为什么要自己部署Embedding

我们组做风控文本分析，需要对用户提交的说明材料做语义检索。想用OpenAI的Embedding API，安全直接驳回：数据不能出内网。于是选了BGE-M3，中文效果好，有ONNX版本可纯CPU推理。但内网服务器离线，镜像必须外网构建后导入。

Docker构建踩坑实录

最初用sentence-transformers加载模型，镜像飙到8G。改用FastAPI包最小推理服务，模型文件挂载卷不塞进镜像，瘦身到1.2G：

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app/ ./app/
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

跑起来才发现slim镜像缺编译依赖，onnxruntime报错OSError: libgomp.so.1: cannot open shared object file。补一行：

RUN apt-get update && apt-get install -y --no-install-recommends libgomp1 && rm -rf /var/lib/apt/lists/*

向量检索的性能调优

200万条历史工单做相似度检索，P99延迟3秒多。优化分三步：Redis缓存高频查询Embedding，命中率约40%；用FAISS预建200万条向量索引，查询时只算查询文本向量；提供批量接口，合并多个文本一次推理，减少循环开销。最终P99降到400毫秒。

经验：BGE-M3的ONNX模型在CPU上跑，batch size设8到16性价比最高，再大因内存带宽瓶颈反而变慢。

区块链存证

存证链项目要把风控决策关键环节哈希上链。我负责把Embedding推理的模型版本、输入文本哈希、输出向量哈希打包，调智能合约存联盟链，审计时证明“这个向量确实由该版本模型算出”。

链上存储成本高，改为每100条记录做一次Merkle树根哈希上链，单条哈希存链下数据库，审计用Merkle证明验证包含关系。

总结

离线环境AI部署，真正花时间的不是模型本身，而是环境依赖、镜像分发、安全合规这些“脏活”。模型代码约200行，Dockerfile调通花了两天，部署文档写了三页。

建议：先跑通最小闭环，别追新模型；镜像能小就小；早点拉安全合规同事介入反而省事。