Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#101 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
git, python

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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:

Lenguaje dominante
Python
Estrellas
337
Forks
52
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ServiceNow/Fast-LLM

Todos los issues de ServiceNow/Fast-LLM

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.