🎯 AI Infra岗位学习材料

一句话：进程 = 资源分配的最小单位（独立地址空间/页表/文件描述符/信号/权限），线程 = CPU 调度的最小单位（同一进程内共享地址空间与大部分资源，只有寄存器/栈/TCB 独立）。线程切换比进程切换开销小，省的不是"进内核"而是"换地址空间"：

• 进程切换要换 mm_struct → 页表切换 → TLB 大概率失效（flush），后续访存全走慢路径；线程同进程切换页表不变 → TLB 命中率高；
• 线程共享文件表/信号/堆，切换不必重建这些"资源语义"；切换内容也少（只换寄存器 + 栈 + 调度器上下文）；
• 两者都要经历"用户态↔内核态 + 保存/恢复寄存器 + 调度器选下一个"。

题眼：先给"资源边界 vs 调度实体"的定位，再点破"线程省的是地址空间/TLB那一大笔（PCID/ASID 只是缓解），不是省了内核切换本身"。

参考来源：Linux Kernel / man pthreads、CSAPP 并发章节。

一句话：三次握手（建连）：SYN → SYN+ACK → ACK——目的：① 双方确认收发能力正常；② 协商初始序列号 ISN（防历史报文串扰）。四次挥手（断连）：FIN → ACK → FIN → ACK——因为 TCP 是全双工，每一方向都要独立关闭：A 发 FIN 表示"A 不再发"；B ACK；B 发 FIN 表示"B 也不再发"；A 最后 ACK。

• TIME_WAIT 在谁身上：主动关闭方（先发 FIN 的 A）。A 发出最后 ACK 后要等 2×MSL（默认 60s 左右）才彻底释放；
• 为什么需要 TIME_WAIT：① 保证最后一个 ACK 送达——若它丢了，B 会重发 FIN，A 若已关闭就无法再回 ACK，导致 B 一直收不到确认、连接无法干净关闭；② 让旧连接的残留报文在网络上自然消失（超过 MSL 后包必然被丢弃），防止"同四元组的新连接"收到上一连接的迟到数据；
• 高频追问：高并发短连接（如大量 HTTP 1.0/短连接）会积压很多 TIME_WAIT，占满端口/内存 → 对策是连接复用（长连接/连接池）减少主动关闭，或调 tcp_tw_reuse（Linux 4.12+ 安全默认）。

题眼：挥手画图把"每方向一对 FIN/ACK"讲清；TIME_WAIT 属于主动关闭方，两大理由=保最后一 ACK + 防迟到旧包；对策落到连接池。

参考来源：RFC 793（TCP）、RFC 1122 §TIME_WAIT。

一句话：镜像（Image）= 静态的只读模板——一组分层的文件系统快照 + 元数据（CMD/ENV/暴露端口等），构建时生成、可打包分发；容器（Container）= 镜像的一个运行实例——在镜像层之上加可写层，由 namespace 隔离视图 + cgroup 限制资源 + 独立进程树 构成的进程运行时。

• 容器的本质：它不是轻量虚拟机，而是一组受限的普通进程。用 namespace 让进程"看起来"有独立的文件系统/PID/网络/用户（隔离视图），用 cgroup 限制 CPU/内存等（隔离资源），rootfs + 可写层给独立的文件环境。多个容器共享宿主内核，所以"隔离"是逻辑/资源的，不是硬件级。
• 镜像为什么能复用：分层（见 OverlayFS，Q26）——同一基础镜像被拉取一次即可被大量容器共享；docker commit/Dockerfile 每行指令产生一层，可缓存复用。

题眼：镜像=静态模板/只读层，容器=可运行实例=镜像层+可写层；本质一句话"容器是加上了 namespace+cgroup 的进程"，跟 VM（独立内核）对比是被问得最多的。

参考来源：Docker 官方：容器 vs 镜像、Docker 存储驱动。

一句话：Pod 生命周期是"申请→调度→运行→终态"四段：

