企业官网建设流程全解析

前言

前面我们完成了LLM服务网关的完整架构落地，具备了流量接入、鉴权、路由、限流、SSE透传能力。

但是能跑 ≠ 能上线。

很多同学的AI项目，本地跑Demo秒回、效果完美，一上并发、一上多用户、一拉长文本请求，立刻出现：

• 首字等待极慢、用户卡顿严重

• 并发一高全部请求排队超时

• GPU显存震荡、忽高忽低、偶尔OOM

• 流式卡顿、断断续续、SSE断连

• 后端负载不均、部分节点满载、部分空闲

这就是因为缺少大模型专属性能压测体系。传统Web压测（QPS、RT）完全不适用LLM长任务场景。

今天是整套AI工程体系中最硬核、最生产化、面试最能拉开差距的一篇：专门讲解工业级LLM压测指标、压测方案、自动化压测脚本、分层瓶颈定位、全维度性能调优。

读完本篇，你的项目从“能跑Demo”直接升级为具备SLA可用性的商用级AI服务。

一、为什么LLM不能用传统Web压测？

1.1 传统Web接口特点

普通HTTP接口：毫秒级响应、短连接、无状态、单请求资源消耗极低。

评价标准：QPS、平均RT、成功率、错误率。

1.2 LLM推理完全是反模型

• 单请求耗时极长：数百ms ~ 数十秒

• 属于GPU算力密集型长任务

• 有严格的串行调度特性（GPU Batch推理）

• 流式输出持续占用连接与显存

• 输入越长、输出越长，资源消耗倍数上涨

所以：QPS 对 LLM 毫无参考意义。

工业界只用四套专属指标：TTFT、TPOT、Throughput、Concurrency。

二、四大核心LLM性能指标

2.1 TTFT：首Token响应时间（用户体验核心）

Time To First Token：用户发送提问后，看到第一个文字的等待时间。

直接决定用户体感，是产品体验第一指标。

工业标准：

• 优秀：< 300ms

• 良好：300ms ~ 800ms

• 及格：800ms ~ 1.5s

• 糟糕：> 2s（用户明显卡顿、流失率飙升）

TTFT 瓶颈来源：Prompt预处理、KV Cache初始化、队列排队、GPU调度延迟、网络延迟。

2.2 TPOT：单Token生成速度（算力真实速度）

Time Per Output Token：每生成一个新token的平均耗时。

代表模型真实生成速度、GPU算力饱和度。

TPOT越小，模型越快。

工业级标准：10~25ms/token 属于正常速度。

TPOT 过高说明：GPU算力不足、batch堆积过大、量化参数不合理、推理引擎优化不足。

2.3 Throughput：全网吞吐（服务能力上限）

单位时间可生成的总 Token 数量（tokens/s）。

代表整套集群的最大算力产能，是扩容、机器采购的核心依据。

2.4 Max Concurrency：最大并发数（线上限流依据）

单卡/单节点可稳定承载的同时进行中的推理任务数。

这就是我们Day66网关限流的核心依据：LLM限流不靠QPS，靠最大并发数。

三、LLM压测两种场景：Prefill阶段 / Decode阶段

大模型推理分为两个完全不同的阶段，性能瓶颈完全不同，压测必须分开分析。

3.1 Prefill 预填充阶段（输入处理）

对用户输入Prompt做整批矩阵计算，计算密集型、可高度Batch合并、速度快。

特点：短时间爆GPU算力，显存占用暴涨。

瓶颈：GPU FP16/FP32算力、输入文本长度。

3.2 Decode 解码阶段（逐字生成）

逐个Token循环生成，访存密集型，速度慢、持续占显存。

瓶颈：显存带宽、KV Cache大小、并发任务数量。

核心结论：

TTFT 主要由 Prefill + 排队延迟决定；

TPOT 主要由 Decode 显存带宽决定。

四、工业级LLM压测方案设计

普通压测工具（JMeter、AB）无法模拟流式、长任务、动态token消耗。我们需要自研一套LLM专属压测体系。

4.1 压测维度

1. 短prompt短生成：模拟日常问答

2. 长prompt短生成：模拟RAG检索长上下文

3. 短prompt长生成：模拟写文章、代码生成

4. 长prompt长生成：超高负载极限压测

4.2 压测梯度

从 1、5、10、20、30、50 并发逐级加压，观测：

• TTFT 何时开始恶化

• TPOT 何时明显上涨

• 显存何时打满

• 队列何时积压

• 错误率何时上升

从而得出单节点安全并发水位，用于网关限流阈值配置。

五、C++ + Python 双版本压测实战代码（可直接上线）

下面提供工业级流式LLM压测代码，自动统计 TTFT、TPOT、平均耗时、成功率。

5.1 Python 自动化压测脚本（运维批量压测用）

import requests import threading import time from datetime import datetime API_URL = "http://127.0.0.1:8000/v1/stream" CONCURRENCY = 20 TEST_PROMPT = "请详细讲解大模型性能优化方法" result_list = [] def stream_test(): st_total = time.time() first_token_time = None headers = {"Content-Type":"application/json"} json_data = { "prompt": TEST_PROMPT, "stream": True, "max_new_tokens": 512 } try: resp = requests.post(API_URL, json=json_data, stream=True, timeout=30) for chunk in resp.iter_content(chunk_size=None): if first_token_time is None: first_token_time = time.time() total_time = time.time() - st_total ttft = first_token_time - st_total result_list.append((ttft, total_time)) except Exception as e: print("请求失败：",e) if __name__ == "__main__": threads = [] for i in range(CONCURRENCY): t = threading.Thread(target=stream_test) threads.append(t) t.start() for t in threads: t.join() avg_ttft = sum([x[0] for x in result_list]) / len(result_list) avg_total = sum([x[1] for x in result_list]) / len(result_list) print(f"平均TTFT: {avg_ttft:.3f}s") print(f"平均总耗时: {avg_total:.3f}s")

5.2 C++高性能压测客户端（生产压测首选）

#include <iostream> #include <thread> #include <vector> #include <chrono> #include <curl/curl.h> #include <nlohmann/json.hpp> using json = nlohmann::json; using namespace std; using namespace chrono; const int CONCURRENCY = 20; string url = "http://127.0.0.1:8000/v1/stream"; string prompt = "详细讲解大模型压测与性能优化"; vector<double> ttft_list; vector<double> total_list; mutex mtx; size_t stream_cb(void*, size_t s, size_t n, void* user) { auto* first_time = (system_clock::time_point*)user; if(*first_time == system_clock::time_point()){ *first_time = system_clock::now(); } return s*n; } void test_func(){ auto start = system_clock::now(); auto first_token_ts = system_clock::time_point(); CURL* curl = curl_easy_init(); json req; req["prompt"] = prompt; req["stream"] = true; req["max_new_tokens"] = 512; string post_data = req.dump(); struct curl_slist* hd = nullptr; hd = curl_slist_append(hd, "Content-Type:application/json"); curl_easy_setopt(curl, CURLOPT_URL, url.c_str()); curl_easy_setopt(curl, CURLOPT_POSTFIELDS, post_data.c_str()); curl_easy_setopt(curl, CURLOPT_HTTPHEADER, hd); curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, stream_cb); curl_easy_setopt(curl, CURLOPT_WRITEDATA, &first_token_ts); curl_easy_setopt(curl, CURLOPT_TIMEOUT, 30L); curl_easy_perform(curl); curl_easy_cleanup(curl); curl_slist_free_all(hd); double ttft = duration_cast<milliseconds>(first_token_ts - start).count() / 1000.0; double total = duration_cast<milliseconds>(system_clock::now() - start).count() / 1000.0; lock_guard<mutex> lk(mtx); ttft_list.push_back(ttft); total_list.push_back(total); } int main(){ vector<thread> thds; for(int i=0;i<CONCURRENCY;i++) thds.emplace_back(test_func); for(auto& t : thds) t.join(); double avg_ttft=0, avg_total=0; for(auto v:ttft_list) avg_ttft+=v; for(auto v:total_list) avg_total+=v; avg_ttft /= ttft_list.size(); avg_total /= total_list.size(); cout << "平均TTFT: " << avg_ttft << "s\n"; cout << "平均总耗时: " << avg_total << "s\n"; return 0; }

