user2595/jetson-ai-ollama
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
accd61625cd3e1ae497eedefe93d7210e9bd138d
jetson-ai-ollama/docs/adr/0003-registry-pull-over-gguf.md
Tarik Moussa accd61625c docs(reconciliation): sync planning repo to ansible-eulernest reality 
Plan ↔ reality abgleich nach tatsächlicher Implementierung in ansible-eulernest:

- CONVENTIONS.md: 4 Profile (+ coder), Registry-Pull statt GGUF/DVC,
  SoT-Pointer auf ansible-eulernest, JP7.2 Source-Build-Note
- STATE.md: W2–W4 done (via ansible-eulernest), W1/W5/W6 dropped,
  N1–N3 (GPU-metric, benchmarks, smoke-tests) als nächste Schritte
- ROADMAP.md: Abgeschlossene Items referenzieren ansible-eulernest-Rollen;
  neue Items N1–N3 für verbleibende Arbeit
- manifests/requirements.md: R-03–R-06 done, R-02/R-07/R-08 drift
- docs/adr/0003: Registry-Pull > GGUF; ansible-eulernest als Impl-SoT
- sessions/2026-06-14-reconciliation.md: Session-Log

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-14 14:45:40 +02:00

2.7 KiB
Raw Blame History

0003 — Registry-Pull statt lokaler GGUFs; ansible-eulernest als Implementierungs-SoT

  • Status: accepted
  • Datum: 2026-06-14
  • Supersedes (partiell): ADR-0002 — nur die DVC=SoT-Klausel; die Kernentscheidung (nativer Ollama-Daemon, kein eigener Swapper) bleibt vollständig gültig.

Kontext

ADR-0002 sah vor: lokale GGUFs unter /opt/jetson-ai/models/, DVC als Modell-SoT, build-models.sh als reproduzierbare Build-Kette. Bei der tatsächlichen Inbetriebnahme des Jetson Orin Nano Super (JetPack 7.2, 2026-06) traten drei Faktoren auf:

  1. JP7.2 / sm_87-Problem: Der offizielle Ollama-Installer liefert CUDA-Bibliotheken ohne sm_87-Support → Ollama würde CPU-only laufen. Lösung: Source-Build (roles/ollama/tasks/build_jp72.yml) mit cmake -DCMAKE_CUDA_ARCHITECTURES=87. Dieser Aufwand hatte Priorität; DVC-Infrastruktur wurde verschoben.

  2. Iterative Einrichtung ohne DVC-Puffer: Die Implementierung lief direkt in ansible-eulernest; ein separates GGUF-Download + DVC-Tracking hätte mehrere GB Datenübertragung auf dem Jetson bedeutet, ohne klaren Nutzen für den Einzelbetrieb.

  3. Ollama-Registry als ausreichende Reproduzierbarkeit: Für Single-User-Betrieb (nicht Produktion, keine reproduzierbare Forschung) genügt base: qwen2.5:7b in group_vars/jetson/vars.yml. Ansible stellt sicher, dass dieselbe Konfiguration jederzeit neu eingespielt werden kann.

Entscheidung

Registry-Pull als Standard. ollama_profiles[].base in ansible-eulernest/group_vars/jetson/vars.yml ist die SoT für Modell-Identität. Kein GGUF-Download, kein DVC-Tracking in dieser Phase.

ansible-eulernest ist der Implementierungs-SoT. Dieses Repo (jetson-ai-ollama) bleibt Planungs- und Methodologie-Referenz; die live laufende Konfiguration wird ausschließlich über Ansible verwaltet.

Vier Profile statt drei. Das vierte Profil coder (qwen2.5-coder:7b, temp 0.3) wurde nach Fertigstellung der ci-ai-Gitea-Integration ergänzt — war zum Planungszeitpunkt noch nicht bekannt.

Konsequenzen

  • Vorteil: Kein GGUF-Download-Aufwand; Ansible-Idempotenz deckt Reproduzierbarkeit ab; schnelleres iteratives Deployment.
  • Risiko: Modell-Versionen sind unpinned (Ollama Registry kann sich ändern). Mitigation: Digest-Check im Pre-Demo-Checklist; N2 (Benchmark-Script) kann Regressionen erkennen.
  • GGUF-Pfad nicht permanent geschlossen: /opt/jetson-ai/models/ bleibt reserviert. Falls Versionspinning kritisch wird (z. B. für reproduzierbare Forschung mit codex-py), kann der GGUF+DVC-Weg nachgerüstet werden. Ein neues ADR wäre dann nötig.
  • N3 (Smoke-Tests) deckt R-09/R-10 ab — Verifikation bleibt als nächster Schritt offen (ROADMAP N3).