Skip to content

CUDA support - #5

Merged
dvcdsys merged 1 commit into
mainfrom
perf/indexing-improvements
Mar 17, 2026
Merged

CUDA support#5
dvcdsys merged 1 commit into
mainfrom
perf/indexing-improvements

Conversation

@dvcdsys

@dvcdsys dvcdsys commented Mar 17, 2026

Copy link
Copy Markdown
Owner

Title: Add CUDA GPU support for inference


What

Adds a separate CUDA Docker image that runs embedding inference on NVIDIA GPUs.

Why

CPU inference is significantly slower on large codebases. Servers with NVIDIA GPUs can run inference on GPU automatically — embeddings.py already has CUDA auto-detection in place, it just needed a proper CUDA
image to run in.

How

  • api/Dockerfile.cuda — Dockerfile based on nvidia/cuda:12.6.3-devel-ubuntu22.04 with Python 3.12 via deadsnakes PPA
  • api/requirements-cuda.txt — copy of dependencies with a note (torch 2.6+ includes CUDA wheels on linux/amd64 by default)
  • docker-compose.cuda.yml — Compose file with GPU reservation via NVIDIA Container Toolkit
  • portainer-stack-cuda.yml — stack for Portainer deployment
  • Makefile — new targets: server-docker-cuda, docker-build-cuda, docker-push-cuda
  • Removed onnxruntime / optimum from both requirements files and onnx_model_path from config — ONNX was never used
  • README — added Experimental section describing the CUDA image and host requirements

Published as dvcdsys/code-index:cuda. The CPU image :latest is unchanged.

Type of change

  • New feature
  • CI / infra

Checklist

  • Tested against a running API server
  • go vet ./... passes (CLI changes)
  • pytest tests/ passes (API changes)
  • No secrets or API keys committed

Note

Medium Risk
Adds a new CUDA-based container build/deploy path and changes Python dependencies, which could impact runtime packaging and deployment on GPU hosts. Core API logic is mostly unchanged but build/infra changes can break installs if misconfigured.

Overview
Adds an experimental NVIDIA GPU (CUDA) deployment option by introducing a new api/Dockerfile.cuda, docker-compose.cuda.yml, and portainer-stack-cuda.yml to run embedding inference on GPUs via the NVIDIA Container Toolkit.

Updates the Makefile with server-docker-cuda plus CUDA image build/push targets, and documents host requirements and usage in README.md. Also removes unused ONNX-related configuration/dependencies by dropping onnx_model_path from api/app/config.py and removing optimum/onnxruntime from api/requirements.txt.

Written by Cursor Bugbot for commit d725614. This will update automatically on new commits. Configure here.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Comment thread api/requirements-cuda.txt
pydantic-settings>=2.7
aiosqlite>=0.20
pathspec>=0.12
einops>=0.7

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Duplicated requirements file risks silent dependency drift

Medium Severity

requirements-cuda.txt is an exact copy of requirements.txt (all 11 dependency lines are identical). If a future change adds or updates a dependency in one file but not the other, the CUDA image silently breaks. The Dockerfile.cuda could simply COPY api/requirements.txt requirements.txt instead, eliminating the duplicate entirely. Any CUDA-specific packages could be added via a separate RUN pip install step or by using -r requirements.txt inside a minimal CUDA-only file.

Additional Locations (1)
Fix in Cursor Fix in Web

@dvcdsys
dvcdsys merged commit bbf61b9 into main Mar 17, 2026
5 checks passed
@dvcdsys
dvcdsys deleted the perf/indexing-improvements branch March 17, 2026 18:43
dvcdsys added a commit that referenced this pull request May 12, 2026
…dule

Previous backoff streak retried indefinitely with delay capped at 30m,
which meant a permanent GitHub outage produced ~48 polls per day per
server. Now a streak gives up after MaxBackoffAttempts (default 5) and
the next attempt is anchored to streakStart + Interval — i.e. the
regular 6h grid resumes from the FIRST attempt of the failed streak,
not from "now".

Worst case progression with defaults (Interval=6h, Initial=1m, Max=30m):
  attempt #1 fails              T = 0
  attempt #2 fails  (wait ~1m)  T = +1m
  attempt #3 fails  (wait ~2m)  T = +3m
  attempt #4 fails  (wait ~4m)  T = +7m
  attempt #5 fails  (wait ~8m)  T = +15m  → exhaust
  attempt #6 fires             T = T0 + 6h  (anchor)

Successful poll mid-streak resets attempt counter and wait reverts to
Interval. The "anchor from first attempt" choice keeps the long-term
schedule on its grid even when a streak ate up to ~30m of it; an
absurdly long streak (rare; needs Interval < BackoffMax × N) collapses
the wait to 0 and fires immediately, which is the only sensible
behaviour when we already overshot.

  - MaxBackoffAttempts surfaced on Config (default 5).
  - TestRunStreakExhaustedAnchorsToInterval covers the exhaust path:
    3 fails → anchored sleep → #4 fires near streakStart+Interval.
  - Existing TestRunBacksOffOnFailureThenResets unchanged (recovers
    after 2 fails, well below the cap).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
dvcdsys added a commit that referenced this pull request May 14, 2026
…projects

Two related correctness fixes:

1. POST /git-repos was not transactional — a failed gitrepos insert
   (e.g. UNIQUE violation under concurrent posts) left an orphan
   projects row in 'pending' that the dashboard couldn't surface for
   cleanup. The handler now tracks whether it created the project
   row and runs a compensating DeleteByHash on gitrepos failure.
   TestAddGitRepo_ConcurrentDuplicate_NoOrphan asserts the
   invariant: SELECT COUNT(*) FROM projects WHERE host_path = ?
   == 1 after two parallel posts.

2. workspaceprojects.Link checked precondition + did INSERT in two
   separate queries — race window where the project could be deleted
   between the SELECT and INSERT surfaced as a 500 instead of 404.
   Rewritten as a single INSERT ... SELECT ... WHERE EXISTS, with a
   follow-up diagnostic SELECT when RowsAffected == 0 to return the
   right 404/422 reason.

3. TestDeleteProject_CascadesGitRepoAndMembership now explicitly
   asserts SELECT COUNT(*) FROM workspace_projects WHERE
   project_path = ? == 0 (instead of relying on UNIQUE-retry
   inference).

Resolves Fix #5, #6, #15, #16.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
dvcdsys added a commit that referenced this pull request May 14, 2026
…projects

Two related correctness fixes:

1. POST /git-repos was not transactional — a failed gitrepos insert
   (e.g. UNIQUE violation under concurrent posts) left an orphan
   projects row in 'pending' that the dashboard couldn't surface for
   cleanup. The handler now tracks whether it created the project
   row and runs a compensating DeleteByHash on gitrepos failure.
   TestAddGitRepo_ConcurrentDuplicate_NoOrphan asserts the
   invariant: SELECT COUNT(*) FROM projects WHERE host_path = ?
   == 1 after two parallel posts.

2. workspaceprojects.Link checked precondition + did INSERT in two
   separate queries — race window where the project could be deleted
   between the SELECT and INSERT surfaced as a 500 instead of 404.
   Rewritten as a single INSERT ... SELECT ... WHERE EXISTS, with a
   follow-up diagnostic SELECT when RowsAffected == 0 to return the
   right 404/422 reason.

3. TestDeleteProject_CascadesGitRepoAndMembership now explicitly
   asserts SELECT COUNT(*) FROM workspace_projects WHERE
   project_path = ? == 0 (instead of relying on UNIQUE-retry
   inference).

Resolves Fix #5, #6, #15, #16.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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.

1 participant