MiniMax
MiniMax-01 · M1 · M2/M2.1/M2.5/M2.7 · M3 · MiniMax Code · Mavis · Hailuo · H3 · Speech 2.8 · Music 3.0 · Image-01 · Talkie · API · MCP · Open Weights
Stand: September 2026
MiniMax ist 2026 kein einzelner Chatbot, sondern einer der ungewöhnlich breit aufgestellten AI-Stacks. Die Entwicklung führt von langen Kontexten und Lightning Attention über M1/M2-Agentenmodelle zu M3 mit MiniMax Sparse Attention, einer Million Kontexttokens und nativer Multimodalität – parallel zu eigenständigen Video-, Speech-, Music- und Image-Modellen.
Der aktuelle Kern besteht aus MiniMax M3 für Coding und Agenten, MiniMax H3 für omni-modale audiovisuelle Generierung, Speech 2.8, Music 3.0 und Produkten wie MiniMax Code, Hailuo, Audio und Talkie. Historische Pfade wie M2.7, Hailuo 2.3 und Image-01 bleiben technisch relevant.
Besonders wichtig ist die Lizenzschicht: Open Weights ≠ automatisch Open Source. M3, H3 und Music 3.0 verwenden unterschiedliche MiniMax-Community-Lizenzen. Die H3-Lizenz schließt die EU einschließlich Deutschland aus der pauschalen öffentlichen Lizenzgewährung ausdrücklich aus.
System Diagnostic
- MiniMax M3
- MSA
- 1M Context
- M2.7
- M1
- MiniMax-01
- MiniMax Code
- Mavis
- H3
- Hailuo 2.3
- Speech 2.8
- Music 3.0
- Image-01
- Talkie
- MCP
- Open Weights
Schnellzugriff
MiniMax-Zeitlinie
- Anfang 2022operativer Aufbau von MiniMax als Foundation-Model-Unternehmen.
- 24.10.2024Realtime API für Text-/Voice-Echtzeitdialog.
- 15.01.2025MiniMax-01: Text-01 und VL-01, Lightning Attention, Open Weights.
- 28.02.2025Image-01.
- 16.06.2025MiniMax-M1, Hybrid Attention, 1M Kontext.
- 18.06.2025Hailuo 02.
- 27.10.2025MiniMax M2 und Agent.
- 28.10.2025Hailuo 2.3 und Media Agent.
- 31.10.2025Music 2.0.
- 23.12.2025M2.1.
- 23.01.2026Speech 2.8.
- 12.02.2026M2.5.
- 14.02.2026Forge Agent-RL-Framework.
- 18.03.2026M2.7.
- 27.05.2026Mavis / Agent Teams.
- 01.06.2026M3: MSA, 1M Kontext, native Multimodalität.
- 09.06.2026MaxProof.
- 31.07.2026H3 vorgestellt.
- 03.08.2026H3-Gewichte veröffentlicht.
- 13.08.2026Music 3.0.
- 20.08.2026Music-Modelle nicht mehr im Token Plan.
- 01.09.2026M3/H3/Speech 2.8/Music 3.0 als aktueller Kernstand.
1. MiniMax ist Modelllabor, Multimodalitätsanbieter, Agentenplattform und Produktunternehmen
MiniMax entwickelt Foundation-Modelle und Generationsmodelle für Text, Bildverständnis, Video, Sprache und Musik sowie Produkte für Coding, Agenten, Audio, Video und soziale Interaktion.
Die Marke allein bezeichnet deshalb weder ein einzelnes Modell noch eine einzelne API. M3, H3, Speech, Music, MiniMax Code, Hailuo, Talkie und die Open Platform sind getrennte Schichten.
2. Anfang 2022: MiniMax nimmt den operativen Aufbau auf
MiniMax beschreibt sich selbst als Anfang 2022 gegründetes globales AI-Foundation-Model-Unternehmen. Die börsenrechtliche Konzernhülle MiniMax Group Inc. wurde bereits 2021 auf den Cayman Islands eingetragen.
Für die Technikchronik ist diese Unterscheidung wichtig: gesellschaftsrechtliche Eintragung und operativer Beginn des AI-Unternehmens sind nicht dasselbe Datum.
3. Yan Junjie als Gründer, Chairman, CEO und CTO
Yan Junjie führt MiniMax als Gründer, Chairman, CEO und CTO. Seine vorherige Arbeit umfasste Forschung und Führungsaufgaben bei SenseTime.
Die technische Entwicklung von MiniMax ist stark forschungsgetrieben; Unternehmensführung und Modellarchitektur bleiben dennoch unterschiedliche Ebenen.
4. „Intelligence with Everyone“ als Mission
MiniMax verwendet 2026 die Mission „Intelligence with Everyone“ und positioniert die eigene Entwicklung in Richtung allgemein nutzbarer, multimodaler und agentischer Systeme.
Eine Unternehmensmission ist kein Leistungsbeweis. Für das Archiv werden konkrete Modelle, APIs, Lizenzen und Produktfunktionen separat geprüft.
5. Produktkarte 2026
Zum aktuellen globalen Portfolio gehören MiniMax M3, M2.7 und M2.5, MiniMax H3, Speech 2.8 und Music 3.0 sowie MiniMax Code, MiniMax Design, Audio, Talkie und die Entwicklerplattform.
Hailuo bleibt als Video-Produktoberfläche und Hailuo 2.3 als API-Modellpfad relevant, obwohl H3 die aktuelle allgemeine Video-/Omni-Generation erweitert.
6. Kernregel: M3 ≠ H3 ≠ Speech ≠ Music ≠ Code ≠ Hailuo ≠ Talkie ≠ API
Die MiniMax-Familie ist besonders anfällig für Namensvermischung, weil Foundation-Modelle, Medienmodelle, Assistentenprodukte und Abonnements unter derselben Marke zusammenlaufen.
Jede technische Aussage muss daher angeben, ob sie ein Gewichtemodell, einen gehosteten Endpunkt, eine Produktoberfläche, ein Agent-Harness oder einen Tarif betrifft.
7. Global- und China-Pfade unterscheiden
MiniMax betreibt globale und chinesische Plattformpfade. Offizielle CLI-Dokumentation unterscheidet beispielsweise die Regionen global und cn und erlaubt eine explizite Regionswahl.
Region, Vertragspartner, Endpunkt und verfügbare Funktionen sollten bei Reproduzierbarkeit und Datenschutz immer mitprotokolliert werden.
8. Nanonoble Pte. Ltd. als globaler API-Vertragspartner
Die globale API-Datenschutzerklärung nennt Nanonoble Pte. Ltd. und verbundene Unternehmen als Anbieter der globalen Plattformdienste.
Diese juristische Ebene darf nicht mit dem technischen Speicherort einzelner Requests oder mit lokalen Open-Weight-Deployments gleichgesetzt werden.
9. 2026: börsennotierter Konzern
MiniMax Group Inc. ist 2026 in Hongkong börsennotiert und veröffentlicht Unternehmens- und Finanzinformationen über eine Investor-Relations-Struktur.
Finanz- und Nutzerzahlen erklären Größenordnung und Marktreichweite, sind aber keine Qualitätsmetriken für einzelne Modelle.
10. Aktueller Text-/Agenten-Endpunkt: MiniMax M3
MiniMax M3 wurde am 1. Juni 2026 veröffentlicht und ist der aktuelle Frontier-Pfad für Coding, Agentenarbeit, lange Kontexte und native multimodale Eingaben.
M3 unterstützt bis zu eine Million Kontexttokens und verarbeitet neben Text auch Bild- und Videoeingaben; die API erlaubt unterschiedliche Thinking-Modi.
11. M3: rund 428B Gesamt- und 23B aktive Parameter
Die veröffentlichten M3-Modellinformationen nennen ungefähr 428 Milliarden Gesamtparameter und ungefähr 23 Milliarden aktivierte Parameter.
Bei MoE-Systemen sind Gesamtparameter, aktive Rechenparameter und tatsächlicher Speicherbedarf drei verschiedene Größen.
12. M3 verwendet die MiniMax Community License
Die M3-Gewichte stehen nicht unter Apache 2.0 oder Standard-MIT, sondern unter einer eigenen MiniMax Community License mit besonderen Bedingungen für kommerzielle Nutzung und Kennzeichnung.
Open Weight darf daher nicht pauschal als vollständig offene FLOSS-Lizenz beschrieben werden.
13. MiniMax H3 als aktueller allgemeiner Video-/Omni-Generator
H3 wurde Ende Juli 2026 vorgestellt und Anfang August als Gewichte veröffentlicht. Es versteht Text, Bild, Video und Audio gemeinsam und erzeugt Video mit nativem Stereo-Audio.
Die veröffentlichten Spezifikationen reichen bis 2K Auflösung und bis zu 15 Sekunden Ausgabedauer.
14. H3-Lizenz: territoriale Sonderregel ist zentral
Die MiniMax-H3-Community-Lizenz definiert ein „Applicable Territory“ und schließt die Europäische Union, das Vereinigte Königreich, Südkorea und die USA von der pauschalen Lizenzgewährung aus.
Für Betreiber in Deutschland bedeutet das: Die öffentlich bereitgestellten Gewichte sind nicht einfach aufgrund des Downloads frei nutzbar; die konkrete Lizenz-/Autorisierungslage muss vor Einsatz geprüft werden.
15. Music 3.0 als aktueller Musikpfad
MiniMax Music 3.0 erschien am 13. August 2026 als Open-Weight-Musikmodell für komplette Songs bis zu etwa fünf Minuten.
Die Architektur kombiniert einen globalen und lokalen Sprachmodellpfad mit RVQ-, Flow-Matching- und VAE-Komponenten; die Gewichte stehen unter einer eigenen MiniMax-Music3-Community-Lizenz.
16. Speech 2.8 als aktueller Sprachpfad
Speech 2.8 erschien am 23. Januar 2026 und erweitert TTS um native Sound Tags, hochwertige Stimmen und Voice-Cloning-Funktionen.
Die API-Dokumentation führt Speech-2.8-HD und Speech-2.8-Turbo und nennt Unterstützung für 40 Sprachen sowie verschiedene Emotionen und Dialekte.
17. Image-01 als weiterhin dokumentierter Bildgenerationspfad
Image-01 wurde am 28. Februar 2025 als erstes Text-zu-Bild-Modell von MiniMax veröffentlicht und ist weiterhin in der API-/Token-Plan-Landschaft dokumentiert.
M3s Bildverständnis ist davon zu trennen: multimodaler Input in einem LLM ist nicht dasselbe wie ein dediziertes Bildgenerationsmodell.
18. MiniMax Agent → Mavis → MiniMax Code
Der M2-Start 2025 war eng mit MiniMax Agent verbunden. Im Mai 2026 wurde die Agentenoberfläche als Mavis ausgebaut; mit M3 steht MiniMax Code als allgemeine Coding- und Agentenplattform im Vordergrund.
Historische Produktnamen bleiben für Archivscreenshots korrekt, dürfen aber nicht automatisch als aktueller Produktname verwendet werden.
19. Coding Plan → Token Plan
Der frühere Coding Plan wurde zu einem breiteren Token Plan weiterentwickelt, der Textmodelle und je nach Tarif weitere Modalitäten unter einer gemeinsamen Abonnementlogik bündelt.
Ein Token-Plan-Key ist von einem normalen Pay-as-you-go-API-Key zu unterscheiden; Quoten, Tarife und Produktionsfreigaben können abweichen.
20. Anthropic- und OpenAI-kompatible API-Pfade
MiniMax dokumentiert sowohl einen Anthropic-kompatiblen als auch einen OpenAI-kompatiblen Integrationspfad für Textmodelle.
Kompatibilität bedeutet API-Formähnlichkeit, nicht vollständige Verhaltensgleichheit mit den jeweiligen Originalanbietern.
21. Offizielle MCP-Server
MiniMax stellt offizielle Model-Context-Protocol-Implementierungen bereit, die unter anderem Speech, Voice Cloning, Video und Musik in Agentenworkflows integrieren können.
MCP erweitert die Wirkung eines Modells und damit auch Angriffsfläche, Berechtigungsbedarf und Reproduzierbarkeitsanforderungen.
22. Offizielle MiniMax CLI
Die offizielle CLI kann Text, Bild, Video, Sprache und Musik ansprechen, API-Key- oder OAuth-Anmeldung verwenden und zwischen globalen und chinesischen Regionen unterscheiden.
CLI-Version, Region, Defaultmodell und Konfiguration gehören deshalb in technische Reproduktionsprotokolle.
23. 2022: operativer Start des Foundation-Model-Unternehmens
MiniMax beginnt mit dem Aufbau eigener Foundation-Modelle und AI-nativer Produkte.
Der spätere Produktmix aus Companion-Apps, Entwicklerplattform und Medienmodellen entsteht schrittweise und sollte nicht rückwirkend als fertiger Stack dargestellt werden.
24. Talkie und Xingye als frühe interaktive Produktlinie
MiniMax entwickelte früh interaktive Charakter- und Companion-Produkte; M2-her wird später ausdrücklich als Modellbasis für Xingye und Talkie beschrieben.
Roleplay-Optimierung, allgemeine Chatfähigkeit und Agentenproduktivität sind unterschiedliche Trainingsziele.
25. 24. Oktober 2024: Realtime API
MiniMax veröffentlichte eine Realtime API mit HTTP- und WebSocket-Pfaden für text- und sprachbasierte Echtzeitinteraktion.
Realtime umfasst Transport, Latenz, Audioverarbeitung und Modellausgabe; es ist keine einzelne Foundation-Modellbezeichnung.
26. August 2024: frühe Video-Demo als Ausgangspunkt der Hailuo-Linie
MiniMax beschreibt den Ursprung der späteren Hailuo-Videolinie als informellen Demo-Start Ende August 2024.
Die Videoproduktgeschichte wird deshalb getrennt von der Textmodellserie M1/M2/M3 archiviert.
27. 15. Januar 2025: MiniMax-01 wird offen veröffentlicht
Die MiniMax-01-Serie umfasst MiniMax-Text-01 und MiniMax-VL-01 und bringt Lightning Attention in großem Maßstab in die Modellfamilie.
MiniMax-Text-01 besitzt 456B Gesamt- und 45,9B aktive Parameter; MiniMax veröffentlichte sehr lange Kontextangaben bis vier Millionen Tokens.
28. Lightning Attention in MiniMax-Text-01
Lightning Attention dient als linearer beziehungsweise effizienter Attention-Pfad, der bei langen Sequenzen Rechenaufwand reduzieren soll.
Die Architekturgeschichte ist wichtig, weil M1 später Hybrid Attention nutzt und M3 mit MiniMax Sparse Attention einen neuen Weg einschlägt.
29. MiniMax-VL-01
VL-01 ergänzt die 01-Serie um visuelles Verständnis.
Vision-Verstehen ist von späterer Bild- oder Videogenerierung zu unterscheiden.
30. 28. Februar 2025: Image-01
Image-01 ist MiniMax’ erstes öffentlich angekündigtes Text-zu-Bild-Modell.
Prompttreue und Komposition wurden als Kernziele beschrieben; die heutige Bildgeneration bleibt als eigener API-Pfad neben M3 bestehen.
31. 16. Juni 2025: MiniMax-M1
M1 wird als großskaliges Open-Weight-Reasoningmodell mit Hybrid Attention veröffentlicht.
Es kombiniert Lightning Attention mit klassischer Softmax Attention und legt besonderen Wert auf lange Kontexte und lange Reasoning-Ausgaben.
32. M1: 456B Gesamt / 45,9B aktiv
M1 ist ein MoE-Modell mit 32 Experten und 456 Milliarden Gesamtparametern; pro Token werden etwa 45,9 Milliarden Parameter aktiviert.
Diese aktive Größe darf nicht als vollständiger Speicherbedarf interpretiert werden.
33. M1: 1M Kontext und bis 80K Reasoning-Ausgabe
MiniMax nannte für M1 eine Million Token Kontext und bis zu 80.000 Token Reasoning-Ausgabe.
Kontextfenster und maximal nutzbare Ausgabe sind verschiedene Limits und zusätzlich runtimeabhängig.
34. 18. Juni 2025: Hailuo 02
Hailuo 02 wird als neue Videogeneration mit nativer 1080p-Ausgabe, stärkerer Instruktionsbefolgung und physikbezogener Bewegungsdarstellung vorgestellt.
Die API unterstützt später Text-zu-Video und Bild-zu-Video sowie 6- und 10-Sekunden-Pfade.
35. 28. August 2025: Start-/End-Frame-Funktion
Hailuo 02 erhält Start-und-End-Frame- sowie End-Frame-Only-Steuerung.
Solche Steuerfunktionen gehören zur Video-Pipeline und nicht zur Textmodell-Tool-Calling-API.
36. 27. Oktober 2025: MiniMax M2
M2 startet als offen veröffentlichtes Modell für Agenten und Code.
Der Release betont Programmierung, Tool Use, Deep Search und End-to-End-Agentenworkflows und koppelt Modell und MiniMax Agent eng miteinander.
37. M2 und MiniMax Agent
MiniMax Agent bot zum M2-Start einen schnellen Lightning Mode und einen umfangreicheren Pro Mode.
Das Produkt ist ein Harness über dem Modell; identisches M2 kann in anderen Agentenframeworks anders arbeiten.
38. Interleaved Thinking als M2-Betriebsmerkmal
MiniMax weist für M2 ausdrücklich darauf hin, dass reasoning- und toolbasierte Zwischenschritte korrekt ineinandergreifen müssen.
Ein API-Wrapper, der Thinking-Zustand zwischen Toolaufrufen verwirft, kann die Agentenleistung deutlich verschlechtern.
39. 28. Oktober 2025: Hailuo 2.3
Hailuo 2.3 verbessert Bewegungsdarstellung, Gesichtsmimik, Stilkontrolle und Instruktionsbefolgung und erscheint zusätzlich als Fast-Variante.
Hailuo 2.3 bleibt 2026 als API-Modell dokumentiert, obwohl H3 die nächste allgemeine Videoarchitektur darstellt.
40. Hailuo Video Agent → Media Agent
Mit Hailuo 2.3 entwickelte MiniMax den Video Agent zum Media Agent weiter, der mehrere Medienmodelle orchestriert.
Media Agent ist Produktorchestrierung, kein einzelner Generationscheckpoint.
41. 31. Oktober 2025: Music 2.0
Music 2.0 erweitert Text-zu-Musik um stärkere Gesangs- und Instrumentdarstellung.
Die Musikmodelllinie entwickelt sich 2026 über 2.5+ und 2.6 zu Music 3.0 weiter.
42. 23. Dezember 2025: MiniMax M2.1
M2.1 verbessert mehrsprachiges Coding, Anwendungsentwicklung und Generalisierung über unterschiedliche Agentenscaffolds.
Die später veröffentlichte technische Analyse nennt rund 230B Gesamt- und rund 10B aktive Parameter.
43. M2.1: Agentic Data Synthesis
MiniMax beschreibt für M2.1 reale SWE-Daten, Expert-in-the-Loop-Appentwicklung und synthetische Long-Horizon-Suchaufgaben als wichtige Trainingspfade.
Die Trainingsmethodik erklärt, warum Coding- und Search-Agenten nicht nur über isolierte Codebenchmarks bewertet werden sollten.
44. 23. Januar 2026: Speech 2.8
Speech 2.8 führt native Sound Tags, hochwertige Stimmklonung und verbesserte Natürlichkeit ein.
Speech-2.8-HD und Turbo sind separate Servingprofile mit ähnlicher Funktionsfamilie, aber unterschiedlichen Qualitäts-/Latenzzielen.
45. 27. Januar 2026: technische Einordnung von M2-her
MiniMax beschreibt M2-her als Textdialogmodell für lange, charakterkonsistente Roleplay-Interaktionen und als Basis für Talkie/Xingye.
Ein Companion-Modell ist nicht automatisch die beste Wahl für Coding, Recherche oder Enterprise-Agenten.
46. 12. Februar 2026: MiniMax M2.5
M2.5 fokussiert reale Produktivität, Coding, Tool Calling, Search und Office-Aufgaben.
MiniMax beschreibt eine starke RL-Skalierung über sehr viele reale und simulierte Agentenumgebungen.
47. 14. Februar 2026: Forge als Agent-RL-Framework
Forge entkoppelt Trainings-/Inferenzengine und Agentenebene und unterstützt unterschiedliche Agentenscaffolds.
Das Trainingsframework darf nicht mit einer Endnutzer-Forge-Produktoberfläche anderer Anbieter verwechselt werden.
48. 18. März 2026: MiniMax M2.7
M2.7 wird als Modell vorgestellt, das bereits an Teilen seiner eigenen Weiterentwicklung mitwirkt.
Schwerpunkte sind Software Engineering, professionelle Büroarbeit, Agent Teams, Skills, dynamische Toolsuche und iterative Harness-Verbesserung.
49. M2.7 und „Self-Evolution“
MiniMax beschreibt interne Workflows, in denen M2.7 Forschungs- und Agentenharnesses analysiert, verändert, evaluiert und iterativ verbessert.
Das ist ein kontrollierter agentischer Entwicklungsprozess und kein Beleg für autonome, unbegrenzte Selbstverbesserung.
50. 27. Mai 2026: MiniMax Agent wird zu Mavis ausgebaut
Mavis bündelt Agent Teams und parallele Agenten und positioniert sich als langlaufender persönlicher Arbeitsagent.
Parallel wurden Token- und Agent-Plan stärker zusammengeführt.
51. 1. Juni 2026: MiniMax M3
M3 löst die reine M2.x-Fortschreibung durch eine neue Frontier-Architektur mit MiniMax Sparse Attention und nativer Multimodalität ab.
Der Release verbindet Coding, Cowork/Agenten, eine Million Kontexttokens und Bild-/Videoeingaben in einem Open-Weight-Modell.
52. 9. Juni 2026: MaxProof
MaxProof kombiniert generatives Modell, Verifier, Refinement und test-time Evolutionary Search für mathematische Beweise.
MaxProof ist ein Systemrahmen um M3 und kein separater allgemeiner Foundation-Checkpoint.
53. M3 und MiniMax Code
Mit M3 wird MiniMax Code als Coding-/Cowork-Harness mit Computer Use, multimodalen Eingaben und langen Codekontexten hervorgehoben.
Das Harness baut auf Open-Source-Komponenten auf und ist von der M3-Gewichtelizenz zu trennen.
54. 31. Juli 2026: MiniMax H3
H3 wird als allgemeines omni-modales Generationssystem vorgestellt.
Es kann multimodale Kontexte aus Text, Bildern, Video und Audio verstehen und Video mit synchronisiertem Stereo-Audio erzeugen.
55. 3. August 2026: H3-Gewichte veröffentlicht
MiniMax veröffentlicht H3-Gewichte und Inferenzmaterialien.
Die Gewichte sind öffentlich zugänglich, aber die spezielle H3-Community-Lizenz enthält territoriale und kommerzielle Sonderbedingungen.
56. 13. August 2026: MiniMax Music 3.0
Music 3.0 erscheint als Open-Weight-Modell für vollständige Songs mit optionalen Lyrics.
Die Architektur trennt globale musikalische Struktur und lokale akustische Details und verwendet anschließend Flow-Matching und VAE-Rekonstruktion.
57. 20. August 2026: Musikmodelle aus Token Plan herausgelöst
Die Token-Plan-Seite kündigt an, dass Music-Modelle ab 20. August 2026 nicht mehr über den Token Plan verfügbar sind und stattdessen andere Zugangswege genutzt werden sollen.
Ein Modell kann also aktuell und offen verfügbar sein, obwohl ein bestimmtes Abonnement es nicht mehr umfasst.
58. 1. September 2026: aktueller MiniMax-Endstand
Am Stichtag stehen M3, M2.7/M2.5, H3, Speech 2.8 und Music 3.0 im aktuellen Modellportfolio; Image-01 und Hailuo 2.3 bleiben als spezialisierte API-/Produktpfade relevant.
Produkte und Endpunkte können schneller wechseln als die Modellgeschichte; deshalb ist ein expliziter Stichtag unverzichtbar.
59. M3 Technik: 428B Gesamtparameter
M3 ist ein großes Mixture-of-Experts-System mit ungefähr 428 Milliarden Gesamtparametern.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
60. M3 Technik: rund 23B aktive Parameter
Pro Token wird nur ein Teil der MoE-Kapazität aktiviert; veröffentlicht sind ungefähr 23 Milliarden aktive Parameter.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
61. M3 Technik: MiniMax Sparse Attention
MSA selektiert relevante KV-Blöcke, um Million-Token-Kontext effizienter zu verarbeiten als volle quadratische Attention.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
62. M3 Technik: Blockauswahl statt Vollattention
Sparse Attention reduziert die Zahl der tatsächlich berechneten Attention-Beziehungen, ohne das gesamte Kontextfenster zu verwerfen.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
63. M3 Technik: 1M Kontext
M3 unterstützt bis zu eine Million Kontexttokens für sehr lange Dokumente, Repositories und Agentenverläufe.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
64. M3 Technik: Long-Context-Billing
Die API unterscheidet Standardkontext bis 512K und einen teureren Bereich oberhalb 512K bis 1M.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
65. M3 Technik: Native Multimodalität
Text, Bilder und Video werden im M3-Training gemeinsam berücksichtigt; Multimodalität ist nicht nur ein nachträglicher externer Visionadapter.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
66. M3 Technik: Bildinput
M3 kann Bildinhalte analysieren und in Agenten- und Codingaufgaben einbeziehen.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
67. M3 Technik: Videoinput
M3 kann Video als Eingabemodalität verstehen, ohne dadurch selbst zum H3-Videogenerator zu werden.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
68. M3 Technik: Computer Use
M3 wird für Computerbedienung über einen Agentenharness eingesetzt, etwa für Anwendungs- und Dateiarbeit.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
69. M3 Technik: Coding
Der Release fokussiert Bugfixing, Frontend, Backend, Performanceoptimierung und Repositoryarbeit.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
70. M3 Technik: Cowork
Neben Coding zielt M3 auf längere Office-, Such- und Wissensarbeitsabläufe.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
71. M3 Technik: Thinking enabled
Im API-Modus `enabled` ist Reasoning dauerhaft aktiviert.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
72. M3 Technik: Thinking adaptive
Im Modus `adaptive` entscheidet das System situationsabhängig über zusätzlichen Reasoningaufwand.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
73. M3 Technik: Thinking disabled
Im Modus `disabled` wird Reasoning reduziert beziehungsweise abgeschaltet, um Latenz und Durchsatz zu verbessern.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
74. M3 Technik: Standard Service Tier
Der normale API-Tier ist für allgemeine Requests vorgesehen.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
75. M3 Technik: Priority Service Tier
Priority kann für priorisierte Scheduling- und Latenzanforderungen eingesetzt werden; Verfügbarkeit und Vertragsbedingungen sind separat zu prüfen.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
76. M3 Technik: Automatischer Cache
MiniMax bewirbt für M3 automatische Caching-Unterstützung, wodurch wiederverwendete Kontextanteile kostengünstiger verarbeitet werden können.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
77. M3 Technik: Open Weights
M3-Gewichte sind öffentlich verfügbar und können lokal beziehungsweise in eigener Infrastruktur betrieben werden.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
78. M3 Technik: Community License
Die Gewichte stehen unter der MiniMax Community License und nicht unter einer Standard-Open-Source-Lizenz.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
79. M3 Technik: Kommerzielle Kennzeichnung
Die M3-Lizenz verlangt für kommerzielle Nutzung eine sichtbare „Built with MiniMax M3“-Kennzeichnung.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
80. M3 Technik: Umsatzschwelle
Bei kommerziellen Produkten oberhalb der in der Lizenz genannten Umsatzschwelle ist eine separate schriftliche Autorisierung vorgesehen.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
81. M3 Technik: vLLM
vLLM gehört zu den empfohlenen Servingframeworks für M3.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
82. M3 Technik: SGLang
SGLang wird als weiterer Servingpfad dokumentiert.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
83. M3 Technik: Transformers
Transformers unterstützt den multimodalen M3-Modellpfad.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
84. M3 Technik: KTransformers
KTransformers wird als zusätzliche lokale Inferenzoption genannt.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
85. M3 Technik: Quantisierung
Quantisierung kann Speicherbedarf reduzieren, verändert aber Qualität, Geschwindigkeit und Reproduzierbarkeit.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
86. M3 Technik: KV-Cache
Eine Million Kontexttokens erzeugen trotz Sparse Attention erheblichen KV-/Runtime-Speicherbedarf.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
87. M3 Technik: Prefill
MSA reduziert die Kosten des Einlesens sehr langer Kontexte gegenüber der M2-Generation deutlich.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
88. M3 Technik: Decode
Auch die Token-für-Token-Ausgabe profitiert bei langen Kontexten von der neuen Attentionstruktur.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
89. M3 Technik: Tool Calling
Agentische Leistung setzt ein korrektes Toolschema, verlässliche Rückgaben und kontrollierte Berechtigungen voraus.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
90. M3 Technik: Interleaved Tool Use
Reasoning, Tool Calls und neue Beobachtungen müssen im Agentenverlauf konsistent erhalten bleiben.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
91. M3 Technik: Repositoryverständnis
Lange Kontexte können große Repositories abdecken, ersetzen aber keine Indexierung, Testausführung oder Abhängigkeitsanalyse.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
92. M3 Technik: Office-Dateien
Agenten können Dokument- und Tabellenarbeit unterstützen; das eigentliche Datei-Harness gehört zur Produktoberfläche.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
93. M3 Technik: Finanzworkflows
MiniMax beschreibt erste produktive Finanzanalysen, dennoch bleiben fachliche Validierung und Datenherkunft erforderlich.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
94. M3 Technik: MaxProof
Mathematische Test-Time-Skalierung wird über einen separaten generative-verifier-basierten Systempfad ergänzt.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
95. M3 Technik: Modell versus Harness
M3 kann in MiniMax Code, API oder Drittframeworks unterschiedlich wirken, obwohl die Gewichte gleich sind.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
96. M3 Technik: Snapshot-ID
Für reproduzierbare API-Tests sollte die konkrete Modell-ID oder dokumentierte Version statt eines flüchtigen Alias gespeichert werden.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
97. M3 Technik: Sampling
Temperatur, Top-p und Toolparameter beeinflussen Reproduzierbarkeit und sollten protokolliert werden.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
98. M3 Technik: Long-Horizon Drift
Bei langen Agentenläufen können Ziel, Berechtigungen und Kontext schleichend driften; Zwischenkontrollen bleiben notwendig.
M3 ist ein Foundation-Modell. Zugriff über API, MiniMax Code oder lokale Runtime kann zusätzliche Systemregeln, Tools und Limits einführen.
99. M2-Serie: M2 als Agent-first-Modell
M2 wurde ausdrücklich für Coding, Tool Use, Deep Search und Agentenworkflows optimiert.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
100. M2-Serie: M2 Open Weights
Die M2-Gewichte wurden öffentlich bereitgestellt und für lokale Servingframeworks dokumentiert.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
101. M2-Serie: M2 und vLLM
vLLM war ein empfohlener lokaler Servingpfad.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
102. M2-Serie: M2 und SGLang
SGLang war ebenfalls ein empfohlener Servingpfad.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
103. M2-Serie: M2 Sampling
MiniMax veröffentlichte konkrete empfohlene Samplingparameter für M2; solche Parameter gehören zur Reproduzierbarkeit.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
104. M2-Serie: Interleaved Thinking
M2 profitiert davon, Reasoningzustand zwischen Toolaufrufen nicht zu verlieren.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
105. M2-Serie: Tool-Schema-Generalisation
Agentenleistung hängt davon ab, ob das Modell neue Toolsets und unterschiedliche Scaffolds robust interpretieren kann.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
106. M2-Serie: M2.1 MoE
M2.1 besitzt rund 230B Gesamt- und 10B aktive Parameter.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
107. M2-Serie: M2.1 Mehrsprachiges Coding
M2.1 wurde gezielt für mehrere Programmiersprachen und reale Softwareprojekte verbessert.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
108. M2-Serie: M2.1 AppDev
Appentwicklung von Grund auf benötigt andere Evaluations- und Rewardmechanismen als klassische SWE-Patches.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
109. M2-Serie: M2.1 Agent-as-Verifier
MiniMax beschreibt interaktive Verifikation durch Agenten statt nur statischer LLM-Bewertung.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
110. M2-Serie: M2.1 WebExplorer
Synthetische Long-Horizon-Suchaufgaben dienen der Verbesserung schrittweiser Recherche.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
111. M2-Serie: M2.1 Scaffold-Generalisation
Training über mehrere Agentenscaffolds soll verhindern, dass Toolkompetenz nur in einer einzelnen ReAct-Schleife funktioniert.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
112. M2-Serie: M2.5 RL-Skalierung
M2.5 wurde mit stark skalierter Verstärkungslern-Infrastruktur über viele reale Arbeitsumgebungen trainiert.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
113. M2-Serie: M2.5 Coding
Coding und Refactoring gehören zu den Hauptzielen von M2.5.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
114. M2-Serie: M2.5 Search
Search-Agenten und Kontextmanagement sind zentrale Anwendungsfelder.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
115. M2-Serie: M2.5 Office
Office- und Wissensarbeit werden als produktive Agentenszenarien behandelt.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
116. M2-Serie: Forge Framework
Forge dient als agent-native RL-Schicht zwischen Agent und Trainings-/Inference-Infrastruktur.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
117. M2-Serie: M2.7 Agent Teams
M2.7 unterstützt Rollentrennung und Zusammenarbeit mehrerer Agenten in einem Harness.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
118. M2-Serie: M2.7 Skills
Komplexe Skills können als wiederverwendbare Arbeitsanweisungen und Toolmuster eingebunden werden.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
119. M2-Serie: M2.7 Dynamic Tool Search
Werkzeuge müssen nicht immer vollständig im Prompt stehen; dynamische Auswahl kann Kontext und Kosten sparen.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
120. M2-Serie: M2.7 Memory
MiniMax beschreibt interne Agenten mit persistenter Memory-Schicht zur Unterstützung längerer Forschungszyklen.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
121. M2-Serie: M2.7 Self-Critique
Iterative Harnessoptimierung nutzt Fehlerspuren, Selbstkritik und Evaluation statt einmaliger Ausgabe.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
122. M2-Serie: M2.7 Rollback
Automatisches Beibehalten oder Verwerfen von Harnessänderungen zeigt die Bedeutung kontrollierter Rollbacks.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
123. M2-Serie: M2.7 Produktion
Produktionsdebugging kombiniert Logs, Metriken, Datenbanken, Repository und Deploymentwissen; reine Codegenerierung reicht nicht.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
124. M2-Serie: M2.7 Skills Compliance
Lange Agentenläufe benötigen stabile Einhaltung umfangreicher Skills und Systemregeln.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
125. M2-Serie: M2-her
M2-her ist auf charakterkonsistente lange Dialoge und Roleplay spezialisiert.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
126. M2-Serie: Roleplay versus Productivity
Ein auf emotionale Interaktion optimierter Modellpfad ist nicht mit dem Coding-/Agentenpfad M2.7 gleichzusetzen.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
127. M2-Serie: M2.x Legacy
Mit M3 bleibt M2.x historisch und teils weiter per API verfügbar, ist aber nicht mehr der einzige aktuelle Frontierpfad.
Die M2-Serie erklärt den Übergang von offenem Reasoning zu realen Agentenworkflows und bildet die direkte technische Vorgeschichte von M3.
128. Architekturgeschichte: Lightning Attention
MiniMax-01 führte Lightning Attention als effizienten Attentionpfad für sehr lange Sequenzen in großem Maßstab ein.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
129. Architekturgeschichte: 4M Kontext bei Text-01
MiniMax nannte für Text-01 sehr lange Kontextfenster bis vier Millionen Tokens; tatsächliche Nutzbarkeit hängt von Runtime und Servingkonfiguration ab.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
130. Architekturgeschichte: 456B/45.9B bei Text-01
Die 01-Serie zeigte früh die MiniMax-Strategie, sehr große MoE-Kapazität mit deutlich kleinerem aktiven Rechenpfad zu kombinieren.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
131. Architekturgeschichte: Hybrid Attention bei M1
M1 kombiniert Lightning Attention und klassische Softmax Attention statt nur einen Attentiontyp zu verwenden.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
132. Architekturgeschichte: 32 Experten bei M1
M1 verwendet 32 Experten innerhalb der MoE-Struktur.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
133. Architekturgeschichte: 1M bei M1
M1 reduzierte gegenüber den extremen 01-Kontextangaben den Fokus auf ein explizit produktives 1M-Kontextfenster.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
134. Architekturgeschichte: 80K Reasoning Output
Lange Reasoning-Ausgaben erfordern getrennte Outputlimits, Kostenkontrolle und Stopbedingungen.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
135. Architekturgeschichte: RL für M1
Reasoningqualität entsteht nicht allein aus Architektur; Post-Training und Reinforcement Learning sind wesentliche Bestandteile.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
136. Architekturgeschichte: Open Weight als Forschungsbrücke
Die offenen 01-/M1-Releases ermöglichten externe Serving- und Long-Context-Experimente.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
137. Architekturgeschichte: Architekturwechsel statt lineare Versionsnummer
M3 übernimmt nicht einfach Lightning Attention unverändert, sondern führt mit MSA eine neue Sparse-Attention-Linie ein.
Die MiniMax-Architekturgeschichte verläuft von Lightning Attention über Hybrid Attention und Agent-MoE-Optimierung bis zu MiniMax Sparse Attention.
138. Video/H3: Hailuo-02
Hailuo-02 ist die 2025er Videogeneration mit 1080p-Pfad und expliziter Physik-/Bewegungsoptimierung.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
139. Video/H3: Text-to-Video
Hailuo 2.3 und Hailuo 02 können aus Textbeschreibungen kurze Videos generieren.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
140. Video/H3: Image-to-Video
Ein Ausgangsbild kann als visueller Zustand für Videoerzeugung dienen.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
141. Video/H3: Start Frame
Ein Startbild kontrolliert den ersten visuellen Zustand der Sequenz.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
142. Video/H3: End Frame
Ein Endbild kann den Zielzustand der Bewegung vorgeben.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
143. Video/H3: Start-and-End-Frame
Die Kombination beider Frames erhöht Kontrolle, kann aber schwierige Bewegungsinterpolation erzeugen.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
144. Video/H3: Subject Reference
Referenzbilder können zur Identitäts- beziehungsweise Subjektkonsistenz genutzt werden.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
145. Video/H3: Hailuo 2.3
2.3 verbessert Bewegungen, Mimik, Stilkontrolle und Instruktionsbefolgung gegenüber Hailuo 02.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
146. Video/H3: Hailuo 2.3 Fast
Die Fast-Variante priorisiert Effizienz und unterstützt insbesondere Image-to-Video.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
147. Video/H3: 6 Sekunden
1080p-Ausgabe ist bei Hailuo 2.3 für kurze 6-Sekunden-Clips dokumentiert.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
148. Video/H3: 10 Sekunden
768p kann bei Hailuo 2.3 auch längere 10-Sekunden-Clips abdecken.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
149. Video/H3: 24 fps
Die API-Dokumentation führt 24 Bilder pro Sekunde für Hailuo-Videomodelle.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
150. Video/H3: Asynchrone API
Videogeneration läuft als Task: Erstellen, Status abfragen, Ergebnisdatei abrufen.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
151. Video/H3: task_id
Die Task-ID ist ein Job-Identifier und keine persistente Medien-ID.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
152. Video/H3: file_id
Nach erfolgreicher Generierung wird ein Datei-Identifier für den Abruf bereitgestellt.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
153. Video/H3: Media Agent
Der Media Agent orchestriert mehrere Medienmodelle und kann automatische Pipelineentscheidungen treffen.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
154. Video/H3: H3 Omni-Modality
H3 verbindet multimodales Verständnis und audiovisuelle Videogeneration in einem allgemeineren System.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
155. Video/H3: H3 2K
H3 unterstützt veröffentlichte Ausgabeprofile bis 2K.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
156. Video/H3: H3 15 Sekunden
H3 erweitert die maximale dokumentierte Clipdauer auf bis zu 15 Sekunden.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
157. Video/H3: H3 Stereo Audio
H3 erzeugt natives synchronisiertes Stereo-Audio gemeinsam mit dem Video.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
158. Video/H3: H3 Textinput
Text kann als Steuerinformation für audiovisuelle Generierung dienen.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
159. Video/H3: H3 Bildinput
Bilder können als Teil eines multimodalen Generationskontexts dienen.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
160. Video/H3: H3 Videoinput
Video kann als Referenz- oder Transformationskontext verwendet werden.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
161. Video/H3: H3 Audioinput
Audio kann in den gemeinsamen multimodalen Kontext eingehen.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
162. Video/H3: Contextual Omni Representation
H3 beschreibt eine gemeinsame Kontextrepräsentation über mehrere Modalitäten hinweg.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
163. Video/H3: H3-VAE
Visuelle und audiovisuelle Latentpfade werden über spezialisierte Encoder/VAE-Komponenten repräsentiert.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
164. Video/H3: H3-Omni-Transformer
Der Omni-Transformer verarbeitet die gepackte multimodale Sequenz.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
165. Video/H3: In-Context Regeneration
H3 nutzt einen Regenerationsansatz, um lokale oder referenzbasierte Änderungen im Kontext zu steuern.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
166. Video/H3: H3 Open Weights
Die H3-Gewichte sind öffentlich abrufbar und in Diffusers-/Community-Ökosysteme integriert.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
167. Video/H3: H3 33B
Die veröffentlichte Hugging-Face-Modellkarte nennt ungefähr 33B Parameter für H3.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
168. Video/H3: H3 Community License
H3 hat eine eigene Lizenz und ist nicht Apache 2.0, auch wenn einzelne Code-Repositories oder Komponenten andere Lizenzen verwenden.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
169. Video/H3: H3 Territory Exclusion
Die pauschale Community-Lizenz schließt EU, UK, USA und Südkorea aus ihrem Applicable Territory aus.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
170. Video/H3: H3 in Deutschland
Für eine Nutzung der H3-Gewichte in Deutschland ist deshalb vorab eine separate Lizenz-/Autorisierungsprüfung erforderlich.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
171. Video/H3: H3 API versus Gewichte
Ein gehosteter API-Zugang und das Recht zur lokalen Nutzung der veröffentlichten Gewichte sind rechtlich und technisch getrennte Wege.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
172. Video/H3: Moderation
Gehostete H3-Pfade moderieren Eingaben und können legitime Inhalte fälschlich blockieren oder problematische Inhalte übersehen.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
173. Video/H3: Video Prompt Injection
Bei agentischer Verarbeitung fremder Bilder/Videos können eingebettete Instruktionen oder manipulierte Metadaten eine zusätzliche Angriffsklasse bilden.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
174. Video/H3: Identitätskonsistenz
Referenzbasierte Generierung verbessert Konsistenz, garantiert aber keine perfekte Identität über alle Frames.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
175. Video/H3: Physik
„Physics mastery“ ist eine Produktpositionierung; generative Videos bleiben probabilistische Synthesen ohne physikalische Garantien.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
176. Video/H3: Text Rendering
H3 zielt auf bessere Text- und Markenrendering-Fähigkeit, dennoch müssen Schriften und Logos visuell kontrolliert werden.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
177. Video/H3: V2V Motion Transfer
Video-zu-Video-Transformation kann Bewegung übernehmen, birgt aber Drift bei Identität, Hintergrund und Details.
Videoqualität wird nicht allein durch Modellnamen bestimmt; Inputtyp, Auflösung, Dauer, Referenzen, Prompt, Seed-/Samplingpfad und Nachbearbeitung beeinflussen das Ergebnis.
178. Speech/Audio: Speech 2.8 HD
HD priorisiert Stimmqualität und Detail gegenüber maximaler Geschwindigkeit.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
179. Speech/Audio: Speech 2.8 Turbo
Turbo priorisiert schnellere Ausgabe und Echtzeitszenarien.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
180. Speech/Audio: 40 Sprachen
Die aktuelle Speech-Dokumentation führt Unterstützung für 40 Sprachen.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
181. Speech/Audio: Dialekte
Neben Sprachen werden unterschiedliche Dialekte beziehungsweise regionale Sprechweisen unterstützt.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
182. Speech/Audio: 7 Emotionen
Die API führt sieben Emotionseinstellungen als steuerbare Ausdrucksebene.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
184. Speech/Audio: Voice Cloning
Kurze Referenzaufnahmen können zur Erzeugung einer geklonten Stimme verwendet werden.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
185. Speech/Audio: Voice Design
Stimmen können auch aus Beschreibungen entworfen werden, ohne eine konkrete Person zu kopieren.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
186. Speech/Audio: Temporäre Stimmen
Neu erzeugte Stimmen können zeitlich begrenzt sein, bis sie durch tatsächliche Synthesenutzung persistiert werden.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
187. Speech/Audio: Streaming
Speech unterstützt Streamingausgabe für Echtzeitinteraktion.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
188. Speech/Audio: MP3
MP3 ist ein unterstütztes Ausgabeformat.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
189. Speech/Audio: PCM
PCM eignet sich für rohe Audiostreams und Echtzeitverarbeitung.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
190. Speech/Audio: FLAC
FLAC bietet verlustfreie komprimierte Ausgabe.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
191. Speech/Audio: WAV
WAV ist im dokumentierten API-Pfad insbesondere für nichtstreamende Ausgabe verfügbar.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
192. Speech/Audio: Lautstärke
Lautstärke kann als Syntheseparameter angepasst werden.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
193. Speech/Audio: Pitch
Tonhöhe ist steuerbar, sollte aber nicht mit natürlicher Sprecheridentität verwechselt werden.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
194. Speech/Audio: Speed
Sprechgeschwindigkeit kann angepasst werden und verändert Rhythmus und Verständlichkeit.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
195. Speech/Audio: Realtime API
Echtzeitsprachdialog verbindet Eingabe, LLM/Agent und TTS in einer Latenzpipeline.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
196. Speech/Audio: Voice Consent
Stimmklonung verlangt klare Einwilligung und Rechteklärung; technische Verfügbarkeit ersetzt keine Nutzungserlaubnis.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
197. Speech/Audio: Deepfake-Risiko
Realistische Stimmen erhöhen Missbrauchsrisiken für Identitätsvortäuschung und Betrug.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
198. Speech/Audio: Pronunciation
Namen, Fachbegriffe und Mischsprachen sollten mit Testsets geprüft werden.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
199. Speech/Audio: Code Switching
Mehrsprachige Äußerungen können Sprachwechsel in einer einzelnen Ausgabe enthalten.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
200. Speech/Audio: Latency
Netzwerk, Modell, Audioencoder und Streamingpuffer bestimmen gemeinsam die Ende-zu-Ende-Latenz.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
201. Speech/Audio: Cloning Similarity
Hohe Ähnlichkeit ist kein Beleg für identische Stimme und kann je nach Referenzaudio schwanken.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
202. Speech/Audio: Audio Agent
Speech ist ein Modell-/API-Baustein; ein Voice Agent benötigt zusätzlich Dialogsteuerung, ASR, Turn Detection, Tools und Sicherheitslogik.
Bei Sprachsystemen müssen Modellqualität, Übertragungsweg, Einwilligung, Sprecherrechte, Speicherfristen und Agentenlogik getrennt bewertet werden.
203. Music: Music 2.0
Music 2.0 etablierte vollständige Songgenerierung mit Gesang und Instrumenten als zentrale Produktlinie.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
204. Music: Music 2.5+
Music 2.5+ erweiterte den 2026er Übergang vor Music 2.6 und 3.0.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
205. Music: Music 2.6
Music 2.6 bleibt in der API-Dokumentation als aktueller beziehungsweise zuletzt gehosteter Music-2.x-Pfad dokumentiert.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
206. Music: Music 3.0
Music 3.0 ist der August-2026-Open-Weight-Endpunkt der Musikmodelllinie.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
207. Music: bis fünf Minuten
Music 3.0 zielt auf vollständige Songs bis zu ungefähr fünf Minuten statt nur kurze Loops.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
208. Music: Lyrics optional
Ein Song kann mit eigenem Liedtext oder nur aus einer kreativen Beschreibung erzeugt werden.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
209. Music: Structured Captions
Feingranulare Beschreibungen steuern Emotion, Instrumentierung, Arrangement und vokale Entwicklung über den Songverlauf.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
211. Music: Global LLM 8B
Der globale Sprachmodellpfad modelliert langfristige musikalische Struktur und semantische Tokens.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
212. Music: Local LLM 0.6B
Ein kleiner lokaler Modellpfad modelliert akustische Details innerhalb einzelner Frames.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
213. Music: Qwen3.5-8B-Basis
Der Global-LM-Pfad von Music 3.0 wurde aus Qwen3.5-8B initialisiert; daraus folgt keine Identität der Gesamtmodelle.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
214. Music: 8-layer RVQ
Mehrstufige Residual Vector Quantization trennt zentrale Struktur von feineren akustischen Restinformationen.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
215. Music: Flow Matching
Kontinuierliche Modellzustände werden über Flow Matching in einen Audio-Latentraum überführt.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
216. Music: Flow-VAE
Ein speziell trainierter VAE rekonstruiert die finale Audio-Wellenform.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
217. Music: Vocal Naturalness
Music 3.0 zielt auf natürlichere Aussprache, Atemführung und Gesangsphrasierung.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
218. Music: Instrument Realism
Instrumentale Details und Mischungsbalance werden als eigenes Qualitätsziel adressiert.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
219. Music: Open Weights
Music 3.0 wird als Open-Weight-Modell veröffentlicht.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
220. Music: Music3 Community License
Die Gewichte stehen unter einer eigenen Community License mit Kennzeichnungs- und kommerziellen Bedingungen.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
221. Music: 20-Millionen-Schwelle
Die Music3-Lizenz nennt für große kommerzielle Produkte eine separate Autorisierung oberhalb einer Umsatzschwelle.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
222. Music: Token Plan entfernt
Seit 20. August 2026 sind Musikmodelle laut Token-Plan-Hinweis nicht mehr Teil dieses konkreten Abonnements.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
223. Music: API versus Open Weights
Gehosteter Music-API-Zugang und lokale Nutzung der Music3-Gewichte sind getrennte Betriebswege.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
224. Music: Urheberrecht
Prompts, Lyrics, Trainingsbezug und Ausgabe können Urheber- und Leistungsschutzfragen auslösen; technische Generierung ersetzt keine Rechteklärung.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
225. Music: Stimmähnlichkeit im Song
Eine generierte Gesangsstimme sollte nicht ohne Rechteklärung gezielt eine reale Person imitieren.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
226. Music: Arrangementkontrolle
Lange Songs benötigen kohärente Übergänge; wiederholte Refrains oder Instrumentwechsel sollten separat bewertet werden.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
227. Music: Reproduzierbarkeit
Modellrevision, Prompt, Lyrics, Seed beziehungsweise Generationsparameter und Nachbearbeitung müssen gemeinsam archiviert werden.
Musikgenerierung ist eine eigene Modell- und Rechteklasse; sie darf weder mit Speech/TTS noch mit einem allgemeinen Textmodell gleichgesetzt werden.
228. Bildgeneration: Image-01
Image-01 ist MiniMax’ erster Text-zu-Bild-Release von Februar 2025.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
229. Bildgeneration: Prompt Adherence
Der Modellpfad wurde auf genaue Umsetzung komplexer Beschreibungen ausgerichtet.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
230. Bildgeneration: Composition
Bildkomposition und räumliche Logik sind eigene Qualitätsdimensionen neben Stilästhetik.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
231. Bildgeneration: Text-to-Image API
Bildgenerierung nutzt einen eigenen API-Endpunkt und eigene Abrechnungslogik.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
232. Bildgeneration: Image-to-Image
Aktuelle Plattformpfade unterstützen auch referenzbasierte Bildtransformation.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
233. Bildgeneration: M3 Vision ≠ Image-01
M3 versteht Bilder als Eingabe; Image-01 erzeugt Bilder. Diese Fähigkeiten sind nicht austauschbar.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
234. Bildgeneration: H3 ≠ Image-01
H3 ist primär ein omni-modales Video-/Audio-Generationssystem und kein Ersatzbegriff für den Bildgenerationsendpunkt.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
235. Bildgeneration: Referenzrechte
Referenzbilder können personenbezogene, urheberrechtliche oder markenrechtliche Anforderungen erzeugen.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
236. Bildgeneration: Text im Bild
Generierter Text und Logos müssen visuell kontrolliert werden; semantisch korrekte Prompts garantieren keine fehlerfreie Typografie.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
237. Bildgeneration: Metadaten
Exportierte Bilder sollten für Archivierung zusätzlich mit Modell, Prompt, Datum und Bearbeitungspfad dokumentiert werden.
Bildgeneration, Bildverständnis und Videoerzeugung sind getrennte Modellklassen innerhalb des MiniMax-Stacks.
238. Produkt/API: MiniMax Code
MiniMax Code ist der aktuelle Coding-/Agentenproduktpfad rund um M3.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
239. Produkt/API: Computer Use
Code kann in einem freigegebenen Harness Anwendungen, Dateien und Systeme bedienen.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
240. Produkt/API: Mobile-to-Desktop
M3-Beispiele zeigen Aufträge vom Mobilgerät an Desktopanwendungen; das erfordert vertrauenswürdige Session- und Rechteübergabe.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
241. Produkt/API: MiniMax Design
MiniMax Design bündelt agentische beziehungsweise generative Funktionen für kommerzielle Content- und Designarbeit.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
242. Produkt/API: MiniMax Audio
Die Audio-Produktoberfläche stellt Speech- und verwandte Audiowerkzeuge für Endnutzer bereit.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
243. Produkt/API: Hailuo
Hailuo ist die Video-Produktoberfläche und darf nicht als Name eines einzelnen Foundation-Modells verwendet werden.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
244. Produkt/API: Talkie
Talkie ist eine interaktive Companion-/Character-Produktoberfläche mit eigener Produktlogik.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
245. Produkt/API: Mavis
Mavis bezeichnet die 2026 ausgebaute Agentenoberfläche mit Teams und langlaufenden Aufgaben.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
246. Produkt/API: Agent Teams
Mehrere Agenten können parallel Rollen übernehmen; Rollen, Rechte und Konfliktauflösung müssen explizit gestaltet werden.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
247. Produkt/API: Long-Running Tasks
Lange Aufgaben erfordern Checkpoints, Kostenlimits, Timeout, Zwischenfreigaben und robuste Wiederaufnahme.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
248. Produkt/API: Skills
Skills kapseln wiederverwendbare Arbeitsanweisungen und erhöhen zugleich die Notwendigkeit von Versionskontrolle.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
249. Produkt/API: Memory
Persistenter Agentenkontext ist von M3s 1M-Kontextfenster zu unterscheiden.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
250. Produkt/API: MCP
MCP kann externe Medien- und Suchwerkzeuge zugänglich machen; Serververtrauen und Toolschemas sind Sicherheitsgrenzen.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
251. Produkt/API: OpenClaw
MiniMax-Modelle werden in Agentenökosystemen wie OpenClaw eingesetzt; das Fremdharness verändert Verhalten und Risiko.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
252. Produkt/API: Token Plan
Token Plan bündelt Nutzungsquoten und unterschiedliche Modellfamilien für interaktive Entwicklerarbeit.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
253. Produkt/API: Pay-as-you-go
Pay-as-you-go ist der reguläre API-Abrechnungspfad für produktive Integrationen.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
254. Produkt/API: Credits
Prepaid Credits sind eine weitere Abrechnungsform und nicht mit Modellkontext oder Token Cache zu verwechseln.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
255. Produkt/API: Team Seats
Team-Abonnements können gemeinsame Ressourcen und Quoten abbilden; Adminrechte und Datenzugriff müssen separat geprüft werden.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
256. Produkt/API: API Key
Normale API-Keys authentifizieren Pay-as-you-go- und Plattformaufrufe.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
257. Produkt/API: Token Plan Key
Token-Plan-Keys bilden eigene Quoten ab und sind nicht einfach ein Alias für den normalen API-Key.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
258. Produkt/API: Global Endpoint
Der globale API-Pfad wird unter api.minimax.io dokumentiert.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
259. Produkt/API: China Endpoint
Für chinesische Plattformpfade existieren separate Domains und Regionseinstellungen.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
260. Produkt/API: OpenAI Compatibility
OpenAI-kompatible Endpunkte vereinfachen SDK-Migrationen, garantieren aber keine vollständige Featureidentität.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
261. Produkt/API: Anthropic Compatibility
Anthropic-kompatible Messages-Integrationen sind für M2.x/M3 besonders relevant wegen Thinking-/Tool-Workflows.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
262. Produkt/API: Native API
Native MiniMax-Endpunkte können multimodale und medienspezifische Funktionen bereitstellen, die Kompatibilitätsschichten nicht vollständig abbilden.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
263. Produkt/API: Official CLI
Die CLI bündelt mehrere Modalitäten und kann als reproduzierbarer Automatisierungsclient dienen.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
264. Produkt/API: Official MCP Server
Offizielle MCP-Server stellen Medienaktionen für Agenten bereit.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
265. Produkt/API: File Management
Die Plattform besitzt Datei-APIs für Dokumente und Medien, die teilweise mit asynchronen Generationsjobs zusammenspielen.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
266. Produkt/API: 100GB File Capacity
Die API-Dokumentation nennt für File Management eine Gesamtkapazität von 100GB; Limits können sich ändern und sollten aktuell geprüft werden.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
267. Produkt/API: 512MB Dokument
Für einzelne Dokumente wird ein Größenlimit von 512MB dokumentiert.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
268. Produkt/API: Asynchronous Jobs
Video und andere lange Medienjobs laufen asynchron und benötigen Statusabfragen statt einer einzigen blockierenden HTTP-Antwort.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
269. Produkt/API: Rate Limits
RPM/TPM und dynamische Traffic-Regeln beeinflussen produktive Zuverlässigkeit unabhängig von der Modellqualität.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
270. Produkt/API: Priority Tier
Priorisierte Servingpfade dienen stabilerer Latenz, machen das Modell aber nicht intelligenter.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
271. Produkt/API: Cache Read
Wiederverwendete Kontexte können gesondert und günstiger abgerechnet werden.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
272. Produkt/API: Production Recommendation
MiniMax empfiehlt für Produktion reguläres Pay-as-you-go statt des primär interaktiven Token Plans.
Produktoberfläche, Authentisierung, Abrechnung, Agentenrechte und Foundation-Modell sind jeweils separat zu dokumentieren.
273. Datenschutz/Sicherheit: API Privacy Policy 30. März 2026
Die globale API-Datenschutzerklärung wurde zum 30. März 2026 aktualisiert.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
274. Datenschutz/Sicherheit: Nanonoble Pte. Ltd.
Die globale Policy nennt Nanonoble Pte. Ltd. und verbundene Unternehmen als verantwortliche Anbieterseite.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
275. Datenschutz/Sicherheit: Jurisdiction-specific provisions
Für EWR/UK/Schweiz und weitere Regionen nennt die Policy zusätzliche länderspezifische Regelungen.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
276. Datenschutz/Sicherheit: Global versus CN
Ein globaler Account und ein chinesischer Plattformpfad können unterschiedliche Vertragspartner, Datenwege und Funktionen besitzen.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
277. Datenschutz/Sicherheit: API ≠ Consumer Product
Datenregeln eines API-Vertrags dürfen nicht automatisch auf Talkie, Hailuo, Audio oder andere Consumerprodukte übertragen werden.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
278. Datenschutz/Sicherheit: Self-Hosting
Lokale Open-Weight-Nutzung kann Promptübertragung zum MiniMax-API-Dienst vermeiden, sofern Runtime und Zusatztools ebenfalls lokal bleiben.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
279. Datenschutz/Sicherheit: Telemetry
Auch ein lokales Modell kann über Launcher, Paketmanager, Telemetrie, MCP oder Websuche Netzwerkverkehr erzeugen.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
280. Datenschutz/Sicherheit: Secrets
API-Keys, Tokens, Kundendaten und Zugangsdaten gehören nicht unkontrolliert in Prompts, Logs oder Agentenspeicher.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
281. Datenschutz/Sicherheit: Least Privilege
Agenten erhalten nur die Dateien, Konten und Aktionen, die für die konkrete Aufgabe erforderlich sind.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
282. Datenschutz/Sicherheit: Prompt Injection
Webseiten, Dokumente, Bilder und Toolantworten können bösartige Instruktionen enthalten.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
283. Datenschutz/Sicherheit: Indirect Prompt Injection
Agenten müssen zwischen Benutzerauftrag und fremden Dokumentinhalten unterscheiden.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
284. Datenschutz/Sicherheit: Visual Prompt Injection
Text in Bildern oder Video-Frames kann ein multimodales Modell zu unerwünschten Aktionen verleiten.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
285. Datenschutz/Sicherheit: Tool Output Injection
Auch strukturierte API-Rückgaben können manipulierte Felder enthalten und dürfen nicht als Systemanweisung behandelt werden.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
286. Datenschutz/Sicherheit: MCP Trust
Ein MCP-Server ist zusätzlicher Code mit eigenen Berechtigungen, Updates und Supply-Chain-Risiken.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
287. Datenschutz/Sicherheit: Shell Access
Coding-Agenten mit Shellzugriff benötigen Sandbox, Verzeichnisgrenzen und Bestätigung für destruktive Befehle.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
288. Datenschutz/Sicherheit: Git Credentials
Repositoryzugriff sollte über minimal berechtigte Tokens und isolierte Branches erfolgen.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
289. Datenschutz/Sicherheit: Package Supply Chain
Automatische Paketinstallation kann Typosquatting, kompromittierte Abhängigkeiten oder unerwartete Postinstall-Skripte auslösen.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
290. Datenschutz/Sicherheit: Browser Credentials
Computer-Use-Agenten dürfen Browserprofile und gespeicherte Sitzungen nicht pauschal übernehmen.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
291. Datenschutz/Sicherheit: File Deletion
Destruktive Dateiaktionen benötigen Vorschau, Backup und explizite Bestätigung.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
292. Datenschutz/Sicherheit: Long-Running Agent Drift
Langlaufende Teams können vom ursprünglichen Ziel abweichen; Zwischenziele und Prüfstopps sind notwendig.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
293. Datenschutz/Sicherheit: Multi-Agent Delegation
Unteragenten dürfen nicht automatisch alle Rechte des Hauptagenten erben.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
294. Datenschutz/Sicherheit: Voice Clone Consent
Stimmen dürfen nur mit geklärten Rechten und Einwilligung geklont beziehungsweise veröffentlicht werden.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
295. Datenschutz/Sicherheit: Biometric Implications
Stimm- und Gesichtsreferenzen können biometrisch oder personenbezogen relevant sein und brauchen besondere Sorgfalt.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
296. Datenschutz/Sicherheit: H3 License Territory
Die H3-Gewichtelizenz schränkt territoriale Nutzung ausdrücklich ein; öffentlich zugängliche Dateien sind deshalb nicht automatisch lokal nutzbar.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
297. Datenschutz/Sicherheit: M3 Commercial License
Die M3-Community-Lizenz enthält Kennzeichnungs- und Autorisierungsregeln für kommerzielle Nutzung.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
298. Datenschutz/Sicherheit: Music3 Commercial License
Music3 besitzt eigene kommerzielle Bedingungen und Kennzeichnungspflichten.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
299. Datenschutz/Sicherheit: Output Rights
Modelllizenz, Rechte an Inputmaterial und Rechte an Output sind getrennte Fragen.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
300. Datenschutz/Sicherheit: Retention
Speicher- und Löschfristen müssen anhand des konkret genutzten Produkts und aktuellen Vertrags geprüft werden.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
301. Datenschutz/Sicherheit: Logs
Anwendungslogs können Prompts, Toolresultate, Dateinamen und Geheimnisse enthalten und brauchen Datenminimierung.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
302. Datenschutz/Sicherheit: Data Residency
Eine globale Domain beweist keine bestimmte Datenresidenz; konkrete Hosting- und Vertragsinformationen sind maßgeblich.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
303. Datenschutz/Sicherheit: Encryption
Transportverschlüsselung schützt Daten auf dem Übertragungsweg, ersetzt aber keine Zugriffs- und Retentionkontrolle.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
304. Datenschutz/Sicherheit: Audit Trail
Produktive Agenten sollten Toolaufrufe, Genehmigungen und Dateiversionen nachvollziehbar protokollieren.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
305. Datenschutz/Sicherheit: Human Approval
Hohe Auswirkungen wie Versand, Zahlung, Löschung, Veröffentlichung oder Produktionsdeployments benötigen menschliche Freigabe.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
306. Datenschutz/Sicherheit: Fail Closed
Wenn Rechte, Ziel oder Toolresultat unklar sind, sollte ein produktiver Agent stoppen statt zu raten.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
307. Datenschutz/Sicherheit: Rollback
Änderungen an Code, Dokumenten und Infrastruktur benötigen eine klar getestete Rückfallmöglichkeit.
Sicherheit entsteht aus Modell, Harness, Berechtigung, Datenfluss, Lizenz und Betriebsprozess gemeinsam; kein einzelner Guardrail ersetzt die übrigen Schichten.
308. Lokale Inferenz: M3 lokal
M3 kann mit veröffentlichten Gewichten selbst gehostet werden; die große Gewichtemenge erfordert leistungsfähige Hardware und verteiltes Serving.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
309. Lokale Inferenz: M3 VRAM
Aktive Parameter reduzieren Rechenaufwand, aber die gesamten MoE-Gewichte müssen für Serving verfügbar sein beziehungsweise über Geräte verteilt werden.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
310. Lokale Inferenz: M3 Quantisierung
Niedrigere Präzision reduziert Speicherbedarf, kann aber multimodale, Tool- und Reasoningqualität beeinflussen.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
311. Lokale Inferenz: M3 1M KV
Ein Million-Token-Lauf erhöht KV-Cache- und Runtimebedarf erheblich, selbst wenn Sparse Attention Rechenarbeit reduziert.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
312. Lokale Inferenz: M3 Tensor Parallel
Große Deployments verteilen Gewichtsmatrizen über mehrere Beschleuniger.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
313. Lokale Inferenz: M3 Expert Parallel
MoE-Serving kann Experten über Geräte verteilen; Kommunikationskosten werden dann zu einer zentralen Leistungsgröße.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
314. Lokale Inferenz: vLLM
vLLM ist ein verbreiteter Produktionsserver für MiniMax-Textmodelle.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
315. Lokale Inferenz: SGLang
SGLang bietet einen weiteren optimierten Servingpfad für Agenten- und Long-Context-Modelle.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
316. Lokale Inferenz: Transformers
Transformers eignet sich für Referenztests und multimodale Integration, ist aber nicht automatisch der schnellste Produktionsserver.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
317. Lokale Inferenz: KTransformers
KTransformers kann große Modelle auf heterogener Hardware nutzbar machen, mit eigenen Performance- und Quantisierungstradeoffs.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
318. Lokale Inferenz: H3 lokal
H3-Gewichte sind sehr groß und die Lizenz ist territorial eingeschränkt; Hardwarefrage und Nutzungsrecht müssen vor einer Installation getrennt geklärt werden.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
319. Lokale Inferenz: H3 Speichergröße
Der veröffentlichte H3-Repositoryumfang liegt im Hunderte-GB-Bereich; lokale Videogeneration ist deutlich anspruchsvoller als das Laden eines kleinen LLMs.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
320. Lokale Inferenz: Music3 lokal
Music3 kann lokal betrieben werden, benötigt aber mehrere Modellkomponenten und eine komplette Audio-Synthesepipeline.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
321. Lokale Inferenz: Containerisierung
Container fixieren Runtime, CUDA-/ROCm-Bibliotheken und Pythonabhängigkeiten und verbessern Reproduzierbarkeit.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
322. Lokale Inferenz: GPU-Treiber
Treiber- und Kernelversionen können Funktionsfähigkeit und Performance stärker beeinflussen als kleine Promptänderungen.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
323. Lokale Inferenz: Quantisierungsformat
GPTQ, AWQ, GGUF oder andere Formate sind nicht austauschbar und können unterschiedliche Runtimefunktionen unterstützen.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
324. Lokale Inferenz: Multimodale Processor
M3 benötigt neben Modellgewichten passende Processor-/Tokenizerkomponenten für Bild- und Videoeingaben.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
325. Lokale Inferenz: Trust Remote Code
Modelle mit benutzerdefiniertem Transformers-Code sollten nur aus vertrauenswürdiger Revision ausgeführt werden.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
326. Lokale Inferenz: Revision Pinning
Git-/HF-Commit oder Revision pinnen, damit spätere Modellkarten- oder Codeänderungen Tests nicht unbemerkt verändern.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
327. Lokale Inferenz: Offline Deployment
Für wirklich offline betriebene Systeme müssen auch Tokenizer, Processor, Modelle, Pythonpakete und MCP-/Toolabhängigkeiten lokal vorhanden sein.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
328. Lokale Inferenz: Network Egress
Egress-Regeln zeigen, ob ein vermeintlich lokaler Stack Such-, Telemetrie- oder Lizenzdienste anspricht.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
329. Lokale Inferenz: Benchmark Warmup
Vor Latenztests Warmup, Cachezustand und Batchgröße dokumentieren.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
330. Lokale Inferenz: Prefill versus Decode
Long-Context-Leistung sollte getrennt nach Prefill und Decode gemessen werden.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
331. Lokale Inferenz: Concurrency
Ein Modell mit hoher Einzelsitzungsrate kann unter paralleler Last deutlich anders reagieren.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
332. Lokale Inferenz: Batching
Continuous Batching verbessert GPU-Auslastung, kann aber Latenz einzelner Requests verändern.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
333. Lokale Inferenz: Context Truncation
Runtime und API können Eingaben kürzen; effektive Tokenzahl muss vor dem Modellaufruf geprüft werden.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
334. Lokale Inferenz: Tokenizer Version
Tokenizeränderungen verändern Tokenzahl und damit Kontext- und Kostenmessung.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
335. Lokale Inferenz: Chat Template
Ein falsches Chattemplate kann Instruction Following und Tool Calling stark verschlechtern.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
336. Lokale Inferenz: Tool Parser
Toolaufrufe benötigen einen zum Modellformat passenden Parser; JSON allein garantiert keine Semantik.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
337. Lokale Inferenz: Thinking Preservation
Reasoningblöcke müssen in kompatiblen Agentenpfaden korrekt zwischen Tool Calls erhalten werden.
Lokale Nutzung bedeutet Kontrolle über Serving, aber auch Verantwortung für Lizenz, Sicherheit, Moderation, Updates, Backups und Hardwarebetrieb.
338. Agent Engineering: Agent Harness
Ein Agent Harness verwaltet Systemregeln, Tools, Dateien, Memory, Schleifen und Zustandsübergänge um das Foundation-Modell.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
339. Agent Engineering: Plan versus Execute
Planung und Ausführung sollten als getrennte Phasen protokolliert werden, damit unerwünschte Aktionen vor Toolzugriff gestoppt werden können.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
340. Agent Engineering: Read-only First
Bei unbekannten Repositories und Dateisystemen ist zunächst ein rein lesender Analysepfad sicherer als unmittelbarer Schreibzugriff.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
341. Agent Engineering: Workspace Boundary
Der Agent sollte nur ein definiertes Arbeitsverzeichnis sehen und nicht das gesamte Benutzerprofil oder Laufwerk.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
342. Agent Engineering: Tool Whitelist
Nur explizit benötigte Tools freigeben; dynamische Tool Search darf nicht zu einer unkontrollierten Capability-Ausweitung führen.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
343. Agent Engineering: Tool Timeout
Jeder externe Toolaufruf benötigt ein Zeitlimit, damit ein hängender Dienst nicht den gesamten Agentenlauf blockiert.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
344. Agent Engineering: Tool Retry
Retries benötigen Backoff und Idempotenzprüfung, damit Aktionen wie Versand oder Zahlung nicht doppelt ausgeführt werden.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
345. Agent Engineering: Idempotency Key
Schreibende APIs sollten, wenn möglich, eindeutige Idempotency Keys erhalten.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
346. Agent Engineering: Checkpointing
Langlaufende Aufgaben brauchen stabile Checkpoints mit Ziel, Dateien, Toolzustand und offenen Entscheidungen.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
347. Agent Engineering: Resume Safety
Beim Wiederaufnehmen darf ein Agent nicht annehmen, dass externe Systeme unverändert geblieben sind.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
348. Agent Engineering: State Revalidation
Vor kritischen Folgeschritten externe Zustände erneut lesen, statt sich nur auf alten Conversation-Kontext zu verlassen.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
349. Agent Engineering: Human-in-the-Loop
Freigaben sind besonders wichtig vor Löschen, Senden, Veröffentlichen, Deployen, Kaufen oder Ändern produktiver Daten.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
350. Agent Engineering: Role Separation
Agent Teams brauchen Rollen mit getrennten Zuständigkeiten statt mehrere identische Modelle ohne Governance.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
351. Agent Engineering: Reviewer Agent
Ein separater Reviewer kann Fehler finden, muss aber unabhängig genug arbeiten und darf nicht nur dieselbe Begründung paraphrasieren.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
352. Agent Engineering: Adversarial Reviewer
Für riskante Änderungen ist eine explizit kritische Gegenprüfung hilfreicher als ein zustimmender Zweitagent.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
354. Agent Engineering: Private Scratchpad
Interne Agentennotizen dürfen keine Geheimnisse oder personenbezogenen Daten unnötig persistieren.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
355. Agent Engineering: Context Compression
Lange Agentenverläufe benötigen kontrollierte Zusammenfassung; dabei dürfen Anforderungen und offene Fehler nicht verloren gehen.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
356. Agent Engineering: Evidence Ledger
Wichtige Fakten sollten mit Quelle beziehungsweise Toolresultat in einer strukturierten Evidenzliste gehalten werden.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
357. Agent Engineering: Decision Log
Warum eine irreversible Aktion freigegeben wurde, sollte nachvollziehbar protokolliert sein.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
358. Agent Engineering: Budget Guard
Token-, Zeit-, API- und Medienbudgets verhindern unendliche oder wirtschaftlich unsinnige Agentenläufe.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
359. Agent Engineering: Loop Detector
Wiederholte identische Toolfolgen sind ein Signal zum Stoppen und zur erneuten Planung.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
360. Agent Engineering: Progress Metric
Lange Aufgaben brauchen überprüfbare Fortschrittskriterien statt bloßer Aktivität.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
361. Agent Engineering: Acceptance Tests
Vor Abschluss müssen fachliche Akzeptanztests erfüllt sein, nicht nur syntaktische oder visuelle Plausibilität.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
362. Agent Engineering: Sandbox
Codeausführung sollte in isolierten Umgebungen mit begrenztem Dateisystem und Netzwerk erfolgen.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
363. Agent Engineering: Network Policy
Ausgehender Netzwerkzugriff kann domainspezifisch eingeschränkt werden, um Datenabfluss und Supply-Chain-Risiken zu reduzieren.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
364. Agent Engineering: Secrets Broker
Agenten sollten kurzlebige, scoped Credentials erhalten statt dauerhaft gespeicherter Hauptschlüssel.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
365. Agent Engineering: Credential Rotation
Nach kompromittiertem oder falsch geloggtem Secret ist Rotation erforderlich; Löschen aus dem Chat reicht nicht.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
366. Agent Engineering: Approval Scope
Eine Genehmigung muss Aktion, Ziel und Umfang benennen; pauschale Dauerfreigaben sind riskant.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
367. Agent Engineering: Dry Run
Ein Dry-Run kann vorgesehene Datei-, Datenbank- oder Infrastrukturänderungen vor Ausführung zeigen.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
368. Agent Engineering: Diff First
Bei Code und Text ist ein Diff leichter zu prüfen als eine vollständig neu geschriebene Datei.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
369. Agent Engineering: Atomic Write
Dateiänderungen sollten möglichst atomar erfolgen, um Teilzustände bei Abbruch zu vermeiden.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
370. Agent Engineering: Backup Before Write
Vor großen Agentenänderungen Backups beziehungsweise Versionskontrolle sicherstellen.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
371. Agent Engineering: Observability
Toolaufrufe, Latenzen, Fehlercodes und Modellnutzung müssen für Produktionsagenten beobachtbar sein.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
372. Agent Engineering: Trace Correlation
Ein gemeinsamer Trace-Identifier verbindet Modellrequest, Toolaufruf und externe Aktion.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
373. Agent Engineering: Error Taxonomy
Fehler sollten nach Modell, Tool, Daten, Auth, Netzwerk, Runtime und Fachlogik klassifiziert werden.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
374. Agent Engineering: Graceful Degradation
Wenn ein Tool ausfällt, sollte der Agent in einen sicheren reduzierten Modus wechseln statt Ergebnisse zu erfinden.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
375. Agent Engineering: Kill Switch
Langlaufende und schreibende Agenten brauchen einen sofort wirksamen Abbruchpfad.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
376. Agent Engineering: Postmortem
Fehlgeschlagene Agentenläufe sollten als reproduzierbare Trajektorien archiviert und ausgewertet werden.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
377. Agent Engineering: Eval from Production
Reale Fehler können anonymisiert in Regressionstests überführt werden, ohne sensible Originaldaten dauerhaft zu speichern.
M3- oder M2.7-Leistung entfaltet sich erst im Harness; robuste Agentensysteme benötigen Zustandskontrolle, Berechtigungsgrenzen, Tests und Wiederherstellbarkeit.
378. Long Context: Token zählen
Vor sehr langen Requests die tatsächliche Tokenzahl mit dem passenden MiniMax-Tokenizer messen.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
379. Long Context: Bilder zählen mit
Multimodale Inputs verbrauchen modellintern Kontextbudget; Dateigröße in Bytes ist nicht gleich Tokenkosten.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
380. Long Context: Video Sampling
Videoinput kann intern Frames oder visuelle Tokens erzeugen; Auflösung und Dauer beeinflussen Kontextlast.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
381. Long Context: Tool Schemas im Kontext
Große Toolschemas reduzieren verfügbaren Raum für Nutzdaten und Konversation.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
382. Long Context: History Growth
Jeder Toolturn kann Kontext vergrößern; alte Rohdaten sollten kontrolliert verdichtet werden.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
383. Long Context: Retrieval trotz 1M
Gezieltes Retrieval kann günstiger, aktueller und leichter prüfbar sein als das Einfüllen einer Million Tokens.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
384. Long Context: Chunk Boundaries
Dokumentchunks sollten semantische Grenzen respektieren, damit Zusammenhänge nicht künstlich getrennt werden.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
385. Long Context: Citation Anchors
Gefundene Textstellen sollten mit stabilen Abschnitts- oder Seitenankern referenziert werden.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
386. Long Context: Needle Tests
Long-Context-Evaluation sollte prüfen, ob relevante Information in verschiedenen Positionen zuverlässig gefunden wird.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
387. Long Context: Distractor Tests
Zusätzliche ähnliche, aber falsche Informationen testen, ob das Modell relevante Evidenz selektieren kann.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
388. Long Context: Recency Conflict
Bei widersprüchlichen Versionen muss die neueste oder autoritative Quelle explizit priorisiert werden.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
390. Long Context: Context Poisoning
Ein einziges manipuliertes Dokument kann einen langen Kontext beeinflussen; Trust Labels helfen bei der Trennung.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
391. Long Context: Compression Loss
Automatische Zusammenfassung kann Zahlen, Negationen oder Ausnahmen verlieren.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
392. Long Context: Structured Memory
Tabellen oder Key-Value-State können bestimmte Fakten robuster erhalten als freie Zusammenfassungen.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
393. Long Context: Window Position
Wichtige Instruktionen sollten nicht nur einmal tief im Kontext stehen, sondern durch System-/Harnessregeln geschützt werden.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
394. Long Context: Long Output
Sehr lange Ausgaben brauchen Abschnittscheckpoints und Validierung, sonst akkumulieren Fehler.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
395. Long Context: Output Budget
Maximales Outputlimit getrennt von Kontextfenster und Reasoningbudget konfigurieren.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
396. Long Context: Streaming Long Output
Streaming verbessert Time-to-First-Token, löst aber nicht die Gesamtzeit langer Ausgaben.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
397. Long Context: Cache Prefix
Stabile System- und Projektdokumentation eignet sich eher für Cache-Wiederverwendung als volatile Chatteile.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
398. Long Context: Cache Invalidation
Schon kleine Änderungen im Prefix können Cache-Hits reduzieren.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
399. Long Context: Long-context Privacy
Je mehr Dokumente in einen Request gepackt werden, desto größer ist unnötige Datenexposition.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
400. Long Context: Selective Disclosure
Nur die für den konkreten Schritt benötigten Abschnitte an Modell oder Tool weitergeben.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
401. Long Context: Repository Map
Für große Codebasen kann eine symbolische Repositorykarte hilfreicher sein als vollständiger Rohcode.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
402. Long Context: Dependency Graph
Abhängigkeitsgraphen ergänzen Textkontext um strukturelle Beziehungen.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
403. Long Context: Log Sampling
Produktionslogs sollten gefiltert und redigiert werden, statt komplette Logarchive ungeprüft in 1M-Kontext zu legen.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
404. Long Context: Table Context
Tabellen müssen Header, Einheiten und Spaltenbezug erhalten; reine CSV-Ausschnitte können semantisch ambig sein.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
405. Long Context: PDF Extraction
PDF-Textreihenfolge und Tabellenextraktion vor LLM-Auswertung prüfen.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
406. Long Context: Multimodal Alignment
Bild und zugehöriger Textabschnitt müssen eindeutig gekoppelt bleiben.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
407. Long Context: Regression over Length
Ein Testset sollte identische Fragen bei 8K, 32K, 128K, 512K und 1M Kontext vergleichen.
Eine Million Tokens sind eine Kapazitätsgrenze, keine Garantie für perfekte Erinnerung, Quellenwahl oder günstige Verarbeitung.
408. Produktions-API: Request ID
Jeder API-Request sollte eine eigene Korrelations-ID in Logs besitzen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
409. Produktions-API: Timeout Budget
Connect-, Read- und Gesamt-Timeout getrennt definieren.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
410. Produktions-API: Retryable Errors
Nur temporäre Netzwerk- und 5xx-Fehler automatisch wiederholen; fachliche 4xx-Fehler zuerst korrigieren.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
411. Produktions-API: Exponential Backoff
Backoff mit Jitter verhindert synchronisierte Retry-Stürme.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
412. Produktions-API: Circuit Breaker
Bei anhaltendem Plattformfehler Requests begrenzen und kontrolliert degradieren.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
413. Produktions-API: Concurrency Pool
Parallele Agenten und Medienjobs über einen zentralen Pool begrenzen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
414. Produktions-API: Queue
Lange Video-/Audiojobs gehören in eine Jobqueue statt in synchrone Webrequests.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
415. Produktions-API: Webhook Validation
Falls Webhooks genutzt werden, Signatur und Replay-Schutz prüfen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
416. Produktions-API: Polling Budget
Asynchrone Tasks nicht sekündlich aggressiv pollen; dokumentierte Intervalle und Backoff nutzen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
417. Produktions-API: Idempotent Submit
Vor Wiederholung eines Medienjobs prüfen, ob der ursprüngliche Task bereits angelegt wurde.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
418. Produktions-API: Model Routing
Automatisches Routing muss transparent machen, welches Modell tatsächlich verwendet wurde.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
419. Produktions-API: Version Pinning
Produktive Systeme sollten kontrollierte Modellversionen statt unbemerkter Aliaswechsel verwenden, sofern verfügbar.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
420. Produktions-API: Canary
Neue Modellgeneration zuerst auf kleinem Trafficanteil gegen bestehende Produktion vergleichen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
421. Produktions-API: Shadow Test
Neue Modelle können parallel ohne Nutzerwirkung auf reale anonymisierte Requests evaluiert werden.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
422. Produktions-API: Rollback Model
Ein bekannter stabiler Modellpfad sollte als Rollback verfügbar bleiben.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
423. Produktions-API: Schema Validation
Tool- und Structured-Output-Ergebnisse vor Weiterverarbeitung maschinell validieren.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
424. Produktions-API: Semantic Validation
Syntaktisch gültiges JSON kann fachlich falsch sein; Domänenregeln zusätzlich prüfen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
425. Produktions-API: Cost Attribution
Kosten pro Nutzer, Agent, Projekt und Toolpfad getrennt messen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
426. Produktions-API: Long-context Cost
Requests oberhalb der M3-512K-Schwelle separat ausweisen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
427. Produktions-API: Media Cost
Video-, Speech-, Image- und Music-Kosten nicht in LLM-Tokens umrechnen, wenn das Preismodell anders funktioniert.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
428. Produktions-API: SLA
Verfügbarkeit, Latenz und Fehlerrate als Servicekennzahlen getrennt von Modellqualität messen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
429. Produktions-API: P95/P99
Medianlatenz verschleiert Ausreißer; P95 und P99 sind für Produktionsagenten oft wichtiger.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
430. Produktions-API: Time to First Token
TTFT und Gesamtdauer separat messen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
431. Produktions-API: Tokens per Second
Decode-Geschwindigkeit getrennt von Prefill und Toolwartezeit messen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
432. Produktions-API: Cold Start
Serverless oder autoskalierte Pfade können bei erster Anfrage zusätzliche Latenz erzeugen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
433. Produktions-API: Region Latency
Global/CN und Nutzerstandort beeinflussen Netzwerklatenz.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
434. Produktions-API: Status Page
Bei systematischen Fehlern zuerst Plattformstatus prüfen, bevor Prompts oder Code umgebaut werden.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
435. Produktions-API: Quota Monitor
Verbleibende Token-Plan-/Credit-Quoten automatisiert überwachen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
436. Produktions-API: Key Separation
Entwicklung, Test und Produktion verwenden getrennte API-Keys.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
437. Produktions-API: Secret Storage
API-Keys in Secret Manager oder geschützten Environmentvariablen statt Quellcode speichern.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
438. Produktions-API: Audit Log
Änderungen an Keys, Tarifen und Agentenberechtigungen protokollieren.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
439. Produktions-API: Data Redaction
Logs vor zentraler Speicherung um Secrets und unnötige personenbezogene Daten bereinigen.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
440. Produktions-API: Synthetic Monitoring
Regelmäßige kleine Testrequests erkennen API- oder Modellregressionen früh.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
441. Produktions-API: Golden Prompts
Ein kleines stabiles Promptset dient als täglicher Regressionstest.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
442. Produktions-API: Media Golden Set
Für Video/Audio/Bild qualitative Referenzprompts mit menschlicher Bewertung beibehalten.
Ein produktiver MiniMax-Stack ist ein verteiltes System; Zuverlässigkeit erfordert klassische API-, Queue-, Retry-, Observability- und Security-Disziplin zusätzlich zum Modell.
443. Medien-QA: Video Subject Consistency
Identität und Kleidung eines Subjekts frameübergreifend separat bewerten.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
444. Medien-QA: Video Motion Smoothness
Bewegung auf Ruckeln, Sprünge und anatomisch unplausible Zwischenzustände prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
445. Medien-QA: Video Camera Consistency
Kamerabewegung darf nicht unmotiviert Brennweite, Perspektive oder Achse wechseln.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
446. Medien-QA: Video Lighting
Lichtquelle, Schattenrichtung und Reflexionen über Frames prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
447. Medien-QA: Video Object Persistence
Objekte dürfen nicht spontan erscheinen, verschwinden oder Form ändern.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
448. Medien-QA: Video Text
Schilder, Logos und UI-Text frameweise prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
449. Medien-QA: Video Audio Sync
Ereignisse und Sprache auf Synchronität mit Bildbewegung prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
450. Medien-QA: Video Stereo
Stereo-Panorama auf unnatürliche Sprünge und Phasenprobleme prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
451. Medien-QA: Video Loopability
Für Loops ersten und letzten Frame sowie Audioübergang messen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
452. Medien-QA: Video Compression
Exportcodec kann Artefakte erzeugen, die nicht vom Modell stammen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
453. Medien-QA: Speech MOS
Natürlichkeit mit mehreren Hörern statt nur persönlichem Eindruck bewerten.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
454. Medien-QA: Speech Intelligibility
Verständlichkeit für Zahlen, Namen, URLs und Fachbegriffe separat testen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
455. Medien-QA: Speech Speaker Similarity
Bei autorisiertem Cloning Ähnlichkeit und Stabilität über mehrere Texte messen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
456. Medien-QA: Speech Emotion Consistency
Emotion darf Inhalt nicht ungewollt verfälschen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
457. Medien-QA: Speech Long-form Drift
Bei längeren Texten Lautstärke, Tempo und Stimmcharakter auf Drift prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
458. Medien-QA: Speech Breaths
Sound Tags sollten Natürlichkeit erhöhen, nicht übermäßig künstliche Atemgeräusche erzeugen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
459. Medien-QA: Speech Silence
Pausenlängen und Satzgrenzen auf Dialogtauglichkeit prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
460. Medien-QA: Speech Streaming Gaps
Chunkgrenzen dürfen keine Knackser oder Zeitlücken erzeugen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
461. Medien-QA: Music Structure
Songform auf nachvollziehbare Intro/Verse/Chorus/Bridge-Entwicklung prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
462. Medien-QA: Music Melody Repetition
Unbeabsichtigte repetitive Loops und stagnierende Melodieführung erkennen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
463. Medien-QA: Music Harmony
Harmonische Übergänge und tonale Stabilität bewerten.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
464. Medien-QA: Music Rhythm
Timing und Groove auf Drift oder ungewollte Tempoänderung prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
465. Medien-QA: Music Vocal Pronunciation
Lyrics wortweise auf Auslassungen und falsche Aussprache prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
466. Medien-QA: Music Vocal Identity
Bei generischen Stimmen unbeabsichtigte starke Ähnlichkeit zu realen Künstlern prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
467. Medien-QA: Music Instrument Separation
Dichte Arrangements auf Maskierung und undefinierte Instrumente prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
468. Medien-QA: Music Bass
Tieffrequenzbereich auf Übersteuerung und Mixmaskierung prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
469. Medien-QA: Music Loudness
Loudness normalisieren und nicht bloß subjektive Lautheit mit Qualität verwechseln.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
470. Medien-QA: Music Artifacts
Digitale Zirpen, Phasenartefakte und hochfrequente Synthesespuren markieren.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
471. Medien-QA: Image Anatomy
Hände, Gesichter, Zähne und Gelenke gezielt prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
472. Medien-QA: Image Geometry
Perspektive, Spiegelungen und räumliche Beziehungen kontrollieren.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
473. Medien-QA: Image Text
Typografie, Zahlen und Markennamen separat lesen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
474. Medien-QA: Image Color
Farben gegen Branding- oder Referenzwerte prüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
475. Medien-QA: Image Reference Fidelity
Bei I2I kontrollieren, welche Merkmale erhalten und welche verändert wurden.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
476. Medien-QA: Cross-modal Consistency
Wenn M3 Text/Bild/Video analysiert, Aussagen mit dem Originalmedium direkt gegenprüfen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
477. Medien-QA: Human Review Grid
Medienoutputs mit wiederkehrendem Bewertungsraster statt nur „gefällt/gefallt nicht“ beurteilen.
Generative Medien benötigen modality-spezifische Prüfungen; ein allgemeiner LLM-Qualitätstest erkennt viele audiovisuelle Fehler nicht.
478. Lizenz/Europa: Gewichtelizenz separat lesen
Die Lizenzdatei des konkreten Modellrepositorys ist maßgeblich und nicht die Lizenz eines SDK- oder Beispielcode-Repositories.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
479. Lizenz/Europa: M3 Community License Snapshot
M3-Lizenz mit Datum und Revision archivieren, weil kommerzielle Kennzeichnung und Umsatzbedingungen relevant sind.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
480. Lizenz/Europa: H3 Applicable Territory
H3 definiert ausdrücklich ein territoriales Lizenzgebiet.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
481. Lizenz/Europa: H3 EU Exclusion
Deutschland liegt in der ausgeschlossenen EU-Zone der pauschalen H3-Community-Lizenz.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
483. Lizenz/Europa: H3 Output Restriction
Die H3-Lizenz enthält auch Beschränkungen für Nutzung der Works und Outputs außerhalb des Applicable Territory; konkrete Anwendung rechtlich prüfen.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
484. Lizenz/Europa: H3 Model Improvement Restriction
Die H3-Lizenz begrenzt die Nutzung von H3/Outputs zur Verbesserung anderer AI-Modelle.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
485. Lizenz/Europa: H3 Notice
Distribution kann eine NOTICE-Datei und weitere Kennzeichnung verlangen.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
486. Lizenz/Europa: H3 Commercial Branding
Kommerzielle Produkte können eine sichtbare H3-Kennzeichnung benötigen.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
487. Lizenz/Europa: Music3 Branding
Music3 verlangt für kommerzielle Produkte eine sichtbare Modellkennzeichnung.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
488. Lizenz/Europa: Music3 Revenue Threshold
Bei hoher kommerzieller Umsatzschwelle wird separate Autorisierung verlangt.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
489. Lizenz/Europa: M3 Built With Notice
M3 sieht für kommerzielle Nutzung eine „Built with MiniMax M3“-Kennzeichnung vor.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
490. Lizenz/Europa: M3 Revenue Threshold
Große kommerzielle Anbieter benötigen nach Lizenztext zusätzliche Autorisierung.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
491. Lizenz/Europa: Open-source Terminologie
Bei nicht OSI-/FLOSS-typischen Bedingungen besser „Open Weights“ oder „öffentlich verfügbare Gewichte“ schreiben.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
492. Lizenz/Europa: Third-party Components
Ein Modell kann Komponenten aus Apache-/MIT-lizenzierten Projekten enthalten, ohne dass die Gesamtgewichtelizenz dadurch Apache/MIT wird.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
493. Lizenz/Europa: Qwen Component in H3
H3 nennt Qwen3-VL-32B als Encoderkomponente mit Apache-2.0-Lizenz; das ändert die H3-Gesamtlizenz nicht.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
494. Lizenz/Europa: Qwen Base in Music3
Music3 initialisiert einen Modellteil aus Qwen3.5-8B; die Music3-Gesamtgewichte haben trotzdem eigene Lizenzbedingungen.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
495. Lizenz/Europa: Output Rights versus Model License
Die Lizenz zur Nutzung des Modells beantwortet nicht automatisch Urheber-, Marken-, Persönlichkeits- oder Vertragsrechte an Outputs.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
496. Lizenz/Europa: Training Data Unknowns
Open Weights bedeuten nicht automatisch vollständige Offenlegung aller Trainingsdaten.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
497. Lizenz/Europa: Commercial API Terms
API-Nutzung unterliegt zusätzlich Plattformbedingungen und Bezahlbedingungen, unabhängig von lokalen Gewichten.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
498. Lizenz/Europa: Consumer Terms
Talkie, Hailuo oder Audio können eigene Produktbedingungen haben, die nicht aus der API-Policy abgeleitet werden dürfen.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
499. Lizenz/Europa: Jurisdiction
Bei grenzüberschreitender Nutzung sind lokale Gesetze zusätzlich zur Modelllizenz relevant.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
500. Lizenz/Europa: Archive License Text
Historische Lizenz immer mit exaktem Modellcheckpoint und Datum speichern.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
501. Lizenz/Europa: Do Not Infer
Nie eine Lizenz aus Modellname, Blogwort „open“ oder GitHub-Badge ableiten.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
502. Lizenz/Europa: Germany Practical Rule
Für Deutschland bei H3 zuerst Lizenz-/Autorisierungslage klären; erst danach Hardware- und Deploymentplanung beginnen.
Lizenzprüfung ist bei MiniMax ein technischer Betriebsparameter: verschiedene Modellfamilien können trotz gemeinsamer Marke völlig unterschiedliche Nutzungsrechte besitzen.
503. Evaluation: Eigene Aufgabenmatrix
Tests aus realen Coding-, Such-, Medien- und Dokumentaufgaben statt nur öffentlichen Benchmarks ableiten.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
504. Evaluation: Baseline behalten
Vor Modellwechsel eine stabile Baseline mit altem Modell und identischem Harness speichern.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
505. Evaluation: A/B Test
Gleiche Prompts, Tools und Daten gegen zwei Modellversionen ausführen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
506. Evaluation: Blind Review
Wenn möglich Ausgaben ohne sichtbaren Modellnamen bewerten, um Markenbias zu reduzieren.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
507. Evaluation: Repeated Runs
Probabilistische Modelle mehrfach ausführen und Varianz messen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
508. Evaluation: Pass Rate
Erfolg nach klarer fachlicher Definition zählen, nicht nach subjektivem Eindruck.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
509. Evaluation: Hallucination Rate
Falsche Fakten und erfundene Quellen als eigene Fehlerklasse zählen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
510. Evaluation: Tool Success
Toolaufrufe getrennt nach Schema, Ausführung und fachlichem Ergebnis bewerten.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
511. Evaluation: Recovery Rate
Messen, ob ein Agent nach Toolfehler oder falscher Annahme selbständig in einen korrekten Pfad zurückfindet.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
512. Evaluation: Instruction Following
System-, Nutzer-, Skill- und Toolinstruktionen auf Konfliktfälle testen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
513. Evaluation: Prompt Injection Set
Bösartige Dokument- und Webinstruktionen in ein kontrolliertes Testset aufnehmen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
514. Evaluation: Secret Exfiltration Test
Prüfen, ob ein Agent auf fremde Promptanweisung Secrets oder nicht freigegebene Dateien preisgibt.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
515. Evaluation: Long-Horizon Completion
Lange Aufgaben bis zum echten Artefaktabschluss testen, nicht nur den ersten Plan bewerten.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
516. Evaluation: Code Compile
Generierter Code muss kompilieren beziehungsweise linten.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
517. Evaluation: Code Tests
Unit-, Integration- und Regressionstests ausführen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
518. Evaluation: Code Review
Diffgröße, unnötige Änderungen und Security-Probleme messen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
519. Evaluation: Search Citation
Jede zitierte Quelle muss den konkreten Satz tatsächlich stützen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
520. Evaluation: Search Freshness
Zeitkritische Fragen gegen aktuelle Primärquellen testen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
521. Evaluation: Document Fidelity
Zusammenfassungen gegen Zahlen, Tabellen, Fußnoten und Ausnahmen im Original prüfen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
522. Evaluation: Spreadsheet Fidelity
Formeln und Zellbezüge programmgesteuert prüfen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
523. Evaluation: Slide Fidelity
Layout, Textüberlauf und editierbare Elemente visuell prüfen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
524. Evaluation: Video Human Rating
Video nach Bewegung, Identität, Prompttreue, Text und Audio getrennt bewerten.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
525. Evaluation: Speech Human Rating
Natürlichkeit, Verständlichkeit, Ähnlichkeit und Latenz getrennt messen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
526. Evaluation: Music Human Rating
Komposition, Arrangement, Gesang, Mix und Prompttreue getrennt bewerten.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
527. Evaluation: Image Human Rating
Prompttreue, Anatomie, Geometrie und Typografie getrennt bewerten.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
528. Evaluation: Latency Metric
TTFT, Gesamtdauer und Toolwartezeit getrennt reporten.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
529. Evaluation: Cost Metric
Kosten pro erfolgreicher Aufgabe statt nur Tokenpreis vergleichen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
530. Evaluation: Energy/Hardware
Bei Self-Hosting GPU-Zeit, Auslastung und Speicherbedarf mit berücksichtigen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
531. Evaluation: Context Efficiency
Messen, wie viel Kontext tatsächlich nötig ist, statt immer Maximalfenster zu verwenden.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
532. Evaluation: Cache Benefit
Identische Tests mit und ohne Cache vergleichen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
533. Evaluation: Quantization Delta
Full/BF16 gegen quantisierte Varianten auf denselben Aufgaben vergleichen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
534. Evaluation: Runtime Delta
vLLM/SGLang/Transformers bei identischem Checkpoint getrennt testen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
535. Evaluation: Region Delta
Globale Endpunkte aus relevanten Nutzerregionen auf Latenz und Verfügbarkeit prüfen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
536. Evaluation: Model Drift Watch
Golden Tests regelmäßig erneut ausführen, um Alias-/Servingänderungen zu erkennen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
537. Evaluation: Release Acceptance
Neue Modellgeneration erst nach bestandenem Regressionstest in Produktion übernehmen.
Reproduzierbare Bewertung braucht feste Aufgaben, klare Erfolgskriterien, identische Rahmenbedingungen und mehrere Durchläufe; Anbieterbenchmarks sind nur ein Teil der Evidenz.
538. Auswahlhilfe: M3 für komplexes Coding
M3 ist die naheliegende Wahl für aktuelle lange Repository-, multimodale und agentische Codingaufgaben.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
539. Auswahlhilfe: M3 für 1M-Kontext
Sehr große Dokument- oder Codekontexte sprechen für M3, sofern Kosten, Latenz und Speicher berücksichtigt werden.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
540. Auswahlhilfe: M3 ohne Thinking
Für einfache, latenzkritische Antworten kann ein deaktivierter Thinking-Modus sinnvoller sein.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
541. Auswahlhilfe: M3 adaptive Thinking
Bei gemischten Aufgaben kann adaptive Reasoningsteuerung einen Mittelweg zwischen Latenz und Tiefe bilden.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
542. Auswahlhilfe: M2.7 für bestehenden Stack
Ein stabiler produktiver M2.7-Stack kann sinnvoll bleiben, wenn Migration zu M3 keinen messbaren Vorteil bringt.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
543. Auswahlhilfe: M2-her für Roleplay
M2-her ist für lange charakterbasierte Dialoge spezialisiert und nicht primär als Codingmodell gedacht.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
544. Auswahlhilfe: H3 für audiovisuelle Videogeneration
H3 ist die aktuelle Wahl für komplexe Videoausgabe mit nativem Audio, wenn Lizenz und Region passen.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
545. Auswahlhilfe: Hailuo 2.3 für etablierte API-Pipelines
Bestehende T2V/I2V-Pipelines können Hailuo 2.3 weiterhin verwenden, wenn die spezifischen Auflösungs-/Dauerprofile passen.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
546. Auswahlhilfe: Speech 2.8 HD für Qualität
HD eignet sich für hochwertige Sprachsynthese, bei der Latenz nicht die einzige Zielgröße ist.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
547. Auswahlhilfe: Speech 2.8 Turbo für Echtzeit
Turbo ist für dialognahe beziehungsweise latenzkritische Sprachsysteme geeigneter.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
548. Auswahlhilfe: Music 3.0 für lokale Forschung
Music 3.0 eignet sich für reproduzierbare Open-Weight-Musikforschung und lokale Pipelineexperimente.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
549. Auswahlhilfe: Image-01 für Bildgenerierung
Für Text-zu-Bild-Aufgaben ist der dedizierte Bildgenerator passender als M3s Bildverständnis.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
550. Auswahlhilfe: MiniMax Code für fertigen Agentenharness
Wer nicht selbst Tools, Computer Use und Sessionlogik implementieren will, bewertet MiniMax Code als Produkt statt nur M3 als API.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
551. Auswahlhilfe: API für eigene Produkte
Die API ist der klarere Weg für kontrollierte Integration, Logging, eigene UI und serverseitige Rechteprüfung.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
552. Auswahlhilfe: lokal für Datenkontrolle
Self-Hosting kann sensible Datenpfade reduzieren, sofern sämtliche Zusatzdienste ebenfalls lokal kontrolliert werden.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
553. Auswahlhilfe: kein H3-Gewicht in Deutschland ohne Lizenzprüfung
Aufgrund der H3-Territorialklausel ist eine lokale Nutzung der öffentlichen Gewichte in Deutschland nicht einfach aus dem Download ableitbar.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
554. Auswahlhilfe: Pay-as-you-go für Produktion
Produktive Systeme sollten die für Produktion vorgesehenen API-Abrechnungs- und Rate-Limit-Pfade nutzen.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
555. Auswahlhilfe: Token Plan für interaktive Nutzung
Token Plan ist auf interaktive Entwicklerarbeit und Agentennutzung mit Quoten ausgerichtet.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
556. Auswahlhilfe: MCP nur mit klarer Vertrauenskette
MCP ist sinnvoll, wenn Server, Berechtigungen und Toolresultate kontrollierbar sind.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
557. Auswahlhilfe: kein Modell nur nach Benchmark auswählen
Praxisleistung hängt von Agentenharness, Latenz, Tooltreue, Kontext und Kosten ebenso ab wie von Benchmarkwerten.
Die richtige MiniMax-Komponente ergibt sich aus Aufgabe, Modalität, Lizenz, Deployment, Latenz, Kosten, Datenklasse und benötigten Aktionen.
558. Problemhilfe: Modellname wird abgelehnt
Prüfen, ob der verwendete Endpunkt M3, M2.7, Speech, Hailuo, H3 oder ein anderes Modell tatsächlich unterstützt; API-Referenz und Region vergleichen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
559. Problemhilfe: M3 liefert 400 bei langem Kontext
Eingabetokens inklusive Bilder/Videos und Toolschemas messen; Grenzen des gewählten Endpunkts und Long-Context-Billing beachten.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
560. Problemhilfe: M3 antwortet zu langsam
Thinking-Modus, Kontextgröße, Service Tier, Cache und Toolschleifen prüfen; große Prefill-Kosten separat messen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
561. Problemhilfe: M3 denkt bei einfacher Aufgabe zu lange
Thinking auf adaptive oder disabled stellen und prüfen, ob der Harness Reasoning unnötig erzwingt.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
562. Problemhilfe: M3 bleibt oberflächlich
Bei komplexer Aufgabe Thinking enabled/adaptive und klarere Ziel-/Prüfkriterien verwenden; Tools und Quellenzugriff kontrollieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
563. Problemhilfe: M3 Tool Call ungültig
JSON-Schema, erforderliche Felder, Typen und Parserkompatibilität prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
564. Problemhilfe: M3 wiederholt Tool Calls
Loop Detection, Toolresultat-Semantik und Stopbedingungen im Harness prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
565. Problemhilfe: M3 vergisst vorherigen Toolschritt
Interleaved Thinking und Conversation-State zwischen Requests vollständig erhalten.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
566. Problemhilfe: M3 sieht Bild nicht
Multimodales Messageformat, MIME-Typ, Dateizugriff und Processorunterstützung prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
567. Problemhilfe: M3 sieht Video nicht
Endpunkt, Videoinputformat, Dateigröße und unterstützte Multimodalität des konkreten SDKs prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
568. Problemhilfe: M3 kann Datei nicht öffnen
Dateizugriff ist Harness-/Produktfunktion; Modellinput und lokale Dateiberechtigung getrennt prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
569. Problemhilfe: M3 verändert falsche Datei
Arbeitsverzeichnis, Pfadgrenzen, Änderungsplan und Freigabeschritt vor Schreibzugriff einführen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
570. Problemhilfe: M3 löscht Dateien
Destruktive Tools blockieren oder Bestätigungspflicht und Backup aktivieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
571. Problemhilfe: M3 installiert falsches Paket
Dependency-Whitelist, Lockfile und Paketquellen kontrollieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
572. Problemhilfe: M3 committed Secret
Pre-commit Secret Scan, reduzierte Umgebungsvariablen und isolierte Credentials verwenden.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
573. Problemhilfe: M3 arbeitet auf falschem Branch
Branch explizit anlegen, Status vor jedem Commit prüfen und Pushrechte begrenzen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
574. Problemhilfe: M3 Test besteht lokal, CI scheitert
Runtime-, OS-, Abhängigkeits- und Environmentunterschiede reproduzieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
575. Problemhilfe: M3 erzeugt falschen Patch
Tests, Diff-Review und minimale Änderungsgrenze erzwingen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
576. Problemhilfe: M3 Kontext kostet unerwartet viel
Inputbereich über 512K, Cache-Hits, Multimodalinput und wiederholte vollständige History prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
577. Problemhilfe: Cache Read bleibt niedrig
Identischen unveränderten Prefix und Cachemechanik des Endpunkts prüfen; dynamische Systemteile können Cache zerstören.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
578. Problemhilfe: Priority bringt keine Qualitätssteigerung
Priority steuert Servingpriorität/Latenz und nicht Modellintelligenz.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
579. Problemhilfe: 429 Rate Limit
RPM/TPM, parallele Agenten und Retry-Backoff prüfen; Token Plan und Pay-as-you-go können andere Limits besitzen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
580. Problemhilfe: 401 API Key
Key-Typ, Header, Region, Ablauf und Produktpfad prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
581. Problemhilfe: 403 trotz gültigem Key
Berechtigung, Kontostatus, regionalen Zugriff und produktspezifische Freischaltung prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
582. Problemhilfe: Anthropic SDK funktioniert nicht
Base URL, API-Key-Variable, Modellname und unterstützte Messages-Features prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
583. Problemhilfe: OpenAI SDK funktioniert nicht
Base URL auf MiniMax setzen und inkompatible OpenAI-spezifische Parameter entfernen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
584. Problemhilfe: Thinking Block fehlt
Prüfen, ob gewählter Endpoint/SDK Reasoningblöcke weiterreicht oder wegtransformiert.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
585. Problemhilfe: Thinking wird doppelt gesendet
Harness darf alte Reasoninginhalte nicht als neuen Benutzertext zurückspiegeln.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
586. Problemhilfe: Toolresultat wird als Promptanweisung behandelt
Toolresultate strukturiert kapseln und nicht vertrauenswürdigen Inhalt von Systeminstruktionen trennen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
587. Problemhilfe: Agent hängt stundenlang
Zeit-, Tool-, Token- und Kostenbudgets sowie Checkpoints festlegen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
588. Problemhilfe: Agent Teams widersprechen sich
Rollen, Zuständigkeiten, Entscheidungsregel und gemeinsame Faktenbasis explizit definieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
589. Problemhilfe: Unteragent sieht zu viele Daten
Berechtigungen pro Agent statt globaler Vererbung definieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
590. Problemhilfe: Memory enthält falsche Information
Memory-Einträge versionieren, Quellen angeben und korrigier-/löschbar halten.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
591. Problemhilfe: Skill wird ignoriert
Skillversion, Einbindung, Kontextposition und Konflikte mit Systemregeln prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
592. Problemhilfe: Skill ist zu lang
Relevante Teile dynamisch laden statt alle Skills in jeden Request zu packen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
593. Problemhilfe: MCP verbindet nicht
Serverprozess, Transport, Authentisierung, Schema und Netzwerkregeln prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
594. Problemhilfe: MCP Tool erscheint nicht
Capabilities-Handschlag und Toolregistrierung im Client prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
595. Problemhilfe: MCP liefert Prompt Injection
MCP-Rückgaben als untrusted Data behandeln und Aktionsebene separat genehmigen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
596. Problemhilfe: CLI nutzt falsche Region
MINIMAX_REGION beziehungsweise lokale CLI-Konfiguration kontrollieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
597. Problemhilfe: CLI findet Credentials nicht
OAuth/API-Key-Priorität und MMX_CONFIG_DIR prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
598. Problemhilfe: lokales M3 OOM
Quantisierung, Tensor-/Expert-Parallelism, Kontextfenster, KV-Cache und Batchgröße reduzieren beziehungsweise Hardware erweitern.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
599. Problemhilfe: lokales M3 sehr langsam
Quantisierungskernel, Interconnect, Expertverteilung, Prefillgröße und Runtimeprofil prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
600. Problemhilfe: M3 Quantisierung verschlechtert Tool Use
Quantisierungsgrad und wichtige Projektionen testen; Toolbenchmarks separat vom normalen Chat messen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
601. Problemhilfe: M3 lädt falsche Revision
Hugging-Face-/Git-Revision pinnen und Cacheverzeichnis kontrollieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
602. Problemhilfe: Transformers verlangt trust_remote_code
Nur vertrauenswürdige Revision ausführen und Code vor produktiver Nutzung prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
603. Problemhilfe: Tokenizer passt nicht
Tokenizer und Modellrevision gemeinsam aktualisieren beziehungsweise zurückrollen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
604. Problemhilfe: Chattemplate falsch
Offizielles Template oder Modellprozessor verwenden und nicht fremde Llama-/Qwen-Templates übernehmen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
605. Problemhilfe: H3 lässt sich in Deutschland lizenzrechtlich nicht einordnen
Öffentliche H3-Community-Lizenz beachten: EU ist aus dem pauschalen Applicable Territory ausgeschlossen; vor Nutzung separate Autorisierung beziehungsweise Rechtsprüfung einholen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
606. Problemhilfe: H3 Download funktioniert, Nutzung trotzdem unklar
Technische Verfügbarkeit der Gewichte ist keine Lizenzgewährung; Lizenztext und Anwendungsort entscheiden.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
607. Problemhilfe: H3 lokaler Start OOM
Modellkomponenten, VAE, Encoder, Auflösung und Framezahl reduzieren beziehungsweise Multi-GPU-/Offloadstrategie verwenden.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
608. Problemhilfe: H3 Video flackert
Referenzkonsistenz, Promptkomplexität, Bewegung, Sampling und Nachbearbeitung prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
609. Problemhilfe: H3 Audio passt nicht zum Bild
Audio-/Video-Konditionierung und Promptstruktur vereinfachen; Lippen-/Ereignissynchronität separat prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
610. Problemhilfe: H3 Text im Bild falsch
Generierten Text nicht ungeprüft übernehmen; gegebenenfalls Text später typografisch compositen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
611. Problemhilfe: H3 Identität driftet
Referenzmaterial, Shotlänge und Bewegungsanforderung reduzieren beziehungsweise Clips segmentieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
612. Problemhilfe: Hailuo 2.3 Task bleibt processing
Pollingintervall, Plattformstatus, Joblimit und Inputmoderation prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
613. Problemhilfe: Hailuo task_id verloren
Task-IDs persistent mit Prompt, Modell und Zeitstempel protokollieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
614. Problemhilfe: Hailuo file_id abgelaufen
Ergebnis nach erfolgreichem Job zeitnah archivieren; temporäre Abrufregeln beachten.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
615. Problemhilfe: Hailuo 1080p 10s nicht verfügbar
Modellspezifische Kombination aus Auflösung und Dauer prüfen; 1080p kann kürzer begrenzt sein.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
616. Problemhilfe: Hailuo Fast akzeptiert Text-only nicht
Fast-Modellpfad ist primär Image-to-Video; richtigen Modelltyp wählen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
617. Problemhilfe: Start-/End-Frame kollidieren
Zu große geometrische Differenz zwischen Frames vermeiden und Übergang vereinfachen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
618. Problemhilfe: Video Prompt wird blockiert
Moderationsgrund, Referenzmaterial und möglicherweise geschützte Identitäten/Marken prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
619. Problemhilfe: Speech klingt zu synthetisch
HD-Modell, natürliche Interpunktion, Sound Tags und passende Stimme testen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
620. Problemhilfe: Speech ist zu langsam
Turbo, Streaming, kürzere Chunks und regionale Netzwerkpfade prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
621. Problemhilfe: Speech Name falsch ausgesprochen
Aussprachehilfen, alternative Schreibweise oder Phonetik testen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
622. Problemhilfe: Speech Code-Switching klingt unnatürlich
Sprachsegmente und Stimm-/Dialektkompatibilität testen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
623. Problemhilfe: Voice Clone ähnelt Referenz nicht
Sauberes Referenzaudio ohne Musik, Hall und mehrere Sprecher verwenden.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
624. Problemhilfe: Voice Clone zu ähnlich zu realer Person
Rechte, Einwilligung und Missbrauchsrisiko prüfen; gegebenenfalls Voice Design statt Clone verwenden.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
625. Problemhilfe: temporäre Stimme verschwindet
Die dokumentierte Persistenzlogik beachten und Stimme innerhalb des vorgesehenen Zeitfensters tatsächlich synthetisch verwenden.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
626. Problemhilfe: WAV im Streaming fehlt
WAV ist im dokumentierten Pfad nicht für alle Streamingmodi vorgesehen; PCM oder anderes Streamingformat nutzen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
627. Problemhilfe: TTS Lautstärke clippt
Synthesepegel reduzieren und nachgelagerte Loudness-Normalisierung einsetzen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
628. Problemhilfe: Music 3.0 ignoriert Songstruktur
Section Tags und Structured Caption klarer und weniger widersprüchlich formulieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
629. Problemhilfe: Music 3.0 Gesang undeutlich
Lyrics, Sprache, Tempo und Arrangementkomplexität anpassen; problematische Stellen segmentiert testen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
630. Problemhilfe: Music 3.0 Instrument verschwindet
Instrumentrollen über Abschnitte explizit beschreiben statt nur global im Prompt zu nennen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
631. Problemhilfe: Music 3.0 lokal OOM
Global-/Local-LM, Flow-Komponenten und VAE-Speicherprofil getrennt optimieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
632. Problemhilfe: Music 3.0 kommerziell unklar
Community License und Umsatz-/Kennzeichnungsbedingungen prüfen; Modellzugang ist keine pauschale kommerzielle Freigabe.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
633. Problemhilfe: Music nicht mehr im Token Plan
Seit 20. August 2026 sind Music-Modelle laut Plan-Hinweis aus diesem Abonnement entfernt; API/Audio/Open-Weight-Zugang separat nutzen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
634. Problemhilfe: Image-01 Prompt falsch umgesetzt
Prompt priorisieren, widersprüchliche Stil-/Objektangaben reduzieren und mehrere Kandidaten erzeugen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
635. Problemhilfe: Bildtext falsch
Text nachträglich setzen oder gezielte Iteration verwenden; generative Typografie bleibt fehleranfällig.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
636. Problemhilfe: Bildreferenz verletzt Rechte
Quelle und Nutzungsrecht des Referenzbildes vor Upload und Veröffentlichung klären.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
637. Problemhilfe: File Upload abgelehnt
Dateiformat, 512MB-Dokumentlimit und API-Zweck prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
638. Problemhilfe: File Capacity erreicht
Gesamtspeicher verwalten und alte Dateien löschen; dokumentierte Kapazität kann kontobezogen sein.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
639. Problemhilfe: Video Download URL abgelaufen
Ergebnisse unmittelbar nach Jobabschluss in eigenes Archiv übernehmen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
640. Problemhilfe: API Modell wechselt Verhalten
Modell-ID, Release Notes, SDK und Systemprompt-Snapshot vergleichen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
641. Problemhilfe: Legacy M2.x verhält sich anders als M3
Architektur, Thinkingmodus, Kontext und Toolformat unterscheiden; Migration als neue Integration testen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
642. Problemhilfe: Benchmark gut, Praxis schlecht
Scaffold, Datenzugriff, Toolset, Latenz und tatsächliche Arbeitsaufgaben mit eigenem Evalset messen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
643. Problemhilfe: Agent erfindet Quelle
Web-/Retrievalresultate direkt prüfen und Zitattext gegen Originalquelle verifizieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
644. Problemhilfe: Agent nutzt veraltete Webseite
Zeitstempel und Aktualität der Quelle prüfen; Cache beziehungsweise Suchindex kann alt sein.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
645. Problemhilfe: Agent verarbeitet geheime Datei
Dateizugriff auf notwendige Ordner beschränken und sensible Daten vor Übergabe redigieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
646. Problemhilfe: Agent sendet Daten trotz lokalem Modell
MCP, Websuche, Telemetrie, Paketmanager und UI-Komponenten auf Netzwerkverkehr prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
647. Problemhilfe: Output klingt sicher, ist aber falsch
Flüssigkeit ist keine Verifikation; Fakten, Berechnungen und Handlungen separat prüfen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
648. Problemhilfe: Mathematikbeweis wirkt überzeugend
Formale oder unabhängige Verifikation verwenden; MaxProof-Ergebnisse nicht als allgemeine Fehlerfreiheit interpretieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
649. Problemhilfe: medizinische Aussage erscheint sicher
Keine medizinische Entscheidung allein auf Modelltext stützen; fachliche Primärquelle beziehungsweise Fachperson heranziehen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
650. Problemhilfe: Rechtsfrist wird genannt
Rechtsgebiet, Stichtag und Primärquelle prüfen; Modellwissen kann veraltet oder falsch sein.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
651. Problemhilfe: Finanzmodell wirkt plausibel
Datenquellen, Formeln, Einheiten, Annahmen und Sensitivitäten manuell beziehungsweise programmatisch validieren.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
652. Problemhilfe: Produktname Hailuo wird als Modellname verwendet
Produktoberfläche und konkrete Modell-ID wie Hailuo 2.3 oder H3 auseinanderhalten.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
653. Problemhilfe: Mavis und MiniMax Code werden verwechselt
Historischen Produktstand und aktuellen M3-Produktpfad anhand des Datums unterscheiden.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
654. Problemhilfe: Open Weight wird als Open Source bezeichnet
Lizenzdatei des konkreten Checkpoints prüfen; M3, H3 und Music3 haben jeweils eigene Community-Lizenzen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
655. Problemhilfe: H3 GitHub zeigt Apache-2.0
Code-Repository-Lizenz nicht mit Modellgewichtelizenz verwechseln; Hugging-Face-Gewichte stehen unter der H3 Community License.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
656. Problemhilfe: M3 ist „nur 23B“
23B beschreibt aktive Parameter, nicht Gesamtgröße und nicht Gewichtsspeicher.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
657. Problemhilfe: M2.1 ist „nur 10B“
10B aktive Parameter sind nicht die gesamte 230B-MoE-Kapazität.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
658. Problemhilfe: 1M Kontext ist Memory
Kontext ist Request-/Conversation-Arbeitsraum und kein dauerhaftes Nutzerprofil.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
659. Problemhilfe: Token Plan ist Produktions-SLA
Interaktive Abonnements und produktive Pay-as-you-go-/Enterprise-Servingpfade getrennt bewerten.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
660. Problemhilfe: Priority macht Antworten richtiger
Priority verändert Scheduling und Latenz, nicht das trainierte Wissen.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
661. Problemhilfe: API-kompatibel bedeutet identisch
OpenAI-/Anthropic-Kompatibilität betrifft Aufrufformate; Tools, Thinking und Limits bleiben anbieterabhängig.
Fehler zuerst nach Schicht isolieren: Modell, API, Netzwerk, Authentisierung, Dateizugriff, Tool-Harness, Lizenz oder Produktoberfläche. Erst danach Parameter ändern.
662. Mythos: MiniMax ist nur ein chinesischer Chatbot
MiniMax betreibt 2026 einen breiten Stack aus LLMs, Video, Audio, Musik, Bild, Agenten und Entwicklerplattform.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
663. Mythos: M3 ist dasselbe wie MiniMax Code
M3 ist das Foundation-Modell; MiniMax Code ist ein Agenten-/Codingprodukt darüber.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
664. Mythos: H3 ist M3 mit Videofunktion
H3 ist ein eigener omni-modaler Generationsmodellpfad mit eigener Architektur und Lizenz.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
665. Mythos: Hailuo ist der Modellname von H3
Hailuo ist eine Video-Produktoberfläche; H3 und Hailuo 2.3 sind konkrete Modellpfade.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
666. Mythos: Open Weights bedeutet Apache 2.0
M3, H3 und Music3 verwenden jeweils eigene MiniMax-Community-Lizenzen.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
667. Mythos: H3 ist in Deutschland frei lokal nutzbar, weil die Gewichte online sind
Die H3-Lizenz schließt die EU aus dem pauschalen Applicable Territory aus.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
668. Mythos: GitHub Apache-2.0 gilt automatisch für H3-Gewichte
Code- und Gewichtelizenz können verschieden sein.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
669. Mythos: M3 hat nur 23B Parameter
23B ist die aktive MoE-Größe; insgesamt sind es ungefähr 428B.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
670. Mythos: M2.1 hat nur 10B Parameter
M2.1 besitzt ungefähr 230B Gesamtparameter und rund 10B aktive Parameter.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
671. Mythos: MoE braucht nur Speicher für aktive Parameter
Alle beziehungsweise große Teile der Gewichte müssen für Routing/Serving verfügbar sein.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
672. Mythos: 1M Kontext ist permanentes Gedächtnis
Kontextfenster und persistente Memory-Schicht sind getrennte Systeme.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
673. Mythos: 4M Kontext von Text-01 bedeutet, dass jede heutige MiniMax-API 4M kann
Kontextgrenzen sind modell- und endpunktspezifisch.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
674. Mythos: Thinking enabled ist immer besser
Zusätzliches Reasoning kann Latenz, Kosten und unnötige Komplexität erhöhen.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
675. Mythos: Thinking disabled macht M3 zu einem anderen Modell
Es ist ein Betriebsmodus desselben Modellpfads.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
676. Mythos: Priority Tier macht M3 intelligenter
Priority betrifft Servingpriorität und Latenz.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
677. Mythos: OpenAI-kompatible API ist OpenAI
Es handelt sich um MiniMax-Modelle hinter einem kompatiblen Aufrufformat.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
678. Mythos: Anthropic SDK bedeutet Claude-Modell
Der SDK kann gegen einen MiniMax-Endpunkt sprechen.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
679. Mythos: MCP ist Teil des Foundation-Modells
MCP ist eine externe Tool- und Integrationsschicht.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
680. Mythos: MiniMax Agent und Mavis sind separate Foundation-Modelle
Beides sind Produkt-/Agentenharness-Bezeichnungen.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
681. Mythos: MiniMax Code ist nur ein Codegenerator
Der M3-Produktpfad umfasst agentische Repo-, Datei- und Computerarbeit.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
682. Mythos: H3 erzeugt nur stumme Videos
H3 kann nativ synchronisiertes Stereo-Audio erzeugen.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
683. Mythos: H3 kann beliebig lange Filme in einem Durchlauf generieren
Der veröffentlichte direkte Generationspfad ist auf kurze Clips bis etwa 15 Sekunden ausgelegt.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
684. Mythos: Hailuo 2.3 Fast kann alles, was 2.3 kann
Fast hat einen engeren, auf Effizienz optimierten Funktionspfad.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
685. Mythos: 1080p bedeutet automatisch bessere Bewegung
Auflösung und Bewegungs-/Identitätskonsistenz sind getrennte Qualitätsdimensionen.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
686. Mythos: Video-Physik ist garantiert korrekt
Generative Modelle simulieren plausible Bildfolgen und liefern keine physikalische Garantie.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
687. Mythos: Speech 2.8 ist Spracherkennung
Speech 2.8 ist primär TTS/Voice-Synthese; ASR und Dialoglogik sind getrennte Komponenten.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
688. Mythos: Voice Clone gibt Nutzungsrechte an einer Stimme
Technische Klonbarkeit ersetzt keine Einwilligung oder Rechteklärung.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
689. Mythos: Music 3.0 ist nur Text-to-Speech mit Melodie
Music 3.0 besitzt eine eigene Musikmodell- und Audiosynthesearchitektur.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
690. Mythos: Music 3.0 basiert vollständig auf Qwen3.5-8B
Nur der globale LM-Pfad wird daraus initialisiert; das Gesamtsystem enthält weitere trainierte Komponenten.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
691. Mythos: Music3 Community License ist Standard-MIT
Es ist eine eigene Lizenz mit Bedingungen.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
692. Mythos: Music ist veraltet, weil es aus Token Plan entfernt wurde
Music 3.0 erschien im August 2026; nur ein bestimmter Abonnementzugang wurde geändert.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
693. Mythos: Image-01 und M3 Vision sind dasselbe
Image-01 erzeugt Bilder; M3 versteht Bilder als Input.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
694. Mythos: Talkie ist das allgemeine MiniMax-Modell
Talkie ist ein AI-natives Endnutzerprodukt mit eigener Interaktionslogik.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
695. Mythos: Self-Hosting ist automatisch privat
Zusatztools, Logs, Telemetrie und Netzwerkausgänge können weiterhin Daten übertragen.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
696. Mythos: lokal ist automatisch sicher
Lokaler Betrieb verlagert Patch-, Berechtigungs-, Moderations- und Supply-Chain-Verantwortung auf den Betreiber.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
697. Mythos: lange Kontexte machen RAG überflüssig
Retrieval kann Quellenwahl, Kosten und Aktualität verbessern, auch wenn das Modell sehr lange Kontexte unterstützt.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
698. Mythos: ein Benchmark beweist Produktionsqualität
Benchmarks decken nur bestimmte Aufgaben, Scaffolds und Bewertungsregeln ab.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
699. Mythos: Agent Teams sind immer besser als ein Agent
Koordination erzeugt zusätzliche Kosten, Konflikte und Fehlerpfade.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
700. Mythos: mehr Tools bedeuten automatisch bessere Antworten
Jedes Tool erweitert Fähigkeiten und Angriffsfläche zugleich.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
701. Mythos: M2 ist durch M3 technisch wertlos
Legacy-Modelle können in stabilen, kostensensitiven oder reproduzierbaren Stacks weiterhin sinnvoll sein.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
702. Mythos: M2-her ist ein Nachfolger von M2.7
M2-her ist ein spezialisierter Roleplay-/Dialogpfad.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
703. Mythos: Self-Evolution bedeutet, dass M2.7 sich ohne Menschen neu trainiert
Die beschriebenen Prozesse laufen in kontrollierten Forschungs-/Harnesszyklen unter menschlicher Rahmensetzung.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
704. Mythos: MaxProof macht M3 mathematisch fehlerfrei
MaxProof ist ein Test-Time-System; Ergebnisse brauchen weiterhin Verifikation.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
705. Mythos: ein API-Key reicht für jedes MiniMax-Angebot
Pay-as-you-go-Keys und Token-Plan-Keys haben unterschiedliche Funktionen und Quoten.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
706. Mythos: Global Domain garantiert EU-Datenhaltung
Domain und Datenresidenz sind unterschiedliche Eigenschaften.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
707. Mythos: ein öffentliches Modellrepo beweist FLOSS
Lizenzbedingungen müssen separat geprüft werden.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
708. Mythos: Lizenz gilt für immer unverändert
Revisions- und Lizenzsnapshot gehören zur Archivierung.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
709. Mythos: M3 kann Desktop bedienen, also darf es jede lokale App verändern
Computer Use unterliegt den Rechten des Harnesses und braucht Least Privilege.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
710. Mythos: Agentenfehler erkennt das Modell zuverlässig selbst
Selbstkritik hilft, ersetzt aber keine externe Tests, Logs und Freigaben.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
711. Mythos: ein schöner generierter Song ist rechtlich automatisch frei nutzbar
Inputrechte, Modelllizenz und Outputrechte sind getrennt zu prüfen.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
712. Mythos: eine perfekte geklonte Stimme beweist Identität
Stimmähnlichkeit ist kein Identitätsnachweis und kann für Täuschung missbraucht werden.
Die belastbare Einordnung folgt aus konkreter Modellkarte, Lizenz, API-Dokumentation und Produktstand statt aus Markenassoziationen.
713. Archivierung: Unternehmensstart
Operativen Start Anfang 2022 und gesellschaftsrechtliche Vorläufer getrennt dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
714. Archivierung: Realtime API 2024
API-Schema, Protokoll, unterstützte Modalitäten und damalige Modelle sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
715. Archivierung: MiniMax-01
Text-01/VL-01-Checkpoint, Modellkarte, Lightning-Attention-Code und Lizenz archivieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
716. Archivierung: Image-01
Modellname, API-Parameter, Promptbeispiele und Ausgabeformate dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
717. Archivierung: M1
Checkpoint, 1M-Kontextkonfiguration, Reasoninglimit, Lizenz und Runtime sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
718. Archivierung: Hailuo 02
Auflösung, Dauer, Start-/End-Frame-Funktionen und API-Schema sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
719. Archivierung: M2
Gewichte, Tool-Calling-Guide, Samplingparameter und Interleaved-Thinking-Verhalten sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
720. Archivierung: Hailuo 2.3
Standard/Fast, T2V/I2V-Fähigkeit, Auflösungen und Preis-/API-Snapshot sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
721. Archivierung: Music 2.0
Produktbeschreibung und APIparameter als historischen Musikstand sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
722. Archivierung: M2.1
Checkpoint, 230B/10B-Spezifikation, Agentbenchmarks und Trainingserläuterungen sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
723. Archivierung: Speech 2.8
HD/Turbo-Modellnamen, Sprachen, Sound Tags, Voice-Cloning-Parameter und APIrevision sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
724. Archivierung: M2-her
Modellkarte und Rolle in Talkie/Xingye getrennt von M2.x-Productivity-Modellen sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
725. Archivierung: M2.5
Release, Benchmark-/RL-Dokumentation und API-ID sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
726. Archivierung: Forge
Frameworkbeschreibung und Verhältnis zu Agenten-/Trainingsebenen dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
727. Archivierung: M2.7
Release, Skills/Agent-Teams-Snapshot und Self-Evolution-Dokumentation sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
728. Archivierung: Mavis
Produktoberfläche, Agent-Team-Funktionen und damalige Tarife dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
729. Archivierung: M3
Gewichte, MiniMax Community License, Modellkarte, MSA-Code, Processor und API-ID sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
730. Archivierung: M3 License
Exakten Lizenztext zusammen mit Checkpointrevision archivieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
731. Archivierung: M3 API
Thinkingmodus, Service Tier, Long-Context-Preise, Cache und Toolformat dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
732. Archivierung: M3 Runtime
vLLM/SGLang/Transformers-Version, Treiber, Quantisierung und Hardware sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
733. Archivierung: MiniMax Code
Harnessversion, freigegebene Tools, Computer-Use-Rechte und Sessionpfad dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
734. Archivierung: MaxProof
Frameworkbeschreibung, Modellversion, Verifier und Test-Time-Suchparameter sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
735. Archivierung: H3
Gewichte, 2K/15s-Fähigkeiten, Architekturkomponenten und Runtime sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
736. Archivierung: H3 License
Territorialklausel und exakten Lizenzstand vom August 2026 archivieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
737. Archivierung: H3 API
Gehosteten Endpunkt getrennt vom lokalen Gewichtemodell dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
738. Archivierung: Music 3.0
Gewichte, Community License, Architektur und Inferenzcode sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
739. Archivierung: Music Token Plan
Hinweis auf Entfernung der Music-Modelle aus Token Plan ab 20.08.2026 sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
740. Archivierung: Speech Voices
Systemvoice-ID, Clone-ID, Sprache, Emotion, Speed/Pitch und Audioformat dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
741. Archivierung: Video Prompt
Prompt, Referenzframes, Modell, Auflösung, Dauer und Ergebnisdatei gemeinsam archivieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
742. Archivierung: Music Prompt
Structured Caption, Lyrics, Section Tags, Modellrevision und Output zusammen sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
743. Archivierung: Bildprompt
Prompt, Referenzbild, Modell-ID und Nachbearbeitung dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
744. Archivierung: API-Key-Typ
Nur Typ und Konfiguration dokumentieren, niemals den geheimen Key selbst archivieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
745. Archivierung: Region
Global/CN-Region und Base URL im technischen Protokoll festhalten.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
746. Archivierung: Tarif
Token Plan, Credits oder Pay-as-you-go als Betriebsumgebung notieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
747. Archivierung: Rate Limits
Kontolimits und Concurrency zum Testzeitpunkt protokollieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
748. Archivierung: Cache
Cache-Hit-Status und wiederverwendeten Prefix dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
749. Archivierung: Tool Schema
Exakte Tooldefinition und Version des MCP-/Funktionsservers sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
750. Archivierung: Agent Skill
Skilltext beziehungsweise Skillrevision und Reihenfolge archivieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
751. Archivierung: Memory
Persistente Memory-Einträge separat und datenschutzgerecht versionieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
752. Archivierung: System Prompt
Systeminstruktion als Teil des reproduzierbaren Produkttests sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
753. Archivierung: Conversation
Nur erforderliche, anonymisierte Testkonversationen archivieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
754. Archivierung: Privacy Policy
Datenschutzpolicy vom 30.03.2026 beziehungsweise späteren konkreten Teststand sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
755. Archivierung: Terms
Nutzungsbedingungen mit Datum archivieren, besonders bei Medien- und Agentenprodukten.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
756. Archivierung: Pricing
Preise nur als datierten Snapshot speichern, nicht als dauerhafte Eigenschaft behandeln.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
757. Archivierung: Hardware
GPU-Modell, Anzahl, RAM/VRAM, Interconnect und Treiber dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
758. Archivierung: Container
Image-Digest statt nur Container-Tag sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
759. Archivierung: Python Environment
Lockfile beziehungsweise vollständige Paketversionen sichern.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
760. Archivierung: Quantisierung
Algorithmus, Bitbreite, Kalibrierung und Quellcheckpoint dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
761. Archivierung: Benchmark
Promptset, Seeds, Grader und Wiederholungszahl dokumentieren.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
762. Archivierung: Output Hash
Erzeugte Artefakte mit SHA-256 versehen, wenn bytegenaue Reproduktion wichtig ist.
Ein historischer AI-Test ist erst reproduzierbar, wenn Modellartefakt, Lizenz, Runtime, Prompt, Tools, Produktpfad und Ergebnis gemeinsam datiert erhalten bleiben.
763. Vergleich mit OpenAI / ChatGPT
MiniMax kombiniert offene beziehungsweise öffentlich verfügbare Gewichte mit eigenen Medienmodellen und Agentenprodukten; ChatGPT ist stärker als einheitliche proprietäre Consumer-/Business-Oberfläche organisiert.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
764. Vergleich mit Anthropic / Claude
MiniMax unterstützt Anthropic-kompatible APIs und Agentenworkflows, bleibt aber eine eigene Modellfamilie mit eigenem Multimodal-/Medienstapel.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
765. Vergleich mit Google Gemini
Beide Ökosysteme verbinden sehr lange Kontexte und Multimodalität; MiniMax ergänzt dies durch offen bereitgestellte große Modelle und eigene Video-/Audio-/Musikfamilien.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
766. Vergleich mit Mistral AI
Beide Anbieter kombinieren Open Weights und Agenten; MiniMax besitzt eine besonders breite Mediengenerationslinie, während Mistral stärker europäische Sovereignty-/Enterprise-Pfade betont.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
767. Vergleich mit Z.ai / GLM
GLM und MiniMax sind breite chinesische Modellökosysteme mit Coding und Agenten; MiniMax differenziert sich besonders durch H3, Speech und Music.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
768. Vergleich mit Qwen
Qwen besitzt ein außergewöhnlich breites Open-Weight-Ökosystem; MiniMax koppelt eigene Frontier-LLMs enger mit Mediengeneration und Agentenprodukten.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
769. Vergleich mit DeepSeek
DeepSeek fokussiert stark auf effiziente LLM-/Reasoningarchitekturen; MiniMax baut zusätzlich eigenständige Video-, Audio- und Musikmodelle.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
770. Vergleich mit Cohere
Cohere fokussiert Enterprise Retrieval, RAG und private Deployments; MiniMax legt stärkeren Schwerpunkt auf multimodale Kreativ- und Agentensysteme.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
771. Vergleich mit Perplexity
Perplexity ist primär Search-/Answer-/Agentenprodukt; MiniMax entwickelt die zugrunde liegenden Foundation- und Medienmodelle selbst.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
772. Vergleich mit Meta / Llama
Meta stellt offene LLMs in ein großes Social-Ökosystem; MiniMax betreibt eigene spezialisierte Kreativmodelle und Produkte wie Hailuo/Talkie.
Vergleiche sollten konkrete Modellversion, Produktpfad, Lizenz, Modalität und Stichtag benennen; Markenvergleiche allein sind technisch zu grob.
773. Wohin MiniMax 2026 zeigt
Die Entwicklung verläuft von langen Kontexten und Agent-Coding zu einem integrierten Stack aus nativer Multimodalität, Computer Use, kollaborativen Agenten und eigenständiger Mediengeneration.
Auffällig ist der parallele Versuch, große Modelle öffentlich bereitzustellen und gleichzeitig eigene Community-Lizenzmodelle, Cloudprodukte und Abonnements zu etablieren.
774. Fazit: Von langen Kontexten zum multimodalen Agenten- und Medienstack
MiniMax entwickelte sich von frühen interaktiven AI-Produkten über Lightning/Hybrid Attention und M1/M2 zu M3 als 1M-Kontext-Agentenmodell sowie H3, Speech 2.8 und Music 3.0 als eigenständige Medienfamilien.
Die wichtigste archivische Regel lautet: M3 ≠ H3 ≠ Speech ≠ Music ≠ Image ≠ MiniMax Code ≠ Mavis ≠ Hailuo ≠ Talkie ≠ API. Nur diese Schichtentrennung macht technische Aussagen dauerhaft nachvollziehbar.
775. Rechtlicher und archivischer Hinweis
Diese Seite ist technische Archivdokumentation und keine Rechts-, Lizenz-, Sicherheits-, Datenschutz- oder Kaufberatung. Modellstände, Lizenzen, Preise, Verfügbarkeit und Nutzungsbedingungen können sich nach dem Stichtag ändern.
Für produktive oder kommerzielle Nutzung gelten die aktuellen Originalbedingungen von MiniMax beziehungsweise des jeweiligen Deploymentanbieters sowie die eigene rechtliche und sicherheitstechnische Prüfung.
Weiterführende interne Themen
Die übergreifende Methoden- und Sicherheitsseite bleibt KI-Werkzeuge. Für direkte technische Vergleiche stehen die großen Chroniken zu OpenAI / ChatGPT, Anthropic Claude, Google Gemini, xAI / Grok, Meta AI / Llama / Muse, Perplexity AI, DeepSeek, Alibaba Qwen, Microsoft Copilot, Mistral AI / Vibe, Z.ai / GLM und Cohere / Command / Aya / North bereit.