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.
Ein T. schrieb: > Einfach bei diesem Thema zu bleiben ist wirklich nicht schwierig. Wer > nichts dazu beitragen kann, sagt dann einfach mal genau das: nichts. Nicht mit Bradward diskutieren. Geh davon aus, er ist ein ChatBot.
> 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.
Frank D. schrieb: > > 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. Jupp.
Rene K. schrieb: > 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 |
2 | > |
>
Ne, sowas macht man nicht.
Einfach irgendwelchen Code ausführen?
Ne, sowas macht man nicht.
Johannes schrieb: > Frage: Können die lokalen Modelle auch dazulernen, [...] ChatGPT Versuch einfach mal zu verstehen, was das P in ChatGPT bedeutet.
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.
Jens B. schrieb: > Ne, sowas macht man nicht. > Einfach irgendwelchen Code ausführen? > Ne, sowas macht man nicht. Du kannst auch einfach deine Fenster mit Holzbrettern vernageln, du kannst dein Schornstein abdichten damit der Weihnachtsmann nicht mehr durchkommt zum spionieren, du kannst einfach auch dein Alu-Hut aufsetzen damit der Satellit dich nicht auskundschaftet... ... du kannst dich auch einfach nur aus einer Unterhaltung raushalten wenn du mal absolut nur Bullshit dazu beizutragen hast und absolut null Ahnung! Dankeschön!
Jens B. schrieb: > Ne, sowas macht man nicht. Ist ja klar das man das script nicht blind ausführt, da schaut man erst mal rein was das lädt, bricht nach dem laden ab und scannt das mal grob, mehr kann man dann auch nicht machen sonst wirst du nie fertig. Führe es halt in einer Sandbox/VM aus wenn du dem Zeug nicht raust.
Rene K. schrieb: > Jens B. schrieb: >> Ne, sowas macht man nicht. >> Einfach irgendwelchen Code ausführen? >> Ne, sowas macht man nicht. > > Du kannst auch einfach deine Fenster mit Holzbrettern vernageln, du > kannst dein Schornstein abdichten damit der Weihnachtsmann nicht mehr > durchkommt zum spionieren, du kannst einfach auch dein Alu-Hut aufsetzen > damit der Satellit dich nicht auskundschaftet... > > ... du kannst dich auch einfach nur aus einer Unterhaltung raushalten > wenn du mal absolut nur Bullshit dazu beizutragen hast und absolut null > Ahnung! > > Dankeschön! Ach ja, auf Dummheit hinweisen ist heutzutage ja voll schlecht. Deine Antwort zeigt wer von uns mehr Ahnung hat. Tipp: Du bist es anscheinend nicht.
Frank D. schrieb: > Ist ja klar das man das script nicht blind ausführt, da schaut man erst > mal rein was das lädt, …was bei einem ›pipe‹ direkt in die shell bestimmt ein interessantes Unterfangen wird. ;-)
Jens B. schrieb: > Ach ja, auf Dummheit hinweisen ist heutzutage ja voll schlecht. > Deine Antwort zeigt wer von uns mehr Ahnung hat. > Tipp: Du bist es anscheinend nicht. Das ist KEIN Script von irgendeiner dubiosen Russischen Warez-Seite. Den Windowsinstaller führst du ja auch ohne jegliche Überprüfung aus, selbst den Chrome, FF oder whatever... führst auch ohne jegliche Überprüfung aus. Du installierst dir sicherlich fast alles auf deinem PC OHNE jegliche Überprüfung aus, seien es Treiber für Grafikkarten etc... Oder hast du einblick in sämtlichen Code den DU auf deinem Rechner ausführst. Mei mei, setz deinen Aluhut ab und komm mal im realen Leben an!
Jens B. schrieb: > 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...
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.