小张开了一家面馆，招牌是“上海葱油拌面”。生意一好，问题就来了：每位客人点单，他都要从洗葱、切葱、熬葱油开始。哪怕十位客人都点同一碗面，他也得重复十遍熬油的活。后厨忙得脚不沾地，客人却等得心急火燎。一位餐饮顾问给他支了招：与其天天现做，不如搞“中央厨房”改造——把熬好的葱油装进保鲜盒，贴上配方标签摆上货架；把每道菜的做法写成标准作业单；再约定好每碗面的摆盘规格，客人说要什么形状就是什么形状。 这个“中央厨房”，正是大模型推理框架 SGLang 的缩影。大模型生成文本，本质像一位“厨师”逐字地“做菜”。传统推理服务里，每个用户请求都从零开始“备菜”，哪怕他们的前几轮对话完全相同，也得重复计算。SGLang 做了三件大事：把常用“食材”（KV 缓存）按前缀标签摆上货架，让相同开头的请求共享（RadixAttention）；把出餐流程编译成流水线，减少等待与浪费（编译器式优化）；用固定模具约束出品规格，说好 JSON 就是 JSON（结构化输出）。本文就用这场后厨改造，带你完整看懂 SGLang。

岗位关联

对 AI 从业者而言，SGLang 是生产环境中把大模型“用好、跑快”的关键工具箱。掌握它，意味着你可以在部署、函数调用、结构化输出等高价值任务里，把成本打下来、把稳定性提上去。

目录
  1. 可视化演示
  2. 一、编译器式优化：把“现做”变成“流水线”
  3. 二、RadixAttention：会分叉的备菜货架
  4. 三、结构化输出：用模具压出标准形状
  5. 四、函数调用：听懂客人的“点菜指令”
  6. 五、性能优势：算清后厨的成本账
  7. 六、部署实践：从样板厨房到连锁品牌
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示SGLang的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

SGLang：SGLa SGLang框架定位与设计理念 RadixAttention前 核心机制可视化 SGLang整体架构与关键组件

一、编译器式优化：把“现做”变成“流水线”

小张的后厨很典型：客人点单，他烧火、备菜、炒菜，一气呵成，但每碗面都把灶台占得死死的。餐饮顾问给出的方案是“流水线化”——不要一个客人独占整口锅，而是把备菜、炒制、装盘拆成独立工位，多个订单在同一时间推进不同的工序。SGLang 的设计者同样发现，GPU 推理最浪费的，就是请求之间的“空烧”：传统框架一个请求用完整个 GPU，另一个请求只能排队等着。

于是 SGLang 把“生成一个回答”看成一条可编译的数据流图。调度器像流水线班长一样，把不同请求的 prefill（预填充，即先读取输入并计算缓存）和 decode（逐字生成）阶段拼到同一批矩阵运算里。多个请求共享一次 GPU 计算，空转时间自然被填满。它还做算子融合：把注意力计算与采样等相邻步骤合并进同一个内核，减少显存反复读写的搬运成本。

这里的关键指标是 GPU 利用率——真正干活的算力占比：

改造之后，小张发现同样的灶台，出餐量却翻了几倍——不是因为火更旺，而是因为火不再空烧。SGLang 的编译器式优化，正是让 GPU 这块“金灶台”每秒钟都忙在刀刃上。

utilization=TcomputeTcompute+Tidle\displaystyle \text{utilization} = \frac{T_{\text{compute}}}{T_{\text{compute}} + T_{\text{idle}}}
  1. 计算时间 \(T_{\text{compute}}\)GPU 真正执行矩阵乘法的有效时间，相当于厨师真正在炒菜。
    Tcompute\displaystyle T_{\text{compute}}
  2. 空闲时间 \(T_{\text{idle}}\)GPU 等待、内存搬运、批处理不完整造成的空转时间，相当于灶台烧着却没锅。
    Tidle\displaystyle T_{\text{idle}}
  3. 利用率有效时间占总时间的比例，越接近 1，说明灶台越忙、浪费越少。
    utilization=TcomputeTcompute+Tidle\displaystyle \text{utilization} = \frac{T_{\text{compute}}}{T_{\text{compute}} + T_{\text{idle}}}

二、RadixAttention：会分叉的备菜货架

