在自然语言处理项目中，SpaCy 和 Stanza 经常被同时用于词法分析、依存句法分析、命名实体识别等任务。SpaCy 以速度快、工业级部署见长，而 Stanza 依托 PyTorch 提供了更丰富的预训练模型和学术研究特性。不过，两者的依赖栈存在明显差异：SpaCy 依赖 Thinc、blis 等编译库，Stanza 依赖 PyTorch、torchtext 等大型组件。如果直接在物理机或虚拟机上安装，很容易因为 Python 版本、CUDA 版本、底层编译工具链的不同而产生冲突。容器化可以把这些依赖封装到独立的镜像中，让开发、测试和生产环境保持一致。本文将从零开始构建一个同时包含 SpaCy 与 Stanza 的容器镜像，并演示如何优化体积、管理模型以及编排服务。
为什么 NLP 模型服务需要容器化
单纯安装 SpaCy 或 Stanza 本身并不困难，一条 pip 命令就能完成。但问题在于这两个库对运行环境的要求并不完全兼容。SpaCy 的底层会编译 Cython 扩展，并且依赖 NumPy 的特定版本；Stanza 则需要完整安装 PyTorch，而 PyTorch 又会根据不同平台和 CUDA 版本拉取不同的二进制包。如果目标机器上已经存在一个旧版本的 NumPy 或者不兼容的 CUDA 工具链，升级其中一个库很容易破坏另一个库的正常运行。这种依赖冲突在多人协作或频繁变更的服务器上尤其明显。
容器化的核心价值在于环境隔离。通过 Docker 镜像，可以把 Python 解释器、系统库、第三方依赖以及模型文件完整打包。只要镜像构建成功，在任何支持 Docker 的机器上运行的结果都是一致的。开发人员可以在本地构建镜像并下发给测试或生产环境，不需要重新配置依赖。当出现问题时，也可以快速回滚到上一个镜像标签，而不是手工修复环境变量或重新安装软件包。对于同时运行多个 NLP 框架的场景，容器化几乎是目前最可靠的交付方式。
当然，容器化也不是没有代价。SpaCy 和 Stanza 的模型文件通常较大，尤其是 Stanza 的预训练模型可能达到数百 MB 甚至 GB 级别。如果把这些模型全部打进镜像，镜像体积会迅速膨胀，构建和分发时间都会增加。因此在实际操作中，需要结合多阶段构建、模型外置挂载等手段，在环境一致性和体积可控之间取得平衡。
构建同时包含 SpaCy 与 Stanza 的 Docker 镜像
首先确定基础镜像。对于大多数 CPU 场景，官方 python:3.10-slim 是一个不错的选择。它基于 Debian，带 glibc 支持，能够正常编译和加载 PyTorch 以及 SpaCy 的 C 扩展。如果需要 GPU 加速，则可以改用 nvidia/cuda 系列基础镜像，或者直接使用 pytorch/pytorch 镜像来避免手动安装 CUDA 工具链。这里以 CPU 版本为例，先创建一个 requirements.txt 文件，内容如下：
spacy stanza
虽然示例中没有锁定版本，但在正式生产环境中强烈建议明确指定版本号，例如 spacy==3.7.5 和 stanza==1.8.2，这样每次构建得到的镜像行为完全可预期。接下来编写 Dockerfile：
FROM python:3.10-slim
ENV PYTHONUNBUFFERED=1 \
PIP_NO_CACHE_DIR=1 \
PIP_DISABLE_PIP_VERSION_CHECK=1
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .
CMD ["python", "app.py"]
在这个 Dockerfile 中，先设置环境变量避免 Python 输出被缓冲，然后拷贝依赖文件并执行安装。安装完成后拷贝应用代码，最后指定容器启动时运行的命令。为了让镜像构建后能直接验证两个框架是否正常工作，可以编写一个简单的 app.py：
import spacy
import stanza
nlp = spacy.load("en_core_web_sm")
stanza.download("en")
stanza_nlp = stanza.Pipeline(lang="en", processors="tokenize,pos,lemma,ner")
text = "Apple is looking at buying U.K. startup for $1 billion"
spacy_doc = nlp(text)
print("SpaCy entities:", [(ent.text, ent.label_) for ent in spacy_doc.ents])
stanza_doc = stanza_nlp(text)
print("Stanza entities:", [(ent.text, ent.type) for ent in stanza_doc.ents])
这里在容器启动时会自动下载 Stanza 的英文模型，而 SpaCy 的 en_core_web_sm 模型并没有被显式安装。为了在构建阶段就完成模型下载，可以在 Dockerfile 中增加一条 RUN python -m spacy download en_core_web_sm，或者把模型文件复制到镜像内部。预下载的好处是容器启动后可以立即处理请求，不需要等待联网下载。对于体积较大的 Stanza 模型，更推荐在构建时下载到镜像内，或者通过外部卷挂载的方式避免镜像过大。
多阶段构建与镜像体积优化
SpaCy 和 Stanza 安装完成后，镜像体积通常会超过 2GB，其中 PyTorch 占据了很大一部分。如果直接把构建过程中的缓存、编译中间文件留在最终镜像里，体积还会进一步增加。多阶段构建可以把依赖安装过程和最终运行环境分离开来，只把必要的文件拷贝到最终镜像。下面是一个使用 Python 虚拟环境的多阶段 Dockerfile 示例：
FROM python:3.10-slim AS builder WORKDIR /app COPY requirements.txt . RUN python -m venv /opt/venv ENV PATH="/opt/venv/bin:$PATH" RUN pip install -r requirements.txt FROM python:3.10-slim AS runtime WORKDIR /app COPY --from=builder /opt/venv /opt/venv ENV PATH="/opt/venv/bin:$PATH" COPY app.py . CMD ["python", "app.py"]
这种方式把虚拟环境整体复制到运行时阶段，避免了 pip 安装过程中产生的缓存和构建工具残留。为了进一步缩小体积，可以在构建阶段执行 pip install --no-cache-dir，并清理 /root/.cache 目录。同时，书写 .dockerignore 文件把本地的模型目录、Git 历史、测试文件排除在构建上下文之外，也能减少上传到 Docker 守护进程的数据量。
需要特别注意的是，Alpine 基础镜像虽然体积小，但 PyTorch 对 musl libc 的支持并不完善，SpaCy 的编译扩展也容易在 Alpine 上失败。因此不建议为了追求极小体积而使用 Alpine 来运行这两个框架。如果确实需要精简，可以考虑把 SpaCy 和 Stanza 拆分成两个独立的服务镜像，让每个镜像只包含一个框架及其依赖，再通过 API 通信。这种拆分方式虽然增加了架构复杂度，但可以显著降低单个镜像体积，也便于独立升级和扩容。
使用 Docker Compose 编排和运行 NLP 服务
实际生产环境中，一个 NLP 服务往往需要绑定端口、挂载模型文件、设置环境变量并限制资源使用。如果每次都用冗长的 docker run 命令启动，不仅难以维护，也不利于团队协作。Docker Compose 通过 YAML 文件描述服务配置，可以一键启动和停止整套服务。下面是一个简单的 Compose 配置：
version: "3.9"
services:
nlp-service:
image: nlp-stack:latest
ports:
- "8000:8000"
environment:
- PYTHONUNBUFFERED=1
- MODEL_DIR=/app/models
volumes:
- ./models:/app/models
deploy:
resources:
limits:
memory: 4G
reservations:
memory: 2G
在这个配置中，ports 把容器内部的 8000 端口映射到宿主机，volumes 把宿主机上的 models 目录挂载到容器内，这样模型文件不需要打进镜像，更新模型时只需替换宿主机文件并重启容器。环境变量可以用来控制模型加载路径、日志级别等。资源限制确保单个容器不会无限制占用内存，避免影响宿主机上的其他服务。
如果服务需要对外提供 HTTP 接口，可以在应用代码中加入 FastAPI 或 Flask，并在 Compose 中增加健康检查配置。例如通过 healthcheck 定时请求一个 /health 端点，判断模型是否加载完成。SpaCy 和 Stanza 的模型加载过程比较耗时，尤其是 Stanza 首次初始化流水线时可能需要几秒甚至十几秒，因此健康检查的初始等待时间要设置得足够长。在实际部署时，还可以为服务配置多个副本，但由于每个副本都会独立加载模型，内存消耗会成倍增加，所以扩容前需要仔细评估可用资源。
容器化 SpaCy 与 Stanza 并不是一劳永逸的工作，模型版本更新、依赖升级、镜像安全扫描都需要纳入日常维护流程。不过相比裸机部署，容器化让这一切变得可重复、可审计。只要把镜像构建、模型挂载和编排配置固化下来，后续开发和运维成本都会明显下降。