GLM-OCR开源大模型部署教程：Kubernetes Helm Chart封装与集群化部署-育师

GLM-OCR开源大模型部署教程：Kubernetes Helm Chart封装与集群化部署

想让一个强大的OCR模型在多个服务器上稳定运行，随时处理海量文档识别任务吗？单机部署虽然简单，但面对生产环境的弹性伸缩、高可用和统一管理需求时，就显得力不从心了。

今天，我将带你从零开始，将一个功能强大的GLM-OCR模型封装成Kubernetes Helm Chart，实现真正的集群化部署。无论你是运维工程师、AI应用开发者，还是技术负责人，这套方案都能帮你构建一个稳定、可扩展的OCR服务平台。

1. 为什么需要Kubernetes集群化部署？

在深入技术细节之前，我们先看看单机部署和集群化部署的差别。

1.1 单机部署的局限性

你可能已经尝试过在单台服务器上部署GLM-OCR，通过简单的脚本启动服务。这种方式在开发测试阶段没问题，但到了生产环境就会遇到几个头疼的问题：

单点故障：服务器宕机，整个OCR服务就不可用了
资源浪费：请求量少的时候，GPU资源闲置；请求突增时，服务又处理不过来
难以扩展：手动在多台机器上部署，配置同步、版本管理都是麻烦事
运维复杂：监控、日志收集、故障恢复都需要人工干预

1.2 Kubernetes集群化的优势

Kubernetes（简称K8s）是目前最流行的容器编排平台，它能帮你解决上述所有问题：

高可用性：多副本部署，一个实例挂了，其他实例继续服务
弹性伸缩：根据请求量自动调整实例数量，节省资源成本
统一管理：通过声明式配置管理所有部署，版本升级一键完成
服务发现：自动为服务分配稳定的访问地址，客户端无需关心后端变化
资源隔离：每个服务运行在独立的容器中，互不干扰

简单来说，Kubernetes让AI模型服务像自来水一样可靠——打开水龙头就有水，你不需要知道水是从哪个水厂来的。

2. 部署架构设计

在开始动手之前，我们先规划一下整体的架构。一个好的架构能让后续的部署和维护事半功倍。

2.1 整体架构图

┌─────────────────────────────────────────────────────────────┐ │ Kubernetes Cluster │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ GLM-OCR │ │ GLM-OCR │ │ GLM-OCR │ │ │ │ Pod 1 │ │ Pod 2 │ │ Pod 3 │ │ │ │ (GPU Node) │ │ (GPU Node) │ │ (GPU Node) │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ ┌──────┴──────────────────┴──────────────────┴──────┐ │ │ │ Service (Load Balancer) │ │ │ └──────────────────────────┬─────────────────────────┘ │ │ │ │ └─────────────────────────────┼──────────────────────────────┘ │ ┌───────┴───────┐ │ Ingress │ │ Controller │ └───────┬───────┘ │ ┌───────┴───────┐ │ 外部用户 │ │ 或客户端 │ └───────────────┘

这个架构的核心思想是：多个GLM-OCR实例组成一个集群，前面通过Service统一暴露服务，再通过Ingress提供外部访问入口。

2.2 关键组件说明

Pod：Kubernetes的最小部署单元，每个Pod运行一个GLM-OCR实例
Service：为Pod提供稳定的网络访问入口，实现负载均衡
Ingress：管理外部访问，支持域名、HTTPS等高级路由功能
Helm Chart：将所有这些配置打包成一个可重复部署的软件包

3. 准备Docker镜像

Kubernetes运行的是容器，所以我们需要先把GLM-OCR打包成Docker镜像。

3.1 编写Dockerfile

创建一个名为Dockerfile的文件，内容如下：