流水线提高了出餐效率，但小张又发现新瓶颈：备菜。每位客人点葱油拌面，他都要重新洗葱、熬油，哪怕配方一模一样。顾问让他建一个“备菜货架”：把熬好的葱油按配方标签装好，客人点单先看货架，有的食材直接取用。大模型推理中，这个“备菜货架”就是 KV 缓存——模型在读取输入时算好的中间状态。传统框架里，每个新请求都重新计算整份缓存，哪怕它的开头和前面的请求完全相同。

SGLang 的 RadixAttention 用一棵“基数树”来管理这些缓存。树的每条路径代表一个 token 前缀序列，路径上挂着对应的 KV 缓存。当新请求到达，它先沿着树找最长的共享前缀，找到后直接从分叉点继续计算，而不是从头开始。请求处理完之后，缓存也不会直接扔掉，而是放回树上，等待下一个请求复用。树上的节点会记录被多少个请求引用，长时间没人用的旧缓存，会被类似 LRU 的淘汰机制清出货架，给新缓存腾地方。

衡量这套机制收益的，是缓存复用率：

有了货架之后，小张发现“上海”开头的订单几乎不用重新洗菜了——客人点“上海天气”和“上海美食”，前面两步完全一样。这个“一步到位的备菜”，就是 RadixAttention 最迷人的地方。

reuse_rate=∑iLishared∑iLitotal\displaystyle \text{reuse\_rate} = \frac{\sum_i L_i^{\text{shared}}}{\sum_i L_i^{\text{total}}}
  1. 共享前缀长度 \(L_i^{\text{shared}}\)第 \(i\) 个请求与已有缓存重合的 token 数，相当于店里已有的熟葱油量。
    Lishared\displaystyle L_i^{\text{shared}}
  2. 总输入长度 \(L_i^{\text{total}}\)该请求全部的输入 token 数，相当于客人这一单需要的全部食材。
    Litotal\displaystyle L_i^{\text{total}}
  3. 复用率对所有请求求和后取比值，越高说明“取货架上现成食材”的比例越大，新算的越少。
    reuse_rate=∑iLishared∑iLitotal\displaystyle \text{reuse\_rate} = \frac{\sum_i L_i^{\text{shared}}}{\sum_i L_i^{\text{total}}}

三、结构化输出：用模具压出标准形状

有一天，一家连锁快餐品牌来找小张，说想订购 500 份盒饭，但要求每份都一样：米饭在上、荤菜左下、素菜右上，绝不随意发挥。小张发现，如果只靠口头嘱咐“请按规格摆盘”，总有几份会走样。于是他定制了一批模具，出餐时直接压模成型。大模型的结构化输出，正是同样的道理。

很多 AI 应用要求模型输出 JSON，比如 {"city": "上海", "weather": "晴"}。传统做法是在提示词里加一句“请输出 JSON”，模型大部分时候听话，但偶尔会多写解释文字、漏掉字段或引号不匹配。SGLang 的结构化输出，在解码时就“压模”：它把正则表达式或 JSON Schema 编译成约束，每生成一个 token 前，先检查哪些候选词是合法的，不在合法集合里的词，直接禁止输出。

从概率视角看，就是对每一步解码施加一个硬性过滤：

小张把模具交给后厨后，500 份盒饭摆盘完全一致，抽查率百分百合格。SGLang 对 JSON 的约束同样如此——输出即合法，不需要事后返工清洗。

Pr⁡(vt∣x<t)=0ifvt∉Vt(R)\displaystyle \Pr(v_t \mid x_{<t}) = 0 \quad \text{if} \quad v_t \notin \mathcal{V}_t(\mathcal{R})
  1. 候选词 \(v_t\)第 \(t\) 步模型可能生成的词，相当于摆盘时可选的各种食材块。
    vt\displaystyle v_t
  2. 合法集合 \(\mathcal{V}_t(\mathcal{R})\)在当前已生成内容与规则 \(\mathcal{R}\) 约束下，第 \(t\) 步允许出现的所有词。
    Vt(R)\displaystyle \mathcal{V}_t(\mathcal{R})
  3. 概率置零一旦候选词不属于合法集合，它的生成概率就被直接改为 0，模型根本“说不出”不合规的词。
    Pr⁡(vt∣x<t)=0\displaystyle \Pr(v_t \mid x_{<t}) = 0

四、函数调用：听懂客人的“点菜指令”

