GitLab CI-Services mit GPU-Beschleunigung ermöglichen die nahtlose Integration von LLMs in DevOps-Pipelines, ohne dass zusätzliche Infrastruktur erforderlich ist.

Große Sprachmodelle (Large Language Models, LLMs) haben bei einer Reihe von natürlichsprachlichen Aufgaben bemerkenswerte Fähigkeiten bewiesen und erleichtern fortgeschrittene KI-Anwendungen mit natürlichsprachlichen Schnittstellen. Die Entwickler verwenden in der Regel vortrainierte proprietäre oder frei zugängliche¹lLMs, anstatt sie von Grund auf neu zu entwickeln, da für die Entwicklung und das Training dieser komplexen Modelle erhebliche Ressourcen, Daten und Fachkenntnisse erforderlich sind. Zu den gängigen Techniken für die Entwicklung von Anwendungen mit LLM gehören statisches Prompt-Engineering, um LLM-Antworten für gewünschte Ergebnisse mit ausgearbeiteten Anweisungen zu steuern.

LLM-Engineering umfasst häufig externe (Cloud-)Dienste wie verwaltete LLM-Inferenzendpunkte. Diese Architektur bringt für Entwickler eine erhebliche Komplexität mit sich, da die Bereitstellung von Diensten über Infrastructure as Code (IaC) und die sichere Zugriffsverwaltung über lokale Entwicklungsumgebungen und kontinuierliche Integrationspipelines (CI) erfolgt.

Dieser Artikel stellt einen neuartigen Ansatz für LLM-Engineering auf GitLab vor, indem CI-Dienste genutzt werden, um einen LLM-Inferenzserver für Integrationstests in einer CI-Pipeline auszuführen. Es erweitert einen vertrauten DevOps-Workflow mit minimalen Änderungen für LLM-Engineering, verwendet einen vollständig offenen Toolstack und erfordert keine zusätzliche Infrastruktur über GitLab hinaus. Ein Beispiel für die Effektivität ist die Entwicklung einer einfachen Python-Bibliothek, die einen LLM in einen Taschenrechner mit einer natürlichsprachlichen Schnittstelle verwandelt, und zwar durch eine Nullschuss-Eingabeaufforderung mit einer selbst erstellten Anweisung. Um produktionsreife Anwendungsfälle zu ermöglichen, haben wir GPU-Unterstützung für CI-Dienste in den GitLab Runner integriert (veröffentlicht mit GitLab Runner v17.10), um die LLM-Inferenz zu beschleunigen.

Grundierung

Container mit GPUs

Docker unterstützt NVIDIA GPU-Beschleunigung für containerisierte Anwendungen. Dazu müssen wir die Docker-Engine, die NVIDIA-GPU-Treiber und das NVIDIA Container Toolkit installieren, mit dem Docker eine Schnittstelle zu NVIDIA-GPUs herstellen kann. Dann können wir die --gpus Flagge des Docker-Container-Startbefehls verwenden, um die Anzahl oder Auswahl der GPUs anzugeben, die im Container verwendet werden sollen. Die Syntax lautet --gpus <string>, wobei <string> sein kann:

all: Weist dem Container alle verfügbaren GPUs zu.
device=<index>: Weist dem Container bestimmte GPUs zu, wobei <index> eine durch Komma getrennte Liste von GPU-Indizes (z. B. device=0 für die erste GPU) oder GPU UUIDs (z. B. device=GPU-ad2367dd-a40e-6b86-6fc3-c44a2cc92c7e) ist.

GitLab CI-Dienste

GitLab CI-Services sind Hilfscontainer, die während der Ausführung der CI-Pipeline neben dem Hauptauftragscontainer laufen. Dienste ergänzen die Laufzeitumgebung des CI-Jobs, indem sie notwendige Ressourcen für den Netzwerkzugriff bereitstellen, z. B. Datenbanken wie PostgreSQL, Caches wie Redis, Test-Frameworks wie Playwright oder Build-Dienste wie Docker-in-Docker. Dieser Ansatz ermöglicht ein sauberes, isoliertes und in sich geschlossenes CI-Job-Setup, das die Erfahrung der Entwickler verbessert und die Korrektheit, Reproduzierbarkeit und Effizienz fördert.

GitLab CI-Dienste werden mit dem Schlüsselwort services in der Datei .gitlab-ci.yml definiert. Der folgende Ausschnitt definiert zum Beispiel einen PostgreSQL-Dienst auf Auftragsebene, der vom CI-Jobtest zum Erstellen einer Datenbank verwendet wird:

