mcpField
M
model-pr-history-knowledge

model-pr-history-knowledge

github.com/bbuf開発1.1k53 回インストール今日更新
リポジトリ

model-pr-history-knowledge について

モデルファミリーとフレームワーク別に、モデルサービング最適化の履歴を PR 中心に整理したナレッジベースです。実装変更、検証結果、リスクを確認してからモデル固有の最適化を選べます。

主な機能

  1. 01フレームワークとモデルファミリーで検索
  2. 02モデルファミリー別の二言語ドキュメント
  3. 03調査済み PR 差分と実装パス
  4. 04履歴、検証結果、リスクの記録

活用シーン

  1. 01サービングパス修正前の過去事例確認
  2. 02プロファイラーの注目箇所に関する変更履歴の確認
  3. 03フレームワーク間の最適化履歴の比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/bbuf/ai-infra-auto-driven-skills --skill model-pr-history-knowledge

インストール後、Claude Code で/model-pr-history-knowledgeを入力して読み込まれたか確認します。

詳細

モデル PR 履歴ナレッジ

これは、モデル最適化の履歴をまとめた PR 主導のナレッジベースです。モデルごとのスキル集ではありません。各モデルファミリーには、調査済みの PR 差分、実装ファイルの網羅状況、タイムライン、変更ファイル、コード抜粋、検証およびリスクに関するメモを含む、英語と中国語のドキュメントが用意されています。

モデル固有のサービングパスにパッチを適用する前、最適化の対象を選ぶ際、またはフレームワークにすでに高速なパスがある理由を説明する際に参照してください。

過去の情報を現在のブランチに適用する場合は、メンテナンスされているソース契約を使用してください。レビュー/履歴コーパスにはそれぞれ独自の取得日があり、現在のディスパッチや数値のデフォルト値を保証するものではありません。カーネルを置き換える場合は、エンドツーエンドテストがカバレッジを提供していると判断する前に、実際のモデルで候補が実行されることを確認してください。

not a manual audit とラベル付けされた生成エントリは、PR の発見インベントリです。最適化に関する結論を出す前に、差分全体と現在の呼び出し元を確認してください。API ファイルの件数や抜粋だけでは、差分全体を網羅しているとは言えません。既存の手動監査メモは、元の日付のまま維持されています。

クエリ

このディレクトリからコマンドを実行してください:

python3 scripts/query.py --list
python3 scripts/query.py --framework sglang --model qwen3-core --paths-only
python3 scripts/query.py --framework sglang --model qwen3-core "fused qk norm rope"
python3 scripts/query.py --framework vllm "DeepSeek-V4 fused norm router" --limit 5
python3 scripts/query.py --framework tokenspeed qwen35 --paths-only

便利なオプション:

  • --framework sglang|vllm|tensorrt_llm|tokenspeed:対象を1つのサービングフレームワークに限定します。
  • --model <slug>:対象を1つのモデルファミリーのディレクトリに限定します。
  • --lang en|zh|both:英語、中国語、または両方のドキュメントを選択します。
  • --paths-only:抜粋を表示せず、読むべきドキュメントの正確なパスを出力します。
  • --limit N:検索結果の件数を制限します。

ワークフロー

  1. ユーザーのモデル ID、チェックポイントパス、または SGLang のソースパスからモデルファミリーのスラッグを推定します。不明な場合は、scripts/query.py "<model name>" を実行します。
  2. SGLang のパッチ作業では、まず該当する SGLang の履歴を読みます。vLLM、TensorRT-LLM、TokenSpeed が主な競合である場合、またはそのトレースから SGLang に高速パスがないことが示唆される場合は、競合の履歴も読みます。ドキュメントの冒頭に日付付きのメモ(ソースヘッドの更新、バックフィル監査、レビュー済みカーネル追記)がある場合は、最初に読んでください。生成されたタイムラインや以下のカードにはない、手動レビュー済みの背景情報が記載されています。
  3. 実行可能な根拠のみを抽出します:
    • モデルの実装ファイルとシンボル
    • ホットなソースパスを変更した PR
    • 以前の融合、オーバーラップ処理、量子化、MoE、アテンション、キャッシュ、サンプラー、ローダーの変更
    • 既知のギャップや未解決のサポート課題を説明する可能性のある、オープン/注視中の PR
    • PR カードから推測される検証レーンと回帰リスク
  4. 読んだパス、PR 番号、ソースファイル、および各項目が判断にどう影響したかを記した短いメモを、現在の実行成果物に保存します。たとえば、history/model-pr-history-notes.md に保存します。
  5. 最終回答に長い PR カードを転載しないでください。関連する実装やリスクを要約し、パスを引用してください。