盒饭生意稳定后，小张想做外卖平台。他发现客人不光要标准盒饭，还要定制菜单：比如“帮我查一下明天上海的天气”。这就需要后厨不仅能出餐，还得能读懂标准化指令，转给对应的窗口执行。大模型的函数调用（Function Calling）就是这个场景：让模型在对话中输出“我要调用什么函数、传什么参数”，然后由程序解析并执行真实 API。

关键是，模型输出的指令必须是一份无歧义的 JSON。SGLang 用结构化输出约束模型，让它只能生成形如 {"name": "get_weather", "arguments": {"city": "Shanghai"}} 的文本。函数名和参数都由前文的 schema 定义好，模型不能自由发挥。这样，外围程序拿到输出后可以直接 json.loads，拿到 name 和 arguments 两个字段，再映射到真实的 Python 函数去执行。函数调用的形式化表示就是：

小张的外卖平台上线后，后厨按标准指令单接单，出菜窗口各司其职：查天气的去查天气、下单订座的去订座。模型的“一句话”，在 SGLang 的约束下变成结构清晰、可以执行的程序调用。

{“name”:f,“arguments”:a}↦f(a)\displaystyle \{ \text{``name''}: f, \text{``arguments''}: a \} \mapsto f(a)
  1. name 字段 \(f\)模型先决定调用哪个工具，函数名必须在预定义工具表中。
    “name”:f\displaystyle \text{``name''}: f
  2. arguments 字段 \(a\)参数必须是一个合法 JSON 对象，键和取值都受 schema 约束。
    “arguments”:a={k1:v1,…,km:vm}\displaystyle \text{``arguments''}: a = \{k_1: v_1, \dots, k_m: v_m\}
  3. 执行映射程序解析这份 JSON 后，把参数展开并真正调用函数 \(f(a)\)，得到外部世界的真实结果。
    f(a)↦result\displaystyle f(a) \mapsto \text{result}

五、性能优势：算清后厨的成本账

中央厨房改造到底值不值？小张拿出账本：以前每碗面都从洗菜开始，现在备菜货架上一大半食材都是现成的；以前灶台空烧，现在流水线排得满满当当；以前客人要换口味得重做，现在标准化出餐，次品率几乎为零。三项加起来，高峰时段的出餐量是原来的好几倍。SGLang 的性能账，也藏在同样的三个地方。

缓存复用大幅减少了 prefill（预填充）阶段的重复计算；动态批处理把不同请求拼车运输，让 GPU 吞吐提升；结构化输出避免了因为格式错误导致的整段重试。综合起来，推理总耗时大幅下降，尤其是共享前缀明显的多轮对话、批量抽取类任务，收益最为显著。加速比可以写为：

账本算完，小张很满意：同样的房租和人力，营收却翻了倍。SGLang 的部署者也会在监控面板上看到类似的曲线——缓存命中率越高，省下的算力越可观。

S=TbaselineTsglang=∑r(Lrprefill+Lrdecode)∑r(Lrnew+Lrdecode)\displaystyle S = \frac{T_{\text{baseline}}}{T_{\text{sglang}}} = \frac{\sum_r \left(L_r^{\text{prefill}} + L_r^{\text{decode}}\right)}{\sum_r \left(L_r^{\text{new}} + L_r^{\text{decode}}\right)}
  1. 基线耗时 \(T_{\text{baseline}}\)每个请求都从头计算全部输入的成本，相当于每单都从洗菜开始。
    Tbaseline=∑r(Lrprefill+Lrdecode)\displaystyle T_{\text{baseline}} = \sum_r \left(L_r^{\text{prefill}} + L_r^{\text{decode}}\right)
  2. SGLang 耗时 \(T_{\text{sglang}}\)得益于缓存，prefill 只需计算缓存未命中的新部分 \(L_r^{\text{new}}\)。
    Tsglang=∑r(Lrnew+Lrdecode)\displaystyle T_{\text{sglang}} = \sum_r \left(L_r^{\text{new}} + L_r^{\text{decode}}\right)
  3. 加速比 \(S\)两者相除，\(S > 1\) 说明更快，值越大，省下的重复劳动越多。
    S=TbaselineTsglang\displaystyle S = \frac{T_{\text{baseline}}}{T_{\text{sglang}}}

六、部署实践：从样板厨房到连锁品牌

中央厨房的成功让小张动了开连锁店的念头。他发现“中央厨房”本身可以打包成一套可复用的基础设施：每家门面只要接通总部的备菜货架和标准流程，就能快速开业。SGLang 的部署形态正是这样：你启动一个 Runtime 服务，相当于开了一间“标准厨房”，它对外暴露 OpenAI 兼容的接口，客户端可以用熟悉的 chat/completions 方式调用，后端则由 SGLang 负责调度、缓存和约束生成。

