ggml-org

PLaMoでQwen3.8-Flash-Nextを高速化したい 日本語と英語の翻訳にも対応した、翻訳特化モデルのPLaMo 3 Translateが公開された。小型モデルでも高速かつ高精度に翻訳できるということで、いろいろ使えそう。 一方、LLMの生成速度は言語によって変わることがある。特に推測デコードを使うと、英語のほうが日本語より速く生成できるケースがある。 それなら、大きなモデルには得意な英語で回答を生成してもらって、最後にPLaMoで日本語に翻訳すれば、日本語で直接生成するより速くなるんじゃない？　と思って試してみた。 結果 日本語で同じ質問をして、この2パターンを比べてみた。 日本語の質問 ├─ Qwenで日本語を直接生成 → 日本語の回答 └─ Qwenで英語を生成 → PLaMoで翻訳 → 日本語の回答 短い回答の測定では、Thinking OFFのとき、英語生成と翻訳を組み合わせたほうが完成までの平均時間は28.08%短くなった。 Thinking 経路 実質速度 翻訳時間 完成までの時間 TTFT OFF 日本語を直接生成 28.73 tok/s — 3.71秒 0.23秒 OFF 英語生成→翻訳 31.70 tok/s 0.26秒 2.67秒 2.41秒 ON 日本語を直接生成 46.47 tok/s — 8.91秒 8.31秒 ON 英語生成→翻訳 50.10 tok/s 0.25秒 8.91秒 8.68秒 実質速度はQwenの推論＋回答トークン数を翻訳込みの完成時間で割り、各条件30回の値を平均。TTFTは最終的な日本語本文が届き始めるまでの時間。 Thinking ONでは完成時間はほぼ同じだったものの、翻訳時間を含めた実質速度は英語経由のほうが高かった。 一方、英語経由ではTTFTが長くなった。Qwenの英語回答が全部できあがってから翻訳しているので、チャットで使うならこの差は結構気になりそう。 翻訳の品質 翻訳の品質はどうだろう。回答を確認してみると、技術用語の訳に気になるところがあった。 バックグラウンド処理についての回答では、Idempotencyが「同一性保証」や「同一性」に。通知の重複対策についての回答では、read stateが「読み取り状態」になっていた。それぞれ「冪等性」「既読状態」と訳してほしいところ。元の日本語の質問を翻訳時の文脈として渡していたが、それだけでは訳語を揃えられなかった。 次は、TTFTを短くするために文や段落ごとに翻訳を重ねる方法と、用語集で訳語を安定させる方法を試してみたい。回答の長さや内容にも違いがあったので、品質ももう少し見てみるつもり。 使用した構成と測定条件 項目 使用したもの マシン NVIDIA DGX Spark、128GB統合メモリ 主モデル Qwen3.8 FlashNext、NVIDIA NVFP4 / MXFP8チェックポイント 主モデルの推論 TensorFold 1.2.3 翻訳モデル PLaMo 3 Translate 0.8B、公式GGUF Q4_K_M 翻訳の推論 llama.cpp / llama-server、CUDA全層オフロード 両モデルを常駐させて、1リクエストずつ測定した。Qwenのコンテキスト上限は8,192トークンで、両パターンとも同じ重みを使い、Qwenのprefix cacheは無効にした。TensorFoldの今回使ったCUDA経路はexperimental扱い。 短い回答には3問を使用。各行30リクエスト、合計120リクエストが正常に終わった。TTFTは最初の空でない日本語本文chunkで測り、先頭のMarkdown記号なども含む。Qwenの推論トークンを含む最初の生成トークンまでの時間とは別。翻訳APIは60件中45件でprefix cacheを再利用していた。 モデルとソフトウェアの詳細 TensorFold 1.2.3（commit 6ec5fa4cb233f3606acbdad5bec433f0f8758f96） NVIDIA Qwen3.8 Flash Next FP4 Local（revision b9ce18a6887e18c089fdea8509a33e63429a3300） PLaMo 3 Translate 0.8B GGUF（Q4_K_M、revision 03891e907db8a43c97d3a7c75add125cc6d1f96a） llama.cpp（commit a7af149a2） 環境はUbuntu 24.04.5 LTS / aarch64、NVIDIA driver 580.178.04、CUDA toolkit 13.0.3。

