传统性能测试以 QPS 为黄金指标，但在 AI 大模型场景中，这一标准远远不够。我们需要从底层逻辑出发，构建一套适配 AI 场景的完整性能测试体系。

核心分析维度：

指标定义：Token级延迟、TTFT、TPOT等AI特有指标
场景分析：并发场景、长上下文等特殊场景
测试策略：针对AI特性的压测方法
瓶颈定位：性能问题的诊断思路

关键挑战

序号	挑战	说明
1	性能退化现象	性能随上下文长度增加而退化的曲线特征，长上下文对性能的显著影响
2	并发下的上下文隔离	高并发场景下各请求上下文需相互隔离
3	会话串扰风险	多会话并发时的相互干扰问题
4	推理冷启动问题	模型首次加载或长时间闲置后的启动延迟
5	用户感知延迟分析	从用户视角评估端到端的体验延迟，冷启动对用户体验的显著影响

1	建立底层认知 → 掌握特有指标体系 → 分析核心挑战 → 学习瓶颈定位方法 → 总结完整测试方案

AI 性能测试的特殊性

维度	具体说明
QPS 的局限性	传统 QPS 指标无法全面反映 AI 应用的性能特征，需要更细粒度的性能评估维度
特有指标	Token 级延迟（单个 Token 生成时间）、TTFT（首Token时间）、TPOT（每输出Token平均生成时间）
用户体验维度	需特别关注用户感知延迟，冷启动对用户体验有显著影响
并发特性	高并发下的上下文隔离需求，会话串扰风险的特殊处理
退化现象	性能随上下文长度增加而退化的曲线特征，长上下文对性能的显著影响

为什么 AI 性能测试，不能只看 QPS？

在传统接口性能测试领域，QPS 几乎是评判服务吞吐能力的黄金标准。压测工具发请求，统计每秒完成多少请求，就能评估系统并发、瓶颈点。但当测试对象切换成大模型 AI 服务之后，如果还拿 QPS 当做唯一性能指标，很容易做出错误评估。

传统软件是确定性计算逻辑：相同输入，产出固定输出。一次 http 请求发出，等待完整响应返回，整个交互就结束。所以用 QPS 衡量每秒能处理多少完整请求，非常合理。

但大模型属于概率性生成，绝大多数线上业务都是流式输出，token 一个接一个返回给前端。用户在对话框里提问，并不是等模型全部算完再一次性返回全文，而是看着文字一点点 “打” 出来。

对比维度	传统软件性能	AI 应用性能（大模型）
计算模式	确定性计算	概率性生成
输出特点	输入输出一一对应，结果固定可预测	流式 Token 逐字输出，结果不完全固定
核心性能指标	QPS（每秒请求数）	Token/s、TTFT、TPOT
衡量侧重点	关注请求完成：整体请求速度、系统并发吞吐能力	关注生成过程：流式输出流畅度、真实用户交互体验
用户体验视角	请求发出去，等待完整响应返回即结束	发送提问后，等待逐字吐出内容，过程体感最重要

指标名词释义

TTFT：首 Token 延迟，发出请求到返回第一个字符的耗时，决定用户感知到的 “响应快慢”
Token/s：每秒生成 Token 数量，代表文字输出速度
TPOT：单 Token 间隔时间，衡量流式输出是否卡顿、断断续续

核心结论

AI 性能测试重点是生成过程体验，不能只统计完成请求的数量。传统 QPS 只能衡量吞吐，无法反映流式交互的真实体验，仅可作为辅助参考指标。

AI 性能指标体系概览

AI 性能测试是一套分层立体的指标体系，分为用户体验、系统性能、资源消耗三层。用户体验层看 TTFT 这类用户直观体感指标；系统性能层看 QPS、TPOT、并发，衡量服务处理能力；资源消耗层监控 GPU、CPU、内存，评估硬件成本。只盯着某一个指标会出现评估偏差，三层结合，才能同时保证体验、并发能力和硬件性价比。

分层	核心指标	关注点	说明
用户体验层	TTFT、用户感知延迟	用户等待的 “感觉” 与流畅度	面向真实使用者，重点感受模型多久出第一个字、输出过程卡不卡
系统性能层	TPOT、QPS、并发用户数	系统处理请求的能力和效率	面向服务本身，衡量系统吞吐、并发、token 生成间隔
资源消耗层	GPU/CPU 利用率、内存占用	硬件成本与效率的权衡	面向基础设施，看硬件资源开销，评估成本是否可控

