KI Modellzoo

[Christoph M. (mchris)]

Es gibt mittlerweile tausende von KI-Modellen wie z.B. das neue Gemma 4:

https://huggingface.co/blog/gemma4

Beim Modell
Gemma 4 26B A4B
(mixture-of-experts with 4B activated/26B total parameters)

sind ja nur 4GB jeweils aktiv, wenn der "Experte" ausgewählt wurde.
Mir ist die Funktion da aber nicht ganz klar: wird erst geschaut, welche 
4GByte benötigt werden und dann diese 4GB zur Graphikkarte geschoben, 
wenn die weniger als 26GB Speicher hat?

[Christoph M. (mchris)]

Das Modell Granite von IBM scheint relativ neu und ist wohl besonders 
für Aufgaben mit wenig "Halluzinationen" geeignet:
https://ollama.com/library/granite4.1

[Poldy H. (poldy)]

Christoph M. schrieb:
> Es gibt mittlerweile
> Mir ist die Funktion da aber nicht ganz klar: wird erst geschaut, welche
> 4GByte benötigt werden und dann diese 4GB zur Graphikkarte geschoben,
> wenn die weniger als 26GB Speicher hat?

Leider nein, du brauchst mindestens 24GB Speicher bzw. 32GB, je nachdem 
welche Zahlenformate die GPU beherrscht.

Das Modell ist nur deutlich schneller, weil es nach der Auswahl des 
Experten nur noch 4B davon benutzt. Aber ob das jetzt der Durchbruch 
ist, da habe ich Zweifel.

[Christoph M. (mchris)]

Poldy H. schrieb:
> Leider nein, du brauchst mindestens 24GB Speicher bzw. 32GB, je nachdem
> welche Zahlenformate die GPU beherrscht.

Danke für die Antwort.

Poldy H. schrieb:
> Aber ob das jetzt der Durchbruch
> ist, da habe ich Zweifel.

Wie meinst du das? Das Granite 4.1:8b müsste ja eigentlich mit der 8GB 
Karte laufen.

[1N 4. (1n4148)]

> sind ja nur 4GB jeweils aktiv, wenn der "Experte" ausgewählt wurde.
> Mir ist die Funktion da aber nicht ganz klar: wird erst geschaut, welche
> 4GByte benötigt werden und dann diese 4GB zur Graphikkarte geschoben,
> wenn die weniger als 26GB Speicher hat?

Nein, würde keinen Sinn machen bzw. lahm werden. Der Router im Modell 
entscheidet ja je Token welcher Expert zum Einsatz kommt (das betrifft 
nur das FFN im Transformer). Er müsste ggf. für jeden Token diese 4B aus 
dem Host-RAM nachladen. Wäre ein Trashing erster Klasse.

[Εrnst B. (ernst)]

So als Datenpunkt:
Gemma-4-26B-A4B-it bringt auf einer Radeon RX6700XT (Ja, ein paar 
Generationen hinten dran, 12GB VRam) etwa 20 Token/sec.
llama/Vulkan Backend.

Dabei verwendet die Grafikkarte ca. 10GB vom Host-RAM mit (GTT), über 
PCIe4×16, mit ca. 1/10 der Bandbreite vom VRam.

Qwen3.5-9B läuft mit ca. 52 Token/sec deutlich schneller, passt auch 
besser auf die Grafikkarte.

Qualität der Antworten scheint bei beiden gut, hab aber nix 
kompliziertes getestet.

[Christoph M. (mchris)]

Die Modell herunter zu laden dauert ewig, insbesondere die 30GB und 
größeren.
Eigentlich habe ich schon ein paar Modelle mit ollama heruntergeladen 
und würde diese gerne mit llama.cpp ausprobieren, aber es scheint ein 
Problem zu geben: Das Format scheint nicht zu passen. llama-cpp braucht 
die gguf-files während ollama irgend ein anderes Format hat. Also 
nochmal 30GB runter laden?

[Christoph M. (mchris)]

Hat jemand Erfahrung mit dem Modell Quen-Coder? Die Code-Entwicklung 
dürfte ja der interessantes Fall für die KI-Anwendungen im MC-Netz sein.

