X2.0 做实时交互视频生成，先摸清输入反馈和延迟这三段

要判断 X2.0 做实时交互视频生成到底慢在哪，光看画面顺不顺没有用。可行的做法是把一次交互切成输入、生成、反馈三段，为每段设定明确的起点和终点事件，用毫秒级时间戳写进日志，再按段统计最大值与分布。分段口径一旦固定，加缓冲、降级、调参才有依据；口径不固定，任何“感觉卡”的判断都只能靠猜。

适用场景：用 X2.0 做实时交互视频生成，需要判断延迟落在采集上传、模型生成，还是编解码与渲染。操作动作：固定三段的起止事件和字段名，逐段打时间戳并写 JSONL 日志。验证方式：先确认每条记录三段字段齐全、每段耗时非负，再按段看最大值和分位值。风险边界：同一段耗时必须用同一时钟源计算；跨端上报的时间只作参考，不要混进服务端段内耗时。

把一次交互拆成输入、生成、反馈三段并各自打点

下面的分段定义表是本页所有判断的共同前提。字段名建议统一成 xxx_ts 形式的毫秒时间戳，同一进程内用单调时钟算差值，墙钟只用来排序和对齐日志。

段落	起点事件	终点事件	时间戳字段	这段能回答什么
输入段	用户触发（按下开始、语音结束、文本提交）	服务端收全请求并通过参数校验	`client_capture_start_ts`、`server_request_accepted_ts`	采集、编码、上传、鉴权哪一步在拖时间
生成段	服务端确认请求可执行，进入生成队列	首个可解码帧或首个分片就绪，可另记整段完成时间	`server_input_ack_ts`、`first_frame_ready_ts`、`clip_ready_ts`	模型推理本身慢，还是在排队
反馈段	首帧或分片就绪，开始下发	首帧上屏，以及本轮交互回执返回	`first_frame_ready_ts`、`client_render_ts`、`feedback_ack_ts`	传输、解码、渲染、回执链路是否又加了一段等待

表里没有单列排队等待。如果 X2.0 的接入层会先把请求放进队列，建议再补 queue_enter_ts 和 queue_leave_ts 两个点，否则排队时间会被算进生成段，让推理看起来莫名变慢。client_capture_start_ts 由客户端上报，和 server_request_accepted_ts 不在同一时钟上，两者差值只能作为输入段整体感觉的参考，不能当作精确耗时。

用一段最小计时代码记录每段耗时

下面的骨架放在服务端请求入口、首帧回调、整段完成回调三处执行，接口地址和日志路径需要替换成实际值。它的作用只有一个：让每次交互的耗时能被复现和比较，而不是靠当次观感。

# timing_probe.py —— 服务端入口 + 回调处调用，输出 JSONL
import json, time, uuid

GATEWAY = "https://your-gateway.example/api/video/interact"  # 占位，替换成实际入口
LOG_PATH = "./logs/interact_timing.jsonl"                      # 占位，替换成可写路径

def now_ms():
    return int(time.time() * 1000)

def emit(rec):
    rec["logged_at"] = now_ms()
    with open(LOG_PATH, "a", encoding="utf-8") as f:
        f.write(json.dumps(rec, ensure_ascii=False) + "\n")

def start_interaction(user_id, prompt, duration_s, client_start_ts=None):
    rid = uuid.uuid4().hex[:12]
    rec = {
        "rid": rid,
        "user_id": user_id,
        "prompt_len": len(prompt),          # 只记长度，避免日志里落原文
        "duration_s": duration_s,
        "client_capture_start_ts": client_start_ts,   # 可能为空
        "server_request_accepted_ts": now_ms(),
        "queue_enter_ts": None,
        "queue_leave_ts": None,
        "server_input_ack_ts": None,
        "first_frame_ready_ts": None,
        "clip_ready_ts": None,
        "client_render_ts": None,
        "feedback_ack_ts": None,
        "degraded": False,
        "degrade_reason": None,
    }
    emit(rec)
    return rid

def mark(rid, field, **extra):
    # 每次只补一个点，写完立刻落盘，进程被掐也不至于全丢
    rec = {"rid": rid, field: now_ms()}
    rec.update(extra)
    emit(rec)

# 调用顺序示例
# rid = start_interaction("u_1", "……", 4)
# mark(rid, "server_input_ack_ts")
# mark(rid, "first_frame_ready_ts")
# mark(rid, "client_render_ts")

