Step 3.5 Flash – Open-Source-LLM für schnelle Inferenz

 (static.stepfun.com)
20 Punkte von GN⁺ 2026-02-20 | 2 Kommentare | Auf WhatsApp teilen
  • Mit einer sparsamen Mixture-of-Experts-Architektur, bei der von 196 Milliarden Parametern nur 11 Milliarden aktiviert werden, unterstützt es schnelle Inferenz und Echtzeit-Interaktion
  • Erreicht eine Generierungsgeschwindigkeit von bis zu 350 Token pro Sekunde sowie ein 256K-Kontextfenster
  • Mit SWE-bench Verified 74.4% zeigt es stabile Leistung bei Coding- und Agenten-Benchmarks und kann auch in lokalen Umgebungen (Mac Studio M4 Max, NVIDIA DGX Spark) ausgeführt werden
  • Durch toolgestützte Inferenz und Multi-Agent-Orchestrierung belegt es hohe Zuverlässigkeit und Ausführungsstärke in realen Arbeitsszenarien wie Finanzen, Datenanalyse und Forschungsautomatisierung
  • Mit der RL-basierten MIS-PO-Optimierungsmethode wird die Stabilität bei langfristiger Inferenz gesichert, während es zu geringeren Kosten als Hochleistungsmodelle Reasoning- und Action-Fähigkeiten auf Frontier-Niveau bietet

Modellüberblick und Leistung

  • Step 3.5 Flash ist ein Open-Source-basiertes foundation model, das schnelle Inferenz und Agentenfunktionen kombiniert und einen durchschnittlichen Benchmark-Wert von 81.0 erreicht
    • Höherer Durchschnittswert als wichtige Modelle wie GLM-4.7 (78.5), DeepSeek V3.2 (77.3) und Kimi K2.5 (80.5)
  • Dank der sparsamen MoE-Architektur werden von 196B nur 11B Parameter aktiviert, was durch effiziente Berechnung Echtzeitreaktionen ermöglicht
  • Auf Basis von MTP-3 werden im normalen Einsatz 100–300 tok/s und bei Coding-Aufgaben bis zu 350 tok/s erreicht
  • Mit SWE-bench Verified 74.4% und Terminal-Bench 2.0 51.0% wird stabile Leistung bei langfristigen Code- und Agentenaufgaben erreicht
  • Das 256K-Kontextfenster ist mit einer 3:1-SWA-Struktur umgesetzt und bleibt auch bei langen Kontexten kosteneffizient

Praxisbeispiele und Tool-Nutzung

  • Durch tool-augmented reasoning wird die Leistung in Mathematik, Coding und Datenanalyse verbessert
    • Mit integrierter Python-Ausführung wurden bei AIME 2025 (99.8), HMMT 2025 (98.0) und IMOAnswerBench (86.7) verbesserte Werte erzielt
  • In einem Aktieninvestment-Szenario wurden mehr als 80 MCP-Tools kombiniert, um Datenerfassung, Analyse und Alarmierung zu automatisieren
  • Die Autonomous Business Intelligence Engine automatisiert alles von der CSV-Verarbeitung bis zur Vorhersage und identifiziert Unterschiede in der Datenqualität (1.6x)
  • Der Large-Scale Repository Architect analysiert große Codebases und erstellt ein spezialisiertes Wiki, das Architekturpattern mit Implementierungsdetails verknüpft

Forschung und Agentenleistung

  • Im ResearchRubrics-Benchmark erreicht es mit 65.3% einen höheren Wert als Gemini DeepResearch (63.7) und OpenAI DeepResearch (60.7)
    • Führt in einer einzelnen ReAct-basierten Schleife die Schritte Planung, Suche, Verifikation und Schreiben aus
  • In der Claude-Code-Umgebung erreicht es 39.6% im Datenanalyse-Benchmark und liegt damit knapp vor GPT-5.2 (39.3)
  • Über das Multi-Agent Framework koordiniert ein Master Agent Such-, Verifikations- und Zusammenfassungs-Agenten und erzeugt strukturierte Ergebnisse
  • Mit Cloud-Device Synergy und Anbindung an Step-GUI erreicht es im AndroidDaily-Hard-Benchmark 57 Punkte (gegenüber 40 Punkten allein)