一个立体、分层的指标体系，是保障 AI 服务高质量、高效率、高性价比的关键。

用户体验层（最贴近真实用户）

TTFT（首 Token 延迟）：用户提问之后，直到收到模型返回第一个 token 的时间，是用户最直观的感受。TTFT 太高，用户会直接觉得 “AI 卡死没反应”。
用户感知延迟：包含整体交互感受，流式输出的流畅程度。

这一层回答：用户用起来爽不爽？

系统性能层（服务吞吐能力）

TPOT：每个输出 token 之间的间隔，代表流式输出会不会断断续续。
QPS：每秒完成请求数，传统性能指标，代表服务能处理多少完整请求。
并发用户数：同时访问 AI 服务的用户规模。

这一层回答：系统扛不扛得住大量请求？

资源消耗层（硬件成本视角）

GPU 利用率、CPU 利用率、内存占用。大模型推理主要消耗 GPU 算力。同样业务量下，如果 GPU 利用率很低，代表硬件浪费，成本高；利用率过高，又会造成排队、延迟飙升。需要做成本和性能之间的权衡。

这一层回答：硬件烧得贵不贵，资源利用是否合理？

深入理解：Token 级延迟

大模型和传统接口最大区别是流式输出。

用户提交 Prompt 之后，LLM 并不是算完所有内容再返回，而是逐个生成 Token，源源不断吐出结果。每个 Token 之间的生成间隔，就是 Token 级延迟（TPOT Time Per Output Token相邻两个输出 Token 的时间间隔，判断输出是否卡顿、跳字、停顿）。

传统压测只统计请求的整体总耗时；但 AI 场景下，就算总耗时指标合格，如果 Token 间隔抖动大，输出断断续续，用户依旧会觉得服务卡顿。所以做 AI 性能测试，不能只盯着请求结束那一刻，必须关注每一个 Token 生成的全过程。

Token 级延迟，直接决定用户对话交互体验好坏。

flowchart LR
    A[输入Prompt 用户提问] --> B[大语言模型LLM推理计算]
    B --> C{生成输出Token?}
    C -->|输出第1个Token| D[返回首个Token
👉TTFT计时结束]
    D --> E[继续生成下一个Token]
    E --> F[相邻Token时间间隔
👉Token级延迟 / TPOT]
    F --> C
    C -->|全部生成完成| G[流式输出结束，请求完成]

用户提交 Prompt，模型开始推理；
产出第一个 Token，此时 TTFT（首 token 延迟）统计结束，用户页面开始看到文字；
循环不断生成后续 Token，每两个 Token 之间的时间就是 Token 级延迟 TPOT；
循环直到全部内容生成完毕，本次请求结束。

TTFT：决定用户第一感受的首 Token 延迟

TTFT（Time To First Token，首次 Token 时间）= 收到第一个 Token 时间 − 用户发送请求时间。它代表用户发送提问之后，多久能看到第一个字，是大模型体验的第一道门槛。

TTFT 是用户等待感的主要来源，直接决定交互即时性。行业经验焦虑阈值：TTFT 尽量控制在 1 秒以内。 TTFT 表现好，会给用户 “秒回” 的直观感受；一旦超过 1 秒，用户就会明显感受到等待、焦虑，甚至误以为服务卡死。

注意：TTFT 只衡量第一个 token 返回，不代表后续输出流畅度。TTFT 优秀，也可能出现后面输出卡顿，需要结合 TPOT、Token/s 综合判断。

项目	内容
全称	TTFT（Time To First Token）首次 Token 时间
计算公式	TTFT = 接收到第一个 Token 的时间 − 发送请求的时间
核心含义	用户发出提问，到服务返回第一个字 / 词的耗时，是衡量大模型响应速度的首要指标
用户体验影响	1. 是用户 “等待感” 主要来源，直接决定交互即时性 2. 决定用户对 AI 的第一印象；低 TTFT 带来 “秒回” 感受，提升流畅度
焦虑阈值	TTFT 建议控制在 1s 以内，避免用户产生等待焦虑

timeline
    title TTFT时间线示意
    0 : 用户发送Prompt请求
    0~800ms : LLM模型预热推理
    800ms : 🎯返回第一个Token 
TTFT=800ms
    800ms之后 : 持续输出后续Token序列

TPOT：决定流式输出丝滑度的关键指标

TPOT（Time Per Output Token），单个输出 Token 平均耗时。