https://ollama.com/library/qwen3-coder

Es gibt hier ja ein gerade noch so "handlebares Modell" mit 30GB wobei 
die richtigen Modell 480GB haben, was auf der heimischen Hardware 
wahrscheinlich eher schwierig wird.

[Εrnst B. (ernst)]

Christoph M. schrieb:
> Also nochmal 30GB runter laden?

ollama verwendet llama.cpp intern, das Fileformat ist dasselbe. Ollama 
organisiert die Dateien nur anders, hat noch Zusatz-Infos in seperaten 
Files usw.
Und "versteckt" die Dateinamen hinter SHA-Summen.

schau mal in die kleinen Dateien, die da angelegt werden, das sind 
Einstellungen:

{"temperature":1,"top_k":64,"top_p":0.95}

Oder Informationen, welches File die eigentliche GGUF-Datei ist:

{
  "model_format": "gguf",
  "model_family": "gemma4",
  "model_families": [
    "gemma4"
  ],
  "model_type": "5.1B",
  "file_type": "Q4_K_M",
  "renderer": "gemma4",
  "parser": "gemma4",
  "requires": "0.20.0",
  "architecture": "amd64",
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:4e30e2665218745ef463f722c0bf86be0cab6ee676320f1cfadf91e989107448",
      "sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2",
      "sha256:56380ca2ab89f1f68c283f4d50863c0bcab52ae3f1b9a88e4ab5617b176f71a3"
    ]
  }
}

Die drei Dateien schaust du an, eins ist das Lizenzfile, eins die 
Settings, und das große ist das GGUF.

Symlink/Hardlink auf gemma4_5B_Q4_K_M.gguf erstellen.

[1N 4. (1n4148)]

> Hat jemand Erfahrung mit dem Modell Quen-Coder? Die Code-Entwicklung
> dürfte ja der interessantes Fall für die KI-Anwendungen im MC-Netz sein.

Qwen3-Coder-Next: Für längere "Sessions" mit viel Tool-Calling und Long 
Text gut, für ZeroShot gibt es bessere.

[Christoph M. (mchris)]

1N 4. schrieb:
> ZeroShot gibt es bessere.

Welch würdest du da vorschlagen?

Ich habe gerade gesehen, dass Quen-Coder-Next kein "thinking" hat. Ob 
das dann gut funktioniert:
https://huggingface.co/Qwen/Qwen3-Coder-Next

[Christoph M. (mchris)]

Εrnst B. schrieb:
> Die drei Dateien schaust du an, eins ist das Lizenzfile, eins die
> Settings, und das große ist das GGUF.

Vielen Dank für deine Hilfe.

Langsam breitet sich ein File-Chaos auf meiner Platte aus.
Scheinbar werden die fetten Modell im versteckten Verzeichnis 
./cache/huggingface abgelegt.
Dort habe ich gerade das gefunden, das gguf ist schon ein Symlink:

~/.cache/huggingface/hub/models--unsloth--Qwen3.6-35B-A3B-GGUF/snapshots 
/a483e9e6cbd595906af30beda3187c2663a1118c/Qwen3.6-35B-A3B-UD-Q5_K_S.gguf

Wenn man aber nach einer NVIDIA-Installationsanleitung ausgeht
https://build.nvidia.com/spark/llama-cpp/instructions
Sollen die Modelle in eine extra "~/model" Verzeichnis.

Wie organisiert man das am besten?

[Εrnst B. (ernst)]

Christoph M. schrieb:
> Wie organisiert man das am besten?

Frag die KI nach Vorschlägen :)

Bei ollama (docker) liegen bei mir die Models in ihrem eigenen 
docker-volume.

Ansonsten hat sich mit den Environment-Variablen "HF_HOME" und 
"HF_HUB_CACHE"
so ein Quasi-Standard entwickelt, den viele KI-Tools (zumindest die mit 
automatischem Download von HF) befolgen. (default ist 
~/.cache/huggingface/hub, hast du ja schon gefunden.)

