GLM-4-9B-Chat-1M模型服务化部署

GLM-4-9B-Chat-1M模型服务化部署：从单机到高可用的RESTful API实战

想把那个支持百万字长文本的GLM-4-9B-Chat-1M模型变成随时可调用的服务吗？今天咱们就来聊聊怎么把这个大家伙服务化部署，让它能稳定、高效地处理并发请求，就像你平时用的那些云服务一样。

我最近刚把一个GLM-4-9B-Chat-1M模型部署成生产环境可用的服务，过程中踩了不少坑，也积累了一些经验。这篇文章就带你走一遍完整的流程，从单机部署开始，一步步讲到怎么处理高并发、怎么做负载均衡，让你也能轻松搭建自己的大模型服务。

1. 为什么需要服务化部署？

你可能已经试过在本地跑GLM-4-9B-Chat-1M模型了，用个Python脚本调用一下，效果确实不错。但真要用到实际业务里，问题就来了：

• 怎么让多个应用同时调用？总不能每个应用都自己加载一遍模型吧
• 怎么管理并发请求？一个请求还没处理完，另一个又来了怎么办
• 怎么保证服务稳定？万一服务挂了，所有依赖它的应用都得跟着停摆
• 怎么监控服务状态？得知道服务现在忙不忙，响应快不快

服务化部署就是来解决这些问题的。简单说，就是把模型包装成一个标准的Web服务，提供统一的API接口，任何应用都能通过HTTP请求来调用。这样既方便管理，也容易扩展。

2. 环境准备与模型选择

2.1 硬件要求

GLM-4-9B-Chat-1M这个模型对硬件要求不低，特别是你要用它的1M上下文长度时。根据官方文档，推理1M长度大概需要4张80G显存的卡（比如A100/H100）。

不过别被吓到，实际使用中我们很少真的用到1M长度。大部分场景下，8192或32768的长度就够用了。这时候显存需求会大幅下降：

• 8192长度：大约需要18-24G显存（单张A10或3090就能跑）
• 32768长度：可能需要2张24G卡做张量并行
• 131072长度：建议2-4张卡
• 1M长度：必须4张80G卡，而且要用vLLM的enable_chunked_prefill参数

我建议你先从8192长度开始，这样单卡就能跑起来，测试和开发都方便。等业务真需要更长上下文时再升级硬件。

2.2 软件环境

我推荐用Docker来部署，这样环境隔离好，也方便迁移。这里有个现成的vLLM Docker镜像可以用：

docker pull egs-registry.cn-hangzhou.cr.aliyuncs.com/egs/vllm:0.4.0.post1-pytorch2.1.2-cuda12.1.1-cudnn8-ubuntu22.04

这个镜像已经预装了vLLM和必要的CUDA环境，省去了自己配置的麻烦。

2.3 模型下载

模型可以从魔搭社区（ModelScope）下载，速度比Hugging Face快不少：

# 安装modelscope pip install modelscope # 下载GLM-4-9B-Chat-1M模型 modelscope download --model ZhipuAI/glm-4-9b-chat-1m

下载完成后，模型会保存在~/.cache/modelscope/hub/ZhipuAI/glm-4-9b-chat-1m目录下。记下这个路径，后面启动服务要用。

3. 单机服务部署

3.1 基础服务启动

我们先从最简单的单机服务开始。用vLLM启动一个兼容OpenAI API的服务：

# 启动Docker容器，把模型目录映射进去 docker run -d -t --rm --net=host --gpus all \ --privileged \ --ipc=host \ --name glm4-service \ -v /path/to/your/model:/models/glm4 \ egs-registry.cn-hangzhou.cr.aliyuncs.com/egs/vllm:0.4.0.post1-pytorch2.1.2-cuda12.1.1-cudnn8-ubuntu22.04 \ python -m vllm.entrypoints.openai.api_server \ --host 0.0.0.0 \ --port 8000 \ --model /models/glm4 \ --served-model-name glm4-9b-chat \ --trust-remote-code \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

这里有几个关键参数需要解释一下：

• --max-model-len 8192：设置最大上下文长度，根据你的显存调整
• --gpu-memory-utilization 0.9：GPU内存使用率，0.9表示使用90%的显存
• --trust-remote-code：GLM模型需要这个参数来加载自定义代码

3.2 测试服务是否正常

