Langchain-Chatchat问答系统弹性扩容实战：应对流量高峰-深圳市維司達科技有限公司

Langchain-Chatchat问答系统弹性扩容实战：应对流量高峰

在企业智能化转型的浪潮中，知识管理正从“静态文档库”走向“动态智能中枢”。尤其是在金融、医疗、制造等对数据安全与响应效率要求极高的领域，通用大模型难以满足私有知识精准检索和合规处理的需求。于是，像Langchain-Chatchat这类基于 RAG（检索增强生成）架构的本地化知识问答系统，逐渐成为构建企业专属 AI 助手的核心选择。

但问题也随之而来——当一场全员培训启动、一次产品发布会上线，或客服咨询集中涌入时，原本运行平稳的问答服务突然卡顿、超时甚至崩溃。这背后暴露的，不是模型能力不足，而是系统架构缺乏应对流量波动的弹性。

如何让一个依赖 CPU/GPU 密集计算的 AI 服务，在不牺牲数据安全的前提下，像电商平台一样实现“自动扩容”？本文将深入探讨 Langchain-Chatchat 的可扩展性设计，并结合真实部署场景，给出一套可落地的弹性伸缩方案。

为什么传统部署模式撑不住突发流量？

我们先来看一个典型困境：某制造业客户部署了基于 ChatGLM + FAISS 的 Langchain-Chatchat 系统，用于员工查询设备维护手册。日常使用下响应流畅，但在季度安全培训期间，上千名员工同时提问，“如何更换X型传感器？”这类高频问题瞬间涌向服务器。

结果是——API 响应时间从 600ms 暴涨至超过 8s，部分请求直接返回 504 错误。

根本原因在于：
- LLM 推理和向量相似度搜索都是高负载操作；
- 单实例服务的 CPU 和内存资源很快耗尽；
- 更致命的是，由于所有组件耦合在同一进程中，一个请求卡住可能拖垮整个服务。

更糟糕的是，如果为了应对这种“峰值时刻”而长期配置高性能服务器，平日利用率却不足 20%，对企业而言无疑是巨大的资源浪费。

所以，真正的挑战不是“能不能跑起来”，而是“能不能聪明地跑”。

解耦、容器化、自动化：打造可伸缩的基础架构

要实现弹性扩容，首先要打破“单体式”部署的思维定式。幸运的是，Langchain-Chatchat 本身的模块化设计为水平扩展提供了天然支持。它的核心流程——文档解析 → 向量化存储 → 语义检索 → 答案生成——本身就是松耦合的，这意味着我们可以按需拆分服务单元。

关键思路一：无状态化 API 层

最适合作为扩缩对象的，是接收用户请求的 Web 服务层。只要保证这个层面是“无状态”的，即不保存会话信息、不独占数据文件，就可以轻松复制多个实例。

回顾其 FastAPI 实现：

@app.post("/ask") async def ask_question(request: dict): question = request["question"] result = qa_chain.invoke({"query": question}) return { "answer": result["result"], "sources": [doc.metadata for doc in result["source_documents"]] }

这段代码本质上是一个纯函数调用：输入问题，输出答案和来源。只要所有实例都能访问相同的向量数据库和嵌入模型，它们就是完全对等的。这就是水平扩展的前提。

关键思路二：共享存储保障一致性

多实例带来的最大风险是数据不一致。比如每个 Pod 都加载一份独立的 FAISS 索引，不仅浪费磁盘空间，还会因更新不同步导致检索结果差异。

解决方案有两种：

共享文件系统挂载
使用 NFS 或云厂商提供的 CSI 存储卷，将向量库目录以只读方式挂载到所有 Pod。适用于中小规模、更新频率低的场景。
独立向量数据库服务
将 FAISS 升级为 Milvus 或 Chroma Server，作为独立微服务运行。所有 API 实例通过 gRPC/HTTP 调用统一接口进行检索。这种方式支持并发读写、权限控制和集群模式，更适合生产环境。

例如，替换原代码中的FAISS.load_local为远程客户端：

from langchain_community.vectorstores import Milvus vectorstore = Milvus( embedding_function=embeddings, collection_name="enterprise_kb", connection_args={"host": "milvus-service", "port": "19530"} )

这样，知识库的生命周期就与 API 服务解耦了。

关键思路三：GPU 资源池化，避免争抢

LLM 推理通常是性能瓶颈所在，尤其当使用 GPU 加速时，若多个 API 实例都尝试直接调用本地模型，极易造成显存溢出。

更好的做法是：将 LLM 封装为独立推理服务，并通过 API 网关统一调度。

例如，使用 vLLM 或 Text Generation Inference (TGI) 启动一个高性能推理后端，监听/generate接口。Chatchat 的 QA 链不再直接初始化ChatGLM，而是改为调用该服务：

llm = HuggingFaceEndpoint( endpoint_url="http://llm-inference-service:8080/generate", model_kwargs={"temperature": 0.7} )

这样一来，你可以单独为 LLM 服务配置 GPU 节点，并设置连接池限制最大并发数，防止过载。同时，多个 Chatchat 实例共享同一个推理资源池，资源利用率更高。

弹性伸缩落地：Kubernetes 如何自动应对流量洪峰

有了模块化和服务化的基础，下一步就是引入编排平台实现自动化伸缩。Kubernetes（K8s）正是这一角色的理想人选。

以下是典型的部署结构：

# deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: chatchat-api spec: replicas: 2 selector: matchLabels: app: chatchat-api template: metadata: labels: app: chatchat-api spec: containers: - name: api-server image: chatchat:v1.2 ports: - containerPort: 8000 resources: requests: cpu: "500m" memory: "2Gi" limits: cpu: "1000m" memory: "4Gi" volumeMounts: - name: kb-storage mountPath: /app/knowledge_base livenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8000 initialDelaySeconds: 60 periodSeconds: 10 volumes: - name: kb-storage nfs: server: 192.168.1.100 path: /data/kb

配合 HPA（Horizontal Pod Autoscaler）实现自动扩缩：

# hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: chatchat-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: chatchat-api minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 behavior: scaleDown: stabilizationWindowSeconds: 300

这套配置意味着：
- 当前平均 CPU 使用率超过 70% 且持续一段时间后，K8s 会自动创建新 Pod；
- 最少保留 1 个实例，最多扩展到 10 个；
- 缩容前等待 5 分钟稳定期，防止因短暂流量 spike 导致频繁扩缩（俗称“抖动”）；

再加上 Ingress 控制器做外部流量分发，整个系统就能像电商网站一样，在访问高峰时“自动加机器”，低谷时“自动收资源”。