One Word, Two GPUs: Why Gemma 4 Answers the Same Question Differently on a Laptop and a Tesla T4 --- title: "One Word, Two GPUs: Why Gemma 4 Answers the Same Question Differently on a Laptop and a Tesla T4" published: true description: "Same GGUF file, same llama.cpp build, greedy decoding, and a GTX 1650 Ti answers $20 where a Tesla T4 answers 2000. One GSM8K question followed down to the word where the two cards part, the order in which each card adds its numbers, and the one stock setting that makes them agree." tags: gemma, llamacpp, cuda, nvidia cover_image: raw.githubusercontent.com --- This article provides a step by step investigation of why Gemma 4 E2B, run from the same GGUF file with the same llama.cpp build and greedy decoding, gives different answers on a GTX 1650 Ti laptop GPU and a Tesla T4, followed through one GSM8K question from the first differing word down to the order in which each card adds its numbers. xbill9/gemma-graveyard --- Same File, Same Build, Two Different Answers Give a laptop GPU and a cloud GPU the same Gemma 4 file, the same llama.cpp build and temperature zero, and ask them the same grade-school math question. The laptop answers $20, and the Tesla T4 answers 2000. Each card repeats itself exactly: the same answer, token for token, every time it runs. What differs is the number of processors on each chip. llama.cpp splits every big matrix product into one share per processor, 16 shares on the laptop and 40 on the T4, and float32 addition rounds the last digits differently when the same numbers are grouped differently. Those last-digit differences build up through the model's layers. After 124 identical tokens the model reaches a near-tie between " spent" and " saved", the two cards fall on opposite sides of it, and every word after that follows from the one that was picked. One stock llama.cpp setting, -ub 1, makes the two cards agree on every token. --- A Week Down One Comment On 2026-10-29 the L4 article in this series picked up one line from a reader: > Same files, same build, and still 2 BF16 questions graded differently across the two cards is the part I keep coming back to. The same question had been nagging here too. Byte-identical model files, one llama.cpp tag, temperature zero: two cards ought to print the same words. At BF16 they disagreed on the grade of 2 questions. At Q8_0 they disagreed on the wording of most answers. A week of runs on three NVIDIA cards later, every one of those differences is accounted for. This article follows one of them, question test-358, from the answer down to the arithmetic. --- The Results in Brief - The GTX 1650 Ti answers test-358 with $20, which is right. The Tesla T4 answers 2000, which is graded wrong. - The two cards print the same 124 tokens, then part at one word: the 1650 picks " spent" at 51.4% against " saved" at 47.8%; the T4 picks " saved" at 59.1% against " spent" at 40.4%. - Each card repeats itself exactly. Run twice on different days, the 1650 gives the same score at all 97,116 tokens compared. - Two things make the cards differ. llama.cpp splits each big matrix product into one share per streaming multiprocessor (SM), and the 1650 has 16 where the T4 has 40. One matrix stored in BF16 goes to NVIDIA's cuBLAS library, which also picks its method by the card. - Adding the same 8,960 float32 numbers in 16 shares gives 47.0389595; in 40 shares it gives 47.0389099. - With one stock setting, -ub 1, the two cards match on all 250 answers and all 97,450 token scores at Q8_0, and on all 107,195 at Q4_0. It costs 14 to 15% of total run time. - The model's own scores cannot say which answers will change grade. Catching all 18 that change across seven setups means flagging 164 of 250 questions. --- At This Point You Should Have… - The repository, xbill9/gemma-graveyard, with its 250 held-out GSM8K questions in data/heldout.jsonl. - llama.cpp b11699 (7182ef71e) built with CUDA for compute capability 7.5 on every card. - The Gemma 4 E2B Q8_0 GGUF, sha256 6b0301104c89a43c3bec5bae4b14d744f6000bc21e00e46e887fbbfe024de38a, on each machine. - Two cards of the same generation: a GTX 1650 Ti with Max-Q Design (laptop, 4 GB) and a Tesla T4 (GCE n1-standard-2). Both are Turing, compute capability 7.5. --- Step 1 — Ask Both Cards the Same Question graveyard.py run starts its own llama-server with -ngl 99 --seed 0, sends each question with greedy decoding and thinking off, grades the last number in the answer, and with --top-logprobs 2 records the two highest-scoring candidates at every generated token. ./graveyard.py run Q8_0 ~/graveyard-gguf/e2b-Q8_0.gguf data/heldout.jsonl out/1650-default \ --llama ~/graveyard-llama --top-logprobs 2 The question: question: Marisa gets $5 as pocket money every day from her parents. She buys 4 lollipops worth 25 cents each every day and saves the change in her piggy bank. How much money does she put in her piggy bank if she saves for 5 days? gold answer: 20 The two cards' last lines, from docs/flip_derived.py: GTX 1650 Ti tokens generated: 412; final line: 'Answer: 20.00'; extracted 20.0; right True T4 tokens generated: 345; final line: 'Answer: 2000'; extracted 2000.0; right False Both cards do the sum correctly. The T4 works in cents and reports 2000 cents. The grader wants dollars. --- Step 2 — Find the Word Where the Answers Part The model writes one token at a time, and each token is the highest-scoring candidate given everything written so far. So the two answers are identical up to the first token where the cards rank the candidates differently, and everything after that follows from it. python3 docs/flip_derived.py tokens identical on both cards before the split: 124 text before the split (last 120 chars): 'tep 3: Calculate the amount of money Marisa spends each day.**\nMarisa receives \\$5 (which is 500 cents) every day.\nMoney' GTX 1650 Ti at the split: ' spent' 51.4%, ' saved' 47.8% T4 at the split: ' saved' 59.1%, ' spent' 40.4% GTX 1650 Ti next 12 tokens: ' spent per day = Total pocket money - Cost of lollip' T4 next 12 tokens: ' saved per day = Money received - Money spent\nMoney saved' At "Money ___" the model is close to a coin flip between " spent" and " saved" on both cards. The 1650 lands on one side and the T4 on the other. From there the 1650 writes "Money spent per day", the T4 writes "Money saved per day", and 221 tokens later they reach different final lines. 🔎 Tip: the split is almost always a near-tie. Across all 165 Q8_0 answers where the two cards' text differs, the median lead of the top candidate at the split is 0.12 logits on the 1650 and 0.13 on the T4, and in 157 of the 165 the two cards hold the same two candidates in opposite order. Edward Lorenz met the same shape when he repeated a weather simulation with one value rounded from .506127 to .506, and the whole pattern his program produced was transformed. A fully deterministic calculation, a difference in the sixth decimal place, and a result that changes completely. --- Step 3 — Check That Each Card Repeats Itself A difference between cards means something only if each card agrees with itself. The 1650 ran Q8_0 at default settings on 2026-11-02, and again on 2026-11-03 with a patched build whose new switches were all off: same card twice: 1650 default 2026-11-02 vs 1650 patched build, variables unset, 2026-11-03: text differs 0, grade differs 0, tokens compared 97116, same score 97116, median lead at the split None / None, top two swapped 0 of 0 Every answer matches word for word, and every one of 97,116 token scores is the same number. The T4 gives the same result against its own earlier run (98,637 of 98,637). Each card is deterministic. The answers depend on which card runs them. --- Step 4 — Count Each Card's Processors Both cards report compute capability 7.5. They differ in how many streaming multiprocessors (SMs) they have, read from the driver with tools/sm_count.py: NVIDIA GeForce GTX 1650 Ti with Max-Q Design sm=16 cc=7.5 smem_per_block=49152 Tesla T4 sm=40 cc=7.5 smem_per_block=49152 llama.cpp reads the SM count once at start-up (ggml/src/ggml-cuda/ggml-cuda.cu:353). Its matrix kernel for quantized weights splits a prompt's work into one share per SM so that every SM stays busy (mmq.cuh, the "stream-k" split), then adds the shares' partial sums together. Sixteen SMs means sixteen partial sums. Forty SMs means forty. Float32 addition rounds after every step, so the grouping changes the last digits. docs/flip_derived.py adds the same 8,960 random float32 numbers both ways: 8,960 float32 numbers, numpy default_rng(0).standard_normal, each share added in order, then the shares 16 shares of 560: 47.0389595 40 shares of 224: 47.0389099 exact sum (math.fsum in float64): 47.0389371 16-share and 40-share sums equal: False Both are valid float32 results, either side of the exact sum. The model makes sums like this in every layer for every token, and at a near-tie like "Money ___" a change in the sixth digit is enough to swap the two candidates. The test: a small patch (tools/graveyard-probe.patch) adds GGML_CUDA_NSM_OVERRIDE, which replaces the SM count llama.cpp reads. Told it has 40 SMs, the 1650 splits its work the way the T4 does: 1650 default vs T4 default: text differs 165, grade differs 4, tokens compared 50572, same score 29969, ... 1650 told 40 SMs vs T4 default: text differs 32, grade differs 2, tokens compared 87580, same score 85282, ... The SM count accounts for 133 of the 165 differing answers. --- Step 5 — Find the Matrix That Goes to cuBLAS The other 32 come from one matrix. The Q8_0 file stores per_layer_model_proj (1536 × 8960) in BF16, because llama-quantize leaves it unquantized (src/llama-quant.cpp:324). llama.cpp has no batch kernel for BF16 on compute capability 7.5, so for any prompt longer than 8 tokens it hands that product to cuBLAS. With the patch's GGML_CUDA_LOG_CUBLAS=1, 200 of 200 logged cuBLAS calls are this one matrix. cuBLAS chooses its own method by the card. NVIDIA's documentation, section 2.1.4, states the limit: > By design, all cuBLAS API routines from a given toolkit version, generate the same bit-wise results at every run when executed on GPUs with the same architecture and the same number of SMs. The 1650 and the T4 share the architecture and differ in SM count, so cuBLAS is free to give them different bits. The SM override cannot reach it, because cuBLAS reads the real card. The patch's GGML_CUDA_SPLIT_TO_VEC=1 sends that one product through llama.cpp's single-token kernel instead. With both changes: 1650 both fixes vs T4 matrix fix: text differs 0, grade differs 0, tokens compared 97380, same score 97380, ... All 250 answers match, and all 97,380 token scores are the same number. The same two changes make the cards match at Q4_0 and at every K-quant rung from Q6_K to Q2_K. --- Step 6 — Make Them Agree With One Stock Setting -ub 1 sets llama.cpp's micro-batch to one token. The prompt then goes through the same single-token kernels a generated token uses, which split no work by SM count and never call cuBLAS. It needs no patch. tools/ub1-ladder.sh 1650 ~/graveyard-gguf ~/graveyard-llama 1650 -ub 1 vs T4 -ub 1: text differs 0, grade differs 0, tokens compared 97450, same score 97450, ... Q4_0: 1650 -ub 1 vs T4 -ub 1: text differs 0, grade differs 0, tokens compared 107195, same score 107195, ... With -ub 1 on both cards, both cards answer test-358 with $20 and get 226 of 250 right at Q8_0. --- Step 7 — What Agreement Costs Generation speed stays within 1 token per second of default on both cards (42.5 to 42.9 on the 1650, 57.0 to 58.0 on the T4). Prompt processing slows down, more on the T4 than on the 1650. From the server logs and the summed per-answer times: card | route | prompt tokens/s | prompt slowdown | median generation tokens/s | whole run, summed seconds | whole run vs default GTX 1650 Ti | default | 289 | 1.0x | 42.8 | 2358 | +0% GTX 1650 Ti | both fixes | 239 | 1.2x | 42.5 | 2403 | +2% GTX 1650 Ti | -ub 1 | 58 | 5.0x | 42.9 | 2696 | +14% T4 | default | 1270 | 1.0x | 57.9 | 1722 | +0% T4 | matrix fix | 1060 | 1.2x | 57.0 | 1734 | +1% T4 | -ub 1 | 81 | 15.7x | 58.0 | 1986 | +15% GSM8K prompts are short, so a 15.7x slower prompt adds 15% to the whole run. Long prompts were not measured; they spend a larger share of each run on the prompt. --- Step 8 — Ask Whether the Model Can Warn You If the model knew when it was at a coin flip, it could flag the answers at risk. Seven Q8_0 setups give seven sets of answers: the T4, the 1650 and the L4 at default settings, the L4 with -ub 1, the 1650 and T4 with -ub 1 (identical), the 1650 told 40 SMs, and the 1650 and T4 with both fixes (identical). tools/route_spread.py counts them: "runs": 7, "questions": 250, "text_varies": 219, "grade_varies": 18 219 of 250 answers are worded differently in at least one setup, and 18 change grade. test-358 is right in 3 of the 7. Flag a question when any token in the T4's default answer had a lead below a threshold: | flag when some token's lead is below | questions flagged | of the 18 that change grade | of the 232 that do not | |---|---|---|---| | 0.05 | 112 | 12 | 100 | | 0.1 | 164 | 18 | 146 | | 0.25 | 218 | 18 | 200 | Catching all 18 means flagging 164 questions. Nearly every answer has a near-tie somewhere, and most of them change only the wording. Looking only at the last 12 tokens, where the final number is written, catches 1 of the 18. --- Step 9 — Ask Which Setup Is Right On the 1650 alone, each rung under -ub 1, under default settings and under both fixes, from docs/evidence-flips/ladder-routes.txt: | rung | right, -ub 1 | right, default | right, both fixes | grade changes, -ub 1 vs default | |---|---|---|---|---| | Q8_0 | 226 | 229 | 229 | 9 | | Q6_K | 231 🥇 | 226 | 228 | 7 | | Q5_K_M | 228 | 226 | 230 🥇 | 10 | | Q4_K_M | 223 | 222 | 226 🥇 | 13 | | Q4_0 | 226 🥇 | 216 | 224 | 18 | | Q3_K_M | 190 | 183 | 195 🥇 | 37 | | Q2_K | 3 🥇 | 5 | 2 | 6 | No setup wins every rung. The totals move by 3 to 12 per rung while 6 to 37 individual questions change grade. Each setup is its own sample of the model's near-ties, and the score is an average over which way they happened to fall. --- Compare and Contrast | | default settings | SM count + matrix fix | -ub 1 | |---|---|---|---| | Needs a patch | no | yes | no 🥇 | | 1650 and T4 answers match, Q8_0 | 85 of 250 | 250 of 250 🥇 | 250 of 250 🥇 | | Whole run, T4 | baseline 🥇 | +1% | +15% | | Prompt speed, T4 | 1,270 tokens/s 🥇 | 1,060 tokens/s | 81 tokens/s | | Right of 250, Q8_0, T4 | 227 | 229 | 226 | --- So, Which One? For a benchmark that two people on two cards need to reproduce, run with -ub 1 and say so: it makes these two cards agree to the last digit with stock llama.cpp, for 15% more run time on short prompts. For serving, the default settings are faster and no less accurate; the cost is that an answer from one card is a sample, and another card can word it differently or grade it differently. Report a score with the card, the build and the settings that produced it. Two cards that agree on a total can still disagree on which questions they got right. --- Summary The goal of this article was to explain why the same Gemma 4 E2B file gives different answers on two GPUs of the same generation. The key to the solution was following one question, test-358, to the single word where the two cards part, and then removing each cause of the difference until the two cards matched at every token. The results were: - 🟢 Each card is deterministic: the same card run twice matches on all 97,116 token scores. - 🟢 Two causes explain every difference: llama.cpp splits matrix work by SM count (16 against 40), and cuBLAS handles one BF16 matrix by the card. Removing both gives 250 of 250 matching answers. - 🟢 Stock -ub 1 makes the GTX 1650 Ti and the T4 match on every token score at Q8_0 and Q4_0, for 14 to 15% more run time. - ⚠️ At default settings the two cards word 165 of 250 Q8_0 answers differently and grade 4 differently. test-358 is right on the 1650 and wrong on the T4. - ⚠️ Seven setups on Q8_0 change the grade of 18 questions; scores stay between 225 and 230. - ❌ The model's own scores cannot pick out the answers at risk: catching all 18 means flagging 164 of 250. Scope: Gemma 4 E2B, 250 held-out GSM8K questions, greedy, seed 0, thinking off, 1,024 max tokens, llama.cpp b11699 built for compute capability 7.5 with CUDA 13.4, one run per setup. Cards: a GTX 1650 Ti with Max-Q Design (laptop), a Tesla T4 on GCE, and an L4 on AWS for the seven-setup count. The T4 rungs under -ub 1 stop at Q4_0; the K-quant rungs under -ub 1 are on the 1650 only. Speed is compared within each card only. Every figure here is recomputed from the committed runs by docs/flip_derived.py and make verify. The strategy for tracing a GPU-to-GPU answer flip in Gemma 4 down to the order of its additions was validated with an incremental step by step approach. --- References - The comment that started it, on the L4 article - Performance vs Quality: Gemma 4 E2B Quantization on an NVIDIA L4 and a Tesla T4, the L4 article - Four GPUs, One Quantization Ladder: Gemma 4 E2B From a 4 GB Laptop to an NVIDIA L4 - gemma-graveyard on GitHub - SM count and cuBLAS report - -ub 1 report - cuBLAS documentation, Results Reproducibility - When the Butterfly Effect Took Flight, MIT Technology Review - llama.cpp - google/gemma-4-E2B-it - GSM8K

