Kimi K2.7-Code: Open-Source-Coding-Modell mit verbesserter Token-Effizienz

 (huggingface.co)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein agentenbasiertes Coding-Modell für langfristige Coding-Aufgaben und komplexe Software-Engineering-Workflows, das auf Kimi K2.6 basiert und die End-to-End-Fähigkeit zur Aufgabenerledigung sowie die Effizienz bei der Token-Nutzung verbessert
  • Gegenüber Kimi K2.6 wurde der Verbrauch von Thinking-Tokens um etwa 30 % gesenkt; Kimi Code Bench v2 stieg von 50.9 auf 62.0 und MCP Mark Verified von 72.8 auf 81.1
  • Die Modellarchitektur basiert auf MoE und umfasst insgesamt 1T Parameter, 32B aktive Parameter, eine Kontextlänge von 256K und den Vision-Encoder MoonViT
  • Die Bereitstellung zielt auf die offizielle API sowie vLLM, SGLang und KTransformers; da die Architektur mit Kimi-K2.5/Kimi-K2.6 identisch ist, können bestehende Deployment-Methoden wiederverwendet werden
  • Bei der Nutzung werden der Thinking-Modus und preserve_thinking erzwungen; Bildeingaben werden unterstützt, Videoeingaben aktuell experimentell nur in der offiziellen API

Modellüberblick

  • Kimi K2.7-Code ist ein coding-zentriertes Agentenmodell auf Basis von Kimi K2.6, das bei realistischen langfristigen Coding-Aufgaben verbessert wurde
  • Die Fähigkeit zur End-to-End-Aufgabenerledigung wurde über komplexe Software-Engineering-Workflows hinweg gestärkt
  • Im Vergleich zu Kimi K2.6 wurde der Verbrauch von Thinking-Tokens um etwa 30 % reduziert, wodurch die Token-Effizienz steigt
  • Es wird mit Tags wie Bild-Text-Eingabe, Transformers, Safetensors, conversational und custom_code bereitgestellt

Modellzusammenfassung

  • Die Architektur ist Mixture-of-Experts (MoE); die Gesamtzahl der Parameter beträgt 1T, davon sind 32B aktiv
  • Die Anzahl der Layer beträgt 61 einschließlich Dense-Layern; davon ist 1 Layer ein Dense-Layer
  • Die Attention Hidden Dimension beträgt 7168, die MoE Hidden Dimension pro Expert 2048
  • Es gibt 64 Attention Heads, 384 Experts, 8 pro Token ausgewählte Experts und 1 Shared Expert
  • Die Vokabulargröße beträgt 160K und die Kontextlänge 256K
  • Der Attention-Mechanismus ist MLA, die Aktivierungsfunktion ist SwiGLU
  • Der Vision-Encoder ist MoonViT, die Parameterzahl des Vision-Encoders beträgt 400M

Evaluierungsergebnisse

  • Coding-Benchmarks

    • Bei Kimi Code Bench v2 erreichte Kimi K2.6 50.9, Kimi K2.7 Code 62.0, GPT-5.5 69.0 und Claude Opus 4.8 67.4
    • Bei Program Bench erreichte Kimi K2.6 48.3, Kimi K2.7 Code 53.6, GPT-5.5 69.1 und Claude Opus 4.8 63.8
    • Bei MLS Bench Lite erreichte Kimi K2.6 26.7, Kimi K2.7 Code 35.1, GPT-5.5 35.5 und Claude Opus 4.8 42.8

  • Agenten-Benchmarks

    • Bei Kimi Claw 24/7 Bench erreichte Kimi K2.6 42.9, Kimi K2.7 Code 46.9, GPT-5.5 52.8 und Claude Opus 4.8 50.4
    • Bei MCP Atlas erreichte Kimi K2.6 69.4, Kimi K2.7 Code 76.0, GPT-5.5 79.4 und Claude Opus 4.8 81.3
    • Bei MCP Mark Verified erreichte Kimi K2.6 72.8, Kimi K2.7 Code 81.1, GPT-5.5 92.9 und Claude Opus 4.8 76.4

  • Evaluierungsbedingungen

    • Sofern nicht anders angegeben, wurden Kimi K2.7 Code und K2.6 in der Kimi Code CLI mit aktiviertem Thinking-Modus, temperature 1.0, top-p 0.95 und einer Kontextlänge von 262,144 Tokens getestet
    • GPT-5.5 lief im xhigh-Modus von Codex, Opus 4.8 im xhigh-Modus von Claude Code
    • Abgesehen von diesen Unterschieden wurden alle Benchmarks unter denselben Bedingungen evaluiert

  • Benchmark-Aufbau

    • Kimi Code Bench V2 ist ein interner Benchmark zur Bewertung von Coding-Agenten in realistischen Aufgaben und deckt mehr als 10 wichtige Programmiersprachen sowie den gesamten Produktions-Stack ab
    • Kimi Code Bench V2 umfasst interne Engineering-Use-Cases, Produktionsstörungen und Aufgaben aus realen Open-Source-Projekten
    • Program Bench verlangt, das Verhalten eines Programms allein anhand kompilierter Binärdateien und Dokumentation zu reproduzieren, und nutzt 200 Aufgaben sowie mehr als 248.000 durch Fuzzing erzeugte Verhaltenstests
    • MLS-Bench bewertet, ob AI-Systeme verallgemeinerbare und skalierbare ML-Methoden entwickeln können; MLS-Bench-Lite ist die offizielle Teilmenge mit 30 Aufgaben
    • Kimi Claw 24/7 Bench ist ein interner Benchmark zur Bewertung langfristiger Agentenleistung in fortlaufender Multi-Day-Zusammenarbeit und deckt 17 professionelle Szenarien sowie 610 Bewertungspunkte ab
    • MCP-Atlas bewertet die LLM-Leistung bei realistischen Tool-Use-Aufgaben über skalierbares MCP
    • MCPMark-Verified ist die menschlich verifizierte Version von MCPMark und bewertet die Nutzung von MCP-Tools in fünf realen Serverumgebungen, darunter Notion, GitHub, Filesystem, Postgres und Playwright