公式：TPOT = (总生成时间 − TTFT) / (生成的Token总数 − 1)

TTFT 负责 “第一个字什么时候出现”，TPOT 负责第一个字出来之后后续输出的表现。它代表首个 Token 之后，平均生成每一个后续 Token 的时间。

TPOT 有三层价值：

吞吐能力：TPOT 直接换算出Token/s，TPOT 越小，每秒产出 token 越多，服务吞吐越强；
用户流畅度：TPOT 数值低且波动小，文字顺滑输出，用户感觉是在阅读；TPOT 高、抖动大，输出断断续续，用户不断等待；
业务成本：按 Token 计费的 API，TPOT 关系整体推理效率，直接影响硬件、调用成本。

实战提醒：TTFT 再好，如果 TPOT 抖动严重，流式对话体验依旧崩盘。TTFT 和 TPOT 必须搭配评估，二者缺一不可。

项目	内容
全称	TPOT（Time Per Output Token）每个输出 Token 耗时
计算公式	TPOT = (总生成时间 − TTFT) ÷ (生成的 Token 总数 − 1)
核心含义	返回第一个 Token 之后，平均每生成一个后续 Token 消耗的时间，衡量模型持续输出的速度，也就是流式输出过程中字与字之间的间隔。
系统 & 体验影响	1. 吞吐量关键：TPOT 直接决定`Token/s`（每秒生成 token 数），代表服务的承载吞吐能力 2. 阅读流畅度：TPOT 低且稳定，输出顺滑像阅读；TPOT 高、抖动大，就会卡顿、断断续续，用户一直在等待 3. 成本控制：按 Token 计费的 API 场景，TPOT 直接影响服务成本效益与运营效率

timeline
    title TTFT与TPOT时序对照
    0ms : 用户发送请求
    700ms : 🎯返回第1个Token，TTFT=700ms
    700ms + TPOT : 返回第2个Token
    700ms + 2*TPOT : 返回第3个Token
    700ms + 3*TPOT : 返回第4个Token
    note : 后面每一个Token间隔，就是TPOT

代码实战

# 这个示例代码展示了如何使用 Locust 对 Ollama 进行压力测试，并计算 TTFT（Time To First Token）和 TPOT（Token Per Token）指标。
# 你可以根据需要修改配置区域的参数来适配你的测试场景。
# 运行这个脚本后，Locust 会启动一个 Web 界面，你可以在其中设置虚拟用户数量和生成速率，然后开始测试。测试过程中，TTFT 和 TPOT 指标会在 Locust 面板的请求统计中显示
# 安装 Locust: pip install locust

import time
import json
from locust import HttpUser, task, between, events


class OllamaLoadTestUser(HttpUser):
    wait_time = between(1, 2)  # 虚拟用户之间的等待时间间隔

    # --- 配置区域 START ---
    # Ollama 默认地址，通常无需修改
    OLLAMA_HOST = "http://192.168.1.37:11434"
    # 你本地已拉取的模型名称（例如: llama2, mistral, qwen 等）
    MODEL_NAME = "deepseek-r1:14b"
    # 测试用的 Prompt
    PROMPT = "请详细介绍一下金字塔的建造过程。"
    # 生成长度限制（可选）
    MAX_TOKENS = 10
    # --- 配置区域 END ---

    def on_start(self):
        # 确保 Locust 的 host 指向 Ollama
        self.client.base_url = self.OLLAMA_HOST

    def _report_custom_metric(self, metric_name, value_ms):
        """向 Locust 面板上报自定义指标"""
        events.request.fire(
            request_type="LLM_Metric",
            name=metric_name,
            response_time=value_ms,
            response_length=0,
            exception=None,
        )

    @task
    def chat_completion_stream(self):
        url = "/v1/chat/completions"
        headers = {
            "Content-Type": "application/json"
        }

        # Ollama 的 OpenAI 兼容格式 Payload
        payload = {
            "model": self.MODEL_NAME,
            "messages": [
                {"role": "user", "content": self.PROMPT}
            ],
            "stream": True,
            "options": {
                "num_predict": self.MAX_TOKENS
            }
        }

        # 初始化计时器
        start_time = time.time()
        first_token_received = False
        token_timings = []  # 存储每个 Token 的生成间隔
        last_token_time = None

        with self.client.post(url, headers=headers, json=payload, stream=True, catch_response=True) as response:
            if response.status_code != 200:
                response.failure(f"请求失败: {response.status_code}")
                return

            # 逐行读取流式数据
            for line in response.iter_lines():
                if line:
                    decoded_line = line.decode('utf-8')
                    # 解析 SSE 格式 (data: ...)
                    if decoded_line.startswith('data: '):
                        data_str = decoded_line[6:]
                        # SSE结束标记
                        if data_str.strip() == "[DONE]":
                            break
                        try:
                            current_time = time.time()
                            data_json = json.loads(data_str)
                            # 拿到delta内容才代表token到达
                            choices = data_json.get("choices", [])
                            if len(choices) == 0:
                                continue
                            delta = choices[0].get("delta", {})
                            if "content" not in delta:
                                continue

                            if not first_token_received:
                                # --- 计算 TTFT ---
                                ttft = current_time - start_time
                                first_token_received = True
                                last_token_time = current_time
                                # 上报 TTFT (单位：毫秒)
                                self._report_custom_metric("TTFT", ttft * 1000)
                            else:
                                # --- 计算 TPOT (单个 Token 间隔) ---
                                if last_token_time:
                                    tpot_interval = current_time - last_token_time
                                    token_timings.append(tpot_interval)
                                    last_token_time = current_time

                        except json.JSONDecodeError:
                            print("JSON 解析错误")
                            pass
                        except Exception as e:
                            print(f"解析错误: {e}")

            response.success()

        # 会话结束后，计算平均 TPOT 并上报
        if token_timings:
            avg_tpot = sum(token_timings) / len(token_timings)
            self._report_custom_metric("TPOT", avg_tpot * 1000)

