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を構築する。
大きなweight/output bufferを扱うM5 Ultraでは2GiB境界は容易に踏む。独自Metal kernelのcorrectness suiteに2GiB直前・直後のaddressing regressionを入れ、Tensor APIのbase-relative sliceに依存しない大規模buffer addressingを優先して検証する価値がある。
MLX PR #4489 は同じkernel名でsourceを変えるcustom kernel実行時、従来のname-keyed cacheがclear_library()を呼び、実行中command bufferが参照するMTLComputePipelineStateを破棄してSIGABRTを起こし得ると報告した。提案修正はsource hashをkeyにして複数variantを共存させる方式。PR自体は未マージでclosed。
shapeやdtypeごとにcustom Metal kernelを生成・autotuneする独自runtimeでは、kernel cacheのidentityとlifetimeが実行安全性に直結する。source/specializationを含むcontent-addressed keyを使い、in-flight pipelineをevictしない契約を早い段階で入れておく価値がある。
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性能は変わらないと報告されている。
wide-head attentionでは演算量だけでなくsimdgroupごとのaccumulator working setがメモリ圧と実装可能性を決める。独自MLX runtimeのattention plannerでhead dimension分割数を候補化し、M5 Ultra実機でD256/D512のsplit数をautotuneする価値がある。
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する。
MoE expertとは別に、table型の静的retrieval stateを独立したstorage tierへ落とす設計が成立する実例。将来の巨大モデル向けResidencyPlanにEngram/lookup table tierを持たせる価値がある。一方256GiB機ではoQ3eでもloader estimateが約251.34GiBで余裕がほぼなく、より高精度量子化を使う用途では現状実用条件を満たさない。
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を報告する。
KV formatを単独のcodecではなくattention kernel・persistence・admission accountingまで含むcapabilityとして設計する好例。8-bitは4-bitより品質余裕を取りやすく長文用途に現実的だが、PRはAffine4の未マージPR #3499に依存し、semantic qualityやretrieval accuracyも未検証なので現時点では導入を保留する。
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は概ね維持された。
CEDが単なる論文上のactive-parameter削減ではなく、Apple Siliconのローカルruntimeでprefill計算そのものを大きく省略できることを示す初期実装。input-heavyなagent workloadでは将来のTTFTを大きく縮めうる。一方で現状はdraft、単一機種・単一モデルの開発者実測で、bounded replayは末尾queryの初期windowを近似するため広範な品質検証がなく、M4 Pro 64GBにはモデル自体が収まらない。
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削減へ直結しないことを明示している。
REAP系のexpert pruningを大規模MoEのApple Silicon適合策として見る際、容量削減とdecode高速化を分けて考える必要があるという実測。64GB機では対象外だが、今後より大きなMoEをローカル化する設計判断に有用な負の結果。
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はほぼ不変だった。
長文decodeでcontext長に比例するindexer前処理を毎token繰り返さずに済む設計で、MLXへもアルゴリズムとして移植しやすい。ただし現時点の公開実測はCUDAでApple Silicon上の効果が未確認のため、まずwatchしてM5系で同じボトルネックをprofileしてから実装判断する。
Inceptionは2026年9月8日にMercury 2.5を公開した。自己回帰ではなく複数トークンを反復的に精緻化する拡散型LLMで、260Kコンテキスト、調整可能な推論、並列ツール呼び出し、スキーマ準拠JSONを提供する。開発元は広く入手可能なNVIDIA GPUで1,107 tok/sを主張し、Augment CodeではMercury系をコンテキスト圧縮やMCPツール検索に本番利用していると報告している。一方、標準ベンチマークの独立検証はまだ乏しく、weightsは非公開でAPI提供のみ。
拡散型テキスト生成が単なる高速デモではなく、ツール利用を伴うproduction agentの補助呼び出しで成立している点が重要。将来open-weight化やローカルruntimeが進めば、自己回帰前提のdecode設計とは別の実用的推論経路になり得る。ただし現状はローカル実行できず、品質・速度の主要数字も開発元主張なので試す対象ではない。
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が未整備なため明示的に無効化している。
looped/recurrent系の新アーキテクチャでは『各layerに1個のKV cache』というruntime前提が崩れる。独自MLX runtimeのStateBundleを最初からモデル固有のnested stateを持てる形にしておく根拠になる。一方この実装のMetal workspace gateは未実行で、今すぐモデル対応する必要まではない。
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で処理できた。
speculationを単純なon/offではなく、parked-but-primedを含む永続的な状態機械として設計する根拠になる。既存のmtp_forwardを使う制御・state管理中心の変更なので、MLXベースの独自runtimeへ比較的移植しやすい。
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%だった。
cache block sizeをモデルのrecurrent/prefill geometryだけで決めると、実際の安定prefix長との境界ずれで大きな再計算が起きる。独自runtimeではprefill演算粒度とcache persistence粒度を分離し、workload統計からblock sizeを選ぶautotune対象にする価値が高い。
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、発話制御を同じネイティブランタイムで扱える。
キャラクター音声用途では、通常のv4.1-Smallとは異なるアニメ調ファインチューニングをApple Silicon上でPython/TorchAO経路なしに比較できる。Anime派生は独自アノテーションのためcaption conditioningやemoji controlがベースと異なる可能性があり、まず短いA/B試験で声質・制御性・速度を確認する価値がある。
9月8日の期間限定プレビューから正式リリースへ移行し、DeepSeekはV4.1 Flashを新アーキテクチャ系の最小モデルとして公開した。公開技術資料を引用した複数の確認では、552B backboneに約196BのEngramメモリを組み合わせ、prefill時8B・decode時16Bを活性化する非対称構成とされる。公式weightsも公開された一方、checkpointは数百GB級で、M4 Pro 64GBのローカル実用範囲から大きく外れる。
prefillとdecodeで活性計算量を変え、巨大なN-gram系メモリを分離する設計は、今後のQwen4級やローカルMoEで計算・記憶・長文処理を別々に最適化する方向として重要。ただし現状はモデル規模、Apple Silicon向けruntime、独立評価の不足が明確な障害で、試す対象ではない。
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。
量子化形式そのものより、global scaleという量子化メタデータの有無で高速matrix pathから外れるだけでprefillが数倍変わり得ることを示している。独自MLX runtimeではbits/group sizeだけでなくscale方式・weight layout・phaseまでKernelPlanのdispatch keyに含め、NVFP4系のprefill crossoverを実測する価値が高い。
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出力を確認している。
NVIDIA PAIRのようなrequest routingではなく、1つのモデル自体を複数Macへ分割するため、単機のunified memory上限を超えるモデルをApple Siliconで扱う方向を実用化し得る。ただしCluster v2 dashboardの今回のmerge自体には新しい物理multi-Mac検証がなく、stable releaseもまだ0.6.4で、異種Mac構成の性能も未確立なので今はWATCH。
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。
既存の並列pread最適化の次段として、I/Oを速くするだけでなく『多数shardのpublicationを一括化する』『schedulerが未来のchunkをモデルへ知らせてI/OをGPU計算と重ねる』という責務境界が有効だと示す。SSD offloadを使う独自runtimeでは、operator側のprefetch hookとscheduler側のlookaheadを明示APIにする価値がある。
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する。
speculative decodingをsingle-stream最適化ではなくcontinuous batchingと統合する設計例として重要で、将来M5 Ultra上で複数coding agentを並列実行するときに効く。一方でrollback依存が未mergeで、対応範囲もgreedyなGDN+PLE系に限定されるため、現時点では実装を取り込むよりstate transactionとragged rollback contractの設計資料として保持する。
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を採用したとは明記しておらず、具体的な内部アーキテクチャは未確認である。
出力CoTを長くする以外にも、1 tokenを出す前の内部処理側へ推論能力が移る可能性を示す強いproduction evidenceになる。将来のローカルモデルでは、出力token数やdecode tok/sだけでは思考量を表せず、可変な内部computeやlatent iterationを扱うruntime設計が重要になる可能性がある。ただし現時点ではweightsもarchitectureも非公開なので実装・試用対象ではない。
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は未測定。
同じhead_dimでもprefillとdecode、さらにcontext境界で最適kernelが変わることが明瞭になった。M5 Ultra実機で phase・qL・kL・dtype・GQA比・KV形式を掃くautotunerを早期に作り、correctness gate後にcrossover tableを生成する価値がある。
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である。
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が揃うまでは導入しない。
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で異なる。
自前MLX runtimeでは、sparse attentionの前処理で物理cache layoutを壊さないことを原則にし、text-only等の意味的な事実はtensor値から毎step推定せずscheduler metadataとして運ぶ価値がある。またQSA routeの閾値はcontext長だけでなくphase・sampling・speculation depthを含むExecutionPlanのdispatch keyにすべきという具体的な実測になる。
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することで修正している。
coding-agent loopでは長いreasoningやtool callの再prefillを避けられる。cacheabilityは「reasoningか否か」ではなく、次のpromptがそのtoken列を同一に再レンダリングするかというtranscript identityで判定する方が一般化しやすい。state checkpointの境界契約もdecode中に遅延初期化せずrequest開始時点で確立すべきだと分かる。
NVIDIA Personal AI Router (PAIR) は、同一LAN上のOllamaまたはLM Studioノードへ独立した推論リクエストをモデル有無・負荷・GPU使用率に応じて振り分けるオープンソースのローカルルータとして公開された。Apple M4+を公式対応対象に含み、OpenAI互換エンドポイントを既存クライアントから利用できる。一方で単一リクエストの分割、GPUメモリのpooling、モデルshardingは行わず、1リクエストは必ず1ノードで完結する。
複数のローカルMacを単一巨大モデルの分散実行ではなく、coding agentのsubagentや並列タスクを捌く共有推論プールとして使う実用的な経路が公式実装になった。現時点ではOllama/LM Studio中心で、llama.cpp対応は未mergeのPR段階なので、標準runtimeを増やして試すより対応拡大を待つ価値が高い。