19 ポイント 投稿者 GN⁺ 2026-01-23 | 2件のコメント | WhatsAppで共有
  • 1.5Bパラメータを持つ Sweep Next-Edit モデルは、ユーザーの次のコード修正を予測して自動補完機能を提供
  • ローカル環境で500ms以下の速度で実行され、4倍以上大きいモデルより高い性能を示す
  • Q8_0 GGUF量子化形式で提供され、軽量化された状態でも長い8192トークンのコンテキスト長をサポート
  • Qwen2.5-Coderをベースとしており、JetBrainsプラグインと連携可能
  • Apache 2.0ライセンスで公開されており、オープンソースAI開発者にとって実験と統合に有用なモデル

モデル概要

  • Sweep Next-Edit 1.5Bは、コード自動補完のためのnext-edit予測モデル
    • ユーザーがコードを修正する前に次の編集を予測して提案
    • ローカルノートPC環境でも500ms以下のレイテンシで実行可能
  • Speculative decodingを活用して高速な応答速度を提供
  • 4倍以上大きいモデルより高い性能を next-edit ベンチマークで記録

モデル詳細情報

  • パラメータ数: 1.5B
  • 形式: GGUF (Q8_0量子化)
  • コンテキスト長: 8192トークン
  • ベースモデル: Qwen2.5-Coder
  • ライセンス: Apache 2.0

使用方法

  • run_model.py とモデルファイルをダウンロード後に実行
    • インストールコマンド:
      uv pip install llama-cpp-python huggingface_hub  
      python run_model.py  
      
  • ローカル実行中心の構成で、別途クラウド推論プロバイダーはない

2件のコメント

 
minsuchae 2026-01-23

