LingBot-VA 2.0 端到端延迟忽高忽低——是推理侧还是通信侧在拖？

LingBot-VA 2.0 端到端延迟忽高忽低，只盯总耗时是分不清推理侧还是通信侧的。可行的路径是先把一次完整调用拆成采集、传输、推理、下发四段，各自打时间戳；跑多轮看分布而非平均；再固定其他变量、单独放大一段负载，用“哪段先变慢”来定位。这样做的成本主要是一次埋点和几轮复现，比直接换模型或换网络更容易收敛。

先分段计时，再讨论优化：采集、传输、推理、下发四段各自打点，时钟对齐到同一基准，单位统一为毫秒。跑多轮记录最大值与分位数，判断抖动看分布而不是看平均。然后固定其余条件，只给推理或传输加压，观察哪一段先抬高。哪段先变慢就先处理哪段；若四段都平稳而端到端仍在抖，通常要回到客户端调度、内存回收或观测自身开销，需要结合运行环境确认。

把一次完整调用拆成几个可计时时段

分段边界必须先定义清楚，否则后面的数据没法横向比较。建议按“数据形态发生变化”的位置切分，而不是按代码模块切分。

采集：从触发信号（按键、唤醒词、VAD 判定起点、上一帧动作完成回调）开始，到最后一帧数据写入本地缓冲为止。
传输：从最后一帧交给发送接口开始，到对端完整收到该请求为止。上行与下行建议分开记，下行容易被顺手算进推理。
推理：从服务端拿到完整输入开始，到输出可用结果（首 token、完整动作序列、结构化指令）为止。预处理算不算进来要一次定死。
下发：从结果离开服务端开始，到执行端确认接收并开始执行该动作的时刻。

边界模糊时按两条规则取舍：一是边界能否在同一台机器上拿到时间戳，跨机边界必须两侧都记；二是发送接口返回通常只代表写入了本地发送缓冲，不代表对端收到，所以上行结束点以服务端接收时间戳为准，客户端时间只作参考。预处理和模型同机竞争 CPU/GPU，建议并入推理段；如果指令要经过中间网关，网关转发耗时并入下发段，不要留成黑盒。

在各时段插入计时并统一时间基准

区间耗时用单调时钟，例如 Python 的 time.monotonic_ns() 或 perf_counter_ns()，避免系统时间被校正时把耗时算成负数。墙钟时间只用来跨机对齐：如果依赖 NTP，相邻两次校时的偏差可能与被观测的抖动同量级，此时改用同机收发打点，或用一次往返估算两端偏移量。单位统一为毫秒、保留一位小数，字段名固定，便于后续直接排序和取分位数。

import time, json

def ms(a, b):
    return round((b - a) / 1e6, 1)

def run_once(payload):
    t0 = time.monotonic_ns()
    frame = capture()                  # 采集
    t1 = time.monotonic_ns()

    resp = transport_send(payload)     # 传输；响应里需带服务端时间戳
    t2 = time.monotonic_ns()

    dispatch(resp)                     # 下发
    t3 = time.monotonic_ns()

    print(json.dumps({
        "capture_ms": ms(t0, t1),
        "roundtrip_ms": ms(t1, t2),    # 需再用服务端字段拆成上行/推理/下行
        "dispatch_ms": ms(t2, t3),
        "total_ms": ms(t0, t3),
    }, ensure_ascii=False))

transport_send 是占位名，替换成实际的发送封装即可。关键是响应体里要带回服务端的接收时刻与推理完成时刻，否则 roundtrip 是一整块，仍然分不清通信和推理。如果服务端暂时无法改代码，可以先在客户端记录“请求发出”和“首字节到达”两个点，把首字节之前的等待整体当作待拆分的黑盒。

跑多轮并记录分布而不是只看平均

抖动问题只有分布才看得出来。先跑一段空闲基线，轮次不用一上来就很多，跑几十轮看有没有明显离群，再决定是否加量。每轮都要落盘原始记录，而不是只留一个汇总值。

记录每个字段的最大值、中位数、p90、p99；分位数按排序后取索引即可，不必引入额外库。
抖动阈值不要照搬某个固定毫秒数。可以先用空闲基线的中位数当参照，把明显偏离基线的轮次单独标出来，再结合业务能接受的延迟上限确认。
同时记录轮次序号和发生时间，方便判断抖动是随机出现还是周期性出现——周期性的往往指向内存回收、定时任务或链路重协商。

如果平均值持平、最大值抬高，说明多数请求正常但少数被拖住，通常出在排队或资源争抢；如果中位数本身就抬高了，说明是整体变慢。两种形态对应不同的下一步动作。

固定其他变量，只放大其中一段负载

对照实验的目的单一：确认哪一段先变慢。每次只改一个变量，其余保持与基线一致。

只加压推理：在同一台机器上并发发起多个推理请求，或提高输入分辨率、序列长度。观察推理段耗时的抬升幅度，以及它是否把采集和下发一起拖慢。
只加压传输：占用上行带宽（例如用 iperf3 制造反向流量），或用 tc netem 增加往返时延与丢包，或临时把上行帧调大。tc 和 iperf3 需要相应权限，改动前记下原值以便还原。

加压期间除了各段耗时，还要同时记录：CPU/GPU 利用率与排队情况、内存占用、网络重传与丢包计数、进程或线程数、是否发生降频。这些字段用来区分“资源饱和”和“单纯排队”：利用率打满通常指向容量，利用率不高但耗时抬高通常指向锁、队列或调度。

根据分段结果决定优化顺序

把分段结果分成三种典型形态，各自对应不同的下一步动作。

推理段随并发明显抬高：先限制并发并加排队与超时保护，把抖动控制在不会阻塞下发的范围内；再考虑批处理参数、输入尺寸和硬件占用上的调整，模型层面的改动放到后面。
传输段先变慢：查上行带宽占用、帧大小、重传与链路类型。通常先降低帧率或做压缩，再评估链路升级；注意不要把缓存或重发这类止血手段当成提速方案，它们只是掩盖抖动。
下发段先变慢：查执行端任务队列、串口或总线占用、控制周期是否被前一动作阻塞。优先做指令合并、丢弃过期动作和超时处理。

如果四段各自都平稳、端到端却在抖，要回头查客户端调度、内存回收、日志写入和观测自身的开销，这类抖动通常不在模型和网络里。复验时用同样的轮次设置和同样的加压条件重跑，比较分段分布的形状而不是平均值；分布形状没变，说明这次改动没有打到根因。