Skip to content

GitLab

"lib/llm/vscode:/vscode.git/clone" did not exist on "15b49818acdf328f098d6fb732b51193a0677d67"
Switch branch/tag
  1. 13 Feb, 2026 1 commit
  3. 02 Jan, 2026 1 commit
  5. 25 Nov, 2025 1 commit
  7. 21 Nov, 2025 1 commit
  9. 20 Nov, 2025 1 commit
  11. 11 Nov, 2025 1 commit
  13. 10 Nov, 2025 1 commit
  15. 08 Nov, 2025 1 commit
  17. 07 Nov, 2025 1 commit
  19. 30 Oct, 2025 1 commit
  21. 28 Oct, 2025 1 commit
  23. 24 Oct, 2025 1 commit
  25. 23 Oct, 2025 1 commit
  27. 10 Oct, 2025 1 commit
  29. 07 Oct, 2025 2 commits
  31. 01 Oct, 2025 1 commit
  33. 30 Sep, 2025 1 commit
  35. 16 Sep, 2025 1 commit
  37. 22 Aug, 2025 1 commit
  39. 22 Jul, 2025 1 commit
  41. 11 Jun, 2025 1 commit
  43. 19 May, 2025 1 commit
    • 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
  45. 29 Apr, 2025 1 commit
    • Graham King's avatar
      chore: Split PushRouter from Client (#817) · a1a10365
      Graham King authored 
      In a distributed system we don't know if the remote workers need pre-processing done ingress-side or not. Previously Client required us to decide this before discovering the remote endpoints, which was fine because pre-processing was worker-side.

As part of moving pre-processing back to ingress-side we need to split this into two steps:
- Client discovers the endpoints, and (later PR) will fetch their Model Deployment Card.
- PushRouter will use the Model Deployment Card to decide if they need pre-processing or not, which affects the types of the generic parameters.

Part of #743
      a1a10365