Systemweite LLM-Server wie "lemond" von https://lemonade-server.ai haben 
nochmal eigene Storages unter /var/lib oder so.

[1N 4. (1n4148)]

> Welch würdest du da vorschlagen?

Dense, Thinking, z.b. Qwen3.6

> Ich habe gerade gesehen, dass Quen-Coder-Next kein "thinking" hat. Ob
> das dann gut funktioniert:

Ja. Funktioniert sehr gut in langlaufenden executive Tasks mit Tools, 
die Loop ist dann das qausi "Reasoning". Ein Dense drüber als 
Planner/Orchestrator, passt.

[Christoph M. (mchris)]

Ich finde es relativ aufwändig, die richtige Konfiguration um eine 
lokale Coding-KI zu bekommen.

Mein Setup: Ollama läuft in Docker auf einer anderen Maschine im lokalen 
Netz. Als erstes habe ich mit open-webui versucht, auf die Modelle 
zuzugreifen, aber das setup war relativ schwierig und das Ding will auch 
noch ein Passwort.

Nach etlichem hin und her hat das dann endlich funktioniert und es ist 
mir tatsächlich gelungen mit dem lokalen quen-coder eine Webseite 
(Anhang) zu erstellen, mit Anfragen an die Modelle auf dem anderen 
Computer stellen kann.

Was leider überhaupt nicht geklappt hat, ist continuer in vscode so 
einzurichten, dass es meine lokalen Modelle benutzt.

[1N 4. (1n4148)]

> Ich finde es relativ aufwändig, die richtige Konfiguration um eine
> lokale Coding-KI zu bekommen.

Was erscheint dir daran aufwändig?

[Christoph M. (mchris)]

1N 4. schrieb:
>> Ich finde es relativ aufwändig, die richtige Konfiguration um
> eine
>> lokale Coding-KI zu bekommen.
>
> Was erscheint dir daran aufwändig?

Es hat schlicht nicht funktioniert.

Ich hatte die ~/.continue/config.yaml geändert aber continue war nicht 
dazu bewegen, das Modell in meinem lokalen Netzwerk anzuzeigen.

models:
  - title: Qwen Coder (30B)
    provider: ollama
    model: qwen3-coder:30b
    apiBase: http://192.168.178.52:11434

[1N 4. (1n4148)]

> models:
>   - title: Qwen Coder (30B)
>     provider: ollama
>     model: qwen3-coder:30b
>     apiBase: http://192.168.178.52:11434

Sieht nach einem config für eine alte Continue Version aus?

name: Local Config
version: 1.0.0
schema: v1

models:
  - name: Qwen Coder (30B)
    provider: ollama
    model: qwen3-coder:30b
    apiBase: http://192.168.178.52:11434
    roles:
      - chat
      - edit

https://docs.continue.dev/guides/ollama-guide

[Christoph M. (mchris)]

1N 4. schrieb:
> Sieht nach einem config für eine alte Continue Version aus?

Super, das war es. Jetzt geht es. Ich danke dir.
Jetzt taucht das qwen-coder Modell auf der linken Seite auf und man kann 
sich dort durch fragen Code erstellen lassen. Das Chat-Fenster auf der 
rechten Seite will aber noch einen externen Agenten.

Gibt es irgendwo ein gutes Video für einen Überblick, wie continue 
bedient werden soll und was es kann? Ich habe bis jetzt immer nur 
ChatGPT mit manuellem Code kopieren benutzt.

Es scheint wohl noch einige Code Agenten Tools mehr zu geben, die 
externe lokale KIs nutzen können:
z.B.
- Opencode
- Claudcode
Da ist schon wieder die Frage, welches man am besten nimmt.

[Εrnst B. (ernst)]

Christoph M. schrieb:
> Da ist schon wieder die Frage, welches man am besten nimmt.

Die meisten sind Forks von VScode, und können dieselben Plugins 
verwenden.

Wenn du sowieso das "Continue"-Plugin verwenden willst, könntest du z.B. 
vscodium nehmen, das ist nicht von vornherein mit Github/Copilot 
verheiratet.

https://vscodium.com/

[1N 4. (1n4148)]

