主题
JavaGuide 与小林都系统讲过（二哥无对应页），对比 JavaGuide《LLM 运行机制》 与小林《温度值、Top-P、Top-K》《解码策略有哪些》。
两版对比
JavaGuide 从工程稳定性切入：采样参数一变输出就飘，是调用链路不稳定的常见根因；成本核算要分输入、缓存输入、输出（和 reasoning tokens）分别记账。
小林 给了完整的参数机理和实战口诀：Temperature 管分布松紧（除以 T 再 softmax，T=0 退化成贪心）、Top-K 是固定截断、Top-P 是自适应截断（确定性问题候选池自动缩到 1，开放问题扩到几十个）；三参数是叠加约束，同时大调互相干扰（高温配低 Top-P = 先搅浑再砍半，结果不可预测）。口诀：「只调 Temperature，Top-P 保持 0.9-1.0，Top-K 不设」，且别把某产品默认值当行业标准。
解码策略的本质假设（小林独有，高价值）：贪心 / Beam Search 假设「存在唯一最优答案」，采样假设「答案有多种合理可能」——选型分歧全在这一句。Beam Search 失宠不只是慢：开放生成没有唯一最优解，「整体概率最高」等价于最乏味最易复读（束越宽越差），而且和 KV Cache 等单序列推理优化不兼容（要复制 B 份显存）；它退回了翻译、受约束生成这些真有唯一解的场景。
最优题解
三个采样参数各管一件事：Temperature 控分布松紧，越低越确定；Top-K 固定候选数；Top-P 按累计概率动态截断。它们是叠加约束，实践口诀是只调温度、Top-P 保持 0.9-1.0、Top-K 不设，一次只动一个参数并跑回归。分档的话：抽取、分类这类精确任务用低温，日常对话中温，创意生成放开——但最终以自己任务的评测为准，默认值不是标准。
解码策略的分歧其实是一个假设问题：任务有没有唯一最优答案。有——翻译、格式受约束的生成——用贪心或 Beam Search；没有——开放对话、创作——用采样。Beam Search 在开放生成里失宠不是因为慢，而是「整体概率最高」天然选最平庸的路径，还和 KV Cache 这类单序列优化相冲突。
追问链
追问：温度调到 0 是不是就不幻觉了？ 参考答：不是。T=0 只是去掉了随机性，概率最高的 token 依然可能是错的——温度防的是「漂」，不防「错」；错误要靠检索依据和事实核查治。展开见 幻觉成因与治理。
追问：结构化输出场景怎么配参数？ 参考答：低温 + 受约束解码（按 Schema 约束每步候选），格式类错误可以根除；同时输出上限要留足，防止被截断的半截 JSON。
我的理解
这题的层次：背参数定义是及格，说得出「叠加约束、一次只调一个」是良好，能答「解码策略 = 有没有唯一最优答案的假设分歧」是优秀——后者把一堆策略名收成一句判断。小林的口诀直接可用；JG 的「别把默认值当标准」和小林的「分档后仍以本地评测为准」是同一个谨慎口径。