最近在规划公司智能客服系统的升级，技术选型时在DeepSeek R1和ChatGLM之间纠结了很久。网上资料要么太理论，要么就是简单的“Hello World”测试，对真实生产环境的参考价值有限。于是我们自己做了一系列压力测试和对比分析，把踩过的坑和总结的经验记录下来，希望能帮到有同样困惑的朋友。

智能客服这个场景，看起来简单，其实对模型的要求非常综合。核心痛点主要集中在三个方面：

1. 意图识别准确率：用户的问题千奇百怪，“我要退款”和“这个东西我不想要了怎么处理”必须识别为同一个意图。准确率直接决定分流效率和首次解决率。
2. 多轮对话记忆与连贯性：客服对话往往是多轮的。用户先问“我的订单物流到哪里了”，得到答案后接着问“那预计什么时候能到？”，模型必须能记住上下文中的“订单”和“物流”信息，否则体验会非常割裂。
3. API吞吐量与稳定性：促销期间，咨询量可能瞬间暴涨。API的响应延迟（P99）、并发吞吐量以及高负载下的稳定性（是否容易超时、报错）直接关系到系统会不会崩。

基于这些核心需求，我们重点对比了DeepSeek R1和ChatGLM几个关键指标。为了更直观，我把对比数据整理成了表格：

光看参数不够，还得上手调一下。下面是我们实际集成时使用的Python代码片段，包含了异步请求、重试机制和针对客服场景优化的prompt模板。

import aiohttp
import asyncio
from typing import Optional, Dict, Any
import backoff
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

class AIChatClient:
    """支持重试的异步AI聊天客户端基类"""
    def __init__(self, api_key: str, base_url: str):
        self.api_key = api_key
        self.base_url = base_url
        self.session: Optional[aiohttp.ClientSession] = None

    async def __aenter__(self):
        self.session = aiohttp.ClientSession(headers={'Authorization': f'Bearer {self.api_key}'})
        return self

    async def __aexit__(self, exc_type, exc_val, exc_tb):
        if self.session:
            await self.session.close()

    @backoff.on_exception(backoff.expo, (aiohttp.ClientError, asyncio.TimeoutError), max_tries=3)
    async def chat_completion(self, messages: list, model: str, **kwargs) -> Dict[str, Any]:
        """带指数退避重试的聊天补全请求"""
        if not self.session:
            raise RuntimeError("Session not initialized. Use async context manager.")
        payload = {
            "model": model,
            "messages": messages,
            "stream": False,
            **kwargs
        }
        try:
            async with self.session.post(f"{self.base_url}/chat/completions", json=payload, timeout=aiohttp.ClientTimeout(total=30)) as resp:
                resp.raise_for_status()
                return await resp.json()
        except Exception as e:
            logger.error(f"Request failed for model {model}: {e}")
            raise

# DeepSeek R1 调用示例
class DeepSeekR1Client(AIChatClient):
    def __init__(self, api_key: str):
        super().__init__(api_key, "https://api.deepseek.com/v1")

    def build_customer_service_prompt(self, user_query: str, history: list = None) -> list:
        """构建客服场景Prompt模板"""
        system_msg = {
            "role": "system",
            "content": "你是一个专业、友善的智能客服助手。请根据用户的问题和对话历史，提供准确、简洁、有帮助的回答。如果问题涉及订单、物流、账号、支付，请务必确认关键信息（如订单号、手机号后四位）。如果无法解决，应引导用户转接人工客服。"
        }
        messages = [system_msg]
        if history:
            messages.extend(history[-6:])  # 保留最近6轮历史，平衡上下文长度与成本
        messages.append({"role": "user", "content": user_query})
        return messages

# ChatGLM 调用示例 (假设API格式与OpenAI兼容)
class ChatGLMClient(AIChatClient):
    def __init__(self, api_key: str):
        super().__init__(api_key, "https://open.bigmodel.cn/api/paas/v4")  # 示例地址，需替换为实际

    def build_customer_service_prompt(self, user_query: str, history: list = None) -> list:
        # ChatGLM可能对Prompt格式有细微偏好，可在此处微调
        system_msg = {
            "role": "system",
            "content": "你是一名客服代表。请先理解用户意图，准确提取问题中的实体信息（如订单号、产品名）。回答需专业且富有同理心。对于不确定的信息，不要猜测，应询问用户或建议其查看具体页面。"
        }
        messages = [system_msg]
        if history:
            messages.extend(history[-5:])  # 根据ChatGLM的上下文窗口适当调整历史轮数
        messages.append({"role": "user", "content": user_query})
        return messages

