[feat] Track Exact Fast-LLM Version in Training Outputs and wandb Logs

オープン
  • 何か問題がありますか？
#101 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
git, python
領域
devtools, machine-learning

調査の方向性

The payload names no source files, so start by finding where training output directories are created and where the wandb run is initialized. Derive the version from git describe --tags --dirty with a commit-hash fallback, then write it to fast_llm_version.txt, add it to the wandb config and a tag, and print it at startup. Done means a run's output directory and wandb run both show the version string. The thread has had no reply for about 646 days, so confirm the approach with maintainers before starting.

索引モデルが issue の本文から書いたものです。

説明

enhancement need update Priority

🧐 Problem Description

The version of Fast-LLM used for training is currently not easily accessible. While training job specs (e.g., Toolkit, Kubeflow) provide the image path/URL, references like ghcr.io/servicenow/fast-llm:latest don't indicate which commit or tagged version was used. This makes it difficult to trace back to the exact codebase version for a training run.

💡 Proposed Solution

Include a version string in the output directory of each training run and log it to wandb for visibility.

Details:
  • For tagged release commits, use the semantic version (e.g., v1.2.3).
  • For non-tagged commits, include the commit hash (e.g., abcdef1) and mark the build as "dirty" if uncommitted changes exist (e.g., abcdef1-dirty).
  • Example formats:
    • Tagged release: v1.2.3
    • Non-tagged commit: abcdef1
    • Modified tagged release: v1.2.3-dirty

This version string should:

  1. Be written to a file in the training output directory (e.g., fast_llm_version.txt).
  2. Be logged to wandb:
    • As part of the run configuration (wandb.init(config=...)).
    • As a standalone field (wandb.log).
    • Optionally, as a tag for easier filtering (wandb.init(tags=...)).
  3. Be shown in stdout logs.

🔄 Alternatives Considered

  1. Using container image tags in job specs:
    • Problem: Tags like latest are ambiguous. Job descriptions may not persist (e.g., they could be garbage-collected or lost when a Kubernetes instance is decommissioned).

📈 Potential Benefits

  • Reproducibility: Trace models back to the exact version of Fast-LLM used.
  • Transparency: Facilitates auditing and debugging of training runs.
  • Usability: Avoids manual tracking of version information.

📝 Additional Context

This feature aligns with best practices for software versioning and reproducibility. Common formats like semantic versioning (semver) and commit hashes are widely supported and easy to interpret.

Relevant references:

主要言語
Python
スター
337
フォーク
52
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ServiceNow/Fast-LLM のほかの issue

ServiceNow/Fast-LLM の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。