• Pending：Pod 已创建并被 API Server 接受，但还没跑起来——可能原因：还没被调度（scheduler 未选出节点）、镜像拉取中、资源不够（节点容量不足在等）、准入/存储卷 PVC 未绑定。此时查 kubectl describe pod 看 Events 找根因；
• Running：Pod 已绑定到某节点、至少一个容器已启动并存活（所有容器都 Running 才进 Running，容器若反复崩溃重启也仍处于 Running 期但要查 RestartCount）。容器满足 liveness 探测通过 / 未配置则默认存活；
• Succeeded：所有容器正常退出（exit 0）——多用于 Job/一次性任务；Failed：至少一个容器非 0 退出或被系统终止（如 OOM）——Job 场景看是否允许重试/重排队。
• 中间还有 ContainerCreating / CrashLoopBackOff / ImagePullBackOff / Terminating 这类细分阶段；kubectl get pod -w 观察、describe + logs 定位是标准排查路径。

题眼：Pending 的根因归类（未调度/拉镜像/资源不足/卷未就绪）+ Running 的判定（容器全 Running + 存活探测）+ 终态 Succeeded(exit 0)/Failed(非 0)，并落到 describe pod 看 Events。

参考来源：K8s Pod 生命周期文档。

一句话：CI（持续集成）= 代码一提交就自动构建+自动测试，尽早发现集成问题（提交 → 静态检查/单测 → 构建镜像 → 集成测试）；CD（持续交付/部署）= 把通过 CI 的产物自动/一键部署到环境并验证（持续交付=部署到预发并随时可手动上生产；持续部署=连生产也全自动）。

• 一条从提交到上线的流水线（示例）：① 触发：Push/PR → ② 静态检查（lint、代码规范、安全扫描 SAST/依赖漏洞）→ ③ 单元测试 → ④ 构建：编译 + 打镜像（多阶段、带版本 tag/Git SHA）→ 推送到镜像仓库（含漏洞扫描）→ ⑤ 部署到测试/预发（CD 开始）：Helm/K8s 滚动发布 → ⑥ 测试：集成/E2E/契约测试 → ⑦ 发布到生产（门禁：人工审批或自动）→ 金丝雀/灰度：先小流量验证 → 全量 → ⑧ 验证与回滚：健康检查/Smoke Test，监控指标对比，异常自动/手动回滚到上一版本。
• 设计要点：门禁（quality gate）分层（每阶段失败即停）；产物不可变（同一镜像在测试/生产间流转，不重建）；快速反馈（单测先于重测试）；发布策略可配（滚动/蓝绿/金丝雀）；环境一致性（配管/依赖版本锁定）。

题眼：CI 定义=构建+测试反馈环；CD 定义=部署，且分清 delivery（可交付待发）与 deployment（自动上线）之差别；流水线要能按"提交→质量门禁→构建产物→部署→灰度→回滚"讲出主干与门禁思想。

参考来源：GitHub Actions 文档（流水线概念）、Continuous Delivery 概念。

一句话：Prometheus 四类指标按"单调不单调 × 是否需要分布统计"区分：

• Counter（计数器）：只增不减（重启归零），代表累计事件量——例：请求总数 http_requests_total、错误数、bytes 总量。用 rate()/increase() 算速率才有意义，直接看绝对值会受累计影响；
• Gauge（仪表）：可增可减的瞬时值——例：当前 CPU 使用率、内存占用、在线连接数、队列长度、温度。直接看当前值，不用 rate；
• Histogram（直方图）：把观测值按预置桶（bucket）计数累加（_bucket{le="..."}）+ 总和 + 计数——可算分位数（如 histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))）、可跨实例聚合。例：请求延迟、响应大小。因为桶的分布可汇总，适合聚合出 P99；代价是要预先定桶边界、精度有限；
• Summary（摘要）：客户端本地直接算分位数上报（{quantile="0.99"}），查询简单精确，但分位数无法跨实例聚合（每实例各自算，sum 无意义），适合"单进程看延迟"或对聚合不强求的场景；还带 _sum/_count。
• 选型速记："累计事件→Counter、瞬时状态→Gauge、要全局限/P99→Histogram、单机精确分位→Summary"；常规延迟监控首选 Histogram（能跨机器算 P99）。

题眼：一句话区分 = Counter 单调递增算 rate、Gauge 瞬时可正负、Histogram 服务端桶计数可聚合算分位、Summary 客户端算好分位不可跨实例聚合；能把"P99 用 Histogram 不用 Summary（要聚合）"点出即拿分。

