ChatGLM3-6B模型缓存优化：提升并发处理能力

你是不是遇到过这种情况：费了好大劲把ChatGLM3-6B部署好了，自己用着挺顺，可一旦有几个人同时来问问题，系统就慢得像蜗牛，甚至直接卡死？

这太正常了。ChatGLM3-6B虽然部署简单，但默认配置下，它处理请求的方式是“来一个，处理一个，再下一个”。当多个请求同时涌来时，它们只能排队等待，前面的请求不结束，后面的就得干等着。这不仅让用户体验变差，也浪费了宝贵的计算资源。

今天，我们就来聊聊怎么给ChatGLM3-6B“动个小手术”，通过一系列缓存优化策略，让它从一个“单线程”的慢郎中，变成一个能同时应对多人提问的“多面手”。这些方法不涉及复杂的底层修改，主要是在使用方式和部署架构上做文章，实操性很强。

1. 为什么需要缓存优化？先搞清楚瓶颈在哪

在动手优化之前，我们得先明白ChatGLM3-6B在处理并发请求时，到底卡在哪里了。

想象一下模型推理的过程：当你输入一个问题，模型需要把这个问题转换成它能理解的数字（分词），然后这些数字在模型的神经网络里（主要是Transformer层）经过复杂的计算，最后再转换回文字输出给你。这个过程每一步都要消耗时间和内存。

对于ChatGLM3-6B这样的模型，主要的瓶颈通常在这几个地方：

  • 模型加载与初始化：每次处理请求，哪怕只是简单的对话，模型相关的权重、计算图都需要保持在GPU显存中。虽然不用重复加载，但为每个请求单独初始化一次计算流程，开销也不小。
  • 计算重复：如果多个用户问了完全相同或高度相似的问题，模型却在为每个问题都从头到尾算一遍，这显然是浪费。
  • 显存竞争：默认情况下，多个推理进程或线程可能会争抢同一块显存，导致冲突甚至崩溃。
  • 输入/输出（I/O）等待：网络接收请求、发送结果，如果处理不好，也会成为瓶颈。

缓存优化的核心思想，就是避免重复计算、重复加载，让共享的资源能被高效复用，从而在单位时间内处理更多的请求。

2. 基础准备：理解ChatGLM3-6B的推理方式

在优化之前，我们先回顾一下ChatGLM3-6B最基础的调用方式，这样你才能明白我们后续的优化是在哪个环节发力的。

通常，你会看到这样的代码：

from transformers import AutoTokenizer, AutoModel

# 1. 加载模型和分词器（这一步最耗时耗资源）
tokenizer = AutoTokenizer.from_pretrained("THUDM/chatglm3-6b", trust_remote_code=True)
model = AutoModel.from_pretrained("THUDM/chatglm3-6b", trust_remote_code=True, device='cuda')
model = model.eval()  # 切换到评估模式

# 2. 处理单个请求
question = "你好，介绍一下你自己。"
response, history = model.chat(tokenizer, question, history=[])
print(response)

这段代码的问题在于，model和tokenizer虽然是全局的，但model.chat这个方法在默认情况下，并没有为并发访问做优化。如果我们在一个Web服务器（比如用Flask或FastAPI搭建）里直接这么用，当两个HTTP请求几乎同时调用这个函数时，就很容易出问题。

所以，我们的优化之旅，就从改造这个最简单的使用模式开始。

3. 策略一：请求批处理（Batching）—— 化零为整

这是提升吞吐量最有效的手段之一。批处理的原理很简单：与其让10个请求排队一个个处理，不如把它们攒一攒，凑成一批，一次性扔给模型计算。模型内部的计算（尤其是矩阵运算）对批量数据非常友好，GPU可以并行处理，效率远高于串行。

3.1 如何实现简单的请求批处理

对于ChatGLM3-6B，我们可以利用transformers库的pipeline功能，或者手动构造批输入。这里展示一个手动批处理的示例思路：

import torch
from transformers import AutoTokenizer, AutoModel
from queue import Queue
from threading import Lock
import time

