Allgemein

TriForce Update: Fallback-Kette bereinigt, lokale Ollama-Modelle entfernt

Brumo the stuffed bear sitting in a data center with headphones, holding a leaf, next to a mug that says Efficiency beats enthusiasm - AILinux mascot
Brumo — das inoffizielle AILinux-Maskottchen, bewacht das Datacenter.

Kurzes technisches Update aus dem heutigen Bug-Hunt.

Die Fallback-Kette in TriForce wurde weiter bereinigt und an die reale Verfügbarkeit angepasst. Wichtigster Punkt: lokale Ollama-Modelle sind nicht mehr Teil der automatischen Nova-Fallback-Kette. Auf dem aktuellen System ist das sinnvoller, weil die CPU nicht als verlässliche Fallback-Basis für lokale Modelle taugt.

Stattdessen gilt jetzt:

  • Ollama-Cloud zuerst
  • OpenRouter-Free nur als letzter Notnagel

Zusätzlich wurde die Reihenfolge innerhalb der Ollama-Cloud-Fallbacks sinnvoll priorisiert. Breite Allrounder kommen zuerst, spezialisiertere Modelle später.

Aktive Cloud-Reihenfolge:

  1. ollama/gpt-oss:120b-cloud
  2. ollama/deepseek-v3.2:cloud
  3. ollama/kimi-k2-thinking:cloud
  4. ollama/glm-5:cloud
  5. ollama/qwen3-coder:480b-cloud

Erst danach folgt als letzter Fallback:

  • openrouter/openai/gpt-oss-120b:free
  • openrouter/mistralai/mistral-small-3.1-24b-instruct:free
  • openrouter/stepfun/step-3.5-flash:free

Nebenbei wurde auch die Content-Schiene stabilisiert: automatische Content-Jobs hängen nicht mehr hart an gemini-mcp, damit API-Limits dort nicht direkt die WordPress- oder Forum-Posts blockieren.

Das Ziel bleibt gleich: weniger fragile Sonderfälle, mehr belastbare Fallbacks, sauberere Prioritäten und eine stabilere Produktionsbasis für TriForce und AILinux.

Weitere technische Updates folgen im Forum und hier auf der Seite.

KI-Assistent
Kontext geladen: TriForce Update: Fallback-Kette bereinigt, lokale Ollama-Mod