参考来源：Prometheus 指标类型文档。

一句话：目标不是"绝对一致"，而是最终一致 + 不读到脏数据/缓存穿透，标准姿势是 Cache Aside（旁路缓存），且顺序有讲究——先更新 DB，再删缓存（失效），而不是先写缓存、也不是先删后更。

• Cache Aside 读：先查缓存 → 未命中则查 DB → 回填缓存。写：先更新 DB → 成功后删缓存（让下次读再回填新值）。
• 为什么先更 DB 后删缓存：① 更新缓存（先更 DB 再写缓存）在"并发写 + 缓存回填竞态"下容易把旧 DB 值覆盖新缓存——缓存是"读时的副本"，写路径直接维护它天然易错；② 先删缓存再更 DB：删完到更完之间，并发读会穿透把旧值回填进缓存，缓存里留下脏值，比"多一次缓存未命中"严重。先更 DB 再删缓存的最坏情况是"删缓存失败/中间有读到旧值回填"——窗口小，且可配 延迟双删 / 重试删除（消息队列兜底） 收敛。
• 完整高一致性姿势：① 写：更 DB → 删缓存（失败就重试/走 MQ 异步删）② 读：未命中回填时带过期/互斥防并发回填旧值（可用 SETNX 锁或对回填加短 TTL）③ 给缓存统一 TTL 兜底最终一致 ④ 关键数据可配订阅 binlog（Canal）失效缓存——把"删缓存"从应用代码里解耦出来，DB 变更必然触发删除，是最稳做法。
• 别用场景：先写缓存后异步更 DB 只适合对一致性极宽容（可丢可延迟）的计数/展示；否则脏窗口不可控。

题眼：先更 DB 再删缓存、删缓存而非更新缓存，理由=防并发回填旧值（先删后更的穿透回填脏）；加分红=延迟双删/MQ 兜底删除/binlog 订阅失效（Canal）收敛一致窗口。

参考来源：Consistent caching（Cache Aside 等）、Canal（MySQL binlog 订阅）。

一句话：四兄弟分工——限流=拦住"放不下的量"、熔断=拦住"已知坏的下游"、降级=砍掉"非核心功能"保核心、重试=对"瞬时抖动"再给一次机会，配套的是超时与退避：

• 限流（保护自己/上游入口）：控制单位时间请求量。令牌桶：匀速往里放令牌、桶有容量（允许突发，尖峰可短时冲高），适合入口流量整形；漏桶：恒定速率流出（强制匀速，超出的排队/丢弃），适合"下游只能吃固定速率"（写 DB/下游 API）——令牌桶管"能不能进"（允许突发）、漏桶管"出去的速率恒定"；滑动窗口：把窗口切成小格统计，避免固定窗口"边界处瞬间双倍放行"的毛刺，更平滑地按时间窗口限总 QPS。另有计数/并发数限流、分布式限流（Redis+Lua 原子）与单机（Guava/本地令牌桶，快但每实例独立）之分；
• 熔断（保护下游与自己不被拖死）：下游连续失败/超时达阈值 → 打开熔断器，后续请求快速失败（不再打坏下游，给自己喘息/给下游恢复时间）；半开状态试探放少量流量，成功则关闭恢复。典型实现 Hystrix/Resilience4j。核心是防止"雪崩/级联失败"——一个慢下游把整条链路线程池占满；
• 降级（保核心）：系统过载/下游不可用时主动放弃非核心功能：返回默认值/降级文案、关掉推荐/评论等次要接口，把资源让给核心链路（下单/支付）。分静态降级（预案配置）与动态降级（运行时开关/配置中心）；
• 重试/退避（容忍瞬时故障）：对幂等的请求在"连接超时/5xx/网络抖动"下有限次重试（指数退避 + 抖动 jitter，防重试风暴打崩系统）；不幂等/已到业务语义边界（如已扣款）不可盲重试；要配合超时（每个环节设超时，避免无限挂起占资源）。
• 组合用法：超时 → 重试（限次数退避）→ 熔断（重试也失败就熔断下游）→ 限流（入口）→ 降级（过载兜底）——从"单次调用"到"整系统过载"层层设防。