DGX Sparkでllama.cppの投機デコードを比較してみた TL;DR DGX Spark + llama.cpp で、Qwen3.8-27B（Q4）に投機デコードとベースモデルを含む計6方式を試しました MTP と DFlash が約21.6 tok/s で最速。Baseline（11.82 tok/s）の約1.83倍です MTP はメモリ増加が約2.1 GiB と小さく、設定も簡単。今回の環境では MTP が一番使いやすかった です 図1 平均速度（2〜6回目）。点線はBaseline 1. はじめに DGX Spark は128GBのUnified Memoryを積んでいて、デスクトップサイズでもかなり大きなLLMを動かせます。ただ、LLMはトークンを1つ生成するたびにモデルの重みをメモリから読み出すので、生成速度は演算性能よりもメモリ帯域に引っ張られがちです。DGX Spark のメモリ帯域は公称273 GB/sです。（ハードウェア仕様） そこで気になったのが投機デコードです。次のトークン候補を先にまとめて用意しておき、ターゲットモデルが一度に検証することで、重みの読み出し1回あたりに進めるトークン数を増やせます。メモリ帯域が詰まりやすい DGX Spark なら効くのでは？と考えたのが出発点です。 方式ごとにドラフトの作り方や必要な重み、設定方法が違うので、実際に使うモデルで比べてみました。 2. 投機デコードのしくみ 投機実行は、ベースモデル+ドラフトモデルのように2つのモデルを使用しています。比較のため、投機実行しない通常のベースモデルのみをもちいた実行結果は、Baseline としています。 まずは全方式に共通する流れです。 図2 投機デコードの基本的な流れ ポイントは、候補が当たれば1回の検証で複数トークン進めることです。外れても出力はターゲットモデル単体と同じになるので、品質は変わりません。方式による違いは「ドラフト役を誰がやるか」です。 3. 比較する投機方式 llama.cpp はドラフトモデルを使う方式や、過去の文脈から候補を探す方式などをサポートしています。（llama.cppの投機デコード資料） ドラフト役で分類すると、次の3グループになります。 図3 ドラフト役による方式の分類 各方式のイメージ MTP（Multi-Token Prediction） ターゲットモデルに付属するMTP用の重みが、本体の内部状態から「この先の数トークン」をまとめて予測します。 DFlash / DFlash2 ターゲット側の情報を受け取った小さな専用ドラフトモデルが、候補をブロック単位でまとめて出します。DFlash と DFlash2 は仕組みは同系統で、使うドラフトモデルが異なります。 DSpark DFlash 系のブロック生成に、直前のトークンを使うMarkov的な補正を加えます。専用ドラフトモデルが必要です。 ngram-mod 生成済みのテキストからn-gramを登録しておき、過去に出てきた並びをそのまま候補にします。ドラフト用のLLMは不要です。 使用したモデル 方式 llama.cppの指定 ドラフトモデル Baseline - - MTP --spec-type draft-mtp mtp-Qwen3.8-27B-Q4_0.gguf DFlash --spec-type draft-dflash dflash-Qwen3.8-27B-Q4_0.gguf DFlash2 --spec-type draft-dflash Qwen3.8-27B-DFlash2-Q4_K_M.gguf DSpark --spec-type draft-dspark Qwen3.8-27B-DSpark-Q8_0.gguf ngram-mod --spec-type ngram-mod 不要 ターゲットモデルはすべて ggml-org/Qwen3.8-27B-GGUF です。 ドラフトモデルの見つけやすさ 参考として、Hugging Face の方式タグ付きリポジトリ数も見てみました（2026年10月30日時点）。 タグ 件数 一覧 MTP 3,713 Hugging Face DFlash 598 Hugging Face DFlash2 未確認 Hugging Face DSpark 371 Hugging Face EAGLE-3 405 Hugging Face ngram-mod 専用モデルなし - 量子化版や派生モデルも含んだ数なので、llama.cpp でそのまま動くモデルの数ではありません。「探したときに見つかりやすいか」の目安くらいに見てください。 4. 検証環境 項目 内容 マシン DGX Spark（NVIDIA GB10） OS Ubuntu 24.04.5 LTS メモリ Unified Memory 128GB 推論エンジン llama.cpp 0.7.0-dev（commit d854d98） モデル管理 llama-swap ターゲットモデル Qwen3.8-27B（Q4量子化） 生成トークン数 1024 測定回数 各方式6回（2〜6回目を平均） 5. llama-swapの設定 llama-swap に方式ごとのモデル名を登録し、OpenAI互換APIのモデル名で切り替えました。ターゲットモデル・コンテキスト長・GPUオフロードはそろえ、方式ごとの引数とドラフトモデルだけを変えています。 models: "Qwen3.8-27B-Q4-Baseline": cmd: > llama-server --host 127.0.0.1 --port ${PORT} -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M --n-gpu-layers 99 --ctx-size 131072 --jinja "Qwen3.8-27B-Q4-MTP": cmd: > llama-server --host 127.0.0.1 --port ${PORT} -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M --spec-type draft-mtp --n-gpu-layers 99 --ctx-size 131072 --jinja DFlash / DFlash2 / DSpark / ngram-mod も同じ要領で、--spec-type とドラフトモデル、--spec-draft-n-max などを指定します。 6. 測定方法 全方式で同じプロンプト・同じ設定（temperature: 0、max_tokens: 1024）を使いました。各方式6回実行し、2〜6回目の平均を速度としています。 { "model": "$MODEL", "messages": [{ "role": "user", "content": "小規模な組織が、重要な業務データを長期にわたって安全に保管するための設計ガイドを書いてください。目的、脅威の想定、保存先の選定、暗号化とアクセス制御、バックアップ頻度、復元テスト、運用上の注意点の順に説明してください。各項目では具体例と判断理由を示し、最後に実行可能な導入手順を番号付きでまとめてください。特定製品の宣伝はせず、全体で十分に詳しい回答にしてください。" }], "temperature": 0, "max_tokens": 1024 } 7. 結果 生成速度 方式 平均速度（2〜6回目） Baseline比 Baseline 11.82 tok/s 1.00× MTP 21.61 tok/s 1.83× DFlash 21.62 tok/s 1.83× DFlash2 21.01 tok/s 1.78× DSpark 16.13 tok/s 1.36× ngram-mod 14.86 tok/s 1.26× ngram-mod は回を重ねるごとに速くなりました。同じプロンプトを繰り返したことで、過去の生成結果からn-gramの候補が当たりやすくなったのかもしれません。 図4 ngram-mod の試行ごとの速度（2〜6回目） メモリ使用量 nvidia-smi で測定しました。 方式 メモリ使用量 Baselineとの差 Baseline 27,067 MiB — MTP 29,144 MiB +2,077 MiB（約7.7%） DFlash 29,894 MiB +2,827 MiB（約10.4%） DFlash2 29,941 MiB +2,874 MiB（約10.6%） DSpark 33,091 MiB +6,024 MiB（約22.3%） ngram-mod 27,069 MiB ほぼ増加なし 8. 結論 速度とメモリを1枚にまとめると、MTP の立ち位置がよく分かります。 図5 横軸がメモリ増加、縦軸が速度。左上ほど効率がよい 速度：MTP と DFlash はどちらも約21.6 tok/s。差は0.01 tok/s なので、実質同じと見てよさそうです。DFlash2 も21.01 tok/s と近い結果でした メモリ：MTP の増加は約2 GiB で、ドラフト用の重みを使う方式の中では最小でした 扱いやすさ：MTP はターゲットモデルとセットで扱えるので、別系統のドラフトモデルを探して管理する手間がありません。Hugging Face のタグ付きモデルも一番多いです というわけで、今回の環境では速度・メモリ・入手性・設定の簡単さのバランスで MTP が一番使いやすい という結論になりました。 ただし、これは Qwen3.8-27B（Q4）と今回の llama.cpp ビルド・プロンプトでの結果です。モデルやタスクが変われば順位が入れ替わる可能性は十分あります。 9. まとめと今後 DGX Spark でも投機デコードはしっかり効き、最大で生成速度は約1.8倍になりました 迷ったらまず MTP 対応モデルを探すのがおすすめです MTP と DFlash がほぼ同じ速度に揃った理由は、今回のログだけでは分かりませんでした。メモリ帯域が上限に達しているのかどうかは、帯域を実測して確かめたいと思います プロンプトの種類（コード生成・要約など）を変えたときの比較も試してみたいです

