Retire kllama-cli's legacy dense-FP32 LlamaRuntime path; route Llama/Mistral GGUF through the DSL like Qwen already does
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
- issue の種類
- リファクタリング
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- kotlin
- 領域
- backend, performance
調査の方向性
Start at llm-runtime/kllama's Main.kt architecture branch and trace the Qwen DSL route alongside the Llama/Mistral GGUF route. Read KLlamaJava.loadGGUF and inspect LlamaNetworkLoader.fromWeights and the Llama2DotCWeightLoader lane to establish what can be reused and what still depends on the legacy runtime. Audit non-CLI callers of LlamaIngestion and LlamaRuntime; done means GGUF uses the DSL and any retained legacy path is scoped to .bin if needed.
索引モデルが issue の本文から書いたものです。
説明
Problem
`llm-runtime/kllama`'s `Main.kt` (kllama-cli) branches on GGUF architecture: Qwen GGUFs go through the modern DSL path (`DecoderGgufWeightLoader` → `QwenNetworkLoader` → `OptimizedLLMRuntime` DIRECT — packed/MAPPED weights, kernel-dispatch-routed matmuls), but Llama/Mistral GGUFs still fall to the legacy `LlamaRuntime` path via `LlamaIngestion`/`LlamaLoadConfig` — dense FP32, no `KernelDispatch`/`WeightForm` involvement at all. See the comment at the branch point:
```kotlin
// --- Llama / SafeTensors / BIN: legacy LlamaRuntime path
// (dense FP32; the eager kernels assume dense data).
// Qwen GGUF stays on the DSL branch above.
```
This is the exact machinery the #338 engine-adoption arc (PR #353) migrated everything else off of — `LlamaRuntime` predates `WeightForm`/MAPPED residency/the row-major kernel packs entirely, and (being dense-FP32-only) can't benefit from any of it.
Impact (measured)
Loading `Llama-3.2-1B-Instruct-Q4_K_M.gguf` (762 MB) via kllama-cli's legacy branch: still running 16-token generation after 5+ minutes at 190%+ CPU, never completing. The exact same file through the DSL path (`KLlamaJava.loadGGUF`, used by `skainet-cli` and by SKaiNET-EdgeTranslator's SkaiNet engine integration) loads in 1.9s and generates 16 tokens in 661ms (~24 tok/s) — coherent output.
This is a correctness-adjacent trap, not just a perf gap: anyone hitting kllama-cli with a plain Llama/Mistral GGUF (the common case — Qwen is the exception, not the rule) gets a runtime that appears to hang, with the working DSL path sitting right there in the same module used one branch away.
Ask
- Route the Llama/Mistral GGUF branch in kllama-cli's `Main.kt` through the same DSL path Qwen already uses (`DecoderGgufWeightLoader` → `LlamaNetworkLoader.fromWeights` → `OptimizedLLMRuntime` DIRECT — exactly what `KLlamaJava.loadGGUF` already does).
- Once nothing exercises it, delete `LlamaRuntime`, `LlamaRuntimeInterface`, `LlamaIngestion`/`LlamaLoadConfig`'s eager-dense path, and any other FP32-only/no-DSL runtime left over from before the engine-loader migration. (`LlamaRuntime` also still serves the llama2.c `.bin` lane via `Llama2DotCWeightLoader` — confirm that lane's fate first; either port it onto the DSL too or keep a narrowly-scoped legacy runtime for `.bin` only, not GGUF.)
- Audit other non-CLI callers of `LlamaIngestion`/`LlamaRuntime` for the same trap (kllama's Android/native test targets, samples) while this is being cleaned up.
Context
Found while wiring SKaiNET-EdgeTranslator's SkaiNet engine option (PR #353's downstream consumer) — `KLlamaJava.loadGGUF` (the facade EdgeTranslator calls) was already correctly on the DSL path, but was separately missing the `KernelPacks.install()`/`FfmRowMajorKernelPack.install()` calls skainet-cli has (fixed alongside this investigation). kllama-cli's own Main.kt, investigated as a comparison baseline, is what surfaced this separate, deeper issue.
🤖 Generated with Claude Code
- 主要言語
- Kotlin
- スター
- 8
- フォーク
- 3
- 平均マージ
- 1日 16時間
- マージ済み PR（30日）
- 48
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
SKaiNET-developers/SKaiNET-transformers のほかの issue
-
documentation good first issue size:xs skill:docs sub-issue
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
SKaiNET-developers/SKaiNET-transformers#478 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement skill:kotlin-core
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
SKaiNET-developers/SKaiNET-transformers#502 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
SKaiNET-developers/SKaiNET-transformers#483 ·
メンテナーはふだん 1 日以内に返信
-
coding good first issue size:s skill:kotlin-core sub-issue
難易度 4/5 1〜2日 初心者へのやさしさ 64/100
SKaiNET-developers/SKaiNET-transformers#477 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
coding good first issue size:s skill:numerics sub-issue
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
SKaiNET-developers/SKaiNET-transformers#476 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
SKaiNET-developers/SKaiNET-transformers の issue をすべて見る
似ている issue
-
android bug kotlin vulkan
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
maplibre/maplibre-native-ffi#852 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信
-
documentation importer size:S
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
enorm-labs/event-junkie#3614 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
InsertKoinIO/koin#2477 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
qiin2333/moonlight-vplus#742 ·
メンテナーはふだん 1 日以内に返信