Lokales Gemma war zu langsam mit AIdaemon, bis ich llama.cpp und die Prompt-Größe optimierte

Ich betreibe AIdaemon meistens auf meinem Mac. Es ist der selbst gehostete Agent-Daemon, den ich in Rust entwickelt habe. Monatelang war das LLM-Backend OpenRouter, plus Gemini, dessen kostenloser Tarif großzügig war. Als er aufgebraucht war, zahlte ich ein paar Dollar im Monat für etwas, das ich selbst hosten konnte. Ich wollte einfach lokale Inferenz mit Googles Gemma-Familie ausprobieren, ohne eine Laufzeitumgebung hinzuzufügen, die ich nicht bereits verwendete.

Ich hatte llama.cpp über Homebrew installiert und ein Gemma 4 26B MoE GGUF auf der Festplatte (unsloth/gemma-4-26B-A4B-it, Q4_K_M), etwa sechzehn Gigabyte, auf einem M4 Pro mit 48 GB einheitlichem Speicher. Ollama wäre der einfache Weg gewesen. Ich habe es absichtlich übersprungen, da es sowieso llama.cpp umschließt und ich die Performance-Flags direkt haben wollte.

Der Stack sah am Ende so aus.

Telegram / Slack → AIdaemon → llama-server (OpenAI-kompatible API) → Gemma 4 26B GGUF

AIdaemon lädt keine Modellgewichte. Es spricht mit allem, was wie die OpenAI-Chat-API aussieht. llama.cpps llama-server passt in diese Form.

Erste Schritte

Die erste Hürde waren die Ports. AIdaemon belegt bereits 8080 für Health Checks und OAuth-Callbacks. llama-server verwendet standardmäßig denselben Port. Ich habe die Inferenz auf 8081 gelegt.

Die zweite Hürde war der Denkmodus. Gemma 4 hat standardmäßig die Denk-/Schlussfolgerungsfunktion im Chat-Template aktiviert. llama-server protokollierte beim Start thinking = 1. Antworten landeten in reasoning_content, während content leer zurückkam. AIdaemon liest content. Von Telegram aus sah es so aus, als wäre das Modell stumm geworden.

Die Lösung war ein Flag.

llama-server \
  -m ~/models/llm/gemma-4-26b/gemma-4-26B-A4B-it-UD-Q4_K_M.gguf \
  --jinja \
  --reasoning off \
  -c 16384 \
  -ngl 99 \
  --alias gemma-4-26b \
  --host 127.0.0.1 \
  --port 8081

--jinja ist wichtig für das Template von Gemma 4. --reasoning off ist wichtig für AIdaemon. Ohne dieses Flag debuggen Sie den Agenten, während das Modell tatsächlich in ein Feld antwortet, das niemand liest.

Und ich würde es auch ohne diesen Fehler ausgeschaltet lassen. Denken verbraucht vor jeder Antwort einen Haufen zusätzlicher Tokens, was bei einem lokalen Modell zu echter Latenz führt, und ein Agent erhält einen Teil dieser Schlussfolgerung kostenlos zurück, indem er eine Aufgabe über Tool-Aufrufe mit echtem Feedback bearbeitet, anstatt einen langen internen Monolog zu führen. Ich tausche etwas Tiefen-Schlussfolgerungsspielraum gegen Geschwindigkeit, was für einen schnellen lokalen Assistenten die richtige Entscheidung ist, und ich kann es für die seltene Aufgabe wieder einschalten, die es wirklich braucht.

Auf der AIdaemon-Seite zeigte der Provider-Block auf den lokalen Server.

[provider]
api_key = "local"
base_url = "http://127.0.0.1:8081/v1"
kind = "openai_compatible"
max_tokens = 4096

[provider.models]
default = "gemma-4-26b"
fallback = []

Ich behielt OpenRouter als [[provider.fallbacks]]-Eintrag, damit ein ausgefallener llama-server den Daemon nicht lahmlegt. Der lokale Modellname muss mit --alias auf llama-server übereinstimmen, nicht mit dem Hugging Face Repo-Slug.

Rauchtest vor der Berührung von Telegram.

curl http://127.0.0.1:8081/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"gemma-4-26b","messages":[{"role":"user","content":"Say hi."}],"max_tokens":50}'

Wenn content leer und reasoning_content voll ist, ist das Denken immer noch aktiviert.

Warum es sich trotzdem langsam anfühlte