> Da ist schon wieder die Frage, welches man am besten nimmt.

Cline?

[Christoph M. (mchris)]

Was ist denn vom Modell "Step Flash" zu halten?

https://huggingface.co/stepfun-ai/Step-3.5-Flash

Es scheint wohl gut für "Agentic Coding" zu sein.

[Bernd (b_b304)]

Ich bin aktuell sehr glücklich mit
 - Graka: AMD 7900 XTX (24GB)
 - Modell: Qwen 3.6 35B A3B (belegt knapp 21 GB VRAM)
 - Runtime: llama.cpp vulkan + ROCM
 - IDE: OpenCode + VSCode

Das läuft mit ca. 130 Token/s und liefert relativ gute Ergebnisse. Einen 
großen Unterschied zum Github Copilot mit Opus 4.6, welches ich vorher 
benutzt habe, merke ich nicht (außer natürlich dem Preis :-D). Reicht 
für meine Privatprojekte vollkommen aus.

[Christoph M. (mchris)]

Εrnst B. schrieb:
> Wenn du sowieso das "Continue"-Plugin verwenden willst, könntest du z.B.
> vscodium nehmen, das ist nicht von vornherein mit Github/Copilot
> verheiratet.
>
> https://vscodium.com/

Die Beschreibungen zu vscodium klingen recht gut. Insbesondere wusste 
ich nicht, das Microsoft vscode compiliert und mit Telemetrie versieht.

Continue mit vscodium scheint grundsätzlich mit der vorigen config zu 
laufen. Allerdings macht es scheinbar kein "tool calling". Außerdem kann 
man für die unterschiedlichen Tätigkeite (code generation, chat, code 
completion) jeweils andere Agenten einstellen. Die Frage ist da: welche? 
ChatGPT schlägt llama3.1:8b vor, warum auch immer .. aber das passt ja 
gut zu dem Thema dieses Threads "Welches Modell aus dem Modellzoo?".

model: llama3.1:8b
capabilities:
  - tool_use

[Christoph M. (mchris)]

Mit MTP (Multi-Token-Prediction) scheint sich das llama Modell ziemlich 
stark beschleunigen zu lassen. Hat da jemand von euch schon was 
probiert?
Man kann die gguf-Files wohl irgendwie konvertieren.
Hier ist ein Beispiel gguf, welches deutlich schneller laufen soll:
https://huggingface.co/am17an/Qwen3.6-27B-MTP-GGUF

Diese Grundlagen habe ich dazu gefunden:
https://ai.google.dev/gemma/docs/mtp/mtp

[Ein T. (ein_typ)]

Εrnst B. schrieb:
> Wenn du sowieso das "Continue"-Plugin verwenden willst, könntest du z.B.
> vscodium nehmen, das ist nicht von vornherein mit Github/Copilot
> verheiratet.

Es ist allerdings lizenzrechtlich möglicherweise problematisch, weil MS 
einen sehr "cleveren" Betrug gefunden hat, um Wettbewerber 
auszuschließen.

[Ein T. (ein_typ)]

Christoph M. schrieb:
> Εrnst B. schrieb:
>> Wenn du sowieso das "Continue"-Plugin verwenden willst, könntest du z.B.
>> vscodium nehmen, das ist nicht von vornherein mit Github/Copilot
>> verheiratet.
>
> Die Beschreibungen zu vscodium klingen recht gut. Insbesondere wusste
> ich nicht, das Microsoft vscode compiliert und mit Telemetrie versieht.

Aber Vorsicht: viele Vscode-Erweiterungen dürfen aus Lizenzgründen nicht 
mit Vscodium benutzt werden, und einige sollen sogar die Arbeit 
verweigern, wenn die "Telemetrie"-Schnüffeltechnik nicht gefunden wird.

[Εrnst B. (ernst)]

Ein T. schrieb:
> Es ist allerdings lizenzrechtlich möglicherweise problematisch, weil MS
> einen sehr "cleveren" Betrug gefunden hat, um Wettbewerber
> auszuschließen.

Was meinst du?