实际落地时，工程师通常先用 python -m sglang.launch_server --model-path ... 拉起服务，然后写业务代码调用它。对于离线批量任务，可以一次提交上千条请求，让它们在共享前缀的缓存树上“拼车”跑完。上线后要盯着几个关键指标：缓存命中率、吞吐量、首 token 延迟。命中率是 RadixAttention 的“体温计”，如果它很低，说明请求前缀彼此差异太大，需要调整 prompt 模板或消息结构，让共享部分更集中。

缓存命中率是部署监控中最直观的健康指标：

小张的连锁店一家家开起来，每家门面都用同一套中央厨房标准，出餐稳定、成本可控。SGLang 也正在成为越来越多大模型应用的后厨标配——把重复劳动交给缓存，把质量交给约束，把速度交给调度。

hit_rate=hit_tokenstotal_tokens\displaystyle \text{hit\_rate} = \frac{\text{hit\_tokens}}{\text{total\_tokens}}
  1. 命中 token 数 hit\_tokens直接从缓存树读取、无需重新计算的 token 数量。
    hit_tokens\displaystyle \text{hit\_tokens}
  2. 总 token 数 total\_tokens所有请求输入 token 的总和，衡量“本来要算多少”。
    total_tokens\displaystyle \text{total\_tokens}
  3. 命中率两者之比，命中率越高，说明“备菜货架”越契合订单结构。
    hit_rate=hit_tokenstotal_tokens\displaystyle \text{hit\_rate} = \frac{\text{hit\_tokens}}{\text{total\_tokens}}

AI 应用场景

智能客服结构化工单

阶段：推理服务与结构化输出

解决的问题：传统客服机器人把对话整理成工单时，需要从长文本里人工抽取字段，写正则或反复让模型“重新输出”。SGLang 用 JSON Schema 约束模型，让它在回复时直接产出 {"客户名": "张三", "问题类型": "退款", "优先级": "高"} 这样的结构化文本，字段齐全、格式零瑕疵，下游系统拿到即可入库。

具体案例：某电商平台的售后机器人每天处理数万会话。接入 SGLang 后，工单生成从“先自由文本再解析清洗”变成“生成即结构化”，工单字段完整率从 85% 提升到 99.9%，下游工单系统的解析代码几乎没改过。

Agent 工具调用平台

阶段：函数调用与 Agent 循环

解决的问题：Agent 需要调用查询天气、订票、查库存等真实 API，模型输出的函数名和参数一旦格式非法，整个 Agent 循环就会卡死。SGLang 的结构化输出约束模型只会生成预定义工具的函数签名，解析稳定性大幅提升。

具体案例：某出行助手 Agent 在用户说“帮我订明天北京到上海的高铁”时，SGLang 强制模型输出 {"name": "search_train", "arguments": {"from": "北京", "to": "上海", "date": "明天"}}，程序直接解析执行，多轮工具调用的成功率从 78% 提升到 96%。

海量日志离线信息抽取

阶段：离线批量推理与缓存复用

解决的问题：上万条日志要抽取错误码和堆栈信息，逐条调用模型，每次都重复计算相同的 system prompt 和抽取指令，算力浪费严重。SGLang 的 RadixAttention 让所有请求共享同一前缀缓存，只需计算各自日志部分，吞吐提升数倍。

具体案例：某云厂商对 10 万条线上日志做安全分析，统一用同一模板 prompt 抽取敏感信息。SGLang 批量跑完耗时从原来的 6 小时缩短到 1.5 小时，GPU 成本下降约 70%。

Python 演示

python36 行
import sglang as sgl PROMPT = (    "You are a travel assistant. "    "Always answer in strict JSON with keys: city, budget, spots. "    "Never output anything else.\n") @sgl.functiondef travel_plan(s, city, budget):    s += PROMPT    s += "City: " + city + ", Budget: " + str(budget) + "\n"    s += "Answer: " + sgl.gen(        "answer",        max_tokens=200,        temperature=0.2,        regex=r'\{[^{}]*\}'    )  def main():    sgl.set_default_backend(        sgl.RuntimeEndpoint("http://localhost:30000")    )    requests = [        ("Shanghai", 300),        ("Shanghai", 500),        ("Beijing", 400),    ]    for city, budget in requests:        state = travel_plan.run(city=city, budget=budget)        print(city, budget, "=>", state["answer"])  if __name__ == "__main__":    main()
目的：演示用 SGLang 定义一次结构化生成任务，用正则约束输出必须是 JSON，并批量发送三个请求，让 RadixAttention 自动复用前缀缓存。
  1. @sgl.function把普通 Python 函数编译成 SGLang 可调度的生成模板，相当于把“菜谱”注册进中央厨房。
  2. s += PROMPT用加法向生成上下文追加内容，SGLang 会把整个上下文视为一棵可复用前缀的树。
  3. sgl.gen("answer", ...)声明一个生成变量，告诉框架“从这里开始逐个 token 生成答案”。
  4. regex=r'\{[^{}]*\}'用正则约束解码过程，保证输出是最外层花括号包住的 JSON，不含多余文字。
  5. sgl.set_default_backend(...)把生成任务绑定到已经启动的 Runtime 服务上，相当于指定用哪家中央厨房出餐。
  6. travel_plan.run(city=..., budget=...)真正执行一次生成，参数会替换到模板中，输出存放在 state["answer"] 里。
  7. ("Shanghai", 300)` 与 `("Shanghai", 500)两条请求共享 上海 前缀，第二次请求会直接命中缓存，只算新部分。

常见误区

误区我在提示词里写“请务必输出 JSON”，模型就肯定会乖乖输出 JSON 了，不用额外加工具。

正解提示词只是软约束。模型底层是概率采样，偶尔会多写一句解释、漏一个字段或引号不配对。SGLang 的结构化输出是硬约束：解码时把不合 JSON 语法的 token 概率直接归零，像用模具压月饼，形状必然统一，不需要碰运气。

为何常见：提示词工程的成功率通常高达 90% 以上，让人误以为 100% 可靠，而小概率失败在日志里才暴露出来。

误区RadixAttention 把缓存都存起来不清理，显存再大也不够用，反正越快越好。

正解缓存树像仓库货架，空间有限。SGLang 用引用计数加 LRU 式淘汰：节点还被其他请求共享时计数大于零，绝不淘汰；没人引用且最久没被访问的节点，优先腾出去。这样才能在有限显存下维持高命中率。

为何常见：把“缓存命中加速”简单理解成“缓存越多越好”，忽略了显存是稀缺资源，必须有进有出。

误区我不做 JSON 和函数调用，主要做普通多轮聊天，SGLang 对我来说没有意义。

正解RadixAttention 对多轮对话和批量跑的收益同样巨大。每轮对话的历史内容都挂在缓存树上，新问题只需在历史前缀后继续生成，省掉大量重复计算。结构化输出只是 SGLang 众多能力中的一项。

为何常见：论文和演示最喜欢拿 JSON 举例，因为效果直观，导致大家误以为 SGLang 的适用面很窄。

误区部署了 SGLang，因为缓存优化很厉害，所有请求的首个 token 都会飞快返回。

正解缓存命中才有收益。对于全新的 prompt 前缀（冷启动），没有任何缓存可用，首 token 延迟和传统框架相差不大。要真正快起来，得设计稳定的共享前缀，例如把 system prompt 和 few-shot 示例统一放在开头。

为何常见：看到评测里亮眼的数字，忽略了评测场景默认了大量共享前缀，和自己的线上流量模式并不一样。

误区每生成一个 token 都要跑一遍完整正则匹配，这开销太大了，结构化输出肯定拖慢速度。

正解SGLang 把正则编译成有限状态机，解码时只需跟随状态转移，掩码计算接近常数时间，而不是每次都重读完整正则。相比“先生成再清洗、不合格就重试”的老路，约束解码整体反而快得多。

为何常见：凭直觉认为“正则 = 慢”，忽略了编译器式优化可以把约束预计算成一张高效状态表。

面试题

Q1. SGLang 中最核心的缓存复用技术是哪一项？

单选题 · easy

  • A.RadixAttention 前缀缓存复用← 正确答案
  • B.模型权重低比特量化压缩
  • C.知识蒸馏小模型替换
  • D.权重剪枝稀疏化加速

答案：A。SGLang 的标志性技术是 RadixAttention，用基数树缓存共享前缀的 KV 缓存。量化、蒸馏、剪枝都是模型压缩手段，并不是 SGLang 的核心特色。