# 使用带有CUDA的基础镜像 FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04 # 设置环境变量 ENV DEBIAN_FRONTEND=noninteractive ENV PYTHONUNBUFFERED=1 ENV MODEL_PATH=/app/models/GLM-OCR # 安装系统依赖 RUN apt-get update && apt-get install -y \ wget \ git \ python3.10 \ python3.10-dev \ python3-pip \ python3.10-venv \ && rm -rf /var/lib/apt/lists/* # 创建应用目录 WORKDIR /app # 复制项目文件 COPY GLM-OCR/ /app/GLM-OCR/ COPY requirements.txt /app/ # 创建Python虚拟环境并安装依赖 RUN python3.10 -m venv /app/venv ENV PATH="/app/venv/bin:$PATH" RUN pip install --upgrade pip && \ pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 && \ pip install -r requirements.txt && \ pip install git+https://github.com/huggingface/transformers.git gradio # 下载模型（如果本地没有，可以从HuggingFace下载） # 这里假设模型已经预下载并放在models目录下 COPY models/ /app/models/ # 暴露端口 EXPOSE 7860 # 启动脚本 COPY entrypoint.sh /app/ RUN chmod +x /app/entrypoint.sh ENTRYPOINT ["/app/entrypoint.sh"]

3.2 创建启动脚本

创建一个名为entrypoint.sh的启动脚本：

#!/bin/bash # 激活虚拟环境 source /app/venv/bin/activate # 进入项目目录 cd /app/GLM-OCR # 启动Gradio服务 echo "Starting GLM-OCR service..." python serve_gradio.py \ --model_path /app/models/GLM-OCR \ --port 7860 \ --host 0.0.0.0 # 如果服务异常退出，保持容器运行以便查看日志 echo "Service stopped, keeping container alive for debugging..." tail -f /dev/null

3.3 构建和测试镜像

在包含Dockerfile的目录下，执行以下命令构建镜像：

# 构建镜像 docker build -t glm-ocr:1.0.0 . # 测试运行 docker run -d \ --name glm-ocr-test \ --gpus all \ -p 7860:7860 \ glm-ocr:1.0.0 # 检查日志 docker logs -f glm-ocr-test # 测试API访问 curl http://localhost:7860

如果一切正常，你应该能看到Gradio服务的启动日志。现在我们已经有了可运行的Docker镜像，接下来就是把它部署到Kubernetes集群中。

4. 创建Helm Chart

Helm是Kubernetes的包管理器，它让我们可以用一个Chart（图表）来定义整个应用的部署配置。

4.1 初始化Chart结构

首先创建Chart的基本目录结构：

# 创建Chart目录 mkdir -p glm-ocr-chart cd glm-ocr-chart # 创建标准Chart结构 mkdir -p templates mkdir -p charts # 创建Chart.yaml文件 cat > Chart.yaml << EOF apiVersion: v2 name: glm-ocr description: A Helm chart for deploying GLM-OCR model on Kubernetes type: application version: 1.0.0 appVersion: "1.0.0" # 依赖项（如果有的话） dependencies: [] EOF # 创建values.yaml配置文件 cat > values.yaml << EOF # GLM-OCR Helm Chart 配置 # 副本数量 replicaCount: 2 # 镜像配置 image: repository: glm-ocr tag: "1.0.0" pullPolicy: IfNotPresent # 服务配置 service: type: ClusterIP port: 7860 targetPort: 7860 # 资源限制 resources: limits: cpu: "2" memory: "8Gi" nvidia.com/gpu: "1" requests: cpu: "1" memory: "4Gi" nvidia.com/gpu: "1" # 自动扩缩容配置 autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 targetCPUUtilizationPercentage: 70 targetMemoryUtilizationPercentage: 80 # 持久化存储配置 persistence: enabled: true storageClass: "standard" accessMode: ReadWriteOnce size: 10Gi mountPath: /app/models # 环境变量配置 env: - name: MODEL_PATH value: "/app/models/GLM-OCR" - name: MAX_SEQ_LEN value: "4096" - name: GRADIO_SERVER_NAME value: "0.0.0.0" # 节点选择器（指定GPU节点） nodeSelector: accelerator: nvidia-gpu # 亲和性配置 affinity: {} # 容忍度配置（允许调度到有污点的GPU节点） tolerations: - key: "nvidia.com/gpu" operator: "Exists" effect: "NoSchedule" # 探针配置 livenessProbe: httpGet: path: / port: 7860 initialDelaySeconds: 60 periodSeconds: 30 timeoutSeconds: 10 readinessProbe: httpGet: path: / port: 7860 initialDelaySeconds: 30 periodSeconds: 15 timeoutSeconds: 5 EOF