最近はビッグテック各社がパラメータ数を増やしながら成長してきましたが、流れが変わるのでしょうか?
個人的には、ひたすらパラメータを増やして成長するやり方には実際のところ限界があると思っていました。
目先の将来を犠牲にして成長しているような感覚、とでも言えばいいでしょうか。特にMoEが最も顕著だったように見えました。
GoogleのGemma 3 27Bもかなり大きい部類でしたが、今ではLLMの世界ではその程度のパラメータ数ですら少ないように見えていました。
技術の進歩も重要ですが、実際にそれをサービングする段階まで考慮した何かが出てこないといけないのでは、と思っていて、今回のものはなかなか良い試みのように思えます。
(パラメータ増加に懐疑的な理由は、高性能なのは分かるものの、それをサービングするのにより大きなコストがかかるからでした。)

 
GN⁺ 2026-01-23
Hacker Newsのコメント
  • 実際にモデルを使ってみたが、性能と品質が本当に印象的だった
    オープンソースとして公開してくれてありがたい
    私はNeovim向けのedit completionプラグインを作った者だが、Sweep Editモデルとの統合に成功した
    興味がある人はcursortab.nvimを参照してほしい

    • Emacs向けの移植版やgptel統合版もあるのか気になる
    • 面白そうなのでさっそくnvimプラグインを試してみるつもり
    • すばらしい。私も自分で試してみようと思う
  • 以前、Continue.devでQwen 2.5 Coderを補完用に使ってみたが、JetBrains IDEでもVS Codeでもひどい出来だった
    こういう試みを共有してくれるのは本当にうれしい。たいていのIDEプラグイン(Cline、RooCode、KiloCodeなど)は補完モデルの設定をまともにサポートしていない
    Copilotの契約を維持していた理由は実質的に自動補完のためだけだったが、これで代替手段ができたようでうれしい

    • llama.cppのVS Code拡張も使ってみたが、設定UXが本当にひどかった
  • こうしたプラグインを使うたびに、AI補完なしでコーディングするのがどれほど非効率かを改めて感じる
    ボイラープレートコードが多いほど、Claude Codeよりはるかに有用だ
    JetBrainsを長く使ってきたのでVSCodeへ移るのは難しかったが、JetBrainsのAI機能はあまりにも遅れていた
    ようやくまともな自動補完ツールが出てきたので、Copilotの契約をこれに切り替えるつもりだ
    しかもオープンウェイト公開プライバシーモードの提供も気に入っている

    • 以前から補完の有用性を強調してきたが、ようやく開発文化には2種類あるのだと理解した
      新しいコードを主に書く開発者は補完による生産性向上を強く感じる一方、保守中心の開発者はClaude Codeのようなツールからより多くの助けを得る
    • 私も同意する。Emacsでローカルモデルとgemini 3 flashを統合して使っている
      ただし普段はLLMをオフにしておき、必要なときだけ有効にする
      小型特化モデルの潜在力は過小評価されていると思う
      関連して『Winning Big With Small AI』という本を書いている
    • 少し話は逸れるが、なぜそんなにボイラープレートコードが多いのか気になる
      たいていはユーティリティやライブラリへリファクタリングできると思う
      私は研究用のパイプラインコードを主に書いているので、感覚が違うのかもしれない
      ちなみにyasnippetultisnipsVSCode snippetsのようなツールでも基本的な自動補完は実現できる
    • Junieはいまひとつだが、自動補完への不満ならIntelliJにもローカル/クラウド補完機能がある
    • ボイラープレート問題の解決策が結局自動生成に行き着くのは少し複雑な気分だ
  • こういうものを本当に長く待っていた
    Cursorが自動補完だけ使うのに月20ドルを要求するのが不満だった
    自分で作ることも考えたが、ローカルで動かせるほど小さいモデルが実用になるのか確信が持てなかった
    そこで急いでVSCode拡張を作ってみたが、モデルはかなり良かった
    過去のローカルモデルはインライン補完ではひどかったが、今回はずっと良い
    競争が活発になることを期待している

    • 気になる点があれば教えてほしいとのこと
      token healingのような機能で品質を高めたという — 関連記事
  • 1.5Bモデルはローカルで動かせるほど小さいと聞いたが、Sweep AI JetBrainsプラグインでも実際にローカル実行されるのか気になる
    インストールするとモデルが自動でダウンロードされ、外部通信がないのか知りたい

    • 現時点ではそうではなく、JetBrainsプラグインはホストされた大規模モデルを使っている
    • JetBrainsプラグインでローカルエンドポイントを設定する方法はなさそうだ
  • JetBrainsのAI実装の水準があまりに低くて驚いた
    何年も経っているのにいまだにこのレベルとは、むしろ新しい会社のほうがうまくやれるほどだ
    技術的な記事も興味深かった

    • ありがとう。フィードバックや質問があればいつでも歓迎する
  • GLM-4.7-Flashと今回の発表を見て、小型モデルの限界突破は本当に興味深い
    いまや自分の持っているハードウェアでも十分動くモデルがどんどん良くなっていて楽しみだ

  • 本当にすばらしい
    特にリポジトリからnext editの学習データをどう生成したのかが気になる
    そのあたりの知見を聞いてみたい

  • すばらしい。関連するブログ記事もとても興味深かった
    Neovim向けプラグインがすぐ出てくるといいな
    関連記事

    • すでにこのモデルと接続されたNeovimプラグインを作った人がいると聞いた
    • llama.vimもある
      Qwen3 Coderと一緒にうまく動いたし、infillさえサポートされれば問題ないはずだ
      今日テストしてみる予定
    • すでにプラグイン作者がこのスレッドにコメントを残している
  • next-editモデルとFIMモデルの違いがよくわからない
    それぞれいつ使うのがよいのか説明してくれる人がいると助かる
    できればSublime向けプラグインも作って、自分で試してみたい

    • 私も気になったので、Claudeにプラグインを作るよう頼んでみた
      基本的な自動補完機能を活用する構成だ
      AItoCompleteで確認できる
    • 私の推測では、FIMはFill-In-the-Middleの略だと思う
      従来の自動補完は単純に末尾を補うが、FIMはコードブロックの間を埋める方式
      つまり、挿入位置の前後両方の文脈を見て、最も自然な中間補完を見つけるモデルだ