题眼：各自一句话场景+两两辨析（令牌桶允突发 vs 漏桶恒速率；熔断防雪崩=快速失败；降级=砍非核心；重试=瞬时容错且须幂等+退避）；能讲"超时→重试→熔断→限流→降级"的防线顺序即高分。

参考来源：Resilience4j 文档（限流/熔断/退避）、Google SRE：超时与重试。

一句话：AI Infra 是"让模型从数据走到能稳定、低成本、大规模服务用户的全套支撑系统"——它回答的不是"怎么训练出一个模型"，而是"怎么把训练和推理做快、做省、做稳、做得起规模"。

记忆锚点：AI Infra=让模型从实验室走向大卖场的全套后勤：每层都在拿「贵算力」换「好延迟/吞吐/成本」；和传统后端最大不同=负载是自回归+显存随时间膨胀的怪物。

分层（自底向上，每层一句核心矛盾）

和传统后端 Infra 的本质区别

1. 算力与硬件层：GPU/NPU 集群、NVLink/IB/RoCE、高速存储——矛盾："算力贵、显存少、带宽是墙"（Q117/130/132）；
2. 资源与调度层：K8s 编排 GPU、配额/抢占/共享池、任务队列——矛盾："多人抢稀有 GPU"；
3. 训练系统层：DP/TP/PP/EP/SP/ZeRO/FSDP、混合精度、checkpoint 与故障恢复、数据管道——矛盾："单卡装不下、单卡训不动、训到一半会崩"（Q92/93/100/101/102/123/148）；
4. 推理服务层：vLLM/SGLang/TensorRT-LLM 引擎、KV 管理、连续批处理、前缀缓存、量化、PD 分离、投机解码——矛盾："KV 随生成长、显存小；decode 慢、带宽窄；延迟与吞吐打架"（Q84–104、114–150 是主力）；
5. 模型开发与评测层：微调/LoRA、实验管理、评测与防遗忘（Q137–140）；
6. 平台工程与可靠性层：模型网关、可观测性（延迟/吞吐/成本）、弹性扩缩、CI/CD、模型生命周期（MLOps）——覆盖题库 IaC/云原生区。

传统后端的负载是"短事务、请求独立、状态在外存/DB"；AI 的负载是逐 token 自回归、上下文（KV）随时间在显存里膨胀、算力/带宽需求按 prefill 与 decode 两个阶段完全不同的怪物。因此 AI Infra 的工程围绕四类新变量转：KV 显存怎么管（分页/共享/量化）、批处理粒度到哪一层（迭代级）、通信拓扑怎么定（TP/EP/CP 机内机外）、SLO 怎么拆（TTFT vs TPOT，PD 分离）。能把这套"新变量"讲清，而不是把传统 K8s/后端经验原样搬来，才是 AI Infra 面试的答案。

题眼：给"6 层 + 每层一句矛盾"，最后一句落在"和传统后端的差异 = 负载的特殊性（自回归 + KV 膨胀 + 两阶段资源形态）"，就能把整张知识网络挂到框架上，也方便面试官顺着任一层深挖。

参考来源：各层技术细项见题库对应编号（Q117 算力 / Q123 分布式训练 / Q126 调度 / Q120 PD / Q130 通信 / Q125 前缀缓存）；业界综述可参考 LMSYS 博客 与 SGLang 文档。

一句话：vLLM 对外是 OpenAI 兼容服务、对内是一条『入口 → 输入处理 → 迭代级调度 → 块式 KV 分配 → 模型前向 → 采样 → 流式吐字与释放』的流水线；『迭代级调度』= 不是把一批请求整体跑完，而是每向前一步（iteration）都重新调度，让新请求随时准入、完成的随时退出——吞吐与单请求延迟解耦。

一次在线请求走完的七段