Einfache Nachrichten waren in Ordnung. Agentenarbeit nicht. Ich schickte etwas Normales auf Telegram und wartete. Und wartete.

Das llama-server-Protokoll erzählte die Geschichte. Prompts um die 14.500 Tokens. Das ist kein Tippfehler und keine einzelne fette Nutzernachricht. Bei einem 16k-Kontextmodell budgetiert AIdaemon Nachrichten plus Tool-Schemas auf etwa 14,8k und reserviert den Rest für die Ausgabe. Ich lief bei jeder Runde gegen die Decke.

Ein paar Dinge füllen diese Nutzlast.

• System-Prompt. Betriebsregeln, Sicherheitsleitplanken, Spezialistenliste, Kanal-Kontext. Eine große statische Vorlage. Bei späteren Schleifendurchläufen wird die Markdown-Tool-Anleitung weggelassen, aber der Kern-Prompt ist immer noch tausende von Tokens.
• Tool-JSON-Schemas, die bei jedem LLM-Aufruf separat von den Chat-Nachrichten gesendet werden. Mit meiner vollständigen Installation sind das etwa 35 bis 40 integrierte Tools, plus alle MCP-Tools, die zur Runde passten. Namen, Parameter, erforderliche Felder, Enums. Beschreibungen summieren sich auch nach der Komprimierung.
• Konversationsverlauf. Kollabierte letzte Runden, optionale Sitzungszusammenfassung und vollständige Tool-Ergebnisse für die aktuelle Interaktion. Ein paar dicke terminal- oder read_file-Ausgaben können die Schema-Kosten übersteigen.
• Speicher, und nicht Ihr gesamter Faktenbestand. Ein kleiner kritischer Fakten-Pin und Anweisungen, den Rest bei Bedarf über Speicher-Tools abzurufen.

Die erste Iteration einer Runde ist schlimmer. Der System-Prompt enthält immer noch die Markdown-Tool-Dokumentation und die JSON-Schemas werden parallel gesendet. Chat-UIs senden eine Blase. Agenten-Daemons versenden ein Betriebshandbuch plus einen Tool-Katalog plus das, was der letzte Befehl zurückgegeben hat.

Lokale Inferenz hat zwei Geschwindigkeiten, und sie verhalten sich sehr unterschiedlich.

• Prefill ist das Modell, das Ihren Prompt liest. Die Zeit skaliert mit der Prompt-Größe. Hier schlagen Agenten-Workloads zu.
• Generierung ist das Modell, das die Antwort schreibt. Der Durchsatz bleibt ungefähr gleich, egal ob der Prompt kurz oder lang war.

Auf meiner Box war dieser Unterschied wichtiger als jedes einzelne llama.cpp-Flag.

Inferenzgeschwindigkeit auf meinem M4 Pro

Hardware für diese Zahlen. Apple M4 Pro, 48 GB einheitlicher Speicher, gemma-4-26B-A4B-it-UD-Q4_K_M.gguf (Unsloth Q4_K_M), llama.cpp Build 9140, vollständiges Metal-Offload (-ngl 99), optimierte Single-Slot-Konfiguration unten. Gemma 4 26B ist MoE, etwa 4B aktive Parameter zur Inferenzzeit. Die Generierung fühlt sich näher an einem mittelgroßen Modell an. Prefill durchläuft immer noch den gesamten Prompt.

Ich habe die Timings aus dem timings-Feld von llama-server in der OpenAI-kompatiblen JSON-Antwort nach einem warmen Modell extrahiert. Derselbe Server, der heute läuft.

Prompt-Größe	Eingabe-Tokens	Prefill-Wandzeit	Prefill tok/s	Generierungs-tok/s
Kurzer Chat (warm)	49	0,2 s	~230	~48
Kleine Agentenrunde	~1.000	1,6 s	~650	~44
Mittlerer Kontext	~5.000	6,2 s	~630	~43
Großer Kontext	~10.000	8,9 s	~550	~40
Echte AIdaemon-Runde	~14.500	8,4 s	~480	~35

Die Generierung blieb durchweg bei etwa 40 bis 48 tok/s. Prefill dominierte. Ein Agenten-Prompt mit ~14,5k Tokens dauerte etwa achteinhalb Sekunden für die Verarbeitung der Eingabe, bevor das erste Ausgabe-Token kam. Das ist kein hängender Server. Das ist das Modell, das die Lesephase abschließt.

Grobe Schätzung für einen Agenten-LLM-Hop auf diesem Setup.