4.2 创建Kubernetes模板文件

现在创建实际的Kubernetes资源模板。首先创建Deployment模板：

# templates/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: {{ include "glm-ocr.fullname" . }} labels: {{- include "glm-ocr.labels" . | nindent 4 }} spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "glm-ocr.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "glm-ocr.selectorLabels" . | nindent 8 }} spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" imagePullPolicy: {{ .Values.image.pullPolicy }} ports: - containerPort: {{ .Values.service.port }} name: http env: {{- range .Values.env }} - name: {{ .name }} value: {{ .value | quote }} {{- end }} resources: {{- toYaml .Values.resources | nindent 10 }} livenessProbe: {{- toYaml .Values.livenessProbe | nindent 10 }} readinessProbe: {{- toYaml .Values.readinessProbe | nindent 10 }} volumeMounts: {{- if .Values.persistence.enabled }} - name: model-storage mountPath: {{ .Values.persistence.mountPath }} {{- end }} volumes: {{- if .Values.persistence.enabled }} - name: model-storage persistentVolumeClaim: claimName: {{ include "glm-ocr.fullname" . }}-pvc {{- end }} {{- with .Values.nodeSelector }} nodeSelector: {{- toYaml . | nindent 8 }} {{- end }} {{- with .Values.affinity }} affinity: {{- toYaml . | nindent 8 }} {{- end }} {{- with .Values.tolerations }} tolerations: {{- toYaml . | nindent 8 }} {{- end }}

接下来创建Service模板：

# templates/service.yaml apiVersion: v1 kind: Service metadata: name: {{ include "glm-ocr.fullname" . }} labels: {{- include "glm-ocr.labels" . | nindent 4 }} spec: type: {{ .Values.service.type }} ports: - port: {{ .Values.service.port }} targetPort: {{ .Values.service.targetPort }} protocol: TCP name: http selector: {{- include "glm-ocr.selectorLabels" . | nindent 4 }}

如果需要持久化存储，创建PVC模板：

# templates/pvc.yaml {{- if .Values.persistence.enabled }} apiVersion: v1 kind: PersistentVolumeClaim metadata: name: {{ include "glm-ocr.fullname" . }}-pvc labels: {{- include "glm-ocr.labels" . | nindent 4 }} spec: accessModes: - {{ .Values.persistence.accessMode }} resources: requests: storage: {{ .Values.persistence.size }} {{- if .Values.persistence.storageClass }} storageClassName: {{ .Values.persistence.storageClass }} {{- end }} {{- end }}

如果需要自动扩缩容，创建HPA模板：

# templates/hpa.yaml {{- if .Values.autoscaling.enabled }} apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: {{ include "glm-ocr.fullname" . }} labels: {{- include "glm-ocr.labels" . | nindent 4 }} spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: {{ include "glm-ocr.fullname" . }} minReplicas: {{ .Values.autoscaling.minReplicas }} maxReplicas: {{ .Values.autoscaling.maxReplicas }} metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }} - type: Resource resource: name: memory target: type: Utilization averageUtilization: {{ .Values.autoscaling.targetMemoryUtilizationPercentage }} {{- end }}

最后，创建辅助模板文件：

# templates/_helpers.tpl {{- define "glm-ocr.fullname" -}} {{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}} {{- end -}} {{- define "glm-ocr.labels" -}} helm.sh/chart: {{ include "glm-ocr.chart" . }} {{ include "glm-ocr.selectorLabels" . }} {{- if .Chart.AppVersion }} app.kubernetes.io/version: {{ .Chart.AppVersion | quote }} {{- end }} app.kubernetes.io/managed-by: {{ .Release.Service }} {{- end -}} {{- define "glm-ocr.selectorLabels" -}} app.kubernetes.io/name: {{ .Chart.Name }} app.kubernetes.io/instance: {{ .Release.Name }} {{- end -}} {{- define "glm-ocr.chart" -}} {{- printf "%s-%s" .Chart.Name .Chart.Version | replace "+" "_" | trunc 63 | trimSuffix "-" -}} {{- end -}}