服务启动后，用curl测试一下：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "glm4-9b-chat", "messages": [ {"role": "system", "content": "你是一个有帮助的助手"}, {"role": "user", "content": "你好，请介绍一下你自己"} ], "temperature": 0.7, "max_tokens": 100 }'

如果看到类似下面的响应，说明服务启动成功了：

{ "id": "chat-123456", "object": "chat.completion", "created": 1723716800, "model": "glm4-9b-chat", "choices": [{ "index": 0, "message": { "role": "assistant", "content": "你好！我是GLM-4-9B-Chat，一个由智谱AI开发的大语言模型..." } }] }

3.3 常见问题解决

我在部署时遇到过一个典型问题：对话无法停止，模型一直输出。这是因为vLLM没有正确识别GLM模型的停止标记。

解决方法是在启动命令中添加停止标记ID：

python -m vllm.entrypoints.openai.api_server \ # ... 其他参数 ... --stop-token-ids 151329 151336 151338

这三个ID（151329, 151336, 151338）是GLM模型特有的停止标记，告诉模型什么时候该结束生成。

4. RESTful API接口设计

虽然vLLM提供了OpenAI兼容的接口，但实际业务中我们可能需要定制化的接口。下面是我设计的一套RESTful API，更适合企业级应用。

4.1 基础聊天接口

from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List, Optional import requests app = FastAPI(title="GLM-4-9B-Chat-1M API服务") class Message(BaseModel): role: str # user, assistant, system content: str class ChatRequest(BaseModel): messages: List[Message] model: str = "glm4-9b-chat" temperature: float = 0.7 max_tokens: int = 1024 stream: bool = False class ChatResponse(BaseModel): id: str content: str model: str usage: dict @app.post("/v1/chat/completions") async def chat_completion(request: ChatRequest): """ 聊天补全接口 支持多轮对话，自动维护对话历史 """ try: # 调用底层的vLLM服务 vllm_response = requests.post( "http://localhost:8000/v1/chat/completions", json=request.dict(), timeout=30 ) if vllm_response.status_code != 200: raise HTTPException( status_code=vllm_response.status_code, detail=vllm_response.text ) result = vllm_response.json() return ChatResponse( id=result["id"], content=result["choices"][0]["message"]["content"], model=result["model"], usage=result.get("usage", {}) ) except requests.exceptions.Timeout: raise HTTPException(status_code=504, detail="请求超时") except Exception as e: raise HTTPException(status_code=500, detail=str(e))

这个接口做了几件事：

1. 统一了请求/响应格式
2. 添加了超时处理
3. 包装了错误信息
4. 保持了与OpenAI API的兼容性

4.2 批量处理接口

实际业务中经常需要批量处理请求，比如同时处理100个用户的提问。vLLM本身支持连续批处理，但我们需要一个接口来管理：

from concurrent.futures import ThreadPoolExecutor import asyncio class BatchChatRequest(BaseModel): requests: List[ChatRequest] max_workers: int = 10 # 最大并发数 @app.post("/v1/batch/chat") async def batch_chat(batch_request: BatchChatRequest): """ 批量聊天接口 同时处理多个聊天请求，提高吞吐量 """ results = [] # 使用线程池并发处理 with ThreadPoolExecutor(max_workers=batch_request.max_workers) as executor: loop = asyncio.get_event_loop() tasks = [] for req in batch_request.requests: # 将同步请求转换为异步任务 task = loop.run_in_executor( executor, lambda r=req: requests.post( "http://localhost:8000/v1/chat/completions", json=r.dict(), timeout=30 ).json() ) tasks.append(task) # 等待所有任务完成 responses = await asyncio.gather(*tasks, return_exceptions=True) for i, resp in enumerate(responses): if isinstance(resp, Exception): results.append({ "index": i, "error": str(resp), "success": False }) else: results.append({ "index": i, "content": resp["choices"][0]["message"]["content"], "success": True }) return {"results": results}

4.3 长文本处理接口

GLM-4-9B-Chat-1M的核心优势就是长文本处理。我们可以设计专门的接口来处理长文档：