Und vscodium ist kein Wettbewerber, das wird aus dem unveränderten 
Sourcecode, den Microsoft unter der MIT-Lizenz veröffentlicht, gebaut.

vscode ist sogesehen ein Fork von vscodium, nicht umgekehrt.

Ein T. schrieb:
> Aber Vorsicht: viele Vscode-Erweiterungen dürfen aus Lizenzgründen nicht
> mit Vscodium benutzt werden, und einige sollen sogar die Arbeit
> verweigern, wenn die "Telemetrie"-Schnüffeltechnik nicht gefunden wird.

Die meidet man dann lieber. Hier ging's um das "Continue"-Plugin, das 
ist unter der Apache-Lizenz OpenSource. Wenn da Telemetrie/Schnüffelei 
drinnen ist, kannst und darfst du die da rauspatchen.

[Ein T. (ein_typ)]

Εrnst B. schrieb:
> Ein T. schrieb:
>> Es ist allerdings lizenzrechtlich möglicherweise problematisch, weil MS
>> einen sehr "cleveren" Betrug gefunden hat, um Wettbewerber
>> auszuschließen.
>
> Was meinst du?

Na dies:

> Ein T. schrieb:
>> Aber Vorsicht: viele Vscode-Erweiterungen dürfen aus Lizenzgründen nicht
>> mit Vscodium benutzt werden, und einige sollen sogar die Arbeit
>> verweigern, wenn die "Telemetrie"-Schnüffeltechnik nicht gefunden wird.
>
> Die meidet man dann lieber. Hier ging's um das "Continue"-Plugin, das
> ist unter der Apache-Lizenz OpenSource. Wenn da Telemetrie/Schnüffelei
> drinnen ist, kannst und darfst du die da rauspatchen.

Wenn ich das richtig verstanden habe, ist "Continue" aber wohl nur für 
die Anbindung KI-gestützter Prüfungen verantwortlich. Ernsthafte 
Entwickler werden darüber hinaus aber vermutlich noch Erweiterungen für 
die gewünschte Sprache etc. verwenden wollen und müssen dabei sehr genau 
auf deren Lizenz achten, weil viele der beliebtesten Erweiterungen und 
insbesondere jene von Microsoft wohl nur mit Vscode und dessen 
Schnüffeltelemetrie ei benutzt werden dürfen. "Open Source" wird dort 
also offensichtlich nur zur Werben unbedarfter Nutzer mißbraucht, was 
zwei Fragen aufwirft: erstens, warum tut Microsoft das, außer um 
wirtschaftliche Vorteile aus dem Code ihrer Nutzer zu ziehen. Und 
zweitens, will ich mich verarschen lassen und Vscodium oder Vscode 
benutzen, obwohl es Hunderte oder Tausende Editoren und IDEs ohne 
derartige Schweinereien gibt?

Oder bekommen die Leute wirklich nicht mit, wie sie da verarscht werden? 
Das will mir irgendwie nicht in den Kopf, aber das liegt natürlich an 
mir.

[Christoph M. (mchris)]

Ein T. schrieb:
> Wenn ich das richtig verstanden habe, ist "Continue" aber wohl nur für
> die Anbindung KI-gestützter Prüfungen verantwortlich.

Nicht ganz:
https://www.youtube.com/watch?v=7AImkA96mE8
( ab Minute 6 )

[Christoph M. (mchris)]

Mittlerweile gibt es gefühlt 100derte KI-Coding-Tools. Die Frage ist, 
welches nutzen?
Im Moment teste ich gerade countinue, es hat umfangreiche Freatures.
https://www.youtube.com/watch?v=X8jLvslWo2k

Die Kommandozeilenversion erinnert ein wenig an Claude-Code. Für 
Claude-Code gibt es aber mittlerweile dank des Antrophic-Leaks auch 
schon wieder ein Open-Source Ersatz Claw-Code
https://claw-code.codes/
der wohl aber eher experimentell ist.

[Hans W. (hanswieland)]

Christoph M. schrieb:
> Die Frage ist, welches nutzen?