5. 部署到Kubernetes集群

现在我们已经有了完整的Helm Chart，可以开始部署了。

5.1 准备Kubernetes集群

首先确保你有一个可用的Kubernetes集群，并且已经配置了GPU支持：

# 检查集群状态 kubectl cluster-info # 检查节点状态（确保有GPU节点） kubectl get nodes # 检查GPU资源 kubectl describe nodes | grep -A 10 -B 10 "nvidia.com/gpu" # 如果有GPU节点但没有GPU资源，可能需要安装NVIDIA设备插件 kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.1/nvidia-device-plugin.yml

5.2 部署GLM-OCR Chart

使用Helm来部署我们的Chart：

# 添加Chart到本地仓库（如果需要） helm package glm-ocr-chart/ # 安装Chart helm install glm-ocr-release ./glm-ocr-chart \ --namespace glm-ocr \ --create-namespace \ --set replicaCount=2 \ --set image.repository=your-registry/glm-ocr \ --set image.tag=1.0.0 # 或者使用values.yaml文件中的配置 helm install glm-ocr-release ./glm-ocr-chart \ -f glm-ocr-chart/values.yaml \ --namespace glm-ocr \ --create-namespace

5.3 验证部署

部署完成后，检查各个资源的状态：

# 查看命名空间 kubectl get namespaces # 查看Pod状态 kubectl get pods -n glm-ocr -o wide # 查看Service kubectl get svc -n glm-ocr # 查看PVC状态 kubectl get pvc -n glm-ocr # 查看HPA状态 kubectl get hpa -n glm-ocr # 查看Pod日志 kubectl logs -n glm-ocr deployment/glm-ocr-release-glm-ocr --tail=50 # 进入Pod内部调试 kubectl exec -n glm-ocr -it deployment/glm-ocr-release-glm-ocr -- /bin/bash

5.4 测试服务访问

在集群内部测试服务是否正常：

# 获取Service的ClusterIP SERVICE_IP=$(kubectl get svc -n glm-ocr glm-ocr-release-glm-ocr -o jsonpath='{.spec.clusterIP}') # 从集群内部测试访问 kubectl run test-client -n glm-ocr --image=curlimages/curl --rm -it -- curl http://${SERVICE_IP}:7860 # 或者创建端口转发到本地 kubectl port-forward -n glm-ocr svc/glm-ocr-release-glm-ocr 7860:7860 # 然后在本地浏览器访问 http://localhost:7860

6. 配置外部访问

默认情况下，Service是ClusterIP类型，只能在集群内部访问。如果需要从外部访问，有几种方式：

6.1 使用NodePort

修改Service类型为NodePort：

# 在values.yaml中修改 service: type: NodePort port: 7860 targetPort: 7860 nodePort: 30080 # 可选，指定端口号

然后更新部署：

helm upgrade glm-ocr-release ./glm-ocr-chart \ -f glm-ocr-chart/values.yaml \ --namespace glm-ocr

6.2 使用LoadBalancer

如果你的集群在云平台上，可以使用LoadBalancer：

service: type: LoadBalancer port: 7860 targetPort: 7860

6.3 使用Ingress（推荐）

创建Ingress资源来管理外部访问：

# templates/ingress.yaml {{- if .Values.ingress.enabled }} apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ include "glm-ocr.fullname" . }} labels: {{- include "glm-ocr.labels" . | nindent 4 }} {{- with .Values.ingress.annotations }} annotations: {{- toYaml . | nindent 4 }} {{- end }} spec: {{- if .Values.ingress.className }} ingressClassName: {{ .Values.ingress.className }} {{- end }} rules: {{- range .Values.ingress.hosts }} - host: {{ .host | quote }} http: paths: {{- range .paths }} - path: {{ .path }} pathType: Prefix backend: service: name: {{ include "glm-ocr.fullname" $ }} port: number: {{ $.Values.service.port }} {{- end }} {{- end }} {{- if .Values.ingress.tls }} tls: {{- range .Values.ingress.tls }} - hosts: {{- range .hosts }} - {{ . | quote }} {{- end }} secretName: {{ .secretName }} {{- end }} {{- end }} {{- end }}