# 使用示例
async def main():
    deepseek_api_key = "your_deepseek_key"
    chatglm_api_key = "your_chatglm_key"
    user_query = "我昨天买的手机订单号123456，现在发货了吗？"

    async with DeepSeekR1Client(deepseek_api_key) as ds_client:
        messages = ds_client.build_customer_service_prompt(user_query)
        response = await ds_client.chat_completion(messages, model="deepseek-chat")
        print("DeepSeek R1:", response['choices'][0]['message']['content'])

    async with ChatGLMClient(chatglm_api_key) as gl_client:
        messages = gl_client.build_customer_service_prompt(user_query)
        response = await gl_client.chat_completion(messages, model="chatglm_turbo")  # 示例模型名
        print("ChatGLM:", response['choices'][0]['message']['content'])

if __name__ == "__main__":
    asyncio.run(main())

纸上得来终觉浅，为了拿到真实数据，我们设计了一套基准测试方案。测试环境：AWS c5.2xlarge (8 vCPU, 16 GiB RAM)，Ubuntu 20.04，Python 3.9，位于华北区域的服务器以减少网络延迟影响。

1. 高并发稳定性测试：使用locust模拟200个并发用户持续发送请求，测试时长30分钟。主要观察错误率（非2xx响应）和响应时间分布。

   • DeepSeek R1：错误率维持在0.3%以下，P99响应时间在并发高峰时升至约520ms。
   • ChatGLM：错误率在0.8%左右，偶尔出现429（请求过多）错误，P99响应时间约为580ms。

2. 长会话内存与性能测试：模拟一个包含20轮问答的客服对话，将整个历史会话作为上下文传入。监控调用过程中的内存增长和响应延迟。

   • DeepSeek R1：得益于大上下文窗口，处理20轮历史对话时，响应时间增长平缓（较首轮增加约40%），内存占用稳定。
   • ChatGLM：当对话历史超过15轮后，响应时间有较明显增加（较首轮增加约70%），需要注意历史窗口截断策略。

3. 冷启动与持续性能：在服务闲置1小时后，发起一系列请求，记录前10次请求的延迟。

   • 两者均未观察到明显的“冷启动”惩罚，首请求延迟与后续请求基本一致，说明云端服务预热做得比较好。

在实际生产环境部署时，我们遇到了几个典型问题，这里分享出来帮大家避坑：

1. 会话状态丢失问题：

   • 问题：用户刷新页面或切换设备后，之前的对话历史丢失，模型无法接续上文。
   • 解决：切勿依赖模型自身的上下文记忆。必须在应用层实现会话状态管理。我们采用Redis存储经过精简的对话历史摘要（例如，每轮对话的意图和关键实体），并在发起新请求时，将摘要与最近几轮原始对话一起拼装成Prompt发送。这样既控制了Token消耗，又保证了会话的连续性。

2. 敏感词与合规性过滤：

   • 问题：模型可能生成不符合公司政策或监管要求的回复。
   • 解决：模型输出后必须经过过滤层。我们部署了一个轻量级的本地过滤服务，采用“关键词+正则+微调文本分类模型”的多层过滤方案。先拦截明显违规词，再用分类模型判断回复的整体倾向性。对于被过滤的回复，自动触发一个修正Prompt让模型重生成，或直接返回预设的安全话术（如“您的问题我需要进一步确认，已为您转接人工客服”）。

3. 流量突增时的降级策略：

   • 问题：大促时流量激增，AI服务API可能成为瓶颈，导致整体客服系统响应缓慢。
   • 解决：设计柔性降级链路。我们的策略是：
     • 一级降级：当P99延迟超过1.5秒或错误率大于5%时，自动将部分非核心、复杂度低的查询（如“营业时间”、“退货政策”）路由到基于规则引擎的FAQ库。
     • 二级降级：当服务持续不可用，则将所有AI客服入口替换为“人工客服排队”或“留言”界面，并给出预计等待时间，保障核心业务流程不中断。

经过这一轮从理论对比到实践压测的完整评估，我们最终的选择是……（这里取决于你的具体业务权重）。如果你的场景非常注重成本效益和多轮长对话的深度理解，DeepSeek R1的长上下文和性价比是巨大优势。如果你的业务对中文场景的细微语义、成语俗语理解要求极高，且团队在ChatGLM的微调生态上有积累，那么ChatGLM可能更顺手。

没有银弹，最好的模型就是最适合你当前业务阶段、技术栈和预算的那一个。建议大家在选型前，务必用自己业务的高频问题集和真实对话流，对候选模型做一次POC测试，数据会比任何评测文章都更有说服力。