SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

首 Token 时间和每秒 Token 数

一个量的是用户按下回车后多久看见第一个字,另一个量的是字一旦开始涌出来、一分钟能涌多少个。把这两个数混在一起优化,花出去的钱可能全投在了不该优化的地方。

寓言

快开门和快搬货

运河边有一家货栈,掌柜姓周,专门帮城里的商铺转运南北货物。货栈的流程分两步:提货人到了门口先递单子、核货号、开仓门,然后伙计进去把货从货架搬到马车上。周掌柜做了十来年,流程熟得像自己的手掌。

对岸新开了几家货栈,价钱差不多,但承诺配货更快。周掌柜的生意开始往下掉。他把伙计们召集起来,每人加了工钱,要求搬货速度翻倍。伙计们埋头练了两个月,一辆马车的货以前要搬三趟,现在两趟就搬完,一个个汗流浃背但脚下生风。

可商铺的抱怨一点没少。一个布商找到周掌柜:我派伙计去你货栈提货,到了门口等了小半个时辰才有人来开门,开完门还要登记、查单子、盖印章。周掌柜自己去货栈门口蹲了三天,亲眼看到提货的人排了一长串,而货栈里面伙计们搬完货正坐在箱子上闲聊——门没开,货出不去。

周掌柜把账本翻出来,发现他把所有力气都砸在了搬货速度上,但瓶颈根本不在搬货。提货单从递进去到仓门打开,平均要等一炷香。一炷香里有两个卡点:登记师傅上了年纪,每张单子都要凑到眼前慢慢看;登记台只有一张桌子,两批客人同时来就排长队,后面的人只能干站着。

周掌柜做了两件事:给登记台加了一张桌子,配了一个年轻伙计专门分拣单子、核对货号;又在门口装了一根拉绳连着铃铛,提货人一拉绳,里面就知道有人来了,提前备好出货单。从此提货人从递单子到看见货,从一炷香压到了不到一盏茶。

年底盘点,货栈生意回到了原来的水平。周掌柜在门口挂了一块木牌,写了八个字:「门快货才快,门慢货白搬。」他又在账本旁边贴了一张新规矩:以后每月的效率报表,第一行写开门时间——从递单子到仓门打开,第二行写搬货速度——从仓门到货上车。两个数字分开记、分开管。

有同行来取经,问他怎么提高配送。周掌柜说:配送分两段——开门时间和搬货时间。开门慢但搬货极快,客人只感受到开门那段等得心烦。你把两段混在一起看一个总数,就会拼命让伙计跑快点,但该开的那扇门还是慢悠悠的。

后来他在行业聚会上打了个比方:开门时间是茶客坐下等茶杯端上来的时间,搬货速度是茶叶泡开的速度。茶泡得再快,你十分钟没把杯子端上来,客人早就起身去别家了。两个数要分开量,一个管门、一个管货。

首 Token 时间 (TTFT)

从用户请求发出到模型返回第一个 token 之间的延迟。这个数值包含了请求排队、上下文预处理、提示词编码和 KV 缓存初始化。它决定了用户对系统响应速度的第一印象。

每秒 Token 数 (TPS)

模型在生成阶段每秒能产生的 token 数量。它衡量的是解码过程的纯计算吞吐,通常在第一个 token 之后才开始发挥作用。TPS 高意味着长回复生成得流畅,但不解决「等多久才开始」的问题。

故事对应

  • 伙计搬货速度翻了一倍但客人依旧抱怨:搬得快不等于整体快,瓶颈不在这里。
  • 开门时间整整一炷香:登记师傅慢、单张桌子、排队,问题全在门口而不是仓库里面。
  • 加桌子、配年轻伙计、装拉绳铃铛:优化开门时间不需要动搬运环节,两道工序各自治理。
  • 效率报表分两行——开门时间和搬货速度分开记录:两个数字的管理逻辑完全不同。
  • 茶泡得快和茶杯端上来的时间:一个日常场景里让人立刻理解分段延迟的比喻。

落到项目里

监控面板上 TTFT 和 TPS 分开打点、分开报警。TTFT 超标查预处理和缓存,TPS 超标查 GPU 算力规划和批处理策略。交互式产品优先保 TTFT,批量处理类产品优先保 TPS。两类场景的优化路径不一样,混在一起做的优化方案最后通常两头都不讨好。