モデルスラッグ

現在のフレームワーク:

  • sglang(45 ファミリー)
  • vllm(44 ファミリー)
  • tensorrt_llm(15 ファミリー)
  • tokenspeed(14 ファミリー)

現在のモデルファミリーのスラッグ:

deepseek-ocr, deepseek-ocr-2, deepseek-v3-r1, deepseek-v31, deepseek-v32,
deepseek-v4, deepseek-v41, dots3, ernie45, exaone4, gemma4, glm-vlm-ocr,
glm45, glm46-glm47, glm5-glm51, gpt-oss, hunyuan3-preview, hunyuan4, inkling,
intern-s1, internvl35, jina-reranker-m0, kimi, ling25, ling3, llada21,
llama31, llama33-70b, llama4, longcat-flash, mimo-v2-flash, minimax,
mistral-small-4, mixtral-quark-int4fp8-moe, moss-vl, nemotron-super,
qwen-vlm-omni-asr, qwen3-coder, qwen3-core, qwen3-next, qwen35, qwen36,
qwen38, qwen4-exp, ring25, step35, step37

利用可否はフレームワークごとに異なります。正確な情報は python3 scripts/query.py --list を参照してください。スラッグの重複に関するメモ:

  • deepseek-v4 には V4 の全 PR が含まれます。deepseek-v41 は同じファイル群のうち V4.1 に該当するものをまとめています(件名に V4.1 が含まれている必要があります)。DSV4.1 の作業では両方を確認してください。
  • glm5-glm51 には GLM-5、5.1、5.2、5.3-Flash(glm5_next、glm53_flash、GlmMoeDsa)が含まれます。
  • qwen4-exp は Qwen3.8-Flash-Next で使われる qwen4_exp モデルファイルを指します。qwen38 は Qwen3.8 のクックブックの範囲を追跡します。公開モデルの Qwen/Qwen3.8-27B は model_type=qwen3_5 なので、ローダーとカーネルの履歴は qwen35 にあります(vLLM には専用の qwen38 スラッグはありません)。
  • hunyuan4 は Hy4(hunyuan_v4/hy_v4)を指し、ling3 は BailingMoeV3 を指します。nemotron-super には Nemotron-H も含まれます。minimax には M2 と M3 が含まれます。kimi には K2、K2.5、K3、Linear、VL が含まれます。
  • TensorRT-LLM と TokenSpeed のドシエも、SGLang や vLLM と同じ方法で生成されます。日付付きの手書き更新メモは、ページの先頭に残されています。

最適化ワークフローの契約

プロファイリングまたは最適化のタスクでこのナレッジベースを使用する場合:

  • モデルの特定後、パッチの計画前に読みます。
  • 履歴のパスと重要な PR の根拠を実行メモに記録します(例: history/model-pr-history-notes.md)。
  • プロファイラーが既知のモデルパスを示した場合、新しいパッチを書く前に、そのファイルに関する過去の変更が履歴にあるか確認します。
  • 競合製品のほうが速い場合、性能差がカーネル固有だと決めつける前に、同じモデルファミリーとステージについて、その競合製品のモデル履歴を検索します。比較が最新のアップストリームの挙動に依存する場合は、対象のコミットに正確に合わせて、最新のソースと PR を確認します。

コメント