• ~14,5k Prefill bei ~480 tok/s ≈ 8 s, bevor etwas zurückkommt
• ~200 Token Antwort bei ~40 tok/s ≈ 5 s Generierung
• Ein Hop ≈ mindestens 13 s, vor Tool-Ausführung oder einem zweiten Hop

Eine Agenten-Schleife mit drei Iterationen mit Tool-Aufrufen kann leicht über vierzig Sekunden reine Modellzeit allein beanspruchen. Telegram fühlt sich lange kaputt an, bevor die Hardware tatsächlich kämpft.

Vergleichen Sie das mit einem dummen Chat-Prompt. "Sag Hallo in einem Satz" auf der Standard-Vier-Slot-llama-server-Konfiguration maß etwa 48 tok/s Prefill und 52 tok/s Generierung auf derselben Maschine. Nach dem Wechsel zu --parallel 1 und den Batch/Cache-Flags sprang derselbe kurze Curl-Test auf etwa 127 tok/s Prefill, während die Generierung immer noch bei etwa 57 tok/s lag. Server-Tuning hat die Nadel bei Prefill für kleine Prompts und Speicher-Overhead hauptsächlich verschoben. Es hat die Acht-Sekunden-Steuer für einen 14k-Agenten-Kontext nicht beseitigt.

Standard-llama-server-Einstellungen machten den Agentenfall schlimmer, und der Regler, der mich überraschte, war --parallel.

llama-server führt intern nicht nur eine Konversation gleichzeitig. Er hat separate Slots. Jeder Slot ist ein vollständiges Kontextfenster mit seinem eigenen KV-Cache im Speicher. Wenn eine Anfrage eintrifft, wählt der Server einen Slot aus, lädt Ihren Prompt hinein und generiert von dort. Eine zweite Anfrage kann gleichzeitig einen anderen Slot verwenden, ohne die erste Konversation zu überschreiben.

--parallel legt fest, wie viele Slots vorhanden sind. Wenn Sie es weglassen, wählen neuere llama.cpp-Builds auto, was auf meinem Mac vier Slots bedeutete. Beim Start wurde n_parallel is set to auto, using n_parallel = 4 und initializing slots, n_slots = 4 protokolliert.

Vier Slots sind sinnvoll, wenn eine GPU mehrere Clients bedient. Eine Browser-UI, ein Curl-Test, vielleicht ein zweiter Benutzer. Der Server kann gleichzeitige Chats jonglieren.

Innerhalb eines Chats ist AIdaemon meist seriell. Telegram, Slack und Discord reihen Nachrichten pro Sitzung, sodass Sie nicht zwei Agenten-Schleifen haben, die um denselben Thread kämpfen. Aber das ist nicht das ganze Bild. Ein geplantes Cron-Ziel kann einen Hintergrund-Task-Lead starten, während Sie auf Telegram chatten. Ein zweites Ziel kann dasselbe tun. Slack und Telegram sind unterschiedliche Sitzungen, sodass beide das Modell gleichzeitig erreichen können, wenn Sie auf beiden aktiv sind.

Für mein Setup war diese Überschneidung selten. Ein Telegram-Chat, eine Handvoll geplanter Prüfungen, normalerweise nicht zur selben Sekunde. Standard --parallel 4 bedeutete immer noch, dass drei Slots die meiste Zeit ungenutzt blieben, während KV-Cache und Prompt-Cache-RAM reserviert wurden. Ich sah, wie der Prompt-Cache während der Tests auf über drei Gigabyte anwuchs. Als ich auf --parallel 1 reduzierte, brachen gleichzeitige Anfragen von AIdaemon nicht zusammen. llama-server reiht sie auf und führt sie nacheinander aus. Sie warten auf Ihre Runde, anstatt den GPU-Speicher über leere Bahnen zu teilen.

Wenn Sie regelmäßig mehrere geplante Ziele gleichzeitig ausführen oder in Telegram leben, während Cron jede Minute feuert, versuchen Sie --parallel 2 oder 3 anstelle von 1. Sie tauschen etwas Einzelanfragen-Geschwindigkeit gegen die Nicht-Serialisierung jeder überlappenden Runde. Passen Sie die Slot-Anzahl an, wie viele LLM-Aufrufe Sie tatsächlich überlappen, nicht die Standardeinstellung von vier.

Das Setzen von --parallel 1 reduzierte es auf einen Slot. Protokolle zeigten n_slots = 1. Das gesamte KV-Cache-Budget ging an die eine Agentenrunde, die ich tatsächlich ausführte.