Was auch immer dir hilft. Und wenn du keine Zeit/Lust hast, dich durch 
zu probieren, dann warte einfach ab. Denn noch steckt das alles in den 
Kinderschuhen. In 10 Jahren haben wir vielleicht etwas Solides mit 
kalkulierbaren Kosten.

Mache dich nicht jetzt schon von etwas abhängig, was du dir bald 
womöglich nicht mehr leisten kannst. Aber ausprobieren ist OK.

[Ein T. (ein_typ)]

Christoph M. schrieb:
> Ein T. schrieb:
>> Wenn ich das richtig verstanden habe, ist "Continue" aber wohl nur für
>> die Anbindung KI-gestützter Prüfungen verantwortlich.
>
> Nicht ganz:
> https://www.youtube.com/watch?v=7AImkA96mE8
> ( ab Minute 6 )

Cool, lieben Dank für den Link. :-)

[Norbert (der_norbert)]

Christoph M. schrieb:
> Mittlerweile gibt es gefühlt 100derte KI-Coding-Tools. Die Frage ist,
> welches nutzen?

Während Villabajo noch das passende Spülmittel sucht, ist Villarriba 
schon mit dem Abwasch fertig. ;-)

[Christoph M. (mchris)]

Im Moment scheint mein continue nicht in der Lage, den Agent-Modus zu 
nutzen. Es kommt immer die Fehlermeldung, dass er die Files auf der 
Platte nicht lesen kann:

I apologize for the technical issues with reading the files. Let me check the structure of the project to understand what we're working with:

Continue listed files in .
Agent tool use
Continue tried to read

Hat jemand eine Idee, woran das liegt?

ChatGPT behauptet:

The key point:
Continue Agent mode currently works reliably mainly with OpenAI/Anthropic-style tool-calling models. Local Ollama models often fail exactly with the "Tool read not found" loop you see.

Was ziemlich schade wäre, wenn man local den Agentic-Mode nicht nutzen 
kann.

[1N 4. (1n4148)]

> Was ziemlich schade wäre, wenn man local den Agentic-Mode nicht nutzen
> kann.

Welches Modell?

[Christoph M. (mchris)]

1N 4. schrieb:
> Welches Modell?

Im Moment sind es diese:

name: Local Config
version: 1.0.0
schema: v1
models:
  - name: Qwen Coder (30B)
    provider: ollama
    model: qwen3-coder:30b
    apiBase: http://192.168.178.52:11434
    roles:
      - chat
      - edit

  - name: Qwen3.6
    provider: ollama
    model: qwen3.6:35b
    apiBase: http://192.168.178.52:11434
    roles:
      - chat
      - edit
      - apply

  - name: qwen2.5-coder
    provider: ollama
    model: qwen2.5-coder:7b
    apiBase: http://192.168.178.52:11434
    roles:
      - autocomplete

context:
  - provider: code
  - provider: docs
  - provider: diff

alle lokal im internen Netz über docker ollama. Vielleicht liegt es ja 
an  meiner config.yaml.

[Εrnst B. (ernst)]

Tools hast du aktiv? Ohne die kann die KI nicht auf die Dateien 
zugreifen.

Sollte Voreinstellung sein, hab bei mir nur ein paar von "Ask" auf 
"Automatic" gestellt.

Gestern getestet: ganz frische vscodium-installation, frisch das 
Continue-Plugin reingeladen, lokale API für die Modelle eingestellt, 
Modellen die Kontext-Length auf 128k hochgedreht, funktioniert.

Wegen nur 12GB VRam funktionieren bei mir nur 9G-Modelle gut, 
Gemma4-26B-A4B ist schon grenzwertig langsam.

"Qualität" ist mit den kleinen Modellen schon fragwürdig, bei einen 
Beispiel auf Arduino-Anfänger-Niveau (Blink) kommt er schon zwischen 
eigenem Code und "How it works"-Erklärung durcheinander.

Und, bin nicht sicher ob das auf dein qwen2.5-Coder zutrifft:
Wenn das Autocomplete-Model "Thinking" kann, wird es durch Abschalten 
davon deutlich reaktiver:

...
    roles:
      - autocomplete
    requestOptions:
      extraBodyProperties:
        think: false # turning off the thinking

