https://findings.yatabis.dev/ AIやローカル推論などのウォッチから残したFindingのログ。 ja https://findings.yatabis.dev/findings/draw-things-local-code-public-beta/ daily-findings:draw-things-local-code-public-beta Sat, 12 Sep 2026 15:00:00 GMT Draw Thingsは2026年9月12日、Apple App SandboxとHardened Runtimeの内部にLLM推論エンジン・モデル別ハーネス・in-process agent runtimeをまとめたLocal Codeの公開ベータを開始した。DeepSeek 4 Flash 0731の2/3-bit版を48GiB以上で推奨し、Qwen3.8-27Bの2-bit/4-bit版も提供する。Python、Node.js、Lean、ssh、ripgrep等を約500MiBのランタイムへ同梱し、ローカルcoding agentをOS強制の権限境界内で成立させる方向を示した。 <p>WATCH · 記録日 2026-09-13</p><p>Draw Thingsは2026年9月12日、Apple App SandboxとHardened Runtimeの内部にLLM推論エンジン・モデル別ハーネス・in-process agent runtimeをまとめたLocal Codeの公開ベータを開始した。DeepSeek 4 Flash 0731の2/3-bit版を48GiB以上で推奨し、Qwen3.8-27Bの2-bit/4-bit版も提供する。Python、Node.js、Lean、ssh、ripgrep等を約500MiBのランタイムへ同梱し、ローカルcoding agentをOS強制の権限境界内で成立させる方向を示した。</p><h2>所感</h2><p>ローカルcoding agentの安全境界を独自permission layerではなくmacOSのApp Sandboxに置き、推論・ツール実行・モデル固有ハーネスを一体化する設計は新しい実用方向。ただし現状はTestFlightベータで、速度・品質は開発側評価が中心、既存Codex/Claude Code相当の外部ツールチェーン互換性も未確立なので今すぐ乗り換える段階ではない。</p><h2>情報源</h2><ul><li><a href="https://releases.drawthings.ai/p/public-beta-of-local-code-by-draw">Public Beta of Local Code by Draw Things</a></li></ul> apple-silicon coding-agent sandbox local-llm inference-runtime https://findings.yatabis.dev/findings/irodori-v4-1-small-mf-meanflow/ daily-findings:irodori-v4-1-small-mf-meanflow Sat, 12 Sep 2026 15:00:00 GMT Irodori-TTS-v4.1-SmallをMeanFlowで蒸留した公式チェックポイントが公開された。デフォルト4 sampling stepsで、CFGは蒸留時に教師軌道へ組み込まれるため推論時は各stepにつきconditional DiTを1回だけ評価する。4-step MeanFlowは4-step RFを全読字指標で上回り、JVSの約30秒参照ではCAM++ cosine 0.7429、top-1 97.52%で、40-step RFの0.7521、98.56%にかなり近い。Voice Design、voice cloning、長時間参照、emoji制御は維持される。 <p>TRY · 記録日 2026-09-13</p><p>Irodori-TTS-v4.1-SmallをMeanFlowで蒸留した公式チェックポイントが公開された。デフォルト4 sampling stepsで、CFGは蒸留時に教師軌道へ組み込まれるため推論時は各stepにつきconditional DiTを1回だけ評価する。4-step MeanFlowは4-step RFを全読字指標で上回り、JVSの約30秒参照ではCAM++ cosine 0.7429、top-1 97.52%で、40-step RFの0.7521、98.56%にかなり近い。Voice Design、voice cloning、長時間参照、emoji制御は維持される。</p><h2>所感</h2><p>Irodori-TTSの会話用途で最大の懸念だったsampling回数とCFG評価コストを大きく削れる可能性があり、レイテンシ改善の本命候補。Apple Silicon向けMLX移植はまだ確認できないが、公式PyTorch/MPS経路で品質と実効レイテンシを今すぐ試す価値がある。</p><h2>情報源</h2><ul><li><a href="https://huggingface.co/Aratako/Irodori-TTS-v4.1-Small-MF">Aratako/Irodori-TTS-v4.1-Small-MF</a></li><li><a href="https://github.com/Aratako/Irodori-TTS/commit/89f9d8fbd4d51ea019867ee1197725ede1df13c5">Add MeanFlow distillation and v4-Large support</a></li></ul> Irodori-TTS TTS MeanFlow voice-cloning Voice-Design latency https://findings.yatabis.dev/findings/irodori-v4-large-forthcoming/ daily-findings:irodori-v4-large-forthcoming Sat, 12 Sep 2026 15:00:00 GMT 公式Irodori-TTSのmainにforthcoming v4-Largeへの明示的な言及と学習設定が追加された。v4-Large設定はT5Gemma 2 1B-1B系の事前学習text/caption backboneを使い、DiTをmodel_dim 2048・24 layers・32 heads、speaker encoderを1280次元・14 layers・20 headsとする。body学習とduration predictor学習の設定が分離されている。公開weightsや品質ベンチマークはまだない。 <p>WATCH · 記録日 2026-09-13</p><p>公式Irodori-TTSのmainにforthcoming v4-Largeへの明示的な言及と学習設定が追加された。v4-Large設定はT5Gemma 2 1B-1B系の事前学習text/caption backboneを使い、DiTをmodel_dim 2048・24 layers・32 heads、speaker encoderを1280次元・14 layers・20 headsとする。body学習とduration predictor学習の設定が分離されている。公開weightsや品質ベンチマークはまだない。</p><h2>所感</h2><p>v4.1-Smallの改良だけでなく、明確に大型化した次世代Irodoriが進行している。音質・表現力・Voice Design追従性が上がる可能性がある一方、実際のモデルサイズ、配布時期、Apple Silicon/MLX対応、推論速度は未確定なので現時点では追跡対象。</p><h2>情報源</h2><ul><li><a href="https://github.com/Aratako/Irodori-TTS/commit/89f9d8fbd4d51ea019867ee1197725ede1df13c5">Add MeanFlow distillation and v4-Large support</a></li></ul> Irodori-TTS TTS v4-Large Voice-Design voice-cloning https://findings.yatabis.dev/findings/omlx-agent-kv-cache-artifact-export-import/ daily-findings:omlx-agent-kv-cache-artifact-export-import Sat, 12 Sep 2026 15:00:00 GMT oMLX draft PR #3615は、engine管理のpaged SSD cacheを外部agentが保持できるartifactへexport/importする仕組みを提案する。artifactはblock chainとGDN sidecarをbyte-identicalに保存し、token chain、model identity、cache signature、SHA-256をfail-closedで検証して再登録する。再起動後も長いprefixを再prefillせず復元できる一方、現状はsingle-node限定でMTP draft stateは保存しない。 <p>HOLD · 記録日 2026-09-13</p><p>oMLX draft PR #3615は、engine管理のpaged SSD cacheを外部agentが保持できるartifactへexport/importする仕組みを提案する。artifactはblock chainとGDN sidecarをbyte-identicalに保存し、token chain、model identity、cache signature、SHA-256をfail-closedで検証して再登録する。再起動後も長いprefixを再prefillせず復元できる一方、現状はsingle-node限定でMTP draft stateは保存しない。</p><h2>所感</h2><p>prefix cacheを単なるengine内部LRUではなくportableなstate artifactとして扱う境界は、長寿命agentとruntimeを分離するうえで有用。ただしformat、cluster restore、speculative stateの扱いが未確定なので現時点では設計監視に留める。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3615">oMLX PR #3615: Add agent-facing KV cache export/import artifacts (draft, RFC)</a></li></ul> mlx kv-cache ssd agent state-persistence https://findings.yatabis.dev/findings/omlx-checkpoint-backed-moe-expert-offload/ daily-findings:omlx-checkpoint-backed-moe-expert-offload Sat, 12 Sep 2026 15:00:00 GMT oMLX PR #2595は、MoEの非resident expertをcheckpoint自身のsafetensors mmapからcache miss時に読み込む固定slot LRU cacheをmainへ統合した。Gemma-4-26B-A4B 4-bitではresident 100%の14.20GB・122.5 tok/sから、50%で7.78GB・59.4 tok/s、25%で4.57GB・40.1 tok/s、12.5%で2.96GB・29.3 tok/sとなり、25%では受入テストのgreedy生成がresident版とbit-identicalだった。OLMoE-1B-7Bでも3.89GBから1.17GBへの削減を確認している。 <p>WATCH · 記録日 2026-09-13</p><p>oMLX PR #2595は、MoEの非resident expertをcheckpoint自身のsafetensors mmapからcache miss時に読み込む固定slot LRU cacheをmainへ統合した。Gemma-4-26B-A4B 4-bitではresident 100%の14.20GB・122.5 tok/sから、50%で7.78GB・59.4 tok/s、25%で4.57GB・40.1 tok/s、12.5%で2.96GB・29.3 tok/sとなり、25%では受入テストのgreedy生成がresident版とbit-identicalだった。OLMoE-1B-7Bでも3.89GBから1.17GBへの削減を確認している。</p><h2>所感</h2><p>モデル全体を低bit化して品質を落とす代わりに、選ばれたexpertだけを正確なweightのままresident化し残りをSSDから取ることで、Unified Memory上限を超えるMoEを動かす設計が実装段階に入った。64GB Macでより大きなMoEを扱う方向として重要だが、低resident率ではTTFT/decodeが大きく落ち、Qwen3.6/3.8やGLM-5系の実機検証もまだ不足している。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/2595">oMLX PR #2595: expert offload — stream non-resident experts from the checkpoint</a></li></ul> omlx mlx moe expert-offload apple-silicon ssd https://findings.yatabis.dev/findings/omlx-m5-pro-ane-prefill-split/ daily-findings:omlx-m5-pro-ane-prefill-split Sat, 12 Sep 2026 15:00:00 GMT oMLX PR #3604はM5 Pro 64GB、Qwen3.8-27B-oQ4e-mtpでANE prefillのsplit sweepを公開した。2048-token測定ではMLP share 35%付近でANEとGPUのper-layer時間が釣り合い、16,317-tokenの実server runではGPU-onlyよりTTFTが8〜11%短縮した。GDN shareはmodelのz floor 37.5%未満だとprocedureが一つもcompileされず、decodeはGPUのままで変化しない。 <p>WATCH · 記録日 2026-09-13</p><p>oMLX PR #3604はM5 Pro 64GB、Qwen3.8-27B-oQ4e-mtpでANE prefillのsplit sweepを公開した。2048-token測定ではMLP share 35%付近でANEとGPUのper-layer時間が釣り合い、16,317-tokenの実server runではGPU-onlyよりTTFTが8〜11%短縮した。GDN shareはmodelのz floor 37.5%未満だとprocedureが一つもcompileされず、decodeはGPUのままで変化しない。</p><h2>所感</h2><p>M5世代ではNAX GPUが強く、過去世代のANE分割率を固定で流用できない。M5 Ultra向けには実機でGPU/ANEのper-layer completion timeを測ってsplitをautotuneする設計が重要だが、Ultra固有データはまだない。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3604">oMLX PR #3604: docs(ane): add M5 Pro single-ANE reference result for Qwen3.8-27B</a></li></ul> mlx ane m5 prefill heterogeneous-compute https://findings.yatabis.dev/findings/omlx-qwen4-yarn-rope-long-context-correctness/ daily-findings:omlx-qwen4-yarn-rope-long-context-correctness Sat, 12 Sep 2026 15:00:00 GMT oMLX PR #3594は、Qwen3.8-Flash-Nextのrope_parametersに指定されたstatic YaRNがpinned mlx-vlmでは無視され、262,144 token超でunscaled RoPEのまま動く問題を修正する。attention、QSA indexer、MTPで同じrotary stateを共有し、未知のRoPE形式はfail-closedにする。Metal fused mRoPEはattention scalingを表現できない場合eagerへfallbackし、SpecPrefillはscaled RoPEと非互換として扱う。M5 Max 128GBで350K tokenまでfield validationされている。 <p>TRY · 記録日 2026-09-13</p><p>oMLX PR #3594は、Qwen3.8-Flash-Nextのrope_parametersに指定されたstatic YaRNがpinned mlx-vlmでは無視され、262,144 token超でunscaled RoPEのまま動く問題を修正する。attention、QSA indexer、MTPで同じrotary stateを共有し、未知のRoPE形式はfail-closedにする。Metal fused mRoPEはattention scalingを表現できない場合eagerへfallbackし、SpecPrefillはscaled RoPEと非互換として扱う。M5 Max 128GBで350K tokenまでfield validationされている。</p><h2>所感</h2><p>長文拡張はmodel settingではなくexecution semanticsであり、attention本体だけでなくsparse index、speculative path、fused kernelまで同じposition transformを共有しなければ静かに誤る。独自runtimeではRoPE capabilityをExecutionPlanの合法性条件に含めるべき。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3594">oMLX PR #3594: feat(qwen4_exp): honor YaRN rope_parameters for long-context extension</a></li></ul> mlx qwen long-context rope correctness https://findings.yatabis.dev/findings/rapid-mlx-moe-fusion-reference-lifetime/ daily-findings:rapid-mlx-moe-fusion-reference-lifetime Sat, 12 Sep 2026 15:00:00 GMT Rapid-MLX PR #3353は、gate/up fusion前のnamed_modules()列挙が削除済みup_projへの強参照を全layer分保持し、181.7GBのGLM-5.3-Flash-Nextを256GB M3 Ultraでloadした際にmemory pressureでprocessが終了する問題を修正した。対象parentだけを保持するstreamingなrewriteへ変更し、42 layerのfusionと32K contextまでの実server検証を完了した。decode改善は短文で約1.1〜1.7%に留まり、主効果はload-time transient memoryの抑制。 <p>TRY · 記録日 2026-09-13</p><p>Rapid-MLX PR #3353は、gate/up fusion前のnamed_modules()列挙が削除済みup_projへの強参照を全layer分保持し、181.7GBのGLM-5.3-Flash-Nextを256GB M3 Ultraでloadした際にmemory pressureでprocessが終了する問題を修正した。対象parentだけを保持するstreamingなrewriteへ変更し、42 layerのfusionと32K contextまでの実server検証を完了した。decode改善は短文で約1.1〜1.7%に留まり、主効果はload-time transient memoryの抑制。</p><h2>所感</h2><p>巨大MoEを256GB級Unified Memoryへ載せる場合、変換アルゴリズムがlayer単位でも探索用containerの参照寿命でpeak memoryが破綻し得る。weight layout変換には明示的なreference lifetimeとweak-reference回帰テストを持たせるべき。</p><h2>情報源</h2><ul><li><a href="https://github.com/raullenchai/Rapid-MLX/pull/3353">Rapid-MLX PR #3353: fix(moe): release projection buffers during fusion</a></li></ul> mlx moe memory weight-layout fusion https://findings.yatabis.dev/findings/rapid-mlx-prefill-snapshot-tile-alignment/ daily-findings:rapid-mlx-prefill-snapshot-tile-alignment Sat, 12 Sep 2026 15:00:00 GMT Rapid-MLX PR #3351は、メッセージ境界でprefillを分割するとMLXの量子化matmulが32行単位で課金されるため、非整列なsnapshot境界が余分なtileを発生させる問題を修正する。M4 ProのQwen3.8-27B-4bitでは短いcold TTFTが642.2msから401.7ms、約500-token prefixを共有する後続turnが699.0msから410.1msへ短縮された。境界は絶対位置ではなく再利用済みprefix後の未計算segmentに対して整列し、tile costが増えない非整列splitは保持する。 <p>TRY · 記録日 2026-09-13</p><p>Rapid-MLX PR #3351は、メッセージ境界でprefillを分割するとMLXの量子化matmulが32行単位で課金されるため、非整列なsnapshot境界が余分なtileを発生させる問題を修正する。M4 ProのQwen3.8-27B-4bitでは短いcold TTFTが642.2msから401.7ms、約500-token prefixを共有する後続turnが699.0msから410.1msへ短縮された。境界は絶対位置ではなく再利用済みprefix後の未計算segmentに対して整列し、tile costが増えない非整列splitは保持する。</p><h2>所感</h2><p>cache checkpointの粒度は意味上のmessage境界だけでなくkernelの実際の計算粒度に合わせる必要がある。独自MLX runtimeではsnapshot/checkpoint候補をExecutionPlanのkernel tile geometryと同じcost modelで評価する価値が高い。</p><h2>情報源</h2><ul><li><a href="https://github.com/raullenchai/Rapid-MLX/pull/3351">Rapid-MLX PR #3351: perf(prefill): align the prompt-cache snapshot split to whole prefill tiles</a></li></ul> mlx prefill prefix-cache scheduler quantization https://findings.yatabis.dev/findings/rapid-mlx-qwen36-fused-router-gdn-decode/ daily-findings:rapid-mlx-qwen36-fused-router-gdn-decode Sat, 12 Sep 2026 15:00:00 GMT Rapid-MLXは2026年9月13日、Qwen3.6-35B-A3B向けにMoE router top-kとGatedDeltaNet single-token decodeの専用Metal fusionをmainへmergeした。M3 Ultra 256GBの4-bit checkpointでrouter単体は中央値+5.1%、GDN fusionは114.65から128.00 tok/sで+11.7%。先行するgate/up・projection等のfusionを含むmain全体では約89から128 tok/s（約+44%）と報告され、対象A/Bではtoken列とstateの同一性を検証している。 <p>HOLD · 記録日 2026-09-13</p><p>Rapid-MLXは2026年9月13日、Qwen3.6-35B-A3B向けにMoE router top-kとGatedDeltaNet single-token decodeの専用Metal fusionをmainへmergeした。M3 Ultra 256GBの4-bit checkpointでrouter単体は中央値+5.1%、GDN fusionは114.65から128.00 tok/sで+11.7%。先行するgate/up・projection等のfusionを含むmain全体では約89から128 tok/s（約+44%）と報告され、対象A/Bではtoken列とstateの同一性を検証している。</p><h2>所感</h2><p>ユーザーのQwen3.6-35B-A3B級という現行baselineへ直接効く最適化で、汎用MLX経路の小kernel launchをモデル形状に合わせて融合する余地がまだ大きいことを示す。ただし最新stable 0.14.1には未収録で、M4 Pro 64GBでの同条件A/Bもない。次のstable releaseで両PRが入った時点で、現行MLX/llama.cpp運用との比較対象にする価値がある。</p><h2>情報源</h2><ul><li><a href="https://github.com/raullenchai/Rapid-MLX/pull/3381">Rapid-MLX PR #3381: fuse Qwen3.6 MoE router top-k</a></li><li><a href="https://github.com/raullenchai/Rapid-MLX/pull/3383">Rapid-MLX PR #3383: fuse Qwen3.6 GDN single-token decode</a></li></ul> rapid-mlx qwen3-6 metal gated-deltanet moe apple-silicon https://findings.yatabis.dev/findings/deepseek-v41-ced-prefill-bounded-replay/ daily-findings:deepseek-v41-ced-prefill-bounded-replay Fri, 11 Sep 2026 15:00:00 GMT oMLXのdraft PR #3607は、DeepSeek V4.1 FlashのCausal Encoder-Decoder構造を利用し、prefill時にdecoder後半のattentionとMoEを末尾のsliding-window tokenだけへ限定する実装を追加した。M3 Ultra 512GBとoQ4e-mtpで21.4K tokenのcold prefillが約430 tok/sから約700 tok/sへ63%向上し、DSpark decodeのacceptanceは概ね維持された。 <p>WATCH · 記録日 2026-09-12</p><p>oMLXのdraft PR #3607は、DeepSeek V4.1 FlashのCausal Encoder-Decoder構造を利用し、prefill時にdecoder後半のattentionとMoEを末尾のsliding-window tokenだけへ限定する実装を追加した。M3 Ultra 512GBとoQ4e-mtpで21.4K tokenのcold prefillが約430 tok/sから約700 tok/sへ63%向上し、DSpark decodeのacceptanceは概ね維持された。</p><h2>所感</h2><p>CEDが単なる論文上のactive-parameter削減ではなく、Apple Siliconのローカルruntimeでprefill計算そのものを大きく省略できることを示す初期実装。input-heavyなagent workloadでは将来のTTFTを大きく縮めうる。一方で現状はdraft、単一機種・単一モデルの開発者実測で、bounded replayは末尾queryの初期windowを近似するため広範な品質検証がなく、M4 Pro 64GBにはモデル自体が収まらない。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3607">feat(deepseek_v41): CED prefill skip with SWA bounded replay</a></li><li><a href="https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash">DeepSeek-V4.1-Flash</a></li></ul> omlx deepseek-v4-1 ced prefill apple-silicon architecture https://findings.yatabis.dev/findings/deepseek-v41-engram-ssd-tiering/ daily-findings:deepseek-v41-engram-ssd-tiering Fri, 11 Sep 2026 15:00:00 GMT oMLX PR #3574 はDeepSeek V4.1 FlashにDSpark MTPとEngram RAM/SSD modeを追加し、M3 Ultra 512GiBのoQ4eでEngram RAM時のpeak MLX約404GiBに対しSSD offloadでは約290GiBまで削減しつつ、4K〜64Kのprefill/decode速度をほぼ維持した。実装はEngram tableをpackedのまま保持し、SSD modeで選択pageをprefetchする。 <p>HOLD · 記録日 2026-09-12</p><p>oMLX PR #3574 はDeepSeek V4.1 FlashにDSpark MTPとEngram RAM/SSD modeを追加し、M3 Ultra 512GiBのoQ4eでEngram RAM時のpeak MLX約404GiBに対しSSD offloadでは約290GiBまで削減しつつ、4K〜64Kのprefill/decode速度をほぼ維持した。実装はEngram tableをpackedのまま保持し、SSD modeで選択pageをprefetchする。</p><h2>所感</h2><p>MoE expertとは別に、table型の静的retrieval stateを独立したstorage tierへ落とす設計が成立する実例。将来の巨大モデル向けResidencyPlanにEngram/lookup table tierを持たせる価値がある。一方256GiB機ではoQ3eでもloader estimateが約251.34GiBで余裕がほぼなく、より高精度量子化を使う用途では現状実用条件を満たさない。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3574">feat: add DeepSeek V4.1 Flash with DSpark MTP and Engram SSD offload</a></li></ul> omlx deepseek-v4.1 ssd-offload engram mtp memory https://findings.yatabis.dev/findings/metal-tensor-slice-2gib-wrap/ daily-findings:metal-tensor-slice-2gib-wrap Fri, 11 Sep 2026 15:00:00 GMT llama.cpp PR #28748 はM5 MacBook Airで、Metal Tensor APIのtensor.sliceがbaseからのslice開始offsetが0x80000000以上になると実アドレスを4GiB手前に生成する再現を報告した。修正はsliceを使わず、64-bit pointer arithmeticでtile先頭を計算してそのpointerからtensorを構築する。 <p>TRY · 記録日 2026-09-12</p><p>llama.cpp PR #28748 はM5 MacBook Airで、Metal Tensor APIのtensor.sliceがbaseからのslice開始offsetが0x80000000以上になると実アドレスを4GiB手前に生成する再現を報告した。修正はsliceを使わず、64-bit pointer arithmeticでtile先頭を計算してそのpointerからtensorを構築する。</p><h2>所感</h2><p>大きなweight/output bufferを扱うM5 Ultraでは2GiB境界は容易に踏む。独自Metal kernelのcorrectness suiteに2GiB直前・直後のaddressing regressionを入れ、Tensor APIのbase-relative sliceに依存しない大規模buffer addressingを優先して検証する価値がある。</p><h2>情報源</h2><ul><li><a href="https://github.com/ggml-org/llama.cpp/pull/28748">metal: fix metal tensor kernel_mul_mm error for large tensor</a></li></ul> llama.cpp metal correctness m5 large-buffer https://findings.yatabis.dev/findings/mlx-custom-kernel-cache-source-hash/ daily-findings:mlx-custom-kernel-cache-source-hash Fri, 11 Sep 2026 15:00:00 GMT MLX PR #4489 は同じkernel名でsourceを変えるcustom kernel実行時、従来のname-keyed cacheがclear_library()を呼び、実行中command bufferが参照するMTLComputePipelineStateを破棄してSIGABRTを起こし得ると報告した。提案修正はsource hashをkeyにして複数variantを共存させる方式。PR自体は未マージでclosed。 <p>TRY · 記録日 2026-09-12</p><p>MLX PR #4489 は同じkernel名でsourceを変えるcustom kernel実行時、従来のname-keyed cacheがclear_library()を呼び、実行中command bufferが参照するMTLComputePipelineStateを破棄してSIGABRTを起こし得ると報告した。提案修正はsource hashをkeyにして複数variantを共存させる方式。PR自体は未マージでclosed。</p><h2>所感</h2><p>shapeやdtypeごとにcustom Metal kernelを生成・autotuneする独自runtimeでは、kernel cacheのidentityとlifetimeが実行安全性に直結する。source/specializationを含むcontent-addressed keyを使い、in-flight pipelineをevictしない契約を早い段階で入れておく価値がある。</p><h2>情報源</h2><ul><li><a href="https://github.com/ml-explore/mlx/pull/4489">fix: hash-based custom kernel cache to avoid clear_library</a></li></ul> mlx metal kernel-cache autotune correctness https://findings.yatabis.dev/findings/mlx-d512-nax-head-split/ daily-findings:mlx-d512-nax-head-split Fri, 11 Sep 2026 15:00:00 GMT MLX PR #4487 はNAX GPU向けD512 self-attentionでhead dimensionを4つのsimdgroupに分割し、各groupがDの一部を担当してQKの部分和だけをthreadgroup memoryで交換する実装を追加する。Gemma 4 31Bの16Kでピークメモリ23.9515GB→22.0368GB、Gemma 4 12Bの65Kで13.8004GB→9.5775GBとなり、prompt/generation性能は変わらないと報告されている。 <p>TRY · 記録日 2026-09-12</p><p>MLX PR #4487 はNAX GPU向けD512 self-attentionでhead dimensionを4つのsimdgroupに分割し、各groupがDの一部を担当してQKの部分和だけをthreadgroup memoryで交換する実装を追加する。Gemma 4 31Bの16Kでピークメモリ23.9515GB→22.0368GB、Gemma 4 12Bの65Kで13.8004GB→9.5775GBとなり、prompt/generation性能は変わらないと報告されている。</p><h2>所感</h2><p>wide-head attentionでは演算量だけでなくsimdgroupごとのaccumulator working setがメモリ圧と実装可能性を決める。独自MLX runtimeのattention plannerでhead dimension分割数を候補化し、M5 Ultra実機でD256/D512のsplit数をautotuneする価値がある。</p><h2>情報源</h2><ul><li><a href="https://github.com/ml-explore/mlx/pull/4487">Improve metal memory usage for SDPA D512</a></li></ul> mlx metal attention nax memory m5 https://findings.yatabis.dev/findings/omlx-affine8-kv-cache/ daily-findings:omlx-affine8-kv-cache Fri, 11 Sep 2026 15:00:00 GMT oMLX PR #3582 はper-vector FP32 scaleを使うsigned-affine 8-bit KV cacheを追加し、incremental prefill compression、portable MLX fallback、prefix/SSD persistence、M5-native attentionを同じcapability lifecycleに統合する。D256のK/V vectorはFP16 512Bに対して260Bで、250K attention-onlyではtested geometryでnative FP16より1.0〜31.2%低いmedian latencyを報告する。 <p>HOLD · 記録日 2026-09-12</p><p>oMLX PR #3582 はper-vector FP32 scaleを使うsigned-affine 8-bit KV cacheを追加し、incremental prefill compression、portable MLX fallback、prefix/SSD persistence、M5-native attentionを同じcapability lifecycleに統合する。D256のK/V vectorはFP16 512Bに対して260Bで、250K attention-onlyではtested geometryでnative FP16より1.0〜31.2%低いmedian latencyを報告する。</p><h2>所感</h2><p>KV formatを単独のcodecではなくattention kernel・persistence・admission accountingまで含むcapabilityとして設計する好例。8-bitは4-bitより品質余裕を取りやすく長文用途に現実的だが、PRはAffine4の未マージPR #3499に依存し、semantic qualityやretrieval accuracyも未検証なので現時点では導入を保留する。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3582">feat: add generic Affine8 KV cache with M5 acceleration</a></li></ul> omlx kv-cache quantization m5 long-context https://findings.yatabis.dev/findings/deepseek-v4-1-reap-2bit-apple-negative-qualification/ daily-findings:deepseek-v4-1-reap-2bit-apple-negative-qualification Thu, 10 Sep 2026 15:00:00 GMT Rapid-MLX 0.14.1はDeepSeek V4.1 Flashのnative affine 2-bit REAP実験を公開した。384 routed expertsを336へ削り、平均99.9949%のrouting massを保持した約199 GiBのartifactはM3 Ultra 256 GiBで213.51 GBのMLX memoryを使用し、best short-decodeでも7.92 tok/sだった。Rapid-MLXの12 tok/s product gateを通らずcatalogには追加されていない。報告ではexpert総数を減らしても各tokenが実行する6 expertsの幅は変わらず、保存容量の削減がdecode compute削減へ直結しないことを明示している。 <p>WATCH · 記録日 2026-09-11</p><p>Rapid-MLX 0.14.1はDeepSeek V4.1 Flashのnative affine 2-bit REAP実験を公開した。384 routed expertsを336へ削り、平均99.9949%のrouting massを保持した約199 GiBのartifactはM3 Ultra 256 GiBで213.51 GBのMLX memoryを使用し、best short-decodeでも7.92 tok/sだった。Rapid-MLXの12 tok/s product gateを通らずcatalogには追加されていない。報告ではexpert総数を減らしても各tokenが実行する6 expertsの幅は変わらず、保存容量の削減がdecode compute削減へ直結しないことを明示している。</p><h2>所感</h2><p>REAP系のexpert pruningを大規模MoEのApple Silicon適合策として見る際、容量削減とdecode高速化を分けて考える必要があるという実測。64GB機では対象外だが、今後より大きなMoEをローカル化する設計判断に有用な負の結果。</p><h2>情報源</h2><ul><li><a href="https://github.com/raullenchai/Rapid-MLX/releases/tag/v0.14.1">Rapid-MLX v0.14.1</a></li><li><a href="https://github.com/raullenchai/Rapid-MLX/commit/cc8681a2b4903d2142e96c26f56f52e036a438d4">bench: qualify native 2-bit V4.1 REAP artifact (#3301)</a></li></ul> deepseek-v4-1 reap moe apple-silicon quantization https://findings.yatabis.dev/findings/llama-qsa-incremental-pooled-key-cache/ daily-findings:llama-qsa-incremental-pooled-key-cache Thu, 10 Sep 2026 15:00:00 GMT llama.cpp PR #28699ではQwen3.8-Flash-NextのQSA indexerが各decode step・各QSA layerで全contextからblock summary keyを再計算していた経路を、完了済みblockごとにf32 summary rowを保存する増分cacheへ変更した。新しく完了したblockだけpool・normalize・RoPEし、rollbackやcopy系操作はsequenceごとのwatermarkで整合させる。8-GPU CUDA測定では63k/114k contextでdecodeが約9.3〜9.4%改善し、prefillはほぼ不変だった。 <p>WATCH · 記録日 2026-09-11</p><p>llama.cpp PR #28699ではQwen3.8-Flash-NextのQSA indexerが各decode step・各QSA layerで全contextからblock summary keyを再計算していた経路を、完了済みblockごとにf32 summary rowを保存する増分cacheへ変更した。新しく完了したblockだけpool・normalize・RoPEし、rollbackやcopy系操作はsequenceごとのwatermarkで整合させる。8-GPU CUDA測定では63k/114k contextでdecodeが約9.3〜9.4%改善し、prefillはほぼ不変だった。</p><h2>所感</h2><p>長文decodeでcontext長に比例するindexer前処理を毎token繰り返さずに済む設計で、MLXへもアルゴリズムとして移植しやすい。ただし現時点の公開実測はCUDAでApple Silicon上の効果が未確認のため、まずwatchしてM5系で同じボトルネックをprofileしてから実装判断する。</p><h2>情報源</h2><ul><li><a href="https://github.com/ggml-org/llama.cpp/pull/28699">llama.cpp PR #28699: incremental pooled-key cache for the QSA indexer</a></li></ul> QSA Qwen3.8-Flash-Next llama.cpp KV cache long context rollback https://findings.yatabis.dev/findings/mercury-2-5-diffusion-llm-production-maturity/ daily-findings:mercury-2-5-diffusion-llm-production-maturity Thu, 10 Sep 2026 15:00:00 GMT Inceptionは2026年9月8日にMercury 2.5を公開した。自己回帰ではなく複数トークンを反復的に精緻化する拡散型LLMで、260Kコンテキスト、調整可能な推論、並列ツール呼び出し、スキーマ準拠JSONを提供する。開発元は広く入手可能なNVIDIA GPUで1,107 tok/sを主張し、Augment CodeではMercury系をコンテキスト圧縮やMCPツール検索に本番利用していると報告している。一方、標準ベンチマークの独立検証はまだ乏しく、weightsは非公開でAPI提供のみ。 <p>WATCH · 記録日 2026-09-11</p><p>Inceptionは2026年9月8日にMercury 2.5を公開した。自己回帰ではなく複数トークンを反復的に精緻化する拡散型LLMで、260Kコンテキスト、調整可能な推論、並列ツール呼び出し、スキーマ準拠JSONを提供する。開発元は広く入手可能なNVIDIA GPUで1,107 tok/sを主張し、Augment CodeではMercury系をコンテキスト圧縮やMCPツール検索に本番利用していると報告している。一方、標準ベンチマークの独立検証はまだ乏しく、weightsは非公開でAPI提供のみ。</p><h2>所感</h2><p>拡散型テキスト生成が単なる高速デモではなく、ツール利用を伴うproduction agentの補助呼び出しで成立している点が重要。将来open-weight化やローカルruntimeが進めば、自己回帰前提のdecode設計とは別の実用的推論経路になり得る。ただし現状はローカル実行できず、品質・速度の主要数字も開発元主張なので試す対象ではない。</p><h2>情報源</h2><ul><li><a href="https://www.inceptionlabs.ai/blog/introducing-mercury-2-5">Introducing Mercury 2.5</a></li><li><a href="https://runtimewire.com/article/inception-mercury-2-5-diffusion-language-model-launch">Inception ships Mercury 2.5 at 1,107 tokens per second, by its count</a></li></ul> diffusion-llm inference-architecture agents production https://findings.yatabis.dev/findings/mlxcel-looped-model-owned-sequence-state/ daily-findings:mlxcel-looped-model-owned-sequence-state Thu, 10 Sep 2026 15:00:00 GMT mlxcelはIQuest-Coder Loopの2-pass decoderを実装し、同じ80層を同じ重みで2回通す構造に対して、各layerがpass 1のdense KVとpass 2の64-token rotating KVを別々に保持するModelOwnedSequenceStateを導入した。flatなVec<KVCache>では表現せず、snapshot/prefix cache・padded prefill・batched decodeなどはstate contractが未整備なため明示的に無効化している。 <p>WATCH · 記録日 2026-09-11</p><p>mlxcelはIQuest-Coder Loopの2-pass decoderを実装し、同じ80層を同じ重みで2回通す構造に対して、各layerがpass 1のdense KVとpass 2の64-token rotating KVを別々に保持するModelOwnedSequenceStateを導入した。flatなVec&lt;KVCache&gt;では表現せず、snapshot/prefix cache・padded prefill・batched decodeなどはstate contractが未整備なため明示的に無効化している。</p><h2>所感</h2><p>looped/recurrent系の新アーキテクチャでは『各layerに1個のKV cache』というruntime前提が崩れる。独自MLX runtimeのStateBundleを最初からモデル固有のnested stateを持てる形にしておく根拠になる。一方この実装のMetal workspace gateは未実行で、今すぐモデル対応する必要まではない。</p><h2>情報源</h2><ul><li><a href="https://github.com/lablup/mlxcel/commit/86d35b2f25fde87172f429eb485206dfc23a0513">mlxcel commit 86d35b2: add IQuest-Coder Loop two-pass decoder</a></li><li><a href="https://github.com/lablup/mlxcel/releases/tag/v0.7.0">mlxcel v0.7.0</a></li></ul> mlxcel Looped Transformer state management KV cache new architecture Apple Silicon https://findings.yatabis.dev/findings/omlx-mtp-parked-head-priming/ daily-findings:omlx-mtp-parked-head-priming Thu, 10 Sep 2026 15:00:00 GMT oMLXのQwen3.8-Flash-Next向けPRでは、適応MTPが一時的に通常decodeへ戻った際にdraft head cacheを捨てず、通常decode中のhidden stateと次tokenを32 token単位でまとめてMTP headへ流して追従させる。68k token級のprose例では、154 token後にMTPをparkした後も再試行時に約68.6kまでprimedされた状態から復帰し、残り742 tokenをMTPで処理できた。 <p>TRY · 記録日 2026-09-11</p><p>oMLXのQwen3.8-Flash-Next向けPRでは、適応MTPが一時的に通常decodeへ戻った際にdraft head cacheを捨てず、通常decode中のhidden stateと次tokenを32 token単位でまとめてMTP headへ流して追従させる。68k token級のprose例では、154 token後にMTPをparkした後も再試行時に約68.6kまでprimedされた状態から復帰し、残り742 tokenをMTPで処理できた。</p><h2>所感</h2><p>speculationを単純なon/offではなく、parked-but-primedを含む永続的な状態機械として設計する根拠になる。既存のmtp_forwardを使う制御・state管理中心の変更なので、MLXベースの独自runtimeへ比較的移植しやすい。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3553">oMLX PR #3553: Qwen3.8-Flash-Next decode optimizations</a></li></ul> Apple Silicon MLX oMLX MTP speculative decoding state management https://findings.yatabis.dev/findings/omlx-workload-aware-paged-cache-block/ daily-findings:omlx-workload-aware-paged-cache-block Thu, 10 Sep 2026 15:00:00 GMT oMLX PR #3557では、Qwen3.8-27Bのモデル形状由来4096-token blockが約3.6k-tokenのcoding-agent system promptを丸ごと再利用不能にしていた。M3 Max 64GBでblockを512へ変更すると、20タスクの中央値でprefix hit率59.8%→88.7%、再prefill token数-64.3%、TTFT 18.35→5.92秒、suite wall time -38.5%となり、decodeは-3.6%だった。 <p>TRY · 記録日 2026-09-11</p><p>oMLX PR #3557では、Qwen3.8-27Bのモデル形状由来4096-token blockが約3.6k-tokenのcoding-agent system promptを丸ごと再利用不能にしていた。M3 Max 64GBでblockを512へ変更すると、20タスクの中央値でprefix hit率59.8%→88.7%、再prefill token数-64.3%、TTFT 18.35→5.92秒、suite wall time -38.5%となり、decodeは-3.6%だった。</p><h2>所感</h2><p>cache block sizeをモデルのrecurrent/prefill geometryだけで決めると、実際の安定prefix長との境界ずれで大きな再計算が起きる。独自runtimeではprefill演算粒度とcache persistence粒度を分離し、workload統計からblock sizeを選ぶautotune対象にする価値が高い。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3557">oMLX PR #3557: allow overriding resolved paged cache block size</a></li></ul> Apple Silicon MLX oMLX paged cache prefix cache scheduler agent https://findings.yatabis.dev/findings/deepseek-v4-1-flash-new-architecture/ daily-findings:deepseek-v4-1-flash-new-architecture Wed, 09 Sep 2026 15:00:00 GMT 9月8日の期間限定プレビューから正式リリースへ移行し、DeepSeekはV4.1 Flashを新アーキテクチャ系の最小モデルとして公開した。公開技術資料を引用した複数の確認では、552B backboneに約196BのEngramメモリを組み合わせ、prefill時8B・decode時16Bを活性化する非対称構成とされる。公式weightsも公開された一方、checkpointは数百GB級で、M4 Pro 64GBのローカル実用範囲から大きく外れる。 <p>WATCH · 記録日 2026-09-10</p><p>9月8日の期間限定プレビューから正式リリースへ移行し、DeepSeekはV4.1 Flashを新アーキテクチャ系の最小モデルとして公開した。公開技術資料を引用した複数の確認では、552B backboneに約196BのEngramメモリを組み合わせ、prefill時8B・decode時16Bを活性化する非対称構成とされる。公式weightsも公開された一方、checkpointは数百GB級で、M4 Pro 64GBのローカル実用範囲から大きく外れる。</p><h2>所感</h2><p>prefillとdecodeで活性計算量を変え、巨大なN-gram系メモリを分離する設計は、今後のQwen4級やローカルMoEで計算・記憶・長文処理を別々に最適化する方向として重要。ただし現状はモデル規模、Apple Silicon向けruntime、独立評価の不足が明確な障害で、試す対象ではない。</p><h2>情報源</h2><ul><li><a href="https://www.reuters.com/world/asia-pacific/chinas-deepseek-launches-v41-flash-model-2026-09-10/">China&apos;s DeepSeek launches V4.1-Flash model</a></li><li><a href="https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash">DeepSeek-V4.1-Flash model weights</a></li><li><a href="https://github.com/deepseek-ai/deepseek-harness/commit/ecc6f11cf133155fe7989d5eb6417c7493928df6">DeepSeek Harness: add V41 Flash alongside V4 models</a></li></ul> deepseek architecture engram moe multimodal https://findings.yatabis.dev/findings/irodori-v4-1-anime-audiocpp-q8/ daily-findings:irodori-v4-1-anime-audiocpp-q8 Wed, 09 Sep 2026 15:00:00 GMT audio.cppは2026年9月9日、phasefield-audio/Irodori-TTS-v4.1-AnimeをIrodori-TTS v4.1 Small互換のQ8_0 GGUFパッケージとして追加し、audio-cpp/audio.cpp-ggufにもモデル実体を公開した。audio.cppはmacOSとApple Siliconをサポートし、Irodori系ではTTS、voice cloning、Voice Design、発話制御を同じネイティブランタイムで扱える。 <p>TRY · 記録日 2026-09-10</p><p>audio.cppは2026年9月9日、phasefield-audio/Irodori-TTS-v4.1-AnimeをIrodori-TTS v4.1 Small互換のQ8_0 GGUFパッケージとして追加し、audio-cpp/audio.cpp-ggufにもモデル実体を公開した。audio.cppはmacOSとApple Siliconをサポートし、Irodori系ではTTS、voice cloning、Voice Design、発話制御を同じネイティブランタイムで扱える。</p><h2>所感</h2><p>キャラクター音声用途では、通常のv4.1-Smallとは異なるアニメ調ファインチューニングをApple Silicon上でPython/TorchAO経路なしに比較できる。Anime派生は独自アノテーションのためcaption conditioningやemoji controlがベースと異なる可能性があり、まず短いA/B試験で声質・制御性・速度を確認する価値がある。</p><h2>情報源</h2><ul><li><a href="https://github.com/0xShug0/audio.cpp/commit/98101a4d6fa1d1ef29f5a0fa52dd5585d9cbcb5a">Add Irodori Anime GGUF package support</a></li><li><a href="https://huggingface.co/audio-cpp/audio.cpp-gguf/commits/main">audio-cpp/audio.cpp-gguf commit history</a></li><li><a href="https://huggingface.co/phasefield-audio/Irodori-TTS-v4.1-Anime">phasefield-audio/Irodori-TTS-v4.1-Anime</a></li></ul> Irodori-TTS audio.cpp Apple-Silicon GGUF TTS Voice-Design https://findings.yatabis.dev/findings/mlx-global-scale-nvfp4-matrix-kernels/ daily-findings:mlx-global-scale-nvfp4-matrix-kernels Wed, 09 Sep 2026 15:00:00 GMT MLX PR #4481はglobal scale付きgather_qqmmを新しいgather_qmm matrix kernelへdispatchし、Qwen3.6-35B-A3BのNVFP4 MLP-only（p2048/g128）でM5 Maxのprefillを1,257.0→3,105.3 tok/s、M3 Ultraを1,627.3→2,673.2 tok/sと報告した。generationはほぼ不変。続く#4483はqmm_t kernelにもglobal scale読み込みを追加し、#4481との組み合わせでM5 Max 4,256.2 tok/s、M3 Ultra 2,819.9 tok/sを報告している。両PRは2026-09-10時点でopen。 <p>TRY · 記録日 2026-09-10</p><p>MLX PR #4481はglobal scale付きgather_qqmmを新しいgather_qmm matrix kernelへdispatchし、Qwen3.6-35B-A3BのNVFP4 MLP-only（p2048/g128）でM5 Maxのprefillを1,257.0→3,105.3 tok/s、M3 Ultraを1,627.3→2,673.2 tok/sと報告した。generationはほぼ不変。続く#4483はqmm_t kernelにもglobal scale読み込みを追加し、#4481との組み合わせでM5 Max 4,256.2 tok/s、M3 Ultra 2,819.9 tok/sを報告している。両PRは2026-09-10時点でopen。</p><h2>所感</h2><p>量子化形式そのものより、global scaleという量子化メタデータの有無で高速matrix pathから外れるだけでprefillが数倍変わり得ることを示している。独自MLX runtimeではbits/group sizeだけでなくscale方式・weight layout・phaseまでKernelPlanのdispatch keyに含め、NVFP4系のprefill crossoverを実測する価値が高い。</p><h2>情報源</h2><ul><li><a href="https://github.com/ml-explore/mlx/pull/4481">Use matrix kernels for global-scale gather_qqmm</a></li><li><a href="https://github.com/ml-explore/mlx/pull/4483">Load global scales in qmm_t kernels</a></li></ul> mlx apple-silicon m5 m3-ultra nvfp4 quantization prefill moe kernel-dispatch https://findings.yatabis.dev/findings/omlx-cluster-v2-distributed-mac-inference/ daily-findings:omlx-cluster-v2-distributed-mac-inference Wed, 09 Sep 2026 15:00:00 GMT oMLX mainにCluster v2 dashboardが入り、複数Mac間のTensor Parallel / Pipeline Parallel、signed planning、モデルstaging、live memory budget、rank prompt cache、activationを一体管理する導線が統合された。関連する物理検証ではQwen3.6-27Bを2台のMacとThunderbolt RDMAで28.6 tok/s、単一node 16.1 tok/sに対して1.78倍で実行し、byte-identical出力を確認している。 <p>WATCH · 記録日 2026-09-10</p><p>oMLX mainにCluster v2 dashboardが入り、複数Mac間のTensor Parallel / Pipeline Parallel、signed planning、モデルstaging、live memory budget、rank prompt cache、activationを一体管理する導線が統合された。関連する物理検証ではQwen3.6-27Bを2台のMacとThunderbolt RDMAで28.6 tok/s、単一node 16.1 tok/sに対して1.78倍で実行し、byte-identical出力を確認している。</p><h2>所感</h2><p>NVIDIA PAIRのようなrequest routingではなく、1つのモデル自体を複数Macへ分割するため、単機のunified memory上限を超えるモデルをApple Siliconで扱う方向を実用化し得る。ただしCluster v2 dashboardの今回のmerge自体には新しい物理multi-Mac検証がなく、stable releaseもまだ0.6.4で、異種Mac構成の性能も未確立なので今はWATCH。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3516">feat(cluster): ship the Cluster v2 dashboard</a></li><li><a href="https://github.com/jundot/omlx/pull/2423">Distributed cluster serving across Macs (tensor + pipeline parallel)</a></li><li><a href="https://github.com/jundot/omlx/commit/4d06a6c65ff5b335dcb124ce42a3a4d23b3053d7">feat(cluster): add the Cluster v2 dashboard</a></li></ul> omlx mlx apple-silicon distributed-inference tensor-parallel pipeline-parallel https://findings.yatabis.dev/findings/omlx-qwen4-ple-lookahead-prefetch/ daily-findings:omlx-qwen4-ple-lookahead-prefetch Wed, 09 Sep 2026 15:00:00 GMT oMLX PR #3534はQwen3.8-Flash-NextのSSD-backed PLEで、chunk内の多数shardを個別upload/dequantizeする代わりにhost側でtensor familyごとの連続bufferへ組み立てて各family一回だけuploadし、さらにschedulerが次chunkのtokenを事前通知して現在chunkのGPU実行中に単一workerで次のPLE rowをgatherする。M5 Maxでは2048-token chunkのPLE layerが248→35 ms、16K/63K/134K/229K prefillがそれぞれ約+33%/+18%/+13%/+12%。decodeはほぼ不変で、PRはopen。 <p>TRY · 記録日 2026-09-10</p><p>oMLX PR #3534はQwen3.8-Flash-NextのSSD-backed PLEで、chunk内の多数shardを個別upload/dequantizeする代わりにhost側でtensor familyごとの連続bufferへ組み立てて各family一回だけuploadし、さらにschedulerが次chunkのtokenを事前通知して現在chunkのGPU実行中に単一workerで次のPLE rowをgatherする。M5 Maxでは2048-token chunkのPLE layerが248→35 ms、16K/63K/134K/229K prefillがそれぞれ約+33%/+18%/+13%/+12%。decodeはほぼ不変で、PRはopen。</p><h2>所感</h2><p>既存の並列pread最適化の次段として、I/Oを速くするだけでなく『多数shardのpublicationを一括化する』『schedulerが未来のchunkをモデルへ知らせてI/OをGPU計算と重ねる』という責務境界が有効だと示す。SSD offloadを使う独自runtimeでは、operator側のprefetch hookとscheduler側のlookaheadを明示APIにする価値がある。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3534">perf(qwen4_exp): faster Qwen3.8-Flash-Next prefill: hyper-connections on prefill rows, SSD-backed PLE gather assembled on the host and gathered ahead</a></li></ul> omlx apple-silicon m5 qwen3.8 qwen4 ssd-offload ple prefill scheduling prefetch https://findings.yatabis.dev/findings/omlx-ragged-batched-mtp/ daily-findings:omlx-ragged-batched-mtp Wed, 09 Sep 2026 15:00:00 GMT oMLX PR #3533は複数MTP requestを一回の(N,k+1) verify forwardへまとめ、各row固有のaccept長に応じてragged commitとper-row rollbackを行うexperimental pathを追加する。M5 Max / Qwen3.8-Flash-Next / greedyでk=2・8-way時51.6 tok/s aggregate、既存row-wise batched MTPの約6倍と報告し、12〜16-wayでは約53 tok/sで飽和した。ただしQSA cacheのragged rollbackにはmlx-vlm PR #2197が必要で、2026-09-10時点では両PRともopen。非greedyやlogits processor等はfallbackする。 <p>HOLD · 記録日 2026-09-10</p><p>oMLX PR #3533は複数MTP requestを一回の(N,k+1) verify forwardへまとめ、各row固有のaccept長に応じてragged commitとper-row rollbackを行うexperimental pathを追加する。M5 Max / Qwen3.8-Flash-Next / greedyでk=2・8-way時51.6 tok/s aggregate、既存row-wise batched MTPの約6倍と報告し、12〜16-wayでは約53 tok/sで飽和した。ただしQSA cacheのragged rollbackにはmlx-vlm PR #2197が必要で、2026-09-10時点では両PRともopen。非greedyやlogits processor等はfallbackする。</p><h2>所感</h2><p>speculative decodingをsingle-stream最適化ではなくcontinuous batchingと統合する設計例として重要で、将来M5 Ultra上で複数coding agentを並列実行するときに効く。一方でrollback依存が未mergeで、対応範囲もgreedyなGDN+PLE系に限定されるため、現時点では実装を取り込むよりstate transactionとragged rollback contractの設計資料として保持する。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3533">Fused-batch ragged multi-token MTP: concurrent speculative decode (OMLX_MTP_FUSED_BATCH)</a></li><li><a href="https://github.com/Blaizzy/mlx-vlm/pull/2197">Fix qwen3_5 ragged speculative rollback on BatchQSAKVCache</a></li></ul> omlx mlx-vlm apple-silicon m5 qwen3.8 mtp speculative-decoding continuous-batching rollback https://findings.yatabis.dev/findings/astra-single-forward-pass-reasoning/ daily-findings:astra-single-forward-pass-reasoning Tue, 08 Sep 2026 15:00:00 GMT GPT-6 AstraのSystem Cardに収録されたUK AISIの外部評価では、Chain of Thoughtを使わない単一forward passで解ける数学問題の50% reliability time horizonが30.9分となり、GPT-5.6 Solの3.6分を大きく上回った。CoT controllabilityも93%対48%に上昇し、raw reasoningはより圧縮された表現になった。一方、OpenAIの公開資料はrecurrent depthやlooped Transformerを採用したとは明記しておらず、具体的な内部アーキテクチャは未確認である。 <p>WATCH · 記録日 2026-09-09</p><p>GPT-6 AstraのSystem Cardに収録されたUK AISIの外部評価では、Chain of Thoughtを使わない単一forward passで解ける数学問題の50% reliability time horizonが30.9分となり、GPT-5.6 Solの3.6分を大きく上回った。CoT controllabilityも93%対48%に上昇し、raw reasoningはより圧縮された表現になった。一方、OpenAIの公開資料はrecurrent depthやlooped Transformerを採用したとは明記しておらず、具体的な内部アーキテクチャは未確認である。</p><h2>所感</h2><p>出力CoTを長くする以外にも、1 tokenを出す前の内部処理側へ推論能力が移る可能性を示す強いproduction evidenceになる。将来のローカルモデルでは、出力token数やdecode tok/sだけでは思考量を表せず、可変な内部computeやlatent iterationを扱うruntime設計が重要になる可能性がある。ただし現時点ではweightsもarchitectureも非公開なので実装・試用対象ではない。</p><h2>情報源</h2><ul><li><a href="https://deploymentsafety.openai.com/gpt-6-astra">GPT-6 Astra System Card</a></li></ul> reasoning latent-reasoning test-time-compute architecture gpt-6-astra https://findings.yatabis.dev/findings/mlx-m5-d256-attention-phase-routing/ daily-findings:mlx-m5-d256-attention-phase-routing Tue, 08 Sep 2026 15:00:00 GMT MLXのdraft PR #4476は、D256 causal attentionの短いprefill（fp16/bf16、query 512〜1023、key最大1536）をNAX split-head-dimension kernelへ広げ、M5 Maxのoperator測定で約1.07〜1.38倍を報告した。key長1537のcontrolはほぼ中立だった。PR #4477は同じD256でGQA=8のsingle-token decode、key長8192以上にtwo-pass vector kernelを追加し約1.11〜1.18倍。どちらも通常の浮動小数点KV cacheが対象で、whole-model throughputは未測定。 <p>TRY · 記録日 2026-09-09</p><p>MLXのdraft PR #4476は、D256 causal attentionの短いprefill（fp16/bf16、query 512〜1023、key最大1536）をNAX split-head-dimension kernelへ広げ、M5 Maxのoperator測定で約1.07〜1.38倍を報告した。key長1537のcontrolはほぼ中立だった。PR #4477は同じD256でGQA=8のsingle-token decode、key長8192以上にtwo-pass vector kernelを追加し約1.11〜1.18倍。どちらも通常の浮動小数点KV cacheが対象で、whole-model throughputは未測定。</p><h2>所感</h2><p>同じhead_dimでもprefillとdecode、さらにcontext境界で最適kernelが変わることが明瞭になった。M5 Ultra実機で phase・qL・kL・dtype・GQA比・KV形式を掃くautotunerを早期に作り、correctness gate後にcrossover tableを生成する価値がある。</p><h2>情報源</h2><ul><li><a href="https://github.com/ml-explore/mlx/pull/4476">Use NAX attention for short causal D256 prefill</a></li><li><a href="https://github.com/ml-explore/mlx/pull/4477">Add D256 to GQA-8 two-pass vector attention</a></li></ul> apple-silicon mlx m5 attention nax gqa autotuning https://findings.yatabis.dev/findings/mlx-qwen4-native-layout-qsa-long-context/ daily-findings:mlx-qwen4-native-layout-qsa-long-context Tue, 08 Sep 2026 15:00:00 GMT oMLX PR #3520 は Qwen3.8-Flash-Next の gathered QSA で、各stepにKV全体をtranspose+reshapeしていた経路を、保存レイアウトのtoken軸から直接 mx.take する方式へ変更した。M5 Maxでは206K tokenのcacheでQSA 1 layer・1 tokenあたり1.83msから0.27msへ短縮。さらに長文のtext-only decodeとMTP verifyをgathered QSAへ通し、serial decodeは63K/134K/229Kで約+8%/+19%/+30%、greedyのadaptive MTPは約+13%/+34%/+40%を報告している。損益分岐はserial・sampled MTP・greedy MTPで異なる。 <p>TRY · 記録日 2026-09-09</p><p>oMLX PR #3520 は Qwen3.8-Flash-Next の gathered QSA で、各stepにKV全体をtranspose+reshapeしていた経路を、保存レイアウトのtoken軸から直接 mx.take する方式へ変更した。M5 Maxでは206K tokenのcacheでQSA 1 layer・1 tokenあたり1.83msから0.27msへ短縮。さらに長文のtext-only decodeとMTP verifyをgathered QSAへ通し、serial decodeは63K/134K/229Kで約+8%/+19%/+30%、greedyのadaptive MTPは約+13%/+34%/+40%を報告している。損益分岐はserial・sampled MTP・greedy MTPで異なる。</p><h2>所感</h2><p>自前MLX runtimeでは、sparse attentionの前処理で物理cache layoutを壊さないことを原則にし、text-only等の意味的な事実はtensor値から毎step推定せずscheduler metadataとして運ぶ価値がある。またQSA routeの閾値はcontext長だけでなくphase・sampling・speculation depthを含むExecutionPlanのdispatch keyにすべきという具体的な実測になる。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3520">perf(qwen4_exp): long-context decode and MTP verify rows on the gathered QSA arms</a></li></ul> apple-silicon mlx qwen3.8 qsa long-context mtp scheduling https://findings.yatabis.dev/findings/omlx-qwen4-ssd-ple-concurrent-pread/ daily-findings:omlx-qwen4-ssd-ple-concurrent-pread Tue, 08 Sep 2026 15:00:00 GMT oMLX mainのcommit fc69aecは、Qwen4-Exp/Qwen3.8-Flash-NextでSSDに置いたPLE（n-gram bank）の散在row lookupを、mmap上の逐次page faultから複数os.preadの並列prefetchへ変更した。開発者のM4 Max内蔵NVMe測定では500件の4KB random readが約9.1kから98.8k IOPSへ伸び、40K-token cold promptでは特定のQwen3.8-Flash-Next checkpointでTTFT 216.85秒から6.54秒、generation 43.70から59.92 tok/sを報告している。row結果はbyte-identicalで、対象はSSD-backed PLE modeのみ。最新stableは依然0.6.4である。 <p>HOLD · 記録日 2026-09-09</p><p>oMLX mainのcommit fc69aecは、Qwen4-Exp/Qwen3.8-Flash-NextでSSDに置いたPLE（n-gram bank）の散在row lookupを、mmap上の逐次page faultから複数os.preadの並列prefetchへ変更した。開発者のM4 Max内蔵NVMe測定では500件の4KB random readが約9.1kから98.8k IOPSへ伸び、40K-token cold promptでは特定のQwen3.8-Flash-Next checkpointでTTFT 216.85秒から6.54秒、generation 43.70から59.92 tok/sを報告している。row結果はbyte-identicalで、対象はSSD-backed PLE modeのみ。最新stableは依然0.6.4である。</p><h2>所感</h2><p>64GB級Apple SiliconでQwen3.8-Flash-Nextの大きなPLEをSSD offloadする際の実ボトルネックを直接潰す変更で、ユーザーの既存運用に最も近い。ただし数値は開発側測定で、0.6.4にはagent loopのprefix-cache regressionが複数報告されたまま。#3287を含むstable releaseと、M4 Pro 64GBでprefix reuse・長時間agent loopのcorrectnessを保った独立A/Bが揃うまでは導入しない。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/commit/fc69aecacb9927bd4be31ebb2e818f342369385a">fix: use concurrent pread for Qwen4-Exp PLE row lookups (~10x SSD throughput)</a></li><li><a href="https://github.com/jundot/omlx/releases/tag/v0.6.4">oMLX 0.6.4</a></li><li><a href="https://github.com/jundot/omlx/issues/3317">Boundary snapshots never captured on Qwen3.8-27B in 0.6.4</a></li></ul> omlx apple-silicon qwen3.8 qwen4 ssd-offload ple inference https://findings.yatabis.dev/findings/omlx-reasoning-output-cache-transcript-identity/ daily-findings:omlx-reasoning-output-cache-transcript-identity Tue, 08 Sep 2026 15:00:00 GMT oMLX PR #3525 は、次ターンのchat historyがthinking/reasoningを保持する場合にpromptだけでなく生成outputもprefix cacheへ保存する。M5 MaxのQwen3.8-Flash-Nextで3126-token promptと6000-token answerを使った2-turn probeでは、従来2048 tokenだけだった保存・再利用が8192 tokenまで増えた。tool-callで終わるturnにも同じ規則を適用する。また短いpromptではMTPのblock-boundary alignmentが最初のcaptureまでarmされず、2048境界が2047/2049へずれることがある問題も、request追加時にalignmentをarmすることで修正している。 <p>TRY · 記録日 2026-09-09</p><p>oMLX PR #3525 は、次ターンのchat historyがthinking/reasoningを保持する場合にpromptだけでなく生成outputもprefix cacheへ保存する。M5 MaxのQwen3.8-Flash-Nextで3126-token promptと6000-token answerを使った2-turn probeでは、従来2048 tokenだけだった保存・再利用が8192 tokenまで増えた。tool-callで終わるturnにも同じ規則を適用する。また短いpromptではMTPのblock-boundary alignmentが最初のcaptureまでarmされず、2048境界が2047/2049へずれることがある問題も、request追加時にalignmentをarmすることで修正している。</p><h2>所感</h2><p>coding-agent loopでは長いreasoningやtool callの再prefillを避けられる。cacheabilityは「reasoningか否か」ではなく、次のpromptがそのtoken列を同一に再レンダリングするかというtranscript identityで判定する方が一般化しやすい。state checkpointの境界契約もdecode中に遅延初期化せずrequest開始時点で確立すべきだと分かる。</p><h2>情報源</h2><ul><li><a href="https://github.com/jundot/omlx/pull/3525">fix(cache): keep a reasoning request&apos;s output cacheable when the history preserves it</a></li></ul> apple-silicon mlx prefix-cache reasoning agent-loop mtp state https://findings.yatabis.dev/findings/nvidia-pair-local-inference-routing/ daily-findings:nvidia-pair-local-inference-routing Mon, 07 Sep 2026 15:00:00 GMT NVIDIA Personal AI Router (PAIR) は、同一LAN上のOllamaまたはLM Studioノードへ独立した推論リクエストをモデル有無・負荷・GPU使用率に応じて振り分けるオープンソースのローカルルータとして公開された。Apple M4+を公式対応対象に含み、OpenAI互換エンドポイントを既存クライアントから利用できる。一方で単一リクエストの分割、GPUメモリのpooling、モデルshardingは行わず、1リクエストは必ず1ノードで完結する。 <p>WATCH · 記録日 2026-09-08</p><p>NVIDIA Personal AI Router (PAIR) は、同一LAN上のOllamaまたはLM Studioノードへ独立した推論リクエストをモデル有無・負荷・GPU使用率に応じて振り分けるオープンソースのローカルルータとして公開された。Apple M4+を公式対応対象に含み、OpenAI互換エンドポイントを既存クライアントから利用できる。一方で単一リクエストの分割、GPUメモリのpooling、モデルshardingは行わず、1リクエストは必ず1ノードで完結する。</p><h2>所感</h2><p>複数のローカルMacを単一巨大モデルの分散実行ではなく、coding agentのsubagentや並列タスクを捌く共有推論プールとして使う実用的な経路が公式実装になった。現時点ではOllama/LM Studio中心で、llama.cpp対応は未mergeのPR段階なので、標準runtimeを増やして試すより対応拡大を待つ価値が高い。</p><h2>情報源</h2><ul><li><a href="https://developer.nvidia.com/blog/nvidia-pair-virtual-inference-router-expands-available-compute-on-your-local-network/">NVIDIA PAIR Virtual Inference Router Expands Available Compute on Your Local Network</a></li><li><a href="https://github.com/NVIDIA/Personal-AI-Router/blob/main/docs/getting-started.mdx">NVIDIA Personal AI Router - Getting Started</a></li><li><a href="https://github.com/NVIDIA/Personal-AI-Router/pull/41">Add adopt-only llama.cpp engine and OpenAI proxy (PR #41)</a></li></ul> apple-silicon local-ai multi-agent inference-routing