llama-server Flags, die tatsächlich geholfen haben

Ich habe llama-server mit einem Single-Slot-, Single-User-Profil neu gestartet.

llama-server \
  -m ~/models/llm/gemma-4-26b/gemma-4-26B-A4B-it-UD-Q4_K_M.gguf \
  --jinja \
  --reasoning off \
  -c 16384 \
  -ngl 99 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --cache-ram 1024 \
  -b 4096 \
  -ub 1024 \
  --prio 2 \
  --alias gemma-4-26b \
  --host 127.0.0.1 \
  --port 8081

--parallel 1 war der größte Gewinn auf der Inferenzseite für mein Setup. Nicht, weil das Modell schlauer wurde. Weil ich aufhörte, für drei leere Gesprächsspuren zu bezahlen, die ich nie benutzte. Das hielt an, bis ich begann, den Cache zwischen den Runden wiederzuverwenden, und die Hintergrundjobs zum Problem wurden. Mehr dazu unten.

--flash-attn on und q8_0 KV-Cache-Typen halfen bei Apple Silicon. Das Begrenzen von --cache-ram verhinderte, dass der Prompt-Cache bei langen Sitzungen anschwoll. Größere Batch-Größen (-b 4096, -ub 1024) beschleunigten das Prefill bei fetten Prompts. --prio 2 schob den Prozess im Scheduler nach oben. Eine Kleinigkeit, aber wenn man an der Konfiguration feilt, hilft es.

Bei kurzen Prompts stieg das Prefill von etwa 48 tok/s auf 127 tok/s. Die Generierung blieb bei etwa 57 tok/s. Das bestätigte, dass sich das Server-Tuning gelohnt hatte. Es bestätigte auch etwas anderes. Bei ~14k Tokens wartet man immer noch auf über acht Sekunden Prefill, egal was passiert. Der nächste Hebel musste die Prompt-Größe sein.

Verkleinern, was AIdaemon sendet

Allein das Server-Tuning beseitigt kein achtsekündiges Prefill, wenn man bei jedem Hop nahe an 15k Tokens ist. Die andere Hälfte war, AIdaemon beizubringen, ein 16k-Fenster zu respektieren, wenn das Modell lokal ist, und das, was es sendet, vor dem Aufruf zu komprimieren, anstatt zu hoffen, dass der Server es überlebt.

Ich habe ein Budget pro Modell in config.toml hinzugefügt.

[state.context_window.model_budgets]
gemma-4-26b = 16384

Diese Zahl sollte mit -c auf llama-server übereinstimmen. Wenn AIdaemon glaubt, es habe 128k Tokens, der Server aber nur 16k speichert, zahlen Sie für Arbeit, die abgeschnitten wird oder seltsam fehlschlägt.

Im Code durchläuft die Nachrichtenaufbauphase fit_tool_definitions_to_budget() vor jedem LLM-Aufruf. Sie verwirft niemals Tools. Sie kürzt Metadaten in Stufen. Beschreibungen werden kürzer, Schema-Annotationen und Beispiele werden entfernt, bis die serialisierten Tools in das verbleibende Budget passen, nachdem der System-Prompt und der Verlauf gezählt wurden. Es gibt einen zweiten Durchlauf, nachdem der vollständige Prompt zusammengestellt wurde, da diese Einfügungen den Spielraum verbrauchen können, den Sie noch hatten.

Der Agent stellt immer noch jedes Tool bereit. Er versendet einfach keine Aufsatz-langen Schema-Texte, die das lokale Modell nicht benötigt, um terminal gegenüber read_file auszuwählen. Bei einem 48k- oder 128k-Cloud-Modell bemerken Sie das vielleicht nie. Bei 16k lokal ist es der Unterschied zwischen einem nutzbaren Hop und acht Sekunden Stille.

Ich habe auch reasoning_effort beim lokalen Provider reduziert. Das ist für Cloud-Denkmodelle. Gemmas Denkpfad ist anders und wir haben ihn bereits in llama-server deaktiviert.

Das macht lokales Gemma nutzbar. Es bedeutet nicht, dass 14k Tokens das Ziel sind. Ich schaue immer noch, wo der Prompt weiter schrumpfen kann. Doppelte Tool-Dokumentation bei der ersten Iteration, ein schlankerer System-Prompt, wenn das Modellbudget klein ist, intelligentere Tool-Filterung, damit lokale Läufe keinen Cloud-großen Katalog mitführen. Komprimierung war die Lösung, die mich blockiert hat; die nächste Runde dreht sich darum, jedes Kontextstück einmal zu senden.

