Sweep unterstützt automatische Code-„Next Edit“-Vervollständigung mit einem Open-Weight-basierten 1.5B-Modell

 (huggingface.co)
19 Punkte von GN⁺ 2026-01-23 | 2 Kommentare | Auf WhatsApp teilen
  • Das Sweep Next-Edit-Modell mit 1.5B Parametern sagt die nächste Code-Änderung des Nutzers voraus und bietet eine Autovervollständigungsfunktion
  • Es läuft in einer lokalen Umgebung mit einer Geschwindigkeit von unter 500 ms und zeigt bessere Leistung als mehr als viermal größere Modelle
  • Es wird im Q8_0-GGUF-Quantisierungsformat bereitgestellt und unterstützt auch in komprimierter Form eine lange Kontextlänge von 8192 Tokens
  • Es basiert auf Qwen2.5-Coder und kann mit einem JetBrains-Plugin integriert werden
  • Es wird unter der Apache-2.0-Lizenz veröffentlicht und ist damit ein nützliches Modell für Experimente und Integration für Open-Source-AI-Entwickler

Modellüberblick

  • Sweep Next-Edit 1.5B ist ein Next-Edit-Vorhersagemodell für Code-Autovervollständigung
    • Es sagt die nächste Bearbeitung voraus und schlägt sie vor, bevor der Nutzer den Code ändert
    • Es kann selbst in einer lokalen Notebook-Umgebung mit einer Latenz von unter 500 ms ausgeführt werden
  • Nutzt Speculative Decoding für schnelle Antwortzeiten
  • Erzielte in Next-Edit-Benchmarks bessere Leistung als mehr als viermal größere Modelle

Modelldetails

  • Anzahl der Parameter: 1.5B
  • Format: GGUF (Q8_0-Quantisierung)
  • Kontextlänge: 8192 Tokens
  • Basismodell: Qwen2.5-Coder
  • Lizenz: Apache 2.0
Anzeige

Verwendung

  • run_model.py und die Modelldatei herunterladen und anschließend ausführen
    • Installationsbefehl: 
      uv pip install llama-cpp-python huggingface_hub  
python run_model.py
  • Struktur mit Fokus auf lokaler Ausführung, es gibt keinen separaten Cloud-Inference-Anbieter

Verwandte Beiträge

2 Kommentare

 
minsuchae 2026-01-23

In letzter Zeit sind die Big-Tech-Unternehmen gewachsen, indem sie die Zahl der Parameter erhöht haben – ändert sich diese Richtung vielleicht?
Ich persönlich dachte ohnehin zunehmend, dass immer weiteres Wachstum durch das Hochdrehen der Parameterzahl letztlich keine echte Antwort ist.
Es fühlt sich an, als würde man dafür die unmittelbare Zukunft opfern, um zu wachsen. Besonders bei MoE schien das am stärksten ausgeprägt zu sein.
Googles Gemma 3 27b lag eher auf der höheren Seite, aber inzwischen wirkte in der LLM-Welt selbst so eine Parameterzahl fast schon klein.
Technologischer Fortschritt ist wichtig, aber es müsste auch etwas geben, das die Phase berücksichtigt, in der das Ganze tatsächlich bereitgestellt wird; insofern scheint das hier ein ganz brauchbarer Versuch zu sein.
(Mein Grund, dem ständigen Anwachsen der Parameter skeptisch gegenüberzustehen, war: Ich weiß, dass die Leistung gut ist, aber das Serving verursacht entsprechend höhere Kosten.)
 