> and the remainder of VRAM is occupied by the KV cache and whatever experts still fit. Those days engines try to optimize "whatever experts" part and can use remaining VRAM as cache, moving hot experts to GPU during inference (but less used experts keep executing on CPU, yea). e.g. llama.cpp recently added flag for that: llama.cpp#29887

Today we ship llama.cpp v0.9.0 and in the next couple of weeks we are gearing towards the first major v1.0.0 release github.com/ggml-org/llama.cpp/releases/tag/v0.9.0

LFM3をllama.cppで手元の会話の補助に。速さは足りたが、専門用語の聞き取りでWhisperに届かなかった 要約 llama.cpp の v0.8.0 で、Liquid AI の LFM3 の音声モデル（LFM3-Audio-2B と LFM3-Omni-2B）が動くようになった。2B の 1 つのモデルで、聞き取り・訳・読み上げができる 自作の会話サポート（AI グラスで会話を聞き、専門用語の一覧と解説、会話の要約を出すもの）の書き起こしを、今のクラウドの書き起こしから LFM3 に置き換えられるかを、手元のノート PC の内蔵 GPU で測った 速さは足りた。音声を流しながら送ると、話し終わってから 0.18 秒で最初の文字が出て、0.82 秒で書き起こしが出そろった。メモリは 4GB 前後 一般の文と会話の聞き取りは、文字の誤り率が 6〜7% だった 専門用語の聞き取りでは、この条件で Whisper medium にもクラウドの書き起こしにも届かなかった。用語 21 語のうち、原音で 13〜15 語（Whisper medium は 16 語）、グラスのマイクで録った音（SNR 24 dB）では 6〜7 語（Whisper medium は 12 語、クラウドは 17 語） 会話サポートは「速報を先に出し、あとで確定に置き換える」作りにしている。測った範囲では、LFM3 は速報の側に合い、確定の側の専門用語にはまだ届かなかった 訳まで広げるなら、速い訳を先に出し、書き起こしてから訳した 2 段目の訳で置き換える形で、意味がずれた発話が 23 中 16 から 9 に減った。前の発話を一緒に渡しても、それ以上は減らなかった きっかけ AI グラスで目の前の会話を聞き、出てきた専門用語の一覧と解説、会話の要約を出す道具を作っている。書き起こしは、今はクラウドの書き起こし（OpenAI の gpt-4o-mini-transcribe）を使っている。以前に手元の Whisper medium とも比べ（中編）、雑音の入ったグラスの音ではクラウドの方が用語を多く拾えたので、そうした。 llama.cpp の v0.8.0 で、LFM3 の音声モデルが動くようになった。LFM3-Audio-2B は、音声か文字を受け取って、文字か音声か両方で返す。手元の PC で書き起こしまで済むなら、通信を待たずに済み、費用もかからない。そこで、これまでの試験と同じ題材で測ることにした。 何で測ったか 環境 ノート PC（Intel Core Ultra、内蔵 GPU は Arc 140V、メモリ 32GB をグラフィックスと共有）。NVIDIA の GPU は無い llama.cpp：公式のリリースの b11972（v0.8.0 は b11960 に当たり、その少し後の版）、Windows の Vulkan 版 モデル：Liquid AI 本人が Hugging Face に置いた GGUF の Q8_0（LFM3-Audio-2B-GGUF・LFM3-Omni-2B-GGUF） 初めて使うモデルなので、外向きの通信を塞いだ専用の環境で動かした。llama-server にも、ネットへ取りに行かない設定（--offline）を付けた 起動の引数はこうした。 llama-server -m LFM3-Audio-2B-Q8_0.gguf -mm mmproj-LFM3-Audio-2B-Q8_0.gguf \ -ngl all -c 8192 -np 1 --reasoning off --temp 0 \ --no-webui --offline Omni は -m と -mm を Omni のファイルに替えただけ。聞き取りは、モデルの説明ページのとおり、システムプロンプトを Perform ASR in Japanese. にした。 題材 すべて合成音声で、台本がある。 題材 中身 声 一般の文 6 つ 道をたずねる、会議の時間の変更など Windows の合成音声（Haruka） 専門用語の 12 文 「今回の遅延はスループットではなくレイテンシの問題だと思います」など。用語 21 語つき Windows の合成音声（Haruka） 同じ 12 文をグラスで録ったもの 上の 12 文を PC のスピーカーで鳴らし、机に置いたグラスのマイクで録った。音量やエアコンを変えた 5 条件（SNR 14〜24 dB） 同上 デモの会議の 23 発話 音声まわりの進捗会議の作り話。3 人 VOICEVOX（青山龍星・玄野武宏・冥鳴ひまり） 専門用語の 12 文の採点は、これまでの試験と同じ物差しにした。用語ごとに表記ゆれ（「Opus」「オーパス」など）を許し、そのどれかが書き起こしに含まれれば取れたとする。どのモデルにも、用語のリストは渡していない。会話の話題は前もって分からないので、リストを用意できない前提で測った。 速さとメモリ LFM3-Audio-2B LFM3-Omni-2B 読み込み 約 12 秒（初回） 約 3 秒 文字を出す速さ 約 43 トークン／秒 約 36 トークン／秒 3〜6 秒の音声の聞き取り（まとめて送る） 0.4〜1.1 秒 0.5〜1.0 秒 llama-server のメモリ（最大） 約 3.7GB 約 4.2GB GPU に載った量（共有メモリ） 約 3.1GB 約 3.7GB 両方とも GPU（Vulkan）で動いた。 会話サポートで気になるのは、話し終わってから文字が出るまでの間だ。llama-server の /v1/realtime（WebSocket で音声を流しながら送る口）に、デモの会議の 23 発話を 100 ミリ秒ずつ実時間の速さで流し、書き起こさせた（LFM3-Audio-2B）。 話し終わってから 中央値 最大 最初の文字まで 0.18 秒 0.21 秒 書き起こしが出そろうまで 0.82 秒 1.33 秒 音声が届いた分から先に読み込んでおく作りなので、話し終わった直後に文字が出始める。23 発話とも途中で止まらずに流れ、文字の誤り率は平均 6.6% で、まとめて送ったときと同じだった。 /v1/realtime には書き起こし専用のセッション（?intent=transcription）もある。言語に日本語を渡したが、この版では設定に反映されず、ローマ字や英語で返ってきた。そこで、会話のセッションのまま、指示を Perform ASR in Japanese. にして文字だけを返させた。上の表はその値。 一般の文と会話の聞き取り 一般の文 6 つ（3〜6 秒）は、両方のモデルで 6 文とも正しかった。違いは「三時」を「3時」と書くような表記だけだった。 デモの会議の 23 発話（VOICEVOX、残響と小さな暗騒音入り）は、文字の誤り率が平均 6.5% だった。誤りは「六十四キロビット毎秒」が「毎ビット」、「通し試験」が「投資試験」、「要約」が「ようやく」になる、といったもので、用語や耳慣れない語の所に集まっていた。同じ 23 発話を Whisper medium で書き起こすと誤り率は 12.1% で、「投資試験」「ようやく」など同じ所で誤っていた（Whisper は数字や英字で書く所が多く、そのぶん誤り率の数字が高く出る）。 専門用語の 12 文 ここが本題。会話サポートでは、聞き慣れない用語を拾って解説を出すので、用語が正しく書けるかを一番重く見ている。 条件 LFM3-Audio-2B LFM3-Omni-2B Whisper medium（ローカル） gpt-4o-mini-transcribe（クラウド） 原音 13/21（62%） 15/21（71%） 16/21（76%） — グラスで録音（SNR 24 dB） 6/21（29%） 7/21（33%） 12/21（57%） 17/21（81%） グラスで録音（SNR 22 dB） 5/21（24%） 5/21（24%） 6/21（29%） 11/21（52%） グラスで録音（SNR 14 dB） 1/21（5%） 1/21（5%） 4/21（19%） 6/21（29%） Whisper medium と gpt-4o-mini-transcribe の値は、同じ 12 文・同じ物差しで以前に測ったもの（中編）。Whisper medium は、手元の GPU で OpenVINO の int8 版（OpenVINO/whisper-medium-int8-ov）を回した。今回あらためて Whisper medium で原音を書き起こすと、17/21 だった。 この条件では、2B の LFM3 は Whisper medium に届かなかった。原音での差は用語 1〜3 語ぶんで、雑音が入ると差が開いた。 用語の一覧を渡せば、取れる語は増えるかもしれない。ただ、会話サポートはどの話題の会話でも使う前提で作っている。あらゆる分野の用語を前もって登録しておくのは現実的ではないし、語を増やすほど、似た音の語を一覧の語に寄せて書く誤りも増えそうだ。そこで今回は、一覧なしで聞き取れる力そのものを測った。 書き起こしを見ると、音としてはかなり近いところまで来ている。 台本の用語 LFM3-Audio-2B の書き起こし（原音） レイテンシ 零点四 オーパス オーバス テザリング 手ざりング フォアグラウンドサービス フワグラウンドサービス 無音化 ブイン化 復号 複合 グラスで録った音では、「ブルートゥース」が「ブルータス」、「ファームウェア側」が「ハウリア川」になった。一方、用語の無い 12 番目の文（「来週の定例ですが、水曜の午後だと参加できない人がいるので、木曜の同じ時間に動かしたいと思っています。」）は、雑音入りでもほぼ正しかった。 以前の試験で分かっていた「雑音の大きさ（SNR）で成績が決まる」という形は、LFM3 でも同じだった。音を拾うところを良くするのが先、という結論は変わらない。 「速報→確定」の作りに当てはめると 会話サポートは、用語の一覧と要約を 2 段で出している。 速報：書き起こしが届いたら、LLM を呼ばずに語を拾い、すぐ一覧に暗い色で出す（聞いたままの語） 確定：次の要約の回で、LLM が専門用語と認めた語を明るい色にし、認めなかった語は消す 要約も、1 回目は始まって 5 秒で粗く出し、そのあと 15 秒ごとに作り直す この作りに当てはめると、測った範囲ではこう整理できる。 求めるもの LFM3-Audio-2B で測った値 速報 早く、聞いたままの語が出ること 話し終わってから 0.82 秒で書き起こしが出そろう。会話の誤り率は 6〜7% 確定 専門用語が正しく書けていること 用語はグラスの音（SNR 24 dB）で 29%。クラウドの 81% には届かない 今の作りでは、書き起こしが届くまで中央 1.2 秒ほどかかっている。ただしこれは区切りの検出や通信を含んだ値で、区切りが分かっている前提の 0.82 秒とそのまま比べられる数字ではない。 速報を LFM3 で早く出し、確定はクラウドの書き起こしで出し直す、という組み合わせは考えられる。ただ、速報の一覧に出る語がほとんど誤った字になるなら、出してすぐ消える語が増えるだけかもしれない。この組み合わせは、まだ試していない。 訳まで広げるなら 会話サポートは今は訳を出していないが、LFM3 は訳も読み上げもできるので、あわせて測った。デモの会議の 23 発話を英語にして、台本と読み比べた。英訳の正解は無いので、意味が落ちたかずれた発話を数えた。 音声から直に英語へ realtime に「英語に訳して、訳だけ返す」と頼み、文字と音声の両方で返させた。 話し終わってから 中央値 最大 最初の英語の文字まで 0.18 秒 1.2 秒 最初の英語の音まで 0.54 秒 1.55 秒 応答の終わりまで 4.3 秒 7.5 秒 速さは会話に間に合う。一方、23 発話中 16 発話で、意味が落ちるかずれた。 台本 英訳 先にセグメンターの話から聞かせてください Please listen to the segmenter's story first. 六十四キロビット毎秒です It is 64 kilobits per minute. ワイファイの方です、遅延の長い尾が消えました It's about Wi-Fi. The length of the delay has disappeared. 図を一枚入れると早いかもしれません It might be faster to put in one more. 速い訳を先に出し、2 段目の訳で置き換える 会話サポートの「速報→確定」と同じ考え方で、訳も 2 段にしてみた。1 段目は上の直の訳。2 段目は、話し終わってから書き起こし、その文字を英訳させる。 話し終わってから 2 段目の訳の文字が出そろうまで、中央値 2.05 秒、最大 3.02 秒。1 段目の最初の文字から 2 秒ほどあとに置き換わる 2 段目も読み上げにするなら、英語の読み上げを作り終えるまでさらに 3.8 秒ほどかかる。字幕だけ置き換え、読み上げは 1 段目のままにする方が、待ちは少ない 意味が落ちたかずれた発話は、直の訳の 16 から、2 段目で 9 に減った 台本 1 段目（直の訳） 2 段目（書き起こしてから訳） 図を一枚入れると早いかもしれません It might be faster to put in one more. Putting in one diagram might be faster. ノイズフロアの推定は分位点に変えたんでしたっけ The noise floor estimate had changed to a different unit. We changed the noise floor estimate to a quantile. オーパスのビットレートは今いくつで送っていますか Are you sending the Opus Bitrate in small pieces? What is the current bitrate of the Opus? 置き換えで直ったのは 9 発話。2 段目でもずれたままの 7 発話は、ほとんどが書き起こしの誤りをそのまま訳したものだった（「毎秒」を「毎ビット」と書き起こして "per bit"、「処理フロー図」を「フローーズ」と書き起こして "Processing Flowers"）。逆に 2 段目で悪くなったものが 2 つあった（「ええ」を「いえ」と書き起こして "No" など）。 前の発話も一緒に渡すと 会話の流れが分かれば、2 段目の訳はもっと正確になるのではないか。そこで、2 段目に前後の発話も渡してみた。書き起こしは LFM3-Audio-2B のものと、比べるために Whisper medium のものの 2 通り。訳はどちらも LFM3-Audio-2B に文字で渡した。 まず、前の 3 発話と次の 1 発話を「BEFORE」「TARGET」「AFTER」の見出しを付けて 1 つの文にまとめて渡した。すると訳が返らず、見出しを繰り返したり途中で切れたりした。2B の大きさでは、この形の指示には沿わなかった。同じ形で書き起こしの誤りを直させる指示も、うまくいかなかった。 次に、前の 3 発話を会話の履歴として渡した（ユーザーの発言に書き起こし、アシスタントの返事にその訳を入れる）。指示文はこうした。 Translate the user's Japanese into natural English. Output only the translation. The earlier turns are from the same meeting; use them as context. 書き起こし 書き起こしの誤り率 音声から直の訳 その発話だけを訳す 前の 3 発話を履歴で渡す LFM3-Audio-2B 6.5% 16/23 がずれ 9/23（1.6 秒） 10/23（1.8 秒） Whisper medium 12.1% — 7/23（1.8 秒） 10/23（2.0 秒） 時間は、話し終わってから 2 段目の訳が出そろうまでの中央値。どの組み合わせでも最大 2.5 秒ほどだった。 前の発話を渡しても、ずれた数は減らなかった。直るものと崩れるものが入れ替わっただけだった（「六十四キロビット毎秒です」は "64 kilobits per second" に直ったが、「オーパス」が "Opa" に崩れた）。 Whisper medium の書き起こしは、数字や英字で書くぶん誤り率の数字は高いが、訳したときに意味が残りやすかった。2 つの書き起こしで共通してずれた 6 発話は、どちらも同じ所で聞き誤っていた（「通し試験」を「投資試験」、「要約」を「ようやく」など）。 2 段目の訳の質は、書き起こしの質で決まるようだ。ここでも、用語の聞き取りが鍵になる。 読み上げ /tts の口で、日本語の文 8 本を読ませた。読み上げを作る時間は、どちらも話す長さの 0.5〜0.9 倍で、実時間より速い（測るたびに 0.6〜0.8 倍ほど揺れた）。 作った音声を同じモデルで聞き直すと、LFM3-Audio-2B は 8 本とも台本どおりだった。LFM3-Omni-2B は 3 本で崩れた（「明日の会議は」が「真下の会議は」、「何ですか」が「を学んだ」に聞こえた）。ただ、同じモデルでの聞き直しは甘い。自分の耳で聞くと、LFM3-Audio-2B も 1 本（男声の「駅までの道を教えていただけますか」が「いただかますか」）で読みが崩れていて、聞き直しではこれを拾えなかった。ほかの読み上げにも、話し方の不自然さが残っていた。 ライセンス LFM3 は LFM Open License v1.0 で配られている。形は Apache License 2.0 とほぼ同じで、再配布するときはライセンスを添え、改変したファイルには改変したことを書く。違うのは商用の条件で、年商 1,000 万ドル以上の事業者による商用利用は、このライセンスでは許されていない（非営利の団体の研究・非商用の利用は除く）。個人で手元の道具に使う分には問題ないようだ。商標は使えない。 持ち帰り 2B の LFM3 は、内蔵 GPU のノート PC で、メモリ 4GB 前後で動いた。話し終わってから 1 秒以内に書き起こしが出そろう速さは、会話の補助に足りる 一般の文と会話の聞き取りは、誤り率 6〜7% だった 専門用語の聞き取りは、この条件では Whisper medium にもクラウドの書き起こしにも届かなかった。用語の解説が目的の会話サポートでは、書き起こしをそのまま置き換えるところまでは行かなかった 「速報→確定」の作りでいえば、LFM3 の速さは速報の側に合い、専門用語は確定の側にまだ届かない 訳まで広げるなら、速い訳を先に出し、書き起こしてから訳した 2 段目で置き換える形にすると、ずれは 16 から 9 に減った。前の発話を一緒に渡しても、それ以上は減らなかった。残りのずれも、もとをたどると書き起こしの誤りだった どの使い方でも、雑音の大きさで成績が決まる形は変わらなかった。モデルを替えるより先に、音を拾うところを良くしたい 次に試したいのは、確定した語と要約を回ごとに積んでいき、話題が近い回の語だけを渡す形である 取得物 リポジトリ ファイル SHA256 ggml-org/llama.cpp（リリース b11972） llama-b11972-bin-win-vulkan-x64.zip 5f3fa9b3ec948e6cb1af3c8f1063fa39c79f58bb5dc9bb9dfb2db890d098508d LiquidAI/LFM3-Audio-2B-GGUF LFM3-Audio-2B-Q8_0.gguf d4e36902ba8f0ee7b333596030a59d650f88ac76660b4d9ba5ff77c3c2258fc0 LiquidAI/LFM3-Audio-2B-GGUF mmproj-LFM3-Audio-2B-Q8_0.gguf 26601e904245a85bd8f3cf320a629e897cfc01c1d09369e8b4fd951f13024d3e LiquidAI/LFM3-Omni-2B-GGUF LFM3-Omni-2B-Q8_0.gguf 59118f661eaacb93d204723d76355b53347f0940b508c11412f6290fd49158d4 LiquidAI/LFM3-Omni-2B-GGUF mmproj-LFM3-Omni-2B-Q8_0.gguf 720ff4fc09df0e026c4ec641d0c698bf27b5bcd50561944c88eda5e3dffe1839 どれも、取得した時点で GitHub と Hugging Face が公開していた値と一致した。その後、Liquid AI は mmproj を差し替えている（音声を作る部分＝コーデックのデコーダを量子化した。Q8_0 は Audio 版が約 338MB→304MB、Omni 版が約 541MB→507MB）。今の mmproj の SHA256 は上の表と違う。この記事の数字は、差し替える前の mmproj で測ったものである。差し替えたあとのファイルでも測り直したが、聞き取りの結果は同じで、メモリが 30〜40MB 減っただけだった。 使った音声 Windows の合成音声（Microsoft Haruka Desktop） VOICEVOX:青山龍星、VOICEVOX:玄野武宏、VOICEVOX:冥鳴ひまり Rokid Glasses の記事 Rokid Glasses を買ってから自作アプリが動くまで —— 購入・技適・ADB・タッチパッドの実機調査 会話サポートを作るまで（前編） —— 読む速さと話す速さは釣り合っていない（表示設計） 会話サポートを作るまで（中編） —— 音声認識は、安いモデルの方が正確だった（認識と補正） 会話サポートを作るまで（後編） —— AudioRecord がエラーも出さずに全部ゼロを返す（録音） 撮った写真を、本体で見られない —— 3つのジェスチャーで削除画面を作ったら、先客がいた 実測値を書いた記事は、いつ嘘になるのか —— ファーム更新に備えて45項目の判定表を作った 録音が暗騒音より小さかった —— 測定値が物理的にありえないなら、疑うのは測定系 Rokid Glasses で自分のアプリを作る —— コードは書けなくていい。ただし PC は要る Rokid Glasses のランチャーは、入口を2つ作っても同じ項目が2つ並ぶだけ —— 名前もアイコンも起動先もパッケージ単位だった Rokid Glasses で Bluetooth の「インターネットアクセス」設定に辿り着けない —— 自作アプリに入口を作って、消した Rokid Glasses の右側の物理ボタンは、キーではなく「合図」で自作アプリに届く —— 押すたびに写真も撮れる Rokid Glasses のマイクは 4ch で使える —— マイクは 4ch 取れる。ただし AudioSource で中身の意味が変わる 答えの分かっている不具合を Opus 5 と 5.5 に渡した（特別編） —— AudioRecord が全部ゼロを返す原因を、実機の記録で採点した プロンプトキャッシュは、変数の位置ひとつで 72% から 0% になる —— 会話サポートの費用を決めていたのは、LLM を呼ぶ回数だった この記事 —— LFM3 の音声モデルは、速さは足りたが、専門用語の聞き取りで Whisper に届かなかった 買ってから自分のアプリが動くまでを順に追いたいなら、無料の本にまとめてある：Rokid Glasses（RV101）を買ってから、自分のアプリが動くまで —— 知識ゼロからの手順書