Die eigentliche Lösung war die Wiederverwendung des Prompts, nicht nur seine Verkleinerung

Das Verkleinern des Prompts hat geholfen, aber ich habe immer noch bei jeder einzelnen Runde einen Prefill bezahlt. Dann wurde es mir klar. Das Modell sollte nicht zweimal dieselben 15.000 Tokens erneut lesen müssen. Fast alles von einem Agenten-Prompt ist von einer Runde zur nächsten identisch. Der System-Prompt, die Tool-Schemas, die älteren Nachrichten. Nur die neue Benutzernachricht und das neueste Tool-Ergebnis ändern sich, und sie stehen am Ende.

llama.cpp weiß bereits, wie es das ausnutzen kann. Es behält den KV-Cache aus der vorherigen Runde. Wenn der Anfang Ihres nächsten Prompts Byte für Byte identisch mit dem letzten ist, verwendet es diese zwischengespeicherte Arbeit wieder und springt direkt zu den neuen Tokens. Das ist ein warmer Start, und er ist schnell. Wenn sich etwas am Anfang unterscheidet, selbst ein einzelnes Token, kann es dem Rest nicht vertrauen, also verwirft es den Cache und liest alles noch einmal. Das ist ein kalter Start, und das ist der langsame Pfad, den ich bei jeder Runde getroffen habe.

Das Problem war, dass AIdaemon den Anfang des Prompts ohne Absicht änderte. Ein Zeitstempel, der sich änderte, ein Speicherblock, der neu geordnet wurde, eine alte Runde, die etwas anders zusammengefasst wurde. Winzige Bearbeitungen, aber sie landeten am Anfang, sodass der Cache nie übereinstimmte und jede Runde kalt startete. Die Lösung war, den Anfang langweilig zu machen. Ein stabiler Systemblock und alte Runden, die in eine feste Form eingefroren wurden, sobald sie aus dem Live-Fenster scrollten, nie wieder neu geschrieben. Danach waren die ersten 15.000 Tokens jedes Prompts identisch mit der vorherigen Runde, und llama.cpp konnte sie endlich wiederverwenden.

Das änderte auch meine Meinung zu --parallel. Ein einzelner Slot war am schnellsten für eine isolierte Anfrage, aber AIdaemon führt Speicher- und Zusammenfassungsarbeiten im Hintergrund auf demselben Server durch, und jeder dieser Jobs landete in meinem Chat-Slot und überschrieb den Cache, den ich warm halten wollte. Also wechselte ich zu --parallel 2, fixierte meine Konversation auf einen Slot und schickte die Hintergrundjobs zum anderen. Jetzt wird die Hausarbeit in ihrer eigenen Spur erledigt und mein Chat bleibt warm.

Das Flag, das niemand erwähnt

Stabiler Prompt, mein eigener Slot, und jede neue Runde war immer noch kalt. Ich gab fast auf. Dann las ich das llama-server-Protokoll noch einmal.

forcing full prompt re-processing due to lack of cache data
(likely due to SWA or hybrid/recurrent memory)

SWA steht für Sliding-Window-Attention. In den meisten seiner Schichten schaut Gemma 4 nur auf ein Fenster von aktuellen Tokens statt auf die gesamte Historie. Das ist ein Teil dessen, was ein 26B-Modell so günstig im Betrieb macht. Der Haken ist, dass llama.cpp standardmäßig nur dieses kleine Fenster speichert, sodass in dem Moment, in dem eine neue Runde die Token-Positionen verschiebt, nichts mehr zum Wiederverwenden übrig ist und es von vorne beginnt. All meine sorgfältige Prompt-Stabilitätsarbeit konnte einem Aufmerksamkeitsmechanismus nicht standhalten, der den Großteil seines eigenen Caches wegwirft.

Ein Flag hat es behoben.

llama-server \
  -m ~/models/llm/gemma-4-26b/gemma-4-26B-A4B-it-UD-Q4_K_M.gguf \
  --jinja --reasoning off \
  -c 131072 \
  -ngl 99 \
  --parallel 2 \
  --swa-full \
  --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  --cache-ram 12288 \
  -b 4096 -ub 1024 \
  --alias gemma-4-26b --host 127.0.0.1 --port 8081