[Christoph M. (mchris)]

Εrnst B. schrieb:
> Tools hast du aktiv? Ohne die kann die KI nicht auf die Dateien
> zugreifen.
> Sollte Voreinstellung sein, hab bei mir nur ein paar von "Ask" auf
> "Automatic" gestellt.

Sieht bei mir eigentlich ziemlich gleich aus.
Vielleicht könntest du deine config.yaml posten, dann kann ich es mit 
genau den gleichen Modellen versuchen.

Εrnst B. schrieb:
> "Qualität" ist mit den kleinen Modellen schon fragwürdig, bei einen
> Beispiel auf Arduino-Anfänger-Niveau (Blink) kommt er schon zwischen
> eigenem Code und "How it works"-Erklärung durcheinander.

Bernd behauptet ja, dass Qwen3.5 35B bei ihm so gut wie Claude Opus 4.6 
funktioniert.
Beitrag "Re: KI Modellzoo"
Das würde ich dann in continue probieren.

[Εrnst B. (ernst)]

Christoph M. schrieb:
> Vielleicht könntest du deine config.yaml posten, dann kann ich es mit
> genau den gleichen Modellen versuchen.

Da ist nicht viel dran:

name: Local Config
version: 1.0.0
schema: v1
models:
  - name: Autodetect
    provider: lemonade
    model: AUTODETECT
    apiBase: http://localhost:13305/api/v1/
  - name: Qwen3 without Thinking for Autocomplete
    provider: lemonade
    apiBase: http://localhost:13305/api/v1/
    model: Qwen3-4B-GGUF
    roles:
      - autocomplete
    requestOptions:
      extraBodyProperties:
        think: false # turning off the thinking

lemonade ist wie ollama ein Wrapper um llama-server, der sich um 
Model-Download&Verwaltung kümmert.
Mit dem Unterschied dass auch whisper.cpp und stable-diffusion mit dabei 
sind.
API für Text/Chat-AI ist dieselbe. Sollte also keinen Unterschied machen 
ob du ollama oder lemonade verwendest. Die Model-Namen sind aber 
unterschiedlich.

Erster Teil der Config wurde automatisch erstellt, das 
autocomplete-Model hab ich hinzugefügt.

Welche Models ich dann in Continue ausgewählt hab ist im Screenshot 
oben.

[Christoph M. (mchris)]

Εrnst B. schrieb:
> Da ist nicht viel dran:

Ich hätte gedacht da müssen noch die "roles"

    roles:
      - chat
      - edit
      - apply

definiert sein, damit alle Funktionen funktionieren.

[Christoph M. (mchris)]

Εrnst B. schrieb:
> Da ist nicht viel dran:

Das Autodetect scheint recht nützlich zu sein, weil man damit die 
Modelle in den verschiedenen Modi (chat, edit, agent) wählen kann.
Bei mir funktionieren die meisten Sachen jetzt, außer ich gebe im Agent 
Mode "schreibe einen Test" ein, dann wird wohl für python ein 
Packetmanager namens "Pixi" vermisst. Bis jetzt habe ich noch nie von 
"Pixi" gehört.

Ich habe die größeren Modelle mit 35B Parametern zur Verfügung (Spark 
DGX). Um die Ergebnisse mit dem obigen Arduino-Test zu vergleichen, 
bräuchte ich aber die exakten Prompts.

Ich bin mir noch nicht sicher, wie sinnvoll es ist, mit dem autocomplete 
zu arbeiten. Irgendwie nervt es, wenn das Modell ständig beim coden 
dazwischen quakt.

[Εrnst B. (ernst)]

Christoph M. schrieb:
> dann wird wohl für python ein
> Packetmanager namens "Pixi" vermisst

Das ist eine der wichtigsten Sachen beim Vibecoden: Achte darauf, was 
dir die KI an Dependencies reinziehen will.

Anweisung neue Abhängigkeiten zweimal zu überdenken und dann mit 
Begründung nachzufragen kann helfen. ("rules:" in der config.yaml)

[1N 4. (1n4148)]

> Ich habe die größeren Modelle mit 35B Parametern zur Verfügung (Spark
> DGX).