Native INT4-Quantisierung

Deployment

  • Auf die Kimi-K2.7-Code-API kann unter https://platform.moonshot.ai zugegriffen werden
  • Die offizielle API bietet eine OpenAI-/Anthropic-kompatible API
  • Empfohlene Inferenz-Engines sind vLLM, SGLang und KTransformers
  • Kimi-K2.7-Code hat dieselbe Architektur wie Kimi-K2.5/Kimi-K2.6, daher kann die Deployment-Methode direkt wiederverwendet werden
  • Die Versionsanforderung für transformers ist >=4.57.1, <5.0.0
  • Deployment-Beispiele finden sich im Model Deployment Guide

Verwendung

  • Grundbedingungen für API-Aufrufe

    • Die Nutzungsdemos basieren auf der offiziellen API-Aufrufmethode
    • Kimi-K2.7-Code erzwingt Thinking und preserve_thinking auf True
    • Bei Third-Party-APIs, die über vLLM oder SGLang bereitgestellt werden, ist Video-Content-Chat derzeit eine experimentelle Funktion, die nur in der offiziellen API unterstützt wird
    • Für den Thinking-Modus wird temperature von 1.0 und top_p von 0.95 empfohlen
    • Der Instant-Modus wird nicht unterstützt

  • Chat Completion

    • Das Chat-Completion-Beispiel ruft die K2.7-Code-API im Thinking-Modus auf
    • Der Beispielcode ruft mit dem openai-Client client.chat.completions.create auf und setzt max_tokens=4096
    • In der Antwort werden response.choices[0].message.reasoning und response.choices[0].message.content ausgegeben

  • Eingabe visueller Inhalte

    • K2.7-Code unterstützt Bild- und Videoeingaben
    • Im Beispiel für Bildeingaben wird das Bild in base64 kodiert, an image_url übergeben und mit max_tokens=8192 eine Antwort erzeugt
    • Im Beispiel für Videoeingaben wird eine mp4-Datei in base64 kodiert und an video_url übergeben
    • Video-Chat ist derzeit eine experimentelle Funktion, die nur in der offiziellen API unterstützt wird

  • Preserve Thinking

    • Kimi K2.7 Code erzwingt den Modus preserve_thinking und behält bei Multi-Turn-Interaktionen den vollständigen reasoning-Inhalt bei
    • preserve_thinking verbessert die Leistung in Coding-Agent-Szenarien
    • Diese Funktion ist standardmäßig aktiviert und kann nicht deaktiviert werden
    • Einige APIs unterstützen reasoning_content möglicherweise nicht; stattdessen kann reasoning versucht werden

  • Interleaved Thinking und mehrstufige Tool-Aufrufe

    • K2.7-Code teilt mit K2 Thinking dasselbe Design für Interleaved Thinking und Multi-Step Tool Calls
    • Für Nutzungsbeispiele wird auf die K2 Thinking documentation verwiesen

  • Coding-Agent-Framework

    • Kimi K2.7-Code funktioniert als Agenten-Framework am besten zusammen mit der Kimi Code CLI
    • Die Kimi Code CLI ist unter https://www.kimi.com/code verfügbar