运行命令： locust -f ttft_demo.py

代码模块	功能说明
`on_start`	虚拟用户初始化，绑定 ollama 服务地址
`_report_custom_metric`	Locust 事件上报，把 TTFT/TPOT 自定义指标输出到 web 面板
`stream=True`	开启 SSE 流式，接收逐 Token 返回
TTFT 计算	收到第一个有效 token时，`当前时间 - 请求发起时间`，转毫秒上报
TPOT 计算	第一个 token 之后，记录每一个 token 的时间差；会话结束求平均值上报
SSE 解析	处理`data:`前缀，跳过`[DONE]`结束标记，捕获 json 解析异常

用户感知延迟分析

TTFT和TPOT如何共同影响体验：

TTFT（Time To First Token，首 token 时间），TTFT 决定了“第一印象”
- 含义：从发送提问，到收到模型返回第一个字符的等待时间，是用户等待的起点。
- 影响：TTFT 过高，用户刚发出请求就要长时间等待，直接失去耐心。
- 通俗理解：你问 AI 问题，多久看到第一个字出来。
TPOT（Time Per Output Token，每输出一个 token 耗时），TPOT 决定了“阅读体验”
- 含义：模型流式输出时，后续每生成一个字符的间隔耗时。
- 影响：TPOT 不稳定，会出现输出卡顿、断断续续，打断用户阅读节奏，看着文字一顿一顿蹦出来。
- 通俗理解：第一个字出来之后，后面文字打字输出的流畅度。

黄金法则

低 TTFT + 稳定 TPOT = 流畅对话体验

TTFT 要低：第一时间尽快吐出第一个字，不让用户干等；
TPOT 要稳定：后续文字持续平稳输出，不要忽快忽慢、卡顿。

长上下文的性能挑战

长上下文是大模型很吸引人的能力，但它是一把”双刃剑“。上下文越长，模型记忆信息越多，可以完成复杂任务。但注意力机制 (O(n^2)) 的复杂度，会带来计算量平方级增长，带来巨大内存带宽压力，内存占用急剧抬升，甚至出现 OOM 内存溢出。长上下文会直接恶化 TTFT、TPOT，带来明显的用户感知延迟。

更长上下文，模型可以记住更多历史对话 / 文档信息，支持摘要长文档、多轮长对话等复杂任务。

⚠️ 性能代价

计算量剧增 Transformer 注意力机制复杂度是 (O(n^2))，上下文长度 n 增大，计算量会按平方级暴涨。上下文越长，推理计算耗时成倍增加。
内存带宽压力 推理时需要反复加载、处理大量历史上下文 token，大量占用显存带宽，直接拉高 TTFT、TPOT，造成响应变慢。
内存溢出风险 OOM 上下文过长，显存被占满，直接触发 OOM（Out of Memory），请求直接失败。

性能退化曲线示例