class LongTextRequest(BaseModel): text: str task: str # summarize, qa, extract chunk_size: int = 32768 # 分块大小 overlap: int = 512 # 块之间重叠部分 @app.post("/v1/longtext/process") async def process_longtext(request: LongTextRequest): """ 长文本处理接口 支持总结、问答、信息提取等任务 """ # 如果文本超过chunk_size，先进行分块 if len(request.text) > request.chunk_size: chunks = [] start = 0 while start < len(request.text): end = min(start + request.chunk_size, len(request.text)) chunk = request.text[start:end] chunks.append(chunk) start = end - request.overlap # 重叠一部分，避免切分关键信息 else: chunks = [request.text] # 根据任务类型构建不同的提示词 if request.task == "summarize": system_prompt = "你是一个专业的文本总结助手。请用简洁的语言总结以下文本的核心内容。" elif request.task == "qa": system_prompt = "你是一个问答助手。请根据文本内容回答用户的问题。" else: system_prompt = "你是一个信息提取助手。请从文本中提取关键信息。" # 处理每个分块 results = [] for i, chunk in enumerate(chunks): chat_request = ChatRequest( messages=[ Message(role="system", content=system_prompt), Message(role="user", content=chunk) ], max_tokens=min(1024, len(chunk) // 4) # 根据输入长度动态调整输出长度 ) # 调用聊天接口 response = await chat_completion(chat_request) results.append({ "chunk_index": i, "content": response.content }) # 如果需要，可以将各分块的结果再合并 if len(results) > 1 and request.task == "summarize": # 对分块总结再进行一次总结 combined_summary = "\n".join([r["content"] for r in results]) final_request = ChatRequest( messages=[ Message(role="system", content="请将以下多个分块的总结合并成一个连贯的完整总结。"), Message(role="user", content=combined_summary) ] ) final_response = await chat_completion(final_request) return {"summary": final_response.content} return {"results": results}

5. 并发处理与性能优化

单机服务处理几个请求没问题，但真要面对成百上千的并发请求，就得好好优化了。

5.1 vLLM的批处理机制

vLLM最大的优势就是它的连续批处理（Continuous Batching）机制。传统批处理要等一批请求都到齐了才开始处理，而连续批处理可以随时加入新请求，随时完成老请求。

我们可以在启动服务时调整批处理相关参数：

python -m vllm.entrypoints.openai.api_server \ # ... 其他参数 ... --max-num-seqs 256 \ # 最大同时处理的序列数 --max-num-batched-tokens 8192 \ # 每批最大token数 --block-size 16 \ # 注意力块大小，影响内存效率 --enable-prefix-caching # 启用前缀缓存，加速重复提示

5.2 异步处理与队列管理

对于高并发场景，我们需要在API层做请求队列管理：

from queue import Queue import threading import time class RequestQueue: def __init__(self, max_size=1000): self.queue = Queue(maxsize=max_size) self.processing = False self.results = {} self.lock = threading.Lock() def add_request(self, request_id, request_data): """添加请求到队列""" if self.queue.full(): return False self.queue.put((request_id, request_data)) self.results[request_id] = {"status": "pending"} return True def process_requests(self, batch_size=8): """处理队列中的请求""" self.processing = True while not self.queue.empty() or self.processing: batch = [] request_ids = [] # 收集一批请求 for _ in range(min(batch_size, self.queue.qsize())): try: req_id, req_data = self.queue.get_nowait() batch.append(req_data) request_ids.append(req_id) except: break if batch: # 批量处理 try: responses = self._process_batch(batch) # 更新结果 with self.lock: for req_id, resp in zip(request_ids, responses): self.results[req_id] = { "status": "completed", "response": resp, "completed_at": time.time() } except Exception as e: with self.lock: for req_id in request_ids: self.results[req_id] = { "status": "failed", "error": str(e) } time.sleep(0.1) # 避免空转 def get_result(self, request_id, timeout=30): """获取请求结果""" start_time = time.time() while time.time() - start_time < timeout: with self.lock: result = self.results.get(request_id) if result and result["status"] != "pending": return result time.sleep(0.1) return {"status": "timeout", "error": "请求超时"} # 全局请求队列 request_queue = RequestQueue(max_size=1000) # 启动处理线程 processing_thread = threading.Thread( target=request_queue.process_requests, daemon=True ) processing_thread.start() @app.post("/v1/async/chat") async def async_chat(request: ChatRequest): """ 异步聊天接口 适用于需要长时间处理的请求 """ request_id = str(uuid.uuid4()) # 添加到队列 if not request_queue.add_request(request_id, request.dict()): raise HTTPException(status_code=429, detail="请求队列已满") return {"request_id": request_id, "status": "queued"} @app.get("/v1/async/result/{request_id}") async def get_async_result(request_id: str): """获取异步处理结果""" result = request_queue.get_result(request_id) if result["status"] == "completed": return result["response"] elif result["status"] == "failed": raise HTTPException(status_code=500, detail=result["error"]) elif result["status"] == "timeout": raise HTTPException(status_code=408, detail="请求处理超时") else: return {"status": "processing"}