GN⁺ 2026-01-23
Hacker-News-Kommentare

  • Ich habe das Modell selbst ausprobiert, und Leistung und Qualität waren wirklich beeindruckend.
    Danke, dass ihr es als Open Source veröffentlicht habt.
    Ich bin die Person, die ein Edit-Completion-Plugin für Neovim gebaut hat, und ich habe es geschafft, es mit dem Sweep-Edit-Modell zu integrieren.
    Wer Interesse hat, kann sich cursortab.nvim ansehen.

    • Ich frage mich, ob es auch einen Port für Emacs oder eine Integration mit gptel gibt.
    • Sieht interessant aus, ich werde das nvim-Plugin direkt ausprobieren.
    • Sehr cool. Ich will es auch selbst testen.

  • Ich hatte früher bei Continue.dev Qwen 2.5 Coder für Autovervollständigung ausprobiert, aber sowohl in JetBrains-IDEs als auch in VS Code war es miserabel.
    Deshalb freue ich mich sehr, dass solche Versuche geteilt werden. Die meisten IDE-Plugins (Cline, RooCode, KiloCode usw.) unterstützen die Konfiguration von Autovervollständigungsmodellen nicht richtig.
    Ich habe mein Copilot-Abo im Grunde nur wegen der Autovervollständigung behalten, deshalb freue ich mich, dass es jetzt offenbar eine Alternative gibt.

    • Ich habe auch die VS-Code-Erweiterung von llama.cpp ausprobiert, aber die Konfigurations-UX war wirklich schrecklich.

  • Jedes Mal, wenn ich solche Plugins benutze, merke ich wieder, wie ineffizient es ist, ohne Autocomplete-AI zu programmieren.
    Je mehr Boilerplate-Code anfällt, desto nützlicher ist das als Claude Code.
    Ich habe JetBrains so lange genutzt, dass ein Wechsel zu VSCode schwerfällt, aber die AI-Funktionen von JetBrains waren viel zu weit zurück.
    Endlich gibt es ein brauchbares Autovervollständigungs-Tool, also denke ich darüber nach, mein Copilot-Abo dadurch zu ersetzen.
    Außerdem gefallen mir die offenen Gewichte und der Privacy Mode.

    • Ich habe schon lange den Nutzen von Autovervollständigung betont, aber erst jetzt verstehe ich, dass es zwei verschiedene Entwicklungskulturen gibt.
      Entwickler, die hauptsächlich neuen Code schreiben, spüren die Produktivitätssteigerung durch Autovervollständigung stark, während wartungsorientierte Entwickler mehr Hilfe von Tools wie Claude Code bekommen.
    • Sehe ich auch so. Ich nutze in Emacs lokale Modelle zusammen mit gemini 3 flash.
      Normalerweise lasse ich LLMs aber ausgeschaltet und aktiviere sie nur bei Bedarf.
      Ich glaube, das Potenzial kleiner spezialisierter Modelle wird unterschätzt.
      Dazu schreibe ich gerade ein Buch mit dem Titel „Winning Big With Small AI“.
    • Das ist etwas off-topic, aber ich frage mich, warum es überhaupt so viel Boilerplate-Code gibt.
      Das meiste müsste sich doch in Utilities oder Bibliotheken refaktorieren lassen.
      Vielleicht sehe ich das anders, weil ich hauptsächlich Pipeline-Code für Forschung schreibe.
      Zur Referenz: Mit Tools wie yasnippet, ultisnips oder VSCode snippets kann man auch grundlegende Autovervollständigung umsetzen.
    • Junie ist nicht besonders gut, aber wenn es speziell um Beschwerden über Autovervollständigung geht: Auch IntelliJ hat lokale/Cloud-Autovervollständigung.
    • Es ist irgendwie unerquicklich, dass die Lösung für das Boilerplate-Problem am Ende bei automatischer Generierung landet.

  • Darauf habe ich wirklich lange gewartet.
    Es hat mich genervt, dass Cursor 20 Dollar im Monat verlangt, obwohl ich nur die Autovervollständigung nutze.
    Ich habe sogar überlegt, es selbst zu bauen, war mir aber nicht sicher, ob ein Modell, das klein genug für den lokalen Betrieb ist, auch wirklich brauchbar wäre.
    Deshalb habe ich hastig eine VS-Code-Erweiterung gebaut, und das Modell ist ziemlich gut.
    Frühere lokale Modelle waren bei Inline-Vervollständigung furchtbar, diesmal ist es deutlich besser.
    Ich hoffe, dass der Wettbewerb aktiver wird.

    • Wenn jemand Fragen hat, gerne Bescheid sagen.
      Die Qualität wurde mit Funktionen wie Token Healing verbessert — passender Artikel

  • Ich habe gehört, dass das 1.5B-Modell klein genug ist, um lokal zu laufen, deshalb frage ich mich, ob es im Sweep-AI-JetBrains-Plugin tatsächlich auch lokal ausgeführt wird.
    Ich würde gerne wissen, ob das Modell bei der Installation automatisch heruntergeladen wird und ob es keine externe Kommunikation gibt.

    • Aktuell nicht, das JetBrains-Plugin verwendet ein gehostetes großes Modell.
    • Es sieht nicht so aus, als gäbe es im JetBrains-Plugin eine Möglichkeit, einen lokalen Endpoint zu konfigurieren.

  • Ich war überrascht, wie niedrig das Umsetzungsniveau von JetBrains bei AI ist.
    Dass es selbst nach mehreren Jahren noch immer auf diesem Stand ist, ist bemerkenswert — fast so, als könnte ein neues Unternehmen es besser machen.
    Der technische Artikel war ebenfalls interessant.

    • Danke. Feedback oder Fragen sind jederzeit willkommen.

  • Wenn ich mir GLM-4.7-Flash und diese Ankündigung ansehe, finde ich es wirklich spannend, wie die Grenzen kleiner Modelle verschoben werden.
    Ich freue mich darauf, dass Modelle, die auf meiner Hardware gut laufen, immer besser werden.

  • Wirklich großartig.
    Mich interessiert besonders, wie die Trainingsdaten für Next Edit aus Repositories erzeugt wurden.
    Dazu würde ich gern mehr Einblicke hören.

  • Großartig. Auch der zugehörige Blogbeitrag war sehr interessant.
    Ich hoffe, dass bald ein Plugin für Neovim erscheint.
    Passender Artikel

    • Ich habe gehört, dass es bereits jemanden gibt, der ein Neovim-Plugin gebaut hat, das mit diesem Modell verbunden ist.
    • Es gibt auch llama.vim.
      Das hat mit Qwen3 Coder gut funktioniert, und solange Infill unterstützt wird, dürfte es kein Problem sein.
      Ich werde es heute testen.
    • Der Autor des Plugins hat in diesem Thread bereits kommentiert.

  • Ich verstehe den Unterschied zwischen Next-Edit-Modellen und FIM-Modellen nicht so richtig.
    Es wäre gut, wenn jemand erklären könnte, wann man welches am besten verwendet.
    Wenn möglich, würde ich auch gern ein Plugin für Sublime bauen, um es selbst auszuprobieren.

    • Ich war auch neugierig und habe Claude gebeten, ein Plugin zu bauen.
      Es nutzt die grundlegende Autovervollständigungsfunktion.
      Zu finden unter AItoComplete
    • Ich vermute, FIM steht für Fill-In-the-Middle.
      Normale Autovervollständigung ergänzt einfach das Ende, FIM dagegen füllt den Bereich zwischen Codeblöcken.
      Das heißt: Das Modell sieht sowohl den Kontext vor als auch nach der Einfügestelle und sucht die natürlichste Vervollständigung für die Mitte.