Qwen3.6-35B-A3B-PALW-runtime

MISAKA PALW Runtime for Qwen3.6-35B-A3B (Claude-4.7, abliterated)

このリポジトリは今、二つのものを配っています。

1. palw-runtime/qwen36-35b-a3b.palwq36 — Qwen3.6-35B-A3B を整数演算だけで実行する 決定的ランタイムの変換済みアーティファクト。MISAKA testnet-11 がこのファイルの root を genesis に登録しており、このモデルの推論がそのままブロック生成の仕事になります。
2. runtime-palw/ ほか — llama.cpp を観測する従来の ComputeReceipt ランタイム。 自己申告どおり mint 不適格のまま、そのまま残しています(下記「二つのランタイムの関係」)。

.palwq36 は実行可能な重み一式です。 GGUF と併せてこのリポジトリだけで完結します。 ただし新しく学習・微調整したモデルではありません — 同梱の Q4_K_M GGUF から 誰でも再生成できる決定的な変換結果であり、上流モデルの派生物です。

---

1. PALW 整数ランタイム(consensus クラス)

これが何か

Qwen3.6-abliterated-35b-Claude-4.7-Q4_K_M.gguf を W8A16 の整数アーティファクトへ変換した ものです。量子化済みの重み一式がこのファイルに入っています(33.27 GiB / 40 層 / vocab 248,320)。float は実行経路に一切現れません(ADR-0040 Decision A)。そのため:

• 同じ入力は、どのマシンでも同じ出力になります。 「概ね一致」ではなくビット一致です。
• 誰でも一手ずつ再実行して反証できます。 裁定は許容誤差との比較ではなく、 一つのステップの厳密な再計算です。嘘をついた実行は開示1枚から有罪にできます。

MISAKA testnet-11(PALW ConsensusV2)は genesis で三つのクラスを登録しています。

実測値

すべて reference host(M4 Pro / 24 GiB)での実測です。

artifact root(testnet-11 が genesis に登録している値):

c970d69327bf65d6b2502a8e53a021739f2579c2274754790869320352a92c7a
4a8deb5da08e27e90f09d5ae9b4f7e44c983304af7bba8127d28e2d85996b236

チェーンが名指すのはこの root であって、パスでもファイル名でもありません。異なる root を 計算するノードは、ファイル名が何であれ違う重みを持っています。

使い方

A. 自分で変換する(何も信用しない)

cargo build --release -p misaka-palw-base0 --bin qwen36-convert
./target/release/qwen36-convert \
  --gguf Qwen3.6-abliterated-35b-Claude-4.7-Q4_K_M.gguf \
  --out qwen36.palwq36 --context 512

--gguf の代わりに --url <このリポジトリの GGUF> --header <先頭48MiBのファイル> を渡すと、 テンソルごとに HTTP range で取得するので 22 GiB を disk に置かずに済みます。 ピークメモリは1層分のテンソル、ピーク disk は出力だけです。

変換は決定的です。 同じ GGUF からの2回の変換がバイト単位で一致することを実測しました (1層分での測定)。経路上に乱数・時刻・反復順依存はなく、高速カーネルは出力チャネルで 並列化するため(各出力はその index の純関数)、スレッド数は「誰が計算するか」だけを変え、 「何を計算するか」を変えません。したがって A と B は同じ 64 バイトに着きます。

B. 変換済みを落とす

palw-runtime/qwen36-35b-a3b.palwq36。使う前に必ず検証してください。

./target/release/qwen36-run --artifact qwen36.palwq36 --root-only

上の root と一致しなければ exit 1 します(実測 110 秒)。ノード自身も起動時に計算して root で 拒否するので、これは「拒否される前に自分で気づく」ための手段です。

ノードで動かす

kaspad --testnet --netsuffix=11 --palw-class-artifact=/path/to/qwen36.palwq36

--netsuffix=11 だけでは mainnet で起動します — --testnet が要ります(実機で確認済み)。 起動すると fingerprint a14333bf81444b14b972df92d5e6d2c52a5c9ef0cb7ae06d99407c2731a0f8d2 (testnet-11、3クラス)を表示し、アーティファクトを読み込んで報告します:

