🧪 Ich habe drei lokale LLMs in LM Studio auf meinem Apple M2 Max (96 GB) gegeneinander getestet. Das überraschendste Ergebnis war nicht die Antwortqualität – sondern die Zeit, die die Modelle zum Denken brauchen. ───────────────────────────── 🔬 DIE DREI MODELLE ───────────────────────────── ① Qwen3.5-27B · Claude 4.6 Opus Distilled (14 GB) ② Qwen3.5-35B-A3B · Claude 4.6 Opus Distilled, MoE (19,5 GB) ③ Qwen3.5-27B Original – kein Finetuning (14 GB) 6 Aufgaben: Python-Code, Debugging, API-Client-Architektur, deutsche Geschäftstexte, Rechtsfragen (revDSG). ───────────────────────────── ⏱ DER THINKING-SCHOCK ───────────────────────────── Diese Modelle denken laut – sie haben einen sichtbaren „Thinking"-Block bevor die Antwort erscheint. Und genau da lag der wahre Unterschied. Beispiel: Eine einfache Sortierfunktion in Python. 🟣 27B Distilled: 4 Sekunden 🟢 35B MoE: 4 Sekunden ⬜ 27B Original: 173 Sekunden Dasselbe Ergebnis. Dreimal. Der gleiche Prompt. Das Original grübelt fast 3 Minuten über eine Aufgabe, für die das Distilled-Modell 4 Sekunden braucht. Über alle 6 Aufgaben: 🟣 27B Distilled: 87 Sekunden gesamt 🟢 35B MoE: 55 Sekunden gesamt ⬜ 27B Original: ~775 Sekunden gesamt ───────────────────────────── 💡 WARUM IST DAS SO? ───────────────────────────── Beim Knowledge Distillation lernt das kleinere Modell nicht aus Rohdaten – es lernt aus den vollständigen Reasoning-Trajektorien eines Frontier-Modells (hier: Claude 4.6 Opus). Das bedeutet konkret: → Das Original-Modell exploriert beim Denken: es probiert Wege aus, verwirft sie, dreht im Kreis – sichtbar im Thinking-Block als endlose Bullet-Listen → Das Distilled-Modell hat Claudes Denkmuster internalisiert: strukturieren → Teilprobleme identifizieren → direkt lösen. Kein Herumirren. → Das Ergebnis: nicht nur bessere Antworten, sondern ein fundamental effizienterer Denkprozess Das ist der eigentliche Wert der Destillation. Nicht mehr Wissen – sondern besseres Denken. ─────────────────────────────

Wer von Euch mit LM Studio arbeitet sollte mit dem aktuellen Update vorsichtig sein. Die Version 0.3.39 bringt bei mir einen Fehler bei der Nutzung mit n8n, so wie es aussieht ist da ein required Parameter hinzugekommen den die OpenAI Node von n8n noch nicht kennt. In den Release Nodes konnte ich aber nichts finden.

Ich habe mich heute einmal dem n8n Workflow Buchhaltung automatisieren gewidmet. Vielen Dank ersteinmal für die Bereitstellung des Workflows. Das hat schon sehr geholfen, das ganze selbst zu adaptieren. 2 Rückfragen habe ich: In der Node: "Erstelle Buchungsvorschlag" übergibst du am Ende das Markdown mit {{ $('OCR').item.json.pages[0].markdown }}. Damit werden bei mehrseitigen PDFs nur die erste Seite für die Erstellung des Buchungsvorschlags genutzt. Frage: Ist das Absicht? Warum nicht alle Seiten für die Vorschläge berücksichtigen? Nicht jede Rechnung hat alle relevanten Informationen auf einer Seite. ----- In der Node: "Ermittle Steuer ID" setzt du zwar eine Tax Rate für Deutschland i.H.v. 19% diese kommt bei mir aber nie zur Anwendung, weil diese überschrieben wird ab Zeile 44 mit // Steuersatz auslesen (SevDesk gibt "ZERO", "NINETEEN" zurück) if (finalRule.taxRates && finalRule.taxRates.length > 0) { if (finalRule.taxRates[0] === 'ZERO') taxRate = 0; else if (finalRule.taxRates.includes('NINETEEN')) taxRate = 19; else if (finalRule.taxRates.includes('SEVEN')) taxRate = 7; } die taxRate auf 0 setzt, wenn Sevdesk in der Guidance 0 zulässt. Frage: Macht es hier nicht mehr Sinn beim höchsten Steuersatz zu beginnen?