--swa-full weist llama.cpp an, einen Cache in voller Größe für die Fenster-Schichten zu behalten, anstatt nur einen Ausschnitt. Das kostet mehr Speicher, ziemlich viel mehr bei einem Modell, das hauptsächlich aus Fenster-Schichten besteht, aber ich habe 48 GB und eine Konversation, die endlich warm bleibt. Bei Gemma ist dieses eine Flag der gesamte Unterschied zwischen der Wiederverwendung des Caches über Runden hinweg und dem erneuten Lesen des Prompts jedes Mal. Ohne es bringen Prompt-Stabilität und Slot-Pinning fast nichts.

Die Zahlen bewegten sich wie gewünscht. Eine Folgeantwort, die früher etwa 15.000 Tokens neu lesen und etwa dreißig Sekunden lang stocken würde, liest jetzt etwa 1.300 neu und antwortet in ein paar Sekunden. Dasselbe Modell, dieselbe Hardware, dieselbe Antwort, etwa neunzig Prozent weniger Arbeit pro Runde.

Ich habe das nur gefunden, weil AIdaemon es mir gesagt hat

Nichts davon war durch Gefühl zu finden. "Es scheint langsam" ist kein Bug-Report. Was es handhabbar machte, ist, dass AIdaemon die Anatomie jedes Modellaufrufs protokolliert. Die Prompt-Größe, wie viele Eingabe-Tokens aus dem Cache bedient wurden versus frisch gelesen, ein Fingerabdruck jedes Teils des Prompts und welcher Hintergrundjob wann lief.

Die Zahl zwischen gecacht und frisch war der Hinweis. Bei einer Runde, die warm hätte sein sollen, bedeutete das Beobachten, wie die frische Anzahl auf fünfzehntausend sprang, dass der Cache kaputt war, und die Fingerabdrücke pro Abschnitt zeigten genau, welcher Teil des Prompts ihn kaputt gemacht hatte. So habe ich zuerst den Prompt-Churn erfasst, dann die Hintergrundjobs, die den Slot stahlen, dann SWA. Drei verschiedene Schuldige, die sich hinter demselben Symptom einer langsamen Antwort versteckten. Ohne diese Telemetrie hätte ich zufällig Flags getauscht.

Wenn Sie eine Sache mitnehmen, machen Sie Ihren lokalen Agenten beobachtbar. Das Modell ist eine Blackbox und der Server ist größtenteils eine Blackbox. Ihr eigener Daemon ist der einzige Ort, den Sie kontrollieren, also lassen Sie ihn Ihnen erzählen, was er gesendet hat und was bei jedem Aufruf wiederverwendet wurde.

Was ich jemandem erzählen würde, der das versucht

Beginnen Sie mit dem Modell, das Sie bereits haben. Ich habe Gemma 4 26B MoE verwendet, weil das GGUF bereits heruntergeladen war. Die 12B Unified-Variante steht als nächstes auf meiner Liste. Kleinerer Kontext, weniger RAM, wahrscheinlich schneller für Chat-lastige Nutzung.

Passen Sie drei Zahlen an. llama-server -c, AIdaemon model_budgets und was Sie tatsächlich in einer geschäftigen Agentenrunde erwarten. Sie sollten übereinstimmen.

Beobachten Sie die Protokolle. tail -f ~/.aidaemon/llama-server.log zeigt Prompt-Token-Anzahlen und Slot-Verhalten. Wenn Sie bei jeder Runde Prefills mit mehreren tausend Tokens sehen, beheben Sie den Agentenkontext, bevor Sie schnellere Hardware kaufen.

Behalten Sie ein Cloud-Fallback, während Sie abstimmen. Lokal-zuerst mit OpenRouter (oder was auch immer Sie bereits bezahlen) als Backup bedeutet, dass Sie llama-server zwanzigmal neu starten können, ohne Telegram zu verlieren.

Führen Sie llama-server vor AIdaemon aus. Der Daemon startet ohne ihn gut und fällt dann beim ersten Nachrichtenversand zurück oder gibt einen Fehler aus. Das habe ich einmal vergessen.

Unter macOS führe ich AIdaemon unter launchd mit caffeinate -i aus, damit der Leerlauf-Schlaf eine lange Agentensitzung nicht beendet. llama-server läuft immer noch manuell, es sei denn, Sie geben ihm seine eigene plist. Lohnt sich, wenn dies Ihr täglicher Treiber wird.