Lizard-LLM

Von der Modelldatei zum Produkt

Lizard-LLM verbindet ein GGUF-Modell, einen Windows-Rechner und einen lokalen Inferenzdienst. Während meines Qendryx-Vertragsprojekts verantwortete ich Architektur und praktische Umsetzung: vom Modell-Onboarding über die Provider-Auswahl bis zu nativer Ausführung, Telemetrie und Wiederherstellung.

Problem und Einsatzkontext

Rechner unterscheiden sich in CPU-Funktionen, GPU-Backends und Speicherbudget. Die Parameterzahl allein beantwortet nicht, ob ein Modell zuverlässig läuft. Modellidentität, Kontextlänge, Quantisierung und unterstützter Ausführungspfad müssen vor der Aktivierung zusammenpassen.

Mein Beitrag

Ich verband den Anwendungsablauf mit der Laufzeit: Artefaktprüfung, Provider-Regeln, native Prozesssteuerung, Graphkonstruktion, Speicherberechnung und nachvollziehbares Serving. Produktbedienung und numerische Ausführung gehörten zur selben Entwicklungsverantwortung.

Systemarchitektur

Anwendung und lokale API liegen über Worker-Prozessen und Provider-Auswahl. Lizard Native und Caterpillar verfolgen unterschiedliche Ausführungsansätze. Caterpillar bildet Berechnungen als C++-Graphplan mit Allokation und Backend-Scheduling ab. Zum dokumentierten Prüfzeitpunkt war Caterpillar als stabil, Lizard Native als experimentell und Ostrich als isolierte Forschung eingestuft.

Technische Entscheidungen

Die Modellidentität bleibt mit den Ausführungsbedingungen verbunden. Eine gemeinsame Serving-Schnittstelle bedeutet keine identischen Provider-Interna. CPU-Kernels und D3D12-Ausführung benötigen explizite Fähigkeitsprüfungen. Graphplanung trennt die logische Berechnung von Platzierung und Allokation.

Implementierungsdetails

Die Laufzeitarbeit umfasst GGUF-Metadaten, Decoder-Graphen, quantisierte CPU-Kernels, D3D12-Dispatch, residente Gewichte und KV-Cache-Berechnung. Cache-Kosten hängen von Kontext, Schichten, Heads und Repräsentation ab. Die Ressourcenrechnung begründet eine rechnerbezogene Entscheidung statt einer pauschalen Zusage auf Basis des installierten RAM.

Herausforderungen im Betrieb

Ein gestarteter Prozess beweist keine Modellbereitschaft. Aktivierung, Anfrage, Abbruch und Beendigung benötigen unterschiedliche Zustände. Provider-Fehler oder Speichermangel sollen erklärbar bleiben und einen Wiederherstellungsweg bieten. Residenz und Synchronisierung müssen über die gesamte Anfrage bewertet werden.

Evaluation und Beobachtbarkeit

Ein Benchmark benötigt einen klaren Vertrag: Modellartefakt, Quantisierung, Hardware, Prompt, Kontext, Generierungslänge, Threads, Provider und Revision bleiben dokumentiert. Prefill und Decode, kaltes und warmes Verhalten sowie Korrektheit und Durchsatz sind getrennte Fragen.

Gemessene Nachweise

Das bereitgestellte Portfolio dokumentiert historische lokale Decode-Werte bis 9,67 Tokens pro Sekunde auf einem Intel i7-1165G7. Die korrigierte llama.cpp-Kontrolle blieb mit 12,50 Tokens pro Sekunde schneller. Das sind historische Ergebnisse unter den im Buch beschriebenen Bedingungen, keine neue Messkampagne oder allgemeine Rangliste. Methodik und Einschränkungen stehen auf PDF-Seiten 26–29.

Auch negative Ostrich-Ergebnisse bleiben erhalten: Im zitierten historischen Vergleich erreichte Per-Node-Dispatch 10,71 Tokens pro Sekunde gegenüber 10,14 im untersuchten Scheduling-Ansatz. Ein Experiment rechtfertigt nicht automatisch einen neuen Standard.

Technologiestack

C++, TypeScript, GGUF, quantisierte Kernels, D3D12, CPU/GPU-Routing, lokale Prozesssteuerung und eine OpenAI-kompatible Serving-Schnittstelle. Die Repository-Verweise im PDF benennen Implementierungsgrenzen und historische Aufzeichnungen.

Diagramme und Demonstrationen

Die Originalgrafiken zu Anwendungsschichten, Graphplanung und Leistung folgen unten. Produktfilme vermitteln das Produkt; sie ersetzen keine Benchmark-Daten. Das vollständige 40-seitige Portfolio enthält weitere Ausführungs-, Speicher- und Recovery-Diagramme.

Erkenntnisse und nächste Schritte

Der wesentliche Beitrag liegt in der Verbindung aus präziser Modellidentität, ausführbarem Hardwareplan und verständlichem Verhalten. Weitere Optimierung sollte die korrigierte Baseline erhalten, numerische Korrektheit prüfen und einzelne Scheduling- oder Speicherhypothesen untersuchen. Externe GPU-Berichte sind Kontext, keine Lizard-Messungen.