1. 入口（API server + Engine）：vllm serve 起的 OpenAI 兼容 HTTP 服务（/v1/completions、/v1/chat/completions，SSE 流式、/v1/models）。在线并发用 AsyncLLMEngine，离线一次性批量用 LLM().generate()——两者底层是同一个调度/执行核心。
2. 输入处理：把请求原文经 tokenizer + chat template（有 system/多轮先拼成完整 prompt）变成 token id；超 max_model_len 的截断或拒绝；登记该请求的 SamplingParams（temperature/top_k/top_p/max_tokens/stop 词/guided schema…）。随后注册为一条 sequence 进入调度器。
3. Scheduler（每步一次，框架的『大脑』）：维护 waiting（没开始）/running（在跑，每 decode 一步各推进一个 token）/swapped（被抢占换出）三队列。每步决策：KV 池与 token 预算允许就把 waiting 的请求准入做 prefill（长 prefill 会被 chunked prefill 切成小片填进 decode 空隙以保吞吐）；KV 不够就抢占（默认 recompute 比 swap 便宜，Q126）。最终产出『这一步要执行的一批 sequence + 每个 sequence 本次算到哪一段 token』。
4. KV 分配（Block Manager / PagedAttention）：给 prefill 按 block（默认 16 token）分配物理 KV 块，请求持有 block_table；相同前缀靠块哈希 + 引用计数共享（前缀缓存，Q125/127）；decode 每步只需为当前新 token 追加一个 slot——『KV 显存是分页的』。
5. 模型前向（Worker / ModelRunner）：把这一批喂进模型：逐层 RMSNorm→QKV 投影→RoPE→attention（走后端：PagedAttention/FlashAttention/FlashInfer 等，decode 按 block_table 读每层历史 KV，是带宽墙，Q84/88）→SwiGLU FFN→残差（Q146）。decode 的固定小批用 CUDA Graph 重放省 launch（enforce_eager 会关掉它）；V1 下 scheduler（engine-core 进程）与 GPU 前向（每卡一个 worker 进程）分离。
6. Sampler（采样）：只对每个 sequence 最后一个位置的 logits 采样：应用 temperature/top_k/top_p/frequency·presence penalty；结构化/guided 输出用合法 token 掩码约束（Q150）；投机解码先并行验证草稿再决定接受/拒绝（Q124）。prompt 位置不参与（Q139）。
7. 输出与释放：把新 token 增量 detokenize（只解新增部分）、按 stop/EOS/max_tokens 判定结束；结果经 SSE 逐 chunk 流式回给客户端；请求结束按引用计数/COW 把 KV 块归还池子（Q127/129）。

为什么叫『迭代级调度』

• 模型每前向一次 = 一步；每步结束整个 scheduler 重排一次：running 再走一步、waiting 能进就进、完成的退出、超预算的被抢占。相比『先整批 prefill、再集体 decode』的请求级 batching，迭代级让长短 prompt、不同进度的请求自然共批——vLLM 高吞吐的来源正是这个（Q94），也是『延迟与吞吐不打架』的调度根基（Q143）。

题眼：把七段各一句话讲清 + 点出『scheduler 每步产出的是一个动态批（不是固定批）』、『decode 瓶颈在读每层历史 KV（带宽）』、『请求结束要还 KV 块』三件事=真懂 vLLM 框架；再补一句 V1 下已无显式 prefill/decode 阶段（Q161）更完整。

参考来源：vLLM 官方文档：V1 / 引擎调度总览。

KV Cache 是什么：Decode 阶段每生成一个 token，都要和所有历史 token 做注意力。

若每步重算历史的 K/V 代价极高，因此把每层已算好的 K/V 缓存下来（形状 [B, num_kv_heads, L, d]），新 token 只追加。

代价：显存和读取带宽随上下文长度线性增长。

记忆锚点：KV Cache=读书把每页要点贴成便签：写下一个字要回顾全书，不缓存就得整本重读；缓存后只翻便签——代价是便签越贴越多（KV 随 token 涨）。

为什么 Prefill / Decode 差异大：

• Prefill：一次算整个 prompt，注意力是 [T_q × T_kv] 的满矩阵，计算密集（compute-bound），GPU 并行度高；
• Decode：每步只有 1 个新 query，矩阵极小，主要时间是读全部 KV Cache，访存密集（memory-bound）。

所以长上下文推理的瓶颈在 KV Cache 的容量与带宽——这正是 GQA、KV 量化、PagedAttention 存在的理由。

权威出处与数据：vLLM 论文对 KV Cache 的浪费做过实测——传统预分配连续显存时，实际存 KV 的利用率仅 20.4%~38.2%（预留给最大长度、内外碎片），PagedAttention 按 16 token/块分页后碎片 <4%，这是它能把吞吐提高 2~4× 的直接原因。KV Cache 随 batch × seq_len 增长、成为长上下文服务第一瓶颈已是共识。

