Skip to content

Improve inference success message #3136

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Improve inference success message #3136

wants to merge 1 commit into from

Conversation

co42
Copy link
Collaborator

@co42 co42 commented Mar 24, 2025

What does this PR do?

Makes the message useful without needing the spans

Copy link

@beurkinger beurkinger left a comment

Choose a reason for hiding this comment

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

👍

@co42 co42 requested a review from Narsil March 24, 2025 15:06
@Narsil
Copy link
Collaborator

Narsil commented Mar 24, 2025

This information is already in the trace (and therefore in the log message) Why do you want things in the log message itself ?

@beurkinger
Copy link

beurkinger commented Mar 25, 2025

@Narsil @co42 I'm not seeing the generated_text / generated_tokens fiels in the logs output on my side 🤔

If I'm not mistaken and the generated tokens info is not present, could we add it ? thank u!

@co42
Copy link
Collaborator Author

co42 commented Mar 25, 2025

@Narsil We are trying to have more concise logs in Endpoints but still have useful information, right now either we just display the message "Success" without anything else, or everything and there are 8 lines per log.

I would be nice to have a message with useful information and if you want to have more look at the extra fields

@Narsil
Copy link
Collaborator

Narsil commented Mar 25, 2025

I would be nice to have a message with useful information and if you want to have more look at the extra fields

Yes, but who gets to chose what merits a place in this log ?

Success is mostly enough if you're just looking for errors which is a valid case imho. The core thing, is that adding metrics in the log message, which are already included elsewhere is really bad imho, those metrics are already there, and in parsable format by existing log readers. Adding them again in the message just adds noise.

The truth is that what you want to see depends on what you are doing, there is no "good log". We have no issues looking at everything we want to see in production using log readers in the current format.

I'm pushing back on this because I don't want to have endless discussion about what's a good log message or not, not this one, nor any other one, at least not based on "verbosity" level of a given tool or how pretty it looks in a certain tool. There is just no correct answer.

What should drive the discussion, is how can you identify issues in production, can you understand what's going on in the system and can you solve issues when they occur at runtime. Currently I don't think this change helps any of that (because the information is already there)

@co42 co42 closed this Mar 25, 2025
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.

3 participants