Q2. RadixAttention 的基数树缓存有哪些特点？

多选题 · mid

  • A.共享前缀请求可以复用缓存← 正确答案
  • B.请求会沿用已缓存的 KV Cache← 正确答案
  • C.节点过期时按引用计数淘汰← 正确答案
  • D.树的每个叶子固定长度不可变

答案：ABC。基数树按前缀组织缓存，相同前缀的请求可以共享 KV 缓存，并通过引用计数和 LRU 策略淘汰冷节点。叶子节点长度并不固定，D 说法错误。

Q3. SGLang 如何保证模型输出合法的 JSON 文本？

单选题 · mid

  • A.在解码时用正则掩码限制词表← 正确答案
  • B.在训练时用微调强制约束格式
  • C.在提示词中承诺输出固定格式
  • D.在后处理时用脚本清洗坏 JSON

答案：A。SGLang 在解码每一步动态计算合法 token 集合，非法的直接置零概率。微调、提示词、后处理都不是 SGLang 采用的硬约束手段。

Q4. 关于 KV 缓存命中后的推理过程，正确的是？

单选题 · mid

  • A.命中缓存则跳过输入 prefill← 正确答案
  • B.命中缓存可减少模型参数加载
  • C.命中缓存之后无需任何解码
  • D.命中缓存能直接增大词表大小

答案：A。命中缓存意味着输入前缀的中间状态已存在，无需重新 prefill，只需从分叉点开始 decode。参数加载、词表大小都与缓存命中无关。

Q5. SGLang 的编译器式优化主要解决什么问题？

单选题 · mid

  • A.GPU 计算与内存搬运动态调度← 正确答案
  • B.训练数据清洗与样本扩增
  • C.模型权重更新与梯度下降
  • D.向量数据库索引与检索

答案：A。SGLang 把生成任务编译成数据流图，通过调度和算子融合减少 GPU 空转与显存搬运。数据清洗、梯度下降、向量检索都是训练或检索领域的事情。

Q6. 正则约束解码时，合法 token 集合变化规律是？

单选题 · hard

  • A.随已生成内容动态更新状态← 正确答案
  • B.生成开始前一次性固定全集
  • C.始终随机选择任意合法字符
  • D.只在首 token 做一次正则检查

答案：A。正则匹配是状态机，每生成一个 token 状态都会转移，下一步合法集合也随之改变。一次性固定或只查一次都无法保证整段输出合法。

Q7. 函数调用时 SGLang 结构化输出主要约束什么？

单选题 · easy

  • A.函数名和参数必须是 JSON← 正确答案
  • B.函数内部的 Python 语法
  • C.模型加载的 GPU 显存大小
  • D.服务部署的端口与地址

答案：A。函数调用要求模型输出 {"name": ..., "arguments": {...}} 的标准 JSON，SGLang 负责保证这个输出格式合法。函数内部实现、显存、端口部署都不是它约束的对象。

Q8. 与传统逐请求推理相比，SGLang 哪些机制带来提升？

多选题 · hard

  • A.共享前缀的 RadixAttention 缓存← 正确答案
  • B.调度器动态合并等待请求← 正确答案
  • C.正则约束避免重复格式重试← 正确答案
  • D.强制所有请求使用同一温度

答案：ABC。缓存复用减少 prefill 计算，动态调度填满 GPU 空档，结构化输出降低返工率，三者共同提升吞吐。强制温度既不是优化手段，反而会牺牲效果。

Q9. 请求解码完成后，其 KV 缓存最终去向是？

单选题 · easy

  • A.放回基数树供复用并淘汰← 正确答案
  • B.立即释放且永不参与缓存
  • C.写入训练集参与模型微调
  • D.复制到所有 GPU 内存副本

答案：A。SGLang 会把请求产生的 KV 缓存放回基数树，等待后续相同前缀的请求复用，内存紧张时按引用计数和 LRU 淘汰。缓存不会进入训练集，也不做全量复制。

Q10. 衡量 SGLang 部署效果时，应关注哪些指标？

多选题 · mid

  • A.缓存命中率与平均吞吐量← 正确答案
  • B.首 token 延迟与生成延迟← 正确答案
  • C.日志中格式非法重试次数← 正确答案
  • D.训练集上 Loss 收敛速度

答案：ABC。命中率反映缓存效率，吞吐和延迟反映服务性能，重试次数反映结构化输出质量。Loss 收敛是训练阶段的指标，与部署推理无关。