[palw-producer] loaded class artifact …/qwen36.palwq36 (40 layers, 33.27 GiB, computed root …)

ブロックを産出するには、さらに operator の3事実が要ります(いずれも欠けると その理由を名指しして production を止めます):

kaspad --testnet --netsuffix=11 \
  --palw-class-artifact=/path/to/qwen36.palwq36 \
  --palw-produce \
  --palw-producer-key=<32byte hex seed のパス(chmod 600)> \
  --palw-producer-bond=<txid:index> \
  --palw-producer-pay-address=<misakatest:…>

アーティファクトが無くてもフルノードとして動きます。 このクラスのブロックも含めて検証は できます(検証は commitment と署名の検査であって推論の再実行ではないため)。できないのは そのクラスのブロックを産出することと、そのクラスの係争に座ることだけです。

クラス集合は ruleset id の内側にあるため、重みを持つノードと持たないノードの fingerprint は 同一で、通常どおり peer します。

チェーンがこのクラスに許すこと

• n_ctx は 8。 これはランタイムの制限ではありません(rotary table は 512 を覆い、エンジンは それを提供します)。裁判所が負担できる上限です — このクラスの worst close は 73,636 バイトで、 lifecycle トランザクションが運べる 81,920 バイトに対して 90% です。再帰の replay 証拠が context に比例して増えるためで、replay が checkpoint に錨を打てば context は戻ります。
• canonical job は (7, 2)、pwu_per_inference はその step-leaf 数。他の値を宣言した登録は拒否されます。
• cadence share は 1‰(最小付与share)。床の置き換えではなく、床の隣に立つ二つ目のクラスです。
• 係争は本物です。 このクラスが到達する全カーネルが裁判所のカタログにあり、step space は エンジン自身の順序から projection され、decode-token close は tiled logits scheme (248,320 レーンではなくタイル開示2枚)に乗ります。その数字が収まったから登録できたのであり、 起動時の gate が毎回 ruleset の上限に対して再検査します。

---

2. 二つのランタイムの関係(正直な差分)

下記の ComputeReceipt ランタイムは、自らを mint 不適格と申告し、その理由を3つ挙げています。

1. Metal の kernel-launch-bound sketch であって intra-kernel accumulator proof ではない
2. network-anchored でない
3. bonded でない

整数ランタイムはこの3つを、別の方法で解消しています — GPU の仕事を証明するのをやめ、 誰でも厳密に再実行できる演算にしたためです。

これは前者の否定ではありません。前者は「上流のランタイムをそのまま観測する」道を、後者は 「再実行できる演算に置き換える」道を取っており、後者が consensus に接続できたというだけです。 runtime-palw/ 以下は当時のまま残してあります。

---

3. ComputeReceipt ランタイム(従来どおり)

固定する上流 artifact

Q4_K_M は Qwen 公式配布 artifact をそのまま使用します。量子化は runtime_class_id と manifest に含め、別の精度・量子化とは照合しません。

Quickstart — 自分のハードウェアで Qwen3.6 を測定する

誰でも自分の Apple Silicon Mac で pin された Qwen3.6-35B-A3B を実行し、署名済み Receipt を 発行して別 process で検証できます。現状サポートは Metal arm64(Apple Silicon)です。手順の正本は docs/runbook.md。前提: Apple Silicon Mac、約 24GB の unified memory 推奨、 約 30GB の空き、git/CMake/uv/rustup。

# 1. clean checkout から一括導入(llama.cpp @ pinned commit + PALW patch を build、
#    Ollama registry blob から Qwen3.6 GGUF(約24GB)+ base metadata を取得・照合)
./scripts/install.sh
./scripts/verify-install.sh          # 固定 artifact hash / commit / Metal offload を独立検証

# 2. audit key(exact 32 raw bytes)を output の外に一度だけ作成
AUDIT_KEY="$HOME/.config/misaka-palw/audit-keys/local-audit.key"
install -d -m 700 "$(dirname "$AUDIT_KEY")"; test ! -e "$AUDIT_KEY"
(umask 077 && openssl rand 32 > "$AUDIT_KEY"); chmod 600 "$AUDIT_KEY"

