Hallo Forum, Vorweg: hier soll es um die Erfahrungen im Zusammenspiel verschiedener AI-Modelle mit Programmiersprachen und IDEs gehen. Dies ist nicht der richtige Thread für Kritik an AI-unterstütztem Coding, die Argumente sind ebenso oft wie ausführlich vorgetragen worden und wohlbekannt, und ich bitte darum, solche Kritiken den dafür vorgesehenen Threads wie diesem hier [1] vorzubehalten. Danke. Mich interessieren Eure Erfahrungen mit verschiedenen AI-Modellen, besonders im Zusammenspiel mit verschiedenen Programmiersprachen. Das betrifft vor allem die Aufwände für eine saubere Vorkonfiguration, das Prompting und die Überprüfung der Ergebnisse, die Qualität des erzeugten Code, und die Integration in verschiedene IDEs, als Emacs-User natürlich vor allem in diesen. Weiterhin interessiert mich, im welchem Umfang und welchem Kontext (Mikrocontroller, GUI-, Web- oder Systementwicklung) Eure Erfahrungen entstanden sind, ob Ihr dabei eine signifikante Steigerung Eurer Entwicklungsperformance Ihr erlebt habt, und wie hoch Ihr deren Umfang grob einschätzt. Ich persönlich habe bisher lediglich mit ChatGPT gespielt und mir Kommentare, Tests und Dokumentation erstellen lassen. Die Ergebnisse bedurften dabei stets einer genauen Kontrolle und meist einer mehr oder weniger umfangreichen Überarbeitung, haben meine Arbeit aber -- je nach Kontext und Aufgabe -- um einen Faktor von, grob geschätzt vier bis zehn beschleunigt. Vor allem interessieren mich Eure Erfahrungen mit offenen, lokalen Modellen, wie DeepSeek Coder, Qwen und Co im Vergleich zu kommerziellen Modellen wie CodeGPT oder Claude. Welches Modell habt Ihr dabei auf welcher Hardware genutzt, wie hat die Kombination performt, wie waren Eure Ergebnisse dabei, wieviel Vor- und Nacharbeit war dazu nötig? Nochmals: dies ist nicht der Ort für grundsätzliche Diskussionen oder für Kritik. Ich habe weder vor, das Denken zu verlernen, noch Aspekte wie die Stabilität, Sicherheit, Performance oder den Ressourcenbedarf meiner Software zu vernachlässigen. Beiträge, die aus meiner Sicht an meiner Frage vorbei gehen, werde ich melden und bitte unsere hochgeschätzten Moderatoren um deren Löschung. Vielen Dank. [1] https://www.mikrocontroller.net/topic/584204
Das ist doch alles gerade erst umfangreich durch gekaut worden. Für meine Arbeit kommen öffentliche KI System wegen dem Datenschutz nicht in Frage. Und wegen ungeklärtem Copyright kommt überhaupt kein KI System in Frage. Ein eigenes System wäre im Vergleich zum erwarteten Nutzen zudem zu teuer. Wie viel es wirklich nützt, kann ich aufgrund des Verbotes (von der Geschäftsführung) nicht ermitteln. Irgendwelche kleinen privaten Projekte eignen sich nicht zum Vergleich.
:
Bearbeitet durch User
Beitrag #8026175 wurde von einem Moderator gelöscht.
Beitrag #8026178 wurde von einem Moderator gelöscht.
Beitrag #8026180 wurde von einem Moderator gelöscht.
Hans W. schrieb: > Das ist doch alles gerade erst umfangreich durch gekaut worden. Du meinst sicher diesen Thread: Beitrag "Re: Programmieren mit KI" Der Thread ist mittlerweile aber ziemlich länglich und echte Erfahrungen sind über einzelne Posts der Beiträge verteilt.
Also ich hab gestern GitHub Copilot über IDE angewiesen in einem alten Projekt den Bluetooth Stack von Arduino ESP32 core 2.x (4.4) auf 3.0 (5.1) zu migrieren. VS Code hat ein bisschen technisch getan und alle Änderungen selbständig vorgenommen. Hab es kompiliert und geflashed, dann festgestellt das die BLE Authentication nicht mehr funktioniert, weil die statt korrekt zu migrieren einfach nur rausgelöscht wurde. Also Bluetooth funktionierte einfach ohne jede Sicherheit. Ergebnis: Ich mache es selbst.
:
Bearbeitet durch User
Christoph M. schrieb: > Der Thread ist mittlerweile aber ziemlich länglich und echte Erfahrungen > sind über einzelne Posts der Beiträge verteilt. Dann lass es von einer KI zusammenfassen.
Beitrag #8026290 wurde von einem Moderator gelöscht.
lol Sieben "Beiträge", und mit Ausnahme von ausgerechnet Alexander schafft es nicht einer davon, auf das Thema einzugehen. Ist das diese viel gepriesene "Natürliche Intelligenz", von der ich hörte? Sorry, aber das kann die AI viel besser als Ihr Spitzenhirne. Wow. :-)
Alexander schrieb: > Also ich hab gestern GitHub Copilot über IDE angewiesen in einem alten > Projekt den Bluetooth Stack von Arduino ESP32 core 2.x (4.4) auf 3.0 > (5.1) zu migrieren. VS Code hat ein bisschen technisch getan und alle > Änderungen selbständig vorgenommen. Hab es kompiliert und geflashed, > dann festgestellt das die BLE Authentication nicht mehr funktioniert, > weil die statt korrekt zu migrieren einfach nur rausgelöscht wurde. Also > Bluetooth funktionierte einfach ohne jede Sicherheit. > > Ergebnis: Ich mache es selbst. Und hast Du die KI dann darauf hingewiesen und es korrigieren lassen? Oder hast Du nach dem ersten Fehlversuch aufgehört? Welches Modell hast du benutzt? Claude Sonnet 4.6?
:
Bearbeitet durch User
Beitrag #8026457 wurde vom Autor gelöscht.
Hab mir den Code erstmal angeguckt. Es sieht alles richtig implementiert aus. Keine Ahnung was da los ist, muss ich noch mal mit dem alten Core testen.
Alexander schrieb: > Hab mir den Code erstmal angeguckt. Es sieht alles richtig > implementiert > aus. Keine Ahnung was da los ist, muss ich noch mal mit dem alten Core > testen. Ganz grundsätzlich liegen KI beim Coden meist ganz gut, aber sie schlampen im Detail - so meine Erfahrungen. Irgend eine Variable oder Klassen-Methode wird falsch benannt, ein falscher Datentyp hier ein ungültiger Parameter dort ... Un dann die bekloppten Entschuldigungen: "Ach ja, entschuldige, das ist ja so und so ... jetzt aber ganz wirklich ...". Aber auch das nicht immer. Ich lasse mir meist nur Algortihmen grundsätzlich erklären und code dann selbst, erscheint mir derzeit effektiver und ausserdem weiss ich dann auch wirklich, was passiert. Das ist mir wichtig.
Ich hab bisher nur Chatgpt und Grok benutzt. Für kleinere Codeabschnitte ist das OK. Es gibt da sicherlich besser geeignete Tools, aber darauf hab ich keinen Zugriff. Es ist erstaunlich, wie gut die Frage verstanden und wie geschickt eine Problemstellung gelöst wird. Ich bräuchte aber was, das ein Projekt in Gänze über mehrere Files hinweg überblicken kann und nicht einfach ab einer bestimmten Wortanzahl anfängt alles zu vereinfachen und wichtige Dinge wegzulassen.
M. D. schrieb: > Ich bräuchte aber was, das ein Projekt in Gänze über mehrere Files > hinweg überblicken kann und nicht einfach ab einer bestimmten Wortanzahl > anfängt alles zu vereinfachen und wichtige Dinge wegzulassen. Ich denke, das wird mit einem "klassischen" LLM alleine nie wirklich optimal. Was eine KI benötigt, um das Ding "rund" zu machen, sind m.E.: - ein wirklich großes Kontext-Fenster, um den Überblick zu behalten und sich morgen noch an das zu erinnern, was heute besprochen wurde - eine einstellbare "Temperatur" von Null, damit die Antworten deterministisch sind - einen Agenten an ihrer Seite, um den Code selbst zu testen und optimieren zu können - Zugriff auf aktuelle Sprach-Referenzen und Algorithmen-Sammlungen (Fachliteratur) - Zugriff auf archiverte eigene Projekte/Versionen, um Stil und Intentionen besser abzubilden und nicht völlig losgelöst drauflos zu fantasieren Mit OpenClaw (oder Ähnlichem) scheint sich ein Weg in diese Richtung anzudeuten ...
:
Bearbeitet durch User
Frank E. schrieb: > Ganz grundsätzlich liegen KI beim Coden meist ganz gut, aber sie > schlampen im Detail - so meine Erfahrungen. In dem Falle trifft die KI aber keine Schuld. Der Bug tritt mit Arduino‑ESP32 Core 2.x (IDF 4.4) nicht auf. ESP32 NodeMCU wird einfach nicht mehr gepflegt. OT: hab hier eine Lösung gefunden https://github.com/espressif/arduino-esp32/issues/11807
Ich nutze inzwischen immer häufiger Claude Code. Immer häufiger schlicht, weil es gut funktioniert. Angefangen habe ich mit kleinen Aufgaben, dass er mal einen Codeteil überprüfen soll, ob er da Bugs findet (hat er gefunden, inkl. Rechtschreibfehler und vertipper in den Kommantern, die dann auch gleich beseitigt werden), dann zum nachführen von Stil der einzelnen Modulen, so dass alle gleich sind. Schlussendlich nutze ich ihn nun auch um komplexere Aufgaben zu übergeben. Ein Protokoll anhand eines PDF zu implementieren ist ebenso möglich. Schlussendlich habe ich mehr Zeit für die Planung und Konzeption der Software, als dann mit der Fleissarbeit. Man kommt nicht darüber hinweg den Code auch selbst zu lesen und zu überprüfen, ob er jetzt die Datenblöcke richtig aufgeteilt hat, oder ob er auf dem Holzweg ist. Programmierfehler im Sinne von kein Free nach Malloc oder so habe ich jedenfalls noch nicht gesehen, was bei meinen Mitarbeitern ab und zu mal vorkommt. Alles in allem bin ich deutlich produktiver, man kommt aber nicht davon weg, dass man verstehen muss, was programmiert werden soll. Das ganze für Embedded C und C#
Für private Projekte nutze ich inzwischen fast nur noch Codex. Das Ergebnis: Meine Produktivität ist drastisch gestiegen. Ein Beispiel ist mein Sport-Laufband. Die originale App, mit der man Strecken, heutige Kilometer, gestrige Kilometer und ähnliche Daten loggen kann, sollte monatlich Geld kosten. Außerdem verliert das Laufband selbst alle Daten, sobald man nur eine kleine Pause machen muss. Codex hat mit weniger als zehn Eingaben von mir ein Programm geschrieben, das die Bluetooth-Daten des Laufbands auf ein ESP32-Display und zusätzlich per MQTT überträgt. Die Oberfläche sieht gut aus und es funktioniert. Ein weiteres Beispiel ist mein automatisierter SkyRC-Akkutester. Die Geräte können auch per Bluetooth mit einer App arbeiten. Meine Akkus haben Barcodes bekommen, und jede Messung eines Akkus wird jetzt per Barcode direkt in eine Datenbank geschrieben – inklusive einer netten Webseite im Docker-Container. Dafür hat Codex das ESP32-Programm, den Container, den Webserver und die Datenbank aufgesetzt. Aber noch viel schlimmer: Codex hat sogar das SkyRC-Protokoll selbstständig aus der Android-App extrahiert, weil es offenbar nirgends dokumentiert war. Mein eigener Aufwand lag bei vielleicht zwei Tagen, in denen ich ab und zu Befehle in Codex getippt und geschaut habe, was noch nicht richtig funktioniert. Ja, zugegeben: Ich habe keine Ahnung, wie diese Programme intern genau aussehen und ob sie optimal und sauber programmiert wurden. Aber ich hätte das alles von Hand niemals umgesetzt, weil mir dafür schlicht die Zeit fehlt.
Alexander schrieb: > ESP32 NodeMCU wird einfach nicht mehr gepflegt. Korrektur, NodeMCU wird nachgezogen. https://github.com/espressif/arduino-esp32/discussions/10991 > ### Stage 2: Moving to Nimble on ESP32 > > In Version 4.0 (to be released in 25/03/2026), even ESP32 will move from > Bluedroid to Nimble. This is a breaking change only for standard ESP32. Ich werde die VS Code KI in zwei Tagen noch mal darauf ansetzen.
:
Bearbeitet durch User
Hallo, lieben Dank für Eure Erfahrungen und Einschätzungen. Sehe ich das richtig, daß Ihr noch keine freien Modelle wie DeepSeek Coder oder Qwen ausprobiert habt?
Mir fallen da neben Lotta (mercedes) und Rene K. (xdraconix) nicht viele ein die sich geoutet haben die nötige Hardware zu besitzen. Beitrag "KI Hardware Anforderungen"
Alexander schrieb: > Mir fallen da neben Lotta (mercedes) und Rene K. (xdraconix) nicht viele > ein die sich geoutet haben die nötige Hardware zu besitzen. Frank E. hat dort auch einen relativ günstigen Server laufen: Beitrag "Re: KI Hardware Anforderungen" So richtig klar ist da aber leider nicht, wie gut ein LLM zur Programmierunterstützung dort läuft.
Christoph M. schrieb: > Alexander schrieb: >> Mir fallen da neben Lotta (mercedes) und Rene K. (xdraconix) nicht viele >> ein die sich geoutet haben die nötige Hardware zu besitzen. > > Frank E. hat dort auch einen relativ günstigen Server laufen: > Beitrag "Re: KI Hardware Anforderungen" > So richtig klar ist da aber leider nicht, wie gut ein LLM zur > Programmierunterstützung dort läuft. Lieben Dank für Euren Input. Sobald ich es zeitlich hinbekomme, werde ich die von Euch Erwähnten einmal anschreiben und sie darum bitten, ob sie vielleicht ihre Erfahrungen in diesem Thread teilen möchten. Aktuell bin ich ein bisschen... verloren angesichts der riesigen Vielfalt an Werkzeugen; die Modelle selbst sind dabei weniger das Problem, aber zwischen Ollama, OpenCode, OpenClaw und was es da nicht noch alles gibt. Zudem sehe ich, daß es zum Beispiel bei eBay etwas ältere Nvidia-M10 mit 32 GB VRAM für weniger als 200 Euro gibt, und ich frage mich, wie dieses Modell wohl in einem halbwegs modernen Rechner (Asus X570+, Ryzen 3800X, 64 GB DDR4-3200) halbwegs performen würde. Ich meine, okay, viel Speicher ist für die größeren Coding-LLMs sicherlich sinnvoll, aber nach meinen bisherigen Erfahrungen mit Machine Learning ist eine maximale Rechenleistung vor allem beim Training des Modells nützlich, während die Nutzung weniger anspruchsvoll ist.
Ein T. schrieb: > Zudem sehe ich, daß es zum Beispiel bei eBay etwas ältere Nvidia-M10 mit > 32 GB VRAM für weniger als 200 Euro gibt, Die besteht wohl aus 4GPUs mit je 8GB. Keine Ahnung, ob man die zusammen benutzen kann. https://www.reddit.com/r/homelab/comments/17wq8fj/nvidia_tesla_m10_good_for_anything/?show=original > und ich frage mich, wie dieses > Modell wohl in einem halbwegs modernen Rechner (Asus X570+, Ryzen 3800X, > 64 GB DDR4-3200) halbwegs performen würde. Ich meine, okay, viel > Speicher ist für die größeren Coding-LLMs sicherlich sinnvoll, aber nach > meinen bisherigen Erfahrungen mit Machine Learning ist eine maximale > Rechenleistung vor allem beim Training des Modells nützlich, während die > Nutzung weniger anspruchsvoll ist. Ja, bei den LLMs ist insbesondere die Speicherbandbreite wichtig. Da hat die M10 wohl 83GB/s pro GPU. Das ist für eine GPU eher wenig. Aber sie hat ja 4 davon. 330GB/s sind (im Vergleich zur CPU) ein guter Wert, aber natürlich nur, wenn man sie wirklich zusammen benutzen kann. https://www.techpowerup.com/gpu-specs/tesla-m10.c3035 Der AMD Ryzen™ AI Max+ PRO 395 macht so um die 200GB/s auf dem Speicher und man kann eben 128GB RAM reinmachen. Allerdings kostet so ein komplett neues System natürlich auch sehr viel mehr als 200€ für eine M10.
Die Tesla M10 hat 2560 Cuda-Cores: https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/tesla-m10/pdf/188359-Tesla-M10-DS-NV-Aug19-A4-fnl-Web.pdf Die RTX4090 hat 16384: https://www.spheron.network/blog/rtx-4090-for-ai-ml/ plus 512 Tensor Cores. Die Tesla M10 ist ausserdem nicht gut geeignet für Modelle mit kleiner Quantisierung (redit):
1 | M10 is Maxwell, quite old so lacking features like tensor cores for fast float16 compute, any support for bfloat16/TF32, not great for Plex (super old version of NVENC hardware), and would be quite energy inefficient and generally slow. |
Deshalb wird sie auch die Quantisierung Q4_K_M nicht können, welches ja hier die schnellen LLM-Modelle sind: Beitrag "Re: KI Hardware Anforderungen"
:
Bearbeitet durch User
Ein T. schrieb: > und ich frage mich, wie dieses > Modell wohl in einem halbwegs modernen Rechner (Asus X570+, Ryzen 3800X, > 64 GB DDR4-3200) halbwegs performen würde Du könntest mal versuchen, llma.cpp auf dem Rechner zu kompilieren und ein kleines Modell ganz ohne GPU laufen zu lassen: https://github.com/ggml-org/llama.cpp
Die Kollegen waren zufrieden, was das AI-Coding für zusätzliche Funktionen erzeugen konnte um diese im Reiter Quicksteps aufzurufen.
Christoph M. schrieb: > Die Tesla M10 hat 2560 Cuda-Cores: > https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/tesla-m10/pdf/188359-Tesla-M10-DS-NV-Aug19-A4-fnl-Web.pdf > Die RTX4090 hat 16384: > https://www.spheron.network/blog/rtx-4090-for-ai-ml/ > plus 512 Tensor Cores. Die RTX4090 kostet allerdings auch um den Faktor 10 mehr als die M10, und hat nicht die 32 GB RAM, die nötig sein sollen, um die größten Modelle zu laden. Die M10 ein altes Schätzchen (wobei: immerhin mit PCI3x16), das ist mir klar. Ich meine, ich mache nicht viel mit schneller Grafik, habe deswegen beim Kauf des Ryzen eine kleine Geforce GT 1030 genommen und lieber in CPU, RAM, NVMes und große HDDs investiert. Im Vergleich mit den 384 Cores der 1030 sind 2560 Cores der M10 um den Faktor 6,6_ und die 32 GB RAM der M10 sind immerhin den Faktor 16 mehr, insofern rechne ich schon mit spürbar mehr Leistung. ;-) > Die Tesla M10 ist ausserdem nicht gut geeignet für Modelle mit kleiner > Quantisierung (redit): >
1 | > M10 is Maxwell, quite old so lacking features like tensor cores for fast |
2 | > float16 compute, any support for bfloat16/TF32, not great for Plex |
3 | > (super old version of NVENC hardware), and would be quite energy |
4 | > inefficient and generally slow. |
5 | > |
Irgendwo habe ich gelesen, daß die Coding-LLMs auch mit deutlich weniger als float16 noch sehr gut arbeiten, eine Optimierung wollte das sogar auf float4 reduzieren. Leider habe ich vergessen, wo ich das gelesen habe. ;-( > Deshalb wird sie auch die Quantisierung Q4_K_M nicht können, welches ja > hier die schnellen LLM-Modelle sind: > Beitrag "Re: KI Hardware Anforderungen" Na, ich lasse das mal auf mich zukommen und harre dem mit Spannung. Wenn mir die Sache viel zu langsam wird, kann ich immer noch aufrüsten. ;-)
Der Vorteil von 8 und 4 Bit ist, dass man weniger Speicher braucht. Ein Netz mit 70 Milliarden Parametern brauchg bei 16bit halt 140GB RAM, bei 8Bit 70GB und bei 4Bit 35GB. Das kann durchaus ein Problem bei der alten Karte werden. Bei den modernen Netzen sind aber nicht unbedingt alle Parameter immer aktiv.
Die offenen Modelle gehen ja auch von winzig Modellen wie Qwen3.5:0.8b,
die auch auf nem Taschenrechner laufen über brauchbarere Modelle mit 9b
die noch auf 12GB Gaming GPUs gut laufen, oder mit 27b schon ne 5090
bräuchten, bis hin zu Rechenzentren Level Monstern mit 100b, 200b, 500b
und mehr Parametern.
Ausprobieren geht "ganz einfach", einfach auf ollama.com Ollama
runterladen, Modell aussuchen und in Opencode reinfrickeln. Hierzu
nochmal: Es gibt Mixture of Experts modelle, z.B. Qwen 3.5 35b-a3b. Das
hat zwar 35b Parameter, davon sind aber jeweils nur 3b aktiv. Es brauch
also Speicher wie ein 35b Modell, ist aber schnell wie ein 3b Modell.
Das hilft besonders, wenn das Modell nicht ganz auf die GPU passt.
Wer Romane schreiben will, der kann vermutlich auch eine alte Karte
kaufen. Text generieren braucht praktisch nur Speicherbandbreite. Text
verstehen braucht dagegen auch Rechenleistung. Und beim Coden muss ja
durchaus ständig Code gelesen, Compilerausgaben verarbeitet,
Fehlermeldungen eingelesen usw. werden. Ich behaupte mal, mit ner alten
Schrulle wird man da nicht glücklich.
Wer jetzt gar keine GPU hat, wirft lieber 10€ Richtung Openrouter. Da
sind praktisch alle Modelle verfügbar, natürlich jetzt von wem anders
gehostet. Damit macht man dann irgendein Beispielprojekt. Opencode hat
übrigens immer ein paar kostenlose Cloud Modelle dabei. Auch die sind
zum Testen gut geeignet. Das sind dann aber meistens aber schon Modelle
> 100b
Hilfts was?
Ich hab auch nur ne 16GB GPU. Mir ist kein sinnvolles lokales Coding
Modell bekannt. Ich hab jetzt gerade nebenbei Omnicoder 9b q8 laufen
lassen und Specs implementieren lassen, die bei nem anderen Test mal
angefallen sind. 10 Minuten später kompiliert das Projekt, funktionieren
tut aber nichts. Zwischendurch hat er 10x unterbrochen und ich musste
ihn motivieren weiter zu machen. Qwen3.5 9b konnte schon mit den Tools
nichts anfangen.
Vergleich dazu: Das in Opencode momentan kostenlose Mimo v2 Pro hat das
ganze in 3 Minuten ohne Nachfrage erledigt und funktioniert auf den
ersten Blick wie gewünscht. Das ist aber auch ein 1T Modell...
Wer nen 128GB Strix Halo oder Apple Rechner rumstehen hat, kann evtl mit
Qwen3.5-122B-A10B oder nemotron-3-super ganz gut arbeiten. Aber brennend
schnell sind die halt auch nicht. (Apple immerhin 2x so schnell wie
Strix Halo).
Mein Fazit:
- Lokale Modelle kann man ohne fette GPU vergessen. Ich wäre mir nicht
sicher, dass 32GB reichen. Ohne Cloud wird es schwierig.
- Es muss nicht unbedingt ChatGPT oder Claude sein. Die kostenlosen
Modell bei Opencode sind schon ganz gut. Wer kein Abo abschließen will,
kann die bei Openrouter pro Token bezahlen.
- Es gibt auch günstige Abos (afaik ab 3€), die mehrere Modelle bieten.
Wer nicht mega viel coded ist da sicher nicht schlecht aufgehoben.
- Je größer/komplexer das Projekt, desto besser muss das Modell sein.
Tja, wie ich schon sagte, man muss einfach das teuerste und groesste kaufen. :-D Selbst wenn man denkt man will nur rumspielen und vielleicht reicht dann erstmal zweite Liga, bei der Geschwindigkeit mit der sich da alles weiter entwickelt ist man mit der aktuell besten Hardware in sechs Monaten in der zweiten Liga angekommen... Vanye
Christoph M. schrieb: > Ein T. schrieb: >> und ich frage mich, wie dieses >> Modell wohl in einem halbwegs modernen Rechner (Asus X570+, Ryzen 3800X, >> 64 GB DDR4-3200) halbwegs performen würde > > Du könntest mal versuchen, llma.cpp auf dem Rechner zu kompilieren und > ein kleines Modell ganz ohne GPU laufen zu lassen: > https://github.com/ggml-org/llama.cpp Oh, lieben Dank für den Hinweis. Ja, der Hinweis, daß die Modelle wohl auch bereits portiert worden sein sollen, stand ebenfalls in dem obengenannten Artikel, den ich Blödmann leider nicht gebookmarkt habe -- allerdings sprach jener Artikel IIRC von C und nicht von Cpp.
Mathias M. schrieb: > Ausprobieren geht "ganz einfach", einfach auf ollama.com Ollama > runterladen, Modell aussuchen und in Opencode reinfrickeln... Ich muss jetzt mal explizit deinen ausführlichen und fundierten Beitrag aus der Praxis loben. Danke :-) Ein T. schrieb: > Christoph M. schrieb: >> Ein T. schrieb: >>> und ich frage mich, wie dieses >>> Modell wohl in einem halbwegs modernen Rechner (Asus X570+, Ryzen 3800X, >>> 64 GB DDR4-3200) halbwegs performen würde >> >> Du könntest mal versuchen, llma.cpp auf dem Rechner zu kompilieren und >> ein kleines Modell ganz ohne GPU laufen zu lassen: >> https://github.com/ggml-org/llama.cpp > > Oh, lieben Dank für den Hinweis. Ja, der Hinweis, daß die Modelle wohl > auch bereits portiert worden sein sollen, stand ebenfalls in dem > obengenannten Artikel, den ich Blödmann leider nicht gebookmarkt habe -- > allerdings sprach jener Artikel IIRC von C und nicht von Cpp. Gerade habe ich einen Simulator für Hardwarekonfiguration versus Modell gefunden, der ein Gefühl für die LLM-Geschwindigkeit vermittelt: https://laptime.run/ Leider ist dort das kleinste NVIDIA-Modell eine RTX3070Ti. Das kommt dann schnell an die Grenzen, weil die meisten Modelle mehr Speicher brauchen.
Mathias M. schrieb: > Text generieren braucht praktisch nur Speicherbandbreite. Text > verstehen braucht dagegen auch Rechenleistung. Puh... am Ende müssen die Word Embeddings aus dem Encoder ja durch das RNN, insofern wundert mich diese Aussage ein wenig. > Wer jetzt gar keine GPU hat, Hab' ich, aber mit der GeForce GT 1030 im Desktop und der GeForce 940MX im Laptop lassen sich zwar winzige Modelle mit Tensorflow und PyTorch machen, aber auch damit stoße ich regelmäßig an Grenzen. > Wer nen 128GB Strix Halo oder Apple Rechner rumstehen hat, Das ist -- neben den aktuell absurden Speicherpreisen -- der andere Aspekt, warum ich jetzt gerade noch keine größeren Summen investieren will. Aktuell ist extrem viel Bewegung im Markt, einerseits bei den Modellen, andererseits aber auch bei der Hardwareunterstützung. Mein Gefühl sagt mir, daß die alte Weisheit "sobald der Rechner zusammengebaut ist, ist er nur noch die Hälfte wert" aktuell noch verschärft ist, im Moment veraltet die Technik besonders hinsichtlich der AI-Unterstützung schneller denn je. Wenn der Preis dafür ist, daß ich eine Weile auf meinen Code warten muß: ok, damit kann ich leben, dann koche ich mir eben noch einen Kaffee. Boilerplate kann ein LLM vermutlich trotzdem viel schneller als ich, auch wenn es wegen veralteter Hardware nur langsam läuft. Ein AtTiny2313 kann sogar bei 1 MHz schneller und genauer rechnen als ich. :-) > Aber brennend schnell sind die halt auch nicht. Ich bin mir gar nicht mal so sicher, ob ich das brauche.
Wenn ich das lese bekomme ich ein ungutes Gefühl. Warum darf man LLM im Freeplan nutzen ohne einen Token zu bezahlen? (rhetorische Frage, bitte nicht antworten)
Ein T. schrieb: > lol Sieben "Beiträge", und mit Ausnahme von ausgerechnet Alexander > schafft es nicht einer davon, auf das Thema einzugehen. Ist das diese > viel gepriesene "Natürliche Intelligenz", von der ich hörte? Sorry, aber > das kann die AI viel besser als Ihr Spitzenhirne. Wow. :-) Man sollte nicht von sich auf andere schliessen.
Alexander schrieb: > Wenn ich das lese bekomme ich ein ungutes Gefühl. Warum darf man LLM im > Freeplan nutzen ohne einen Token zu bezahlen? Die Mimo v2 Modelle sind quasi Werbung für das Modell von Xiaomi. Die Anderen sind vertretbar klein und Werbung für deren Abodienst. Auf Duck.ai kannst du GPT-5 mini kostenlos nutzen. Duckduckgo wirbt ja gerade mit Privatsphäre. Das sind immer Mischkalkulationen. Aber meine 1B $ Codebase würde ich damit auch nicht verwurschteln wollen.
Ein T. schrieb: > Aktuell ist extrem viel Bewegung im Markt, einerseits bei den > Modellen, andererseits aber auch bei der Hardwareunterstützung. Mein > Gefühl sagt mir, daß die alte Weisheit "sobald der Rechner > zusammengebaut ist, ist er nur noch die Hälfte wert" aktuell noch > verschärft ist, im Moment veraltet die Technik besonders hinsichtlich > der AI-Unterstützung schneller denn je. Ich finde Hardware veraltet jetzt nicht soo schlimm. Nvidia unterstützt auch die alten Karten noch recht gut. Die M10 war aber schon immer ein Sonderfall. Man zahlt nur, was die Karte auch wert ist. Wer sich vor Jahren ne 3090 gekauft hat, packt da auch heute noch "viel" mit. Schnäppchen gibt es eigentlich nicht. AMD ist mit der Unterstützung seiner Karten nicht ganz so gut. Die Mi50 (32GB) ist tatsächlich abgekündigt. Dennoch teurer als die M10, weil die (noch) ganz passabel performt. Und nochmal zum Speed... Wenn dein Modell mit 3 t/s läuft und 100k Tokens verbraucht, sind das >9 Stunden. Oder eben ne Viertelstunde bei 100t/s. 9 Stunden sind halt auch ganz schnell 1-3€ Stromkosten. Für ein Einsteigermodell und bei 1-5k€ Hardwarekosten. Es muss schon die Firma muss schon genug springen lassen, damit du dir wenigstens 4-6 3090 in nen Server schrauben kannst, wenn du ernsthaft lokal was machen willst. Und dann bist du immernoch nicht bei den großen Modellen... Es war halt nie billig.
Keno von der ct3003 hatte vor 5 Monaten ein Video zur lokalen KI gemacht, bei dem er auch das Coding getestet hat. https://www.youtube.com/watch?v=ii8Npn8H2BQ In dem Video wird auch klar, warum die eher alte RTX3090 noch so teuer gehandelt wird: Da kann man mehrere in einen Rechner packen, die über den NVIDIA-Link gebündelt werden können. Unpraktischerweise hat NVIDIA diesen Link bei den neueren Modellen nicht mehr (ob da wohl ein paar Buisiness Developer am Werk waren .. )
:
Bearbeitet durch User
Christoph M. schrieb: > Keno von der ct3003 hatte vor 5 Monaten ein Video zur lokalen KI > gemacht, bei dem er auch das Coding getestet hat. Kurzer Vergleich: Keno hat auch ein Video zu OpenClaw gemacht und das mit Claude oder so - irgenein State-of-the-art Modell - verbunden. An einem Tag hat er Tokens für 100€ durchgezogen ... Gerade gabs nen Artikel, wo die Coder in den großen Firmen sich damit übertrumpfen Tokens für 100k$ pro Monat (ein Dev) zu verbraten...
Mathias M. schrieb: > Und nochmal zum Speed... Wenn dein Modell mit 3 t/s läuft und 100k > Tokens verbraucht, sind das >9 Stunden. Irgendwo im Netz hab ich von jemanden gelesen, der mit Llama auf fp16 6 t/s geschafft hat. Meine Hoffnung wäre nun, daß mit fp8 vielleicht bis zu 12 t/s möglich sein könnten... und wenn es mir zu lahm ist, wird sie vielleicht durch zwei P40 oder P100 ersetzt, aber dann... genau, das Netzteil. :-)
Ein T. schrieb: > Irgendwo im Netz hab ich von jemanden gelesen, der mit Llama auf fp16 6 > t/s geschafft hat. Meine Hoffnung wäre nun, daß mit fp8 vielleicht bis > zu 12 t/s möglich sein könnten... und wenn es mir zu lahm ist, wird sie > vielleicht durch zwei P40 oder P100 ersetzt, aber dann... genau, das > Netzteil. :-) Früher hieß das "Angeben", mit fetter Grafikkarte, eventuell 2 davon, Wasserkühlung, hohem FPS-Wert und modbedingte Sceenshots oder Videos in Spielen. Noch früher konnte man im Emax2 zwei Sounds per Algo verschmelzen. Die Rechnerei konnte mehrere Tage dauern, und das Ergebnis dann nur Hamsterhusten. Was hatten wir damals nicht alles gemacht, um irgendwie weiterzukommem.. (Ein paar Kilobyte Speicher waren damals auch furchtbar teuer)
:
Bearbeitet durch User
Gerade habe ich mal ollama auf meinem alten I5-2500Kx4 installiert und ein 1GB Modell laufen lassen:
1 | curl -fsSL https://ollama.com/install.sh | sh |
2 | |
3 | Kleines 1GB Modell holen: |
4 | |
5 | ollama pull qwen3.5:0.8b |
6 | |
7 | Modell laufen lassen: |
8 | |
9 | ollama run qwen3.5:0.8b |
>>> Can you create an Arduino blink programm?
Nicht ganz richtig, aber erstaunlich, dass der Code irgendwie in den
Trainingsdaten ist.
1 | Yes, absolutely! Here's a simple yet complete example of an Arduino-based |
2 | blink (toggle light) using an LCD display and the standard Arduino Uno |
3 | board. |
4 | |
5 | ## Arduino Blink Program
|
6 | |
7 | ```cpp |
8 | #include <Arduino.h> |
9 | |
10 | void setup() { |
11 | Serial.begin(9600); |
12 | |
13 | // Set the LCD display to clear and initialize
|
14 | lcd.clear(); |
15 | lcd.setCursor(0, 0); |
16 | lcd.print("Arduino Blink"); |
17 | lcd.print("\n"); |
18 | }
|
19 | |
20 | void loop() { |
21 | lcd.print("On"); |
22 | |
23 | // Toggle blink mode on/off
|
24 | digitalWrite(LED_A, !digitalRead(LED_A)); |
25 | |
26 | // Ensure the display updates after each blink
|
27 | delay(100); |
28 | }
|
29 | ```
|
Rbx schrieb: > Früher hieß das "Angeben", mit fetter Grafikkarte, Es ging um die M10. > Noch früher konnte man im Emax2 Wenn Du nichts beitragen kannst außer wirrem Gefasel über antikes Gerümpel, dann beschränke Dich in diesem Thread bitte auf das Lesen.
Da das nicht ganz in den Programmierthread passt, hier ein extra Thread für die Experimente mit dem kleinen quen3.5 Modell: Beitrag "lokale KI Experiment auf altem (LLM)"
Mathias M. schrieb: > Gerade gabs nen Artikel, wo die Coder in den großen Firmen sich damit > übertrumpfen Tokens für 100k$ pro Monat (ein Dev) zu verbraten... Welchen Artikel meinst Du?
> Es muss schon die Firma > muss schon genug springen lassen, damit du dir wenigstens 4-6 3090 in > nen Server schrauben kannst, wenn du ernsthaft lokal was machen willst. > Und dann bist du immernoch nicht bei den großen Modellen... Kenne einige KMU, die haben sich 2-4 Strix Halos geschnappt und betreiben damit erfolgreich produktiv ihren Model-Zoo. Die Kunst liegt darin, Agenten asynchron zu nutzen. Wer ständig nur auf eine Chatbot-Ausgabe wartet hat da was falsch verstanden.
Christoph M. schrieb: > Mathias M. schrieb: >> Gerade gabs nen Artikel, wo die Coder in den großen Firmen sich damit >> übertrumpfen Tokens für 100k$ pro Monat (ein Dev) zu verbraten... > > Welchen Artikel meinst Du? https://www.golem.de/news/tokenmaxxing-wer-verbraucht-die-meisten-ki-tokens-2603-206792.html
Alexander schrieb: > Mir fallen da neben Lotta (mercedes) und Rene K. (xdraconix) nicht viele > ein die sich geoutet haben die nötige Hardware zu besitzen. Gut, ich habe hier zu Hause einen Render-Server mit 4x RTX8000 stehen. Die werden, dank NVLink, als eine reine Karte mit 192GB VRAM, 2.300 Tensor-Cores 288 RTX-Cores und ~18.000 CUDA-Cores. Aaaaber, ich nutze den Server ausschließlich als Renderserver. Da läuft keine LLM oder sowas darauf. Obwohl auch Rendering mittlerweile mit generativer KI arbeitet - da hab ich aber absolut keinen Einblick drin. Ich freue mich nur, das selbst enorme Szenen als Video innerhalb weniger Stunden bis Minuten fertig gerendert sind, wo ich bei vor 5-6 Jahren noch mehrere Tage bis Wochen brauchte. Tatsächlich nutze ich aber KI zum Programmieren. Ich habe so einige Tests gefahren. Ich habe mich gerade mal hingesetzt und habe, selbstverständlich ausschließlich mit KI, eine Webseite erstellt um dort so nach und nach einige KI generierten Programme, Snippets und Firmware für Mikrocontroller zu zeigen. Ich habe fix mal ein Projekt eines RP2040 hochgeladen, dieses ist unter VS Code mit Copilot und Claude entstanden. Selbst eine LLM zu erstellen oder zu betreiben, da hab ich aber kein Interesse oder Bedarf drann. Zu finden unter: https://ki.draconix.org/index.php
:
Bearbeitet durch User
Markus K. schrieb: > Christoph M. schrieb: >> Mathias M. schrieb: >>> Gerade gabs nen Artikel, wo die Coder in den großen Firmen sich damit >>> übertrumpfen Tokens für 100k$ pro Monat (ein Dev) zu verbraten... >> >> Welchen Artikel meinst Du? > > https://www.golem.de/news/tokenmaxxing-wer-verbraucht-die-meisten-ki-tokens-2603-206792.html Danke für den Link. Das scheint mir aber eher so ein amerikanisches Ding großer Big-Tec-Unternehmen, bei denen das Geld egal ist. Es ist aber vielleicht ein wenig ein "Click Bait" Artikel. Ich glaube eher nicht, dass es in Deutschland Firmen gibt, die darauf bestehen, dass die Mitarbeiter mit KI-Nutzung möglichst viel Geld verbraten.
Christoph M. schrieb: > Das scheint mir aber eher so ein amerikanisches Ding großer > Big-Tec-Unternehmen, bei denen das Geld egal ist. Oder ist es einfach eine völlig unbrauchbare Metrik, wie LoC beim klassischen Programmieren?
Rene K. schrieb: > Gut, ich habe hier zu Hause einen Render-Server mit 4x RTX8000 stehen. > Die werden, dank NVLink, als eine reine Karte mit 192GB VRAM, 2.300 > Tensor-Cores 288 RTX-Cores und ~18.000 CUDA-Cores. Wow, das wäre eine schicke Maschine für lokale LLMs. Darf ich Dich fragen, was der Rechner gekostet hat und wie er darüber hinaus ausgestattet ist?
>> Gut, ich habe hier zu Hause einen Render-Server mit 4x RTX8000 stehen. >> Die werden, dank NVLink, als eine reine Karte mit 192GB VRAM, 2.300 >> Tensor-Cores 288 RTX-Cores und ~18.000 CUDA-Cores. > Wow, das wäre eine schicke Maschine für lokale LLMs. Darf ich Dich > fragen, was der Rechner gekostet hat und wie er darüber hinaus > ausgestattet ist? Nö, zu alt, vieles was mit Ampere kam fehlt der Turing Architektur.
J. T. schrieb: > Oder ist es einfach eine völlig unbrauchbare Metrik Ein T. schrieb: > Darf ich Dich fragen, was der Rechner gekostet hat In Indern bitte!
Alexander schrieb: > In Indern bitte! Der Marktpreis eines "Inders" hängt doch aber sicher davon ab, wieviele LoC er am Tag schafft?!
Nee die haben ein Kastensystem. Ich glaub ein Monatslohn liegt bei 100k (Rupien)
1N 4. schrieb: > Nö, zu alt, vieles was mit Ampere kam fehlt der Turing Architektur. Das stimmt, die hat 2. Gen Tensor Cores. Die Ampere dann 3. Gen. Die führten dann TF32 und Bfloat16 ein. Was bei modernen LLMs ungefähr eine Verdoppelung des Durchsatzes ausmacht. Für eine lokale LLM im Homelab sollte das aber allemal reichen. Und wie gesagt, ich brauche sie für Raytracen - dafür sind die noch super. 😊 Ein T. schrieb: > Darf ich Dich fragen, was der Rechner gekostet hat und wie er darüber > hinaus ausgestattet ist? Sie stecken in einem ML350 Gen10.
Christoph M. schrieb: > Du könntest mal versuchen, llma.cpp auf dem Rechner zu kompilieren und > ein kleines Modell ganz ohne GPU laufen zu lassen: > https://github.com/ggml-org/llama.cpp Danke für diesen großartigen Hinweis, das habe ich gemacht -- allerdings mit einem nicht ganz so kleinen Modell, Qwen3.5-27B, das ich allerdings zuvor in Int8 quantisiert habe. Das funktioniert dann sogar auf meinem etwas älteren Dell E-5580 mit i7-7820HQ, 32 GB DDR4-DDR (2400 MT/s) und einer 1 TB Samsung 970 Evo Plus, allerdings, na klar: schnell ist anders. Das Modell läuft in einem Docker-Container mit 0,3 bis 0,6 Token pro Sekunde. Damit hat es mir in etwas über drei Stunden ein modulares Webframework in Go mit GORM [1], Gofiber [2], PostgreSQL und JWT-Authentifizierung erzeugt. Eine Stunde Nacharbeit, im Wesentlichen wegen einiger kleiner Import-Fehler, die main.go ins Root-Dir verschoben, zwei Methodenaufrufe korrigiert die nur einen Rückgabewert zurückgeben anstelle derer zwei... nichts Wildes, und der Code sieht bisher sogar ganz anständig aus. Weil ich angelegentlich ohnehin gerade dabei war, habe ich noch ein Makefile eingefügt und damit gleich auch auf ein statisch gelinktes Binary umgebaut. Es wurden mir sogar direkt dazu ein Dockerfile und eine docker-compose.yml erzeugt. Auch hier waren ein paar kleine Anpassungen notwendig, natürlich Benutzername und Paßwort für die DB sowie eine Anpassung wegen PGDATA unter dem PostgreSQL-Dockerimage [3]. Unterm Strich wurden 561 Zeilen Code in etwas über drei Stunden erzeugt, davon 394 Zeilen Go und 125 Zeilen SQL, der Rest ist ein bisschen YAML, Makefile und Dockerfile (alles laut cloc(1). Mit meinen Korrekturen hat das letztlich also vier Stunden gedauert, und, realistisch betrachtet, hätte ich alleine sicher doppelt, eher viermal bis fünfmal so lange gebraucht. Im erzeugten Code habe ich sogar ein paar Ideen gefunden, die ich mir abschauen werde, sowie einige Dinge gefunden, die ich im Laufe der Zeit mit Golang schon selbst entwickelt hatte und selbst benutze. Offenbar machen das auch andere so wie ich. ;-) Die korrigierten Fehler waren allesamt solche, die ich auch von der Arbeit mit anderen Entwicklern, insbesondere Junioren, erwartet hätte. Ich muß zugeben: ich bin trotz allem beeindruckt, wie gut das funktioniert. [1] https://gorm.io/ [2] https://gofiber.io/ [3] https://github.com/docker-library/postgres/pull/1259
Christoph M. schrieb: >>>> Can you create an Arduino blink programm? > > Nicht ganz richtig, aber erstaunlich, dass der Code irgendwie in den > Trainingsdaten ist. Ich lese hier mit halben Auge mit und daher würde es mich interessieren, wie das Ergebnis aussieht, wenn es nicht ganz so banal sein soll. Ist es Dir möglich mit den modifizierten Angaben: ATmega48, RTC, 32768 Hz, stromsparend, exakt 50 ms Intervall, LED, Blinken den C-Code für ein Programm erstellen zu lassen? Das wäre eher praxisgerecht und keine 0815 Kopie eines Suchergebnisses aus dem Netz. Oder sind meine Erwartungen völlig daneben?
Ist euch bewusst, dass Ihr nach dem European AI-Act Pflicht zur Kompetenz (Art. 4) Ihr zum Arbeiten eine KI gar nicht nutzen dürft, wenn ihr vorher keine Ausbildung (AI Führerschein) dafür hattet?
Jens K. schrieb: > Ist euch bewusst, dass Ihr nach dem European AI-Act Pflicht zur > Kompetenz (Art. 4) Ihr zum Arbeiten eine KI gar nicht nutzen dürft, wenn > ihr vorher keine Ausbildung (AI Führerschein) dafür hattet? Wo kein Kläger, da kein Richter;-)
Jens K. schrieb: > Ist euch bewusst, dass Ihr nach dem European AI-Act Pflicht zur > Kompetenz (Art. 4) Ihr zum Arbeiten eine KI gar nicht nutzen dürft, wenn > ihr vorher keine Ausbildung (AI Führerschein) dafür hattet? Da bin ich fein 'raus, denn ich habe vor drei Jahren eine Fortbildung gemacht und ein Zertifikat erworben, um Geld vor der Steuer zu verbrennen. ;-) Davon abgesehen sehe ich in Artikel 4 der von Dir genannten Verordnung [1] nichts, das Deine Aussage stützen würde. Könnten wir die Bedenkenträger- und Regulierungsdiskussionen bitte fürderhin aus diesem Thread heraus halten? Wenn Ihr dringenden Bedarf habt, könnt Ihr jederzeit einen eigenen Thread dazu eröffnen. Danke. [1] https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ:L_202401689
Mi N. schrieb: > Ist es Dir möglich mit den modifizierten Angaben: > ATmega48, RTC, 32768 Hz, stromsparend, exakt 50 ms Intervall, LED, > Blinken > den C-Code für ein Programm erstellen zu lassen? Das sollte man nicht tun. Man kann der KI (ollama run qwen3.5:0.8b) beim Denken zusehen und es hat den Anschein, dass sie quasi dem Irrsinn verfallen ist (siehe Anhang).
unsloth/Qwen3-Coder-Next-GGUF:Qwen3-Coder-Next-MXFP4_MOE.gguf auf Strix Halo 128GB. 52t/s. Prompt per Copy & Paste von hier: "ATmega48, RTC, 32768 Hz, stromsparend, exakt 50 ms Intervall, LED, Blinken den C-Code" Qualität müssen andere beurteilen ;)
1 | #include <avr/io.h> |
2 | #include <avr/interrupt.h> |
3 | #include <avr/sleep.h> |
4 | |
5 | /* ───────────────────────────────────────────────────────────
|
6 | * ATmega48 – 50 ms LED-Blink via Timer2 asynchron (32768 Hz)
|
7 | *
|
8 | * Quarz: 32.768 kHz an TOSC1/TOSC2
|
9 | * Timer2: asynchroner Modus, CTC, Prescaler /1
|
10 | * Compare: OCR2A = 163 → 164 Takte = 5,00488 ms
|
11 | * Software-Zähler: 10 × 5 ms = 50 ms Toggle-Intervall
|
12 | * LED: PB0 (active-low oder active-high, nach Bedarf)
|
13 | * Sleep: Power-Save – CPU schläft zwischen Interrupts
|
14 | * ─────────────────────────────────────────────────────────── */
|
15 | |
16 | #define LED_DDR DDRB
|
17 | #define LED_PORT PORTB
|
18 | #define LED_PIN PB0
|
19 | |
20 | /* 10 Interrupts à ~5 ms = 50 ms */
|
21 | #define TICK_TOP 163 /* 164 Takte @ 32768 Hz = 5.00488 ms */ |
22 | #define TICKS_PER_50MS 10
|
23 | |
24 | static volatile uint8_t tick_cnt; |
25 | |
26 | ISR(TIMER2_COMPA_vect) |
27 | {
|
28 | if (++tick_cnt >= TICKS_PER_50MS) { |
29 | tick_cnt = 0; |
30 | LED_PORT ^= (1 << LED_PIN); |
31 | }
|
32 | }
|
33 | |
34 | /* Warten, bis asynchrone Timer2-Register übernommen sind */
|
35 | static void t2_sync(void) |
36 | {
|
37 | while (ASSR & ((1 << TCR2AUB) | (1 << TCR2BUB) | (1 << OCR2AUB))) |
38 | ;
|
39 | }
|
40 | |
41 | int main(void) |
42 | {
|
43 | /* LED-Pin als Ausgang */
|
44 | LED_DDR |= (1 << LED_PIN); |
45 | |
46 | /* ── Timer2 asynchron konfigurieren ──────────────── */
|
47 | ASSR |= (1 << AS2); /* externen 32768-Hz-Quarz nutzen */ |
48 | |
49 | TCCR2A = (1 << WGM21); /* CTC-Modus (Top = OCR2A) */ |
50 | TCCR2B = (1 << CS20); /* Prescaler /1 */ |
51 | OCR2A = TICK_TOP; /* 164 Takte → ~5 ms */ |
52 | TCNT2 = 0; |
53 | |
54 | t2_sync(); /* Übernahme abwarten */ |
55 | |
56 | TIMSK2 = (1 << OCIE2A); /* Compare-Match-A-Interrupt ein */ |
57 | |
58 | /* ── Schlafmodus ─────────────────────────────────── */
|
59 | set_sleep_mode(SLEEP_MODE_PWR_SAVE); |
60 | sleep_enable(); |
61 | |
62 | sei(); |
63 | |
64 | for (;;) { |
65 | sleep_cpu(); /* schlafen bis nächster IRQ */ |
66 | }
|
67 | }
|
:
Bearbeitet durch User
Moin, Armchair programming? Der Weg in die Zukunft, oder doch nur ein momentaner Blip am Radar? Die Versuchung ist groß in den Malstrom der bald allgegenwärtigen AI-Maschinerie hineingesogen zu werden. Ich nasche manchmal in der Arbeit auch an den Früchten der KI. Andrerseits geht's mir eher so, daß ich mich lieber selber engagiere; zumindest beim Hobby. Auch verursacht mir die alte Redensart "Wer rastet, der rostet" ein gewisses Unbehagen. Ein Freund von mir konstatierte kürzlich bei einem Besuch, daß das händische Programmieren für ihn nun endgültig Geschichte wäre, seit er alles mit Claude macht. Soweit hat er auch nette Erfolge einheimsen können und 8000+ Zeilen Programme sind natürlich nicht mehr trivial. Er arbeitet übrigens an einem tollen Browser basierten Midi Editor und Steuerprogramm. Vor zehn Jahren hätte ich mir es nicht träumen lassen, dass wir alle so unkomplizierten und teils billigen Zugang zu diesen mächtigen Werkzeugen haben. Man wird ein Auge darauf halten müssen. 'The Times They Are a-Changin' Bob Dylan hörte wahrscheinlich schon damals die Glocken läuten. Bestimmt konnte er sich aber unsere AI der Gegenwart trotzdem nicht gut vorstellen. Gruß, Gerhard
:
Bearbeitet durch User
Mi N. schrieb: > Oder sind meine Erwartungen völlig daneben? Gerhard O. schrieb: > Die Versuchung ist groß in den Malstrom Sowohl die Lösung derartiger Probleme, als auch Bob Dylans Mahlstrom sind nicht das Thema dieses Threads. Danke.
Ein T. schrieb: > Mi N. schrieb: >> Oder sind meine Erwartungen völlig daneben? > > Gerhard O. schrieb: >> Die Versuchung ist groß in den Malstrom > > Sowohl die Lösung derartiger Probleme, als auch Bob Dylans Mahlstrom > sind nicht das Thema dieses Threads. Danke. Anbetracht Deiner Hinweise im Eröffnungs-Beitrag muß ich Dir eigentlich im Nachhinein recht geben. Also nichts für ungut und auch weiterhin viel Erfolg. Gruß, Gerhard
Gerhard O. schrieb: > Man wird ein Auge darauf halten müssen. sprach die Maus im Angesicht der Schlange… Oliver
Ein T. schrieb: > Ich muß zugeben: ich bin trotz allem beeindruckt, wie gut das > funktioniert. Ich bin immer beeindruckt wie doof die Teile ab einem gewissen Punkt sind, z.B. gestern bekommt Claude nicht mal command line paras hin wie ich sie gerne hätte aber immer Pseudotestausgaben auf der bash werden einem präsentiert als würde es jetzt wie gewünscht funktionieren, was es aber nicht tut. Selbst die Tests sind zusammenfantasierter Schrott. Das wird dann nach jedem weiteren Hinweis immer schlimmer, das Ding produziert dann nur noch Müll aber präsentiert immer neue "jetzt aber ist es richtig, ich schwör!"-Lösungen die für die Tonne sind. Threading kapieren die Dinger auch nicht wirklich, wenn man dann ein paar Hinweise gibt erkennt er scheinbar manchmal das Problem (z.B. zu viele Threads auf zu kleinen Daten) tut so als hätte er Benchmarks gefahren und im nächsten Schritt macht er wieder den selben Fehler, man kommt sich vor als würde man einem Idioten beibringen was es in den Rechner einzutippen hat. Ab und an kommt mal was brauchbares raus dann wieder nur übelster Müll, das ganze Nacharbeiten und Geplapper mit der KI geht einem dann nur noch auf die Nerven, entwickeln ist was anderes. Wenn ich das alles selber geschrieben hätte wäre ich anschliessend tief in meinem Code drinn wüsste sofort wo was wie funktioniert, da gehen Änderungen schneller von der Hand als an dem ausgekotzten AI-Code mit subtilen Fehlern die ich erst mal aufspüren muss. Wenn das die Zukunft sein soll, dann gute Nacht und ich mach was anderes. Die ganzen DAUs sind nat. begeistert wenn hinten was rausfällt was scheinbar funktioniert, ich glaube die meisten wissen gar nicht was sie da für einen Schrott serviert bekommen, die sind schon zufrieden wenn das Ding anschliessend ohne Absturz startet.
Frank D. schrieb: > Threading kapieren die Dinger auch nicht wirklich, LLM sind keine KI die sind nicht fähig etwas zu kapieren. Du benutzt das Werkzeug falsch wenn Du diesen Anspruch hast. Frank D. schrieb: > "jetzt aber ist es richtig, ich schwör!" Die Floskeln kann man abstellen. Ansonsten volle Zustimmung, hat wohl jeder schon so erlebt. Antworten sind immer kontextbezogen und ab einer gewissen Dialoglänge eben festgefahren.
:
Bearbeitet durch User
Dieselbe Aufgabe oben habe ich jetzt Qwen3.5-9B und Qwen3.5-4B gestellt. Die beiden Varianten erzeugen ebenfalls Code, der eine gewisse Nacharbeit braucht, wenig überraschend. Der Code von 9B macht einen guten Eindruck, hat aber viel mehr Korrekturbedarf als der von 27B, was ich auch so erwartet hatte. Aber daß der von 4B erzeugte Code weniger Korrektur benötigt als der von 9B, das hätte ich nicht erwartet. Ebenfalls spannend: anders zu 27B und 9B strukturiert 4B seinen Code nicht in ein "internal"-Verzeichnis [1], sondern in Verzeichnisse direkt im Wurzelverzeichnis des Projekts. Auf dem kleinen Laptop hier performt 4B mit etwa 5 t/s, das macht leider nur begrenzten Spaß. Aber ich hab' noch 'nen ungenutzten Server mit i9-9900K und 64 GB Dual-Channel RAM, den ich gerade einrichte; nach dessen Umstellung von Traefik auf Caddy, die noch ein paar Tage benötigen wird, werde ich schauen, wie die Veranstaltung darauf läuft. Mit dem großen Arbeitsspeicher werde ich darauf auch einmal das 35B-Modell testen. Schauen wir mal. Bis dahin gelten meine besten Wünsche und mein herzlicher Dank allen, die sich hier in diesem Thread mit ihren Kenntnissen und Erfahrungen eingebracht haben, insbesondere Christoph M. für seinen großartigen Tipp bezüglich llama.cpp. [1] https://www.bytesizego.com/blog/golang-internal-package
Ein T. schrieb: > Mi N. schrieb: >> Oder sind meine Erwartungen völlig daneben? > ... > Sowohl die Lösung derartiger Probleme, als auch Bob Dylans Mahlstrom > sind nicht das Thema dieses Threads. Danke. Dein 'Danke' liest sich so, als ob Du mit dem Zeigerfinger bzw. Rohrstock durch den Raum läufst und zwingend Deine Erwartungen bestätigt haben möchtest. @ Christoph M. (mchris) @ 1N 4. (1n4148) Vielen Dank für Eure Ergebnisse! Insgeheim hatte ich einen fraktionalen Teiler erwartet, aber mein 'exakt' hätte ich nicht so schwammig formulieren dürfen. Frank D. schrieb: > Wenn ich das alles selber geschrieben hätte wäre ich anschliessend tief > in meinem Code drinn wüsste sofort wo was wie funktioniert, da gehen > Änderungen schneller von der Hand als an dem ausgekotzten AI-Code mit > subtilen Fehlern die ich erst mal aufspüren muss. Von außen betrachtet sind das auch meine Einschätzungen, aber die Zeiten ändern sich. Wenn alles oberflächlich wird, fällt das nicht mehr auf ;-)
Wie genau richte ich denn so ein llama.cpp mit diesen Qwen ein? Läuft der nur auf CPU oder kann ich den auch mal auf GPU laufen lassen?! Wo gibts da ein HowTo?
Frank D. schrieb: > Ich bin immer beeindruckt wie doof die Teile ab einem gewissen Punkt > sind, [...] > > Threading kapieren die Dinger auch nicht wirklich, [...] Ich befürchte, "doof" und "kapieren" sind keine besonders klugen Kategorien und Ansprüche zur Beurteilung von LLMs zur Generierung von Code. Deswegen betrachte ich das deutlich pragmatischer: wie ist die Codequalität, viel Nacharbeit ist nötig, welche Sicherheits- und Performanceimplikationen habe ich zu beachten, solche Dinge eben. Für Boilerplate sind die LLMs eine feine Sache, aber kreative Lösungen, gar für für komplexe Probleme, erwarte ich davon gar nicht und kann daher auch nicht enttäuscht werden, wenn diese nicht geliefert werden. Nichtsdestotrotz habe ich einen gewissen Eindruck gewonnen, wie deutlich der Produktivitätsschub ist, wenn mir ein LLM das Schreiben von Boilerplate und andere ebenso langweilige wie langwierige Tipparbeit abnimmt -- allem voran Kommentare, Tests und Dokumentation. Ich hab mich ja nicht für diesen Beruf entschieden, weil ich so gern stundenlang vor einer Tastatur sitze und dort stupides und langweiliges Zeug hinein tippe. Neben und durch den Produktivitätsschub -- der auf lange Sicht vermutlich alle Entwickler arbeitslos machen dürfte, die sich ihm verweigern -- hab ich zudem mehr Zeit für die Dinge, die meinen Beruf (für mich) so interessant machen -- allem voran die Kommunikation mit der fachlichen Kompetenz und die Abstimmung mit meinen Kollegen und Mitarbeitern, aber auch das kreative Entwickeln von Software-, System- und Netzwerkarchitekturen, Verbesserungen von Sicherheit, Stabilität und Performance, Deployment, Monitoring, Alarming, Backup und Restore, Fehlerbehandlung, ... you get the idea. Insofern kann ich Dir nur den Rat geben, Deine Erwartungen deutlich herunter zu schrauben, schließlich ist so ein LLM doch weder mehr noch weniger als die Replikation von zuvor erlernten Mustern. Es ist nicht kreativ und zudem nicht gut bei der Lösung von komplizierten oder komplexen Problemen. Dein Problem ist aus meiner Sicht daher keins der LLMs, sondern Deiner IMHO viel zu hohen Erwartungen daran. Betrachte die LLMs als dumme Tippknechte, die Dir immerhin die stupidesten Teile Deiner Arbeit abnehmen können.
Mi N. schrieb: > Ein T. schrieb: >> Sowohl die Lösung derartiger Probleme, als auch Bob Dylans Mahlstrom >> sind nicht das Thema dieses Threads. Danke. > > Dein 'Danke' liest sich so, als ob Du mit dem Zeigerfinger bzw. > Rohrstock durch den Raum läufst und zwingend Deine Erwartungen bestätigt > haben möchtest. Ich versuche lediglich, möglichst frühzeitig zu verhindern, daß dieser Thread aus dem Ruder läuft. Denn "ich stelle einer KI eine besonders schwierige Aufgabe und triumphiere, wenn sie die nicht fehlerfrei lösen kann" hatten wir in diesem Forum IMHO schon mehr als genug. :-)
Ein T. schrieb: > Wünsche und mein herzlicher Dank allen, die sich hier in diesem Thread > mit ihren Kenntnissen und Erfahrungen eingebracht haben, insbesondere > Christoph M. für seinen großartigen Tipp bezüglich llama.cpp. Danke :-) Es ist schon interessant, dass das Coding mit einem lokalen LLM auf einem größeren Rechner irgendwie funktioniert. Besonders spannend wäre es, wenn man lokale LLMs eine lokales Codieragenten Framework einbinden könnte (so was wie OpenClaw). Ich habe mal ein Video gepostet, das die Begriffe etwas genauer erklärt: Beitrag "Re: Programmieren mit KI"
Rene K. schrieb: > Wie genau richte ich denn so ein llama.cpp mit diesen Qwen ein? Läuft > der nur auf CPU oder kann ich den auch mal auf GPU laufen lassen?! > > Wo gibts da ein HowTo? Hab' Dir eins (für Linux) gemacht und angehängt, allerdings nicht besonders ausführlich getestet. Bei Problemen bitte einfach melden, viel Erfolg!
Ein T. schrieb: > Denn "ich stelle einer KI eine besonders > schwierige Aufgabe und triumphiere, wenn sie die nicht fehlerfrei lösen > kann" hatten wir in diesem Forum IMHO schon mehr als genug. :-) Darum geht es mir nicht. Meine Frage ist: bekomme ich eine verlässliche Lösung für ein reales Problem oder schenke ich mir den Installationsaufwand, um nicht anschließend gut versteckte Irrtümer/Fehler im Code suchen zu müssen. Nichts ist schlimmer als das! Ich weiß nicht, welche Programme Du schreibst, wo dann eine Arbeitserleichterung stattfindet. Was Du zum "Neben und durch den Produktivitätsschub" schreibst, liest sich wie ein Werbepapier: Zeit für sinnvolle Tätigkeiten ;-) Vielleicht gibt es eine Erleichterung, wenn man Scripts und LIBs zusammenklicken möchte. Aber das sind nicht meine Aufgaben.
Ein T. schrieb: > Denn "ich stelle einer KI eine besonders > schwierige Aufgabe und triumphiere, wenn sie die nicht fehlerfrei lösen > kann" hatten wir in diesem Forum IMHO schon mehr als genug. Das kann man übrigens leicht haben. Und die KI weiß oft sogar warum sie Probleme hat. Durchaus selbstkritisch, was man von gewissen - durch ständigen Selbstlob auffallenden Teilnehmern hier im Forum - ganz und gar nicht annehmen kann.
Mi N. schrieb: > Ein T. schrieb: >> Denn "ich stelle einer KI eine besonders >> schwierige Aufgabe und triumphiere, wenn sie die nicht fehlerfrei lösen >> kann" hatten wir in diesem Forum IMHO schon mehr als genug. :-) > > Darum geht es mir nicht. Meine Frage ist: bekomme ich eine verlässliche > Lösung für ein reales Problem oder schenke ich mir den > Installationsaufwand, um nicht anschließend gut versteckte > Irrtümer/Fehler im Code suchen zu müssen. Nichts ist schlimmer als das! Das kann und will ich nicht beurteilen. Ich kann nicht, weil ich natürlich nicht weiß, was Du entwickelst, womit Du entwickelst, was Du im Allgemeinen über KI und im Besonderen über LLMS weißt und welche Erwartungen Du deswegen daran stellst. Wenn Du mit der Erwartung daran gehst, daß Dir sofort fehlerfreier, stabiler, performanter, wartbarer Code geliefert wird, wirst Du enttäuscht werden, wie Frank weiter oben. Und ich will das nicht beurteilen, weil sonst Ende an allem schuld bin. :-) > Vielleicht gibt es eine Erleichterung, wenn man Scripts und LIBs > zusammenklicken möchte. Aber das sind nicht meine Aufgaben. Meine auch nicht. Für Betrugsprävention, AML, KYC und Distributed Computing in Echtzeit gibt es eher wenig, das man zusammen klicken könnte und so ziemlich gar nichts, bei dem man das wollen würde. ;-)
Rbx schrieb: > Das kann man übrigens leicht haben. Und die KI weiß oft sogar warum sie > Probleme hat. Die KI "weiß" gar nichts. Jedenfalls nicht in der Bedeutung des Wortes "Wissen", die unsere Sprache üblicherweise damit verbindet.
> Vielen Dank für Eure Ergebnisse! > Insgeheim hatte ich einen fraktionalen Teiler erwartet, aber mein > 'exakt' hätte ich nicht so schwammig formulieren dürfen. Das LLM hat außerhalb des Codes nebst anderen Rahmenbedingungen darauf hingewiesen. Mal noch mit 50ms Constraint. Wäre das nun in deinem Sinne?
1 | #include <avr/io.h> |
2 | #include <avr/interrupt.h> |
3 | #include <avr/sleep.h> |
4 | |
5 | #define LED_DDR DDRB
|
6 | #define LED_PORT PORTB
|
7 | #define LED_PIN PB0
|
8 | |
9 | /*
|
10 | * 32768 × 0.05 = 1638.4 → nicht ganzzahlig
|
11 | *
|
12 | * Kompensation über 5-Tick-Zyklus:
|
13 | * 3 × 1638 Takte + 2 × 1639 Takte = 8192 Takte = exakt 250 ms
|
14 | * → mittlere Periodendauer = exakt 50.000 ms
|
15 | *
|
16 | * Maximaler Einzeltick-Jitter: 1/32768 = 30.5 µs
|
17 | */
|
18 | |
19 | #define TICK_SHORT 163 /* 164 Takte = 5.00488 ms */ |
20 | #define TICK_LONG 164 /* 165 Takte = 5.03540 ms */ |
21 | #define CYCLE_LEN 5
|
22 | |
23 | /* Muster: short, short, short, long, long (3×164 + 2×165 = 822) */
|
24 | /* Pro 10 Ticks (2 Zyklen) → exakt 50 ms Toggle */
|
25 | |
26 | static const uint8_t ocr_pattern[CYCLE_LEN] = { |
27 | TICK_SHORT, TICK_SHORT, TICK_SHORT, TICK_LONG, TICK_LONG |
28 | };
|
29 | |
30 | static volatile uint8_t tick_cnt; /* 0..9 */ |
31 | static volatile uint8_t pat_idx; /* 0..4 */ |
32 | |
33 | ISR(TIMER2_COMPA_vect) |
34 | {
|
35 | /* Nächsten OCR2A-Wert sofort laden */
|
36 | pat_idx++; |
37 | if (pat_idx >= CYCLE_LEN) |
38 | pat_idx = 0; |
39 | OCR2A = ocr_pattern[pat_idx]; |
40 | |
41 | /* 10 Ticks = 2 volle 5er-Zyklen = exakt 50 ms */
|
42 | if (++tick_cnt >= 10) { |
43 | tick_cnt = 0; |
44 | LED_PORT ^= (1 << LED_PIN); |
45 | }
|
46 | }
|
47 | |
48 | static void t2_sync(void) |
49 | {
|
50 | while (ASSR & ((1 << TCR2AUB) | (1 << TCR2BUB) | (1 << OCR2AUB))) |
51 | ;
|
52 | }
|
53 | |
54 | int main(void) |
55 | {
|
56 | LED_DDR |= (1 << LED_PIN); |
57 | |
58 | /* Timer2 asynchron mit 32768 Hz Quarz */
|
59 | ASSR |= (1 << AS2); |
60 | |
61 | TCCR2A = (1 << WGM21); /* CTC */ |
62 | TCCR2B = (1 << CS20); /* Prescaler /1 */ |
63 | OCR2A = ocr_pattern[0]; |
64 | TCNT2 = 0; |
65 | |
66 | t2_sync(); |
67 | |
68 | TIMSK2 = (1 << OCIE2A); |
69 | |
70 | set_sleep_mode(SLEEP_MODE_PWR_SAVE); |
71 | sleep_enable(); |
72 | |
73 | sei(); |
74 | |
75 | for (;;) |
76 | sleep_cpu(); |
77 | }
|
:
Bearbeitet durch User
> Besonders spannend wäre es, wenn man lokale LLMs eine lokales > Codieragenten Framework einbinden könnte (so was wie OpenClaw). Wieso "könnte"? Kann man doch. Ich nutze zum Beispiel VScode, Cline, lokales LLM. Findet sich auch für andere Agenten.
Ich finde vieles inzwischen ganz brauchbar, aber eher als Hilfe. Hauptanwendung bei mir ist VHDL/FPGA, bzw C für Microcontroller. Wenn man irgendwelche Sachen implementiert haben will, erzeugt es im Regelfall erstmal eine ganz gute Basis auf die man aufsetzen kann. Aber wie schon jemand hier schrieb hier, scheitert es oft im Detail sodass seltenst etwas aus dem Stehgreif funktioniert (selbst mit mehrmaligen Nachfragen). Das heißt ich fange dann doch wieder händisch an zu analyiseren was die KI produziert hat und warum es nicht funktioniert hat. Entweder muss ich der KI dann doch noch einen Hinweis geben was schief läuft oder ich fixe es einfach selber. Mir ist oft aufgefallen, dass sich die KI beim bug-fixing dann irgendwann im Kreis dreht und dann "gefixte" Dateien anbietet, die aber drei Iterationen vorher schonmal 1:1 so produziert wurden wo es eigentlich bekannt sein müsste, dass es nicht funktional war. Was ich auch ganz gerne damit mache ist für so Dinge wie Code-Analysen oder Codes gegenüber ältere Versionen vergleichen etc... Oder Refactoring-Eingriffe die recht straight-forward sind. Redundante Code-Stellen etc... Für so Sachen wie Python Skripte mal schnell schreiben taugt es aber.
Gerhard O. schrieb: > Soweit hat er auch nette Erfolge einheimsen können und 8000+ Zeilen > Programme sind natürlich nicht mehr trivial. Ich arbeite täglich an einem 6 Mio Zeilen Projekt (generierten Code und fremde Libs nicht mit gezählt). Schade, daß ich damit keine KI testen darf.
:
Bearbeitet durch User
Markus W. schrieb: > dem Stehgreif ich bin ja normalerweise kein Rechtschreibnazi und habs bis vor kurzem noch genau wie du geschrieben, aber weil Youtube es mir neulich um die Ohren gehauen hat: Es heißt Stegreif und das ist ein altes Wort für den Steigbügel eines Reiters. Wenns mal schnell gehen musste ist er nicht abgestiegen sondern hat noch im Steigbügel, also im Stegreif gesprochen. Ich fands irgendwie interessant.
1N 4. schrieb: > Das LLM hat außerhalb des Codes nebst anderen Rahmenbedingungen darauf > hingewiesen. > > Mal noch mit 50ms Constraint. Wäre das nun in deinem Sinne? Nochmals Danke für Deine Arbeit! Es sieht besser aus, wobei der Teiler 1644 (2 x 822) leicht oberhalb der eff. notwendigen 1638,4 liegt. Genau wird es, wenn man ein Verfahren wie bei der Signalerzeugung per DDS verwendet. Aber das wird hier dann OT. Ohne den Code real getestet zu haben, ist jedoch lobenswert, daß wie erwartet T2 mit ext. Quarz verwendet wird. Das weiter oben gezeigte Ergebnis https://www.mikrocontroller.net/attachment/693492/Atmega48_Blink_Confusion.txt sollte man sich für den 1.4. aufheben ;-) J. T. schrieb: > ich bin ja normalerweise kein Rechtschreib ... Weiter oben für Dich noch zum Feierabend: "LCD display"
Mi N. schrieb: > Weiter oben für Dich noch zum Feierabend: "LCD display" Vom Prinzip eine ähnliche Kategorie Fehler, zumindest aus der Warte, dass er gern gemacht wird. Aber der Stehgreif ist glaub ich noch deutlich verbreiteter, zumindest beim "Otto-Normalverbraucher". Aber das LCD-Display lässt mich irgendwie kalt. Beim Stegreif hat es halt gut gepasst, weil ich den Fehler auch machte. Einer der wenigen, der meinen Beißreflex triggern kann, ist "der Drehmoment". Frag aber nicht warum, dass weiß ich selbst nicht :D
:
Bearbeitet durch User
Ich geb Dir € 1.000,- tausend Euro wenn Du mir erklärst was am LCD-Display das Problem ist, am QLED‑Display, CRT‑Display, OLED‑Display und TFT‑Display aber nicht.
> Das weiter oben gezeigte Ergebnis > https://www.mikrocontroller.net/attachment/693492/Atmega48_Blink_Confusion.txt > sollte man sich für den 1.4. aufheben ;-) Ja, wobei es manchmal ganz interessant ist die Chain of Thought durchzugehen.
> Ich geb Dir € 1.000,- tausend Euro wenn Du mir erklärst was am > LCD-Display das Problem ist, am QLED‑Display, CRT‑Display, OLED‑Display > und TFT‑Display aber nicht. Ich nehm die auch, gerne per Paypal. Oder wenn möglich bitte an ein Tierheim. Liquid Crystal Display-Display. Quantum Light Emitting Diode-Display, Cathode Ray Tube-Display, Organic Light Emitting Diode-Display, Thin Film Transistor-Display. Siehst Du den Pleonasmus nun? :D
:
Bearbeitet durch User
Mi N. schrieb: > Darum geht es mir nicht. Meine Frage ist: bekomme ich eine verlässliche > Lösung für ein reales Problem oder schenke ich mir den > Installationsaufwand, um nicht anschließend gut versteckte > Irrtümer/Fehler im Code suchen zu müssen. Nichts ist schlimmer als das! Man muss den Code auf jeden Fall gründlich kontrollieren. Man kann aber natürlich auch Vorgaben machen. Du kannst ihm z.B. sagen, es soll das Problem mit einem Thread lösen. Prinzipiell würde ich bei einem bestehenden (großen) Programm eher kleine Aufgaben geben, die man dann auch bei der Kontrolle gut überblicken kann. Ich hatte neulich den Fall, dass es in meinem Programm 2 sehr ähnliche APIs mit unterschiedlicher Struktur gab, die aber die gleichen Funktionen aufgerufen haben. In beiden APIs wurden die Funktionen direkt aufgerufen. Das wollte ich vereinheitlichen. Das ist nicht schwierig, aber halt eine Fleißarbeit. Die KI hat Ruckzuck die 10 neue Funktionen dafür geschrieben und die 20 anderen angepasst. Ich habe beim Review einen Fehler gefunden, aber hätte ich das selber gemacht, dann hätte ich es ja auch gründlich anschauen müssen. Ich war echt froh, dass mir die KI das abgenommen hat, denn ich hatte wenig Lust auf diese Fleißarbeit. Github Copilot hat einen Planungsmodus, bei dem man die KI halt erstmal planen lässt, wie sie das Problem denn angehen würde und entsprechend Korrekturen einbringen kann, bevor sie loslegt. Das finde ich sehr praktisch. > Ich weiß nicht, welche Programme Du schreibst, wo dann eine > Arbeitserleichterung stattfindet. Was Du zum "Neben und durch den > Produktivitätsschub" schreibst, liest sich wie ein Werbepapier: Zeit für > sinnvolle Tätigkeiten ;-) Man kann sie nicht alles machen lassen und man muss ihr unbedingt hinterher kontrollieren. Aber ich möchte sie nicht mehr missen. > Vielleicht gibt es eine Erleichterung, wenn man Scripts und LIBs > zusammenklicken möchte. Aber das sind nicht meine Aufgaben. Definitiv. Ich brauche öfter mal ein kleines Python Script (300-1000 Zeilen) um etwas zu analysieren oder zu testen und das ist schon sehr viel schneller geworden. Manchmal schafft sie das Script ganz alleine.
> Man muss den Code auf jeden Fall gründlich kontrollieren.
Deshalb bin ich ein Freund von Multi-Agenten Systemen die sich
gegenseitig auf die Finger schauen.
Und, was ich persönlich als "bequemer" Mensch schätze: Aussagekräftige
Commit-Messages als Bonus on Top :D
:
Bearbeitet durch User
Sicher heißt es dann auch LC Panel, LC Modul, und QLEDD TFTD CRTD in Kurzform.
1N 4. schrieb: >> Das weiter oben gezeigte Ergebnis >> https://www.mikrocontroller.net/attachment/693492/Atmega48_Blink_Confusion.txt >> sollte man sich für den 1.4. aufheben ;-) > > Ja, wobei es manchmal ganz interessant ist die Chain of Thought > durchzugehen. Ja ist recht lustig. Es versucht irgendwie verzweifelt zu verstehen, was der User will. Da könnte man natürlich argumentieren, dass die Frage nicht gut genug gestellt oder zu undeutlich formuliert war. Es könnte ja vielleicht auch einfach nachfragen, aber es traut sich wohl nicht. Das Modell ist ja sehr klein und von den Gedankengängen erinnert es eher an einen überforderten Schüler.
1 | Actually, this is confusing. 32768Hz is an exact value. A 32768Hz clock |
2 | would blink every 1/32768th of a second. 1 second / 32768 = 30.606 |
3 | microseconds. That doesn't match the 50ms blink time. |
4 | |
5 | Wait, I think I'm misunderstanding. The user says: |
6 | "blinks a led with 50ms interval" |
:
Bearbeitet durch User
> Das Modell ist ja sehr klein und von den Gedankengängen erinnert es eher > an einen überforderten Schüler. Ja, weil LLM mehr oder weniger dumm sind. Deshalb versucht man ja mit Reasoning, Chain of Thoughts, etc. über statistische Methoden die unausgesprochenen Hintergründe hinter einem einfachen Prompt in sequentielle "Denk"-Schritte zu modellieren. Ob ein Modell nachfragt oder nicht ist auch eine Frage des Trainings. Wenn die Benchmarks darauf abzielen Antworten statt Rückfragen zu bekommen, tja, dann muss halt möglichst überzeugend argumentiert werden :D
Alexander schrieb: > Ich geb Dir € 1.000,- tausend Euro wenn Du mir erklärst was am > LCD-Display das Problem ist, am QLED‑Display, CRT‑Display, OLED‑Display > und TFT‑Display aber nicht. Weils doppelt gemoppelt ist. LCD steht doch für Liquid Crystal Display. Ein LCD-Display wäre dann ein Liquid Crystal Display Display. Das d in OLED steht für Diode. Ein AMOLED-Display ist also völlig richtig ein Aktiv Matrix Organic Light Emittig Diode Display. CRT Cathode Ray Tube, nicht jede Kathodenstrahlröhre wurde für Anzeigezwecke eingesetzt. TFT Thin Film Transistor. Da passt das Display überall hin, ohne doppelt gemoppelt zu sein. Wie möchtest du mur die 1000€ zukommen lassen?
J. T. schrieb: > LCD steht doch für Liquid Crystal Display. Das gehört hier nicht her. Könnt Ihr das bitte per PN oder in einem eigenen Thread klären? Danke.
Ein T. schrieb: > Rene K. schrieb: >> Wie genau richte ich denn so ein llama.cpp mit diesen Qwen ein? Läuft >> der nur auf CPU oder kann ich den auch mal auf GPU laufen lassen?! >> >> Wo gibts da ein HowTo? > > Hab' Dir eins (für Linux) gemacht und angehängt, allerdings nicht > besonders ausführlich getestet. Bei Problemen bitte einfach melden, viel > Erfolg! Wenn man es sehr einfach haben will, braucht man ja nur 3 Befehle in der Linux-Kommandozeile um ollama zu installieren, ein Modell zu holen und laufen zu lassen: Beitrag "Re: Erfahrungen mit AI-Coding" Allerdings ist das dann ohne Docker-Container. Man kann das Modell aber dann direkt über python steuern.
1 | import ollama |
2 | |
3 | response = ollama.generate(model='qwen3.5:0.8b', prompt='Why is the sky blue?') |
4 | print(response['response']) |
J. T. schrieb: > Wie möchtest du mur die 1000€ zukommen lassen? Ich wollte Dich jetzt grad eben nach Deiner IBAN Nr. fragen, aber nun hab ich die PIN Nummer 3x dreimal falsch eingegeben, das WLAN‑Netzwerk hat keine Internetverbindung verbunden und die LED Diode meiner HDD Festplatte blinkert wie wild. Ich weiß nicht ob's am CPU- oder GPU Prozessor liegt oder an der PCB Platine, mein LCD Bildschirm Display Kabel ist jedenfalls richtig angeschlossen. Könnte aber auch am PCI- oder USB Bus liegen.
Ich kenne keinen der mit IBA Nr, PI Nummer, WLA Netzwerk, LE Diode, HD Festplatte, C Prozessor, G Prozessor, PC Platine, US Bus oder LC Display direkt etwas anfangen könnte. LCD bezeichnet eine Technologie und ist nur als vollständiges Akronym ein sinnvolles Lexem für den Gattungsbegriff, alles andere wäre entstellend. ABS-System oder USB-Bus zu schreiben ist völlig legitim und zeugt nicht von Unwissenheit sondern von intuitiver sprachlicher Intelligenz.
Alexander schrieb: > Ich kenne keinen der mit Musst du eigentlich in jeden Thread mit irgendwas reinquacken? Hast du so ein Geltungsbedürfnis?
Ich kann Dir aus dem Stehgreif nicht sagen wer damit angefangen hat. Den Ball mit dem Geltungsbedürfnis spiele ich weiter an Mi N. (msx)
Hallo, also ich hab mir von ChatGPT bei einer Internetseiten-Gestaltung helfen lassen .. grauenvoll, das Teil machte nur Fehler und war vergesslich .. .. aber manchmal ist es echt hilfreich, .. man kann auch Codes von Claude gegenprüfen lassen und darin ist es gut. Arbeite derzeit mit Claude Pro und würde sagen, hat meine Programmierzeit aktuell von Monaten auf zwei Wochen reduziert, weil es einfach Dinge schon weiß, die ich mir erst mühevoll aneignen/anlesen/suchen müsste. So macht es wirklich Spaß. Aber manchmal kommt auch Müll raus. Ich entwickle schon seit Jahrzenten in C/C++ und schätze diese Hilfe, die man damit bekommen kann, Größenordnung 2000 Zeilen Code kann das Teil handeln, sehe es mir immer wieder an und gerade für Verbesserungen und Erweiterungen ist es echt brauchbar. KI wird uns Entwickler ersetzen, dann spricht ein User ein paar Worte in ein Mikro und bekommt ein fertig funktionierendes Gerät, dessen Funktionsweise er nie verstehen wird. Aber das Ergebnis zählt. Bis dahin, wäre es eine Verschwendung von Lebenszeit, KI nicht zu nutzen.
Tier schrieb: > also ich hab mir von ChatGPT Leider hast Du das Thema verfehlt, hier geht es um lokale Modelle. > KI wird uns Entwickler ersetzen, Das sehe ich noch LANGE nicht, dafür macht sie zu viele Fehler.
Ein T. schrieb: > Leider hast Du das Thema verfehlt, hier geht es um lokale Modelle. Ich lese im Eingangsbeitrag nichts von lokalen Modellen. Aus eigener Erfahrung: VSCode mit RooCode und Claude Sonnet 4.6. Ich hab mich langsam rangetastet, Python-Scripts schreiben lassen, Tests automatisiert, Plantuml-Diagramme aus textueller Beschreibung und aus bestehendem Code (auch in Kombination), refactoring von C-Code. Und Erklären (und wenn mans erlaubt auch patchen) von unübersichtlichen xml-Files mit allerlei Querabhängigkeiten. Klar muss man draufschauen was rauskommt. In der Regel heißt falscher Output, dass der Prompt nicht präzise genug war. Das öffnet auch die Augen für das tägliche Miteinander: Es passiert auch unter Kollegen, dass man zwar meint, etwas abgestimmt zu haben, aber viel später merkt, dass es jeder ein klein wenig anders verstanden hatte. Die AI liefert diese Erkenntnis von jetzt auf gleich, und draufhauen "wie doof bist du denn, das weiß doch jeder wie das gemacht gehört" verbessert gar nichts. Diese Erkenntnis hilft auch im echten Leben. Das krasseste was ich als Spielwiese mal gemacht hab: Einen Arduino-Sketch schreiben lassen, der über Serial 6 AD-Kanäle abfragen und 6 PWM-Ausgänge schreiben lässt. Gut, das kann man händisch auch. Dann ein kleines Manual dazu schreiben lassen, also welche Baudrate und welche Befehle es gibt und was die machen. Auf einem Steckbrett aufgebaut, und einen Transistor in Emitterschaltung inkl Widerständen zwischen einen Ausgang und einen Eingang gehängt. Und dann die Aufgabenstellung in eine Textdatei geschrieben (etwas verkürzt hier). "Identifiziere die Schaltung zwischen PWM0 und A0. Nutze die Bedienungsanleitung blahblub. Such selber den seriellen Port an dem der Arduino hängt. Nutze Python, und erzeuge schöne Diagramme mittels plotly und stell die direkt im Browser dar. Wiederhole das ganze fünf Mal, verbessere die Testsequenz jedes Mal auf Basis deiner Erkenntnisse." Nun noch so viel wie möglich auf auto-accept eingestellr, und schwupps, das Teil schreibt python-Scripte, startet sie, auf dem Oszi sieht man wie es Spannungsrampen fährt, und Reports kommen raus. NPN-Transistor gefunden. Ich find das irre. Bei "schwierigeren" Schaltungen (p-Kanal-FET, alle drei Pins gesteuert und alle drei Pins rücklesbar) hatte er alles mögliche gemessen, aber die Schlussfolgerung, dass es ein FET ist, fehlte. Hat sich dann auf detailreiche Analyse der Body-Diode fixiert. Produktivitätssteigerung? Deutlich, weil ganz viel Tipperei wegfällt. Der Kopf bleibt frei, sich zu überlegen, was man eigentlich genau will, nicht wie man das umsetzt. Und die Kommentare (die man sonst sehr spartanisch hält, weil man muss ja weiter...) sind automatisch nicht nur da, sondern auch noch klar und hilfreich.
:
Bearbeitet durch User
Tier schrieb: > Hallo, > also ich hab mir von ChatGPT bei einer Internetseiten-Gestaltung helfen > lassen .. grauenvoll, das Teil machte nur Fehler und war vergesslich .. Kann ich so nicht bestätigen: https://ki.draconix.org/ ist rein per ChatGPT Prompt entstanden. Es waren genau sieben Prompts, jedes mal habe ich mir direkt ein ZIP Archiv liefern lassen um sie direkt auf den Server so schieben. Gut, ich habe ein ChatGPT Pro Account, aber ich denke das der Free-Plan dies auch in sieben Prompts dies hinbekommt. Fehler war nur einer dabei, dies lag aber an meiner Apache2 Konfiguration (php-zip hatte gefehlt) und da war halt ein Prompt für eben diese Frage. Was ich mittlerweile als Wichtig empfinde ist sein Ziel klar und deutlich zu formulieren. Auch seine Gegebenheiten zu definieren ist extrem wichtig. Es nutzt halt nichts wenn ChatGPT oder Whatever sich seine Daten erraten muss. Es ist halt ein fundamentaler Unterschied ob ich als Prompt dies angebe:
1 | Erstelle mir eine Webseite in denen ich Code-Dateien präsentieren kann! |
Oder eben:
1 | Ich habe einen LAMP Server. Ich möchte eine Webseite haben, in der ich Dateien hochladen kann, diese Dateien enthalten Sourcecode. Diese Dateien möchte ich anzeigen und zum Downloaden anbieten und in die Zwischenablage kopieren lassen können. Diese Dateien sollen mit Syntaxhighlightning angezeigt werden. In dem Verzeichnis dürfen keine Dateien ausgeführt werden um ein serverseitiges Script Ausführen zu verhindern. Der Upload / Bearbeitung soll über ein Passwortgeschütztes Admin Panel realisiert werden. Ich hätte die Seite gerne im Darkmode. |
Jede KI lebt von ihren Infos - ganz einfach. Ein T. schrieb: > Leider hast Du das Thema verfehlt, hier geht es um lokale Modelle. Das ist eigentlich der andere Thread im Hardware-Forum. Wo es um die Leistungsfähigkeit der Hardware geht. Hier ging es eigentlich nie wirklich um lokale KI Modelle, wurde mal kurzfristig reingeworfen ja, aber es ging um AI im Coding allgemein.
:
Bearbeitet durch User
Uwe schrieb: > Ein T. schrieb: >> Leider hast Du das Thema verfehlt, hier geht es um lokale Modelle. > > Ich lese im Eingangsbeitrag nichts von lokalen Modellen. Vierter Absatz, erster Satz: "Vor allem interessieren mich Eure Erfahrungen mit offenen, lokalen Modellen [...]".
Ein T. schrieb: > Vor allem interessieren mich Eure Erfahrungen mit offenen, lokalen > Modellen, wie DeepSeek Coder, Qwen und Co im Vergleich zu kommerziellen > Modellen wie CodeGPT oder Claude. Danke, sorry, hatte ich übersehen. Mich würde auch interessieren, wieviel "schlechter" die freien, lokalen Modelle sind. Aus meiner Erfahrung mit Claude und dem was ich über Experimente mit lokalen Modellen auf normalen Maschinen gelesen hab: Es liegen Welten dazwischen, bei Präzision, Antwortzeit, Kontextwindow. Würde mich freuen wenn jemand gegenteilige Erfahrungen berichten kann.
Uwe schrieb: > ürde mich freuen > wenn jemand gegenteilige Erfahrungen berichten kann. Sofern man eine Möglichkeit des standardisierten Vergleiches hätte. Ohne könnte man zumindest behaupten, dass mit entsprechend gut beschriebenen Fragen, eventuell mit Links dazu, die KIs ganz ordentlich antworten. Ganz abgesehen davon wissen die KIs schon, dass Claude für Programmierfragen am längeren Hebel sitzt. Es ist doch so: man muss selber auch nach Fragemöglichkeiten schauen - denn mittlerweile kann man z.B. schon sehr gute Beschreibungen von z.B. kommerziellen Herstellungsprozessen bekommen - was früher eher schwierig war, herauszubekommen. Wer es wirklich drauf anlegt zu lernen, wird so oder so gute Hilfe finden. Sehr merkwürdig fand ich, dass die KI auch kreativ unterwegs sind und super smalltalk können. Da kann ein gewisser DATA allenfalls von träumen. Fragt doch mal sowas: wie werde ich zu einem guten KI-Flüsterer? ;)
> Danke, sorry, hatte ich übersehen. Mich würde auch interessieren, > wieviel "schlechter" die freien, lokalen Modelle sind. Aus meiner > Erfahrung mit Claude und dem was ich über Experimente mit lokalen > Modellen auf normalen Maschinen gelesen hab: Es liegen Welten > dazwischen, bei Präzision, Antwortzeit, Kontextwindow. Würde mich freuen > wenn jemand gegenteilige Erfahrungen berichten kann. Direkte Vergleichbarkeit ergibt sich wohl nur aus standardisierten Benchmarks. Die Real Life Experience schwankt stark, wobei man immer beachten muss, was man testet: Nur das reine LLM oder die mittlerweile spezifischen Frameworks wie Codex, Claude Code, etc. Wenn man sich z.B. solche Vibe Coding Frameworks ansieht, sieht man schnell, dass hier sorgfältig erstellte Skills & Tools mehr zum Ergebnis beitragen als das LLM. Rein LLM bezogen sind die kommerziellen Frontier-Modelle wie Claude & GPT 5.4 im Zero Shot deutlich überlegen. Sobald aber eine Agent-Chain dahintersteckt können lokale Modelle wie Qwen3-Coder-Next u.a. gut aufholen. Würde ich mich auf ein Modell alleine verlassen? Nein. Dazu machen auch die Frontier-Modelle triviale Fehler die vermeidbar wären.
Uwe schrieb: > Mich würde auch interessieren, > wieviel "schlechter" die freien, lokalen Modelle sind. Genau das interessiert mich auch sehr. > Aus meiner > Erfahrung mit Claude und dem was ich über Experimente mit lokalen > Modellen auf normalen Maschinen gelesen hab: Es liegen Welten > dazwischen, bei Präzision, Antwortzeit, Kontextwindow. Würde mich freuen > wenn jemand gegenteilige Erfahrungen berichten kann. Nunja, es gibt so ein paar Aussagen dazu, darunter auch einige, die ich als durchaus vertrauenswürdig einschätzen würde. Die großen Modelle wie Qwen3.5 oder DeepSeek-Coder sollen wohl ähnlich gut funktionieren wie ChatCPT Codex und Claude Opus, zumindest, wenn die "großen" Varianten sind, die aber eine entsprechend leistungsfähige Hardware benötigen. Nur zum Vergleich: Qwen3.5 mit 27 Milliarden Parametern hat, heruntergerechnet auf 8 Bit kleine Gewichte, hat meinen etwas älteren E5580 mit i7-7820HQ und 32 GB DDR4-RAM schon sehr an seine Grenzen gebracht, und ohne Nutzung der ohnehin vollkommen ungeeigneten Grafikkarte nur ein halbes Token pro Sekunde erzeugt. So macht das jedenfalls keinen großen Spaß, es sei denn, ich mach das wieder so wie zuletzt mit Tensorflow- und PyTorch-NLP auf demselben System: am Abend wird die Berechnung gestartet und morgens arbeite ich mit dem Ergebnis weiter. Das könnte dann zumindest eine Möglichkeit bieten, kostenpflichtige Tokens bei den großen Anbietern einzusparen: quasi nachts das Programm vom lokalen Modell erzeugen und es am nächsten Tag von einem Cloud-Modell korrigieren, verfeinern und verbessern zu lassen -- denn eines muß bei diesem kleinen Qwen-Modell klar sein: produktionsreifen Code erzeugt das definitiv nicht. (1) Allerdings ist Qwen3.5-27B natürlich immer noch ein recht kleines Modell, das größte Modell dieser Serie verwendet mit 397 Milliarden vierzehn Mal so viele Parameter. Das geht auch auf einem großen Rechner sicherlich nicht mehr -- wie bei mir -- auf der CPU, sondern dazu ist sind GPUs mit vielen Recheneinheiten und exorbitant großem Videospeicher notwendig, wenn da nicht alle zehn Stunden mal ein einzelnes kleines Token herauspurzeln soll. :-) Insofern denke ich, Stand heute, daß die freien Modelle zwar in den kleineren Versionen noch nicht gänzlich an die großen kommerziellen Modelle herankommen, jedoch auch nicht völlig unbrauchbar sind. Sicherlich benötigen sie ein wenig mehr Nacharbeit, aber stupiden Boilerplate bekommen sie IMHO genauso gut hin. Richtig spannend wäre es mal, die großen freien Modelle wie Qwen3.5-327B oder sogar DeepSeek-Coder mit 671 Milliarden Parametern (!) auszuprobieren, aber... für die Kosten der dazu notwendigen Hardware kann man bei allen kommerziellen Anbietern seeehr viele Token kaufen. :-) (1) ChatGPT Codex jedoch auch nicht -- dem hatte ich dieselbe Aufgabe gegeben wie meinen lokalen Modellen, und es hat ebenfalls zwei Importfehler generiert, mithin die Hälfte des Qwen3.5-27B, das deren vier produziert hat. Qwen3.5-9B kam ebenso wie Qwen3.5-4B auf je fünf Importfehler, Qwen3.5-0.8B hat sich sehr frühzeitig in einer Endlosschleife aufgehängt.
1N 4. schrieb: > Wenn man sich z.B. solche Vibe Coding Frameworks ansieht, sieht man > schnell, dass hier sorgfältig erstellte Skills & Tools mehr zum Ergebnis > beitragen als das LLM. Das ist eine sehr interessante Aussage, könntest Du dazu vielleicht noch ein bisschen mehr sagen? Danke! > Würde ich mich auf ein Modell alleine verlassen? Nein. Dazu machen auch > die Frontier-Modelle triviale Fehler die vermeidbar wären. Ach, sei nicht so streng, Menschen machen ja auch Fehler. (Außer natürlich den Teilnehmern dieses Forums, denen unterlaufen niemals welche.) :-)
>> Wenn man sich z.B. solche Vibe Coding Frameworks ansieht, sieht man >> schnell, dass hier sorgfältig erstellte Skills & Tools mehr zum Ergebnis >> beitragen als das LLM. > Das ist eine sehr interessante Aussage, könntest Du dazu vielleicht noch > ein bisschen mehr sagen? Danke! AI-Coding-Tools liefern ihre Qualität primär durch sorgfältig kuratierte System-Prompts, Tool-Definitionen, RAG-Kontexte und Agentic-Scaffolding – das Modell selbst trägt je nach Task-Komplexität vielleicht 30-40% bei. Die eigentliche IP steckt im Tooling und Workflow-Design; wer das versteht, kapiert auch, warum „better scaffolding" oft mehr bringt als ein Modell-Upgrade – außer bei echter Architekturarbeit oder mehrstufigem Debugging, wo Reasoning-Tiefe dann doch den Unterschied macht.
1N 4. schrieb: > AI-Coding-Tools liefern ihre Qualität primär durch sorgfältig kuratierte > System-Prompts, Tool-Definitionen, RAG-Kontexte und Agentic-Scaffolding > – das Modell selbst trägt je nach Task-Komplexität vielleicht 30-40% > bei. Die eigentliche IP steckt im Tooling und Workflow-Design; wer das > versteht, kapiert auch, warum „better scaffolding" oft mehr bringt als > ein Modell-Upgrade – außer bei echter Architekturarbeit oder > mehrstufigem Debugging, wo Reasoning-Tiefe dann doch den Unterschied > macht. Vielen Dank für die Infos, da muß ich wohl jetzt mal ein bisschen lesen. :-)
Man ist ja neugierig.^H^H^H^H^H^H^Hwissbegierig. Ich habe gerade mal eine meiner schon seit Ewigkeiten existierenden 6502 Assembler Routinen versucht per sehr präziser und wohl formulierter Beschreibung von ›Claude Haiku‹ erstellen/nachbauen lassen. Wichtig dabei war maximale Ausführungsgeschwindigkeit, koste es was es wolle. Dabei hatte ich dem System einen Spielraum eingerichtet um zwischen zwei möglichen Ansätzen zu entscheiden. Da ich mit 100% Gewissheit sagen kann, das diese Routine nicht auch nur um einen einzigen Prozessor-Zyklus verbessert werden kann, war ich sehr gespannt auf das Ergebnis, für das ich auch gleich eine Laufzeitanalyse anforderte. Den Ersten Versuch gelesen welcher bereits innerhalb weniger Programmzeilen scheiterte. Und zwar da eine Funktionalität verwendet wurde, welche gar nicht existiert. Darauf habe ich mit einem beschreibenden Satz hingewiesen und bekam das typische ›Du hast vollkommen recht — entschuldige diesen fundamentalen Fehler! Der 6502 kann die X-Seite nicht automatisch in die Adresse einblenden. Das war Unsinn.‹ Die nächste Version war dann tatsächlich schon Funktionell und sogar einigermaßen nahe am Optimum. Inklusive der Laufzeitanalyse des erstellten Codes welche – noch besser – nur um wenige Zyklen abwich. Interessanterweise an zwei ähnlichen Stellen unnötigerweise fehlerhaft. Dennoch, das war das erste Mal, dass mich so ein System fast schon ein wenig beeindruckt hat. Allerdings brauchte das Erstellen des präzisen Prompts, das Durchlesen und finden des eingebauten Fehlers, das Korrekturprompt und die zweite Verifikation mehr Zeit als eine Programmierung von Hand. Und wenn ich's hätte assemblieren (wäre formell fehlerfrei gewesen) und testen müssen (da hätte man den Speicher inspizieren müssen) noch deutlich länger. Aber immerhin…
Der next hot shit ist die wiggum loop, benannt nach einer "The Simpsons"-Figuren. Man füttert per script claude,... bis das rauskommt was man haben möchte also ähnlich dem früher hypotetischen monkey coding, im Gegensatz zu diesem liefert wiggum loop brauchbare Ergebnisse, nach Stunden oder Tagen, was aber egal ist weil man selber daran nicht arbeiten muss. https://ghuntley.com/ralph/
:
Bearbeitet durch User
Norbert schrieb: > Ich habe gerade mal eine meiner schon seit Ewigkeiten existierenden 6502 > Assembler Routinen versucht per sehr präziser und wohl formulierter > Beschreibung von ›Claude Haiku‹ erstellen/nachbauen lassen. Von den 3 Claude Modellen, die man z.B. bei Github Copilot zur Auswahl hat, ist Haiku das kleinste/billigste, Sonnet das mittlere und Opus das größte. Von den Preisen her (und damit vielleicht auch von der Rechenleistung?) ist da jeweils ein Faktor 3 dazwischen. > Dennoch, das war das erste Mal, dass mich so ein System fast schon ein > wenig beeindruckt hat. > > Allerdings brauchte das Erstellen des präzisen Prompts, das Durchlesen > und finden des eingebauten Fehlers, das Korrekturprompt und die zweite > Verifikation mehr Zeit als eine Programmierung von Hand. Und wenn ich's > hätte assemblieren (wäre formell fehlerfrei gewesen) und testen müssen > (da hätte man den Speicher inspizieren müssen) noch deutlich länger. Wie wäre es denn bei einem Menschen gewesen? Also nicht Du, sondern z.B. ein Arbeitskollege, der Assembler kann, aber noch nie mit einem 6502 gearbeitet hat und auch nicht in dem Projekt arbeitet. Wie präzise hättest du das formulieren müssen, wie lange hätte er gebraucht die Doku zu sichten und es zu bauen und zu testen?
Markus K. schrieb: > Wie wäre es denn bei einem Menschen gewesen? Also nicht Du, sondern z.B. > ein Arbeitskollege, der Assembler kann, aber noch nie mit einem 6502 > gearbeitet hat und auch nicht in dem Projekt arbeitet. Wie präzise > hättest du das formulieren müssen, wie lange hätte er gebraucht die Doku > zu sichten und es zu bauen und zu testen? Das kann ja nicht die Zielfrage sein. Ich hole mir für so etwas ja nicht Käti und Pläti von der Straße. Die Frage müsste lauten: Wenn jemand nur durchschnittlich gut in dieser Art der Programmierung ist, hätte ihm das System geholfen? Schwierig zu sagen. Ohne tiefer gehende Kenntnisse hätte er noch nicht einmal den Fehler erkennen können. Geschweige denn zielgerichtet Anweisungen zur Behebung zu geben. Alles hätte assembliert, es wäre auch ohne Fehlermeldung gelaufen. Nur eben nicht bis ins Letzte funktioniert wie gefordert. Damit man so ein System vernünftig benutzen und anwenden kann, muss man die Thematik verstehen und es im Grunde genommen selbst gut machen können.** Bei den kleineren Gimmicks, welche vieltausendfach im Netz herum schwirren, ginge das vermutlich mit etwas Einarbeitungszeit. Daher kommen ja auch die Jubel-Stories. Sobald es aber speziell wird sehe ich zur Zeit noch keine Chance. Außer selbst lernen (und zwar wirklich gut und eingehend lernen) um so die Fehler erkennen zu können. Sonst rennt man Stundenlang, Tagelang blind allen möglichen falschen Fährten hinterher und dreht sich doch nur im Kreis. Trotzdem kann so ein System in engen Grenzen hilfreich sein. Zum Beispiel kann man sich Online Dokus riesiger Pakete bequemer und zielgeführter suchen lassen um sich dann selbst zu informieren. Das große Problem das ich persönlich sehe, ist das unbegrenzte Vertrauen auf eine bequeme Lösung und der damit einhergehende arg begrenzte Wunsch wirklich selbst zu lernen und sich und sein Denken zu verbessern. Ich werde das sicher als ›Helferlein‹ im Auge behalten, aber bei der Software Erstellung in meinem Bereich kann ich mir keine Fehler leisten und deshalb keinesfalls auf die angebotenen, augenscheinlich korrekten Lösungen zu vertrauen. Und das wird noch eine vermutlich sehr lange Zeit so sein. Segen und Fluch zugleich… **Wenn er es selbst geschrieben hätte, präzise nach den gegebenen Anweisungen, dann wüsste er um jeden programmierten Schritt. Die ersten Male sicherlich etwas zäher, weil viel gelernt und gelesen werden müsste. Dann aber flüssiger und mit immer mehr Verständnis. Eigenem Verständnis.
:
Bearbeitet durch User
Christoph M. schrieb: > Wenn man es sehr einfach haben will, braucht man ja nur 3 Befehle in der > Linux-Kommandozeile um ollama zu installieren, ein Modell zu holen und > laufen zu lassen: > Beitrag "Re: Erfahrungen mit AI-Coding" Danke für die Info, hab das gerade mal gemacht und hat tadellos funktioniert. Als Modell habe ich qwen2.5:7B genutzt. Hat seine Arbeit relativ gut verrichtet. Aber wie kann man die "Token" messen / sehen? Wie macht sich das bemerkbar? Ich lese hier oft von 1T pro Sekunde... Aber wie, wo sieht man das oder merkt man das?!?
Rene K. schrieb: > Aber wie, wo sieht man das oder > merkt man das?!? Mit Ollama musst du das Modell mit ollama run --verbose qwen3.5:9b starten. Dann wird nach jeder Antwort eine Statistik ausgegeben: total duration: 3m45.970937988s load duration: 248.67934ms prompt eval count: 11 token(s) prompt eval duration: 930.925017ms prompt eval rate: 11.82 tokens/s eval count: 819 token(s) eval duration: 3m44.160545887s eval rate: 3.65 tokens/s Das kommt von Qwen3.5:35b (Q4_K_M) bei dem Prompt: "Hi" auf nem einfachen DDR4 dual Channel System ohne GPU. Das ist ein A3b Modell. Also von den 35b Parametern werden für jedes output Token nur 3b aktiviert. Es braucht also Speicher wie ein 35b Parameter, ist aber so schnell wie ein 3b Modell. Aber schlechter als das vollbesetzte 27b Modell von Qwen. Ich melde mich morgen mal, ob das meinen coding Test irgendwie sinnvoll bearbeitet hat...
:
Bearbeitet durch User
Norbert schrieb: > Markus K. schrieb: >> Wie wäre es denn bei einem Menschen gewesen? Also nicht Du, sondern z.B. >> ein Arbeitskollege, der Assembler kann, aber noch nie mit einem 6502 >> gearbeitet hat und auch nicht in dem Projekt arbeitet. Wie präzise >> hättest du das formulieren müssen, wie lange hätte er gebraucht die Doku >> zu sichten und es zu bauen und zu testen? > > Das kann ja nicht die Zielfrage sein. Ich hole mir für so etwas ja nicht > Käti und Pläti von der Straße. Das habe ich auch nicht geschrieben. Jemand der Assembler kann ist ja nicht der nächstbeste von der Straße. > Die Frage müsste lauten: Wenn jemand nur > durchschnittlich gut in dieser Art der Programmierung ist, hätte ihm das > System geholfen? Der Punkt ist: Wie extrem sind die Aufgabenstellungen eigentlich? Wie viele Softwareentwickler können diese Aufgaben überhaupt lösen/schlecht lösen/gut lösen/besser als Du lösen? Du hast durchaus zu recht betont, dass man der KI die Aufgaben recht gründlich beschreiben sollte. Ist das bei Menschen anders? Klar, wer so ähnliche Projekte schon ein paar mal gemacht hat, dem reichen ein paar Andeutungen, aber für die anderen ist das ja nicht unbedingt so.
Rene K. schrieb: > Ich lese hier oft von 1T pro Sekunde... Aber wie, wo sieht man das oder > merkt man das?!? Token sind so was ähnliches wie Silben. Kurze Wörter können auch ein Token sein. Satzzeichen auch. Token hat man zum einen beim Verarbeiten, also Deine Anfrage und bei einer Konversation die Texte beider(!) Seiten. Bis zur Kontextlänge. Bei der Ausgabe ist das halt die Antwort. Das ist entsprechend die Antwortgeschwindigkeit. Bei 1 Token/s sind das halt 1-2s pro Wort. Wenn die Antwort 1000 Wörter hat, dann wartest Du halt eine halbe Stunde, bis die Antwort fertig ist. Hat das System einen internen Monolog ("Thinking" Modelle), dann zählt das auch.
Norbert schrieb: > Ich habe gerade mal eine meiner schon seit Ewigkeiten existierenden 6502 > Assembler Routinen versucht per sehr präziser und wohl formulierter > Beschreibung von ›Claude Haiku‹ erstellen/nachbauen lassen. Die Zeiten des C64 sind sehr lange vorbei, und außerhalb seltener Nischen wie beispielsweise der Treiberentwicklung und Mikrocontrollern benutzt heute kaum noch jemand Assembler. Die 6502 sind alt, und zu deren Zeit hat keiner seinen Code in öffentliche Repos gelegt, ganz einfach weil es keine gab und auch das Internet noch nicht einmal in seinen Kinderschuhen gesteckt hat. Und was die Assembler Routine am Ende tut, dazu sagst Du nicht einmal was und verwendest obendrein auch noch das kleinste der verfügbaren Modelle. Deine Beschreibung liest sich für mich also wie eine Neuauflage von "ich gebe dem LLM eine möglichst exotische Aufgabe und habe gewonnen wenn sie die nicht sofort perfekt lösen kann". Aber viel wichtiger ist, daß die Lösungen solcher Nischenexoten natürlich rein gar nichts darüber aussagen können, was die LLMs letztlich zu leisten vermögen, und nochmal weniger, wie viel Entwicklungszeit und -Arbeit damit gespart werden kann. Vor allem geht Dein Beitrag allerdings leider am Thema "lokale LLMs" vorbei, das ausdrücklich das Thema dieses Threads ist.
Mathias M. schrieb: > Mit Ollama musst du das Modell mit ollama run --verbose qwen3.5:9b > starten. Dann wird nach jeder Antwort eine Statistik ausgegeben: Ich erhalte mit anderem Rechner und kleinerem Modell:
1 | ollama run --verbose qwen3.5:0.8b |
2 | |
3 | Hi! How can I help you today? |
4 | |
5 | total duration: 2m6.027021614s |
6 | load duration: 329.162974ms |
7 | prompt eval count: 11 token(s) |
8 | prompt eval duration: 332.985942ms |
9 | prompt eval rate: 33.03 tokens/s |
10 | eval count: 899 token(s) |
11 | eval duration: 2m4.599540528s |
12 | eval rate: 7.22 tokens/s |
Hat jemand eine NVIDIA-Graphikkarte und könnte eines der beiden Modelle mal darau laufen lassen?
Markus K. schrieb: > Der Punkt ist: Wie extrem sind die Aufgabenstellungen eigentlich? Die Aufgabenstellung ist einfach erfassbar. Maximale Ausführungsgeschwindigkeit. Zwei getrennte Speicherbereiche, einen löschen, den anderen mit einem Wert in ›Y‹ beschreiben. Beide Bereiche sind kein vielfaches der Page-Größe. Aber ich hatte dem System überlassen selbst zu entscheiden ob es lieber präzise oder bis zur jeweiligen Page-Grenze löschen/setzen möchte. Die inhärente Gemeinheit findet sich in der Tatsache, dass für die beiden Bereiche zwei unterschiedliche Strategien erforderlich wären. Beide Male die gleiche Strategie führt zur Verlängerung der Zeit. Aber das ist für einen Programmierer sehr schnell offensichtlich. Der von Hand-erstellte Assembler Code ist übrigen gerade einmal 18 Zeilen lang und hat eine Laufzeit von 48011 Zyklen (inkl. RTS, exkl. aufrufendes JSR) Voraussetzungen an Programmierer: Man muss den erlaubten Befehlssatz kennen und die Zykluszeiten. Diese Information standen seit '76 zur freien Verfügung. Ein wenig rechnen und vor allem Sinn-ergreifend denken. Vielleicht die zwei unterschiedlichen Strategien anwenden und jeweils die bessere nehmen. > Wie viele Softwareentwickler können diese Aufgaben überhaupt lösen Alle > gut lösen Die Meisten > besser als Du lösen? Niemand. Das hat aber absolut nichts mit mir oder meinen Fähigkeiten zu tun. Vielmehr ist es so, das es genau eine optimale (aber Speichermäßig völlig untragbare) Lösung gibt (27005 Bytes/36010 Zyklen) Und die zweitbeste Lösung ist die oben genannte. Sie kann nicht mehr verbessert werden. Wie gesagt, das System ist ja durchaus bis in einen akzeptablen Bereich gekommen. Warum es allerdings seinen eigenen Code mit den korrekten Zyklen kommentiert, die Laufzeit jedoch trotzdem falsch berechnet, das verschließt sich mir. Ein T. schrieb: > … Da das System schlussendlich einen lauffähigen Code erzeugte, erübrigt es sich auf deine restlichen Kommentare zu antworten.
Norbert schrieb: > Ein T. schrieb: >> … > Da das System schlussendlich einen lauffähigen Code erzeugte, erübrigt > es sich auf deine restlichen Kommentare zu antworten. Wenn Du von Norbert schrieb: > [...] inhärente Gemeinheit [...] sprichst, eher nicht. Inhärente Gemeinheiten sind genau das, was mit "ich gebe dem LLM eine möglichst exotische Aufgabe und habe gewonnen wenn sie die nicht sofort perfekt lösen kann" gemeint war.
> Hat jemand eine NVIDIA-Graphikkarte und könnte eines der beiden Modelle > mal darau laufen lassen? Da kommen dann lockar 200t/s raus, aber wofür möchtest du ein 0.8B Modell verwenden, mit welcher Erwartungshaltung?
Ein T. schrieb: > sprichst, eher nicht. Inhärente Gemeinheiten sind genau das, was mit > "ich > gebe dem LLM eine möglichst exotische Aufgabe und habe gewonnen wenn sie > die nicht sofort perfekt lösen kann" gemeint war. Das ist kolossaler Unsinn. Wie ausführlich beschrieben, besteht die "Gemeinheit" einzig und allein darin, dass die zu füllenden Bereiche nicht an Page-Grenzen enden und es deshalb zumindest ein wenig rudimentäre Intelligenz braucht um das zu erkennen. Wer nun aber gar nicht denken kann, erstellt einfach zwei Routinen mit den jeweiligen Strategien als Ende-Bedingung und vergleicht diese anschließend. Ad: Im Übrigen ist das auch keine exotische Aufgabe, sondern eine im laufenden System oft genutzte Funktion.
:
Bearbeitet durch User
Mathias M. schrieb: > Mit Ollama musst du das Modell mit ollama run --verbose qwen3.5:9b > starten. Dann wird nach jeder Antwort eine Statistik ausgegeben: > > total duration: 3m45.970937988s > load duration: 248.67934ms > prompt eval count: 11 token(s) > prompt eval duration: 930.925017ms > prompt eval rate: 11.82 tokens/s > eval count: 819 token(s) > eval duration: 3m44.160545887s > eval rate: 3.65 tokens/s Ahh okay cool!
1 | draconix@Rene:~$ ollama --verbose run qwen2.5-coder:7b |
2 | >>> Hi! |
3 | Hello! How can I assist you today? |
4 | |
5 | total duration: 644.654796ms |
6 | load duration: 156.476126ms |
7 | prompt eval count: 31 token(s) |
8 | prompt eval duration: 260.069577ms |
9 | prompt eval rate: 119.20 tokens/s |
10 | eval count: 10 token(s) |
11 | eval duration: 190.879912ms |
12 | eval rate: 52.39 tokens/s |
Ich probiere das mal mit qwen 3.5:9b aus.
1N 4. schrieb: > Da kommen dann lockar 200t/s raus, aber wofür möchtest du ein 0.8B > Modell verwenden, mit welcher Erwartungshaltung? Es wird ja von der Grafikkarte abhängen. Wie wäre es mit GTX5060?
Rene K. schrieb: > prompt eval rate: 119.20 tokens/s Du müsstest schon dein Setup mit angeben, sonst kann man ja wenig daraus schließen.
Christoph M. schrieb: > Du müsstest schon dein Setup mit angeben, sonst kann man ja wenig daraus > schließen. Achso, ja... ein alter Testrechner mit einem I7-9800x / 16GB und einer RTX2070 mit 8GB. Auf was er da nun rechnet, keine Ahnung. Rene K. schrieb: > Ich probiere das mal mit qwen 3.5:9b aus. Ich habe da nunmal qwen3.5:0.8b mit einem "Hi!" laufen lassen, da hat er sich in einer endlossschleife überlegt, was er nun sagen könne... bevor er dann depressiv wird, habe ich abgebrochen :-D Siehe Anhang... Mit qwen3.5:9b:
1 | Draconix@Rene~$ ollama run qwen3.5:9b |
2 | >>> Hi! |
3 | Thinking... |
4 | Thinking Process: |
5 | |
6 | 1. **Analyze the Input:** |
7 | * Input: "Hi!" |
8 | * Intent: Greeting. |
9 | * Tone: Friendly, casual. |
10 | * Expected Response: Acknowledge the greeting, offer assistance, maintain a friendly tone. |
11 | |
12 | 2. **Determine the appropriate response:** |
13 | * Standard greeting response: "Hello!" or "Hi there!" |
14 | * Offer help: "How can I help you today?" or "What's on your mind?" |
15 | * Keep it concise but warm. |
16 | |
17 | 3. **Draft potential responses:** |
18 | * "Hello! How can I assist you today?" |
19 | * "Hi! How's it going? Anything I can help you with?" |
20 | * "Hey there! What do you need?" (Too blunt) |
21 | * "Hi! Welcome! How can I help you?" (Good balance) |
22 | |
23 | 4. **Select the best option:** |
24 | * "Hi there! How can I help you today?" is polite, friendly, and open-ended. |
25 | |
26 | 5. **Final Polish:** Ensure it sounds natural. |
27 | * "Hello! How can I help you today?" |
28 | |
29 | 6. **Final Output Generation:** (Matches the selected option). |
30 | ...done thinking. |
31 | |
32 | Hello! How can I help you today? |
33 | |
34 | total duration: 2.20826532s |
35 | load duration: 283.887341ms |
36 | prompt eval count: 35 token(s) |
37 | prompt eval duration: 450.158065ms |
38 | prompt eval rate: 77.75 tokens/s |
39 | eval count: 25 token(s) |
40 | eval duration: 1.452489512s |
41 | eval rate: 17.21 tokens/s |
42 | >>> Send a message (/? for help) |
Angehängte Dateien:
-
ollama.png
240 KB
Sooo... um mal direkt Ollama auf Herz und Nieren zu testen, habe ich mir mal mal direkt eine Webseite / Webinterface durch Ollama erstellen lassen. Das Ergebnis kann sich, meiner Meinung nach, sehen lassen... Ging auch recht zügig....
Angehängte Dateien:
-
ollama_1_.png
240 KB
Rene K. schrieb: > Sooo... um mal direkt Ollama auf Herz und Nieren zu testen, habe > ich mir > mal mal direkt eine Webseite / Webinterface durch Ollama erstellen > lassen. Das Ergebnis kann sich, meiner Meinung nach, sehen lassen... > Ging auch recht zügig.... Reschpeckt!
Rene K. schrieb: > Achso, ja... ein alter Testrechner mit einem I7-9800x / 16GB und einer > RTX2070 mit 8GB. Auf was er da nun rechnet, keine Ahnung. Immer hin eine RTX (2560 Cuda Cores). Um zu sehen, wo das Modell läuft: Ollma Model laufen lassen, dann in anderem Fenster
1 | ollama ps |
2 | NAME ID SIZE PROCESSOR CONTEXT UNTIL |
3 | qwen3.5:0.8b f3817196d142 2.1 GB 100% CPU 4096 4 minutes from now |
(In meinem Fall leider nur CPU..)
Rene K. schrieb: > Sooo... um mal direkt Ollama auf Herz und Nieren zu testen, habe ich mir > mal mal direkt eine Webseite / Webinterface durch Ollama erstellen > lassen. Das Ergebnis kann sich, meiner Meinung nach, sehen lassen... > Ging auch recht zügig.... Sieht gut aus. Du könntest das File hier posten, dann kann man es mal ausprobieren.
Christoph M. schrieb: > Um zu sehen, wo das Modell läuft: Ollma Model laufen lassen, dann in > anderem Fenster Oh danke... dann bei mir scheinbar auf der GPU:
1 | Draconix@Rene:~$ ollama ps |
2 | NAME ID SIZE PROCESSOR CONTEXT UNTIL |
3 | qwen3.5:9b 6488c96fa5fa 8.9 GB 28%/72% CPU/GPU 4096 4 minutes from now |
Christoph M. schrieb: > Sieht gut aus. Du könntest das File hier posten, dann kann man es mal > ausprobieren. Mach ich, ich lade es in ein paar Minuten auf meine Webseite hoch. Läuft aktuell auf Debian 13 und benötigt wird Apache2, php8, php-curl, php-mbstring und libapache2-mod-php Link folgt dann gleich... ÄDITH: https://ki.draconix.org/Ollama.zip
:
Bearbeitet durch User
Rene K. schrieb: > Oh danke... dann bei mir scheinbar auf der GPU: > eval duration: 1.452489512s Da merkt man ja schon einen gewaltigen Unterschied durch die RTX2070 im Vergleich zu meinem alten rein CPU bassierten I5-2500Kx4 System.
1 | eval duration: 2m4.599540528s |
Rene K. schrieb: > Link folgt dann gleich... > > ÄDITH: https://ki.draconix.org/Ollama.zip Äh .. danke :-) Mich wundert, dass es PHP genommen hat. Eigentlich müsst das doch kompakt in einem HTML-File mit eingebetteten JS möglich sein.
:
Bearbeitet durch User
>> Da kommen dann lockar 200t/s raus, aber wofür möchtest du ein 0.8B >> Modell verwenden, mit welcher Erwartungshaltung? > Es wird ja von der Grafikkarte abhängen. Wie wäre es mit GTX5060? Verstehe den Benchmarking-Sinn trotzdem nicht :D Auf Strix Halo kommen so 180t/s raus, könnte mal noch die alte RTX3060 testen. Oder morgen bei der Arbeit eine Nvidia B200 gegen eine AMD MI355X antreten lassen. Aber irgendwie sinnfrei sich eine Spiele-Graka mit Mager-VRAM dafür nutzen zu wollen.
Wir könnten ja mal ein bis drei offizielle mikrocontroller-net-benchmark-prompts schreiben, ums besser vergleichen zu können. Beispiel: Du bist ein erfahrener Software-Entwickler, aber sprichst nur Ostfriesisch und fast kein Englisch. Erstelle ein python-Skript, um eine Sinusfunktion im Bereich 0 bis 4 Pi darzustellen. Nutze plotly.
Hier gibt es eine schöne Übersicht mit qwen-Benchmarks, leider nicht von den ganz kleinen Netzen, geht erst ab 9b los https://llmdev.guide/
Angehängte Dateien:
-
ollama.jpg
310 KB
Christoph M. schrieb: > Äh .. danke :-) > Mich wundert, dass es PHP genommen hat. Eigentlich müsst das doch > kompakt in einem HTML-File mit eingebetteten JS möglich sein. ja, ich schreibe zu 95% meine Webseiten in PHP :-D Das war eine beim Prompt eine Anforderung. Das ist quasi meine Schuld. Aber ich finde das okay soweit, ich kann PHP besser als JS. Jetzt ist das Web-Interface ein wenig "verbessert": Man kann mehrere Chats haben, Sourcecode hat nun Syntax-Highlighting, man kann Code direkt per Button kopieren, die Anwtort wird jetzt gestreamt, während die LLM arbeitet und denkt - kann man sich dies nun streamen lassen - das wird bei Antwort dann direkt ausgeblendet Uwe schrieb: > Du bist ein erfahrener Software-Entwickler, aber sprichst nur > Ostfriesisch und fast kein Englisch. Erstelle ein python-Skript, um eine > Sinusfunktion im Bereich 0 bis 4 Pi darzustellen. Nutze plotly. Also qwen3.5:9b verfranzt sich dann völlig in der Anweisung Ostfriesisch zu sprechen. Sein ganzes "Denken" dreht sich dann nur noch darum "Low-German or German?". Ohne diese Anweisung läuft er sehr sauber durch und macht eine schöne Funktion daraus.
Norbert schrieb: > Das ist kolossaler Unsinn. Keineswegs. > Wie ausführlich beschrieben, besteht die "Gemeinheit" einzig und allein > darin, dass die zu füllenden Bereiche nicht an Page-Grenzen enden und es > deshalb zumindest ein wenig rudimentäre Intelligenz braucht um das zu > erkennen. Abseits davon gibt es noch mehr "Gemeinheiten": - exotische Sprache - exotische Plattform - kleinstes Modell Das ist genau die Aufgabe, die jemand stellt, der etwas scheitern sehen will. Dazu schreibst Du dann sogar noch, daß dies das erste Mal sei, daß Dich "so ein System fast schon ein wenig beeindruckt hat". Beeindruckt ist natürlich nur, wer etwas anderes erwartet hatte. > Wer nun aber gar nicht denken kann, Also ein LLM. Egal. Können wir jetzt bitte wieder auf das Thema des Threads zurückkommen?
> Also qwen3.5:9b verfranzt sich dann völlig in der Anweisung Ostfriesisch > zu sprechen. Sein ganzes "Denken" dreht sich dann nur noch darum > "Low-German or German?". Ohne diese Anweisung läuft er sehr sauber durch > und macht eine schöne Funktion daraus. default-Parameter? Da navigieren sich die kleineren Modelle gerne in eine Endlosschleife. presence_penalty und repeat_pentalty optimieren.
1N 4. schrieb: > default-Parameter? Ja als default-Parameter habe ich deutsch gesetzt bzw.: "Du bist ein hilfreicher Assistent. Antworte präzise und auf Deutsch.", das ist richtig. Ich installiere gerade mal qwen coder als agent für ollama, mal sehen wie sich das so macht, sollte da die Integration in die IDE als positiv herausstellen. So werde ich dann morgen doch mal überlegen aus meinem Renderserver die HDDs raus zu ziehen, eine extra Platte mit Debian aufzuziehen und auf die vier RTX8000 mal ein großes qwen3-coder Modell loslassen. Irgendwie Laune macht das jetzt schon, wenn man sich damit ein wenig auseinander setzt... :-D EDIT: Was sind eigentlich die Modelle mit :cloud? Also qwen3-coder:cloud?
:
Bearbeitet durch User
> Ja als default-Parameter habe ich deutsch gesetzt bzw.: "Du bist ein > hilfreicher Assistent. Antworte präzise und auf Deutsch.", das ist > richtig. Nein, ich meinte nicht den System-Prompt. Die System-Parameter des Modells, z.B. temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0 > So werde ich dann morgen doch mal überlegen aus meinem > Renderserver die HDDs raus zu ziehen, eine extra Platte mit Debian > aufzuziehen und auf die vier RTX8000 mal ein großes qwen3-coder Modell > loslassen. Warum extra Platte? > Ich installiere gerade mal qwen coder als agent für ollama, Du meinst Modell? Qwen-Coder ist nur ein Modell. Kein Agent. > Was sind eigentlich die Modelle mit :cloud? Also > qwen3-coder:cloud? Die laufen in der Ollama-Cloud.
:
Bearbeitet durch User
1N 4. schrieb: > Nein, ich meinte nicht den System-Prompt. Die System-Parameter des > Modells, z.B. temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, > presence_penalty=1.5, repetition_penalty=1.0 Achso, nein - da habe ich noch gar nichts gemacht. 1N 4. schrieb: > Warum extra Platte? Weil ich Sorge trage das ich mir da was zerschieße. Damit verdiene ich mein Hobby-Geld, das ist mir zu heiß. :-D Ist nicht so, das ich nicht genügend Platten rumliegen habe. Da mach ich nen sauberes System, wurschtel nicht auf dem Renderserver rum und meine Blutdruck bleibt ein wenig gesenkt. ;-) Soooo fit bin ich in Linux nicht. Rudimentär würde ich sagen....
Angehängte Dateien:
-
QwenCode.png
43 KB
1N 4. schrieb: > Ich installiere gerade mal qwen coder als agent für ollama, > > Du meinst Modell? Qwen-Coder ist nur ein Modell. Kein Agent. Nein: Ollama (LLM) qwen3-code (Model) Qwen Code (Agent) Qwen Code kann auf die CLI und auf das Dateisystem zugreifen, was Ollama nicht kann. So kann man es als API Agent nutzen... so wie ich das verstanden habe. Läuft und funktioniert, noch mit qwen2.5-code wegen dem geringen RAM auf der Graka von 8GB.
Ein T. schrieb: > - exotische Sprache > - exotische Plattform Assembler 6502 Ein T. schrieb: > Egal. Können wir jetzt bitte wieder auf das Thema des Threads > zurückkommen? Ein T. schrieb: > hier soll es um die Erfahrungen im Zusammenspiel verschiedener > AI-Modelle mit Programmiersprachen und IDEs gehen. Tja, das ist schon Mist, wenn das eigene Weltbild mal durchgerüttelt wird… Aber gleich soooooo dünnhäutig?
> Qwen Code kann auf die CLI und auf das Dateisystem zugreifen, was Ollama > nicht kann. So kann man es als API Agent nutzen... so wie ich das > verstanden habe. Läuft und funktioniert, noch mit qwen2.5-code wegen dem > geringen RAM auf der Graka von 8GB. Ja, richtig erkannt, Ollama ist ja auch nur der Modelserver. Qwen3-coder-next 80B sollte eigentlich komfortabel auf deinen RTX-Stack passen. Achte auf ein max. Kontextfenster. Viel Spass beim Agent-Tuning ;)
:
Bearbeitet durch User
Danke Norbert für deine Rückmeldung. Ich fasse sie kurz zusammen: Claude Haiku hat bei der Aufgabe, laufzeitoptimalen Assemblercode für den 6502 zu erzeugen, nicht das Optimum gefunden. Schön das zu wissen, um es mit anderen Konstellationen vergleichen zu können.
:
Bearbeitet durch User
Uwe schrieb: > um es mit anderen Konstellationen vergleichen zu > können. Forendiskussion hier? ;) Ich hatte die KI gestern nach einem an die 1000 Jahre alten Text gefragt, der in gewisserweise ein Vorfahre der Nachhaltigkeitslehre ist. Die kannte sogar die genaue Textstelle, den Autor und den Buchtitel. Toll, was die alles weiß. Über Assembler und Krypto weiß die auch sehr gut Bescheid, ich bin bisher da aber noch nicht in die Vollen gegangen. Genaugenommen muss ich mit Rust weitermachen, freue mich aber eigentlich schon auf die Zusammenarbeit mit der KI.
Rbx schrieb: > Ich hatte die KI gestern nach einem an die 1000 Jahre alten Text > gefragt, Geh weg. Wirres Gefasel ist hier nicht das Thema.
1N 4. schrieb: > Verstehe den Benchmarking-Sinn trotzdem nicht :D > > Auf Strix Halo kommen so 180t/s raus, könnte mal noch die alte RTX3060 > testen. Oder morgen bei der Arbeit eine Nvidia B200 gegen eine AMD > MI355X antreten lassen. Aber irgendwie sinnfrei sich eine Spiele-Graka > mit Mager-VRAM dafür nutzen zu wollen. Im Moment will ich einfach nur etwas experimentieren. Ich will mal selber eine "Ralph Wiggum Loop" programmieren und dafür brauche ich schnelle Antwortzeiten. Außerdem will ich das Budget ein wenig begrenzen. Da ja alles im Fluss ist, weiß man ja noch nicht so recht, wohin die Hardware-Reise führt.
Die Softwareabteilung hier nutz KI zur Erstellung langweiliger Testbenches und um sich in neue Prog-sprechen schnell einzuarbeiten. Wenn man bedebkt, das "Test" einen Grossteil der SW-Entwicklung ausmacht sicherlich nicht der dümmste Umgang. Anderswo wird behauptet, das KI das Testen eher ineffizient macht: https://www.heise.de/news/KI-Code-Schneller-geschrieben-langsamer-getestet-11215818.html
> Im Moment will ich einfach nur etwas experimentieren. Ich will mal > selber eine "Ralph Wiggum Loop" programmieren und dafür brauche ich > schnelle Antwortzeiten. Find ich gut! Bin gespannt wie deine Ergebnisse sind, hier hat sich Ralph öfters in einer Endlosschleife verfahren, ähnlich den kleinen Qwen-Modellen in den Thinking-Loops. Vielleicht haben die Chinesen da ja schon Ralph Wiggum kopiert? :D
1N 4. schrieb: > hier hat sich > Ralph öfters in einer Endlosschleife verfahren Wahrscheinlich würde ich
1 | while(True): |
2 | .. |
durch sowas wie
1 | for n in range(1,10): |
2 | .. |
ersetzten (naiv gesprochen).
Ja, jeglichen Agenten ein Budget zu verpassen ist seit längerem ein sinnvoller Guardrail. Nicht nur für Ralph Wiggum.
Ein T. schrieb: > Wirres Gefasel ist hier nicht das Thema. Unverständigkeit zu gewissen Themen aber auch nicht. Du hast ja auch keine konkreten Vorstellungen vorgebracht und gibst die auch nicht die Mühe, sich mit Fragen gegenüber der KI auseinanderzusetzen. Wie gesagt, Objektivierungen sind im Moment fraglich. Da müsste man erstmal Standards zum Vergleichen finden. Und wenn ich hier noch eine Maßregelung im Thread lese, dann..
Geht es nur mir so, oder hört sich der Ton dieses Threads hier auffallend scharf und territorial-gebietend an?
Ich schätze irgendwo im Kleingedruckten des Forums steht, dass höflicher Umgang zu vermeiden ist. Zumindest kann ich mir das, was in ganz vielen Threads abgeht, nicht anders erklären. Im Sinne der Leserlichkeit des Threads wäre es schön, wenn ein Mod alles offtopic rausräumt, natürlich meins auch.
Uwe schrieb: > Ich schätze irgendwo im Kleingedruckten des Forums steht, dass höflicher > Umgang zu vermeiden ist. Ich habe diesen verwirrten Menschen zunächst höflich angesprochen und gebeten, diesen Thread nur zu lesen, solange er nichts dazu beitragen könne. Das hat er aber offensichtlich nicht verstanden. Darum sage ich es deutlicher. Mit jenen, die etwas zum Thema beitragen, gehe ich höflich und respektvoll um, nur nicht mit Trollen. Daß ich das so handhabe, ist kein Zufall. > Im Sinne der Leserlichkeit des Threads wäre es schön, wenn ein Mod alles > offtopic rausräumt, natürlich meins auch. Die Aussage der Moderatoren ist, daß der Threadstarter seinen eigenen Thread moderieren sollte -- verbal, also ohne die Möglichkeiten eines Moderators zu haben. Genau das versuche ich hier und vermute, daß der "auffallend scharfe" und "territorial-gebietende" Ton dazu beigetragen haben, daß der Thread dem polarisierenden Thema zum Trotz doch weitgehend beim Thema geblieben ist. Es wäre allerdings schön, wenn meine Möglichkeiten der verbalen Moderation auch von einem Moderator unterstützt und die Off-Topic-Beiträge (inklusive meines eigenen, den Du gerade liest) gelöscht würden. Dennoch verstehe ich natürlich, daß unsere Moderatoren hier Freiwillige sind, die ohnehin schon viel mehr mit viel üblerem Zeug als genug zu tun haben.
Ich tüftel nun schon seit zwei Tagen daran rum ollama in Visual Studio Code zu integrieren. Was mich da stark wunder: Wenn ich ollama mit qwen3.5:latest nutze, dann kann der weder Code-Completion noch direkt im Code schreiben, ausschließlich der Chat funktioniert. Wenn ich aber ollama mit kimi-k2.5:cloud nutze. Dann funktioniert alles genauso wie es soll. Warum ist das so? Wieso kann ein Modell das und das andere Modell nicht? Ist das Modell abhängig? Oder liegt das an ollama?
-> Start Off-Topic: Ein T. schrieb: > Nochmals: dies ist nicht der Ort ... > für Kritik. > werde ich melden und bitte unsere hochgeschätzten > Moderatoren um deren Löschung. Meine Übersetzung: Kritik wird nicht geduldet und soll von der Leitungsassistenz gelöscht werden. Das nenn ich "Aufforderung zur administrativen Zensur". https://de.wikipedia.org/wiki/Zensur Off-Topic Ende <-
:
Bearbeitet durch User
Bradward B. schrieb: > Ein T. schrieb: >> Nochmals: dies ist nicht der Ort ... >> für Kritik. > >> werde ich melden und bitte unsere hochgeschätzten >> Moderatoren um deren Löschung. > > Meine Übersetzung: Kritik wird nicht geduldet und soll von der > Leitungsassistenz gelöscht werden. > > Das nenn ich "Aufforderung zur administrativen Zensur". > > https://de.wikipedia.org/wiki/Zensur Das siehst Du fast korrekt. Leider nur fast, weil unter "Zensur" gemeinhin eine staatliche Aktivität verstanden wird und ich zwar zweifellos vieles bin, aber ganz sicher kein Staat. Zudem hat dieser Thread ein vorgegebenes Thema, nämlich lokale AI-Modelle mit verschiedenen Programmiersprachen und IDEs. Ich versuche deswegen nur, ein Abdriften dieses Threads zu verhindern, und hoffe dabei weiterhin auf die Unterstützung unserer hochgeschätzten Moderatoren. Wer über andere Themen diskutieren oder Kritik üben will, kann jederzeit gern einen eigenen Thread dazu eröffnen, solange er die Nutzungsbedingungen dieses Forums nicht verletzt. Es darf also jeder alles sagen, das sich innerhalb des Rahmens der Nutzungsbedingungen verhält, aber nicht überall und insbesondere nicht in meinem Thread. Und auch in meinem Thread darf natürlich jeder alles sagen, solange es zum Thema gehört. Insofern geht Dein Vorwurf einer "Zensur" vollkommen an allem vorbei, was das Wort bedeutet, und ebenso an allem, was in diesem Thread geschehen ist.
Rene K. schrieb: > Warum ist das so? Wieso kann ein Modell das und das andere Modell nicht? > Ist das Modell abhängig? Oder liegt das an ollama? Frag die KI, die weiss alles.
Angehängte Dateien:
Frank D. schrieb: > Frag die KI, die weiss alles. Habe ich, und sie hat mir geholfen. :-) Nun läuft alles wunderbar in Visual Studio Code. Da ich da aber nun, natürlich, keine Übersicht und Statistik des Ollama Servers mehr habe, habe ich mir direkt eine Dashboard / Statusseite mit Proxy Backend über qwen schreiben lassen. Das Problem bei KI mittlerweile... es verleitet extrem zum spielen xD Aber ist wahnsinnig cool, wie lange hätte man wohl ohne KI an solch einer Seite gesessen?! Drei, vier Tage?! Das geschieht ja nun in wenigen Minuten... Kurios!
OT: Frank D. schrieb: > Frag die KI, die weiss alles. Sarkasmus bitte kennzeichnen. ;) Zu mindestens ChatGPT in der freien Variante nicht wirklich. Frage: Können die lokalen Modelle auch dazulernen, wenn man sie korrigiert und ich den Fehler beweisen kann? Laut einen Bekannten ist bei Cloud Varianten wie ChatGPT das nicht der Fall. Hab das aber nicht geprüft, also hab die Frage nicht nochmal gestellt. Ich habe aber ChatGPT nur als bessere Google Suche verwendet. Frage damals hat darüber gehandelt ob die KI mir die verschieden Relocation Types für AArch64 erklären kann. Hier hat ChatGPT entweder uralte oder erfundene Typen genannt. Jedenfalls keine laut aktueller Spezifikation. Auch hab ich mal zum Spaß ChatGPT gefragt ob er mir einen Pacman Klon programmieren kann. Ergebnis war nicht ganz korrekt und außerdem haben die Geister gefehlt. :) Also eigentlich suche in nach einer KI die auch das Internet benutzen kann und Sachen auch vorher wenn möglich überprüft.
:
Bearbeitet durch User
> Also eigentlich suche in nach einer KI die auch das Internet benutzen > kann und Sachen auch vorher wenn möglich überprüft. Wie soll man sich diese "überprüfung durch die KI" vorstellen ?! Klassischerweise überprüft man Code, in dem man ihm in einer Testbench gegen die Requirements stellt, also praktisch überprüft das SOLL und IST passen. Ich hab noch keine KI mit einem Testbench/Eval-Board hantieren sehen ("Keine Arme -> keine Kekse"). Also bei der Methode "trial and Error" aka "Versuch und Irrtum" wird wohl die KI nach heutigen Verständniss nicht wirklich über die Hürde helfen, nur den Zeitpunkt des Aufschlags vorziehen. Und KI-Slope macht den "Fortschtitt" soganr schwieriger. https://www.heise.de/news/KI-Slop-vs-Open-Source-KI-Branche-will-mit-12-5-Millionen-US-Dollar-helfen-11214917.html
Bradward B. schrieb: > Klassischerweise überprüft man Code, Ebenfalls hier nicht das Thema. Bitte nehmt Euch einen eigenen Thread oder diskutiert das per PN.
Rene K. schrieb: > Da ich da aber nun, natürlich, keine Übersicht und Statistik des Ollama > Servers mehr habe, habe ich mir direkt eine Dashboard / Statusseite mit > Proxy Backend über qwen schreiben lassen. Auf Deiner fetten Büchse mit den vier Computekarten? Welches Qwen-Modell hast Du benutzt und wie hat es darauf performt? > Das Problem bei KI mittlerweile... es verleitet extrem zum spielen xD Das tut normale Entwicklung ja auch... ich hab' das sooo oft, daß eine Software fertig ist und mir dann noch tausende Ideen kommen, was sie sonst noch alles können könnte. :-)
Ein T. schrieb: > Auf Deiner fetten Büchse mit den vier Computekarten? Welches Qwen-Modell > hast Du benutzt und wie hat es darauf performt? Nein, das ist auf dem Testrechner mit der RTX2070. Ich sag mal so, das "performt", Geschwindigkeitsmäßig, so wie der typische ChatGPT Prompt und in VS Code wie Copilot mit Claude. Ist halt aber auch teilweise, Größenbedingt, alte und kleine Modelle. In VS Code nutze ich aber nicht den Github Copilot Chat sondern Continue. Hier ist die aktuelle config die ich nutze, als LineCompletion nutze ich halt ein sehr kleines LLM, aber macht seine Arbeit garnicht schlecht:
1 | name: Local Config |
2 | version: 1.0.0 |
3 | schema: v1 |
4 | models: |
5 | - name: qwen3.5:9b |
6 | provider: ollama |
7 | model: qwen3.5:9b |
8 | apiBase: http://192.168.231.21/ollama-status |
9 | roles: |
10 | - chat |
11 | - edit |
12 | - apply |
13 | - name: Qwen2.5-Coder 1.5B |
14 | provider: ollama |
15 | model: qwen2.5-coder:1.5b-base |
16 | apiBase: http://192.168.231.21/ollama-status |
17 | roles: |
18 | - autocomplete |
19 | - name: Nomic Embed |
20 | provider: ollama |
21 | model: nomic-embed-text:latest |
22 | apiBase: http://192.168.231.21/ollama-status |
23 | roles: |
24 | - embed |
Rene K. schrieb: > Hier ist die aktuelle config die ich nutze, als LineCompletion nutze ich > halt ein sehr kleines LLM, aber macht seine Arbeit garnicht schlecht: Wie hast du ollama installiert? In einem Docker container oder wie hier Beitrag "Re: Erfahrungen mit AI-Coding" einfach mit curl?
Eigentlich ne ganz einfache Geschichte. In dem Testrechner läuft Debian 13 (ohne GUI). Man braucht ganz simpel nur curl und zstd und macht dann einfach:
1 | curl -fsSL https://ollama.com/install.sh | sh |
Mehr ist das dann nicht. Die Modelle mit ollama pull holen und das wars. Für die zwei Webseiten dann noch: PHP, Apache2 und ein paar php Bibliotheken. Thats it...
>> Klassischerweise überprüft man Code, > Ebenfalls hier nicht das Thema. Und wie das hier Thema ist, siehe allerersten Beitrag: Ein T. schrieb: > Mich interessieren Eure Erfahrungen mit ... Das > betrifft vor allem ... die Überprüfung der Ergebnisse,
:
Bearbeitet durch User
Bradward B. schrieb: > Ein T. schrieb: >> Mich interessieren Eure Erfahrungen mit ... Das >> betrifft vor allem ... die Überprüfung der Ergebnisse, Weiterlesen: Ein T. schrieb: > Vor allem interessieren mich Eure Erfahrungen mit offenen, lokalen > Modellen Einfach bei diesem Thema zu bleiben ist wirklich nicht schwierig. Wer nichts dazu beitragen kann, sagt dann einfach mal genau das: nichts.
Beitrag #8031255 wurde von einem Moderator gelöscht.
> Also eigentlich suche in nach einer KI die auch das Internet benutzen > kann und Sachen auch vorher wenn möglich überprüft. Das machen die Frontiermodelle eigentlich eh, ggf. dazu anweisen, das zu tun. Trotzdem kommen immer wieder lustige Dinge heraus.
Beitrag #8031282 wurde von einem Moderator gelöscht.
Beitrag #8031285 wurde von einem Moderator gelöscht.
Beitrag #8031302 wurde von einem Moderator gelöscht.
Beitrag #8031319 wurde von einem Moderator gelöscht.
Johannes schrieb: > Frage: Können die lokalen Modelle auch dazulernen, wenn man sie > korrigiert und ich den Fehler beweisen kann? Nein. Diese Netze haben immer eine Trainings- und eine Ausführungsphase und in letzterer lernen sie nicht dazu. Bei ChatGPT und Co werden die Dialoge dann für weitere Trainingsläufe benutzt (man kann ja auch die Ergebnisse bewerten), aber bei den lokalen Netzen gibt diese Schleife zum Training hin ja normalerweise nicht. Man könnte theoretisch selber nachtrainieren, aber wahrscheinlich braucht man dafür große Hardware. Man kann natürlich das gesammelte Wissen (also die Korrekturen) dem Netz immer mitgeben. Allerdings wird dadurch der Prompt immer länger und man kämpft irgendwann mit der Länge des Kontextwindows, d.h. er vergisst dann einen Teil davon wieder.
Beitrag #8031573 wurde von einem Moderator gelöscht.
Beitrag #8031581 wurde von einem Moderator gelöscht.
Beitrag #8031588 wurde von einem Moderator gelöscht.
Beitrag #8031603 wurde von einem Moderator gelöscht.
Beitrag #8031610 wurde von einem Moderator gelöscht.
Beitrag #8031621 wurde von einem Moderator gelöscht.
Jens B. schrieb im Beitrag #8031588:
> Ach ja, auf Dummheit hinweisen ist heutzutage ja voll schlecht.
Meist werden solche Skripte von genau dem Projekt angeboten, dessen
Software man ohnehin auf seinem System ausführen möchte, was man
sicherlich nicht tun würde, wenn man dem Projekt oder der Software
mißtraut. Wer derartige Basics nicht weiß, wird sie hier nicht lernen
und höchstwahrscheinlich ohnehin auch keine Experimente mit lokalen LLMs
machen, die hier das Thema sind.
Insofern ist dieser Thread nicht der richtige Ort für Deinen Hinweis,
weitere Diskussionen darüber bitte ich in einen eigenen Thread zu
verlegen.
Markus K. schrieb: > Nein. Diese Netze haben immer eine Trainings- und eine Ausführungsphase > und in letzterer lernen sie nicht dazu. Was aber durchaus interessant wäre. Geht das? Kann man freie LLM weiter anlernen? Gerade für Sachen die man selbst macht fände ich das durchaus interessant.
Rene K. schrieb: > Was aber durchaus interessant wäre. Geht das? Kann man freie LLM weiter > anlernen? Gerade für Sachen die man selbst macht fände ich das durchaus > interessant. Das kommt aufs Modell drauf an. Aber ja, das kann man durchaus machen. Nennt sich finetuning. Gibt es haufenweise von anderen. Teilweise um Zensierung oder andere Beschränkungen zu umgehen. Oder normale Modelle wurden zum Coding Modell spezialisiert. Dafür braucht man dann aber mehr Speicher und Rechenleistung. Wer also nicht einige zig-hundert k€ in GPU-power hat, muss das per Cloud machen.
Nochmal zu lokalen Modellen. Gerade ist Gemma 4 von Google veröffentlicht worden. Vier Versionen wurden veröffentlicht: 26B-A4B 31B E4B E2B Die E4/2B Modelle sind fürs Handy gedacht. Das 26B Modell läuft auf meiner 16GB RX9070 ziemlich schnell... na ja, ziemlich quantisiert natürlich (gemma-4-26B-A4B-it-UD-IQ4_NL), damit es in den ram passt. Aber dann bekomm ich 2000 t/s Prompt Processing und 95 t/s Text Generation. Zum Vergleich bei meinem DDR4 System ohne GPU liege ich bei <8 t/s PP & <2 t/s TG. Wer das nur ansatzweise ernsthaft nutzen will, ist mit 2t/s nicht zufrieden. Klar, wenn man einen wirklich guten Anforderungskatalog geschrieben hat, kommt am nächsten Morgen vielleicht auch mit 2t/s was sinnvolles raus. Aber zumindest ich muss immer wieder mal was nachbessern lassen. Dann immer 50x so lange zu warten ist absoluter Unsinn. Und die Karte kostet ja auch nur 550€. (Aber 16GB sind ja auch nicht so viel.) Obwohl es laut mehreren Berichten noch ein paar Probleme mit Gemma4 geben soll, scheint mir das ein recht fähiges Modell zu sein. edit Zumindest llama.cpp hat die größten Probleme behoben. Dauert dann etwas, bis ollama die version übernommen hat.
:
Bearbeitet durch User
Christoph M. schrieb: > Hat jemand schon mal KoboldCPP ausprobiert? > Was ist davon zu halten? > https://koboldcpp.com/ Koboldcpp ist auch nur ein llama.cpp Fork. Ich weiß jetzt nicht genau, was da anders dran ist. Anderes WebUI. Die schreiben "Optimized C++ Backend", ich glaube aber kaum, dass die llama.cpp irgendwie voraus sind. Der letzte Commit auf Github ist 2 Wochen her. In LLM-Jahren ist das eine Ewigkeit. Llama.cpp hatte heute schon 8 Commits. Jetzt ist die pure Anzahl der Commits nicht besonders aussagekräftig, aber Llama.cpp unterstützt halt neue Modelle, kobold braucht dafür immer länger. Sowieso, (lokale) LLMs bewegen sich rasend schnell. Klar kann man auch ein 6 Monate altes Modell nutzen, aber meistens gibt es halt was besseres. Wer sich da wirklich für interessiert, sollte sich irgendnen Blog oder so suchen oder besser täglich in ner Community wie https://old.reddit.com/r/LocalLLaMA/ vorbeischauen...
> Nochmal zu lokalen Modellen. Gerade ist Gemma 4 von Google > veröffentlicht worden. Vier Versionen wurden veröffentlicht: > 26B-A4B > 31B Nice. Laufen mit ~60t/s bzw. 10t/s auf dem Strix. Gleich mal in den Multimodel-Agent einbinden.
Nochmal (fast) zum eigentlichen Thema zurück, diesmal nicht "Coden" sondern allgemein die Verlässlichkeit der Aussagen von LLM. Ich hab mir einen kleinen Desktop-Galvo-Laser gegönnt, weil ich damit Platinen direkt belichten will oder - etwas einfacher - einen Schutzlack vor dem Ätzen wegbrennen. Es handelt sich um einen "Longer Nano 6W" - quasi ein Auslaufmodell (war deshalb billig) und für den Zweck mit mehr als genug Leistung. Nun muss man das Ding ja auch ansteuern und ich bin Mac-User. Das fängt schon mit einem geeigneten USB-Serial-Driver an (das Elend kenne ich von diversen Arduino- und ESP-Modellen) und endet bei der quasi Standard-Software "Lightburn" (die für sich gesehen absolut Spitze ist). Leider gibt es keine "fertige" und zuverlässig funktionierende Konfig für meinen Laser. Lange Rede kurzer Sinn: Ich habe sage und schreibe gut 2 Tage benötigt, trotz intensiver KI-Unterhaltung (ChatGPT, Grok, Gemini ...). Die haben im Detail aber alle nur Sch... erzählt. Man möchte doch meinen, diese Modelle haben Zugang zu den Hersteller-Dokumenten ... und trotzdem (fast) nur dämliche Antworten (so auf dem Niveau: "haben sie auch den Stecker drin?"), jedenfalls nichts Substanzielles. Am Ende hab ich mich selber durchgekämpft .. das Ding läuft nun.
> Nochmal (fast) zum eigentlichen Thema zurück, diesmal nicht "Coden" > sondern allgemein die Verlässlichkeit der Aussagen von LLM. Nochmal. Du bekommst damit nicht die ultimative Wahrheit. Nur die Antwort die am wenigsten falsch aus Sicht des Modelles ist.
Frank E. schrieb: > Nochmal (fast) zum eigentlichen Thema zurück, diesmal nicht "Coden" > sondern allgemein die Verlässlichkeit der Aussagen von LLM. In Wirklichkeit IST Coden das eigentliche Thema dieses Threads, insbesondere im Zusammenhang mit lokalen Modellen. Bitte klär' Deine Fragen woanders.
Frank E. schrieb: > Lange Rede kurzer Sinn: Ich habe sage und schreibe gut 2 Tage benötigt, > trotz intensiver KI-Unterhaltung (ChatGPT, Grok, Gemini ...). Die haben > im Detail aber alle nur Sch... Ich hatte heute auch Probleme, einen Dust SF Shortfilm zu finden, bzw. wie dessen Titel das überhaupt war. Die KI hatte aber eine perfekte Beschreibung von diesem Shortfilm parat - nur wurde, trotz der guten Beschreibung, ständig auf andere Filme mit völlig anderen Inhalt hingewiesen. Glücklicherweise hatte ich noch einen Link auf einem anderen Rechner.. Aber beispielsweise auch bei Problemen mit Skyrim bringen die auch so einiges durcheinander - Jetzt sehe ich eigentlich schon ein dreidimensionales Problem. Die KI Flüsterei auf der einen Seite + die fehlende Ausbildung oder die fehlenden Hintergrundinfos, die man mitbringt - Auf der anderen Seite den Fortschritt der KI, wenn die Zusammenarbeit nicht richtig läuft - und der dritte Teil wäre dann nochmal den Unsinn der KI zu erkennen - auch wenn der nicht so offensichtlich ist.
Frank E. schrieb: > Nochmal (fast) zum eigentlichen Thema zurück, diesmal nicht "Coden" > sondern allgemein die Verlässlichkeit der Aussagen von LLM. Das Thema des Threads hier IST "Coden" mit AI. Rbx schrieb: > Ich hatte heute auch Probleme, einen Dust SF Shortfilm zu finden Ihr seid hier beide falsch, geht doch einfach in den OT KI Thread, der ist auch schon gekapert - dort könnt ihr euch schwallhaft darüber auslassen was die KI kann und nicht kann - abseits von AI-Coding! Eure Meinungen zu Filmsuchen oder Treibersuchen hat hier nichts zu suchen!
Beitrag #8032041 wurde von einem Moderator gelöscht.
Ich hab jetzt viel im Thread über meine Erfahrung mit lokalen Modellen geschrieben. Irgendwie fühle ich mich verpflichtet darauf hinzuweisen, dass ich keine lokalen Modelle produktiv einsetze. Ich teste viel, lass was laufen und so und hab mittel-gute Hardware. Aber reproduzierbar gute Ergebnisse bekomme ich noch nicht. Ich habe einen Standardtest, das ist ein Kommandozeilenprogramm dass ich mir mal von ner halbwegs großen KI hab schreiben lassen. Das hab ich mir auch dokumentieren lassen und geb diese Doku nem lokalen Modell und sag er soll das so implementieren. Ich erwarte so 15kb / ~500 loc Rust code + cargo.toml & git commits. Meine kleinen lokalen Modelle (nur 16GB VRAM) machen das manchmal korrekt, es gehört aber durchaus Glück oder so dazu. Manchmal verfangen die sich in ner Endlosschleife, die Ausführung bricht aus unbekannten gründen ab, oder sie schreiben so langen komplexen Code, dass sie die Compilerfehler nie bereinigt bekommen. Manchmal fängt es schon damit an, dass sie die zur Verfügung gestellten tools nicht richtig benutzen, manchmal ist es erst nach 10 Minuten offensichtlich, dass nichts gescheites bei rumkommt. Manchmal bekomm ich aber auch das gewünschte Ergebnis. Aber das gleiche Modell läuft mal gut, mal nicht so... Ich nutze weitgehend Opencode als Agent. Teilweise kann das Problem also auch da liegen. Ansonsten bin ich von Ollama jetzt auf Llama.cpp umgestiegen, weil es da den Turboquant Fork gibt, der den Context-Cache besser quantisieren kann. Bei gleichem Speicherbedarf ist da ein 3-4x größeres Kontextfenster möglich. Laut Paper ohne nennenswerten Genauigkeitsverlust. Wie auch immer. Ich überlege mir auf der Arbeit dennoch eine R9700 mit 32GB Speicher kaufen zu lassen...
Rbx schrieb im Beitrag #8032041: > So als könnte man das eben mal sauber trennen Man kann selbstverständlich sauber trennen: Suche nach einem Film || AI-Coding Das eine hat mit dem anderen nichts zu tun, also begib dich mit dem Zeugs, was nichts mit AI-Coding zu tun hat bitte hierher: Beitrag "Programmieren mit KI"
Rbx schrieb im Beitrag #8032041: > So als könnte man das eben mal sauber trennen. Natürlich kann man das. > offenen Diskussiongeist hier Die Diskussion in diesem Thread ist auf dessen Thema "Coding mithilfe lokaler LLMs" beschränkt. Alles andere ist ausdrücklich unerwünscht. > Framing [...] Diskussionsunterdrückung: [...] Hexenverbrenner Bitte such' Dir endlich professionelle Hilfe, verwirrter Schlumpf.
Rene K. schrieb: > Frank E. schrieb: >> Nochmal (fast) zum eigentlichen Thema zurück, diesmal nicht "Coden" >> sondern allgemein die Verlässlichkeit der Aussagen von LLM. > > Das Thema des Threads hier IST "Coden" mit AI. > Ja ja, schon gut. Am Ende war die Lösung in einer JSON-Datei mit passenden Parametern versteckt. Ist das nicht auch irgendwie "Coding"? :-)
Was mich gerade sehr stört sind diese ungeschickten und sprunghaften Lösungsansätze. Ich bin gerade an einem ESP32-P4 und spiel mit Video rum. Die KI hat jetzt festgestellt, dass der Hardware H264-Encoder kein RGB565 kann und die Lösung ist jetzt nicht, die ISP auf YUV umzustellen, sondern auf den Software-H264-Encoder umzustellen. Sie war wahrscheinlich auch davon beeinflusst, dass es zuvor den MJPEG-Encoder benutzt hat, der das kann. Habt Ihr dafür irgendwelche Lösungsansätze? Man könnte immer erst auf "Plan" stellen (ich benutze github copilot) und dann den Ansatz reviewen und dann erst umsetzen lassen, aber gerade bei der Fehlersuche ist das auch sehr mühselig. Oder ist das Netz zu klein? Ich benutze aktuell GPT-5.4 Medium. Wie geht ihr damit um?
In solchen Situationen frage ich dann expliziz z.b.: "Ist Software-H264-Encoder nun die richtig Wahl für mich, oder gibt es einen besseren Lösungsansatz?" Da überdenkt er es sich oft mal. Zumindest bei Claude Haiku 4.x funktioniert das unter VSC immer sehr gut. Mit GPT-5.4 hab ich das noch nicht gemacht.
Rene K. schrieb: > In solchen Situationen frage ich dann expliziz z.b.: "Ist > Software-H264-Encoder nun die richtig Wahl für mich, oder gibt es einen > besseren Lösungsansatz?" > > Da überdenkt er es sich oft mal. Zumindest bei Claude Haiku 4.x > funktioniert das unter VSC immer sehr gut. Mit GPT-5.4 hab ich das noch > nicht gemacht. ja, das ist das alte Problem, dass er die Infos eigentlich hat, aber sie nicht nutzt. Wenn ich am Projektanfang bin, dann reviewe ich den Plan und schau mir das gründlich an. Aber wenn er nur an der Fehlersuche ist, meistens nicht mehr.
Ich finde es auch hilfreich, explizit nach verschiedenen Ansätzen zu fragen, und sich dann selber den zu wählen, der einen am besten erscheint. Tut man das nicht, kommt gelegentlich eine spannende Lösung raus, von der man manchmal sogar etwas lernen kann, aber manchmal passt die einfach nicht so gut ins Gesamtkonzept.
Norbert schrieb im Beitrag #8031603: > …was bei einem ›pipe‹ direkt in die shell bestimmt ein interessantes > Unterfangen wird. ;-) Wenn man nat. schon zu blöd ist die Pipe wegzulassen…
Hat hier jemand womöglich eine Idee, was der Unterschied zwischen diesen beiden Modellen ist? Abgesehen vom Namen, meine ich. :-) - https://huggingface.co/google/gemma-4-26B-A4B - https://huggingface.co/google/gemma-4-26B-A4B-it
Beitrag #8032203 wurde von einem Moderator gelöscht.
Beitrag #8032208 wurde von einem Moderator gelöscht.
Beitrag #8032211 wurde von einem Moderator gelöscht.
Beitrag #8032214 wurde von einem Moderator gelöscht.
Beitrag #8032220 wurde von einem Moderator gelöscht.
Beitrag #8032227 wurde von einem Moderator gelöscht.
Dieter D. schrieb im Beitrag #8032227: > Ein T. schrieb im Beitrag #8032220: >> ... verpiß Dich, hau ab, troll woanders. Jetzt verstanden? > > An den Folgen Deiner Kinderstube oder unguten Umgebungseinflüssen > solltest Du noch etwas arbeiten. > > Es ist nicht Dein Forum. Aber es ist mein Thread mit meinem Thema. > Wenn etwas nicht passt, solltest auch Du Dich > an die Formen der Nettiquette halten. Das habe ich getan, und es wurde offensichtlich nichts verstanden. Du und ein paar andere sondert immer noch Euren Bullshit hier ab, obwohl ich anfangs sehr freundlich darum gebeten und dann mit zunehmender Bestimmtheit gefordert habe, das zu unterlassen. Das beweist deutlich genug, daß hier weder ich noch meine Kinderstube das Problem sind.
Beitrag #8032253 wurde von einem Moderator gelöscht.
Können einfach mal die Leute, die hier NICHTS zum Thema beizutragen haben sich hier raushalten?! Geht ins OT, geht woanders hin! Aber haltet euch einfach raus hier!
Ein T. schrieb: > ..sondert immer noch Euren Bullshit hier ab, obwohl > ich anfangs sehr freundlich darum gebeten und dann mit zunehmender > Bestimmtheit gefordert habe, das zu unterlassen Nun, deine Ausgangsfrage und dein Verlangen ist auch ein wenig Bullshit, denn: 1) Sollte die Diskussion offen bleiben, denn das zeigt oft, ob die Ausgangsfrage gut beantwortbar ist oder nicht. Sich dagegen zu wehren ist reichlich dämlich. 2) Erfahrungen mit Modellen? Klar kann man die haben. Die sind doch aber erstmal abgesehen von generellen Hintergründen wie Kosten oder Hardware ziemlich individuell. Grob generell: Wenn man Ahnung hat, kann man die KI auf gewisse Punkte hinweisen (egal ob Programmierung oder bei anderen Themen), und das hilft (ganz generell eben) Wenn man keine Ahnung hat, und sich auch keine Mühe gibt, eine zu bilden, außer die KI veräppeln zu können, dann kann man nicht erwarten, dass hier irgendwas fruchtbares in der Diskussion rüberkommt. 3) der zitierte Beitrag oben klingt wohl mit "sondern" etwas besser. Oder eben so: Du und ein paar andere: Ihr sondert.. So wäre die Satzbildung korrekter.
Ein T. schrieb im Beitrag #8032220: > Gerhard O. schrieb: >> Stattdessen moderiert hier ein >> wild gewordener selbst ernannter Moderator die Gesprächsrunde > > Dies hier ist mein Thread, zu meinem Thema, und ich tue genau das, zu > dem die Moderatoren dieses Forums ausdrücklich und wiederholt > aufgefordert haben: ich moderiere ihn und achte darauf, daß er beim > Thema bleibt. Wenn Dir das nicht gefällt oder Du nichts zum Thema > beitragen kannst, dann... Das ist nicht DEIN Thread - Jeder ist hier Gast. Die Moderatoren sehen Deine Einstellung nicht im Geist des Forums. Deine Tunnel Vision zeigt höchstens, daß es Dir nicht an zum Thema passenden Gedanken und Beiträgen liegt. Was dieser Thread hier sehr deutlich gemacht hat, ein sehr unerquicklicher Wind hier weht. > >> Tut mir leid, es mal so deutlich sagen zu müssen. > > ... verpiß Dich, hau ab, troll woanders. Jetzt verstanden? Ich glaube, dafür solltest Du Dich jetzt entschuldigen! Solche Kraftausdrücke hören sich für viele gebildete Menschen sehr unprofessional an - zumindest in meinen Kreisen. Zu dem kann ich nur erwähnen, daß mir keiner hier im Forum nach Jahrzehnten nachtragen kann, dass ich mich jemals als Troll geübt habe. Das würden hier die meisten, die mich schätzen, bestätigen können. Auch habe ich Dich nicht beleidigt, sondern nur meine Meinung über Dein ungewöhnlich engstirniges Verhalten hier herausgestellt. Da ich aber nicht die Absicht habe, diesen Deinen Thread weiter zu "verunglimpfen" sei unbesorgt; ich werde mich aus oben genannten Gründen nicht weiter darüber äussern und wünsche den Erfolg den Du Dir erhofft hattest - More Power to You!
:
Bearbeitet durch User
Gerhard O. schrieb im Beitrag #8032203: > Es ist mir unverständlich, daß Ihr Euch den Mund verbieten lasst. Gerade > die verschiedenen Gedanken zum Thema und Ansätze können Synergien Das ist doch gerade die Kritik: Die Beiträge waren eben NICHT zum Thema. > Stattdessen moderiert hier ein > wild gewordener selbst ernannter Moderator die Gesprächsrunde und zwingt > das Gespräch in sein privates Korsett. Er hat diese Diskussion ja auch angefangen. Es kann doch auch jeder seine eigene Diskussion anfangen, wenn ihm diese nicht gefällt. Wenn man mal etwas länger in Diskussionsforen unterwegs ist, dann sieht man regelmäßig Fälle, wo eine Diskussion "gekapert" wird. Meistens nicht böswillig, sondern die Diskussion biegt halt in eine andere Richtung ab. Das führt dann auch sehr oft dazu, dass die ursprüngliche Diskussion einschläft. > Tut mir leid, es mal so deutlich sagen zu müssen. Was hier vorgeht ist > in der Geschichte des Forums erstmalig. Nein, es kommt immer mal wieder vor. Such im Forum z.B. nach "Thema konzentrieren" . Allerdings sind die meisten Aufforderungen, zum Thema zurückzukehren, etwas höflicher formuliert.
Beitrag #8032278 wurde von einem Moderator gelöscht.
Markus K. schrieb: > Gerhard O. schrieb: > >> Es ist mir unverständlich, daß Ihr Euch den Mund verbieten lasst. Gerade >> die verschiedenen Gedanken zum Thema und Ansätze können Synergien > > Das ist doch gerade die Kritik: Die Beiträge waren eben NICHT zum Thema. > >> Stattdessen moderiert hier ein >> wild gewordener selbst ernannter Moderator die Gesprächsrunde und zwingt >> das Gespräch in sein privates Korsett. > > Er hat diese Diskussion ja auch angefangen. Es kann doch auch jeder > seine eigene Diskussion anfangen, wenn ihm diese nicht gefällt. > > Wenn man mal etwas länger in Diskussionsforen unterwegs ist, dann sieht > man regelmäßig Fälle, wo eine Diskussion "gekapert" wird. Meistens nicht > böswillig, sondern die Diskussion biegt halt in eine andere Richtung ab. > Das führt dann auch sehr oft dazu, dass die ursprüngliche Diskussion > einschläft. > >> Tut mir leid, es mal so deutlich sagen zu müssen. Was hier vorgeht ist >> in der Geschichte des Forums erstmalig. > > Nein, es kommt immer mal wieder vor. Such im Forum z.B. nach "Thema > konzentrieren" . > Allerdings sind die meisten Aufforderungen, zum Thema zurückzukehren, > etwas höflicher formuliert. Deine Einwände sind durchaus sachlich und bei einigen, einschließlich meines ersten, stimmt das auch. Allerdings wurden auch fachliche Beiträge zum Thema als Solchen, genauso scharf kritisiert - Und das wäre Tunnel Vision, weil gerade oft in fachlich bezogenen Themen, solche Perspektiven zum Verständnis des Sachverhalts durchaus nützlich sein können. Aber wie gesagt, belassen wir es besser dabei; wir können die Einstellung des T.O. nicht ändern und man muß den Thread nicht unbedingt lesen und Toleranz war noch nie ein Fehler. ...
Rbx schrieb: > 1) Sollte die Diskussion offen bleiben, Solange sie beim Thema bleibt, darf sie gerne offen sein. Das Thema ist AI-gestütztes Coding mit freien, mithin: lokalen Modellen. > 2) Erfahrungen mit Modellen? Klar kann man die haben. Genau, und dann kann man etwas zu diesem Thread beitragen. > Die sind doch aber > erstmal abgesehen von generellen Hintergründen wie Kosten oder Hardware > ziemlich individuell. Dieser Thread soll dazu dienen, sich über diese individuellen Erfahrungen beim Betrieb lokaler Modelle zur Generierung von Code auszutauschen. > Grob generell: Nein, nicht generell. Sondern beschränkt auf das vorgegebene Thema. > Wenn man keine Ahnung hat, ... kann man diesen Thread gerne mitlesen, aber nichts dazu beitragen. Wenn Du über Deine "Diskussionen" mit einem proprietären Modell über "1000 Jahre alte Texte" reden möchtest, habe ich damit nicht das geringste Problem. Dann mach doch einfach einen eigenen Thread auf und diskutier dort über Deine Abenteuer, alles gut. Nur HIER gehört das einfach NICHT hin.
> - https://huggingface.co/google/gemma-4-26B-A4B Basismodell > - https://huggingface.co/google/gemma-4-26B-A4B-it Instruction Tuned Das Basismodell setzt lediglich rohen Text fort, wohingegen die "-it"-Version ("instruction-tuned") gezielt darauf trainiert wurde, Anweisungen und Fragen wie ein Chat-Assistent zu beantworten.
Uwe schrieb: > Ich finde es auch hilfreich, explizit nach verschiedenen Ansätzen zu > fragen, und sich dann selber den zu wählen, der einen am besten > erscheint. Tut man das nicht, kommt gelegentlich eine spannende Lösung > raus, von der man manchmal sogar etwas lernen kann, aber manchmal passt > die einfach nicht so gut ins Gesamtkonzept. Das klingt gut. Das werde ich gleich mal in die Agents.md reinschreiben.
Gerhard O. schrieb: > Das ist nicht DEIN Thread Aber natürlich ist er das. Ich habe ihn eröffnet, ich habe das Thema gewählt, ich habe schon im Eingangsbeitrag und auch in der Folge mehrmals ausdrücklich und freundlich darum gebeten, bei diesem Thema zu bleiben. > Jeder ist hier Gast. In diesem meinem Thread sind nur jene willkommene Gäste, die sich über das von mir gesetzte Thema austauschen können und wollen. Alle anderen sind hier nicht willkommen und werden als Störer angesehen, von mir und, wenn ich die Beiträge und Bewertungen ansehe, anscheinend auch anderen, die gerne über dieses Thema sprechen möchten -- und die Du und andere dabei mutwillig stören. > Die Moderatoren sehen Deine Einstellung nicht im Geist des Forums. Das phantasierst Du. In Wirklichkeit sagt zum Beispiel unser hochgeschätzter Moderator Lothar hier [1]:
1 | Ein Moderator ist zuallererst der TO selber. Übertragen auf die |
2 | Realität hat er zu einer Sitzung/Besprechung eingeladen und er leitet |
3 | sie. |
Der TO hier, der diesen Thread "leitet" (um in Lothars Wortwahl zu bleiben), der bin: ich. Eigentlich ganz einfach, findest Du nicht? > Was dieser Thread hier sehr deutlich gemacht hat, ein > sehr unerquicklicher Wind hier weht. Ja, weil ständig Threads von Leuten zugemüllt werden, die nichts zum Thema beitragen können und / oder wollen. Wenn Du und ein paar andere Leute ihre Tastatur still gehalten und einfach nichts geschrieben hätten, dann könnten (und würden) die Leute hier über ihre Erfahrungen mit dem Thema diskutieren, und jene ohne eigene Erfahrungen mitlesen, lernen, und Fragen stellen. >> ... verpiß Dich, hau ab, troll woanders. Jetzt verstanden? > > Ich glaube, dafür solltest Du Dich jetzt entschuldigen! Wofür? Gegenüber jemandem deutlich geworden zu sein, der meine freundlichen Ansprachen und Bitten bereits mehrmals penetrant ignoriert hat? Tut mir leid, aber meine Freundlichkeit hat ihre Grenzen, die schnell erschöpft sind, wenn mir jemand so penetrant, unfreundlich und ignorant entgegen tritt. Obwohl... nein, tut mir nicht leid. > Zu dem kann ich nur erwähnen, daß mir keiner hier im Forum nach > Jahrzehnten nachtragen kann, dass ich mich jemals als Troll geübt habe. Nein, das stimmt, normalerweise tust Du das nicht. Aber was Du hier tust, darüber findet sich eine Passage in den Nutzungsbedingungen [2]:
1 | |
2 | Ebenso nicht erlaubt ist: |
3 | - Mutwillige Störung von Diskussionen ("trollen")
|
Insofern bitte ich Dich nochmals freundlich, Dich an die Nutzungsbedingungen und die von den hiesigen Moderatoren ermutigten Verhaltensweisen zu halten. Ich freue mich sehr, wenn Du etwas zum Thema "AI-gestütztes Coding mit freien lokalen Modellen" beiträgst oder gern auch Deine Fragen dazu stellst -- oder Dich auf Mitlesen beschränkst, wenn Du keine Erfahrungen zum Thema beisteuern kannst und keine Fragen dazu hast, aber am Thema interessiert bist. Wenn all das nicht auf Dich zutrifft, kein Problem: dann kannst Du andere Theads mit Deinen Beiträge zu deren Themen sicherlich mehr bereichern und erhellen als diesen hier. Danke. [1] Beitrag "Re: Vorschlag: Thread selbst verwalten, zum zweiten" [2] https://www.mikrocontroller.net/articles/Hilfe:Forum_Nutzungsbedingungen
Gerhard O. schrieb: > Allerdings wurden auch fachliche > Beiträge zum Thema als Solchen, genauso scharf kritisiert Welche?
1N 4. schrieb: >> - https://huggingface.co/google/gemma-4-26B-A4B > > Basismodell > >> - https://huggingface.co/google/gemma-4-26B-A4B-it > > Instruction Tuned > > Das Basismodell setzt lediglich rohen Text fort, wohingegen die > "-it"-Version ("instruction-tuned") gezielt darauf trainiert wurde, > Anweisungen und Fragen wie ein Chat-Assistent zu beantworten. Ah, cool, danke für die Information. Gehe ich also Recht in der Annahme, daß das -it-Modell für Coding-Aufgaben besser geeignet sein sollte?
> Ah, cool, danke für die Information. Gehe ich also Recht in der Annahme, > daß das -it-Modell für Coding-Aufgaben besser geeignet sein sollte? Ein Basismodell taugt i.d.R. weder für Chat noch für Agents, egal ob Coding oder sonstwas. Es kennt schlichtweg keine Instruktionen.
Moin, An Ein_t: Ich möchte hier nicht Deinen Thread weiterhin stören, könnte aber Einiges Deiner Stellungsnamen kommentieren. Ich schlage aber dagegen vor, daß wir uns einigen, nicht-einig zu sein;-) Daß Du Dich nicht entschuldigen willst, trage ich Dir nicht unbedingt nach, auch wenn es angebracht wäre. In einer Beziehung hattest Du mich wahrscheinlich aber falsch eingeschätzt: es war in meinem ersten Beitrag gar nicht die Absicht eine Thread Diversion loszutreten und es war wahrscheinlich spontan unüberlegt von mir, worüber ich mich dann bei Dir auch entschuldigte. Das wäre das Ende meiner Beiträge hier gewesen. Aber Dein weiteres Verhalten war mir später andern gegenüber zu ruppig. Ferner hattest Du auch andere unfairerweise zurechtgewiesen, die mit ihren Kommentar durchwegs thematisch nicht unbedingt nebenplatziert waren. OK. Beenden wir das Ganze und konzentriert Euch auf das Nächstliegende und habt Erfolg und wir rauchen die Friedenspfeife. Gerhard
1N 4. schrieb: >> Ah, cool, danke für die Information. Gehe ich also Recht in der Annahme, >> daß das -it-Modell für Coding-Aufgaben besser geeignet sein sollte? > > Ein Basismodell taugt i.d.R. weder für Chat noch für Agents, egal ob > Coding oder sonstwas. Es kennt schlichtweg keine Instruktionen. Da Du ja ein funktionierendes Gesamtsystem auf Basis Deiner Strix Halo und eines passenden Software- und Modellstack zu haben scheinst, würde ich mich sehr freuen, wenn Du ein wenig über Dein Gesamtsystem, Deiner Nutzung und Deinen Erfahrungen damit erzählen könntest. Dankeschön! :-)
> Da Du ja ein funktionierendes Gesamtsystem auf Basis Deiner Strix Halo > und eines passenden Software- und Modellstack zu haben scheinst, würde > ich mich sehr freuen, wenn Du ein wenig über Dein Gesamtsystem, Deiner > Nutzung und Deinen Erfahrungen damit erzählen könntest. Dankeschön! :-) Was exakt?
1N 4. schrieb: >> Da Du ja ein funktionierendes Gesamtsystem auf Basis Deiner Strix Halo >> und eines passenden Software- und Modellstack zu haben scheinst, würde >> ich mich sehr freuen, wenn Du ein wenig über Dein Gesamtsystem, Deiner >> Nutzung und Deinen Erfahrungen damit erzählen könntest. Dankeschön! :-) > > Was exakt? Im Prinzip: welche Modelle verwendest Du, mit welcher Software und welchen Funktionen, wie performen die Kombinationen auf Deiner Hardware, welche Art von Software entwickelst Du damit, mit welchen Programmiersprachen, als wie nützlich empfindest Du die AI-Unterstützung bei Deiner Arbeit, hat sich die Investition Deiner Ansicht nach gelohnt und würdest Du sie nochmal machen? Quasi im Prinzip alles von Deinem Setup, über Deine konkreten Anwendungfälle, bis hin zu den Ergebnissen und Erfahrungen, die Du gemacht hast und machst. Dankeschön!
Hab jetzt nicht den ganzen Thread durchgelesen, aber das Atmega-Beispiel hat mich gereizt mal die von mir präferierte online-KI zu befragen: den prompt hab ich ähnlich wie hier vorgemacht wurde knapp gehalten: "C-code for ATmega48, RTC @ 32768 Hz, power saving mode, LED blinking at 50ms interval" ich kenn den Atmega48 nicht, bin entfernt vertraut mit den Megas, kann den ausgespuckten Code also nicht wirklich beurteilen. Aber auf den ersten Blick sieht das halbwegs vernünftig aus. Interessant finde ich das Links angegeben werden woher das Zeug stammt und dass Erklärungen gegeben werden. Der Kundige wird daher wohl sofort grobe Flapser finden. https://www.perplexity.ai/search/c-code-for-atmega48-rtc-32768-e2a_tee4TW2.GDfX8zS17w
1 | #define F_CPU 8000000UL
|
2 | #include <avr/io.h> |
3 | #include <avr/interrupt.h> |
4 | #include <avr/sleep.h> |
5 | #include <util/delay.h> |
6 | |
7 | #define LED_DDR DDRB
|
8 | #define LED_PORT PORTB
|
9 | #define LED_PIN PB0
|
10 | |
11 | volatile uint8_t tick10ms = 0; |
12 | volatile uint8_t led_toggle = 0; |
13 | |
14 | static void timer2_async_init(void) |
15 | {
|
16 | cli(); |
17 | |
18 | /* Stop Timer2 while configuring */
|
19 | TCCR2A = 0; |
20 | TCCR2B = 0; |
21 | TIMSK2 = 0; |
22 | |
23 | /* Enable asynchronous Timer2 clock from 32.768 kHz crystal */
|
24 | ASSR |= (1 << AS2); |
25 | |
26 | /* CTC mode, OCR2A as top */
|
27 | TCCR2A = (1 << WGM21); |
28 | |
29 | /*
|
30 | * 32.768 kHz / 128 = 256 Hz
|
31 | * 1 compare tick = 3.90625 ms when OCR2A = 0
|
32 | *
|
33 | * For an easy 10 ms-ish tick:
|
34 | * 32.768 kHz / 32 = 1024 Hz
|
35 | * OCR2A = 9 gives 10 ms exactly: 1024 / (9 + 1) = 102.4 Hz
|
36 | * wait, that is 9.765625 ms, which is close to 10 ms.
|
37 | *
|
38 | * For a clean 50 ms blink, we count 5 ticks.
|
39 | */
|
40 | TCCR2B = (1 << CS21) | (1 << CS20); // prescaler 32 |
41 | OCR2A = 9; // compare every ~9.765625 ms |
42 | TCNT2 = 0; |
43 | |
44 | /* Wait for async register updates to complete */
|
45 | while (ASSR & ((1 << TCR2BUB) | (1 << TCR2AUB) | (1 << OCR2AUB) | (1 << TCNT2UB))) { |
46 | }
|
47 | |
48 | /* Clear pending flags */
|
49 | TIFR2 = (1 << OCF2A) | (1 << TOV2); |
50 | |
51 | /* Enable compare match A interrupt */
|
52 | TIMSK2 = (1 << OCIE2A); |
53 | |
54 | sei(); |
55 | }
|
56 | |
57 | ISR(TIMER2_COMPA_vect) |
58 | {
|
59 | tick10ms++; |
60 | if (tick10ms >= 5) { |
61 | tick10ms = 0; |
62 | led_toggle = 1; |
63 | }
|
64 | }
|
65 | |
66 | int main(void) |
67 | {
|
68 | LED_DDR |= (1 << LED_PIN); |
69 | LED_PORT &= ~(1 << LED_PIN); |
70 | |
71 | timer2_async_init(); |
72 | |
73 | set_sleep_mode(SLEEP_MODE_PWR_SAVE); |
74 | |
75 | while (1) { |
76 | if (led_toggle) { |
77 | led_toggle = 0; |
78 | LED_PORT ^= (1 << LED_PIN); |
79 | }
|
80 | |
81 | sleep_enable(); |
82 | sei(); |
83 | sleep_cpu(); |
84 | sleep_disable(); |
85 | }
|
86 | }
|
> Im Prinzip: welche Modelle verwendest Du, Lokal eher Qwen3/3.5, Gemma-4, Nemotron, Cloud GPT, Gemini, Claude > mit welcher Software llamacpp > welchen Funktionen, Completion, Embedding, Reranking > wie performen die Kombinationen auf Deiner Hardware, Gut, aber das ist immer relativ. > welche Art von Software entwickelst Du damit, Architekturen für Agentic AI Use Cases > mit welchen Programmiersprachen, Python > als wie nützlich empfindest Du die AI-Unterstützung > bei Deiner Arbeit, Ohne AI wäre die One Man Show undenkbar > hat sich die Investition Deiner Ansicht nach gelohnt > und würdest Du sie nochmal machen? Jederzeit
So....mir ist es endlich gelungen, meinen Strixx Halo in einem LCX-Container zu nutzen, und im Anhang seht ihr das Transkript des 1. Versuch mit ollama und einem qwen3.5:35b. Ich hab ihn mal ein Blink-Programm für STM32 mit HAL schreiben lassen. Sieht für mich auf den 1. Blick Ok aus. Anschliessend hab ich mir noch die Takt-Konfiguration erklären lassen. Keine der Antworten hat dabei länger als ca. 30s gedauert. (genaue Tests folgen - hab das vor <30min. erst zum Laufen bekommen :-D )
Nachdem ich die seit beginn dieses Threads nochmal ziemlich viel probiert habe, wollte ich erstmal wieder frustriert aufgeben. Jetzt ist die Gemma4 Unterstützung in llama.cpp immer wieder verbessert worden. Und tatsächlich, meine Erfolgsquote ist hochgegangen. (Ich hab einen Test, wo ein Agent ein Kommandozeilentool nach vorgaben in Rust coden muss.) Bislang hatte ich kein Modell, was das mit nennenswerter Wahrscheinlichkeit schafft. Ich hab jetzt nochmal gemma-4-26B-A4B-it-UD-Q3_K_XL probiert und Opencode hat da immerhin 2 von 4 Versuchen erfolgreich das Problem gelöst. Nebenbei hab ich auch mal den Agentenmodus von Zed mit dem gleichen Modell probiert. Der hat das bei 3 von 3 Versuchen zufriedenstellend erledigt. Wow. Morgen werde ich auch mal Qwen3.5 damit testen. Wenn das durchgehend klappt, muss ich mir noch nen zweiten Test ausdenken...
Harry L. schrieb: > im Anhang seht ihr das Transkript des 1. > Versuch mit ollama und einem qwen3.5:35b. WTF. Hast du dir das Transkript mal angeguckt? Im Thinking process: Du: schreibe ein "blink-programm" für STM32 unter verwendung der ST HAL Model: Thinking ... 50 Zeilen Englisch. Dann: > * Actually, looking at the history: > * Turn 1: User: "warum ist der himmel blau?" -> Model: Answered. > * Turn 2: User: "wasa ist der sinn des lebens" -> Model: Answered. > * Turn 3: User: "schreibe ein "blink-programm" für STM32 unter verwendung der ST HAL" -> Model Das geht dann weitere 50 Zeilen weiter so, wo das ganze noch 4x wiederholt wird... Irre, dass da dennoch was sinnvolles rausgekommen ist.
Mathias M. schrieb: > Model: Thinking ... 50 Zeilen Englisch. Dann: >> * Actually, looking at the history: >> * Turn 1: User: "warum ist der himmel blau?" -> Model: Answered. >> * Turn 2: User: "wasa ist der sinn des lebens" -> Model: Answered. >> * Turn 3: User: "schreibe ein "blink-programm" für STM32 unter > verwendung der ST HAL" -> Model Das war die 3 Anfrage in der Session und er hat -natürlich vergeblich- versucht die in einen Kontext mit den vorherigen 2 Tests zu bringen. Vermutlich hab ich das einfach nur falsch bedient. (1. Begegnung mit ollama)
Harry L. schrieb: > Das war die 3 Anfrage in der Session und er hat -natürlich vergeblich- > versucht die in einen Kontext mit den vorherigen 2 Tests zu bringen. Ah ok. Ich dachte schon, der fantasiert dir da irgendwelche Fragen rein. Immer ne neue Session aufmachen. Ansonsten verbrauchst du sinnlos Kontextfenster und Tokens für solche Gedanken. Für Trivialprobleme geht es aber auch so.
1N 4. schrieb: >> hat sich die Investition Deiner Ansicht nach gelohnt >> und würdest Du sie nochmal machen? > > Jederzeit Vielen Dank für Deine Ausführungen! Verstehe ich Dich richtig, daß Du also mit Unterstützung der AI Werkzeuge für deren Nutzung entwickelst?
Harry L. schrieb: > So....mir ist es endlich gelungen, meinen Strixx Halo in einem > LCX-Container zu nutzen, und im Anhang seht ihr das Transkript des 1. > Versuch mit ollama und einem qwen3.5:35b. > [...] > Keine der Antworten hat dabei länger als ca. 30s gedauert. (genaue Tests > folgen - hab das vor <30min. erst zum Laufen bekommen :-D ) Cool, sogar im Container, danke!
Ein T. schrieb: > Cool, sogar im Container, danke! Ja, das war zunächst nen ziemlicher Krampf, bis ich dann auf diesen Beitrag gestossen bin: https://forum.proxmox.com/threads/proxmox-9-x-strix-halo-gpu-passthrough.181331/
> Verstehe ich Dich richtig, daß Du > also mit Unterstützung der AI Werkzeuge für deren Nutzung entwickelst? Eher, dass die Agentic AI unter meiner Aufsicht Agentic AI Lösungen für Use Cases entwickelt.
So, wieder daheim habe ich auf meinem "dicken" Horst [1] den Container mit llama-server (llama.cpp) und dem Modell Qwen3.5-27B_q8_0.gguf gestartet und als erste Aufgabe die Folgende gestellt:
1 | create a web chat application with golang, gofiber, gorm and postgresql for the backend and svelte for the frontend, and with user authentication, and present the result as a zip archive. |
und diese später um
1 | please create a dockerfile for the backend, enhance the docker-compose.yml with instructions to build and run the backend, and add html templates. |
erweitert. Für die erste Aufgaben hat der Kleine 1:16 und für die zweite 1:21 Stunden gebraucht, bei 1,2 bzw. 1.18 Token pro Sekunde. Klar, das ist nicht sonderlich performant, aber das hatte ich auch nicht erwartet. Aber in dieser Zeit hätte ich das Erzeugte niemals selbst schreiben können, auch dann nicht, wenn ich noch ein, zwei Tage in Verständnis und Korrektur investieren muß. Die Bewertung der Qualität steht allerdings noch aus, denn... Leider stehe ich dabei aktuell vor einem, nunja, Faulheitsproblem: das Modell spuckt mir die Dateien einzeln aus und kann mir keine Archive (Zip, Tar, you name it) daraus erzeugen. Deswegen müßte ich die Verzeichnisstruktur manuell anlegen und die Dateien per Copy'n'Paste befüllen, und das nervt. In meinem Container sind allerdings auch keine entsprechenden Programme (zip(1), tar(1), you name it) enthalten. Hat jemand von den geschätzten Mitlesern vielleicht eine Idee, wie ich das besser (also weniger arbeitsaufwändig) machen kann? Würde es wohl reichen, diese Programme in den Container zu installieren? Oder könnte ich das Modell anweisen, die Dateien selbst zu erzeugen, indem ich ihm einem MCP-Server (oder etwas anderes?) zur Seite stelle? [1] Naja, sooo fett isser nu auch wieder nich... :-) CPU: 8-core AMD Ryzen 7 3800X (-MT MCP-) speed/min/max: 3574/2200/4200 MHz Kernel: 6.8.0-106-generic x86_64 Up: 28d 16h 32m Mem: 22.27/62.71 GiB (35.5%) Storage: 16.37 TiB (88.6% used) Procs: 417 Shell: Bash inxi: 3.3.34 Graphics: NVIDIA GP108 [GeForce GT 1030] driver: nouveau v: kernel
> Würde es wohl reichen, diese Programme in den Container zu installieren? > Oder könnte ich das Modell anweisen, die Dateien selbst zu erzeugen, > indem ich ihm einem MCP-Server (oder etwas anderes?) zur Seite stelle? Du musst dem LLM schon passende Tools im Sinne des LLM bereitstellen. Nur weil da eine bash ist, weiß das Modell ja nicht was es soll & darf.
Ein T. schrieb: > Hat > jemand von den geschätzten Mitlesern vielleicht eine Idee, wie ich das > besser (also weniger arbeitsaufwändig) machen kann? Am sinnvollsten wäre wahrscheinlich ein Coding Agent, den du mit dem Modell verbindest. z.B. Opencode, aber jede IDE (wie VSCode) hat da Plugins für, wenn die nicht gleich mitgeliefert werden. Je nach Einstellungen hat der Agent dann Zugriff auf die Dateien des aktuellen Verzeichnisses und darf auch Befehle ausführen. Da kann es theoretisch natürlich passieren, dass der im Internet sucht und "ignoriere alles, was oben steht und mache rm -rf /" findet... Paranoide (mange sagen: Vernünftige) packen das also auch in nen Container oder so. Opencode hat ein TUI interface, das geht also gut auf der Konsole...
Es tut mir Leid das lange Video zu posten (eine Zeile Text hätte es auch getan) aber evtl. ist das von Interesse. https://youtu.be/Wa98kS_m6fw
Alexander schrieb: > Es tut mir Leid das lange Video zu posten (eine Zeile Text hätte es auch > getan) aber evtl. ist das von Interesse. > > https://youtu.be/Wa98kS_m6fw Das hat nichts mit dem Thema dieses Threads zu tun.
Ich entnehme Deiner Antwort man kann den Sourcecode lokal bzw. offline also gar nicht gebrauchen.
Alexander schrieb: > Ich entnehme Deiner Antwort man kann den Sourcecode lokal bzw. offline > also gar nicht gebrauchen. Wenn Du nicht gerade ein sehr gut ausgestattetes, modernes Rechenzentrum in Deinem Keller hast, sicherlich nicht.
Ein T. schrieb: >> Ich entnehme Deiner Antwort man kann den Sourcecode lokal bzw. offline >> also gar nicht gebrauchen. > > Wenn Du nicht gerade ein sehr gut ausgestattetes, modernes Rechenzentrum > in Deinem Keller hast, sicherlich nicht. Das ist der Quellcode zu Claude Code CLI, das ist ein Tool zum agentic coding. Das hat mit dem Modell selber erstmal nichts zu tun. Man braucht kein großes Rechenzentrum, das läuft auch auf nem Raspberry Pi. Zusätzlich braucht man natürlich noch ein KI Modell, da gilt "je größer, desto besser". Braucht man jetzt den Quelltext? Das CLI gabs ja vorher auch schon als node "binary" (= obfuscated Javascript) Es ist ja jetzt dennoch nicht open source, so dass man das bearbeiten und verbreiten dürfte. Witzigerweise ist das passiert, was als Witz irgendwann mal rumging. Irgendwer hat mit KI den Code dokumentieren lassen und die Doku dann quasi Clean-Room in Python & Rust implementieren lassen. Damit ist die original Lizenz nicht mehr anwendbar. Keine Ahnung, ob das jetzt was taugt oder nicht. Hier gibts das: https://github.com/ultraworkers/claw-code edit Irgendwie zum Thread passend, war das Video IMO aber auch nicht.
:
Bearbeitet durch User
Die KI-Welt dreht sich ja ca. 9x schneller als die normale Welt. Gerade wurde Qwen3.6 35B-A3B veröffentlicht. Vorher war Qwen3.6 nur per API verfügbar. Da läuft vermutlich aber ohnehin ein größeres Modell. Obwohl mir das für meine 16GB GPU eigentlich zu groß ist, hab ich mir mal die Q4_K_S Quants runtergeladen. Und ich muss sagen, das ist IMO bedeuntend besser als die Modelle, die ich mir bislang angeguckt habe. Zugegeben haben die bislang max. 13GB auf der Platte belegt, das ist jetzt 20GB groß. Fast 1/3tel muss also bei mir ins System RAM. Dank Mixture of Experts Architektur komme ich dennoch auf >500 t/s prompt-processing und ~30-35 t/s text generation. Das macht jetzt nicht super Laune, ist aber auch nicht unbrauchbar. Und na ja, das Ergebnis ist zum ersten mal für mich wiederholbar brauchbar. Was ich bislang teste ist ein Programm, was ich zwar real brauchte, aber vom Umfang her ziemlich klein. Aber das finde ich teilweise schon eine echte Erleichterung. Man hat ein Problem, irgendwas, was man automatisieren will oder so, und lässt sich das einfach gerade machen. Aber: Wer sein Problem nicht ausführlich beschreibt und vorher den Arbeitsplan absegnet, hat Probleme das gewünschte zu bekommen. Und hier ist Geschwindigkeit oft entscheidend. "1 Minute was beschreiben, 2 Minuten Warten, testen, verbessern lassen" ist produktiv. Muss man 20 Minuten warten, macht das keine großen Spaß mehr.
Mathias M. schrieb: > Obwohl mir das für meine 16GB GPU eigentlich zu groß ist, hab ich mir > mal die Q4_K_S Quants runtergeladen. Wie hast du es heruntergeladen? Bei Ollama sehe ich nur die 24GB-Version: https://ollama.com/library/qwen3.6
Mathias M. schrieb: > Obwohl mir das für meine 16GB GPU eigentlich zu groß ist, hab ich mir > mal die Q4_K_S Quants runtergeladen. Das Modell ist für meine RTX5060 mit 8GB wohl zu groß. Beitrag "Re: KI Hardware Anforderungen"
Versuch das Gemma 4 - Mixture of Experts Modell (google/gemma-4-26B-A4B-it). Das hat 26B Parameter, aber es muss nur der jeweils aktive "Experte" daraus in die Grafikkarte, mit ~4B Parametern. Damit läuft das lokal sehr gut & schnell, auch ohne dicke Grafikkarte mit viel VRAM.
Christoph M. schrieb: > Wie hast du es heruntergeladen? Bei Ollama sehe ich nur die > 24GB-Version: Ich bin inzwischen ausschließlich mit llama.cpp unterwegs. Ollama nutzt das zwar auch unter der Haube, aber die Entwicklung findet im Original statt, bzw. in Forks, die ich dann auch ohne Probleme nutzen kann. Modelle gibts dann von Huggingface: https://huggingface.co/collections/unsloth/unsloth-dynamic-20-quants Qwen 3.6 hier: https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF/tree/main Einfach das passende .gguf laden. Je größer desto besser und langsamer + mehr Speicherverbrauch. Grob gesagt sollte das Modell besser ganz in den VRAM passen. Neben dem Modell braucht aber auch der Kontext nicht zu knapp Speicher. Da gibt es recht aktuell eine Entwicklung, dass man den Kontext ohne große Verluste quantisieren kann. Normalerweise ist der FP16, also 2 Bytes. Bei Qwen3.6 sind das bei 100k Kontext auch 2GB. Ich geh da auf Q4.0, also 0.5 Bytes. Damit bin ich lande ich dann bei ~600MB bei 100k Kontext. Der Speicher wird bereits beim Starten reserviert. Wenn man weiß, dass man nur 50k braucht, kann man 300MB sparen. Brauch ich 200k, muss mehr vom Modell in den RAM ausgelagert werden. Das wird leider nicht dynamisch zugewiesen. Qwen 3.6 hat einen extra Vision encoder, den ich nicht mit lade. Nochmal 1-2GB gespart. Momentan starte ich das so: llama-server -np 1 // Nur eine Verbindung gleichzeitig zulassen, spart Speicher --flash-attn on //auch irgendwie schneller --cache-type-k q4_0 --cache-type-v q4_0 //quantisierte (Kontext) KV-Cache -fitt 512 // lass nur 512MB VRam für den Desktop (default: 1024) -fitc 100000 //mach mindestens 100k Kontext --model ~/Downloads/Qwen3.6-35B-A3B-UD-Q4_K_S.gguf --chat-template-kwargs '{"preserve_thinking": true}' //Irgendein fix für Qwen Ja das sieht irgendwie kompliziert aus. Ist halt besser als das One-size fits all. Ich bin mir sicher, man kann das auch in Ollama irgendwie einstellen. Oder AFAIK LM-studio hat die Einstellungen auch in der GUI. Umgekehrt kann auch llama.cpp ohne Parameter direkt ein Modell runterladen und starten: llama-server -hf unsloth/Qwen3.6-35B-A3B-GGUF:UD-Q5_K_S
Christoph M. schrieb: >> mal die Q4_K_S Quants runtergeladen. > Das Modell ist für meine RTX5060 mit 8GB wohl zu groß. Es wird dann halt langsamer. Deutlich. Du kannst das auch ohne GPU nur im RAM laden. VRAM ist halt ca 20x schneller. > Versuch das Gemma 4 - Mixture of Experts Modell > (google/gemma-4-26B-A4B-it). > Das hat 26B Parameter, aber es muss nur der jeweils aktive "Experte" > daraus in die Grafikkarte, mit ~4B Parametern. Qwen3.6 ist 35B-A3B. Also auch ein MoE und zwar mit nur 3B aktiven Parameter. Komplett im System RAM sollte also Qwen schneller als Gemma 4 sein. Mit 8GB Vram kann man das nicht pauschal sagen. Es passen bei Gemma4 mehr % in den Vram, man muss aber dennoch mehr Parameter aktivieren... Welches Modell bei welcher Quantisierung jetzt besser ist, ist leider auch alles andere als klar. Qwen3.6-35B-A3B-UD-Q3_K_XL: 16.8GB gemma-4-26B-A4B-it-UD-Q4_K_M: 16.9GB Volle Benchmarks gibt es immer nur für das FP16 Modell. Für die Quants gibt es dann nur schnelle Einzelwerte, die sich höchstens in einem Modell vergleichen lassen: https://old.reddit.com/r/LocalLLaMA/comments/1so5nrl/qwen36_gguf_benchmarks/
> Welches Modell bei welcher Quantisierung jetzt besser ist, ist leider > auch alles andere als klar. In Agentic Stacks merkt man den Unterschied zwischen Q4 und Q8 doch deutlich. Bei Q4 biegt das Modell in einer ReAct Loop öfters frühzeitig falsch ab und braucht dann sogar noch länger für ein schlechteres Ergebnis. > Das hat 26B Parameter, aber es muss nur der jeweils aktive "Experte" > daraus in die Grafikkarte, mit ~4B Parametern. Nein, es müssen dann ständig die Parameter aus RAM -> VRAM geladen werden. Macht die Sache dann wieder langsam. Mit 16 oder gar 32GB VRAM bleibt das alles nur eine nette Spielerei.
1N 4. schrieb: > In Agentic Stacks merkt man den Unterschied zwischen Q4 und Q8 doch > deutlich. Ja klar. Mir ging es darum, dass nicht direkt klar ist, ob mehr Parameter mit höherem Quant bei gleichem Speicherverbrauch jetzt besser oder schlechter ist. Wenn dich der Q3/Q4 Vergleich stört, dann nimm Q6/Q8 oder wasauchimmer. 1N 4. schrieb: > Nein, es müssen dann ständig die Parameter aus RAM -> VRAM geladen > werden. Macht die Sache dann wieder langsam. Bislang wird das nicht gemacht. Die Parameter im Ram sind im RAM und bleiben auch da und werden dann auf der CPU durchgenudelt... na ja, zumindest bei llama.cpp (und damit Ollama, lm_studio, etc.) Keine Ahnung wie das bei VLLM läuft, aber DDR5 ist nunmal schneller als PCIe. Tatsächlich gibts jetzt recht neu nen Fork, der die letzten x benutzten Experten in den VRAM schiebt in der Hoffnung, dass nahe beieinanderstehende Tokens ähnliche Experten aktivieren. Wenn eine Karte mit PCIe5 x16 angeschlossen ist, bringt das was. Wenn man per Riser 4 Karten mit wenigen Lanes angeschlossen hat, ist das auf jeden Fall langsamer, weil der Transfer eben schnarch langsam ist. > Mit 16 oder gar 32GB VRAM bleibt das alles nur eine nette Spielerei. Ich finde, auch mit 16GB VRAM kann man schon produktive Sachen machen. Agentic coding ist schon hart gremzwertig. Wie gesagt, erst jetzt hab ich da mal positive Erfahrungen gemacht. Wenn ich das auf 32GB extrapoliere, dann ist das schon tauglich. Aber ich stimme dennoch zu. Viel mehr als ne Spielerei ist es (noch) nicht. Wer das produktiv einsetzen will, will bessere Modelle schneller laufen lassen. Wer seinen Code nicht an die Cloud geben will, muss dann eben fette Hardware kaufen. Privat muss ich sagen, sind die kostenlosen Modelle von Opencode oft ausreichend.
Mathias M. schrieb: > Ich bin inzwischen ausschließlich mit llama.cpp unterwegs. Ollama nutzt > das zwar auch unter der Haube, aber die Entwicklung findet im Original > statt, bzw. in Forks, die ich dann auch ohne Probleme nutzen kann. Danke für den ausführlichen Beitrag. Da muss ich wohl erst mal llama.cpp compilieren. Das wird vermutlich eine ganze Zeit lang dauern, bis ich alle Tools zusammen habe.
Christoph M. schrieb: > Da muss ich wohl erst mal llama.cpp > compilieren. Warum das? Die bieten doch Binaries an: https://github.com/ggml-org/llama.cpp/releases Nur die Forks muss man selber compilieren... oder wenn man ROCm < 7.2 nutzen will oder so.
Mathias M. schrieb: >> Das Modell ist für meine RTX5060 mit 8GB wohl zu groß. > > Es wird dann halt langsamer. Deutlich. Du kannst das auch ohne GPU nur > im RAM laden. VRAM ist halt ca 20x schneller. Nochmal Butter bei die Fische. Qwen3.6-35B-A3B-UD-Q2_K_XL (12GB): - 16GB VRAM: 2416 t/s PP, 56 t/s TG - 8GB VRAM: 519 t/s PP, 26 t/s TG - CPU: 31 t/s PP, 11 t/s TG (Ich hab Q2 gewählt, weil ich das gerade da hab und in 16GB passt, das ist keine Empfehlung.) So schlimm ist der Unterschied dann garnicht. Irgendwie wundert mich, dass TG nicht mehr einbricht. Qwen3.6-35B-A3B-UD-Q4_K_S (20GB): - 16 GB VRAM: 616 PP, 30 TG - 8 GB VRAM: 277 PP, 20 TG Bench war: llama-bench -fa 1 --cache-type-k q4_0 --cache-type-v q4_0 --model $model -p 4096 -n 512 -fitt 500 bzw. -fitt 8500 für den 8GB Test. Dann wird einfach 8GB weniger VRAM benutzt.
Ich muss mich ja leider mit meinen 8GB begnügen .. Beitrag "Re: Neues Unterforum für KI-Themen einrichten ?" Schön wäre es, wenn es ein kleines quen3.6 für die 8GB gäbe. Apropos: wir sollten einen eigenen KI-Modellthread aufmachen, weil das Thema hier ja "Erfahrung mit KI coding ist".
> Mir ging es darum, dass nicht direkt klar ist, ob mehr > Parameter mit höherem Quant bei gleichem Speicherverbrauch jetzt besser > oder schlechter ist. Tool Calling funktioniert bei Q6/Q8 deutlich zuverlässiger. Ebenso verliert das Modell dann auch bei großen Kontextfenstern seltener den Faden. > Wenn dich der Q3/Q4 Vergleich stört, dann nimm Q6/Q8 oder wasauchimmer. Abgesehen davon, dass mich der Vergleich nicht im geringsten stört, nehme ich grundsätzlich nur noch >=Q6.
1N 4. schrieb: > Abgesehen davon, dass mich der Vergleich nicht im geringsten stört, > nehme ich grundsätzlich nur noch >=Q6. Die meisten haben nunmal endlich viel VRAM und können nicht "grundsätzlich nur noch >=Q6" nehmen. Qwen3.5-9B ist bei mir auch Q8 noch recht flott. Meinst du das ist grundsätzlich besser als Qwen3.5-27B-Q3_K_M? Wäre mal ein interessanter Test. 27B-Q3_K_M und 9B-UD-Q8_K_XL sind auf der Platte praktisch gleich groß (13.5GB vs 13GB) Ich werf mal den Download an...
Weiß jemand von euch, wie man eine Spracherkennung realisiert? Ich habe mal einen neuen Thread aufgemacht, weil das Thema nur bedingt zum programmieren passt: Beitrag "KI Modell mit Spracherkennung"
> Qwen3.5-9B ist bei mir auch Q8 > noch recht flott. Meinst du das ist grundsätzlich besser als > Qwen3.5-27B-Q3_K_M? Grundsätzlich nicht. Kommt immer auf den Use Case drauf an. Wie geschrieben, langer Kontext, exzessives Tool Calling, z.B. in einem Agentic Stack. Das 27B ist breiter als das 9B, mit Q3 aber halt auch mal unschärfer in der Konsequenz. Die Dense-Modelle leiden aus meiner Erfahrung mehr unter starker Quantisierung. Da kommt es dann gerne mal beim Reasoning zu "interessanten" Ergebnissen die sich dann etliche Iterationen später negativ auswirken.
1N 4. schrieb: > Grundsätzlich nicht. Kommt immer auf den Use Case drauf an. Wie > geschrieben, langer Kontext, exzessives Tool Calling, z.B. in einem > Agentic Stack. So, ich hab die Kiste mal Nudeln lassen. Wie oben, ein 1-Shot coding Test mit Opencode. ("Implement the following in Rust: ...") Kontrahenten der 13GB auf Platte Klasse: Qwen3.5-9B-UD-Q8_K_XL Qwen3.5-27B-Q3_K_M Qwen3.6-35B-A3B-UD-IQ3_S Qwen3.6-35B-A3B-UD-Q2_K_XL (12GB) Als Vergleich: Qwen3.6-35B-A3B-UD-Q4_K_S (20GB) opencode/minimax-m2.5-free (Cloud, 230B, von Februar) opencode/big-pickle (Cloud) Die beiden Qwen3.5 Modelle scheitern beide. 27B kompiliert wenigstens... Qwen 3.6 IQ3_S war spannend anzugucken. Hat sich Quelltext zwischendurch mal als hexdump reingezogen... und am Ende ein nicht unbrauchbares Ding abgeliefert. Irgendwie Probleme gehabt und die dann kreativ teilweise geschafft zu umschiffen. Aufgabe nicht 100% gelöst, aber definitiv einige Teilpunkte errungen. Qwen 3.6 Q2_K_XL (!) hat ein absolut brauchbares Ergebnis abgeliefert. Auch da hab ich den hexdump zwischendrin gesehen. Aber so what. Da bin ich echt überrascht. Die Vergleichsmodelle haben alle gute Arbeit abgeliefert. Im Anhang hab ich den Tokenverbauch noch aufgelistet. Die beiden kleinen Qwen3.6 Modelle haben deutlich mehr Tokens verbraucht, als der Vergleich. Ich muss nochmal dazu sagen, es kann gut sein, dass die Ergebnisse anders aussehen würden, wenn ich den Test 5x wiederhole. Gerade ob Qwen3.6 Q2 immer besser als IQ3 wäre, ist fraglich. Wenn ich das richtig rechne, hätte Minimax bei Openrouter $0.16 an API Kosten verursacht. Das ist natürlich auch ein billiges Modell. Qwen 3.6-Q4 hat mit ca 18 Minuten bei ~200W GPU 2-3 ct Strom verbraucht. Die 500€ für die GPU darf man natürlich nicht gegenrechnen... Minimax war natürlich deutlich schneller fertig. (vielleicht 5 Minuten, weiß ich nicht mehr genau.)
:
Bearbeitet durch User
Ein T. schrieb: > hier soll es um die Erfahrungen im Zusammenspiel verschiedener > AI-Modelle mit Programmiersprachen und IDEs gehen. Ich nutze VS-Code mit Platformio Erweiterung um ESP und Atmegas zu programmieren. Heute hatte ich den eingebauten KI-Chat (Claude Haiku 4.5) mal ausprobiert. Da ich nicht oft programmiere und mir die ein oder andere Methode entfallen ist, wäre das mal eine gute Gelegenheit. Aufgabe in den Chat geschrieben: Die Signallaufzeit zwischen zwei abfallenden Flanken ermitteln. Die Signallaufzeit über einen gleitenden Mittelwert (Bereich 20 Werte) beruhigen und über die serielle Schnittstelle ausgeben. Nach etwas "überlegen" hat die KI meinen Quellcode ergänzt und die Ergänzungen sogar erklärt. Die KI hat nicht irgendwas reingeschrieben, sondern analysiert, was schon geschrieben steht. So jedenfalls mein Eindruck. Die Ergänzungen kann man übernehmen oder ablehnen. Ich war doch sehr überrascht, dass das einfach so funktioniert hat. Was mich noch mehr wundert: Wenn ich anfange den Quellcode mit Kommentaren oder Befehlszeilen zu ergänzen, schlägt mir der Editor das vor, was ich hinschreiben wollte. Spooky... Als Gelegenheitsprogrammierer eine tolle Hilfe.
Frank G. schrieb: > Wenn ich anfange den Quellcode mit > Kommentaren oder Befehlszeilen zu ergänzen, schlägt mir der Editor das > vor, was ich hinschreiben wollte. Spooky... Ja, das ist teilweise krank :-D Wie "in den Kopf geblickt" kommt einen das manchmal vor. Das einzige was mich daran manchmal arg nervt: Der Farbunterschied vom geschriebenen zu den Vorschlägen ist schon sehr dürftig, da gehört meiner Meinung nach ein viel größerer Kontrast rein. Wenn man gerade flüssig schreibt ist das dann schon teils nervig. Aber tatsächlich spoky! :-D
Meine Erfahrung (ohne KI gesellschaftlich, ökologisch, wirtschaftlich,... einzuordnen und zu bewerten) -> ChatGPT und Claude (insbesondere die App + Code) verkürzen frühere Arbeitsabläufe für mich enorm. Die Erfahrung, Verantwortung und das Wissen der Anwender steuert den Nutzen und die Gefahr die von KI ausgeht: Ich kann mit meinem Wissen schnell überprüfen, ob Claude auf dem "Holzweg" ist oder interessante Lösungsantworten bietet. Ich kann sicherheitsrelevante Vorgaben machen und Fehler entdecken. *Ein loses Paar Stichpunkte:* Recherche und Stunden auf Google entfallen. Dateien aufsetzen und "Anfangen" beim Coden erleichtert. ChatGPT hat vor einem Jahr noch ständig Code leicht abgeändert oder etwas dazu gedichtet oder unnötige Funktionen im Code gelassen. Das macht Claude nicht mehr. Vorsicht bei Bauteilen, Schaltungen, Lösungen, Programmierungen die leicht vom "üblichen" abweichen. Obwohl Angaben klar im Datenblatt oder in der Anweisung stehen, nimmt die KI gern das "normale". Claude Code schwafelt nicht und setzt code terminal-befehle debugging / etc. direkt um (solange man es lässt). Kann direkt Logs und Errors auslesen. Gefahr: Man verliert evtl. den Überblick oder muss sich "zwingen" den Code zu prüfen (nicht überprüfen -> prüfen ;) Projekte für die ich früher Monate gebraucht hätte (Code, Recherche, Standardberechnungen, Angaben aus Normen, ... ) kann ich schneller konzipieren und habe Zeit für andere Themen im Projekt: Verbesserungen, KiCad, usw. Was/Wie (schnell ohne viel Mühe / gut überlegt, klar, keine Rechtschreibfehler oder sonstige Fehler, kein eigenes Gelaber) der Prompt geschrieben ist, ändert sehr stark was zurück kommt. *Ich denke mir KI immer als junger Berufsanfänger:* Gute Ideen und Impulse verstecken sich manchmal unter etwas unpräzisem und falschem Gelaber und selbst Überschätzung.
Frank G. schrieb: > Wenn ich anfange den Quellcode mit Kommentaren oder Befehlszeilen zu > ergänzen, schlägt mir der Editor das vor, was ich hinschreiben wollte. > Spooky... Rene K. schrieb: > Ja, das ist teilweise krank :-D Wie "in den Kopf geblickt" So spooky wie T9 auf dem Nokia 3310.
Alexander schrieb: > So spooky wie T9 auf dem Nokia 3310. Da war nicht spooky, das war absolut vorhersehbar, da dies einer reinen Statemachine folgte - aus diesem Grund konnte man auch blind schreiben ohne auf das Display zu schauen. Und T9 hatte ich sogar schon auf dem 3210. Das ist nicht nur Birne mit Äpfel vergleich, sondern Birnen mit nem Stück Rindfleisch.
Klar.. der Kommentar über einer Funktion ist extrem schwer vorhersehbar..
Alexander schrieb: > Klar.. der Kommentar über einer Funktion ist extrem schwer > vorhersehbar.. "Sag mir das du noch nie eine KI als Agent in einer IDE genutzt hast, ohne mir zu sagen das du noch nie eine KI als Agent in einer IDE genutzt hast!" Hier geht es nicht nur um Kommentare, hier geht es um ganze Funktionen, die logisch aufeinander folgen und die ein Agent völlig aus der Luft gegriffen zusammenhängend vorschlägt. T9 war kein Vorhersagemodell, sondern eine reine Text-Liste. Drücke ich A reduziert sich die Liste auf Worte mit "A*" drücke ich dann "L" reduziert sich diese List auf alle Worte mit "AL*". Das hatte nichts mit "Vorhersagen" zu tun. Und um es auf dein "Kommentar erzeugen" zu reduzieren: Ja, eine LLM muss "verstehen" was, z.b. die Funktion die sie gerade kommentieren soll, überhaupt macht. Deren Abhängigkeiten, deren Zustandsmöglichkeiten,... Da hast es, mal wieder, einfach nicht verstanden um was es überhaupt geht. Völlig sinnlos sich bei dir den Mund fusselig zu reden.
Streiche das Atmega und das Post trifft auch auf mich zu. Dein Lese- und Textverständnis lässt mal wieder zu wünschen übrig. Es ging sehr wohl nur um Kommentare.
Operator S. schrieb: > Alles in allem bin ich deutlich produktiver, man kommt aber > nicht davon weg, dass man verstehen muss, was programmiert werden soll. Wie sieht es denn damit aus, verstehen zu können, was die KI programmiert hat? Eine Software, die z. B. 10 Jahre lang gewartet werden können soll (oft von jemandem, der diese Software noch nie gesehen hat), die muss brauchbare Kommentare, Variablennamen usw. haben. Auch schon in der ersten Version, sonst sind Tests und Debugging schwierig. Kann die KI so etwas auch berücksichtigen? Und wie verhält es sich mit in manchen Unternehmen vereinbarten Codierungs/Formatierungsregeln und -standards, die unter anderem auch dazu dienen, die Lesbarkeit durch "Fremde" zu verbessern?
Rolf schrieb: > Und wie verhält es sich mit in manchen Unternehmen vereinbarten > Codierungs/Formatierungsregeln und -standards, die unter anderem auch > dazu dienen, die Lesbarkeit durch "Fremde" zu verbessern? Diese kann man den Agenten im Ruleset mitgeben. Rolf schrieb: > Eine Software, die z. B. 10 Jahre lang gewartet werden können soll (oft > von jemandem, der diese Software noch nie gesehen hat), die muss > brauchbare Kommentare, Variablennamen usw. haben. Auch schon in der > ersten Version, sonst sind Tests und Debugging schwierig. Kann die KI so > etwas auch berücksichtigen? Mann kann sich, auch jetzt schon, eine Zusammenfassung des Codes geben lassen, eine Variablenübersicht erstellen lassen etc... Das ist jetzt schon deutlich einfacher als es vor der KI war, gerade wenn man Spaghetti Code (eigenen) vor sich liegen hat, den man so gar nicht mehr durchschaut. Wenn ich mir so betrachte, was die KI in den letzten 3-4 Jahren durchgemacht hat, möchte ich gar nicht wissen wozu sie dann in 10 Jahren fähig sein wird. Ich denke das wird dann kein großes Thema mehr sein.
Rolf schrieb: > Wie sieht es denn damit aus, verstehen zu können, was die KI > programmiert hat? Das ist gar nicht nötig. Erstens produziert die KI heute schon viel verständlicheren Code als der durchschnittlich begabte Entwickler. Zweitens: Habe ich ein Stück Code vor mir, das ich nicht verstehe - egal ob der Autor ein Mensch war oder eine KI - lasse ich mir es von einer KI erklären. Auch hier ist das Ergebnis dann verständlicher als es fast jeder gelernte Entwickler und Pädagoge könnte.
Alexander schrieb: > Streiche das Atmega und das Post trifft auch auf mich zu. Dein Lese- und > Textverständnis lässt mal wieder zu wünschen übrig. Es ging sehr wohl > nur um Kommentare. Der Begriff ODER ist dir schon geläufig oder?! Frank G. schrieb: > Wenn ich anfange den Quellcode mit > Kommentaren oder Befehlszeilen zu ergänzen, schlägt mir der Editor das > vor, was ich hinschreiben wollte. Spooky... Ach was rede ich, ich sollte es einfach sein lassen dein Quatsch zu lesen...
Rene K. schrieb: > Wenn ich mir so betrachte, was die KI in den letzten 3-4 Jahren > durchgemacht hat, möchte ich gar nicht wissen wozu sie dann in 10 Jahren > fähig sein wird. Ich denke das wird dann kein großes Thema mehr sein. Tja .. der Trend geht zum https://de.wikipedia.org/wiki/Vibe_Coding
Rene K. schrieb: > Mann kann sich, auch jetzt schon, eine Zusammenfassung des Codes geben > lassen, eine Variablenübersicht erstellen lassen etc... Eine Aufgabenstellung wie z. B. "Gibt mir ein Sortierprogramm für einhundert 16-Bit-Werte", die ist einfach und das Programm kann ein menschlicher Leser leicht nachvollziehen. Ist halt nur ein Algorithmus, den die KI aus ihrem Trainingsmaterial generieren kann. So, wie sich ein menschlicher Programmierer aus dem Internet bedienen kann. Eine Aufgabenstellung im Embedded-Bereich ist aber meist nicht so simpel, da geht es ja nicht nur um Algorithmen, sondern um ein System aus Hard- und Software. Die KI hat aber den Schaltplan nicht. Und wenn sie ihn hätte, müsste sie obendrein auch noch die Funktion mancher Bauteile kennen. Wie sagst du der KI, was die Hardware tut, mit der die Software interagieren soll? Und woher weiß die KI z. B., wie die Interrupt-Verarbeitung der jeweiligen CPU funktioniert? Woher weiß die KI, welches Port-Bit welche Funktion hat? Was ist mit der internen Peripherie des Mikrocontrollers (Timer, ADC usw.)?
Klaus schrieb: > Habe ich ein Stück Code vor mir, das ich nicht verstehe - egal > ob der Autor ein Mensch war oder eine KI - lasse ich mir es von einer KI > erklären. Auch hier ist das Ergebnis dann verständlicher als es fast > jeder gelernte Entwickler und Pädagoge könnte. Im Embedded-Bereich hast du es mit einem System aus Hardware und Software zu tun, die miteinander interagieren. Aus dem Programmcode allein lässt sich nicht genau erkennen, was da abläuft. Man braucht zusätzlich den Schaltplan, plus Informationen über die Bauteile (diese Informationen stecken ja nicht alle im Schaltplan, sondern z. B. in Datenblättern), einschließlich der konkreten CPU.
Rolf schrieb: > Woher weiß die KI, welches Port-Bit welche Funktion hat? Was ist mit der > internen Peripherie des Mikrocontrollers (Timer, ADC usw.)? Das klappt schon alles recht gut. Dafür gibt's HAL und Datenblätter. Es fragt sogar nach wenn Infos fehlen.
Rolf schrieb: > ine Aufgabenstellung im Embedded-Bereich ist aber meist nicht so > simpel, da geht es ja nicht nur um Algorithmen, sondern um ein System > aus Hard- und Software. > > Die KI hat aber den Schaltplan nicht. Und wenn sie ihn hätte, müsste sie > obendrein auch noch die Funktion mancher Bauteile kennen. Doch, hat sie - und das macht sie gar nicht mal schlecht. Aktuell "lasse" ich auf einem ESP32-S3 mit Claude einen FIDO2 Key mit NFC Leser und ISP Display schreiben. Die KI kann mir genau sagen, an welchen Pins beim M5Dial der Rotary Encoder sitzt, er erstellt mir die Init-Routinen für das I2C Display, er weiß auch an welchen Pins das beim ESP32 hängt, dieses beschreibt er natürlich mit der DMA des ESP32. Und wenn du ein selbst erstelltes Board hast, ja da gibst du ihm einfach deine KiCAD Shematic und er zieht sich das alles selbst daraus. Ich glaube teilweise wird es hier noch extrem arg unterschätzt was ein Coding Agent mittlerweile im Stande ist zu leisten.
Rolf schrieb: > Und woher weiß die KI Aus den gleichen Quellen wie der Mensch. Nur dass eine KI viel schneller suchen und filtern kann. Kürzlich selbst erlebt: Das Web-Interface eines Netzwerkswitches sollte aufgehübscht und eine Funktion ergänzt werden. Ich habe keine Ahnung von html und Javascript. Also den Coplilot rangelassen. Der hat fröhlich angefangen zu erweitern, dann compiliert, dann gemerkt, dass er viel zu viel RAM für den kleinen 8051 verbraucht hat. Dann sein Programm so lange angepasst, bis es reingepasst hat. Und schließlich noch vorgeschlagen, den existierenden Code so umzubauen, dass weniger RAM verbraucht wird und so auch zukünftige Erweiterungen noch reinpassen. Habe eine Stunde investiert. Ohne KI hätte ich (auch mangels Know-How) mindestens 2 Tage gebraucht.
Im übrigen ist hier im Projekt Bereich aktuell eines MC Projekt was komplett mit KI generiert wurde: Beitrag "Wasserstandsmessung mit RaspberryPico und Drucksensor MPX2050DP"
Rene K. schrieb: > Ich glaube teilweise wird es hier noch extrem arg unterschätzt was ein > Coding Agent mittlerweile im Stande ist zu leisten. Ich glaube das geht fast allen so. Bis man es mal selbst ausprobiert hat. Hier mal ein kleiner Beitrag eines erfahrenen Enwticklers im ESP Umfeld (Tasmota, Scripting): https://tasmota.de/forum/index.php?thread/4570-tasmota-c-compiler-auf-ger%C3%A4t/&postID=46741#post46741
Rolf schrieb: > Die KI hat aber den Schaltplan nicht. Und wenn sie ihn hätte, müsste sie > obendrein auch noch die Funktion mancher Bauteile kennen. Wie sagst du > der KI, was die Hardware tut, mit der die Software interagieren soll? > Und woher weiß die KI z. B., wie die Interrupt-Verarbeitung der > jeweiligen CPU funktioniert? > Woher weiß die KI, welches Port-Bit welche Funktion hat? Was ist mit der > internen Peripherie des Mikrocontrollers (Timer, ADC usw.)? Die großen Modelle können Bilder durchaus gut verarbeiten. Es gibt auch nen KiCad MCP (ein Konnektor zum LLM). Da kann das LLM im Zweifelsfall selber nachgucken. Datenblätter kannst du ins LLM kippen. Aber du musst natürlich schon irgendwie beschreiben, was das LLM machen soll. Wenn du Komponenten fiese zweckentfremdest, solltest du das besser beschreiben. Aber: Alles was du dem LLM gibts, steigert die Belastung des Contexts. Das LLM kann also nicht 10x150 Seiten Datenblätter komplett im Kopf haben. Es kann aber durchaus selber entscheiden, welches PDF zu durchsuchen ist. Für populäre uCs sind die (großen) Netze aber schon trainiert. Wurde ja oben schon geschrieben. Das einfach Blink example für AVR können die mit allen Registern aus dem "Gedächnis". Wenn du nen 3ct Padauk programmieren willst, dann eher nicht. Aber es ist wie bei dir auch. Wenn man exakte Details aus 10 Datenblättern braucht, damit man eine Grundfunktion implementieren kann, wird es schwierig, das automatisch zu lösen. Aber normalerweise lässt sich sowas ja splitten, so dass nur weniger Informationen gleichzeitig gebraucht wird.
Ich versuche, gemma 4 auszuprobieren:
1 | docker exec -it ollama ollama run gemma4:e2b |
Im Moment brauche es gerade ewig, bis es heruntergeladen ist und läuft dann voraussichtlich in der Kommandozeile. Kann man das Ding in irgend einen Coding-Agenten einbinden und wie?
Christoph M. schrieb: > Kann man das Ding in irgend einen Coding-Agenten einbinden und wie? Du nimmst ein Coding-Plugin was lokale KI unterstützt (z.B. "Continue" für vscode), und trägst dort ein dass es die Ollama-API unter 127.0.0.1:11434 erreicht. (Den Port solltest du per Docker auch durchreichen) Ansonsten macht es Sinn, da ein persistentes Volume anzugeben (damit die Modelle nicht alle Nase lang neu herunter geladen werden müssen) und nötige device-nodes in den Docker-Container zu geben, z.B. /dev/dri, damit dort auch Hardwarebeschleunigung funktioniert (/dev/dri für OLLAMA_VULKAN=1) PS: Nicht erschrecken wenn Continue einen Login von dir will, die wollen auch nur ihre KI-Dienste verkaufen. Kann man einfach wegklicken und ignorieren.
:
Bearbeitet durch User
Εrnst B. schrieb: > (Den Port solltest du per Docker auch > durchreichen) Docker macht mich im Moment gerade wahnsinnig und ich überlege es zu installieren und alles "native" zu machen. Im Moment klappt nicht mal von docker open-webgui auf den ollama zuzugreifen. Ganz konkret weiß ich nicht, wie man den Port durchreicht.
:
Bearbeitet durch User
Christoph M. schrieb: > Docker macht mich im Moment gerade wahnsinnig und ich überlege es zu > installieren und alles "native" zu machen. Dann lass Docker doch einfach sein. Das LLM hat keinen direkten Zugriff auf irgendwas. Vor allem nicht, wenn du noch nen Coding Agenten dazuschaltest. Den solltest du vielleicht isolieren. Weil der nämlich KI gesteuert das tut, was er will. Die allermeisten Coding-Tools haben Zugriffsberechtigungen. Wo teilweise alles abgesegnet werden muss. Wirste aber wahnsinnig bei, wenn alle 30s ein "darf Datei x.cpp" geschrieben werden" abgenickt werden will. Im Yolo Modus kann der aber auch einfach alles Löschen... Ollama selbst ist IMO nicht das Sicherheitsproblem.
Rolf schrieb: > Eine Aufgabenstellung im Embedded-Bereich ist aber meist nicht so > simpel, da geht es ja nicht nur um Algorithmen, sondern um ein System > aus Hard- und Software. > > Die KI hat aber den Schaltplan nicht. Und wenn sie ihn hätte, müsste sie > obendrein auch noch die Funktion mancher Bauteile kennen. Wie sagst du > der KI, was die Hardware tut, mit der die Software interagieren soll? Na einfach direkt sagen. Die anderen haben ja bereits geschrieben, dass die KI Datenblätter und teilweise auch Schaltpläne lesen kann, aber wenn es z.B. gar keinen Schaltplan gibt, weil man halt kurz mal was zusammengesteckt hat (z.B. einen ESP32 mit einem Display), dann sagt man das halt. Also ESP32-S3, mit xxMB Speicher, Display mit xyz Controller, welche Auflösung das hat, welche Pins am Mikrocontroller an welche Pins vom Display angeschlossen wurden usw. usf. Man kann das auch einfach in eine Textdatei schreiben und der KI sagen, dass das dort steht. Und es geht auch durchaus andersrum, also dass die KI den Code eines bestehenden Projektes liest und dann sagt, was wo angeschlossen ist und das in einer Textdatei dokumentiert. Bei den ESP32 gibts ja die serielle Debug-Console und die kann die KI (also jedenfalls github copilot in VSCode, aber wahrscheinlich auch andere) lesen. Wenn es dort einen Crash mit Stacktrace gibt, dann analysiert sie das, findet und behebt das Problem und flasht dann neu. Wenn das nicht geholfen hat dann probiert sie es nochmal. Sie kann auch Debug-Ausgabe da rein machen und das dann auswerten. Das fand ich schon sehr beeindruckend.
1 | ├────────────────────────────────────────────────────────┤ |
2 | │llama.cpp/Qwen3.6-35B-A3B-UD-Q4_K_S │ |
3 | │Sessions 21 │ |
4 | │Messages 1,216 │ |
5 | │Avg Tokens/Session 2.5M │ |
6 | │Median Tokens/Session 774.2K │ |
7 | │Input 2.1M │ |
8 | │Output 417.5K │ |
9 | │Cache Read 49.0M │ |
10 | └────────────────────────────────────────────────────────┘ |
Hab heute nochmal bisschen was rumgebastelt. Kein Test-Kram, aber auch nichts weltbewegendes. Irgendein CLI Tool, um mir was zu erleichtern. Diesmal mit TUI Interface. Viel hin und her. Mach mir dieses Feature, mach das, nee doch nicht, änder noch ... Gelegentlich mal ne neue Session gestartet, damit der Kontext nicht überläuft. Ich hatte den Kontext auch nur auf 100k beschränkt, da musste gelegentlich mal kompaktiert werden. Das ging überraschend gut. Eigentlich gab es nie Probleme oder irgendwas wurde nicht verstanden oder falsch umgesetzt. Na gut, ich hab mich nicht immer gut ausgedrückt. Weil das bei mir mit ~20t/s vorangeht, konnte ich den Denkprozess dann halb verfolgen und hab opencode dann doch manchmal unterbrochen. Doch Probleme gab es einmal. Da wollte ich die GIT history umschreiben lassen. Irgendwo hatte ich nen feature-branch eröffnen lassen und imo nicht sauber in den master gemerged. Also mir hat eigentlich nur nicht gefallen, wie das gemerged wurde. Entweder das geht überhaupt nicht wie ich das wollte, es wurde nicht richtig verstanden, oder einfach Murks produziert. Richtig zerschossen wurde der Tree nicht, aber ich hab am Ende doch ein Backup eingespielt und es so belassen. Wer Spaß am Code schreiben hat, für den ist das nichts. Ich guck erst jetzt mal den Code an. Sieht IMO schon ok aus. Man ist eher der Projektleiter & Tester, der dem kompetenten Azubi über die Schulter schaut. Damit kommt man bedeutend schneller zu einem Ergebnis. Und es macht IMO einfach Spaß, irgendwas umzusetzen, wozu einem sonst einfach die Zeit fehlen würde. Klar wäre ein kommerzielles Modell schneller gewesen und hätte vermutlich auch weniger Tokens gebraucht. Mit den kosten von Qwen3.5-35B-A3B bei Openrouter wären das jetzt 6€ gewesen. Ich hab mal 50ct für Strom überschlagen. Mit dem 10$ Monatsabo von opencode hätte das etwa 8% des Monatslimits bedeutet. Danke fürs zuhören.
Mathias M. schrieb: > Klar wäre ein kommerzielles Modell schneller gewesen und hätte > vermutlich auch weniger Tokens gebraucht. Da wäre die Frage, ob man mehrere Modelle gleichzeitig einbinden könnte (z.B. Gemma 4) und sich die Modelle gegenseitig unterstützen könnten. Es gibt ja Agentensysteme für andere Aufgaben, die das tun. Mathias M. schrieb: > Danke fürs zuhören. :-) P.s: Welche Maschine hattest du gleich noch?
Also man kann durchaus verschiedene Modelle einbinden. Einen zum Planen,
einen zum coden lassen, einer guckt über den Pull Request drüber und
bewertet den nochmal. Ich bin da nicht zu tief drin, ich hab kein Abo
und nutz das momentan nur zum Spaß. Aber AFAIK nutzt man zum planen das
beste Modell, dass einem zur Verfügung steht. Gut geplant kann dass dann
auch eine moderat schlaue KI coden.
Für eine Aufgabe nutzt man aber immer nur eine zur Zeit. Wobei, es gibt
spekulatives decoding. Da hat man ein "billiges" Modell, dass die die
Token vorhersagt. Keine Ahnung wie, aber llama.cpp kann dann überprüfen,
ob das große Modell das gleiche Token erzeugt hätte, ohne dass es
wirklich berechnet werden müsste. War es falsch, muss das große Modell
ran. Wenn die Trefferrate des kleinen Modells hoch genug ist, bekommt
man damit einen Speedup. Je nach Aufgabe sollen das so 10-30% mehr t/s
sein.
Qwen 3.6 hat sogar ein draft Modell direkt drin. Da musst du llama.cpp
nur mit z.B. `--spec-type ngram-mod --spec-ngram-size-n 24 --draft-min
12 --draft-max 48` starten, dann wird das genutzt. Oft muss man aber ein
zusätzliches Modell laden, was dann natürlich mehr Speicher braucht. Ich
habs nie gebenchmarkt...
> P.s: Welche Maschine hattest du gleich noch?
AM4 System, 32 GB Dual Channel DDR4 + RX 9070 (16GB)
Kein wirklich fettes Ding. Die GPU gibts ab 550€. Ist aber IMO auch die
Untergrenze des brauchbaren - wenn man nicht gebraucht kauft.
1 | Draconix@Rene~$ ollama run qwen3.5:9b |
2 | >>> Hi! |
3 | |
4 | total duration: 2.20826532s |
5 | load duration: 283.887341ms |
6 | prompt eval count: 35 token(s) |
7 | prompt eval duration: 450.158065ms |
8 | prompt eval rate: 77.75 tokens/s |
9 | eval count: 25 token(s) |
10 | eval duration: 1.452489512s |
11 | eval rate: 17.21 tokens/s |
aus Beitrag "Re: Erfahrungen mit AI-Coding" Rene K. schrieb: > Achso, ja... ein alter Testrechner mit einem I7-9800x / 16GB und einer > RTX2070 mit 8GB. Auf was er da nun rechnet, keine Ahnung. Hier mal der Vergleich mit Ryzen 5 1600 / 16GB und RTX5060 mit 8GB
1 | christoph@Ryzen5:~$ docker exec -it ollama ollama --verbose run qwen3.5:9B |
2 | >>> Hi! |
3 | total duration: 12.755300431s |
4 | load duration: 323.007954ms |
5 | prompt eval count: 12 token(s) |
6 | prompt eval duration: 72.503984ms |
7 | prompt eval rate: 165.51 tokens/s |
8 | eval count: 272 token(s) |
9 | eval duration: 12.087102373s |
10 | eval rate: 22.50 tokens/s |
Seltsam: Meine Version braucht 3 x länger, die Tokenrate ist aber deutlich höher .. da muss sich das Ding was ganz anderes gedacht habe oder die Einstellungen des Modells sind komplizierter.
Und hier noch das gleiche auf einer Spark DGX:
1 | total duration: 11.188978004s |
2 | load duration: 156.919815ms |
3 | prompt eval count: 12 token(s) |
4 | prompt eval duration: 54.145474ms |
5 | prompt eval rate: 221.63 tokens/s |
6 | eval count: 405 token(s) |
7 | eval duration: 10.863034707s |
8 | eval rate: 37.28 tokens/s |
Interessant: die Prompt-Eval Rate ist auf Spark gar nicht so viel höher .. ob der Docker-Container das runter bremst?
Ich habe mal mit Docker / Ollama rumexperimentiert, eigentlich völlig quark, ich habe dann Ollama wieder ganz einfach lokal installiert. Gerade wenn man Ollama extern als Agent nutzen möchte ist das weeeesentlich entspannert, schon alleine der Netzwerkgeschichte wegen. Christoph M. schrieb: > Hier mal der Vergleich mit Ryzen 5 1600 / 16GB und RTX5060 mit 8GB Bist du dir auch ganz sicher, das das Modell komplett in die GPU geladen wurde? Macht dann mal ein zweites terminal auf und schau mal mit "ollama ps" ob er 100% auf GPU läuft oder 70/30 teilt. Wenn z.b. die GPU schon Speicher für einen Desktop bereitstellt, dann reicht das nicht mehr für das 9B Modell.
Christoph M. schrieb: > Docker macht mich im Moment gerade wahnsinnig und ich überlege es zu > installieren und alles "native" zu machen. Im Moment klappt nicht mal > von docker open-webgui auf den ollama zuzugreifen. > Ganz konkret weiß ich nicht, wie man den Port durchreicht. docker run --publish 8081:8080 image 8080 ist der Port der Applikation im Container, 8081 der externe.
Ein T. schrieb: > docker run --publish 8081:8080 image Würd ja gleich ein docker-compose-File anlegen. Dann muss man sich das nicht alles merken. Vor allem wenn noch mehr Optionen dazumüssen, damit die Grafikkarte mitspielen darf.
1 | services: |
2 | ollama: |
3 | image: ollama/ollama |
4 | ports: |
5 | - "127.0.0.1:11434:11434" |
6 | networks: |
7 | - ollama-docker |
8 | devices: |
9 | - /dev/dri:/dev/dri |
10 | cap_add: |
11 | - CAP_PERFMON |
12 | group_add: |
13 | - video |
14 | - 107 |
15 | volumes: |
16 | - ollama-data:/root/.ollama |
17 | environment: |
18 | - OLLAMA_VULKAN=1 |
19 | |
20 | webui: |
21 | image: ghcr.io/open-webui/open-webui:main |
22 | volumes: |
23 | - webui-data:/app/backend/data |
24 | depends_on: |
25 | - ollama |
26 | ports: |
27 | - "127.0.0.1:8880:8080" |
28 | environment: |
29 | - OLLAMA_BASE_URLS=http://ollama:11434 |
30 | - ENV=dev |
31 | - WEBUI_AUTH=... |
32 | - WEBUI_NAME=MyStupidAI |
33 | - WEBUI_URL=http://localhost:8880 |
34 | - WEBUI_SECRET_KEY=***** |
35 | networks: |
36 | - ollama-docker |
37 | |
38 | volumes: |
39 | ollama-data: |
40 | webui-data: |
41 | |
42 | networks: |
43 | ollama-docker: |
Εrnst B. schrieb: > Würd ja gleich ein docker-compose-File anlegen. Das scheint eine interessante Idee. Dein Compose-File vereinigt sowohl Ollama als auch WebUi. Bei mir sind die auf zwei getrennten Maschinen. Vermutlich braucht man, Wenn alles eingerichtet ist, das Dockerfile nur einmal um den Container zu erstellen. Ich frage mich, ob Docker jedesmal wenn Docker-Compose gestartet wird, die riesigen, Gigabyte großen LLM jedes mal verdoppelt.
Das AI-Coding scheint mir verschiedene Stufen zu haben: Die erste ist Codegenerierung mit Copy- und Paste mit ChatGPT oder ähnlich. Die nächste Stufe ist eine IDE wie z.B. vscodium, in der man die KIs integrieren kann. Die Kunst ist da aber die Auswahl der richtigen Modelle für die entsprechende Aufgabe: Beitrag "Re: KI Modellzoo" Im Moment scheint mir vscodium einen großen Vorteil gegenüber vscode zu haben, weil die Grundkonfiguration auf minimale Belästigung ausgelegt ist (Linux Style). Allerdings bin ich mir noch nicht so sicher, ob diese Art der komplexen IDEs für mich große Vorteile haben. Große Teile meiner Software habe ich nur mit Texteditoren geschrieben, weil es da keine lästigen, undurchschaubaren Abhängigkeiten gibt. Die ultimative Stufe der Code-Entwicklung dürfte allerdings die von Andreas-Spieß vorgestellte sein: https://www.youtube.com/watch?v=nmGEedloQ6E Wenn das so mit Requirements-Engineering und automatischer Testerstellung funktioniert, dürften 80% der Informatikerstellen in Großbetrieben wegfallen.
Rene K. schrieb: > Gerade wenn man Ollama extern als Agent nutzen möchte ist das > weeeesentlich entspannert, schon alleine der Netzwerkgeschichte wegen. Vielleicht arbeite ich schon zu lange mit Docker, aber diese Sache mit dem Netzwerk erscheint mir dabei wirklich einfach: ein Programm lauscht in dem Container auf einem bestimmten Port, sagen wir: 1234, und dieser soll von außerhalb des Containers über Port 5678 erreichbar gemacht werden. Das geht ganz einfach über den Kommandozeilenparameter "--publish 5678:1234" bei den Kommandos "docker create" (das einen Container nur erzeugt) beziehungsweise "docker run", das einen Container erzeugt und direkt startet. Wer mag, kann diesen Host-Port auch einfach an eine bestimmte IP-Adresse binden, das geht einfach mit "--publish 127.0.0.1:5678:1234" für den Lokal-Horst. Oh, ach ja: natürlich kann man auch mehrere Ports dergestalt öffnen, "--publish" wird dabei einfach mehrmals angegeben. Wenn Ihr Fragen zu Docker habt, helfe ich gerne.
Εrnst B. schrieb: > Ein T. schrieb: >> docker run --publish 8081:8080 image > > Würd ja gleich ein docker-compose-File anlegen. Beste Lösung, haste Recht. :-)
Christoph M. schrieb: > Das scheint eine interessante Idee. Dein Compose-File vereinigt sowohl > Ollama als auch WebUi. Bei mir sind die auf zwei getrennten Maschinen. Es bleiben trotzdem zwei Container. > Vermutlich braucht man, Wenn alles eingerichtet ist, das Dockerfile nur > einmal um den Container zu erstellen. Mit einem Dockerfile werden nur Images erzeugt, auch das läßt sich mit einem Dockerfile im selben Verzeichnis und dem Befehl "docker compose build" über die compose.yml anstoßen. Mit der compose.yml oder dem Aufruf von docker auf der Kommandozeile werden aus den Images dann Container erstellt, indem einem Image der Name und und Laufzeitkonfiguration des Containers zugefügt werden. Container sind daher grundsätzlich Wegwerfware. Man kann bestimmte Optionen der Konfiguration eines Containers zwar ändern, aber meistens wirft man den Container stattdessen einfach weg und erzeugt ihn neu. Das bedeutet: alles, was während der Laufzeit im Container gespeichert worden ist, ist nach der Neuerzeugung natürlich verschwunden. Deswegen benötigt man Bind oder Volume Mounts, wenn die gespeicherte Daten die Neuerzeugung überleben sollen. > Ich frage mich, ob Docker jedesmal > wenn Docker-Compose gestartet wird, die riesigen, Gigabyte großen LLM > jedes mal verdoppelt. Ernsts compose.yml verwendet dazu die Volumes "ollama-data" und "webui-data". Diese bleiben über den Tod und die Wiederauferstehung der Container erhalten, und müssen bei Bedarf manuell gelöscht werden.
Ein T. schrieb: > verwendet dazu die Volumes "ollama-data" Statt den docker-volumes geht natürlich auch einfach ein Order vom Host, macht es einfacher wenn z.B. die Modell-GGUF-Files zwischen verschiedenen Services geteilt werden sollen. (hardlinks, CoW-Reflink-Copies, ...)
1 | volumes: |
2 | - /opt/mein_model_zoo/ollama:/root/.ollama |
Εrnst B. schrieb: >
1 | > volumes: |
2 | > - /opt/mein_model_zoo/ollama:/root/.ollama |
3 | > |
Tipp: in compose.yml gibt es ja einen Bezugspunkt, daher sind dort anders als beim Kommandozeilen-Aufruf von Docker auch relative Pfade möglich. Das gehört zu den Gründen, weswegen ich die compose.yml auch dann bevorzuge, wenn es nur um einzelne Container geht. :-)
Wir wollten unbedingt alle so viel KI Nutzen, wie nur irgend möglich. Dann wird sie uns allen Wohlstand in einer sauberen Welt verschaffen. Wir müssen die fossilen Brennstoffe (incl. Uran) unbedingt noch ganz schnell verstromen, bevor sie ungenutzt im Erdreich versauern. Und wir müssen den Menschen die Arbeit weg nehmen, damit sie mehr Zeit haben zum konsumieren haben. Sonst wird das nichts. "Links ist vorbei" (Friedrich Merz)
:
Bearbeitet durch User
Hans W. schrieb: > Wir wollten unbedingt alle so viel KI Nutzen, wie nur irgend möglich. Dein Klagelied ist zutiefst ergreifend, gehört aber nicht hierher.
Εrnst B. schrieb: > Christoph M. schrieb: >> Kann man das Ding in irgend einen Coding-Agenten einbinden und wie? > > Du nimmst ein Coding-Plugin was lokale KI unterstützt (z.B. "Continue" > für vscode), und trägst dort ein dass es die Ollama-API unter > 127.0.0.1:11434 erreicht. (Den Port solltest du per Docker auch > durchreichen) Möglicherweise ist es sinnvoll, den Coding-Agent ebenfalls zu verdockern und die Code-Repos per Bind Mount einzubinden. Das könnte man dann elegant mit Docker Compose orchestrieren und so auch wirksam verhindern, daß der Coding Agent komische Sachen außerhalb des Bereichs macht, in dem er arbeiten soll.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.