自测与跨章辨析

概念层

1. 输入是"角色标注过的整段对话"（messages），输出是模型续写的下一段 assistant 内容。会话状态由你的客户端维护——服务器无状态，每次调用都要把完整历史重发。
2. token 是模型的子词单位（BPE 切分），约 0.75 个英文词 / 1–2 个汉字。用字符数会出错，因为切分不是按字符、且各模型 tokenizer 不同；上下文上限和计费都按 token，不按字符。
3. 改善的是首字时间（TTFT）/ 感知延迟，不是生成总速度。总时长不变，只是让第一个字更早出现。
4. 不是最终答复，是中间步——模型只 emit 了"想调用 X(参数)"的 token。真正执行函数的是你的代码；执行完把结果喂回，模型才给最终答复。
5. JSON mode 不保证形状（字段可能缺/错/类型不符）也不保证完整（截断成半个对象）；strict schema 保形状，但代价是 schema 需可编译、部分特性（递归等）不支持。

原理层

6. 角色是模型训练时学会服从的特殊 token（如 ChatML 定界符），生效靠训练分布而非服务端权限校验。所以模型只能从风格上区分 system 与 user，无法证明指令来源——把"忽略上面指令"塞进 user 或工具结果里，模型可能照做，这就是注入。
7. 把 schema 编译成语法/状态机，每步用一个 logit 处理器把"违反当前语法状态"的 token 概率设为 −∞ 再采样——非法形状的 token 概率归零，所以不可能被采到。
8. 不是随机数。根因在推理 kernel 不是 batch-invariant：请求被拼进动态 batch，浮点求和顺序随 batch 大小变化，而浮点加法不满足结合律，末位误差逐 token 放大成不同分叉。
9. decode 每步都要看前面所有 token；KV cache 把每个 token 的 Key/Value 存下来供复用，避免重算，但它随 token 线性增长、占满显存带宽——所以长上下文又慢（带宽受限）又贵（cache 大）。
10. 命中要求缓存的前缀逐字节相同。时间戳每秒都变，放在顶部会让整个前缀每次都不同，后面再长的固定内容也全部失效、全价重算。动态内容必须放在缓存断点之后。

应用判别层

1. 场景 1：重点用结构化输出（标签要进数据库，必须是可靠的枚举字段，strict schema 把 label 限定在三选一）。放弃流式——批处理没有"人盯着等"的场景，TTFT 无意义，流式只增加解析复杂度；这类任务更该用 Batch API（约 5 折）。不开高 effort reasoning——情感分类是简单任务，开高 effort 纯烧 token。
2. 场景 2：选自托管开源（vLLM + 长上下文开源模型）。结构化输出走推理引擎自带的约束解码（自托管下没有"原生 SDK vs 兼容层"问题，引擎直接管）。决策树里"数据是否不能出境"一票定音——硬合规约束先于任何能力/价格考量，直接锁进自托管支。30 万字（30 万+ token）再叠加长上下文要求。
3. 场景 3：两个最可能根因——① prompt cache 未命中反噬（前缀被破坏，每次付 1.25× 写入却命中不了 0.1× 读取，§2.4）；② 忘设 max_tokens / 输出失控导致 completion token 暴涨（§2.6）。先查缓存命中率指标和前缀是否稳定（更隐蔽、更常见），再查 max_tokens 配置。
4. 场景 4：根因属于工具调用原语的失败模式（失败结果原样喂回 → 模型反复重试，§01.4 / §2.6）。两种止损：① 限制每轮工具调用次数（拦在"喂回—再请求"这一步，超限就跳出循环）；② 工具失败时返回结构化的错误信息而非原始报错、并在若干次后把 tool_choice 复位为 auto，让模型有机会停下来给文字答复。
5. 场景 5：不可让步项是结构化输出的形状保证——下游严格依赖三字段，少一个或类型错会让报表系统崩或算错。这条路径绝不能走兼容层：兼容层会丢掉 strict 保证（§3.2 边界），退化成"倾向"而非"保证"。valid-but-wrong 比"贵一点"危险，是因为它静默产出错误数据、下游照单全收，等发现时已污染一片；而贵只是钱的问题，可见、可控。