题眼：抓住两个阶段访存/计算密度相反：Prefill 计算密集，Decode 每步只加 1 个 query 却要读全量历史 KV（访存密集）→ 长上下文瓶颈在 KV 的容量与带宽，这正是 GQA / KV 量化 / PagedAttention 的共同动机。

参考来源：vLLM：PagedAttention 论文（arXiv:2309.06180）、vLLM 博客：Anatomy of a High-Throughput LLM Inference System。

部署选型：

记忆锚点：压测像测餐厅排号：QPS=每小时接待桌数，P99=最慢 1% 客人等了多久——只看平均会被一桌请客的骗，SLO 盯的是那 1%（看分位）。

• vLLM：吞吐高、易上手（PagedAttention + continuous batching），适合在线服务；
• TensorRT-LLM：编译期优化 + FP8，延迟最低，适合极致性能与固定 shape；
• Triton：多框架/多模型统一服务，适合生产网关与异构管理。

压测：用 Locust/自定义脚本测 吞吐（tokens/s） 与延迟分布（TTFT 首 token、TPOT 逐 token、P99），

画 QPS-延迟曲线找拐点（吞吐上去了延迟爆炸）。

优化清单：

1. 精度：FP16 → FP8/INT8（权重 + KV 量化）；
2. 调度：continuous batching、chunked prefill、前缀缓存；
3. 引擎：CUDA Graph 捕获、减少 Python 开销、speculative decoding（投机采样，draft 模型+验证）；
4. 硬件：GPU 多实例切分、多卡 TP 推理、负载均衡与扩容。

权威出处：vLLM 的 PagedAttention/continuous batching 出自 SOSP'23 论文（吞吐比 FasterTransformer/Orca 等基线提升 2~4×）；chunked prefill、prefix caching 是其生产特性；TensorRT-LLM 主打编译期图优化 + FP8/INT8（TensorRT）；Triton 负责异构模型统一服务。

题眼：按需求选引擎：在线高吞吐上 vLLM（PagedAttention+continuous batching），延迟极致上 TensorRT-LLM（编译期+FP8），异构网关用 Triton；压测别只看平均——盯 tokens/s + TTFT/TPOT/P99，画 QPS-延迟曲线找拐点。

参考来源：vLLM：Efficient Memory Management with PagedAttention（arXiv:2309.06180）、vLLM 文档、NVIDIA TensorRT-LLM、Triton Inference Server。

一句话：SGL（Structured Generation Language，结构化生成语言）是 SGLang 的前端：让你用一段 Python 函数描述『这次生成的结构』（哪些是共享的 system/多轮前缀、要并行采几个候选、输出必须满足什么格式），而不是拼一串字符串丢给接口——引擎拿到的是一个『生成程序』，能据此把前缀复用与并行做到最大。SGLang 的名字（Structured Generation Language）说的就是这个。

最小骨架一眼看懂

@sgl.function
def answer(s, question):
    s += sgl.system("You are a concise assistant.")
    s += "Q: " + question + "\nA:"
    s += sgl.gen("answer", max_tokens=128)

• 用 @sgl.function 装饰一个 Python 函数；函数体里用 sgl.gen('名字', ...) 声明『在这里生成一段并命名』；sgl.system/user/assistant(...) 拼对话与多轮；也可 s += sgl.gen(...) 直接续写。
• 对想返回的每个字段命名，程序跑完取 state['名字'] 就是结构化结果（dict）。

SGL 比『拼字符串调 API』强在哪（面试核心）

1. 结构引擎可见：程序天然把公共前缀（system、多轮历史、few-shot）和真正新生成的部分切开；运行时把这些前缀落到 RadixCache 树里复用（Q125/163）——纯字符串客户端，引擎只能靠启发式甚至不做。
2. 并行是显式的：sgl.fork(n) 开 n 个分支（best-of-n 采样、多候选、并行子问题），sgl.join 汇合；各分支共享分叉前的前缀 → 前缀树同批推进、KV 只存一份。把『并发采样 / 多智能体分叉』从应用层挪进了引擎层。
3. 约束做进采样：sgl.gen(..., regex=...) / json_schema=... / grammar=... 让引擎在解码时用合法 token 掩码约束（Q150 同思路），输出天然可解析，而不是生成完再解析重试。
4. 多模态可交错：同一程序里可插入图像/视频输入再继续 gen——长视觉/视频任务的标准写法。