Architektur und technische Merkmale

  • Das Sparse-MoE-Backbone trennt globale Kapazität (196B) von der Rechenleistung pro Token (11B) und optimiert Inferenzkosten und Geschwindigkeit
  • Die Struktur Sliding-Window Attention + Full Attention (3:1) erhält die Effizienz bei der Verarbeitung langer Kontexte
  • Head-wise Gated Attention steuert den Informationsfluss dynamisch und sichert numerische Stabilität
  • Einen Dekodierdurchsatz von 350 tok/s erreicht es auf NVIDIA-Hopper-GPUs
  • Über ein INT4-GGUF-Quantisierungsmodell wird lokale Inferenz (20 tok/s, 256K-Kontext) unterstützt

Reinforcement-Learning-Framework

  • Einführung von Metropolis Independence Sampling Filtered Policy Optimization (MIS-PO)
    • Statt Importance Sampling werden instabile Samples durch binäre Filterung entfernt
    • truncation-aware value bootstrapping und routing confidence monitoring stabilisieren langfristige Inferenz
  • Diese Struktur ermöglicht kontinuierliche Selbstverbesserung in Mathematik, Coding und Tool-Nutzung insgesamt

Benchmark-Vergleich

  • Step 3.5 Flash zeigt in den drei Bereichen Reasoning, Coding und Agentic eine ausgewogene Spitzenleistung
    • AIME 2025: 97.3 / HMMT 2025: 98.4 / LiveCodeBench-V6: 86.4
    • τ²-Bench: 88.2 / BrowseComp-ZH: 66.9 / ResearchRubrics: 65.3
  • Die Dekodierkosten liegen bei 128K-Kontext bei 1.0x und sind damit effizienter als DeepSeek V3.2 (6.0x) und Kimi K2.5 (18.9x)

Einschränkungen und Ausblick

  • Token-Effizienz: Im Vergleich zu Gemini 3.0 Pro sind für die gleiche Qualität längere Generierungen nötig
  • Integration von Fachwissen: Forschung zu On-Policy-Distillation für eine effizientere Verbindung von Generalität und Spezialisierung läuft
  • Erweiterung von agentischem RL: Der Einsatz von RL soll auf komplexe Aufgaben auf professionellem Arbeits- und Forschungsniveau ausgeweitet werden
  • Betriebsstabilität: Bei langen Dialogen oder Domain-Wechseln können wiederholte Inferenz und gemischte Sprachausgaben auftreten

Bereitstellung und Zugänglichkeit

  • In die OpenClaw-Plattform integriert und mit einfacher Installation sowie Modellregistrierung nutzbar
  • Zugriff über die API-Plattform (Englisch/Chinesisch) sowie Web- und Mobile-Apps (iOS/Android)
  • Updates und Support werden über die Discord-Community bereitgestellt

Verwandte Beiträge

2 Kommentare

 
sftblw 2026-02-20

Dieses Modell ist ziemlich stark.
Wer die Möglichkeit hat und es mit llama.cpp ausführen möchte, muss den Prompt aus dem Kommentar im unten verlinkten Thread zusätzlich anwenden. Andernfalls tritt das Problem auf, dass ohne ein öffnendes <think> mitten im Text nur ein einzelnes </think> erscheint.
https://huggingface.co/stepfun-ai/Step-3.5-Flash-GGUF-Q4_K_S/…

llama-server \  
  옵션생략 \  
  --jinja \  
  --chat-template-file 경로/step3p5_flash_chat_template.jinja
 