随着并发请求上升，大模型推理性能会经历三个阶段：平稳期、缓慢下降期、急剧下降期。性能拐点（Knee Point）是关键分界线，代表系统最大服务能力。一旦越过拐点，TPOT 会断崖式恶化，用户流式输出体验雪崩。线上业务要避开拐点，预留资源缓冲，不要跑满系统极限能力。

平稳期 系统资源充足，TPOT 指标保持稳定。并发压力不大，显卡、显存带宽够用，流式输出流畅。
缓慢下降期 资源开始紧张。随着并发继续上涨，TPOT 慢慢变差，性能逐步下滑。此时还没有彻底崩，但用户已经能隐约感受到输出变卡。
急剧下降期 系统资源耗尽，发生性能崩溃。TPOT 会急剧飙升。并发再多一点，响应严重卡顿，大量请求体验恶化。

并发挑战：上下文隔离

在大模型高并发服务场景，大量用户请求会共享 GPU 计算资源，上下文隔离是并发架构的核心挑战。所谓上下文隔离，就是保障各个用户 Session 会话之间严格隔离。一方面守护数据安全，杜绝不同用户之间隐私信息互相泄露；另一方面保障业务逻辑正确，每个用户的对话状态独立，不会出现上下文串扰，模型输出错乱。一旦隔离机制失效，不仅会引发隐私泄露风险，还会直接导致业务结果不可用。

什么是上下文隔离

当多个用户请求并发跑在同一套 GPU 资源上，系统要做到不同用户会话（Session）完全互相隔离，用户 A 的对话上下文，绝对不能泄露、干扰到用户 B。

两大核心价值

数据安全 避免 A 用户的隐私提问、敏感输入，泄露给其他用户，防止信息串话、数据泄漏事故。
业务逻辑正确性 防止不同用户的对话状态互相串扰，保证每个用户拿到属于自己独立的模型输出，不会出现 “我的对话里莫名其妙出现别人的聊天内容” 这种诡异 bug。

⚠️ 并发压测容易踩坑：只统计 QPS、响应耗时，忽略业务数据校验。举个例子：做 10 万下单并发压测，接口全部返回成功，但是数据库实际写入订单不足 10 万条。接口显示成功，业务数据已经出错。

会话串扰（Session Crosstalk）风险

当上下文隔离机制失效，就会出现会话串扰（Session Crosstalk）。也就是一个用户的会话信息错误污染、混入另一个用户的对话。举个典型现象：用户 A 询问苹果手机，用户 B 询问香蕉，高并发下模型回复 A 的内容里莫名其妙带上香蕉的信息。该风险等级极高，一方面会造成用户隐私泄露，另一方面直接破坏业务逻辑，模型输出完全失真。这也给大模型压测提出新要求：不能只看 QPS、响应时间等性能指标，除校验对话日志完整落库之外，还必须专项校验会话隔离，确认并发场景不会发生会话串扰。

直观案例

用户 A 提问：介绍苹果手机
用户 B 提问：介绍香蕉
❌异常结果：模型回复用户 A 的时候，输出内容混入了香蕉相关信息。

明明 A 完全没有提过香蕉，返回结果却带上 B 的提问信息，这就是典型会话串扰。

风险等级：极高

它会带来两类严重问题：

隐私安全事故：用户的私密提问、敏感业务内容，泄露给其他完全无关的用户，造成信息泄露。
业务逻辑错乱：模型输出被别人的上下文干扰，返回完全不符合预期的错误答案，上层业务直接出错。

示意图含义：并发请求同时处理时，不同会话的信息发生错误交叉混合，不同用户的对话内容互相 “串门”。

和压测校验结合

很多性能压测，只看 QPS、响应时延、接口返回成功，不会做会话串扰专项校验。哪怕接口全部 200，吞吐量指标很漂亮，高并发下依然会出现会话串扰。

普通业务压测：10 万下单，校验数据库是否落满 10 万条订单；
大模型压测：高并发压测同时，必须增加会话隔离校验，验证 A 用户的输出，绝对不能混入 B 用户的对话信息。

并发压测策略

大模型并发压测不能简单粗暴地并发打接口，需要一套组合策略。首先要模拟真实用户行为，回放真实会话，避免使用千篇一律的重复请求；同时采用混合请求模式，把短查询、长文档总结、多轮对话都纳入压测流量，贴近线上真实流量特征。短时冲高压测不足以验证稳定性，需要在预估峰值 80% 负载下持续跑数小时，观察性能退化以及内存、显存泄漏。最重要的是，需要增加会话隔离专项测试，给每个请求增加独有的标识，以此检测是否出现会话串扰。把以上策略组合起来，才能完整评估大模型服务高并发场景下的性能、稳定性与安全能力。

