很多团队一做结构化抽取、长摘要复核或代码修补就把Beam Search当成稳质量的保险丝。开关刚打开时离线命中率常会涨一点。⚠️ 真到线上多数人先看到的不是质量提升而是输出速度塌下去KV Cache占用和批次抖动一起抬头。问题往往不在模型“不会搜”而在推理引擎把搜索状态做成了昂贵常驻。原本一条 decode 链路只要维护一份前缀和一组采样状态一旦 beam 宽度从1变成4很多实现会很早复制隐藏状态、KV引用和重排元数据。 表面只是多保留几个候选实际却把单请求热路径改成了多分支调度。图 1Beam Search 不会自动解决线上吞吐吞吐断崖通常不是搜索太深而是分支太早失控最常见的浪费是共享前缀还没真正分叉系统已经把每个 beam 当独立请求。 前5 - 10个 token 往往还在同一条高概率路径上按理只需要一份前缀状态可不少引擎从第一步起就分配完整 beam 槽位让批大小、缓存占用和重排成本同步放大。 GPU 看起来很忙真正忙的是重复维护本可共享的状态。第二个坑是完成态 beam 没有及时压缩。️ 有些请求里前两个候选已经遇到EOS后两个候选还在缓慢扩展如果调度器继续按固定宽度保留整组张量慢分支就会拖住整条请求。 线上经常不是 Beam Search 本身拖垮服务而是“已完成分支仍常驻、低分分支迟迟不退出”把尾延迟越拖越长。图 2昂贵的不是候选而是无效分支常驻一组 14 B 回放里决定结果的是前缀压缩不是 beam 开关这次回放的是14 B指令模型硬件为4 x H100请求类型以结构化摘要和代码修复为主平均输出长度168token。 基线组使用贪心解码第二组开启beam 4的朴素实现第三组同样使用beam 4但把前8个 token 维持共享前缀并在候选结束或分差拉开后立刻压缩低价值分支。 结果很直接吞吐差异主要由“是否回收共享状态”决定。✅方案首 Token P95输出 Tokens/s峰值 KV 显存结构化命中率贪心解码182 ms14121 GB91.4%beam 4朴素实现197 ms6439 GB93.9%beam 4 prefix compaction201 ms10328 GB93.7%这组数据最值得记住的点是第二组并没有“选错算法”而是把状态复制做得太早、太满。 当前缀共享和完成态压缩被补上后质量几乎保住了吞吐却明显回升。线上真正要治理的不是beam width这个数字而是每条分支何时值得拥有独立状态。beam_runtime{num_beams:4,share_prefix_until:8,compact_finished_beams:True,score_gap_prune:1.6,max_active_branches:2,reorder_bucket_tokens:32,}图 3共享前缀和完成态回收决定搜索收益生产上应把 Beam Search 当预算化能力而不是默认开关更稳的做法是只在确实需要候选竞争的路由上启用 Beam Search再给它单独的分支预算。 比如字段抽取、短代码修复、受限格式生成这些场景往往受益明显开放式闲聊和高并发流式问答则更容易被分支常驻拖垮。 团队真正该盯的不只是命中率而是active_branch_ratio、finished_beam_stall_ms和shared_prefix_hit_rate这类指标。笔者认为未来3 - 6个月更成熟的推理平台不会把 Beam Search 视为统一默认值而会把它做成按请求类型、输出长度和资源余量动态启停的策略层。 如果系统回答不了“这次多花的 GPU 时间究竟被哪几条分支吃掉”它大概率还停留在糊涂账阶段。你们现在保的是结果稳定性还是在为无效分支持续付费图 4把 Beam Search 做成分支预算收益才会稳定落地