test: # ⚡️ Deaktivieren Sie den PostgreSQL-Passwortschutz, verwenden Sie ihn nicht in der Produktion!
  variablen: POSTGRES_HOST_AUTH_METHOD: trust # Dienstcontainer services: - postgres:17 # Hauptjob-Image: postgres:17 script: - psql -h postgres -U postgres -c "CREATE DATABASE my_db;"

Ollama

Ollama ist ein Open-Source-Framework für den Aufbau und Betrieb von LLMs auf lokaler Infrastruktur. Es bezieht Modelle aus der Ollama-Bibliothek, so dass Benutzer vorgefertigte Modelle herunterladen und lokal verwenden können. Darüber hinaus unterstützt es die Erstellung abgeleiteter Modelle durch Systemaufforderungen oder Feinabstimmung und ermöglicht so die Anpassung an spezifische Anforderungen. Ollama stellt auch Modelle für Inferenzen über eine HTTP-API bereit, was die Integration mit anderen Anwendungen erleichtert und Antworten auf Abfragen in Echtzeit liefert. Diese umfassende Verwaltung gewährleistet eine effiziente Bereitstellung und Nutzung der LLM.

Um Ollama zu benutzen, starten Sie den Server:

# CLI
ollama serve

# Docker (CPU only)
docker container run -d --name ollama -p 11434:11434 -v ollama:/root/.ollama ollama/ollama:0.6.3

# Docker (with GPU)
docker container run -d --name ollama -p 11434:11434 -v ollama:/root/.ollama --gpus all ollama/ollama:0.6.3

Ziehen Sie dann z. B. ein Modell (z. B. den Phi-3 Mini von Microsoft)

# CLI
ollama pull phi3:mini

# API
curl -sS localhost:11434/api/pull -d '{"model": "phi3:mini"}'

und senden Sie eine Chat-Nachricht:

# CLI
ollama run phi3:mini "Hello world"

# API
curl -sS localhost:11434/api/generate -d '{
  "model": "phi3:mini",
  "prompt": "Hello world",
  "stream": false
}'

LLM-Dienstleistungen über CI-Dienste

Anstatt sich auf extern gehostete LLMs für die Entwicklung und das Testen von LLM-infundierten Anwendungen zu verlassen, schlagen wir die Verwendung eines lokalen LLM-Inferenzservers sowohl für die lokale Entwicklung als auch für Integrationstests in einer CI-Pipeline vor. Ähnlich wie beim lokalen Betrieb des Ollama-Servers konfigurieren wir einen CI-Dienst, um den Ollama-Server als Hilfscontainer des CI-Jobs zu betreiben. Dazu fügen wir der Datei .gitlab-ci.yml eine CI-Job-Spezifikation hinzu, die in etwa wie folgt aussieht:

tests: services: - name: ollama/ollama:0.6.3 alias: ollama image: curlimages/curl before_script: | curl -sS http://ollama:11434/api/pull -d '{ "model": "phi3:mini" }' script: | curl -sS http://ollama:11434/api/generate -d '{ "model": "phi3:mini", "prompt": "Hello world", "stream": false }'

Standardmäßig leitet GitLab den Hostnamen eines CI-Dienstes aus dem Dienstnamen ab. Um den Hostnamen explizit und präzise zu überschreiben, verwenden wir den Alias-Schlüssel, der den Ollama-Server über http://ollama:11434 offenlegt .

Während einige LLMs leichtgewichtig genug sind, um Inferenzen auf CPUs zu ermöglichen, benötigen viele LLMs GPU-Beschleunigung, um praktikabel zu sein. Wir haben GPU-Unterstützung für CI-Dienste in den GitLab Runner eingebracht, so dass das vorgestellte CI-Setup eine breite Palette von realen Anwendungsfällen unterstützen kann. Ein GitLab-Runner-Administrator kann den GPU-Zugriff für CI-Dienste im [runners.docker]abschnitt der runner's config.tomldatei über die Einstellung service_gpus konfigurieren, die der Einstellung gpus entspricht:

[[runners]]
  (...)

  [runners.docker]
    (...)
    service_gpus = "all"

Auf Multi-GPU-Hosts gewährleisten Geräte-Pins mit Indizes oder UUIDs den exklusiven Zugriff auf GPUs pro Job. Darüber hinaus können GPUs vom Hauptauftragscontainer und den Service-Containern gemeinsam genutzt werden, indem beiden die gleichen Gerätepins zugewiesen werden:

[[runners]]
  (...)
  gpus = "device=<INDEX>"

  [runners.docker]
    (...)
    service_gpus = "device=<INDEX>"

Beispiel