Ah, cool. Wie zufrieden bist du mit dem arm64 Umfeld außerhalb LLMs?

[Christoph M. (mchris)]

1N 4. schrieb:
> Ah, cool. Wie zufrieden bist du mit dem arm64 Umfeld außerhalb LLMs?

DGX wird scheinbar auch für die größeren Maschinen verwendet. Meine 
(geliehene) ist von Lenovo und heißt Thinkstation PGX. Zuerst dachte ich 
an einen großen Server, aber dieses Ding ist ein netter kleiner Mini-PC 
dessen Kantenlänge von ca. 15cm. Beim ersten Einloggen wird ein 
angepasstes Ubuntu mit ansprechendem Dark-Design installiert und läuft 
problemlos. Wenn das Ding nicht um die 4000€ kostete, würde ich es glatt 
als Desktop-PC verwenden.
Mit einem Klick lässt sich auch ein vordefiniertes JupiterLab mit KI 
Features aktivieren und es gibt haufenweise Tutorials. Für den Monitor 
hat es nur einen HDMI Ausgang und ich hab's mal einen Abend lang als 
ziemlich teures TV-Backend für die ARD-Mediathek laufen lassen. Firefox 
läuft natürlich ultra flott. LLamaCPP habe ich auf der Kiste selbst 
kompiliert, weil es ja ein 20 Core Arm ist .. hat ohne Probleme 
funktioniert.

Mittlerweile verwende ich die PGX aber remote, das dürfte auch der 
vorgesehene Einsatzzweck sein. Da ja Ubuntu zur Zeit auch Haufenweise 
Updates verlangt, habe ich die derweil ein paar mal durchgeführt. Einmal 
ist die PGX hängen geblieben und ich musst einen manuellen Powercycle 
machen. Das wäre natürlich ziemlich ungut, wenn man das Update wirklich 
aus weiter Ferne machen muss.
Die Thinkstation PGX hat keinerlei LED, an der man sehen könnte, ob sie 
mit Strom versorgt ist. Deshalb habe ich an einem der USB Anschlüsse 
einer dieser kleinen USB-Spannungs- und Stromanzeiger angesteckt. Das 
Netzteil habe ich in einem Stromzähleradapter gesteckt. Das ist extrem 
praktisch, weil man aus der Stromaufnahme ziemlich gut auf die aktuelle 
Rechenlast schließen kann. Maximal habe ich bis jetzt so um die 150 Watt 
gesehen. Wenn kein Modell und sonst nichts im Ubuntu läuft sind es 24 
Watt. Der Lüfter ist ultra leise. Das würde ich als großen Vorteil der 
PGX gegenüber einer RTX5070-TI mit ähnlicher Rechenleistung aber viel zu 
kleinem Speicher mit zu großer Stromaufnahme und zu lauten Lüftern 
sehen. Insgesamt gefällt mir die PGX sehr gut. Die Rechenleistung ist 
ausreichend, auch wenn ich mehr als die einer RTX5070-TI erwartet hätte. 
Allerdings muss man sagen, dass das Produktmanagement von NVIDIA extrem 
geschickt gearbeitet hat: Bei den günstiger RTX-Graphikarten ist immer 
der Speicher zu klein (die PGX hat ja 128GB und kann damit mehrere 
Modelle im Speiche halten) und will man höhere Geschwindigkeiten mit dem 
Speicher liegt man ruck zuck in der 10-40k€ Klasse der NVIDIA 
Beschleuniger.

[1N 4. (1n4148)]

> Die Rechenleistung ist
> ausreichend, auch wenn ich mehr als die einer RTX5070-TI erwartet hätte.

Nein, ist wie beim AMD Strix Halo: Der Speicher ist das Gute daran. Von 
der rohen Rechenleistung ist eine kleinere Grafikkarte oft schneller. 
Wobei die auch stark im Kurs gestiegen sind.

Deshalb ja auch die Frage wie gut das ARM-Umfeld ist, gerade da klemmts 
oftmals im Number Crunching Umfeld und man muss vieles selbst bauen und 
optimieren.