执行摘要

• 一句话：迁移 GPTBigCode 和 Starcoder2 至 Transformers 后端
• 推荐动作：建议关注此 PR 的团队阅读 registry.py 的变更和提交历史，了解模型迁移到 Transformers 后端的通用策略和潜在陷阱（如 Conv1D、tp_plan）。此 PR 是 vLLM 逐步淘汰自定义模型实现的典型案例，值得参考，但使用者需验证 TP/PP 场景的兼容性。

功能与动机

这些架构（GPTBigCode 系列包括 StarCoder、SantaCoder，以及 Starcoder2）大约有 2 年历史，属于 vLLM 前 100 热门架构之外。维护重复的自定义实现成本高，且缺少对新特性（如量化、LoRA、PP、Eagle）的支持。迁移到 Transformers 后端可以同时解决这两个问题。

实现拆解

1. 删除模型实现文件：删除 vllm/model_executor/models/gpt_bigcode.py（339 行）和 vllm/model_executor/models/starcoder2.py（337 行），移除所有自定义类（如 GPTBigCodeAttention、Starcoder2ForCausalLM 等）。
2. 更新模型注册表：在 vllm/model_executor/models/registry.py 中，从 _MODEL_REGISTRY 字典移除 GPTBigCodeForCausalLM 和 Starcoder2ForCausalLM 条目，并在 _TRANSFORMERS_SUPPORTED_MODELS 中添加它们，指向 TransformersForCausalLM 后端。
3. 调整文档：在 docs/models/supported_models.md 中，将这两个模型从主模型表移到 Transformers 后端支持的表，并标注 LoRA ✅、PP ❌（GPTBigCode）或 ✅（Starcoder2）。
4. 更新 Pipeline Parallel 测试：在 tests/distributed/test_pipeline_parallel.py 中移除 bigcode/starcoder 测试条目，因为该模型通过 Transformers 后端运行时的 PP 行为可能需要单独验证。
5. 提交历史显示作者最初尝试迁移 GPT-2 和 GPT-J，但因 Transformers 后端不支持（如 GPT-2 的 Conv1D 层不支持 TP）而回退，最终只保留这两个模型。

关键文件：

• vllm/model_executor/models/gpt_bigcode.py（模块 模型实现；类别 source；类型 deletion；符号 GPTBigCodeAttention, init, forward, GPTBigMLP）: 删除整个 GPTBigCode 模型实现，包含注意力、MLP、模型类等所有自定义代码，是整个迁移的核心。
• vllm/model_executor/models/starcoder2.py（模块 模型实现；类别 source；类型 deletion；符号 Starcoder2Attention, init, forward, Starcoder2MLP）: 删除整个 Starcoder2 模型实现，包含注意力、MLP、DecoderLayer 等类，同样为核心变更。
• vllm/model_executor/models/registry.py（模块 模型注册；类别 source；类型 data-contract）: 模型注册表更新：移除旧映射，添加 Transformers 后端映射，是迁移的枢纽逻辑。
• tests/distributed/test_pipeline_parallel.py（模块 并行测试；类别 test；类型 test-coverage）: 移除 Starcoder 的 PP 测试用例，避免运行已迁移模型的旧测试。
• docs/models/supported_models.md（模块 文档；类别 docs；类型 documentation）: 文档更新，反映模型移至 Transformers 后端并更新支持状态。

关键符号：GPTBigCodeAttention.init, GPTBigCodeAttention.forward, GPTBigMLP.init, GPTBigCodeBlock.init, GPTBigCodeBlock.forward, GPTBigCodeModel.init, GPTBigCodeModel.forward, GPTBigCodeModel.load_weights, Starcoder2Attention.init, Starcoder2Attention.forward, Starcoder2MLP.init, Starcoder2DecoderLayer.init, Starcoder2DecoderLayer.forward, Starcoder2Model.init, Starcoder2Model.forward, Starcoder2ForCausalLM.init, Starcoder2ForCausalLM.forward

关键源码片段

vllm/model_executor/models/registry.py

模型注册表更新：移除旧映射，添加 Transformers 后端映射，是迁移的枢纽逻辑。

# vllm/model_executor/models/registry.py
# 从手动实现字典中移除（不再维护）
_MODEL_REGISTRY = {
    # ... 其他架构 ...
    # "GPTBigCodeForCausalLM": ("gpt_bigcode", "GPTBigCodeForCausalLM"), # 已删除
    # "Starcoder2ForCausalLM": ("starcoder2", "Starcoder2ForCausalLM"), # 已删除
    # ...
}
​
# 添加到 Transformers 后端支持列表
_TRANSFORMERS_SUPPORTED_MODELS = {
    # ... 已有模型 ...
    "GPTBigCodeForCausalLM": ("transformers", "TransformersForCausalLM"), # 新增迁移
    "SmolLM3ForCausalLM": ("transformers", "TransformersForCausalLM"),
    "Starcoder2ForCausalLM": ("transformers", "TransformersForCausalLM"), # 新增迁移
    # ...
}

评论区精华

• gemini-code-assist[bot] 指出 GPT-2 的 Conv1D 层不被 Transformers 后端的 TP 替换逻辑覆盖，若迁移 GPT-2 会破坏 TP > 1 的场景。这导致了作者回退 GPT-2 的迁移。

• chatgpt-codex-connector[bot] 提醒 Transformers 后端需要模型定义 tp_plan 和 supports_pp_plan 等属性，否则运行时可能出错。但最终 PR 通过了合并，说明 GPTBigCode 和 Starcoder2 的 HF 实现可能已定义这些属性，或者实际执行路径未触发该问题。

• GPT-2 Conv1D 与 TP 兼容性 (correctness): 作者回退了 GPT-2 的迁移，最终 PR 不涉及 GPT-2。

• Transformers 后端需要 tp_plan/pp_plan 属性 (design): PR 合并时未发现运行时错误，说明 GPTBigCode 和 Starcoder2 的 HF 实现可能已包含这些属性，或实际路径未触发。但缺乏明确测试。

风险与影响

• 风险：
  1. Transformers 后端兼容性：若 HF 的 GPTBigCode/Starcoder2 实现缺少 tp_plan 或 pp_plan，使用 TP/PP 时可能崩溃。虽然 PR 已合并，但缺乏明确的 CI 覆盖。
  2. PP 支持缺失：作者在最终 commit 中明确 GPTBigCodeForCausalLM 暂不支持 PP，用户若在 PP 场景使用该模型会失败。
  3. 功能回归：自定义实现中可能包含了一些非标准优化（如特殊的权重映射），切换到标准后端后可能丢失或导致精度差异。
  4. 测试覆盖不足：删除模型文件后，原有针对这些模型的单元测试可能失效，但未新增对应的后端测试。
     - 影响：对用户：两个架构的模型入口（型号名）不变，但内部实现切换。用户无需修改代码即可获得量化、LoRA 等新特性，但需注意 PP 支持状态。对系统：减少了约 680 行维护代码，降低了未来兼容性负担。对团队：模型迁移模式可复用，为后续迁移其他低使用率模型提供参考。影响范围：仅影响使用 GPTBigCode（含 StarCoder）和 Starcoder2 的用户，且行为基本兼容。
     - 风险标记：核心路径变更（删除文件）, PP 支持不完全, 缺少 TP/PP 兼容性自动化测试

关联脉络

• PR #47263 [Model] Remove AyaVision, MusicFlamingo: 同样涉及移除低使用率模型以减少维护，与本次迁移清理思路一致。
• PR #46806 Remove mantis: 同样属于模型清理，修改了同一文件 registry.py，反映了团队持续清理旧模型的趋势。