5.3 性能监控与限流

服务上线后，监控和限流很重要：

from prometheus_client import Counter, Histogram, generate_latest from fastapi import Response import time # 定义监控指标 REQUEST_COUNT = Counter( 'http_requests_total', 'Total HTTP requests', ['method', 'endpoint', 'status'] ) REQUEST_LATENCY = Histogram( 'http_request_duration_seconds', 'HTTP request latency', ['method', 'endpoint'] ) ERROR_COUNT = Counter( 'http_errors_total', 'Total HTTP errors', ['method', 'endpoint', 'error_type'] ) class RateLimiter: def __init__(self, requests_per_minute=60): self.requests_per_minute = requests_per_minute self.requests = {} # ip -> [timestamp1, timestamp2, ...] def is_allowed(self, client_ip: str) -> bool: now = time.time() if client_ip not in self.requests: self.requests[client_ip] = [] # 清理一分钟前的记录 self.requests[client_ip] = [ ts for ts in self.requests[client_ip] if now - ts < 60 ] # 检查是否超过限制 if len(self.requests[client_ip]) >= self.requests_per_minute: return False # 记录本次请求 self.requests[client_ip].append(now) return True rate_limiter = RateLimiter(requests_per_minute=100) @app.middleware("http") async def monitor_requests(request, call_next): start_time = time.time() # 限流检查 client_ip = request.client.host if not rate_limiter.is_allowed(client_ip): ERROR_COUNT.labels( method=request.method, endpoint=request.url.path, error_type="rate_limit" ).inc() return Response( content="请求过于频繁，请稍后再试", status_code=429 ) try: response = await call_next(request) # 记录请求 REQUEST_COUNT.labels( method=request.method, endpoint=request.url.path, status=response.status_code ).inc() # 记录延迟 latency = time.time() - start_time REQUEST_LATENCY.labels( method=request.method, endpoint=request.url.path ).observe(latency) return response except Exception as e: ERROR_COUNT.labels( method=request.method, endpoint=request.url.path, error_type=type(e).__name__ ).inc() raise @app.get("/metrics") async def metrics(): """Prometheus监控指标""" return Response(content=generate_latest(), media_type="text/plain")

6. 负载均衡与高可用

单个服务实例总有瓶颈，也容易单点故障。生产环境需要多实例+负载均衡。

6.1 多实例部署

我们可以用Docker Compose部署多个服务实例：

version: '3.8' services: glm4-service-1: image: egs-registry.cn-hangzhou.cr.aliyuncs.com/egs/vllm:0.4.0.post1-pytorch2.1.2-cuda12.1.1-cudnn8-ubuntu22.04 command: > python -m vllm.entrypoints.openai.api_server --host 0.0.0.0 --port 8000 --model /models/glm4 --served-model-name glm4-9b-chat --trust-remote-code --max-model-len 8192 --gpu-memory-utilization 0.8 --tensor-parallel-size 2 volumes: - /path/to/model:/models/glm4 deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu] networks: - glm4-network glm4-service-2: image: egs-registry.cn-hangzhou.cr.aliyuncs.com/egs/vllm:0.4.0.post1-pytorch2.1.2-cuda12.1.1-cudnn8-ubuntu22.04 command: > python -m vllm.entrypoints.openai.api_server --host 0.0.0.0 --port 8000 --model /models/glm4 --served-model-name glm4-9b-chat --trust-remote-code --max-model-len 8192 --gpu-memory-utilization 0.8 --tensor-parallel-size 2 volumes: - /path/to/model:/models/glm4 deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu] networks: - glm4-network load-balancer: image: nginx:alpine ports: - "8080:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf depends_on: - glm4-service-1 - glm4-service-2 networks: - glm4-network networks: glm4-network: driver: bridge