Beispiele für lokale Ausführung

  • Transformers

    • In Transformers kann mit pipeline("image-text-to-text", model="moonshotai/Kimi-K2.7-Code", trust_remote_code=True) eine High-Level-Pipeline erstellt werden
    • Direktes Laden des Modells ist mit AutoModel.from_pretrained("moonshotai/Kimi-K2.7-Code", trust_remote_code=True, dtype="auto") möglich

  • vLLM

    • vLLM wird mit pip install vllm installiert, der Server mit vllm serve "moonshotai/Kimi-K2.7-Code" gestartet
    • Das Aufrufbeispiel verwendet den OpenAI-kompatiblen API-Endpunkt http://localhost:8000/v1/chat/completions
    • Im Docker Model Runner erfolgt die Ausführung mit docker model run hf.co/moonshotai/Kimi-K2.7-Code

  • SGLang

    • SGLang wird mit pip install sglang installiert, der Server mit python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K2.7-Code" gestartet
    • Das Aufrufbeispiel verwendet den OpenAI-kompatiblen API-Endpunkt http://localhost:30000/v1/chat/completions
    • Das Docker-Ausführungsbeispiel setzt GPU, Shared Memory, den Hugging Face Cache und die Umgebungsvariable HF_TOKEN

Lizenz

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Musste lachen, als ich die überarbeiteten Lizenzklauseln gelesen habe. Im Grunde ist es die MIT-Lizenz mit einer alten BSD-Werbeklausel obendrauf, und unabhängig von monatlich aktiven Nutzern oder Umsatz läuft es praktisch darauf hinaus, dass man sie „bewerben“ soll, wenn man es im Produkt nutzt.
    Ehrlich gesagt wirkt das wie eine vernünftige Forderung

    • Das sieht nach einer gegen Cursor gerichteten Klausel aus. Sinngemäß: Bringt uns nicht in die peinliche Lage, euch öffentlich bloßstellen zu müssen
    • Die „Werbe“-Klausel hier bedeutet nur, dass irgendwo im Produkt offengelegt werden soll, dass es verwendet wird. Zum Beispiel als Eintrag in den Credits im „About“-Bereich
    • Das wirkt hastig nachträglich ergänzt. Ich hätte erwartet, dass die juristische Formulierung dazu, was genau zur „Benutzeroberfläche“ zählt, etwas sauberer ausgearbeitet wäre

  • Ich habe Kimi K2.7-code nur mit ziemlich einfachen Anweisungen gefüttert und damit den Fil-C-OpenSSL-Patch von 3.3.1 auf 3.5.7 rebased, und es scheint funktioniert zu haben.
    Der Patch war mit 177 KB keine kleine Änderung, und anfangs ließ er sich nicht sauber anwenden, sodass der Agent ziemlich substanzielle Arbeit leisten musste.
    Ich habe nur den für 3.3.1 gedachten Patch, den Build-Befehl, den Pfad zu 3.5.7 und einen Link zur Änderungsdokumentation gegeben (https://fil-c.org/constant_time_crypto).
    Ich habe allerdings den hauseigenen Coding-Agenten T800 verwendet, der nicht öffentlich ist und zuvor schon gründlich für K2.5 getestet und abgestimmt worden war.
    Die API-Kosten lagen wohl irgendwo zwischen $5~$10. Korrektur: OpenSSL, nicht OpenSSH

  • Persönlich habe ich bei Open Code oder bei Routern ab einem gewissen Niveau nicht mehr das Gefühl, dass sich die Modelle stark unterscheiden. Eine Ausnahme sind teure und schwer einzuordnende Modelle wie Gemini.
    In dem Sinn sind die Modelle aus China ziemlich ordentlich. Ich lasse sie meist Code auf Funktions- oder Methodenebene schreiben und entwerfe und montiere den Rest dann selbst.
    Die GPT-Familie ist zwar sorgfältiger und wohl auch besser, aber ich bin nicht sicher, ob der Unterschied wirklich riesig ist. Hängt vom Workflow ab, aber wenn man sie hinreichend strikt führt, frage ich mich, ob es überhaupt einen großen Unterschied gibt

    • Von „kostenlosen“ Inference-Routern habe ich mich einigermaßen verabschiedet. Wie zu erwarten sparen sie möglichst aggressiv an Inference, wodurch die Qualität des Denkens oft leidet.
      Es war einigermaßen erfolgreich, mein MacBook M1 Pro mit Qwen 3.6 35B A3B MTP in ein Heizkissen zu verwandeln.
      Als ich versucht habe, Gemini-Modelle quasi „lokal“ zu nutzen, gab es ein ähnliches Problem: Die Modelle rationierten ihren Aufwand in kurze Schübe, machten dadurch mehr Fehler und brauchten mehr Turns.
      Umgekehrt wirkt es nach den Aussagen über Fable, das hartnäckig „proaktiv“ sei, so, als wäre auch das genaue Gegenteil möglich, wenn Branding stark genug und das Abrechnungsmodell effektiv genug ist
    • Meiner Erfahrung nach gibt es bei der Implementierung einzelner Funktionen kaum einen Unterschied zwischen Frontier-Modellen und aktuellen Modellen der 30B-Klasse.
      Wenn bereits ein konsistentes Design vorhanden ist, und das ist der schwierige Teil, bekommt man selbst mit ziemlich kleinen Modellen fast die gleiche Qualität.
      Sie schaffen es nicht in einem Durchgang, sind aber schneller und billiger, was am Ende zu ihren Gunsten wirkt. Außerdem geht das auch lokal
    • Die Unterschiede in den Ergebnissen sind nicht groß, aber man muss sie tatsächlich strenger führen. Zum Beispiel haben Kimi K2.5/K2.6 in meinem Fall gelegentlich fehlschlagende Tests als „bestehende Fehler“ missverstanden und auskommentiert, statt Probleme zu beheben, die sie gerade selbst verursacht hatten.
      Deshalb muss man explizit dafür sorgen, dass auskommentierte Tests den Build kaputt machen. Bei Modellen von Anthropic oder OpenAI hatte ich persönlich dieses Problem nicht
    • Ich fände es gut, wenn man mit der Formulierung „chinesische Modelle“ aufhören würde. Das hat einen negativen Beiklang.
      Das ist ähnlich wie früher bei „japanischen Autos“; heute sagt das kaum noch etwas aus, und stattdessen sagt man einfach Toyota, Honda oder Lexus

  • Mich würde wirklich interessieren, ob jemand opencode + Kimi K2.6/2.7 im Vergleich zu Claude Code ausprobiert hat. Was ist besser, was schlechter, und wie sieht der Kostenvergleich aus?
    Im Moment zahle ich $100 für den 5x-Max-Plan, aber Fable verbraucht das Nutzungslimit ziemlich schnell, und ich würde auch nicht sagen, dass der Unterschied zu Opus so groß ist wie Tag und Nacht.
    Ich nutze es hauptsächlich für Side Projects, deshalb fühlt sich selbst eine Rechnung über $100 ziemlich hoch an, und ich möchte nicht noch mehr ausgeben.

    • Ich habe Claude Code hauptsächlich mit Opus genutzt und bin dann bei privaten Projekten auf opencode + Kimi 2.6 umgestiegen und habe das ein paar Monate lang verwendet.
      Claude Code ist besser. Aber wichtig ist, dass auch opencode + Kimi 2.6 brauchbar ist.
      Wenn man genau weiß, was man will, und nur einfachen Code schreiben lässt, sind populäre Modelle wie DeepSeek und Kimi meistens völlig okay und fühlen sich nicht dramatisch anders an als die Modelle von Anthropic.
      Opus versteht die Absicht dagegen deutlich besser als DeepSeek. Bei DeepSeek muss man Prompts viel präziser formulieren, und wenn man sie schlampig schreibt, läuft es oft in eine völlig falsche Richtung.
      Kimi liegt dazwischen. Es stellt den Flow mit „lockeren Prompts“ bis zu einem gewissen Grad wieder her, und man kann seinen Plänen mehr vertrauen als bei DeepSeek.
      Ein ähnlicher Workflow wie mit Claude Code ist möglich, aber insgesamt ist es überall ein wenig schwächer. Kontextlänge, Fehlerzahl, Entscheidungsfindung, Empfehlungen und Debugging-Fähigkeit sind jeweils etwas schlechter.
      Beim Nutzungsmodell hat der $100-Claude-Plan tatsächlich ein gutes Preis-Leistungs-Verhältnis. Pro Token ist Kimi zwar viel günstiger, aber das Claude-Abo scheint stark subventioniert zu sein, sodass man für $100 viel mehr Tokens bekommt, als man über die API kaufen könnte.
      Am Ende können sich bei ähnlichen Nutzungsmustern die Kosten von opencode + Kimi und Claude Code angleichen.
      DeepSeek ist günstiger, und Cache-Tokens sind absurd billig, aber wenn man von Claude Code kommt, muss man je nach Gewohnheiten möglicherweise die eigene Arbeitsweise anpassen.
      Für Side Projects scheint mir die Kombination aus dem $10-Opencode-Go-Plan plus $10 DeepSeek-v4-Guthaben bei einem Anbieter wie OpenRouter ziemlich praktikabel.
    • Im Job nutze ich Claude, für Side Projects Kimi. In der Organisation sind LiteLLM und Kimi 2.5 zwar aktiviert, laufen aber fast nie richtig, daher sind Claude und GPT die Hauptwerkzeuge.
      Kimi fühlt sich eher wie ein Entwickler im Bewerbungsgespräch an, was unterhaltsamer ist. Den Gedankengang bei der Problemlösung zu sehen, erinnert an die Art, wie ich selbst in einer Whiteboard-Session erkläre. Dass es so oft „wait“ sagt, ist schon lustig.
      Claude wirkt eher wie ein bereits eingestellter Mitarbeiter oder gleich ein ganzes Team. Es erklärt am Anfang nicht ewig alles, stellt nur bei Bedarf Fragen und liefert dann einen umfassenden Bericht oder Plan.
      OpenCode halte ich für das bessere Harness. Zu den Kosten kann ich nichts direkt vergleichen, weil ich nie exakt denselben Prompt auf beiden Seiten laufen ließ.
      Kürzlich habe ich Kimi einen libpq-Wrapper für die Programmiersprache ZenC bauen lassen (https://github.com/nobleach/zenc-postgres); das dauerte etwa eine Stunde und kostete rund $4.
    • Ich bin mit ohmypi sehr zufrieden, aber man kann auch OpenCode nutzen oder einfach bei Claude Code bleiben.
      DeepSeek-V4-Pro ist völlig solide, und für Aufgaben oder kleinere Tätigkeiten, die man sonst Haiku oder Sonnet geben würde, reicht DS4-Flash. Man kann einfach mit $10 Prepaid einsteigen.
      OpenCode Go bekommt man für $5 im Monat und kann Qwen-3.7-Max für Design, Planung, Architektur und schwierige Problemlösung nutzen. Es fühlt sich näher an Opus 3.6 oder 3.7 an als DeepSeek und war das Ähnlichste, was ich gefunden habe.
      OpenAI Codex bietet im $20-Monatsplan GPT-5.5 per API für Design, Planung, Architektur, Problemlösung und das Schreiben von Commits. Bei wirklich schwierigen Problemen kann man auch $100 zahlen und es in den GPT-5.5-Pro-Chat kopieren.
      Xiaomi MiMo-2.5-Pro kann über einen $2-Empfehlungscode von einem Freund 72 Cent an Gratisguthaben bringen. Es kostet wie DeepSeek und liegt leistungsmäßig irgendwo zwischen Sonnet und Opus, also durchaus kompetent. Die UltraSpeed-Beta ist ebenfalls einen Versuch wert.
      In OpenCode oder ohmypi kann man diese Modelle spontan durchwechseln und herausfinden, was am besten zu einem passt. Mit CodexBar prüfe ich die Nutzung fast in Echtzeit.
      Für leichte Nutzer oder Programmieranfänger ist der $20-Plan von Cursor mit Composer-2.5 und Composer-2.5-Fast ein guter Einstieg. Es gibt dort auch API-Kontingent, sodass man außerhalb von Cursor selbst über OpenCode oder ohmypi auf Opus-4.x oder GPT-5.5-Pro zugreifen kann.
      Wenn man Grok oder Twitter nutzt, bekommt man mit SuperGrok für $30 im Monat ein gutes Vision-Modell; ich habe es für automatisierte Frontend-Tests verwendet. Im Moment wechsle ich aber auf lokales Qwen-3-VL auf einem normalen Mac. Wenn man technisch weniger versiert ist, erleichtert unreach das Hosting lokaler Modelle auf dem Mac.
      Wenn man eine starke GPU wie eine RTX 5090 hat, lohnt sich auch ein lokaler Versuch mit Qwen-3.6. Mit ollama oder llama-swap geht das relativ einfach.
      Das neue Kimi habe ich noch nicht ausprobiert, aber ich betreibe ein Team mit 3 professionellen Entwicklern, 1 Grafikdesigner, der Midjourney und Grok Imagine intensiv nutzt, und 1 nichttechnischen Nutzer, der ohmypi für Anforderungserfassung und Umsetzungsverfolgung verwendet, und halte die Kosten bei unter $200 pro Mitarbeiter und Monat.
      Mit etwas mehr Aufwand könnte man wahrscheinlich eher in die Nähe von $75 pro Mitarbeiter und Monat kommen.
    • Ich nutze Claude Code mit einem gepatchten litellm-Proxy, OpenRouter und Qwen 3.7 max/Kimi K2.6/DeepSeek v4 pro.
      Die einzigen Funktionen, die nicht laufen, sind webfetch und Websuche, aber das habe ich ersetzt, indem ich den Agenten mit ddg MCP und einem Pre-Hook für Web-Fetch/Suche umgeleitet habe.
      Speicher, Caching und alles andere funktionieren gut.
      Qwen ist bei der Planung nah an Opus, aber Fable ist klar besser.
      Beim Coding sind die Ergebnisse von Kimi und DeepSeek kaum noch von Opus zu unterscheiden, wenn Opus vorher den Plan geschrieben hat.
      Der größte Unterschied ist der Ausgaberhythmus. Kimi denkt zum Beispiel lange nach und gibt dann sehr schnell viel Text aus.
      Ich teste derzeit Fable für Recherche und Planung und DeepSeek v4 flash fürs Coding. Die Ergebnisse wirken ähnlich wie Opus + DeepSeek v4 pro, und die Gesamtkosten dürften niedriger sein.
    • Zu GLM 5.1 kann ich nur sagen, dass es für mich ungefähr auf dem Niveau von Sonnet 4 liegt.

Gut und erledigt die meisten Aufgaben, die man ihm gibt, recht gut, aber bei kognitiv komplexen Aufgaben scheitert es. Bleibt oft hängen. Dafür kostet es nur etwa 6 $ pro Monat.

  • Es gibt einen Kipppunkt, an dem das „beste“ Modell nicht mehr so wichtig ist, und ich glaube, wir sind nicht mehr weit davon entfernt. Fable ist im Moment wirklich gut, aber wenn Kimi in etwa einem Jahr aufholt, würde ich wahrscheinlich Kimi nutzen, selbst wenn Fable6 deutlich besser ist, falls es nur ein Zehntel kostet
    Früher habe ich bei Opus 4.5 gedacht: „Wenn es so gut ist, dann werden chinesische Modelle in 6–12 Monaten genauso gut und billiger sein, also werde ich die nutzen“ — aber ich lag falsch. Auch jetzt zahle ich noch einen Aufpreis für Opus 4.7/8 und Fable
    Trotzdem wird irgendwann ein Niveau erreicht sein, auf dem Modelle einfach das leisten, was man will, und ab dann beginnt der Preisverfall durch Konkurrenz
    Jetzt, da chinesische Unternehmen Zugang zu sehr guten Fable-Token haben, hoffe ich, dass dieser Wettbewerb schneller kommt

    • Je nachdem, wer man ist und wie man Modelle nutzt, kann es sein, dass man diesen Punkt bereits erreicht hat
    • Ich glaube, die nächste Wettbewerbsfront ist Geschwindigkeit. Statt ständig zwischen mehreren Agenten zu wechseln, die jeweils an eigenen Aufgaben arbeiten, wäre es besser, wenn ein einzelner Agent innerhalb weniger Sekunden jeden Prompt durchziehen könnte, sodass der Arbeitsfluss einer Aufgabe erhalten bleibt
    • Nicht nur der Preis pro Token ist wichtig. Wenn man die AI noch einmal fragen muss, kann sie teurer sein als ein Modell, das es von Anfang an richtig macht
      Deshalb kann ein besseres Modell in der Praxis günstiger sein, selbst wenn der Tokenpreis höher ist

  • Wenn Opus 5-mal teurer ist als Kimi K2.6 oder andere chinesische Modelle und nur ein wenig besser, habe ich mich gefragt, wie Unternehmen wie Anthropic ihre Wettbewerbsfähigkeit aufrechterhalten
    Meine Hypothese ist, dass US-Unternehmen ihre Daten nicht nach China schicken können, und das ist nachvollziehbar. Aber ist das wirklich ein „Burggraben“?

    • Der aktuelle Burggraben ist die Modellleistung und die dadurch zusätzlich verbrauchten Token und die zusätzliche Zeit
      Ich sage das als jemand, der Kimi-Modelle ziemlich oft nutzt und sie im Großen und Ganzen mag
      Auf Benchmarks wie DeepSWE, die noch nicht gamifiziert sind, liegt Kimi K2.6 deutlich hinter Claude Sonnet 4.6($3/$15) und sogar leicht hinter GPT 5.4 Mini($0.75/$4.50)
      Es ist klar, dass Kimi-Modelle bei vielen Coding-Aufgaben sehr gut sind und unter den Open-Weight-Modellen die beste Qualität haben
      Aber um insgesamt ähnliche Ergebnisse wie mit Sonnet/Opus zu erzielen, muss man im Durchschnitt viel mehr Token verbrauchen und das Modell stärker steuern
      Entscheidend ist nicht der Preis pro Token, sondern was man für den gesamten Ablauf bezahlt
    • Ich glaube, viele sehen es nicht als „nur ein bisschen besser“ an. Diese wahrgenommene Qualitätslücke ermöglicht überhaupt erst die Preisdifferenzierung
      Außerdem gibt es bei hohen Ausgaben genug rationale Akteure, die Evaluierungen laufen lassen, sodass „ein bisschen besser“ wahrscheinlich nicht nur ein bloßes Gefühl ist
      Allerdings sehe ich selbst nur einen Teil der Evaluierungssuiten. Es kann natürlich auch sein, dass alle irrational sind und Anthropic das ausnutzt
    • Die meisten, die beide genutzt haben, würden vermutlich sagen, dass Anthropic-Modelle mehr als nur ein bisschen besser sind als Kimi
      Kimi und andere Open-Source-Modelle können bei Dingen wie SWE-bench gut abschneiden, aber in der tatsächlichen Nutzung merkt man den Abstand
    • API-Tokenpreise sind nur ein Faktor, und das Claude-Abonnement hat ein gutes Preis-Leistungs-Verhältnis
      Seltsamerweise argumentieren alle mit den API-Preisen und sagen, das Claude-Abonnement werde subventioniert, aber niemand kennt die tatsächlichen Inferenzkosten von Claude, und chinesische Anbieter können ebenfalls günstige Inferenz anbieten. Warum also sollte Claude das nicht können?
      Für Unternehmenskunden könnte es außerdem andere, nicht veröffentlichte API-Preisvereinbarungen geben. Vielleicht sehen wir nur die hohen Listenpreise
    • Nur in vergleichbaren Bereichen ist es eher ein Fall von „ein bisschen besser“, aber in vielen anderen Bereichen sind die A-Modelle viel besser. Zum Beispiel bei Arten von Aufgaben, die Kimi usw. nicht destilliert haben
      Bei solchen Aufgaben ist der Unterschied geradezu abgrundtief

  • Nach ordentlichem Testen wirkt es wie eine ziemlich solide Verbesserung. Allein die Tatsache, dass für dieselbe Aufgabe weniger Token verbraucht werden, ist schon ein ausreichend guter Grund, bei Bedarf an einem offenen Modell statt K2.6 dieses Modell zu verwenden

  • Wenn ein neues Modell gegenüber DeepSeek v4 nicht klar um etwa 20–30 % besser ist, aber pro Token mehr kostet als DeepSeek, wird es meiner Meinung nach fast automatisch zu einem wenig genutzten Modell. Vielleicht noch brauchbar für Planungsaufgaben

    • DeepSeek v4 Pro ist im Vergleich zu GLM 5.1 oder Kimi K2.6 in der Praxis gar nicht so ein gutes Modell. Eher ein ordentlicher Coder/Reasoner fürs Geld
    • Ich frage mich, ob DeepSeek die Kosten bewusst in Kauf nimmt oder ob Leute offene Modelle tatsächlich zu ähnlichen Kosten hosten können

  • Mit Open-Weights-/Open-Source-Modellen bin ich noch nicht besonders vertraut. Falls jemand sie hauptberuflich nutzt, würde ich gern etwas über Setup und Performance hören. Ich überlege, meine Organisation von Anthropic-Produkten wegzubewegen

    • Aus meiner persönlichen Erfahrung: Für meine eigene Arbeit nutze ich forgecode und openrouter. Zunächst einmal halte ich forgecode für ein deutlich besseres Harness als Claude Code
      Bei der Modellqualität gibt es keinen großen Unterschied, aber der Kostenunterschied ist absurd groß. Zumindest bei der Art, wie ich Agenten nutze, ist das so
      Gestern habe ich zum Beispiel Fable getestet, während ich ein kleines DSL zum Durchsuchen komplexer technischer Dokumente entwickelt habe und einen kleinen Operator hinzufügen wollte
      Fable hat $13 verbrannt und zwar eine Lösung geliefert, aber objektiv war sie nicht besser als dieselbe Aufgabe, die DeepSeek v4 für $1.7 erledigt hat
      Allerdings gebe ich Agenten stark fragmentierte Aufgaben. Im Fall des DSL habe ich die Operatoren selbst entworfen und den Agenten sie einzeln implementieren lassen
      Wenn ich mit einem komplexen Dokument gestartet und ihn gebeten hätte, das Ganze zu entwerfen, hätte Fable vielleicht glänzen können
      Aber immer wenn ich Agenten Aufgaben mit größerem Umfang gebe, verbrennen sie Millionen von Tokens und erzeugen fragwürdigen Code, in den ich mich am Ende selbst einarbeiten muss
    • Ich habe https://github.com/gitsense/gsc-cli gebaut, und ich würde sagen, dass etwa 80 % des Codes von glm-4.7 stammen
      Wenn man sich zum Beispiel Dateien wie https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r... ansieht, habe ich dort das verwendete Modell angegeben
      4.7 war in go-Code nicht besonders gut, und deshalb tauchte in der Attribution dann Gemini 3 Flash auf
      4.7 ist ein von Cerebras bereitgestelltes Modell, und für mich ist Iterationsgeschwindigkeit viel wichtiger
      Nachdem ich MiMo v2.5.0-Pro ausprobiert habe, bin ich sicher, dass es 100 % von dem hätte leisten können, was Gemini 3 Flash gemacht hat
      Wenn ich ein paarmal festhing, musste ich mir Erklärungen von Sonnet holen, aber das schmutzige Geheimnis, das Anthropic und OpenAI nicht aussprechen werden, ist: Wenn man coden kann, sind die Modelle ehrlich gesagt gut genug
      Nach meinen Erfahrungen mit MiMo und den Einschätzungen anderer zu GLM 5.1 würde ich sagen, dass wir jetzt im Hardware-Wettbewerb angekommen sind
      Für Leute, die programmieren können und KI nutzen wollen, um ihr Wissen zu verstärken, sind chinesische Modelle ein 100%iger Ersatz für Claude
      Jetzt wird es darum gehen, welcher Anbieter die schnellste Inferenz liefert
      MiMo-v2.5.0-Pro-Ultraspeed erzeugt gute Ergebnisse schnell und verbrennt auch das Geld schnell
    • Diese Modelle sind zwar Open Weights, aber auf die meisten aktuellen Flaggschiffmodelle kann man faktisch nur über Drittanbieter für Modelle zugreifen
      Eine wichtige Ausnahme sind Modelle um die 30B Parameter, die sich noch auf Consumer-GPUs betreiben lassen
      Allerdings sind auch Consumer-GPUs in den letzten Jahren immer teurer geworden, sodass sie sich kaum noch rechtfertigen lassen
    • Ich versuche ständig, auf chinesische Modelle umzusteigen, aber am Ende bitte ich Claude doch wieder darum, ihre Ausgaben zu korrigieren. Sowohl bei Funktion als auch Stil, und am Ende komme ich immer wieder zurück
      Ich probiere auch immer wieder GPT aus, und es ist ziemlich solide. Sehr schnell und großartig beim Debugging. Aber der Code ist oft übertrieben clever, was mir Kopfschmerzen macht
      Vielleicht lässt sich das per Prompting beheben. Bei chinesischen Modellen hat es ein wenig geholfen. So wie früher bei Bild-KI mit „+good -bad“ sagt man ihnen einfach, dass sie elegant vorgehen sollen
      Im Moment muss der Mensch den Code immer noch verstehen können, und diese Anforderung erfüllt nur Claude durchgängig
      Trotzdem hoffe ich, dass irgendwann eines der chinesischen Labs eine besondere Geheimzutat findet
      Für kleine Änderungen ist DeepSeek Flash wirklich gut. Es fühlt sich an wie praktisch unbegrenzte KI direkt an der Seite, und das ist großartig
    • Seit dwarf star erschienen ist, nutze ich DeepSeek v4 flash als Hauptmodell für fast alle Aufgaben
      Es läuft auf einem M4 Max MacBook Pro mit 128 GB Speicher
      Normalerweise betreibe ich es als Server und nutze auf meinem Coding-Rechner per Tailscale den Pi-Coding-Agenten, um darauf zuzugreifen
      Das ist ein großer Sprung gegenüber der Nutzung von Qwen-Modellen, aber es hat keine Vision-Funktion, daher lasse ich für Aufgaben mit Vision weiterhin diese Modelle laufen
      Zuvor habe ich GLM 4.7 flash als Hauptmodell fürs Coden verwendet, aber alle nicht visionsbezogenen Aufgaben habe ich vollständig auf DeepSeek umgestellt

  • Ich frage mich, ob schon jemand versucht hat, CCP-Elemente aus chinesischen Open-Weights-Modellen zu entfernen. Nicht spöttisch gemeint, ich frage nur, ob das mit Techniken wie Gewichtungs-Robustheitsprüfung oder Konzeptaktivierung gründlich untersucht wurde
    Wenn die CCP zum Beispiel tatsächlich kontextabhängiges Verhalten eingebaut hätte, könnte man schauen, wie das Modell auf Eingaben reagiert, die täuschendes oder böswilliges Verhalten auslösen könnten
    Ich weiß nicht, ob Dinge wie der Verdacht, dass bei US-Regierungsanwendungen verwundbarer Code erzeugt wird, jemals tatsächlich belegt wurden
    In einer Zeit intensiver geopolitischer Konkurrenz ist diese Frage nicht unvernünftig. Sie gilt unabhängig davon, in welchem Land man lebt

    • Es könnte sich lohnen, TNG von Hugging Face anzusehen
      Das ist ein deutsches Beratungsunternehmen, und ich habe einmal eine Präsentation darüber gesehen, wie sie DeepSeek-Modelle feinabstimmen und Bias entfernen. Das war ziemlich interessant
      https://www.tngtech.com/en/about-us/news/release-of-deepseek...
      Worüber man sich Sorgen machen sollte, ist nicht nur Code, sondern auch anderes wie potenzielles Messaging
    • Das klingt nach einer Aufgabe, für die ein Tool wie heretic nützlich sein könnte
      https://github.com/p-e-w/heretic
    • Auch von Unternehmen entwickelte LLMs können unter Verdacht stehen, einen Unternehmens-Bias zu haben. Sicher ist keines