class BatchedChatGLM:
    def __init__(self, model_path="THUDM/chatglm3-6b", batch_size=4, max_wait=0.1):
        self.tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True)
        self.model = AutoModel.from_pretrained(model_path, trust_remote_code=True, device='cuda').eval()
        self.batch_size = batch_size
        self.max_wait = max_wait  # 最大等待时间（秒），用于凑批
        
        self.request_queue = Queue()
        self.lock = Lock()
        self.results = {}

    def _process_batch(self, batch_requests):
        """内部方法，处理一个批次的请求"""
        questions = [req['question'] for req in batch_requests]
        ids = [req['id'] for req in batch_requests]
        
        # 这里需要将多个问题编码并padding到相同长度
        inputs = self.tokenizer(questions, padding=True, return_tensors="pt").to('cuda')
        
        # 注意：ChatGLM的.chat方法原生不支持批处理，这里需要更底层的调用或使用其他方式。
        # 以下为概念性代码，实际实现需调用model.generate并处理历史记录。
        # outputs = self.model.generate(**inputs, ...)
        # decoded = self.tokenizer.batch_decode(outputs, skip_special_tokens=True)
        
        # 由于ChatGLM3的chat接口限制，更实际的批处理可能需要等待官方支持或使用vLLM等推理引擎。
        # 此处先模拟结果
        decoded = [f"已处理批处理请求，原问题：{q}" for q in questions]
        
        # 将结果存回字典
        with self.lock:
            for req_id, answer in zip(ids, decoded):
                self.results[req_id] = answer

    def ask(self, question, request_id=None):
        """提交一个问题，返回一个未来可获取结果的ID"""
        if request_id is None:
            request_id = str(time.time()) + str(hash(question))
        
        # 将请求放入队列
        self.request_queue.put({'id': request_id, 'question': question})
        
        # 如果队列大小达到batch_size，则触发处理
        if self.request_queue.qsize() >= self.batch_size:
            batch = []
            while not self.request_queue.empty() and len(batch) < self.batch_size:
                batch.append(self.request_queue.get())
            # 启动一个线程或异步任务来处理batch
            # threading.Thread(target=self._process_batch, args=(batch,)).start()
            self._process_batch(batch)  # 简化起见，同步执行
        
        return request_id

    def get_result(self, request_id):
        """根据ID获取结果"""
        with self.lock:
            return self.results.pop(request_id, None)

# 使用示例（概念性）
# batcher = BatchedChatGLM(batch_size=4)
# req_id = batcher.ask("今天天气怎么样？")
# ... 等待或轮询 ...
# answer = batcher.get_result(req_id)

重要说明：上面的代码主要是为了展示批处理的思想。ChatGLM3-6B原生的.chat() API并不直接支持批处理输入。要实现真正的批处理，通常有两种路径：

  1. 使用像 vLLM 或 TGI (Text Generation Inference) 这样的高性能推理引擎，它们对ChatGLM有很好的支持，内置了高效的批处理和持续批处理功能。
  2. 使用模型底层的generate方法，并自己处理对话历史、注意力掩码等复杂逻辑。这对初学者来说门槛较高。

3.2 使用vLLM引擎进行批处理

这是目前生产环境推荐的做法。vLLM通过其PagedAttention内核，极大地提高了显存利用率和批处理效率。部署ChatGLM3-6B使用vLLM非常简单：

首先，安装vLLM：

pip install vllm

然后，使用以下代码启动一个支持批处理的API服务：

from vllm import LLM, SamplingParams

# 定义模型和采样参数
llm = LLM(model="THUDM/chatglm3-6b", trust_remote_code=True, max_model_len=8192)
sampling_params = SamplingParams(temperature=0.8, top_p=0.95, max_tokens=256)

# 准备一批提示词
prompts = [
    "你好，请介绍一下你自己。",
    "中国的首都是哪里？",
    "如何学习Python编程？",
    "写一首关于春天的短诗。"
]

# 批量生成
outputs = llm.generate(prompts, sampling_params)

# 打印结果
for output in outputs:
    prompt = output.prompt
    generated_text = output.outputs[0].text
    print(f"Prompt: {prompt!r}\nGenerated: {generated_text!r}\n")

vLLM会自动管理请求队列、动态批处理（continuous batching），并高效利用GPU显存。你可以将其与FastAPI结合，轻松搭建一个高并发的模型API服务。

4. 策略二：结果缓存（Response Caching）—— 以空间换时间