在values.yaml中添加Ingress配置：

ingress: enabled: true className: "nginx" annotations: nginx.ingress.kubernetes.io/proxy-body-size: "100m" nginx.ingress.kubernetes.io/proxy-read-timeout: "300" nginx.ingress.kubernetes.io/proxy-send-timeout: "300" hosts: - host: ocr.yourdomain.com paths: - path: / pathType: Prefix tls: []

7. 监控与运维

部署完成后，我们需要确保服务稳定运行，并能及时发现问题。

7.1 配置监控

使用Prometheus和Grafana监控服务状态：

# 在Pod中添加监控注解 template: metadata: annotations: prometheus.io/scrape: "true" prometheus.io/port: "7860" prometheus.io/path: "/metrics"

7.2 查看监控指标

# 查看Pod资源使用情况 kubectl top pods -n glm-ocr # 查看节点资源使用情况 kubectl top nodes # 查看GPU使用情况 kubectl describe nodes | grep -A 5 "Allocated resources" # 查看事件日志 kubectl get events -n glm-ocr --sort-by='.lastTimestamp'

7.3 常见问题排查

如果服务出现问题，可以按照以下步骤排查：

# 1. 检查Pod状态 kubectl describe pod -n glm-ocr <pod-name> # 2. 检查容器日志 kubectl logs -n glm-ocr <pod-name> --tail=100 # 3. 检查事件 kubectl get events -n glm-ocr --field-selector involvedObject.name=<pod-name> # 4. 检查资源限制 kubectl describe node <node-name> | grep -A 10 "Allocated resources" # 5. 检查网络连通性 kubectl run network-test -n glm-ocr --image=nicolaka/netshoot --rm -it -- /bin/bash # 在容器内执行：curl http://glm-ocr-service:7860

7.4 备份与恢复

定期备份模型数据和配置：

# 备份PVC数据 kubectl cp glm-ocr/<pod-name>:/app/models ./backup/models -c <container-name> # 备份Helm配置 helm get values glm-ocr-release -n glm-ocr > backup/values-backup.yaml # 恢复部署 helm upgrade glm-ocr-release ./glm-ocr-chart \ -f backup/values-backup.yaml \ --namespace glm-ocr

8. 总结

通过这个教程，我们完成了一个完整的GLM-OCR模型从单机部署到Kubernetes集群化部署的转变。让我们回顾一下关键步骤和收获：

8.1 部署流程总结

准备阶段：理解集群化部署的价值，设计合理的架构
容器化：将GLM-OCR打包成Docker镜像，确保环境一致性
Chart封装：创建Helm Chart，定义所有Kubernetes资源
集群部署：使用Helm将应用部署到Kubernetes集群
外部访问：配置Ingress或LoadBalancer提供外部访问
监控运维：设置监控告警，建立运维流程

8.2 集群化部署的优势

现在你的GLM-OCR服务已经具备了以下能力：

高可用性：多副本部署，自动故障转移
弹性伸缩：根据负载自动调整实例数量
资源优化：GPU资源得到充分利用
统一管理：所有配置版本化，一键部署升级
易于扩展：新增节点或实例只需修改配置

8.3 后续优化建议

部署完成后，你还可以考虑以下优化：

性能优化：调整模型参数，优化推理速度
成本优化：使用Spot实例，设置自动启停策略
安全加固：配置网络策略，启用TLS加密
CI/CD集成：自动化构建部署流程
多租户支持：为不同团队或客户隔离资源

8.4 开始你的集群化之旅

现在你已经掌握了GLM-OCR在Kubernetes上部署的全套技能。无论你是要部署一个OCR服务，还是其他AI模型，这套方法论都是通用的。

记住，技术部署不是目的，而是手段。真正的价值在于让AI能力稳定、高效地服务于业务需求。从今天开始，告别单点故障，拥抱弹性可扩展的AI服务架构吧！

获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

GLM-OCR开源大模型部署教程：Kubernetes Helm Chart封装与集群化部署