-
Notifications
You must be signed in to change notification settings - Fork 538
libgemma API refactor - decouple from interactive repl demo specifics, add hello world example using libgemma #82
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
Conversation
… for intermediate computations, add `model` to EOT token
…s to remove InferenceArgs. TODO: update hello_world example after git commit hash is available for fetching
…LoaderArgs validation, revert ReplGemma EOT token behavior
Separate KV cache from GemmaImpl
…pdate git hash in CMakeLists.txt of hello world after push
…le, add convenience version of constructor (no uncompressed weights)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
// - Bundle runtime parameters as RuntimeConfig | ||
// - No threadpools within threadpools (inner_pool = dummy) | ||
// - All tokens accepted | ||
void GenerateGemma(Gemma& gemma, RuntimeConfig runtime_config, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A simplified interface seems useful. Maybe we should also move stream_token and gen inside RuntimeConfig? (Which we should pass by ref = RuntimeConfig&)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of this too, but decided for now to make stateful things more explicit for now. For example, say a user who's new to the code wants to make the randomness reproducible - it's implied what to do from this interface - seed the RNG that gets passed in.
Packing it inside RuntimeConfig adds a level of indirection + opacity - first they have to know or guess that there's an rng that is getting passed in (and not say, initialized somewhere internally), then know to check the internals of RuntimeConfig to find it, then find the place in application codebase where RuntimeConfig is constructed, and finally make the change.
Granted for us w'ere able to track this without too much cognitive overhead, but I want to try to keep things flatly legible as much as we can until other tradeoffs make it obviously needed+beneficial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable and fine for now :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
This PR refactors the library interfaces to facilitate multiple frontends / apps to make better use of libgemma. It removes coupling between the specific interactive interface of
run.cc
, it's set of CLI arguments and the core library API ingemma.h
andgemma.cc
. As a test of this library use case, we add a minimal usage example inexamples/hello_world/
with minimal setup to interact with the library interfaces.Minor:
See also: