做搜索服务的人，这两年大概率逃不开一个话题：怎么在检索链路里塞入向量召回、怎么把用户查询和候选文档做embedding、怎么在延迟预算内把模型推理跑完。Perplexity这类AI驱动的大规模搜索结果服务，本质上就是把传统倒排索引的绿色通道变成了一条GPU推理流水线。很多人以为这只是“索引里多了一列向量”，实际上整个服务从架构形态到资源规划都不一样了——每个query进来要做query嵌入推理，百万级候选文档要提前做文档嵌入推理，一次搜索可能要触发成千上万次小张量的矩阵运算，这些活全部压到GPU上之后，批处理策略就成了吞吐和延迟之间的胜负手。
这篇文章我想从实际落地角度聊聊大规模搜索结果服务里GPU嵌入推理与批处理这件事。适合正打算给自己的搜索系统加向量召回、或者在已有rerank服务上压吞吐的同行参考，也适合对Perplexity这类产品背后的工程实现感兴趣、想搞明白“它们为什么能这么搜”的人。我不会复述官方文档，而是把我在真实服务里踩过、调过、优化过的细节拿出来讲。
1. 从Perplexity说起：为什么搜索引擎需要GPU嵌入推理
1.1 嵌入推理到底是什么
嵌入推理，说人话就是让模型把文本变成一串固定长度的浮点数。这串数字经过训练之后，被设计成一种“语义坐标”——语义相近的文本在高维空间里离得近，语义无关的文本离得远。搜索引擎拿到一个query，同样做一次嵌入推理，得到查询向量，然后再到提前建好的文档向量库里用矩阵运算把最相近的一批文档找出来。
这个过程跟传统BM25最大的区别是：BM25匹配的是字面词项，嵌入匹配的是语义概念。用户搜“怎么给猫洗澡”，传统搜索能召回包含“猫”“洗澡”字样的页面，但嵌入搜索还能召回那些通篇在讲“宠物清洁护理”但没出现完整query词的页面。Perplexity这类产品的体验感远超老一代搜索引擎，靠的就是这个语义泛化能力。
那为什么非要“GPU”嵌入推理？因为Transformer架构的嵌入模型，核心计算是矩阵乘法和注意力机制。这类运算在CPU上属于“能跑但活很重”的类型。一次推理还好，但搜索引擎的流量是按毫秒和并发算的，一秒钟哪怕只有几百个查询，每个查询都要过一遍Transformer，CPU很快就会被吃满，延迟也会一路飙升。
1.2 为什么必须上GPU：一次线上事故的教训
我之前维护过一套纯CPU做query嵌入的服务。模型是12层的MiniLM，参数量大概3300万，单条文本的嵌入推理延迟在CPU上大约是30到50毫秒。听起来还能接受是不是？问题出在并发上。搜索系统的查询不是排队来的，是一波一波涌进来的。一旦QPS超过50，CPU就忙不过来了，排队延迟直接把P99推到1秒以上，搜索结果页刷不出来。
那次事故之后我把推理迁到了GPU。同样的模型在T4上单条延迟大约4到6毫秒，吞吐翻了将近十倍。更关键的是，GPU天然适合并行处理批量小张量——把几十条文本拼成一个batch喂给模型，总耗时往往只比单条多一点点。这就为批处理埋下了伏笔：CPU是“一个人做很多事”，GPU是“一堆人同时做类似的事”，搜索这种海量短文本推理场景，天生就是GPU的主场。
2. 大规模搜索结果服务的整体设计与思路拆解
2.1 服务链路全景：从query到结果页
先画一下大规模搜索结果服务的完整链路，让后面讲细节时大家都有个上下文。整个服务大致分四段：
入口层：接收query，做query理解。包括语言识别、分词、改写。Perplexity这类产品通常会在这里把query做一次改写或扩展，生成多个更利于检索的子查询。
召回层：双路召回。一路走传统稀疏倒排索引，快速拿回字面匹配的文档；另一路走向量召回，把query做嵌入推理，从向量索引里拿回语义相近的文档。两路结果做合并。向量召回这一步就是嵌入推理的主战场之一。
排序层：粗排给候选集做快速打分，精排则会上更强的模型做rerank。现在的趋势是粗排精排都在向量化，两个阶段都有嵌入计算需求。
生成层：这是Perplexity和传统搜索最不一样的地方。从召回和排序选出的高相关文档片段作为上下文，喂给一个大语言模型，让它组织成一段自然语言回答，并附上引用来源。这一层也需要GPU推理，但我们这篇主要聚焦嵌入与批处理，生成层的细节先略过。
在这个链路里，GPU嵌入推理出现在两个位置：一是query侧，实时推理，延迟敏感；二是文档侧，离线批量处理，吞吐敏感。两侧的特点完全不同，优化思路也不同。
2.2 批处理的核心思想：与其刷新更快，不如算得更省
搜索服务的候选文档量是非常大的。一个中等规模的索引可能有上亿篇文档，每篇文档要切成若干段落，每段都要做嵌入。如果一段一条的串行推理，就算GPU再强，上亿次推理也要跑到天荒地老。
批处理的核心思想很简单：把大量独立的推理请求攒在一起，拼成大batch喂给模型。GPU的算力在batch足够大的时候才能真正跑满，而单次推理的额外开销（比如kernel launch）被分摊到每条样本上，平均成本大幅下降。
打个比方。你有一辆大巴车，如果每次只载一个人跑一趟，油钱和司机工资摊下来很亏。批处理就是把几十上百个乘客装上车一起跑，人均成本一下子就下来了。GPU是辆大巴车，你要想尽办法让它满载。
但批处理不等于“无脑拼batch”。batch太大模型显存会炸，batch太小GPU利用率不够。而且不同请求的文本长度差异很大，拼在一起要填充padding，导致一堆无效计算。所以真正的工程优化是动态且精细的。
2.3 在线推理 vs 离线批处理：两套完全相反的逻辑
在动手之前必须把在线和离线两条线分开讲，因为它们看上去都是GPU嵌入推理，优化目标却完全相反。
离线文档向量化是典型的吞吐敏感场景。上亿篇文档切段之后，可能是几千万甚至上亿条短文本。目标只有一个：在尽可能短的时间里，用尽可能低的成本，把这些文本全部变成向量。这里可以接受较大的batch size，比如128甚至512，可以把模型精度从fp16降到int8来换取吞吐，可以跑很久，甚至可以断点续跑。
在线query嵌入是典型的延迟敏感场景。用户在搜索框里敲下回车，几百毫秒内就要出结果。query嵌入这条链路的延迟预算通常只有几十毫秒。这里batch size不能大，因为等不起攒batch的时间；模型精度尽量保持高一点，因为精度下降会导致召回质量下降。
两种场景可以在同一套基础设施上跑，但要分开做成两条服务管道，否则一次突发的离线跑批任务会把在线查询的GPU资源挤占掉，P99瞬间崩盘。后面有一章我会讲怎么混部资源隔离。
3. 核心细节解析与实操要点
3.1 嵌入模型选型与向量维度权衡
模型选型是所有决策里最难回退的一步。嵌入模型的门派很多：有老牌的BERT系（MiniLM、Sentence-BERT），有专门为检索优化的BGE系列、GTE系列，还有多语言模型、开源指令微调的嵌入模型。
选择时最核心的三个维度：
- 向量维度：维度越高，表达能力越强，但存储成本和检索耗时越高。768维和384维的向量，在百万级文档的索引里，检索耗时会差一倍以上。
- 模型大小：MiniLM（约120MB）和BGE-large（约1.3GB）的开销差了十倍。模型越大表示能力越强，但推理延迟和显存占用也越高。
- 语言覆盖：如果你的搜索服务是多语言的，必须选多语言模型，否则跨语言语义检索就是空谈。
我的建议是：先跑评测，别拍脑袋。拿一批真实query和带标注的相关文档，对比各模型的Recall@10。如果384维的小模型能达到768维大模型95%以上的召回率，果断选小的。Perplexity这类产品能保持低延迟体验，很重要的一个原因就是把每个环节的模型做到“够用就好”。
另外需要注意一个细节：嵌入模型id的输入长度上限。很多嵌入模型是512 token上限，超过会被截断。搜索结果里的网页正文远不止512 token，这就需要在文本切段环节把每段控制在模型允许范围内，还要让切分段保留语义完整性，通常是按句子边界切。
3.2 GPU推理引擎与显存估算
选好模型之后，接下来是推理引擎。主流选项有三个：HuggingFace Transformers、ONNX Runtime、TensorRT。还有一个近年很火的vLLM，主要用于大模型生成，嵌入场景用前三个更常见。
三者的取舍我用表格说明：
| 推理引擎 | 上手难度 | 延迟表现 | 吞吐表现 | 适用场景 |
|---|---|---|---|---|
| Transformers | 低 | 中 | 低 | 快速验证、调试 |
| ONNX Runtime | 中 | 中高 | 中高 | 生产落地、跨平台 |
| TensorRT | 高 | 低 | 高 | 极致性能、固定shape |
我实际用下来，生产环境首选ONNX Runtime，它和PyTorch的兼容性好，导出一条命令，而且自带图优化（比如算子融合），不用像TensorRT那样花大量时间调engine。TensorRT性能确实最好，但模型结构一改就得重新导出、重新调参，适合稳定不动的模型。
显存估算是另一个容易踩坑的地方。公式大约是：
总显存 = 模型权重显存 + 激活显存 + 推理框架运行时显存模型权重显存=参数量×每个参数的比特数。比如3300万参数的MiniLM，fp32就是3300万×4字节≈126MB，fp16直接对半≈63MB，int8再对半≈32MB。注意这里没有算上CUDA context和cuDNN的缓存，实测下来为了安全，应该把计算值乘以1.3到1.5。
激活显存取决于batch size和输入长度。一个能被batch size为64、序列长度512填满的T4（16GB）显存，模型用int8时大概还能剩70%左右的空间，所以T4跑这种模型非常充裕。但如果换成千亿参数模型，那就是另一套算法了。在搜索嵌入场景，模型普遍在1亿参数以下，显存一般不是瓶颈，反而是batch太大导致的算子中间结果溢出才是实际会遇到的坑。
3.3 批处理调度：动态batching的完整实现
在搜索服务里，请求到达不是匀速的，而是忽高忽低。静态batch（比如固定每32条一批）在低峰期会让请求白白排队等候，高峰期batch又不够大、GPU吃不饱。动态batching才是工程上的正解。
动态batching的思路是：设一个最大等待时间（比如8毫秒）和一个最大batch上限（比如128）。请求进来后先进入队列，等待两个条件之一满足就触发推理：队列里的请求数达到上限，或者第一个请求已经在队列里等了8毫秒。这样低峰期延迟可控，高峰期吞吐最大化。
我实现过一版动态batching调度器，核心逻辑可以简化成下面这段伪代码：
class DynamicBatcher: def __init__(self, max_batch=128, max_wait_ms=8, infer_fn=None): self.max_batch = max_batch self.max_wait_ms = max_wait_ms self.infer_fn = infer_fn self.queue = Queue() self._stop = False def submit(self, texts): """提交单个请求，返回一个future""" future = Future() self.queue.put((texts, future)) return future def run(self): """调度主循环""" while not self._stop: # 先取第一条，然后等待攒batch first, first_future = self.queue.get() batch = [(first, first_future)] deadline = time.time() + self.max_wait_ms / 1000.0 while len(batch) < self.max_batch and time.time() < deadline: try: item = self.queue.get(timeout=0.001) batch.append(item) except Empty: break # 合并请求并推理 texts = [t for t, _ in batch] vectors = self.infer_fn(texts) for i, (_, fut) in enumerate(batch): fut.set_result(vectors[i])这套调度器在实际压测中拿到了不错的收益：在T4上跑MiniLM模型，单流串行推理的QPS大约80左右，换上动态batching后QPS可以拉到600以上，P99延迟没有明显恶化，因为等待窗口被控制在8毫秒以内。
代码里的关键点在于合并请求后要保证futures一一对应返回，并且推理异常要有超时和重试机制。线上环境我还加了“队列积压熔断”——如果队列里的请求超过500条，说明下游推理已经跟不上了，此时直接放弃等待、返回降级结果，强于让所有请求排队到超时。
3.4 缓存：被低估的批处理前置层
批处理负责让GPU吃饱和低延迟，但真正的第一道加速器应该是缓存。搜索场景有个很大的特点：热门query的重复率很高。在Perplexity的架构里，缓存也大量存在，有人查过“今天天气如何”，另一个人大概率也会查类似的话。
缓存要做两件事：
- 精确匹配缓存：完全相同的query文本直接命中，返回之前计算好的向量。可以用redis或者内存LRU实现。
- 语义近似缓存：这个高级一些。新query和某个已缓存query的向量距离很近时，直接复用。这要求缓存索引本身也是一个向量检索库，本质上“用搜索服务来加速搜索服务”。
我第一次做缓存时忽略了缓存值的过期策略，结果上游文档更新后，旧向量和新向量混在一个索引里，召回质量出现肉眼可见的抖动。后来给每个缓存项加了文档版本号，版本不匹配直接强制穿透重算，问题才解决。
4. 实操过程与核心环节实现
这一章把前面提到的所有方案串起来，走一遍可落地的实操流程。环境以PyTorch 2.x + ONNX Runtime + Triton Inference Server为例，这是我现在生产环境用的组合。
4.1 环境准备与模型导出
首先是PyTorch的GPU环境。别只看装个torch就完事，CUDA、cuDNN和PyTorch版本之间的兼容矩阵非常关键。以PyTorch 2.1为例，对应的CUDA 12.1安装命令：
pip install torch==2.1.2 torchvision==0.16.2 torchaudio==2.1.2 --index-url https://download.pytorch.org/whl/cu121装完之后先跑一行验证GPU是否真的可用：
import torch print(torch.cuda.is_available()) # True print(torch.cuda.get_device_name(0)) # Tesla T4 之类踩坑提示：torch.cuda.is_available()返回True不代表一切正常，最好再跑一次实际张量运算，确认没有算子兼容问题。
接着把训练好或者选定的嵌入模型从PyTorch格式导出为ONNX。导出时要把动态轴设置好，否则后续想换batch size就麻烦了。以MiniLM为例：
from transformers import AutoTokenizer, AutoModel import torch model = AutoModel.from_pretrained("sentence-transformers/all-MiniLM-L6-v2") model.eval() dummy_input = torch.randint(0, 30522, (1, 128)) # (batch, seq_len) torch.onnx.export( model, dummy_input, "minilm.onnx", input_names=["input_ids"], output_names=["sentence_embedding"], dynamic_axes={ "input_ids": {0: "batch", 1: "seq_len"}, "sentence_embedding": {0: "batch"} }, opset_version=17, )这里有一个容易忽略的点：很多库里的嵌入模型本身输出不止一个张量，你要确定取的是哪个输出。SentenceTransformer系列通常取最后一层隐藏层的mean pooling结果。如果导出的是原始模型结构，pooling需要在导出前或者推理后自己做，千万别把last_hidden_state当成最终向量用。
4.2 Triton Inference Server部署推理服务
ONNX模型导出之后，用NVIDIA Triton Inference Server来部署是最稳的路径。Triton原生支持动态batching，不用自己手写调度器。配置文件长这样：
name: "embedding" platform: "onnxruntime_onnx" max_batch_size: 256 input [ { name: "input_ids" data_type: TYPE_INT64 dims: [128] } ] output [ { name: "sentence_embedding" data_type: TYPE_FLOAT32 dims: [384] } ] dynamic_batching { preferred_batch_size: [16, 32, 64, 128] max_queue_delay_microseconds: 5000 }这段配置里，preferred_batch_size和max_queue_delay_microseconds就是Triton版的动态batching参数。前者告诉调度器优先凑哪些batch大小，后者限制请求最大在队列里待多久。5毫秒的延迟上限在实测里对在线搜索的P99影响可以控制在10毫秒以内。
Triton的启动命令：
tritonserver --model-repository=/models --gpu-memory-fraction=0.5注意--gpu-memory-fraction：如果你在同一块GPU上还要跑别的推理服务，这个参数能限制Triton的显存占用，防止模型加载时把显存一次性吃光。但如果这是专卡专用，建议设成0.9以上，让Triton有足够显存做cuda缓存管理。
客户端调用Triton的Python代码：
import tritonclient.http as httpclient import numpy as np client = httpclient.InferenceServerClient(url="localhost:8000") input_ids = np.array([[101, 1, 1, ..., 102]], dtype=np.int64) inp = httpclient.InferInput("input_ids", input_ids.shape, "INT64") inp.set_data_from_numpy(input_ids) result = client.infer("embedding", [inp]) embedding = result.as_numpy("sentence_embedding")这里有个隐蔽的坑：Triton对输入张量shape的约束非常严格。如果你在配置里指定了dims: [128]，那所有请求的序列长度都必须固定128。实际搜索场景每条文本长度不一，所以要么在预处理时统一padding到固定长度，要么在配置里把维度设成-1表示动态。前者实现简单但浪费算力，后者要用到Triton的max_batch_size和dynamic shape功能，配置更复杂但效率更高。
4.3 离线文档向量化的完整跑批流程
文档向量化的跑批不像在线推理那样有现成的Triton配置可用，因为它还涉及文档的读取、切段、去重、过滤以及结果写回。我的流程大致分四步：
文档读取与切段：把网页/PDF/文档切分成512 token以内的段落。切分点尽量放在句子末尾。从实践看，段落重叠（overlap）设成50-100 token能明显改善跨段语义割裂的问题。
批量请求：把切好的段落按128条一组打包，通过HTTP/gRPC发给Triton的嵌入服务。这里要注意并发控制，别一次性把所有段落全压进队列，否则要么客户端内存爆掉，要么把服务端打挂。我是按文档维度做分片，每个分片一个worker线程。
向量校验：拿到向量之后做一个快速校验，检查shape对不对、有没有NaN/Inf值。亲测这个步骤能拦住很多“索引里出现零向量”的诡异Bug。
写回向量库：向量和文档ID一起写入向量数据库。这里根据你的规模选型：百万级用FAISS单机够了，千万级以上要上Milvus、Elasticsearch插件这类分布式方案。
整个Pipeline用Airflow编排，每天全量跑一次，增量每五分钟跑一批。某次版本发布后我们发现增量任务老是跑到一半就失败，排查半天发现是切段逻辑改了之后，生成了几条比模型max_length还长的段落，导致Triton返回400。从此之后所有段落生成完一律本地先用tokenizer检查长度，超长直接丢弃，再也没出过问题。
4.4 在线查询链路的嵌入实时推理
在线侧query嵌入走Triton的HTTP/gRPC接口。查询阶段注意三点：
第一，query改写后要重算向量。Perplexity这类产品通常会对query做改写，但改写出的N个子查询必须逐条做嵌入推理，不能复用原query的向量。我见过有同学图省事直接用原始query向量去召回改写后子查询的相关文档，召回率掉了将近10个点。
第二，在线batch size不能大。虽然Triton支持动态batching，但在线场景请求不能等太久。max_queue_delay_microseconds建议设在3-8毫秒之间，超过这个时间宁可单条推，也不要让用户在结果页前多等几十毫秒。
第三，超时与降级。在线推理服务必须设置超时，我通常设100毫秒。一旦Triton响应超时，整个向量召回分支放弃，只走传统的BM25召回，保证搜索结果页永不空白。这个降级策略在后端抖动时是救命的。
4.5 向量索引与检索服务
嵌入推理完成之后，向量本身是死的，关键在检索。拿FAISS做示例，影响检索效果和速度的，一是索引类型，二是检索参数。
索引类型这里有个典型取舍：
| 索引类型 | 检索速度 | 内存占用 | 召回精度 | 适用规模 |
|---|---|---|---|---|
| IndexFlatIP（暴力扫描） | 慢 | 高 | 100% | 百万级以下 |
| IndexIVFFlat | 快 | 中 | 高（调好nprobe） | 千万级 |
| IndexIVFPQ | 极快 | 低 | 中低 | 亿级 |
我实际用下来，千万级文档用IVFFlat，nprobe设为16-32时，召回率和延迟都能兼顾。如果直接上PQ压缩，召回率下降通常不止1个点，除非你的业务对完全召回没有刚性需求，否则不建议默认选PQ。
再补充一个容易被忽略的点：向量索引是需要训练和更新的。IVF索引要先用一批样本来训练聚类中心，如果文档分布发生明显漂移，旧的聚类中心就不准了。我们的做法是每天凌晨用全量向量重新训练一次索引，训练期间新写入的向量进增量缓冲区，搜索时合并查两处结果。
5. 常见问题与排查技巧实录
5.1 显存不足与OOM排查
现象：Triton启动后一切正常，跑着跑着突然报CUDA out of memory，服务自动重启。
排查步骤：
- 先看是不是并发请求过多导致激活显存暴涨。
nvidia-smi能看实时显存占用，如果发现显存被逐步吃满，先降max_batch_size，把256改成128试试。 - 排查模型权重有没有被重复加载。容器化部署时，同一个模型如果副本开太多，每个副本都占一份显存。用
--gpu-memory-fraction限制每副本的显存上限。 - 确认是否开启了CUDA缓存自动清理。PyTorch和ONNX Runtime会缓存一些显存块以加速后续分配，平时看着占用高是正常的，但搭配Triton时它会在request结束后自动清理，如果你手动设了
PYTORCH_NO_CUDA_CACHE反而可能导致频繁分配碎片化。
踩坑心得：有一段时间我为了控制显存，把Triton的max_batch_size和--gpu-memory-fraction同时调小，结果吞吐下降一半不说，显存碎片化还更严重。后来把内存分数调回0.9，只用batch size控制并发，问题才消失。
5.2 推理延迟突刺怎么定位
现象：P99延迟从平稳的15毫秒突然冲到200毫秒，持续几秒后恢复。
第一排查目标永远是“有没有别的任务在抢GPU”。离线跑批任务大多不做资源隔离，一个大的批处理任务占满GPU后，在线查询的推理请求就得排队。我在混部架构里加了独占调度策略，给在线服务预留了一整块GPU，离线任务只能使用剩余的份额，P99突刺基本消失。
第二排查目标是预处理耗时。嵌入服务在真正推理之前要做tokenization和padding，这一步用的是CPU。如果文本长度分布极不均衡，比如一批长文本突然进来导致padding数量暴涨，预处理时间会上来。在调度层限制单batch内文本最大长度比，把超长文本单独放一批，能显著平滑延迟。
第三排查目标是Triton的模型实例数量。ONNX Runtime一次性只能处理一个请求的batch，如果你的QPS超过了单实例的吞吐极限，Triton会自动扩容新实例，但这个扩容过程耗时在几十毫秒量级，正好是延迟尖刺的来源。提前用instance_group配置好足够的实例数量，避免运行中扩容。
5.3 批处理参数调优速查表
批处理的参数调优是门手艺活，我把调过的参数和心得整理成一张表：
| 参数 | 影响面 | 调整倾向 | 备注 |
|---|---|---|---|
| max_batch_size | 吞吐、显存 | 从64开始，每翻倍压测一次 | 超过128后收益递减 |
| max_queue_delay | 延迟、吞吐 | 在线3-8ms，离线20-50ms | 越长吞吐越高但延迟越糟 |
| preferred_batch_size | 稳定性 | 设为2的幂次 | 配合模型优化效果最好 |
| 文本padding长度 | 算力利用率 | 按业务文本长度分布选P90 | 别按最大长度给所有文本装箱 |
最后一条最容易被忽视。搜索结果的文档长度是长尾分布的，大部分是300 token以内，少数长文有2000 token。如果统一按512 padding，短文本大部分算力都浪费在填充token上。我是先统计线上文本长度分布，把长度阈值按90分位切成256 token，超长的截断到256；精确的关键信息如果因截断丢失，再靠进阶的段落筛选逻辑保底。事实证明，这类“按数据分布定参数”的做法比任何优化技巧都提效明显。
6. 最后再聊聊我踩过的几次坑
我对嵌入推理批处理最深的体会是：很多问题不是模型或者GPU带来的，而是服务化那一层没有做好。格式转换、超时控制、并发模型、资源隔离，这些“不性感”的工程环节才是决定体验上限的地方。Perplexity这类产品能在产品质量上拉开差距，除了模型选得好，更大的功劳是工程层面把每条链路的延迟和资源控制到了极致。
我自己踩过的坑包括：刚开始用Triton时，没配动态batching，请求一多就100% CPU打满；后来配了动态batching但没设max_queue_delay，低峰期体验还好，高峰期延迟直接无法接受；再后来在多个服务混部时没做显存限制，一次离线跑批把在线推理服务的显存挤爆，线上搜索挂了十几分钟。这几件事让我彻底明白了一个道理：GPU推理服务的批处理从来不是“把请求拼一起”这么简单，你要在吞吐、延迟、稳定性之间找一个可持续的平衡点。
如果你现在正打算给自己的服务接入GPU嵌入推理，我的建议是：先从一个小规模、可观测的POC开始，把Triton动态batching的四个关键参数跑一遍压测，记录数据，再决定怎么调。别一上来就追求极致性能，稳定性永远是第一位的。
