1. 31 Dec, 2025 1 commit
  2. 19 Dec, 2025 1 commit
  3. 18 Dec, 2025 1 commit
  4. 11 Dec, 2025 1 commit
  5. 09 Dec, 2025 1 commit
  6. 02 Dec, 2025 1 commit
  7. 25 Nov, 2025 1 commit
  8. 13 Nov, 2025 2 commits
  9. 11 Nov, 2025 1 commit
  10. 08 Nov, 2025 1 commit
  11. 07 Nov, 2025 1 commit
  12. 27 Oct, 2025 1 commit
  13. 21 Oct, 2025 1 commit
  14. 16 Oct, 2025 1 commit
  15. 07 Oct, 2025 1 commit
  16. 16 Sep, 2025 1 commit
  17. 05 Sep, 2025 1 commit
  18. 03 Sep, 2025 3 commits
  19. 22 Aug, 2025 1 commit
  20. 19 Aug, 2025 1 commit
  21. 15 Aug, 2025 1 commit
  22. 14 Aug, 2025 1 commit
  23. 06 Aug, 2025 1 commit
  24. 30 Jun, 2025 1 commit
    • Graham King's avatar
      chore(dynamo-run): Refactor to library (#1687) · 92f06b0e
      Graham King authored
      Move much of what was in the `dynamo-run` crate into `dynamo-llm` so that everyone can use it.
      
      Example usage:
      
      1. Create a `LocalModel`:
      
      ```
          let local_model = LocalModelBuilder::default()
      	.model_path("Qwen/Qwen3-0.6B")
      	.http_port(8080)
      	.build().await?;
      ```
      
      2. Make an engine:
      
      ```
          let engine_config = EngineConfig::StaticFull {
      	engine: dynamo_engine_mistralrs::make_engine(&local_model).await?,
      	model: Box::new(local_model),
          };
      ```
      
      3. Connect it to an input and run it
      
      ```
          dynamo_llm::entrypoint::input::run_input(Input::Http, runtime, engine_config).await?;
      ```
      
      For https://github.com/ai-dynamo/dynamo/issues/1647
      
      Code Rabbit summary, thanks:
        * Introduced a flexible builder pattern for local model configuration, allowing advanced customization and easier initialization.
        * Added new input modes and unified input handling, supporting interactive chat, HTTP server, batch file, and distributed endpoint modes.
        * Centralized engine configuration and routing, enabling more extensible and maintainable engine management.
        * Simplified and modularized the codebase by moving input and engine logic into dedicated modules.
        * Replaced direct model construction with an asynchronous builder for improved clarity and extensibility.
        * Streamlined configuration and validation for flags and router settings.
        * Added validation to prevent incompatible input and output combinations in endpoint and dynamic modes.
      92f06b0e
  25. 26 Jun, 2025 1 commit
  26. 04 Jun, 2025 1 commit
  27. 02 Jun, 2025 2 commits
  28. 21 May, 2025 2 commits
  29. 19 May, 2025 2 commits
    • Graham King's avatar
      feat: Support multiple models on single ingress node (#1127) · aeb79e62
      Graham King authored
      We can now do this:
      
      - Node 1:
      
      ```
      dynamo-run in=http out=dyn
      ```
      
      - Node 2 and 3, two instances of component 'backend' in the nemotron_ultra pipeline:
      
      ```
      dynamo-run in=dyn://nemotron_ultra.backend.generate out=vllm /data/models/NemotronUltra
      ```
      
      - Node 4 and 5, two instances of the 'backend' component in nemotron_super pipeline:
      
      ```
      dynamo-run in=dyn://nemotron_super.backend.generate out=vllm /data/models/NemotronSuper
      ```
      
      The ingress node will discover all four instances and route correctly. We have been planning for this for a long time now.
      
      As part of this auto-discovery is now always `out=dyn`, with no extra URL parts. Previously it could only route to a single pipeline.
      
      Also:
      - Refactor endpoint / instance naming now that I understand them
      - Fix removing models when their instance stops.
      aeb79e62
    • Tom O'Brien's avatar
      feat: Add OpenAI Embeddings interface in rust lib (#1110) · 73fdfb8a
      Tom O'Brien authored
      Implements OpenAI embeddings (interface only).
      
      - Adds ModelType::Embedding
      - Adds OpenAI embedding request/response structs
      - Adds support for embedding model discovery
      73fdfb8a
  30. 15 May, 2025 2 commits
    • Graham King's avatar
      chore: Prevent duplicate components with different models. (#1103) · 641234cd
      Graham King authored
      Each namespace is for a single pipeline, so a component must be model-unique. The means we can have several components with the same name running the same model (data parallel), their traffic will be routed according to `--router-mode`, but we cannot have several components with the same name running different models.
      
      Add an `ensure_unique` check to prevent that happening.
      641234cd
    • Graham King's avatar
      fix: Fix default RouterMode value (#1092) · 889ab67e
      Graham King authored
      The Python bindings use the default value for RouterMode. Previously that was Random (good), but now it became None (bad).
      
      Remove the option and clean up the duplicate RouterMode. I was trying to avoid putting the `KV` enum in dynamo-runtime. Turns out adding those two characters gives us a healthy simplification, and restores the old default router value.
      
      Also clean up two noisy log messages when waiting for KV routing metrics to start in worker.
      889ab67e
  31. 14 May, 2025 1 commit
  32. 07 May, 2025 1 commit
  33. 06 May, 2025 1 commit
    • Graham King's avatar
      feat: dynamo-run <-> python interop (#934) · 99cd9d85
      Graham King authored
      Adding this to a Python script makes it register on the network so that `dynamo-run` can discover it and send it requests:
      ```
      from dynamo.llm import register_llm
      
      MODEL = "Qwen/Qwen2.5-0.5B-Instruct"
      await register_llm(endpoint, MODEL, 3)
      ```
      
      Full vllm example, with pre-processing in dynamo:
      - `dynamo-run in=text out=dyn://dynamo.backend.generate`
      - `cd lib/bindings/python/examples/hello_world`
      - `python server_vllm.py`
      
      This builds on top of the work to move pre-processor to ingress side. It means we can decouple Rust and Python using NATS as the bus.
      
      The `register_llm` call does this:
      
      - Download the model from HF if necessary
      - Load the model deployment card from the HF folder or extract from GGUF
      - Push the tokenizer config etc into NATS object store so ingress can access it from a different machine
      - Publish the model deployment card to ETCD
      99cd9d85