Ling-3.1-flash 接入后首字慢 / 是并发排队还是输出太长？

首字慢不要只看总耗时。把一次调用拆成“请求从客户端发出到服务端开始处理”的排队段，和“服务端开始生成到客户端拿到首段内容”的生成段，再配合一个只回一句话的最小基线，就能判断主要来源在并发等待还是输出长度。判断前需要先固定模型版本、入参和网络出口，否则日志对不齐。

适用场景：已接入 Ling-3.1-flash，感觉第一段内容出来慢。操作动作：在调用日志里记录发出、到达、首段返回、结束四个时间点，先跑只回一句话的基线，再固定输出长度做并发递增，最后对流式与非流式各跑一轮。验证方式：看首字耗时随并发上升的幅度，以及总耗时随输出长度增加的变化。风险边界：客户端未记录首段时间时，非流式返回只能近似判断，不能拆分排队和生成。

在调用日志里对齐请求发出与首段返回的时间戳

日志至少要能回答：请求是什么时候离开客户端、什么时候到达服务端或网关、首段内容什么时候返回、整次调用什么时候结束。如果只打印一个总耗时，排队和生成会混在一起。字段名以实际 SDK、网关或服务端日志为准，下面是一组通用占位：

client.send_ts：客户端构造完请求、准备发送的时间。
gateway.recv_ts：服务端或网关收到请求的时间。
gateway.first_token_ts：服务端生成并发出首段内容的时间。
client.first_chunk_ts：客户端读到首段内容的时间。
gateway.done_ts / client.done_ts：生成结束、连接关闭的时间。

计算时先对齐时区与时钟，客户端和服务端最好用同一时间源，否则差值不可信。排队等待可以用 gateway.recv_ts - client.send_ts 观察网络与入口等待，用 gateway.first_token_ts - gateway.recv_ts 观察服务端侧排队与首段生成；客户端侧首字总耗时用 client.first_chunk_ts - client.send_ts。若 gateway.first_token_ts - gateway.recv_ts 占主要部分，优先查并发与限流；若 client.first_chunk_ts - gateway.first_token_ts 偏大，优先查网络传输和客户端读取方式。每个字段都需要在日志中真实存在，缺失时先补打点，不要用估算值下结论。

写一个最小调用示例，只回一句话做基线

基线调用的目的是得到不受输出长度干扰的首字参考值。请求构造尽量简单：单轮 user 消息，要求只回一个短词，限制最大输出长度，关闭重试或只允许一次重试，超时设得足够宽。接口路径、鉴权头、字段名以官方文档为准，下面只是通用骨架：

import time, requests

url = 'https://<你的接口地址>/v1/chat/completions'
headers = {
    'Authorization': 'Bearer <API_KEY>',
    'Content-Type': 'application/json',
}
payload = {
    'model': 'Ling-3.1-flash',
    'messages': [{'role': 'user', 'content': '只回复：ok'}],
    'max_tokens': 8,
    'stream': False,
}
t0 = time.perf_counter()
resp = requests.post(url, headers=headers, json=payload, timeout=30)
t1 = time.perf_counter()

print('status:', resp.status_code)
print('total_ms:', round((t1 - t0) * 1000, 1))
print('body_head:', resp.text[:120])

把这段放在你能控制网络出口的机器上跑，连续记录多次，关注 total_ms 的分布而不是单次值。如果接口支持返回 usage 或时间字段，也一并打印。这个基线不回答“有没有排队”，但它给出一个参照：当输出长度被压到很短时，首字仍然很慢，说明排队、网络或客户端读取更值得怀疑；如果基线很快，而正常长输出很慢，则要把输出长度纳入变量。

固定输出长度再压并发数，观察延迟怎么变

并发对照要固定参数，否则结果不能比较。建议每次运行固定：同一个 prompt、同一个 max_tokens 或等价输出上限、同一个 temperature/top_p、同一个 stream 开关、同一个超时与重试次数、同一台客户端、同一个网络出口，并在较短时间内完成多轮。记录表可以按下面结构组织：

并发数 | 请求数 | 成功数 | 错误数 | 首字耗时 P50(ms) | 首字耗时 P95(ms) | 总耗时 P50(ms) | 备注
1      | 20     |        |        |                 |                 |                |
2      | 20     |        |        |                 |                 |                |
4      | 20     |        |        |                 |                 |                |
8      | 20     |        |        |                 |                 |                |

判断方向：并发数增加时，如果首字耗时明显上升、错误数增加，而单次总耗时相对稳定，排队或入口限流更可能是主因；如果并发数不变、只把输出长度拉长，首字耗时基本不变而总耗时跟着变长，那么“输出太长”解释的是整体慢，不是首字慢。还有一种常见情况：首字和总耗时同时上升，这通常意味着服务端已经在排队，同时你的客户端也在堆积读取任务。记录时不要只保留平均值，P95 和错误数更能暴露排队。

把流式与非流式两种返回方式各跑一轮对照

流式返回能观察到首个数据块到达时间，非流式返回通常只有完整响应时间，所以两者要分开记录，不能直接用同一个“首字”字段比较。流式侧观察点：请求发出时间、首个 SSE 或分块数据到达时间、最后一个数据块时间、状态码、收到的内容长度。非流式侧观察点：请求发出时间、响应完成时间、状态码、usage 或返回长度；如果服务端提供处理时间字段，也记下来。

对比时保持条件一致：同一个 prompt、同一个 max_tokens、同一个并发数、同一个客户端超时、同一个网络出口，最好在相近时间段跑。流式和非流式如果并发不同，比较结果没有意义。若流式首字明显慢而非流式完整响应也慢，需要回到第 1 节看服务端首段生成时间；若只有非流式慢，要检查客户端是否等到全部内容才处理、中间是否有缓冲或反代聚合；若只有流式慢，检查分块读取实现、SSE 解析和是否被中间层缓冲。

把结论落到调用层的超时与并发上限配置

调整顺序建议从超时开始，再到重试，最后动并发上限。超时：客户端连接超时和读取超时都要设，读取超时至少覆盖基线首字耗时并留出余量；如果业务允许长输出，还要覆盖总耗时。重试：只对连接错误、明确限流或 5xx 做有限次数重试，不要在超时后无限重试，否则并发会被重试放大。并发上限：从低并发开始，按第 3 节的表逐级增加，把首字 P95 开始明显上升或错误数开始增加之前的那个值，作为候选上限，再留一点余量。

验证方式：改完配置后重跑最小基线、固定输出长度的并发表、流式与非流式对照。看三个信号：首字 P95 是否比调整前稳定、错误数是否下降、总耗时是否没有因为超时过短而被截断。风险边界：并发上限压得太低会影响吞吐，读取超时设得太短会中断本来就正常的长输出，重试次数太多会让排队更严重。最终上限需要结合你的套餐限制、服务端返回的限流信号和实际流量峰谷确认，不要只靠一次对照就固定。