最近ローカルLLMで使っているSwift-Qwen3.8-27Bに、新しいSwift 1.5が出ていたので、1.0と同じ条件で比べてみました。
今回は同じPC・同じllama.cpp環境・同じプロンプトで、そのまま比較。単純な速度だけでなく、実際に困っていたKotlin / Jetpack Composeのコード修正を投げて、回答の組み立て方まで見ていきます🐈
🧪 今回比較したSwift 1.0と1.5
今回使ったGGUFはこの2つです。
Swift 1.0Swift-Qwen3.8-27B-NVFP4-Q8mix.gguf
Swift 1.5Swift-1.5-Qwen3.8-27B-NVFP4-Q8mix.gguf
どちらもQwen3.8-27Bベース。今回使ったQ8mix GGUFは、1.0が約19.72GB、1.5が約19.74GBで、ファイルサイズはほぼ同じです。
Swift 1.5はSwift 1.0の直接アップデートとして公開され、RLとOn-Policy Distillation（OPD）をさらに強化し、特にコーディングやエージェント系タスクの改善がうたわれています。
- 同じPC
- 同じllama.cpp環境
- 同じプロンプト
- 同じQwen3.8-27Bベース
💬 今回使ったプロンプト
今回投げたのはこちら。
Kotlin/Jetpack Composeで、LazyColumnに500件の漫画一覧があります。高速スクロールしてもANRを起こしにくくし、Reader画面から戻ったときにfirstVisibleItemIndexとoffsetを正確に復元してください。既存UIを大きく変えず、変更点とコード例を簡潔に示してください。
ちょうど自分で作っている漫画ビューアで、実際に困っていた内容です（笑）。コード理解、原因整理、実装案、既存UIを壊さない提案まで必要なので、比較にはちょうどよさそうです。
🔵 Swift 1.0の結果
▲ Swift 1.0をllama.cppで起動。同じプロンプトを入力して比較します。
▲ Swift 1.0の実測。Prompt 191.3 t/s、Generation 34.2 t/s。
Swift 1.0は、rememberLazyColumnState()、key = { it.id }、画像の非同期ロード、Dispatchers.IOなど、高速スクロール時のANR対策を広く提案。
スクロール位置についても、firstVisibleItemIndexとfirstVisibleItemScrollOffsetを保存して戻す方針が出ました。
内容としては十分使える回答ですが、今回は少し「対策候補を広く並べる」印象でした。
🟣 Swift 1.5の結果
▲ 新しいSwift 1.5を同じllama.cpp環境で起動。
▲ Swift 1.5の実測。Prompt 190.5 t/s、Generation 37.9 t/s。
Prompt処理速度はほぼ同じ。一方、Generationは34.2 → 37.9 t/sになり、今回の1回の実測ではSwift 1.5が約10.8%高速でした。
回答では、Readerへ移動する前に位置保存 → ViewModelにindex/offsetを保持 → 戻ったらscrollToItem()で復元、という実装の流れがかなり明確。
さらに、key = { it.id }、保存タイミングを毎フレームにしないこと、500件程度なら数値保存方式で十分、といった「なぜそうするのか」まで整理されていました。
⚡ 速度差を並べると約10.8%
今回の実測を並べるとこうなりました。
Swift 1.0
Prompt：191.3 t/s
Generation：34.2 t/s
Swift 1.5
Prompt：190.5 t/s
Generation：37.9 t/s
Promptはほぼ誤差。Generationは今回、Swift 1.5が約10.8%高速です。
ただし測定は1回だけ。温度、コンテキスト、生成内容、GPU負荷などでも数字は変わるので、「1.5は必ず10.8%速い」という意味ではありません。
- Prompt：191.3 → 190.5 t/s（ほぼ同じ）
- Generation：34.2 → 37.9 t/s
- 今回のGeneration差：約+10.8%
- 1回の測定なので、固定の性能差とは断定しない
🧩 速度より、回答の整理の仕方が分かりやすかった
個人的に一番違いを感じたのは、速度よりこちら。
Swift 1.0も答え自体は悪くありませんが、1.5は「何を、どの順番でコードへ入れるか」が見えやすい回答でした。
今回のように、既存UIをあまり変えずに不具合を直したいケースでは、対策候補をたくさん並べるより、実装順まで整理してくれる方が使いやすいです。
📌 Swift 1.5は何が変わった？
UkisAIの公式説明では、Swift 1.5はSwift 1.0を土台に、RLとOn-Policy Distillation（OPD）をさらに強化した直接アップデートです。コーディングやエージェント系タスクを含む複数の領域で、Swift 1.0やベースモデルより強い性能を狙っています。
公式評価では、ベースのQwen3.8-27Bに対して、GPQA-Diamondで思考トークンの中央値を58.5%削減しつつスコアをわずかに上回った結果が示されています。
ここは注意：この58.5%はSwift 1.0比ではなく、ベースQwen3.8-27Bとの比較です。「1.0から1.5で58.5%短くなった」という意味ではありません。
🤔 実際に使うなら1.5でいい？
今回の1問だけを見るなら、1.0から1.5へ入れ替えるハードルはかなり低そうです。
生成速度は少し上がり、コード修正の流れも整理されていました。しかも今回使ったQ8mix GGUFは、1.0が約19.72GB、1.5が約19.74GBで容量差はほぼありません。
ただし、今回はコード修正1問だけ。これだけで「1.5が全部上」と決めるのはまだ早いです。
🔬 次に試したいこと
次は、速度以外の差ももう少し見てみたいところ。
- 長いコード修正
- 日本語の文章生成
- 画像認識
- 長い会話
- 複数ファイルのコード解析
- reasoning_effortのlow / medium / xhigh比較
🐈 まとめ：今回の1問ではSwift 1.5が速く、回答も整理されていた
同じ環境・同じプロンプトで比較した結果、GenerationはSwift 1.0：34.2 t/s → Swift 1.5：37.9 t/sでした。
今回の速度差は約10.8%。さらに1.5は、コードをどの順番で直すかが整理されていて、個人的には実装へ持っていきやすい回答でした。
まだ1問だけなので最終判断は早いですが、同じQwen3.8-27Bをローカルで使うなら、Swift 1.5を試してみる価値はありそうです。
そして何より……19GB台の27Bモデルが普通にこの速度で動くの、やっぱり面白い（笑）🐈