如果很多用户都在问“你好”、“你是谁”、“怎么用”这类高度重复的问题，每次都让模型生成一遍，太不划算了。结果缓存就是把之前生成过的答案存起来，下次遇到相同或相似的问题，直接返回缓存的结果。

4.1 实现一个简单的问答缓存

我们可以用一个字典，或者用更专业的Redis来存储缓存。

import hashlib
import json
from functools import lru_cache

class CachedChatGLM:
    def __init__(self, model_path="THUDM/chatglm3-6b"):
        self.tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True)
        self.model = AutoModel.from_pretrained(model_path, trust_remote_code=True, device='cuda').eval()
        self.cache = {}  # 简单内存缓存，生产环境建议用Redis

    def _get_cache_key(self, question, **kwargs):
        """根据问题和参数生成唯一的缓存键"""
        # 将对话历史等参数也考虑进去
        data = json.dumps({"question": question, **kwargs}, sort_keys=True, ensure_ascii=False)
        return hashlib.md5(data.encode('utf-8')).hexdigest()

    @lru_cache(maxsize=1024)  # 也可以使用Python内置的LRU缓存
    def chat_with_cache(self, question, history=None, **kwargs):
        """带缓存的聊天方法"""
        if history is None:
            history = []
        
        cache_key = self._get_cache_key(question, history=history, **kwargs)
        
        if cache_key in self.cache:
            print(f"缓存命中: {question[:50]}...")
            return self.cache[cache_key]
        
        print(f"缓存未命中，调用模型: {question[:50]}...")
        response, new_history = self.model.chat(self.tokenizer, question, history=history, **kwargs)
        
        # 存储缓存（注意：只缓存答案，历史记录是新的）
        self.cache[cache_key] = (response, new_history)
        return response, new_history

# 使用示例
cached_model = CachedChatGLM()
# 第一次问，会调用模型
ans1, hist1 = cached_model.chat_with_cache("什么是人工智能？")
# 第二次问一模一样的问题，直接返回缓存
ans2, hist2 = cached_model.chat_with_cache("什么是人工智能？")  # 这次应该看到“缓存命中”

4.2 缓存的进阶考虑

  • 缓存粒度：是缓存单轮问答，还是缓存整个对话序列？通常缓存单轮更简单，但多轮对话的上下文相关性很强，直接缓存可能不合适。
  • 过期与更新：知识可能更新，或者模型的生成具有随机性（如果temperature>0）。你需要设计缓存的过期策略，或者为同一问题缓存多个可能的答案。
  • 相似问题匹配：用户可能用不同的措辞问同一个问题。这时可以用文本嵌入模型（如BGE）计算问题的向量相似度，如果相似度超过阈值，就返回缓存中相似问题的答案。这属于“语义缓存”，更智能，但实现也更复杂。

5. 策略三：模型与内存管理—— 让资源更耐用

并发上来了，对GPU显存和系统内存的管理就成了关键。这里有几个实用技巧：

5.1 模型量化

如果你的GPU显存比较紧张（比如只有8GB或16GB），量化是必须的。它能把模型权重从FP16（16位浮点数）压缩到INT8甚至INT4，显著减少显存占用，代价是轻微的性能损失。

# 使用 transformers 库进行 8-bit 量化
model = AutoModel.from_pretrained("THUDM/chatglm3-6b", 
                                   trust_remote_code=True, 
                                   load_in_8bit=True,  # 8位量化
                                   device_map="auto")  # 自动分配设备

# 或者使用4位量化（需要bitsandbytes库）
model = AutoModel.from_pretrained("THUDM/chatglm3-6b",
                                   trust_remote_code=True,
                                   load_in_4bit=True,
                                   device_map="auto",
                                   bnb_4bit_compute_dtype=torch.float16)

量化后的模型，显存占用可能降低一半甚至更多，让你能在同一张显卡上运行更多的并发推理进程。

5.2 使用PagedAttention和vLLM的内存管理

如前所述，vLLM的PagedAttention技术就像操作系统的虚拟内存，将显存分页管理，可以极大地减少内存碎片，提升显存利用率。这对于处理长上下文和大量并发请求至关重要。你只需要在初始化LLM时指定max_model_len等参数，剩下的交给vLLM。

5.3 进程管理与资源隔离