Crew's first job is four questions: what do I actually need, what do I actually want, what actually helps, and what am I trying to accomplish? Local engine underneath: ggml-org/llama.cpp How do you share one GPU between a local model and games? #LocalLLM #homelab

Betelgeuse: Running Qwen 3.8 Flash Next at 22 tok/s sustained (spiking to 48 tok/s) on an RTX 3060 12GB + 16GB DDR4 RAM 100% bit-exact! About two months ago I posted here about trying to predict which MoE experts get used on the next token to speed up CPU/GPU offload on Qwen 3.6 35B. Quick confession on that older post before anything else: I ended up throwing that prototype away. To get the big numbers I was seeing back then, I was basically cheating with gate pruning (dropping cold experts when their router weights were low). It made the tok/s counter go brrr, but on an already low-bit quant it quietly degraded output quality and reasoning. I didn't want to ship something that lobotomizes the model just to look fast in a screenshot, so I scrapped it. When Qwen 3.8 Flash Next dropped, I wanted to see if we could actually run the 68GB GSQ-RCO-IQ2_XS build at real usable speeds on a normal budget gaming PC—without dropping a single expert. For context, here is the exact box I tested this on (I actually pulled my extra RAM sticks out specifically to test what a regular 16GB PC gets): - GPU: RTX 3060 12GB - RAM: 16GB DDR4, single-channel (~19 GB/s) - OS: CachyOS / Arch Linux (tested inside a strict MemoryMax=12G cgroup) - Storage: Consumer PCIe NVMe SSD (~2.1 GB/s) If you try to load a 68GB MoE on 12GB VRAM + 16GB RAM in stock llama.cpp, you already know what happens: mmap thrashes the OS page cache to death, you get ~1,500 major page faults per token, and generation crawls at 1.47 tok/s. Then I tested Strata. Strata is super cool and hits 40+ tok/s if you have 48GB–64GB of RAM to mlock 24GB+ of experts in system memory. But on a 16GB RAM setup, it refuses to load unless you force --low-ram mmap, where it drops down to 8.11 tok/s because it's bound by cold SSD reads. So over the last week I built Betelgeuse (bel-cli / bel-server, a fork of llama.cpp, and I'm also opening a clean upstream PR for llama.cpp even if it probably won't get merged lol). What it actually does under the hood: - Zero gate pruning / 100% bit-exact: Every single one of the 10 routed experts per layer across all 48 layers is computed at full precision. We verified 28,080 router records and 576 generated tokens byte-for-byte against golden stock output (0.000e+00 diff). - Arrival-Slack VRAM Slot Pool (~5,000 slots in VRAM): All 49 dense layers + GDN + QSA + LM head stay in ~3.2 GB of VRAM. The remaining VRAM holds ~5,000 expert slots distributed non-uniformly (240 slots/layer on early layers 0–4 where there is 0ms of compute slack, 92 on middle layers, 60 on tail layers). - In-Stream GPU Doorbell + 1-Split CUDA Graph Replay: Instead of ggml_backend_sched splitting the graph 48 times per token to ask the CPU which experts missed (which burns ~360ms/token in cudaStreamSynchronize), a custom in-stream CUDA kernel resolves hits in ~2 µs on-device and only rings a mapped host doorbell when an expert is missing. Per-layer token embeddings (per_layer_token_embd) are also staged to CUDA0 so the entire decode pass runs as 1 single CUDA Graph replay. - RAM Victim Cache + io_uring Pager: When an expert gets evicted from the VRAM pool, it moves into a dedicated host RAM victim cache instead of getting thrown away.VRAM and RAM stay 100% exclusive instead of duplicating the same hot experts in the OS page cache. Physical NVMe reads drop from ~71 MB/token down to 12.43 MB/token. - No duplicate 35GB expert bloat on disk: Instead of keeping 35GB of dead expert tensors inside Shard 1 .gguf AND another 35GB in experts.bin, we stripped the expert payloads out of Shard 1 so the main GGUF is only 3.2 GB (Dense.gguf) + 35.3 GB (experts.bin, 4KB-aligned single-read blobs) + **26.8 GB (**PLE.gguf n-gram shard). Measured Results (RTX 3060 12GB + 16GB DDR4, MemoryMax=12G) |Engine|Cold Decode (Run 1)|Warm Decode (Run 2)|Peak Bursts|Prompt Processing (PP)|Physical SSD Reads|Output Parity| |:-|:-|:-|:-|:-|:-|:-| |Stock llama.cpp (mmap)|1.47 tok/s|1.63 tok/s|~2 tok/s|14–20 tok/s|208–312 MiB/tok|Baseline| |Strata (--low-ram mmap)|8.11 tok/s|8.11 tok/s|~9 tok/s|34.6 tok/s|~105 ms pool wait|~0.022 KL| |Betelgeuse (bel-server)|16.80 tok/s|22.03 tok/s|Up to 48 tok/s|16.2 – 19.3 tok/s|12.43 MiB/tok|100% Byte-Exact| On warm runs it holds 21.8–22.03 tok/s sustained across long coding prompts, and when generation hits stretches where all 10 routed experts are resident in the VRAM/victim pools, it spikes up to 48 tok/s. Links & What's Next - GitHub (Betelgeuse Engine — bel-cli & bel-server): [https://github.com/Betelgeuse-AI/Betelgeuse] - HuggingFace (Pre-packed Alpha-Orionis-XS 3.2GB Dense + Experts bundle): https://huggingface.co/Betelgeuse-AI/Alpha-Orionis-XS - Upstream llama.cpp PR: [https://github.com/ggml-org/llama.cpp/pull/31469] 1. Even on the massive Q8_K_XL quant (~190GB total), bel-server runs at 8 tok/s cold and 12 tok/s warm (with bursts up to 21 tok/s) on the exact same 12GB 3060 + 16GB DDR4 box, where stock llama.cpp immediately OOMs or crawls at <0.1 tok/s. 2. Zero experts are dropped or thresholded (0.000e+00 diff across 28,080 router records and 576 tokens vs unmodified stock). The speedup comes from eliminating the 48 per-layer CPU/GPU scheduler splits (KICK/WAIT doorbell around the shared expert), keeping the RAM victim cache strictly exclusive of VRAM (MOE_DROP_MMAP), and pre-staging cold misses via the upgraded oracle + 4KB-aligned io_uring pack. What I'm working on next: We're currently bringing this exact streaming + victim-cache architecture over to DeepSeek V4.1 Flash (1017)—early testing under development is already sitting around ~25 tok/s on the same hardware class. Happy to answer any questions or have people poke holes in the benchmarks! Leave us a Star :)