6.2 Nginx负载均衡配置

对应的Nginx配置：

events { worker_connections 1024; } http { upstream glm4_backend { # 最少连接数负载均衡 least_conn; server glm4-service-1:8000; server glm4-service-2:8000; # 健康检查 check interval=3000 rise=2 fall=3 timeout=1000; } server { listen 80; location / { proxy_pass http://glm4_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 超时设置 proxy_connect_timeout 5s; proxy_send_timeout 60s; proxy_read_timeout 60s; # 缓冲设置 proxy_buffering on; proxy_buffer_size 4k; proxy_buffers 8 4k; proxy_busy_buffers_size 8k; } # 健康检查端点 location /health { access_log off; return 200 "healthy\n"; } } }

6.3 服务发现与自动扩缩容

对于更复杂的场景，可以用Kubernetes实现自动扩缩容：

apiVersion: apps/v1 kind: Deployment metadata: name: glm4-service spec: replicas: 2 selector: matchLabels: app: glm4-service template: metadata: labels: app: glm4-service spec: containers: - name: glm4 image: egs-registry.cn-hangzhou.cr.aliyuncs.com/egs/vllm:0.4.0.post1-pytorch2.1.2-cuda12.1.1-cudnn8-ubuntu22.04 command: ["python", "-m", "vllm.entrypoints.openai.api_server"] args: - "--host=0.0.0.0" - "--port=8000" - "--model=/models/glm4" - "--served-model-name=glm4-9b-chat" - "--trust-remote-code" - "--max-model-len=8192" - "--gpu-memory-utilization=0.8" - "--tensor-parallel-size=2" resources: limits: nvidia.com/gpu: 2 volumeMounts: - name: model-volume mountPath: /models/glm4 livenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 5 periodSeconds: 5 volumes: - name: model-volume hostPath: path: /path/to/model type: Directory --- apiVersion: v1 kind: Service metadata: name: glm4-service spec: selector: app: glm4-service ports: - port: 80 targetPort: 8000 type: LoadBalancer --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: glm4-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: glm4-service minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70

7. 实际部署建议

根据我的经验，给你几个实际部署的建议：

对于初创项目或内部工具：

• 单机部署就够了，用一张24G显存的卡
• 上下文长度设8192，能处理大多数场景
• 用Docker部署，方便备份和迁移
• 加上基础的健康检查和监控

对于中小型生产环境：

• 至少2个实例，做负载均衡
• 每实例2张GPU卡，做张量并行
• 上下文长度可以提到32768
• 设置完整的监控告警
• 做好日志收集和分析

对于大型生产环境：

• 多实例+多区域部署
• 用Kubernetes管理，支持自动扩缩容
• 实现灰度发布和回滚机制
• 建立完整的DevOps流程
• 考虑混合部署（CPU+GPU，应对不同负载）

性能调优要点：

1. 批处理大小：根据实际请求模式调整--max-num-batched-tokens
2. 内存使用：监控GPU内存，调整--gpu-memory-utilization
3. 响应时间：长文本请求单独处理，避免阻塞短请求
4. 缓存策略：对常见问题启用前缀缓存

成本控制建议：

1. 按需扩容：用Kubernetes HPA，流量低时自动缩容
2. 混合精度：能用FP16就不用BF16，能省显存
3. 请求合并：相似请求合并处理，提高GPU利用率
4. 冷热分离：高频功能保持热实例，低频功能用冷启动

8. 总结

把GLM-4-9B-Chat-1M做成服务化部署，听起来复杂，但一步步拆解下来其实挺清晰的。从单机服务开始，慢慢加上并发处理、负载均衡、监控告警，最后实现高可用架构。

关键是要根据实际需求来设计，别一开始就追求大而全。内部工具用单机就行，对外服务再考虑多实例，真正高并发场景再上K8s。

我在这套方案里积累的经验是：稳定性比性能重要，监控比功能重要，简单比复杂重要。先让服务稳定跑起来，再慢慢优化性能；先做好监控知道服务状态，再加新功能；架构尽量简单，容易维护才是长久之计。

GLM-4-9B-Chat-1M的长文本能力确实强，但要用好它，服务化部署是关键。希望这篇文章能帮你少走些弯路，快速搭建起自己的大模型服务。

获取更多AI镜像

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