六、分层瓶颈定位体系

压测出指标后，如何精准定位瓶颈？分为四层排查。

6.1 网络层瓶颈

现象：TTFT高、GPU利用率低、卡顿断断续续。

原因：网关转发延迟、TCP参数不合理、SSE粘包、带宽不足。

优化：调优TCP队列、开启内核快速应答、长连接复用、网关零拷贝转发。

6.2 队列调度层瓶颈

现象：GPU空闲，但请求排队严重、TTFT飙升。

原因：并发限流不合理、队列堵塞、任务调度不公平。

优化：动态队列、优先级调度、自动扩缩容。

6.3 Prefill计算层瓶颈

现象：长文本请求TTFT爆炸、GPU瞬间满载。

优化：动态Batch、Prompt缓存、上下文压缩。

6.4 Decode显存带宽瓶颈

现象：TPOT持续走高、并发一高就变慢。

优化：KV Cache量化、PagedAttention、显存池化、模型量化调优。

七、全维度生产级调优方案

• INT4/INT8量化调优：平衡速度与精度，大幅降低访存压力

• PagedAttention开启：解决KV Cache内存碎片化，提升并发上限

• 动态Batch推理：合并瞬时请求，提升GPU利用率

• Prompt Cache缓存：重复上下文直接命中，大幅降低TTFT

• 网关精准限流：基于压测得出的安全并发阈值限流

• 多级队列优先级：核心业务优先调度

• TCP内核参数调优：解决SSE长连接超时、断连

• 多模型负载隔离：防止大模型抢占小模型算力

八、线上经典故障复盘

故障1：并发不高，但TTFT持续上涨

根因：KV Cache碎片化严重，显存不断膨胀，Decode速度持续下降。

解决方案：开启分页注意力机制、定时清空缓存、限制单用户最大上下文长度。

故障2：GPU利用率很低，但是请求极慢

根因：网关队列堵塞、请求排队超时，并非算力不足。

故障3：短文本很快，长文本直接超时

根因：Prefill阶段无动态batch，长文本独占GPU导致排队雪崩。

九、面试终极问答

Q：LLM为什么不用QPS做性能指标？

答：LLM是长耗时GPU任务，QPS极低但并发压力巨大。QPS无法体现显存占用、排队延迟、生成速度。工业界统一使用 TTFT、TPOT、吞吐、并发数四维指标。

Q：TTFT 和 TPOT 分别优化哪些方向？

答：TTFT优化排队延迟、Prefill速度、网络转发、缓存命中率。TPOT优化显存带宽、KV Cache、量化策略、解码效率。

Q：如何提升单机最大并发承载？

答：降低单请求显存占用（量化、KV缓存优化）、减少显存碎片、动态batch、合理队列调度。

Q：压测的意义是什么？

答：拿到线上安全水位，确定网关限流阈值、机器扩容标准、保障SLA稳定，避免上线雪崩。

十、总结

1. LLM性能体系完全区别传统Web，核心指标是 TTFT、TPOT、吞吐、最大并发。

2. 推理分为 Prefill 计算密集、Decode 访存密集两个阶段，瓶颈完全不同。

3. 压测必须梯度压测、长短文本全覆盖，拿到真实线上安全水位。

4. 性能瓶颈分为：网络、队列、Prefill、显存四层，逐层定位调优。

5. 本篇内容可以直接写进简历：具备大模型性能压测、瓶颈分析、线上SLA调优、集群稳定性治理工程能力。