Skip to content

[FEAT] add log_metrics as Optuna trial user attrs#22

Merged
VincentG1234 merged 4 commits into
mainfrom
FEAT/optuna-user-attrs-log-metrics
May 19, 2026
Merged

[FEAT] add log_metrics as Optuna trial user attrs#22
VincentG1234 merged 4 commits into
mainfrom
FEAT/optuna-user-attrs-log-metrics

Conversation

@VincentG1234

@VincentG1234 VincentG1234 commented May 18, 2026

Copy link
Copy Markdown
Collaborator

Summary

Adds optional optimization.log_metrics so selected benchmark scalars are copied onto each optimization trial as Optuna user attributes (metric_<name>) for dashboard visibility, without affecting objectives or study.tell().

Motivation / context

Multi-objective runs already expose objectives in Optuna; teams still want extra latency/throughput snapshots in the dashboard for comparison and debugging without promoting every metric to an objective.

What changed

  • OptimizationConfig.log_metrics: optional list of identifiers validated against existing combined metric keys (same vocabulary as objectives).
  • StudyController: after a successful optimization trial, sets user attrs from detailed_metrics (float coercion, warnings when missing/non-numeric).
  • Example YAML comment documenting the feature.
  • Unit tests for log_metrics validation.

Testing

  • Unit tests (tests/core/test_optimization_config.py)
  • Local run / Optuna dashboard spot-check with a tiny study

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds an optional optimization.log_metrics configuration to persist selected benchmark scalars onto Optuna trials as user_attrs (metric_<name>), improving Optuna Dashboard visibility without affecting objective values or study.tell() behavior.

Changes:

  • Introduces OptimizationConfig.log_metrics with validation/normalization against the same combined metric identifier vocabulary used by objectives.
  • Extends StudyController to write metric_<name> user attributes from TrialResult.detailed_metrics (with float coercion and warnings on missing/non-numeric values).
  • Updates example config + documentation and adds unit tests for log_metrics validation.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
auto_tune_vllm/core/config.py Adds log_metrics field and validates entries against allowed combined metric identifiers.
auto_tune_vllm/core/study_controller.py Writes configured log_metrics values into Optuna trial user attributes after successful runs.
docs/configuration.md Documents log_metrics behavior, constraints, and an example configuration.
examples/study_config.yaml Shows how to configure log_metrics in the example study YAML.
tests/core/test_optimization_config.py Adds unit tests covering log_metrics defaulting and validation errors.
Comments suppressed due to low confidence (1)

examples/study_config.yaml:39

  • This PR also removes the gpu_memory_utilization parameter block from the example configuration, but the PR description doesn’t mention this change. If this removal is intentional, it would help to either note it in the PR description or keep the example parameter to avoid an unrelated diff in this feature-focused PR.
parameters:
  max_num_batched_tokens:
    enabled: true
    options: [1024, 2048, 10000]


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread examples/study_config.yaml Outdated
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
@VincentG1234 VincentG1234 merged commit 7c4da56 into main May 19, 2026
7 checks passed
@VincentG1234 VincentG1234 deleted the FEAT/optuna-user-attrs-log-metrics branch May 19, 2026 12:25
VincentG1234 added a commit that referenced this pull request May 20, 2026
## Summary
Add structured documentation for human maintainers and coding agents:
`AGENTS.md`, `.ai/context/`, `.ai/skills/`, and a user-facing
architecture guide with Mermaid diagrams. Link the new doc from README
and quick start. Align the local example YAML with vLLM V1 constraints.

## Why
The InseeFrLab fork needs a stable onboarding path for contributors and
agents (local backend focus, safe commands, known issues/PRs) without
reading the whole codebase. Architecture was previously only implicit in
code; diagrams improve onboarding and reviews.

## What changed
- `AGENTS.md` — entry point for agents (context files, skills, safe
commands).
- `.ai/context/` — repo map, execution flow, history, known issues,
current work snapshot, external links.
- `.ai/skills/` — pr-writer, pr-reviewer, test-writer, docs-writer,
architecture-diagrams.
- `docs/architecture.md` — end-to-end, layout, orchestration, trial
lifecycle, outputs (Mermaid).
- `README.md`, `docs/quick_start.md` — links to architecture doc.
- `examples/study_config_local_exec.yaml` — disable
`max_num_partial_prefills` (unsupported on V1; comment added).

## How tested
- [x] `ruff check .`
- [x] `pytest -v tests/`
- [x] Manual E2E (maintainer): not required (docs-only PR)

## Risks / limitations
- `.ai/context/current-work.md` is a point-in-time snapshot (open PRs
#13, #17, #21, #22); it will drift until refreshed after merges.
- Mermaid rendering depends on the viewer (GitHub, IDE); no runtime
behavior change except the example YAML default.

## Links
- (none — no issue closed)

Signed-off-by: Vincent Gimenes <vincent.gimenes@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants