当前vllm/sequence.py中get_beam_search_score方法的实现似乎在计算beam分数时错误地将提示长度包含在序列长度中。这与huggingface和其他地方使用的标准方法相悖。
当前的实现是：

if seq_len is None:
            seq_len = self.get_len()
            # NOTE: HF implementation does not count the EOS token
            # towards the length, we align with that here for testing.
            if (eos_token_id is not None
                    and self.get_last_token_id() == eos_token_id):
                seq_len -= 1
        return self.get_cumulative_logprob() / (seq_len**length_penalty)

我认为如果get_len()返回生成的长度，那么这是正确的，但get_len()包括提示：

def get_len(self) -> int:
        return len(self.output_token_ids) + len(self.prompt_token_ids)

我通过研究beam搜索返回的结果发现了这个问题。令我惊讶的是，当第二个选项远远长得多，只比对数概率小一点时，短序列被选为最佳选择。现在我意识到原因是我的提示与生成相比相当长，因此长度惩罚没有正确应用。