上面代码采用“一行一条、按 rid 合并”的写法，好处是任意一个回调延迟或丢失都能从日志里看出来。合并时按 rid 取各字段最后一次非空值，再算 gen_ms = first_frame_ready_ts - server_input_ack_ts、feedback_ms = client_render_ts - first_frame_ready_ts。

日志条目是否齐全，用下面这段检查就能确认。它只统计缺字段的记录数，不涉及任何性能结论：

python - <<'PY'
import json
need = ["server_request_accepted_ts", "server_input_ack_ts",
        "first_frame_ready_ts", "client_render_ts"]
docs = {}
for line in open("logs/interact_timing.jsonl", encoding="utf-8"):
    r = json.loads(line)
    d = docs.setdefault(r["rid"], {})
    for k, v in r.items():
        if v is not None:
            d[k] = v
missing = [k for k, d in docs.items()
           if any(d.get(f) is None for f in need)]
print("total", len(docs), "missing", len(missing))
PY

如果 missing 数量明显，先别急着分析耗时，先修打点：常见原因是首帧回调和整段完成回调写到了不同目录，或者客户端 client_render_ts 上报接口失败。打点缺失时的耗时分布是不可信的。

在日志里判断耗时到底集中在哪一段

把合并后的记录按段求最大值和分位值，比看平均值有效，因为实时交互的体感由最慢的那几次决定。取最近一段时间的日志，按 rid 合并后排序即可：

python - <<'PY'
import json, statistics

def pct(xs, p):
    xs = sorted(xs)
    i = min(len(xs) - 1, int(len(xs) * p))
    return xs[i]

docs = {}
for line in open("logs/interact_timing.jsonl", encoding="utf-8"):
    r = json.loads(line)
    d = docs.setdefault(r["rid"], {})
    for k, v in r.items():
        if v is not None:
            d[k] = v

for name, a, b in [("gen", "server_input_ack_ts", "first_frame_ready_ts"),
                   ("feedback", "first_frame_ready_ts", "client_render_ts")]:
    xs = [d[b] - d[a] for d in docs.values()
          if d.get(a) and d.get(b)]
    if xs:
        print(name, "n=", len(xs), "max=", max(xs),
              "p50=", pct(xs, .5), "p95=", pct(xs, .95))
PY

判读时可以按下面的顺序看，避免把责任推错段：

输入段明显偏大：检查客户端采集与上传、请求体大小、鉴权往返。server_request_accepted_ts 与客户端上报时间差距大，只能说明链路上有等待，具体在哪一跳需要服务端访问日志佐证。
生成段偏大且与 prompt_len、duration_s 同向变化：大概率落在推理或分片生成环节；若 queue_leave_ts - queue_enter_ts 本身就很长，先看排队再看模型。
生成段偏大但与入参无关、忽快忽慢：优先怀疑资源争用或并发调度，而不是参数配置。
反馈段偏大而生成段正常：问题在编码、传输、解码或前端渲染；client_render_ts 缺失或长期为空，说明问题在客户端上报而不是链路本身。
最大值集中在个别 rid：先看这些记录的 degraded 字段和重试次数，重试成功的那次通常会把整段耗时拉长。

为最长的那一段准备降级方案

降级的目标是让交互在慢的时候仍然走得通，不是让指标变好看。先确认哪一段最长，再只对那一段动手；三段同时降级容易把体验和排查线索一起糊掉。

降级选项	适用段	落地方式	可观察的验证指标
缩短单次时长	生成段	按 `duration_s` 或分片数收敛，先出短片段再续	`first_frame_ready_ts - server_input_ack_ts` 是否回落；`clip_ready_ts` 是否出现缺省
降低交互频率	输入段、生成段	节流提交，新请求到达时取消上一次未完成的 `rid`	日志中取消标记条数、并发中的 `rid` 数量、`queue_enter_ts` 数量是否下降
排队重试	生成段	超时后转异步，先返回占位或上一帧延续，完成后再补推	`degraded=true` 占比、重试次数分布、补推到达的 `clip_ready_ts` 是否仍在可接受区间

三项都需要一个共同的兜底观察：降级开启后，反馈段的 feedback_ack_ts 是否还在正常返回。如果降级换来的是回执缺失或客户端报错，说明降级点选错了段，应该退回去重新看统计。参数阈值和触发条件要结合自己的环境确认，不要照搬别处的数值；能说清“哪一段、降什么、看哪个字段”就已经够用。