GN⁺ 2026-02-20
Hacker-News-Kommentare

  • Ich halte das für eine der am meisten unterschätzten Veröffentlichungen unter den LLMs der letzten Monate
    Ich habe die lokale 4-Bit-Quant-Version (Step-3.5-Flash-GGUF) getestet, und sie war sogar besser als Minimax 2.5 oder GLM-4.7 (GLM lief nur in 2-Bit)
    Die wichtigsten Merkmale sind folgende

    • Die Kontext-Effizienz ist sehr hoch. Auf einem Mac mit 128 GB können entweder der volle 256k-Kontext oder zwei 128k-Streams gleichzeitig laufen
    • Auch auf einem M1 Ultra ist die Geschwindigkeit gut (36 t/s tg, 300 t/s pp), und selbst bei großem Kontext fällt die Leistung nur moderat ab
    • Es ist für agentic coding optimiert und scheint so trainiert worden zu sein, dass es mit Claude Code kompatibel ist. Eine Ausnahme ist nur Codex wegen Problemen mit dem Patch-Editing-Tool
      Unter den Modellen in der 200B-Parameter-Klasse ist das das erste lokale Modell, das sich im CLI-Harness tatsächlich sinnvoll nutzen lässt. Ich verwende es zusammen mit pi.dev, und die Erfahrung war ausgezeichnet
      Als Nachteil gibt es einen Bug mit einer Endlosschleife im Reasoning (zugehöriges Issue)
      StepFun scheint auch die Firma hinter ACEStep, einem Musikgenerierungsmodell, zu sein, und wird auch in der ComfyUI-Dokumentation erwähnt
    • Ich habe Qwen3 Coder Next zusammen mit OpenCode getestet, und das funktionierte ziemlich gut
      Gelegentlich ruft es Tools falsch auf, aber mit der von Qwen empfohlenen Einstellung temperature=1 bleibt es nicht hängen
      Nemotron 3 Nano war bei der Tool-Nutzung schwach und neigte dazu, meist nur das Shell-Tool zu verwenden
      Insgesamt scheinen agentic Open-Weight-Modelle unbekannte Tools eher schlecht aufzurufen
    • Ich frage mich, ob es kostengünstiger ist, OSS-Modelle auf einem M3 Ultra (512 GB RAM) laufen zu lassen als ein Claude- oder Codex-Abo zu bezahlen
      Mich würde interessieren, ob jemand diese Rechnung schon einmal gemacht hat
    • Ich frage mich, ob sich das Problem der Endlosschleife im Reasoning durch einen Wechsel der Inferenz-Engine lösen lässt
      Ich denke eher, dass dafür die Modellgewichte selbst geändert werden müssten
    • Mich würde interessieren, ob es jemand in der MLX-Version ausprobiert hat. Theoretisch dürfte die schneller sein, aber ich zögere, mehrere Versionen herunterzuladen
    • Auch gpt-oss 120b und 20b funktionierten gut mit Codex

  • Kürzlich fand ich den Reasoning-Prozess hinter dem Trick „Walk or drive to the carwash“ interessant
    Zugehörige Links: gist, stepfun.ai-Gespräch

  • Es heißt, das Modell habe im Terminal-Bench 2.0 51,0 % erreicht, aber ich bezweifle, dass das wirklich eine 'zuverlässige Fähigkeit zur Bearbeitung langfristiger Aufgaben' garantiert

    • Allein der Wert von 51 % ist nicht besonders aussagekräftig. Solche Benchmarks basieren auf absoluten Scores, und 100 % bedeutet nicht automatisch menschliches Niveau
      Im Leaderboard liegt der Höchstwert bei 75 %, daher entsprechen 51 % ungefähr zwei Dritteln des SOTA-Niveaus
    • Dieser Wert liegt in der Nähe von Gemini 3 Flash, aber in der Praxis scheint die Agenten-Konfiguration den Score stärker zu beeinflussen als das Modell selbst
    • Trotz des Namens hat TerminalBench kaum etwas mit dem Terminal zu tun und ähnelt eher einem Test zufälliger Tool-Syntax
      Es könnte sein, dass das Modell einfach Kommandozeilen-Flags auswendig gelernt hat

  • In meinen Tests war die Halluzination stark ausgeprägt. Selbst bei einfachen Fragen wie „Finde mir ein Pokémon-Champion-Deck“ war es ungenau
    Opus 4.6, Deepseek und Kimi funktionierten erwartungsgemäß gut

    • Für die Ausführung halte ich Modelle mittlerer Größe für besser geeignet
    • Modelle wie Gemini nutzen Suchfunktionen aktiv, weshalb sie möglicherweise schneller und genauer waren

  • Das ist ein kürzlich veröffentlichtes Modell, das eine Mixture-of-Experts-(MoE)-Architektur nutzt und pro Token nur 11B von 196B aktiviert
    In mehr Benchmarks liegt es vor Kimi K2.5 und GLM 4.7
    Selbst auf einer Maschine mit 128 GB lässt es sich in der 4-Bit-Quant-Version ausführen (Referenzlink)

    • Ich bezweifle, dass die Benchmark-Überlegenheit in der Praxis wirklich viel bedeutet. Für mich sind Befolgung von Anweisungen, Schlussfolgern über lange Kontexte und geringe Halluzinationen wichtiger
    • Mich würde interessieren, welche Variante unter Q4_K_S(116GB), IQ4_NL(112GB) und Q4_0(113GB) besser ist
      Siehe Modellseite

  • Bei neueren Modellen gehen hohe Benchmark-Scores oft mit einer explodierenden Token-Nutzung einher
    Für echte Innovation muss das Problem der Energieeffizienz gelöst werden

    • Wichtig ist nicht nur die reine Tokenzahl, sondern auch die Energieeffizienz pro Token (tokens/joule)
      Eine effiziente Nutzung der MoE-Architektur beeinflusst sowohl tokens/joule als auch tokens/sec

  • SWE-bench Verified ist ganz ordentlich, aber wir brauchen bessere SWE-Benchmarks
    Faire Benchmarks verursachen hohe laufende Kosten
    Das Konzept eines „Live-Benchmarks“ ist gut, bildet aber aktuelle Modelle nicht ausreichend ab

    • Es gab den Vorschlag, an der Entwicklung von Terminal Bench 3.0 mitzuwirken
      Dokumentationslink

  • Ich denke, dass eher tokens per dollar/sec eine wichtige Kennzahl ist als die reine Parameterzahl
    Denn die Top-Modelle unterstützen keine lokale Inferenz

    • Bei Open-Source-Modellen ist die Parameterzahl für Leute, die Self-Hosting in Betracht ziehen, dennoch wichtig
    • Die Parameterzahl ist weiterhin ein grober Indikator für die Modellleistung
      Qwen3 0.6b ist zum Beispiel bei tok/dollar hervorragend, reicht aber für die meisten Anwendungsfälle nicht aus
    • Dieses Modell ist insofern bemerkenswert, als es sich sogar auf einer Maschine unter 3.000 US-Dollar lokal ausführen lässt

  • In einem einfachen Test habe ich einige Beobachtungen gemacht

    1. Der ausgegebene Trace war sehr ausschweifend, und die Absätze wirkten im LinkedIn-Stil sehr kurz
    2. Die gehostete Version hatte eine sehr hohe Token-Ausgabegeschwindigkeit
    3. Anweisungsbefolgung und Ausgabequalität waren besser als bei führenden Modellen wie Opus 4.5

  • Die x-Achse des Diagramms war umgekehrt, was verwirrend war

    • Das fand ich auch. Ich weiß nicht, warum man das so gemacht hat
    • Vermutlich wollte man das Diagramm dadurch besser aussehen lassen, tatsächlich ist das aber nicht der Fall