我想比较两个推理后端，第一步却不是让请求并发跑起来，而是写清楚“第一”指什么。响应头先到、SSE角色字段先到、第一段非空文本先到，是三个不同的时刻。用固定 sleep 替代模型，只能测试客户端的等待逻辑。

llama.cpp server 文档提供流式接口及服务端计时相关字段。仓库 b11829 标签页面日期为 2026-10-22，标记为预发布；它不是模型新版本，也不能替代本地二进制的提交记录。

先固定客户端观察口径

这篇把 TTFT 定义为“提交客户端请求”到“读到第一段非空文本”的时间，因此包含排队、网络及预填充。另记准入时间，可以拆出本地排队。若要研究服务端纯预填充，应读取对应版本的服务端日志，不能拿这个客户端数值代替。

真实实现使用同一进程里的单调时钟。每个请求保存 submit、admit、first_text、done；错误与无输出必须单列，不能悄悄丢掉再算成功请求平均值。HTTP分块不等于SSE事件，一个事件又不必等于一个token，解析器要处理跨块、空增量和结束标志。

用可检查的事件验证公式

下面的整数是人为构造的同一时钟刻度，单位任意。程序检查事件顺序，并跳过空文本。它没有连接模型，也没有采集性能数据。

#[derive(Debug, PartialEq)] struct Metrics { queue: u64, ttft: u64, total: u64 } fn metrics(submit: u64, admit: u64, chunks: &[(u64, &str)], done: u64) -> Result<Metrics, &'static str> { if submit > admit || admit > done { return Err("invalid boundary"); } let mut previous = admit; let mut first = None; for &(t, text) in chunks { if t < previous || t > done { return Err("unordered event"); } previous = t; if first.is_none() && !text.is_empty() { first = Some(t); } } let first = first.ok_or("no text")?; Ok(Metrics { queue: admit-submit, ttft: first-submit, total: done-submit }) } fn main() { assert_eq!(metrics(10, 20, &[(21, ""), (35, "hi")], 70), Ok(Metrics { queue: 10, ttft: 25, total: 60 })); assert!(metrics(10,20,&[(21,"")],30).is_err()); assert!(metrics(10,20,&[(25,"a"),(24,"b")],30).is_err()); assert!(metrics(20,10,&[],30).is_err()); println!("timing boundary checks: 4 passed (synthetic events)"); }

保存为 main.rs，运行rustc --edition=2024 main.rs -o demo && ./demo。本地 rustc 1.98.0、aarch64 上四项断言通过，输出明确标为 synthetic events。这里的25、60只是算术断言，不能写成25毫秒TTFT或60毫秒推理。

真压测还缺什么

下一步接真实服务时，我会先固定模型文件哈希、量化类型、上下文长度、server提交、启动参数与提示词集合。客户端日志保存每次请求的状态和原始时间戳；预热请求与正式样本分开；相同输入长度和输出上限才有比较意义。

吞吐量也要分口径：服务端报告的生成token数，和客户端收集到的字符串长度不是同一单位。统计p50/p95前先说明失败率、样本数、并发以及是否包含排队。跨机器时钟不能直接相减。

这轮验证只证明计时归约函数按选定定义工作，未完成HTTP解析器、SSE异常恢复或真实模型测量。实际采用的二进制与接口字段应在发布前再查一次。