SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

管部署入口的和跑计算的推理

模型服务是模型的 HTTP 部署层——负载均衡、请求排队、缓存、超时和重试。推理是 GPU 上实际算 token 的数学计算。把服务层的超时归因为推理慢,或者反过来给 GPU 扩容解决排队问题,都是在用错钱。

寓言

茶馆的柜台师傅和后台炒茶的师傅,动刀不一样

镇上茶馆生意好,客人从早坐到晚。柜台老周管接单——谁先来、要什么茶、顺不顺路先端给赶时间的、回头客插不插队。后台老赵管炒茶——茶叶下锅、火候掐秒、翻炒圈数不差、出茶的时间精确到盏。

夏天客人翻了一倍,茶馆开始慢。老板先找老赵问能不能炒快点。老赵把火调到最大,翻炒加快,结果出茶量确实涨了,但三盏里有一盏焦了——锅的极限不在这里。老板又给老赵加了一口锅。出茶量涨了不到两成,但柜台老周那边还是堆着三十个茶牌没人接。

老周才是真正的瓶颈。他一个人既要收牌、又要排顺序、又要记回头客的偏好、还要把退茶换茶的客人的牌子重新插回队列。炒茶用了三十秒,老周在排队上多花了四十秒。加锅没有用——锅多出来的时候,老周连该端哪锅茶都不知道。

老板请了一个懂行的过来看。那人看了一眼就说你们把两件事揉在一起了:炒茶慢加锅,叫排队等太久加柜台人手。炒茶慢和排队等太久是两个独立的问题,分别查,分别动。

老周被配了一个跑堂。跑堂专门管排队、分单、接退换和记偏好。老周只管收钱和确认。那天出茶速度没变,但客人从坐下到喝到茶的时间少了四成。老赵的锅没加,火没调大,焦茶率降回零。

冬天又出事了。不是慢,是彻底崩——有批客人点了十几盏需要特殊工序的茶,老赵每盏要多花一倍时间。后面的数字全歪了。老周的柜台干干净净,却一个客人都接不了——后台堵死了,柜台空的等于堵死。

茶馆最后分了两套指标。后台管出茶速度——一盏茶从下锅到出茶要多久,能做多快要看锅和火。柜台管端茶速度——从客人开口到杯子放上桌要多久,能做多快要看排队和分单。每周看两张表,哪张数值涨了就动哪边的人。

后来掌柜把灶台后面又添了排班、保温、上菜和投诉记录。会炒一道菜只是开始,能让整间馆子稳定出菜,才算服务。

模型服务

模型的 HTTP 部署和请求管理层,负责负载均衡、请求排队、缓存、限流、认证和重试。关注的是并发连接数和请求调度。

推理

GPU 或其他加速硬件上执行的实际数学计算过程,把输入 token 通过模型权重转换成输出 token。关注的是延迟、吞吐和显存利用率。

故事对应

  • 柜台老周接单排队:模型服务层,管理请求调度和排队
  • 后台老赵炒茶:推理层,执行实际的计算工作
  • 加火加大出了焦茶:推理侧的单卡极限不能靠增加压力突破
  • 加锅没用老周不知道端哪锅:服务层瓶颈不能靠增加计算资源解决
  • 加跑堂分单排队:服务层扩容——增加并发处理能力而非算力
  • 特殊工序堵死后台:推理侧的延迟瓶颈会反向压垮服务层
  • 两张表两套指标:服务和推理需要独立的监控和扩容决策

落到 LLM API 性能问题定位

收到用户抱怨响应慢时,先分清楚是服务慢还是推理慢。看两个指标:请求排队时间(从到达网关到开始推理的间隔)和首 token 延迟(从开始推理到第一个 token 返回的时间)。排队时间长——扩容网关、优化限流策略或调整批处理逻辑。首 token 延迟长——检查模型大小、量化精度、KV 缓存命中率和 GPU 利用率。常见的钱被花错地方:推理延迟高却去扩充了 API 网关的 Pod 数量,或者排队堆积却去采购了更多 GPU。两个层的优化预算必须分开做预算,分别看 ROI。