模拟真实用户行为

不要只用一套固定请求反复循环压测。通过录制、回放真实业务会话，覆盖长短不一、复杂度各不相同的请求，规避单一重复请求带来的测试偏差。

如果压测全部使用一模一样 prompt，会掩盖很多线上才会暴露的问题，压测结果会虚高，和真实线上表现脱节。

混合请求模式

压测流量需要做场景混合，同时注入多种请求类型：简短问答、长文档总结、多轮连续对话等。线上用户本来就会同时做简单提问、长文本处理、多轮聊天，混合请求模式更贴近真实业务流量，能暴露出单一场景测不出来的资源竞争问题。

长时间稳定性测试

很多人只做短时间脉冲式压测，这是不够的。将负载维持在预估峰值的80%，连续跑数小时，重点观测：

系统是否发生缓慢性能退化
是否存在内存泄漏、显存泄漏问题

短压看不出来的内存缓慢泄露，长时间跑负载才会暴露，这是验证系统稳定性的关键手段。

专项测试隔离有效性（对应前面会话串扰风险）

普通性能压测测不出会话串扰，需要专门设计测试用例。常用手段：给每个用户的 Prompt 带上唯一标识符，例如给 A 用户加入专属标记#userA_001，B 用户带上#userB_002。并发跑起来之后，校验返回结果：A 的输出不能出现 B 的唯一标记，B 的输出不能出现 A 的标记，以此验证有没有发生会话信息交叉串扰。

性能瓶颈定位

压测出现性能退化之后，需要从多维度定位瓶颈，不要直接默认就是 GPU 算力不够。优先排查 GPU：算力、显存带宽、是否触发硬件降频；其次检查主机内存，警惕 Swap 大量使用；再看网络带宽、网卡队列是否溢出。同时不能忽略软件架构：推理框架效率、调度逻辑、前后处理逻辑，经常会在 GPU 还没打满的时候就成为瓶颈。除此之外，CPU 负载、磁盘与数据库 I/O，也都有可能成为整个服务的性能短板。只有把硬件指标和软件链路结合分析，才能精准找到真正的性能瓶颈。

完整排查顺序参考：GPU → 内存 → CPU → 网络 → I/O → 软件架构。

做完并发压测之后，如果发现性能不达标、时延上涨、吞吐量上不去，就要做瓶颈定位。这张图把大模型场景常见瓶颈划分为 6 大维度：GPU、内存、网络、软件架构、数据 I/O、CPU。

GPU（大模型最首要瓶颈）

GPU 是大模型推理的核心，绝大多数性能问题都出在这里。

计算能力不足：算力跟不上并发请求，token 生成速度下降；
显存带宽限制：带宽跑满，会严重制约 token 输出速率；
核心频率 Throttling（降频）：GPU 过热、功耗上限触发，硬件主动降频，直接导致推理速度暴跌。

很多时候 GPU 利用率看着不高，但带宽已经打满，这是非常容易被忽略的点。

内存（主机内存，非显存）

这里指服务器主机内存，不是 GPU 显存：

主机内存不足，业务进程、缓存无法正常加载；
Swap 交换分区被大量使用，系统开始读写磁盘充当内存，整体响应会出现剧烈抖动。

网络

客户端和服务端、服务内部组件之间的网络问题：

带宽瓶颈：大 prompt、长返回报文占满带宽；
网络延迟过高；
NIC 网卡队列溢出：并发请求打满网卡队列，发生丢包、请求超时。

软件架构（软件层面瓶颈，容易被硬件指标掩盖）

硬件资源充足，但软件设计不合理照样跑不起来：

模型本身参数规模过大；
推理框架执行效率低下；
请求调度策略不合理，负载分配不均衡；
请求前后处理逻辑（预处理、后处理）耗时过长，拖慢整体链路。

数据 I/O

磁盘、数据库读取成为卡点：从磁盘、数据库加载会话上下文、向量数据、业务数据速度慢，IO 等待拉高整体接口时延。

CPU

很多人误以为大模型只吃 GPU，忽略 CPU 压力：

CPU 算力不足；
业务代码、预处理、调度逻辑消耗大量 CPU 资源，CPU 成为整个链路的 “卡点”，GPU 反而空闲等待。

Jean's Blog

AI应用性能测试