Yapay Zekayı Kendi Bilgisayarında Çalıştıran 3 GitHub Reposu | Bi Öğren #shorts Yapay zekayı kendi bilgisayarında nasıl çalıştırırsın? Ollama, llama.cpp ve LocalAI nedir? Kısa özet aşağıda. 1) Ollama: açık modelleri yerelde ya da bulutta çalıştır. ollama/ollama 2) llama.cpp: modeli Hugging Face'ten indirip tek komutla çalıştır, OpenAI uyumlu API sunucusu aç. ggml-org/llama.cpp 3) LocalAI: metin, görüntü, ses ve video modelleri tek API arkasında; README'ye göre GPU şart değil. mudler/LocalAI Hangi modelin çalışacağı bilgisayarına bağlı. Kurmadan önce her reponun README'sini oku. Bi Öğren: her gün yeni bir bilgi.

Yapay Zeka Kullananlar İçin 3 Harika Araç | Bi Öğren #shorts Sesi yazıya çevirme nasıl yapılır? Whisper, whisper.cpp ve faster-whisper nedir? Kısa özet aşağıda. 1) Whisper: açık kaynaklı, çok dilli konuşma tanıma modeli. openai/whisper 2) whisper.cpp: aynı modelin bağımlılıksız C/C++ uygulaması. ggml-org/whisper.cpp 3) faster-whisper: README'ye göre aynı doğrulukla orijinalinden 4 kata kadar hızlı. SYSTRAN/faster-whisper Hız bilgisayarına göre değişir. Kurmadan önce README'yi oku. Bi Öğren: her gün yeni bir bilgi.