1. 23 Nov, 2024 2 commits
    • Rodrigo Ribeiro Gomes's avatar
    • Jesse Gross's avatar
      runner.go: Fix deadlock with many concurrent requests · 3478b2cf
      Jesse Gross authored
      If there are no avilable slots for new sequences then a request
      will not be added to the processing queue but will continue on
      to wait for a response that never comes. Besides never giving a
      response to the request, this prevents the model from being
      unloaded due to the outstanding request.
      
      To prevent this, there are semaphores that prevent more requests
      from being processed than there are slots - one in the Ollama
      server and one in the runner.
       - The Ollama server one works but it is not designed to protect
      the runner's data internal structures and the runner can return a
      final response before clearing its data structures.
       - The internal runner semaphore has similar behavior where it
       can release the semaphore when it issues a response. This is
       wrong - it should only release the semaphore after it has
       cleared the data structure.
      
      In addition, we should return an error if a slot is not found
      rather than deadlocking in the event we ever get to this spot.
      
      Fixes #7779
      3478b2cf
  2. 22 Nov, 2024 8 commits
  3. 21 Nov, 2024 28 commits
  4. 20 Nov, 2024 2 commits
    • Jesse Gross's avatar
      runner.go: Truncate inputs that exceed context rather than shifting · c4b34f2a
      Jesse Gross authored
      Previous versions of the runner would truncate inputs to the context
      window before beginning processing. The main processing loop relied
      on this behavior if the context needed to be shifted later (due to
      token generation). If truncation did not occur then invariants
      would be broken, causing crashes or infinite loops.
      
      Later versions attempted to fix these bugs and make the logic less
      subtle so that all inputs could be handled. Truncation was removed
      to make things consistent.
      
      However, truncation is much faster than processing and shifting, so
      removing it caused performance problems when the input vastly exceeded
      the context size. This restores the input truncation as a performance
      optimization while keeping the more robust processing logic.
      
      Fixes #7762
      c4b34f2a
    • Jesse Gross's avatar
      runner.go: Don't add inputs to cache view until actually processed · c3ff9164
      Jesse Gross authored
      We need to track which tokens are in the cache ourselves. We currently
      add tokens to the cache tracker when we add them to batch but they are
      not actually in the cache until we call Decode. This can cause
      confusion when we are shifting the cache.
      
      Avoids "could not find a KV slot for the batch" issues.
      
      Bug #7545
      c3ff9164