Als Beispiel für die Effektivität des vorgestellten Ansatzes soll ein LLM in einen Taschenrechner mit einer natürlichsprachlichen Schnittstelle verwandelt werden, und zwar durch Zero-Shot-Prompting mit einem statisch erstellten Systemprompt. Dazu erstellen wir ein minimales Python-Projekt mit dem folgenden Dateisystem-Layout:

📁 src
└── 📁 llm_calc
    ├── 📄 __init__.py
    └── 📄 py.typed
📁 tests
├── 📄 conftest.py
└── 📄 test_calculate.py
📄 .gitlab-ci.yml
📄 pyproject.toml
📄 uv.lock

Zu Beginn füllen wir pyproject.toml mit den wichtigsten Projekt-Metadaten und Abhängigkeitsangaben:

[project]
name = "llm-calc"
version = "0.0.0"
requires-python = ">=3.10"
dependencies = ["ollama>=0.4.7", "pydantic>=2.11.1"]

[dependency-groups]
dev = ["pytest==8.3.5"]

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

Dann installieren wir die Abhängigkeiten in einer virtuellen Umgebung mit uv:

uV-Synchronisation

uv erstellt auch die Datei uv.lock, die die genauen Versionen der installierten Abhängigkeiten enthält, um reproduzierbare Umgebungen zu ermöglichen.

Als nächstes implementieren wir eine LLM-Rechenklasse in src/llm_calc/__init__.py, die die interne Verwendung eines LLM kapselt und eine einfache Schnittstelle für die Berechnung eines mathematischen Ausdrucks in natürlicher Sprache bietet:

from __future__ import annotations

from textwrap import dedent
from typing import Final
from typing import Literal
from typing import TypeAlias

import ollama
import pydantic


Response: TypeAlias = (
    int
    | float
    | Literal[
        "error:zero-division",
        "error:invalid-domain",
        "error:invalid-expression",
    ]
)

ResponseModel = pydantic.TypeAdapter[Response](Response)


class LLMCalculatorError(Exception):
    def __init__(self, prompt: str, message: str) -> None:
        super().__init__(message)
        self.prompt = prompt


class InvalidDomainError(LLMCalculatorError):
    def __init__(self, prompt: str) -> None:
        super().__init__(prompt, f"Invalid math domain: {prompt}")


class InvalidExpressionError(LLMCalculatorError):
    def __init__(self, prompt: str) -> None:
        super().__init__(prompt, f"Invalid expression: {prompt}")


class LLMCalculator:
    MODEL: Final[str] = "phi3:mini"

    INSTRUCTION: Final[str] = dedent(
        """
        Perform a mathemati

        To respond with an error, return one of the following literal strings:
        - "error:zero-division" if the prompt contains a division by zero
        - "error:invalid-domain" if the prompt contains a mathematical domain error
        - "error:invalid-expression" if the prompt is an invalid mathematical expression

        Calculate: 
        """
    )

    def __init__(self, client: ollama.Client | None = None) -> None:
        self._client = client or ollama.Client()

    def calculate(self, prompt: str) -> int | float:
        response = self._client.generate(
            self.MODEL,
            prompt,
            system=self.INSTRUCTION,
            options={"seed": 0},
            format=ResponseModel.json_schema(),
        )
        result = ResponseModel.validate_json(response.response)
        match result:
            case "error:zero-division":
                raise ZeroDivisionError(prompt)
            case "error:invalid-domain":
                raise InvalidDomainError(prompt)
            cas

Die Klasse LLMCalculator bietet eine einzige Methode, calculate, die eine Eingabeaufforderung des Benutzers als Eingabe annimmt und das numerische Ergebnis der Berechnung zurückgibt. Intern generiert die Berechnungsmethode eine strukturierte Antwort aus dem LLM, die sich an der Systemaufforderung orientiert und dem JSON-Schema entspricht, das aus dem Pydantic-Modell ResponseModel generiert wurde. Die Antwort wird dann mithilfe des ResponseModel-Modells geparst. Wenn eine der angegebenen und angewiesenen Fehlerreaktionen auftritt, wird eine entsprechende Ausnahme ausgelöst. Andernfalls wird das numerische Ergebnis zurückgegeben.

Um das erwartete Verhalten unseres LLM-basierten Rechners zu testen, fügen wir eine Testsuite in das Verzeichnis tests/ ein, die das pytest-Framework verwendet. Zu diesem Zweck implementieren wir Fixtures in tests/test_calculate.py, um einen Ollama-Client zu instanziieren und unsere ausgewählte LLM in der Setup-Phase der Testsuite zu verwenden:

from __future__ import annotations import ollama import pytest from llm_calc import LLMCalculator @pytest.fixture(scope="session") def client(request: pytest.FixtureRequest) -> ollama.Client: return ollama.Client(request.config.getoption("--ollama-host")) @pytest.fixture(scope="session", autouse=True) def pull_model(client: ollama.Client) -> None: client.pull(LLMCalculator.MODEL)

Die Client-Fixture wird durch die Option --ollama-host parametrisiert, die über ein entsprechendes Kommandozeilen-Flag, das in tests/conftest.py definiert ist, an die ausführbare Datei pytest übergeben wird, da die Testsuite lokal ausgeführt wird, wo der Hostname des Ollama-Servers localhost ist, und in einem CI-Job, wo der Hostname anders ist, wie wir später sehen werden:

from __future__ import annotations from typing import TYPE_CHECKING if TYPE_CHECKING: import pytest def pytest_addoption(parser: pytest.Parser) -> None: """Pytest Optionen Parser."""
    parser.addoption( "--ollama-host", action="store", default="localhost", help="Ollama server host" )

Schließlich fügen wir einen parametrisierten Testfall in die Datei tests/test_calculate.py ein, um das erwartete Verhalten für einige Benutzeraufforderungen sicherzustellen:

# ...

@pytest.mark.parametrize(
    ("prompt", "expected"),
    [
        ("3 plus 7", 10),
        ("123 minus 45", 78),
        ("10 divided by 2", 5),
        ("123 times 45", 5535),
    ],
)
def test_calculate(calculator: LLMCalculator, prompt: str, expected: int | float) -> None:
    result = calculator.calculate(prompt)
    assert result == expected

Darüber hinaus fügen wir einen weiteren parametrisierten Testfall in die Datei tests/test_calculate.py ein, um das erwartete Verhalten bei Benutzeraufforderungen sicherzustellen, die eine Ausnahme auslösen sollen:

# ...

from llm_calc import InvalidDomainError
from llm_calc import InvalidExpressionError
from llm_calc import LLMCalculatorError

# ...

@pytest.mark.parametrize(
    ("prompt", "exception_class"),
    [
        ("foo plus bar", InvalidExpressionError),
        ("Square root of -1", InvalidDomainError),
        ("One divided by zero", ZeroDivisionError),
    ],
)
def test_calculate_raises_error(
    calculator: LLMCalculator, prompt: str, exception_class: type[Exception]
) -> None:
    with pytest.raises(exception_class) as exc:
        calculator.calculate(prompt)
    if isinstance(exc, LLMCalculatorError):
        assert exc.value.prompt == prompt

Nun führen wir die Testsuite lokal aus:

uv run pytest # oder uv run pytest --ollama-host localhost

Schließlich fügen wir die folgende CI-Job-Spezifikation in die Datei .gitlab-ci.yml ein, um die Testsuite über GitLab CI auszuführen:

tests: services: - name: ollama/ollama:0.6.3 alias: ollama image: ghcr.io/astral-sh/uv:0.6.11-python3.13-bookworm-slim before_script: - uv sync --frozen script: - uv run pytest --ollama-host ollama

Die vollständige Implementierung dieses Beispiels finden Sie in unserem ergänzenden GitLab-Projekt.

Schlussfolgerung

Große Sprachmodelle (LLMs) haben sich zu einer transformativen Technologie entwickelt, die fortgeschrittene KI-Anwendungen mit natürlichsprachlichen Schnittstellen ermöglicht. Es gibt sowohl proprietäre als auch frei zugängliche LLMs, die jeweils unterschiedliche Vor- und Nachteile bieten. Wir stellen einen neuartigen Ansatz für LLM-Engineering vor, der die GitLab-CI-Dienste nutzt, um LLMs mit offenem Zugang innerhalb einer CI-Pipeline für Integrationstests bereitzustellen, was eine nahtlose Integration von LLMs in DevOps-Workflows ohne zusätzliche Infrastruktur ermöglicht. Darüber hinaus beschreiben wir, wie man den GPU-Zugriff für CI-Dienste aktiviert. Dies ist eine neue Funktion, die wir zu GitLab Runner beigetragen haben und die für den praktischen Einsatz vieler LLMs unerlässlich ist. Ein Beispielprojekt, bei dem es um das Prompting ohne Schüsse geht, zeigt die praktische Anwendung dieses Ansatzes.

Wenn Sie diesen Artikel nützlich finden, teilen Sie uns bitte Ihr Feedback und Ihre Erfahrungen über das Kommentarfeld unten mit. 🙏

We use open-access LLMs as an umbrella term to refer to open-source, open-weights, and restricted-weights LLMs under a single term. ↩︎