从零实现 LLM Inference:048. Streaming Submit Schedule(absolute vs relative)
submit_interval_ms 如果用“sleep after each add_request”的相对口径,提交路径一变快,实际到达率就变了,TTFT 会被排队形态污染。给 benchmark_streaming 加 submit_scheudle=absolute,用 t0+i*interval 固定到...
submit_interval_ms 如果用“sleep after each add_request”的相对口径,提交路径一变快,实际到达率就变了,TTFT 会被排队形态污染。给 benchmark_streaming 加 submit_scheudle=absolute,用 t0+i*interval 固定到...
add_request 里同步做 tokenizer.encode 会放大 submit wall / p99。引入 tokenize_workers 线程池,把 tokenization 变成后台阶段,并把 TTFT 拆到 tokenize/queue/prefill 三段。
streaming bench 里 add_request 的 p99 很容易被 tokenizer.encode 的 CPU 开销污染。增加 add_request(prompt_token_ids=…) + benchmark_streaming –pretok,把 tokenization 从提交路径挪出去。
TTFT 只是一个总数:里面既有排队等待,也有 prefill 的真实计算。只看 TTFT 很容易把优化方向搞反。给 SchedulerManager 记录 admit timestamp,并在 benchmark_streaming 里打印 TTFT breakdown。
paged-attn / CUDA Graph 的第一次请求会把 Triton JIT 和 graph capture 算进 TTFT/吞吐,导致对比结论失真。给 benchmark_streaming 加 warmup-runs + repeat-runs,把冷启动和稳态拆开。