后端怎么执行一个 SGL 程序

• SGL 只是前端规范，跑的时候必须挂一个 LLM 后端：sgl.set_default_backend(sgl.RuntimeEndpoint('http://host:port'))（连到 launch_server 起的服务，走 OpenAI 兼容接口），或本地直接 sgl.LM(model_path, ...)。
• runtime 把程序拆成一段段『前向段 + 采样段』：每段的 token 前缀/长度是精确已知的；fork 产生的多分支在调度器里共享 radix 前缀、尽量同批；约束以语法状态机/掩码形式传给采样器。也就是说 SGL 让『提示词工程』升级成『生成程序』——编译与运行时层面的优化空间，是拼字符串给不到的。

题眼：能答出『SGL = 用代码声明生成结构，而非拼 prompt』并说出三个程序化收益（前缀可见→radix 复用 / fork·join→引擎内并行 / regex·schema→解码期约束），再说清『程序最终要落到一个 LLM 后端上执行』，就防住了『以为 SGL 自己能生成』的误解。

参考来源：SGLang：Efficiently Programming LLMs（SGL 与 RadixAttention 同篇提出）、官方仓库。

一句话：TTFT / TPOT / ITL 是 LLM serving 的『延迟体检表』，各自盯一段时延：TTFT 是首字多久来，TPOT / ITL 是之后每字多快、稳不稳，端到端是整段多久。它们不是装饰指标，而是 prefill 与 decode 两个物理阶段的用户可见投影（这族指标在题库里被反复引用却常没被定义，先把定义钉死）。

四个定义（先背准）

• TTFT（Time To First Token）：从『发出请求』到『收到第一个输出 token』。含排队 + 首段 prefill + 首次 decode——聊天场景用户等的就是它；计算/并发主导（Q84）。
• TPOT（Time Per Output Token）：第一个 token 之后平均每个输出 token 的耗时（生成阶段除去首字的平均）。decode 是带宽受限的逐 token 自回归 → TPOT 基本由『每步读一遍权重 + 该层全部历史 KV』的带宽决定（Q88）。
• ITL（Inter-Token Latency）：流式返回时相邻两个 token 的时间间隔。理想稳态下与 TPOT 数值接近，但它是『逐 token 采的』，能暴露抖动——调度/prefill 插入/抢占造成的忽快忽慢，用户体感是『打字断断续续』。
• 端到端延迟：从发到收完最后一个 token，近似 TTFT + (输出 token 数 − 1) × TPOT（公式要会写；首字走 TTFT，之后每个新字各一个 TPOT）。

和阶段 / 吞吐的关系

• prefill（计算型、突发）主导 TTFT；decode（带宽型、串行）主导 TPOT / ITL——所以优化手段分家：前缀缓存命中砍掉 prefill → TTFT 大降（Q125/163）；量化/GQA 减 decode 每步带宽 → TPOT/ITL 降（Q86/149）；PD 分离把两种 SLO 拆开独立扩缩（Q114/120）。
• 与吞吐：均匀 decode 的极限下，B 条并发流每步各产 1 token、步时 t ⇒ 系统吞吐 ≈ B/t、单流 TPOT ≈ t ⇒ TPOT ≈ B / 总吞吐。但生产 batch 不均质（prefill 插入、抢占、请求进出），别用总吞吐反推单请求体感（Q143）。
• 两种 SLO：聊天/交互盯 TTFT，长输出/写作盯 TPOT / ITL；goodput（DistServe）= 在 TTFT 与 TPOT 都达标的请求里算吞吐，把延迟当约束、吞吐当目标（Q126/143）。

题眼：四个定义 + 一条 端到端 ≈ TTFT + (N−1)·TPOT 先背准，再挂『prefill→TTFT、decode→TPOT/ITL』与『并发下 TPOT≈B/总吞吐（理想极限）』两条关系，就把常被混用的指标族钉死了。

