中文分词与词性标注是自然语言处理的基础环节，无论是搜索引擎建索引、舆情分析还是对话系统，都绕不开这一步。但真正动手搭建环境时，很多问题会接踵而至：Python 版本不匹配、gcc 编译失败、模型文件体积巨大不好分发、不同项目依赖互相冲突。Docker 的出现让这些麻烦有了统一解法，把运行环境和模型一起打包进容器，任何机器上拉起容器即可使用。本文围绕几个主流分词工具，完整讲解容器化部署的思路与落地细节。
为什么分词与词性标注适合容器化
分词工具的依赖链往往比想象中复杂。以 jieba 为例，它本身是纯 Python 实现，安装简单，但如果追求性能启用并行模式或者对接其他 C 扩展库，环境差异就会显现出来。而 HanLP、LTP 这类工具则更依赖特定版本的 PyTorch、Transformers 甚至 CUDA，在宿主机上装错一个版本就可能导致模型加载失败。
容器化的第一个好处是环境一致性。开发人员在笔记本上调试通过的镜像，原封不动地推送到测试环境、生产环境，行为完全一致，不会出现“我这里明明是好的”这种经典对话。第二个好处是模型与代码同生命周期管理，分词模型动辄几百 MB 甚至数 GB，把它们打进镜像或者通过数据卷挂载，配合镜像仓库就能实现版本化管理，回滚也只需要换一个 tag。
第三个好处是资源隔离。分词服务通常 CPU 密集，如果和其他服务混部在同一台机器上，可能互相抢占资源。通过 Docker 的 --cpus 和 --memory 参数限制容器配额，可以保证服务之间互不干扰，也便于容量规划。
用 Dockerfile 封装 jieba 分词服务
下面从一个最简单的例子开始，把 jieba 封装成 HTTP 服务。选择轻量的 Flask 作为 Web 框架，基础镜像选用官方 slim 版本，体积小且足够稳定。Dockerfile 中将依赖写入 requirements.txt 再统一安装，可以利用 Docker 的层缓存机制，依赖不变时重新构建会快很多。
from flask import Flask, request, jsonify
import jieba.posseg as pseg
app = Flask(__name__)
@app.route("/cut", methods=["POST"])
def cut():
text = request.json.get("text", "")
# pseg.cut 同时完成分词和词性标注
result = [(w, f) for w, f in pseg.cut(text)]
return jsonify({"result": result})
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5000)
上面的服务代码保存为 app.py，再编写 Dockerfile 如下。
FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY app.py . EXPOSE 5000 CMD ["python", "app.py"]
requirements.txt 中只需两行：flask 和 jieba。构建命令为 docker build -t jieba-server .，运行时用 docker run -d -p 5000:5000 jieba-server 即可对外提供服务。用 curl 发一个 POST 请求验证，输入“今天天气真不错”，返回结果中每个词都带有词性标记，例如“今天/t 天气/n 不错/a”，说明分词与词性标注链路已经跑通。
有几个细节值得注意。第一，Flask 自带的开发服务器性能有限，生产环境建议换成 gunicorn，把 CMD 改为 gunicorn -w 4 -b 0.0.0.0:5000 app:app，多进程可以充分利用多核。第二，jieba 支持加载自定义词典，词典文件不要打进镜像，而是通过 -v /data/user_dict.txt:/app/user_dict.txt 挂载进去，这样更新词典不需要重新构建镜像。第三，首次加载词典耗时较长，建议在应用启动阶段就调用 jieba.initialize() 预热，避免第一个请求超时。
部署深度学习方案：HanLP 与 LTP 的容器化
jieba 基于词典和统计模型，速度快但准确率有上限。对准确率要求高的场景，比如法律文书分析、医疗文本处理，深度学习方案更合适，HanLP 和 LTP 是国内使用广泛的两个选择。它们基于神经网络模型，依赖 PyTorch，镜像体积和内存占用都会明显增加，Dockerfile 的写法也需要调整。
FROM python:3.10-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
gcc g++ libgomp1 \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 模型单独放到数据卷，避免镜像过大
ENV HANLP_HOME=/data/hanlp
RUN mkdir -p /data/hanlp
COPY server.py .
EXPOSE 8000
CMD ["python", "server.py"]
这里有一个关键决策：模型不放进镜像。HanLP 的完整模型包超过 1 GB，LTP 的深度学习模型也有几百 MB，如果把模型烧进镜像，每次模型升级都要传输巨大的镜像层，且同一个基础环境换模型就要重复构建。更优雅的做法是把模型目录做成数据卷，运行时挂载，镜像只包含代码和依赖。命令形如 docker run -v /data/models:/data/hanlp -p 8000:8000 hanlp-server，模型升级只需替换宿主机目录里的文件并重启容器。
如果需要 GPU 加速推理，基础镜像要换成 nvidia/cuda 或 PyTorch 官方的 GPU 版本，运行时加上 --gpus all 参数，并确保宿主机安装了 nvidia-container-toolkit。不过要提醒一点，纯分词和词性标注任务的模型通常不大，CPU 推理延迟往往在几十毫秒级别，除非要处理海量离线数据，否则 GPU 方案的性价比未必高，建议先做压测再决定。
生产环境的进阶实践
进入生产环境后，还有几个问题需要面对。首先是健康检查，Dockerfile 中可以用 HEALTHCHECK 指令定期请求服务的健康接口，配合编排工具自动摘除异常实例。其次是并发处理，分词是 CPU 密集型任务，单进程吞吐有限，横向扩展比纵向堆配置更划算，用 docker compose 定义多副本配合 Nginx 做负载均衡是常见组合。
version: "3.8"
services:
jieba:
build: .
deploy:
resources:
limits:
cpus: "2"
memory: 2G
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
interval: 30s
timeout: 5s
retries: 3
nginx:
image: nginx:alpine
ports:
- "80:80"
depends_on:
- jieba
日志管理也不容忽视。容器内的日志默认走标准输出，由 Docker 收集，长期运行要注意配置日志轮转，例如在 daemon.json 中设置 max-size，否则磁盘会被慢慢吃满。对于批量离线处理场景，可以不用 HTTP 服务，直接写一个批处理脚本放进容器，用 docker run --rm -v /data/input:/input -v /data/output:/output tokenizer batch.py 一次性执行完毕即退出，这种用法在数据流水线中非常常见。
总结来看，Docker 把分词与词性标注从“装环境噩梦”变成“一条命令启动”的标准化能力。小规模场景用 jieba 加 Flask 足够，追求精度再上 HanLP 或 LTP，配合数据卷管理模型、健康检查保活、编排工具扩缩容，一套完整的中文词法分析基础设施就可以稳定地支撑上层业务了。