在生产环境中，不要把所有请求都塞进一个Python进程。你可以使用：

  • 多进程：利用gunicorn或uvicorn启动多个工作进程，每个进程加载一个模型实例。操作系统会调度它们到不同的CPU核心，并能更好地利用多核GPU。
  • 容器化：使用Docker封装你的模型服务，结合Kubernetes进行水平扩容，根据负载自动增减副本数。

6. 实战：搭建一个高并发的ChatGLM3-6B API服务

让我们把上面的策略组合起来，用一个简单的FastAPI + vLLM的例子，展示一个具备基本并发能力的服务端。

# app.py
from fastapi import FastAPI, BackgroundTasks
from pydantic import BaseModel
from vllm import LLM, SamplingParams
from typing import List
import asyncio
import uuid

app = FastAPI(title="ChatGLM3-6B 高并发API")

# 全局加载模型和采样参数（vLLM内部已优化）
llm = LLM(model="THUDM/chatglm3-6b", 
          trust_remote_code=True, 
          max_model_len=8192,
          gpu_memory_utilization=0.9,  # 显存利用率目标
          enable_prefix_caching=True)   # 启用前缀缓存，优化重复提示

sampling_params = SamplingParams(temperature=0.7, top_p=0.9, max_tokens=512)

# 简单的内存缓存（生产环境换Redis）
response_cache = {}

class ChatRequest(BaseModel):
    prompt: str
    request_id: str = None
    use_cache: bool = True

class BatchChatRequest(BaseModel):
    prompts: List[str]
    request_id: str = None

@app.post("/chat")
async def chat_completion(request: ChatRequest):
    """单轮对话，带简单缓存"""
    if request.use_cache and request.prompt in response_cache:
        return {"response": response_cache[request.prompt], "cached": True}
    
    # vLLM生成
    outputs = llm.generate([request.prompt], sampling_params)
    generated_text = outputs[0].outputs[0].text
    
    # 存入缓存
    response_cache[request.prompt] = generated_text
    # 可设置缓存大小上限或过期时间
    
    return {"response": generated_text, "cached": False}

@app.post("/batch_chat")
async def batch_chat_completion(request: BatchChatRequest):
    """批量对话，vLLM自动批处理"""
    outputs = llm.generate(request.prompts, sampling_params)
    responses = [output.outputs[0].text for output in outputs]
    return {"responses": responses}

@app.get("/health")
async def health_check():
    return {"status": "healthy", "model": "chatglm3-6b"}

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000, workers=2)  # 启动2个工作进程

使用uvicorn启动时，通过workers参数可以指定进程数。每个进程都会加载一个vLLM引擎实例，它们可以并行处理请求。vLLM引擎内部又通过持续批处理来高效处理每个进程接收到的多个请求。

7. 总结

给ChatGLM3-6B做缓存优化，核心目标就是提高吞吐量和降低延迟。我们今天聊的这几个策略，其实是一个递进的关系。

对于刚起步或者请求量不大的场景，先从结果缓存开始最简单，能立刻避免重复计算。当用户量增长，出现并发请求时，请求批处理就成了必选项，而vLLM这类工具让这件事变得不那么困难。最后，为了服务稳定和资源高效利用，模型量化和精细的内存/进程管理是走向生产环境的必修课。

实际做的时候，你不需要一下子把所有策略都上齐。可以根据你的实际痛点，比如是GPU内存不够了，还是请求排队太长了，来选择合适的优化组合。最重要的是，在每一步改动之后，做好测试和监控，看看吞吐量、响应时间这些关键指标是不是真的变好了。

优化是个持续的过程，随着ChatGLM3本身和推理工具的迭代，还会有更多更好的方法出现。但万变不离其宗，理解缓存和并发的核心思想，就能让你在面对各种大模型时，都能找到让它们跑得更快、更稳的办法。

获取更多AI镜像

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

# 性能优化
Logo
MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

cover

MateClaw 2.0 正式发布：从“一个能干活的人”到“一支能协作的队伍”

avatar MCP技术社区
cover

MCP更新： 2026-07-28：从 Agent 插件协议到企业 AI 工具总线

avatar MCP技术社区
cover

Nature正刊！| 基于可追溯推理的智能体系统重塑罕见病诊断

avatar MCP技术社区