一句话：API 按 token 计费，是因为 token 才是模型真正消耗的资源单位——算力、KV 显存、带宽都随它线性走；输入与输出 token 因 prefill / decode 的成本形态不同而分开计价，惯例输出约为输入的 3–4 倍。账单就是两笔钱相加。

为什么按 token，不按请求 / 字符 / 汉字 / 词

为什么 input 和 output 单价不一样（量级）

账单公式

• 按请求会失真：一个『你好』请求和一个『传 10 万字文档做总结』的请求，成本差几个数量级；服务商若按请求计费，就要自己扛极端长度风险。
• 按字符 / 汉字 / 词失真在模型侧：tokenizer 是 BPE 切分，与人类字数没有固定换算关系（Q168）；服务端计费必须和它内部真正搬运、计算的东西对齐。
• token 数直挂三笔账（Q157/119）：prefill 算力≈输入 token 数；KV 显存≈(输入+输出)长度×每 token 开销；decode 带宽≈逐 token 读出权重与 K/V。按 token = 按真实成本单位。
• 输出 token 更贵，因为 decode 是逐 token 串行、memory-bound，GPU 峰值利用率低（Q88/170）：每个生成 token 都要把全部权重 + 历史 K/V 读一遍，单 token 的成本下限高；而 prefill 是大 GEMM、算力利用充分、同一批输入可并行摊薄。
• 主流惯例：输出 ≈ 输入 ×3–4。示例（价格随厂商/模型/时段浮动，以官方价格页为准）：OpenAI gpt-4o 曾 in $2.50 / out $10（每百万 token），gpt-4o-mini 曾 $0.15 / $0.60；各供应商方向一致，都是『输出显著贵于输入』。
• 缓存命中的输入通常再打折：命中段不需要重新 prefill（Q125/163）——OpenAI 曾约半价，DeepSeek 曾 cache-hit 价远低于 miss 价。所以共享前缀越长（system prompt、多轮历史），命中越多、输入成本越低，这是优化账单的第一抓手。

cost = input_tokens×p_in + cached_input_tokens×p_cache + output_tokens×p_out（p 为每百万 token 单价）。同一段输入里：前缀命中的部分走 p_cache、未命中的走 p_in；输出没有缓存价。

输入主导 vs 输出主导

• 输入主导：RAG / 超长文档问答（检索资料全塞进 prompt）、复杂 system prompt、带全量历史的多轮——输入随『喂进去的资料与记忆』线性涨（Q136），输出往往只是一段答案。
• 输出主导：对话闲聊、总结 / 翻译、长文与代码生成、agent 多轮里模型自己产出的内容——输出 token 多、单价又高。
• 判断：两侧各自『token 数 × 单价』再比大小，不要只数 token。长文档 RAG 常是『输入 token 多但单价低、输出 token 少但单价高』，算完才知道钱在哪头。

题眼：先答根因（token = 算力 / KV / 带宽的真实计量单位），再写账单公式、讲清输出≈输入 3–4×、缓存命中输入另打折，最后能指出『用量×单价』判断主导而不是只看 token 数。

参考来源：OpenAI Pricing、Anthropic 计费文档、DeepSeek API 定价与缓存命中。

一句话：Terraform 是声明式 IaC——你描述"想要的最终状态"（.tf 里的资源），它把当前真实状态记在 State，把"从现状到目标"算成 Plan，再执行 Apply。三个核心概念：

• State（tfstate）：基础设施的"事实来源"，记录每个资源的 id 与属性（本地文件或远端 backend S3/Consul）。一致性全靠它：丢/旧 State = TF 不知道要改什么（→ Q111 drift）；
• Provider：与具体系统对话的插件（AWS/Azure/GCP/K8s…），把 TF 的资源模型翻译成真实 API 调用；每个资源必须归属某个 provider，支持 alias/多版本；
• Plan / Apply：先做差异分析生成可读执行计划（dry-run、可评审），Apply 按计划增删改并回写 State（多人协作时 backend 要加锁防并发写坏）。

题眼：讲清"声明式目标 + State 事实源 + Provider 翻译 + Plan 先行"四件套，再点出 State 是双刃剑（一致性来源也最容易出错），就能引出 drift/import/backend 锁这些连环考点。

参考来源：Terraform 官方文档（State / Provider / CLI 工作流）。