# 3. Receipt 発行(prompt は stdin。ここでは例として capital-of-France を 2 token 生成)
OUT="receipts/manual-$(date +%Y%m%d-%H%M%S)"
printf '%s' 'The capital of France is' | runtime-palw/target/release/palw-metal-receipt \
  --prompt-stdin --audit-key-file "$AUDIT_KEY" --output-dir "$OUT" --n-predict 2

# 4. 別 process で検証(status=local_restored / trust_scope=embedded_local_snapshot なら成功)
ID=$(basename "$OUT"/*.palw .palw)
runtime-palw/target/release/palw-verify-bundle \
  --receipt "$OUT/$ID.palw" --bundle "$OUT/$ID.palw.bundle" \
  --public-json "$OUT/$ID.json" --audit-key-file "$AUDIT_KEY" \
  --state-db "$OUT/palw-state.sqlite3"

発行される公開 metadata(<id>.json)には CU ルールセット v3 の canonical_compute_units、 semantic_schedule、実捕捉 expert_route、trace_evidence=metal_kernel(各 GEMM を実 Metal kernel dispatch へ束縛)、および mint(常に eligible=false、失格理由を自己申告)が含まれます。 job ID/nonce/salt/signing key は実行ごとに OS CSPRNG で生成されるため Receipt ID は証跡例と一致しません。 参照 receipt は receipts/final-v7/。この Receipt は mint-grade ではなく、 mainnet 報酬には外部インフラが別途必要です(下記「セキュリティ上の境界」)。

LM Studio デスクトップ利用(palw-gateway)

チャット UI として LM Studio を使う場合、generator plugin infra/lmstudio/palw-receipt-adapter (./docs/evidence/qi35_lmstudio_install.sh で導入)が既定で palw-gateway(127.0.0.1:12346、初回チャットで自動起動)へ接続します。 画面に回答を stream したその実行そのものが PALW A-run で、二重推論はありません: 永続 session(token-id-stable な履歴で prefix cache がヒット、実測 23.1s→8.7s)、 turn ごとの engine receipt + 実行 roots、送信前確定の privacy/mint 3 モード、 SSRF ガード付き live web search(bundle digest は prompt commitment に推移的に束縛)、 バックグラウンドの replica→certified 検証状態のチャット内表示までを 1 本の経路で行います。 正本は docs/evidence/qi35-lmstudio-palw-receipt.md。 注記: 既定の --palw-loopback は配管の検証であって consensus ではなく(node 側 bridge へは QI35_PALW_COORDINATOR で接続)、receipt は上記と同じく mint-grade ではありません。

現在の状態

Rust core、Metal graph observer、署名済み Self Local Receipt、schema v4 SQLite replay/state registry、adversarial test suite は実装・実行済みです。対象モデルを dense Qwen3-8B から hybrid Qwen3.6-35B-A3B（huihui_ai/Qwen3.6-abliterated:35b-Claude-4.7）へ 移行し、Apple M1 Max（Metal、41/41 layer GPU offload）で実機ロード・推論・Receipt 発行・別 process 検証まで確認しています。

hybrid モデルは linear-attention（SSM / gated-delta-net）層と mixture-of-experts 層を 持つため、次を追加しました。

• pinned llama.cpp への qwen35moe loader/graph 互換修正（vendor/llama.cpp/src/models/qwen35moe.cpp、 PALW observer patch に同梱）。3-section mrope、ssm_dt naming、per-layer KV-head、 bundled vision/MTP tensor、per-layer attention reshape を扱う。
• Rust adapter の hybrid profile（AdapterProfile::HybridQwen36A3B）: dense 演算は正確な canonical operation へ忠実に写像する(MUL_MAT_ID→ExpertGemm、ARGSORT→ExpertRoute、 SSM_CONV→SsmConv、GATED_DELTA_NET→GatedDeltaNet、L2_NORM→L2Norm、SUM_ROWS→Reduction、 CONCAT/CONT/CPY→TensorCopy、UNARY/SCALE/DIV/CLAMP→Elementwise)。VIEW/RESHAPE/PERMUTE/ TRANSPOSE は layout-only、未列挙 op は fail-closed。Generic 演算は廃止(M3)。
• CU ルールセットは v3 semantic(ComputeUnitRules::v3): 観測 schedule は commitment-only とし、 canonical CU は pinned model 構造 + token 数から算出した graph 非依存の semantic 値を署名 commit。 dense Receipt は v1 のまま identity 不変。

Receipt 実装の詳細(observer JSONL v2、adapter 写像、CU 語彙、schedule、manifest、builder/verifier、 bundle、永続化、CLI 契約、実測値)は docs/receipt-implementation-qwen36.md を正本とします。

この Receipt は mint-grade ではありません。 assess_mint_eligibility(runtime-palw/src/mint.rs) が全 receipt を eligible=false, weight=0 と判定し、公開 JSON の mint ブロックに自己申告します。 用途はローカル自己整合 receipt / testnet 計測 / Self-Local 非報酬に限られます。compute-gate track (M1-M5、全て実機検証済み)で semantic CU v3 の canonical commitment・Generic 廃止・canonical semantic schedule 再生成・実 MoE routing 捕捉・各 GEMM の実 Metal kernel dispatch 束縛 (trace_evidence=metal_kernel、graph-fallback から昇格) を実装しました。ただし Metal の kernel-level trace は launch-geometry 束縛であり、CUDA V3 相当の intra-kernel accumulator proof ではないため mint 不適格のまま(honest labeling)。残る失格理由は「Metal kernel-launch-bound sketch, not an intra-kernel accumulator proof」/ 非 network-anchored / 非 bonded の 3 件。是正計画は docs/receipt-review-remediation.md を参照してください。

Apple M1 Max（macOS Metal）で hybrid モデルから生成した schema-v4 E2E artifact は receipts/final-v7/8e2dd34b7609d6d7aeec17bff485eb1ae4db31f66dd899a3c3a3e671656053f9.palw、 公開測定値は receipts/final-v7/8e2dd34b7609d6d7aeec17bff485eb1ae4db31f66dd899a3c3a3e671656053f9.json にあります。Receipt ID は 8e2dd34b…6053f9、verification bundle ID は f5b8a296…dcf9db、 CU ルールセットは v3 semantic（43a5feef…7870ce）、evidence_level=gemm_traced、 trace_evidence=metal_kernel。prompt 5 token + 2 生成 token の実行で observed schedule 13,770 件(commitment-only)・GEMM sketch 2,466 件(各々実 Metal kernel dispatch へ束縛)・ canonical compute units 41,692(v3 semantic)、semantic_schedule(80 expert-route ops)、 実捕捉した expert_route(240 record) を committ し、別 process の palw-verify-bundle が status=local_restored / trust_scope=embedded_local_snapshot で再検証しました。

dense Qwen3-8B の schema-v4 E2E artifact（Receipt ID eb51b08c…78131、bundle 359f1bed…096e9、receipts/final-v6/）と schema-v3 artifact（receipts/final-v5/）は、 移行前の検証証跡として履歴保持します。hybrid モデルの Receipt は実行ごとに OS CSPRNG で identity を生成するため ID は再現しません（docs/runbook.md の手順で生成・検証）。

現行 release CLI が発行する単位は、署名済み .palw、認証付き暗号化 .palw.bundle、検証対象の公開 JSON、schema v4 の SQLite state、最後に作成する misaka.palw.receipt-set.v2 completion marker の一式です。秘密 opening、署名済み request/assignment、検証用 registry snapshot は公開 JSON ではなく暗号化 bundle に封入します。 公開 metadata は strict misaka.palw.public-receipt.v2 で、unknown field を拒否し、保持する artifact/observer field を authenticated bundle と照合します。palw-verify-bundle がこの一式を 別 process で復元・再検証します。上記 final-v5 のDBは旧schema v3であり、当時の検証証跡として 保持します。schema v4 sourceはsilent migrationを行わず、旧DBをcurrent stateとしてopenしません。

repository-scope の設計・実装・evidence baseline はこの版で固定しますが、これは Production Network readiness の完了を意味しません。R13/R21/R23/R24/R26/R27/R35 の未達gateは内部統合と外部境界を docs/requirements.md で分離し、R32 は In progress です。以下の CUDA producer evidence は移行前 dense Qwen3-8B を対象とした legacy V2 CUDA track の測定記録で、現行 35B の main path（Metal、41/41 offload）とは別系統として保持します。Windows WSL2の Ubuntu 24.04、RTX 4060 Ti（sm_89）、CUDA Toolkit 13.3.1 / nvcc 13.3.73で、当時の固定 Qwen3-8B GGUFの37/37 layer CUDA offloadとbatch 1 graph observerの6/6同一diagnostic streamを確認しました。さらにstandaloneの producer-internal FP32 accumulator採取primitiveはsm_89 standalone device gate 7/7と20/20同一diagnostic fingerprintを通過しています。vendored llama.cppのQ4_K/Q6_K MMVQ full-K pre-epilogue hookも traced llama contextと同じCUDA backendへattachし、FA-off 1-token diagnostic E2Eで253 launch（Q4_K 216 / Q6_K 37）を取得します。さらにFA-off eager attentionのQK GEMM 36、softmax 36、PV GEMM 36を同じ request-local V3 producerへ統合し、合計361 recordを3回連続で完全取得して同一fingerprintとなること、 5 work classそれぞれの先頭拒否がfail closedになることを確認しました。

CUDAはadditive 184-byte V2 codec、strict Rust full-stream/dispatch/runtime binder、authority署名と runtime/job/schedule/integrationへbindする将来のReceipt V2 evidence candidateに加え、FA-off attentionの canonical 3-sublaunch groupingを持つ452-byte V3 schema/binderを実装しています。 ComputeReceiptV1にはこのprovenanceをcommitするfieldがないため、builderとverifierはCUDA KernelSketchをともにfail closedで拒否します。現行deterministic profileのFA-off eager attentionには V3 schema/binderに加え、実QK-score/softmax/value-aggregation work直後の同一stream collectorと typed graph associationをsourceへ統合しました。実機361-launch gate、exact mangled entry point、 runtime CUDA attributes、DSO/fatbin/cubin/section hashを結ぶrelease manifest、361-launchを厳密にbindする Receipt/RuntimeManifest/Request/Assignment V2、暗号化Bundle V2、原子的SQLite V2は実装・検証済みです。 ただしlive C++ smokeはdiagnostic callbackであり、authority提供のcanonical physical-layout IDから production署名Receiptを発行する経路ではありません。このため PALW_CUDA_TRACE_PRODUCTION_CAPABLE=0、PALW_CUDA_PRODUCER_VENDOR_RUNTIME_INTEGRATED=0、 PALW_CUDA_PRODUCER_RECEIPT_MAPPING_AVAILABLE=0、PALW_CUDA_PRODUCER_PRODUCTION_CAPABLE=0 のままproduction CUDA Receipt発行は拒否されます。 要件別の状態は同requirements matrixを正本とします。

Rust crate の宣言 MSRV は 1.85 です。protocol が要求する ML-DSA-87 stack（ml-dsa 0.1.1 → signature 3 / hybrid-array 0.4 / module-lattice / rand_core 0.10 / getrandom 0.4）が edition-2024 manifest を配布しており、Cargo 1.85 未満はそれを parse すらできません。以前宣言して いた 1.81 は --features ml-dsa のどのビルドでも充足不能でした（cargo +1.81.0 check は constant_time_eq 0.4.2 の manifest parse で即座に失敗します）。あわせて zeroize 1.8.1 / base64ct 1.7.3 を exact pin しています。MSRV、host sanitizer、手動 experimental NVIDIA gate は .github/workflows/palw-ci.yml にも定義しています。NVIDIA job は production approval や R32 completion を意味しません。

開発・検証コマンド

依存ツールとモデル取得用 Python 環境:

uv sync --frozen

固定 artifact、4つの llama.cpp target、Metal device を再検証:

./scripts/verify-install.sh

Rust 1.85 MSRV core gate と release CLI:

rustup toolchain install 1.85.0 --profile minimal --component rustfmt,clippy
cargo +1.85.0 fmt --manifest-path runtime-palw/Cargo.toml --all -- --check
cargo +1.85.0 clippy --manifest-path runtime-palw/Cargo.toml --locked --all-targets -- -D warnings
cargo +1.85.0 test --manifest-path runtime-palw/Cargo.toml --locked --all-targets
cargo +1.85.0 build --release --locked --manifest-path runtime-palw/Cargo.toml \
  --bin palw-metal-receipt --bin palw-verify-bundle

現行 MSRV test result は 224 passed、2 ignored（226 discovered）です。ignored 2件は pinned Qwen model と Metal observer を必要とする実モデル test で、release build と汚染した親環境を使った 手動 gate では 2/2 passed です。

実モデル Receipt の生成、SQLite 検査、CUDA host/device gate は docs/runbook.md に記載します。実測証跡は docs/evidence/metal-smoke-schema-v4-2026-07-15.md と docs/evidence/cuda-wsl-sm89-2026-07-15.md と docs/evidence/cuda-v3-mmvq-hook-sm89-2026-07-15.md と docs/evidence/cuda-v3-full-hook-sm89-2026-07-16.md を参照してください。旧 schema-v3 の証跡は docs/evidence/metal-smoke-2026-07-15.md に履歴として残します。

セキュリティ上の境界

Receipt は prompt、prompt token IDs、generated token IDs、出力 bytes、opening、private key、 owner salt を公開しません。Receipt CLI は --prompt-stdin、--audit-key-file、--output-dir をすべて必須とし、prompt は UTF-8・非空・最大 1 MiB に限定します。argv で prompt を受ける 互換入口はありません。Qwen adapter も prompt を tokenizer/native observer の argv に置かず 専用 stdin pipe で渡し、通常の Receipt 実行では decoded output bytes を IPC JSONL から省略します。

audit key は output directory の外に置く exact 32-byte raw key で、同一 owner、single-link の regular file、mode 0400 または 0600 を要求します。output directory は owner-only 0700、 bundle と DB は 0600、公開 .palw / JSON / marker は 0644 です。v2 marker は receipt ID、 bundle ID、公開 JSON の SHA-256 を結ぶ crash-completion signal ですが、秘密鍵付き MAC や network authority の署名ではありません。marker 単独を真正性や maturity の根拠にせず、必ず bundle verifier と trust policy を通します。

一方、単独ノードが発行する Receipt はそれだけでゼロ知識の計算証明になるものでは ありません。PALW の不正耐性は runtime/model digest、署名、k=2 replica、future audit、 canary、bond/slashing を組み合わせて成立します。Metal の graph fallback は CUDA kernel trace ではありません。詳細は docs/security-model.md を参照してください。

ローカル CLI が実行ごとに生成する scheduler/worker signing key、network ID、job ID は、この ローカル証跡を相互に bind するための値です。production network の登録済み scheduler、worker credential、beacon service、auditor、payment/escrow authority を表すものではありません。 replication/future auditに加え、scheduler-signed durable canary、authority-signed bond funding/appeal/ decision、assignment lock/release/slash/health、authority-confirmed External settlementのschema-v4 coreは 統合されています。maturityは必要なassignment bondをrelease/linkし、WorkTicketV2はmaturity basisと External weight grantをbindします。External settlementはterminal confirmation、両bond release、maturity、 ticketをlocal SQLite transactionでatomicにしますが、実payment railの資金移動そのものとのdistributed atomicityは主張しません。これらを運用するproduction authority/governance/payment serviceはrepositoryの 完了範囲外です。

Work Ticket の maturity は caller が raw flag で登録できません。field/constructor が非公開の MatureEvidence を Self Local audit の Mature state、Self Replicated の typed k=2 pair、または authority-confirmed External settlement だけが生成し、SQLite はその証拠、maturity_basis_id、 mature_epoch、必要なbond release linkを検査してから一回だけWorkTicketV2へ消費します。

---

関連: Qwen2.5-1.5B PALW A16 runtime(同じネットワークの dense クラス)