抡锤者

David Chen

我建議各位在發文前，發個範例文章給AI分析，請她照格式轉成md，妳再複製張貼，這樣就很快了，我都是用這懶人法發文的

David Chen

@YDM 是沒錯，但是阿貓阿狗就不會知道你是誰，光這樣就排除99.9%的麻煩了

David Chen

Screenshot from 2026-09-13 17-51-37.webp
先講結論：82GB 的 MoE 大模型塞進兩張 32GB 的 5090，開 MTP（Multi-Token Prediction）投機解碼，實測 decode 平均 75.4 t/s，draft 接受率 69.4%。比原本 NVFP4 引擎跑約 10 t/s 快了 7 倍。過程中踩了三個坑，全部記錄在下面。

1. 目前設備

項目	規格
CPU	AMD Ryzen 9 9950X3D（16C/32T，最高 5.76 GHz）
RAM	60 GB DDR5
GPU	2 × NVIDIA GeForce RTX 5090 32GB
OS	Ubuntu 24.04.4 LTS (Noble Numbat)
Kernel	7.0.0-31-generic
NVIDIA Driver	595.84

兩張卡沒有 NVLink / P2P DMA，tensor split 的跨卡通訊走 host 記憶體（走 PCIe），這是後段效能數據需要留意的點。

2. 軟體版本與 AI 模型

llama.cpp build

version: 0.3.0-dev (build 10715, commit 92cedc867)
built with GNU 11.4.0 for Linux x86_64
(Compiled by the Unsloth team)

用 Unsloth 官方 prebuilt 的 cuda13-portable linux-x64 版，不是自己編。

模型

	檔案	大小	說明
Target	`Qwen3.8-Flash-Next-UD-IQ3_XXS`（3 分片）	77 GB（10.9 MB + 49.6 GB + 32.4 GB）	主模型
MTP draft head	`mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf`	2.6 GB	投機解碼 head

模型架構 qwen4exp，embedding_length = 2560，target block_count = 48，head 是 49 層（48 主 + 1 nextn）。

️ 版本相容性是這題的第一個坑

Unsloth 的 MTP head 用的是新式 per-block tensor 命名（blk.48.nextn.hc_head_down/up/norm）。我原本的 build 是 10702，只認舊式的 top-level output_hc_norm.weight，結果直接 fatal：

E llama_model_load: error loading model: check_tensor_dims:
  tensor 'output_hc_norm.weight' not found

換成 quimmedes 的舊 schema head 也不行，變成 tensor 數量對不上：

W model has unused tensor blk.48.indexer.q_proj/k_proj/q_norm/k_norm — ignoring
E llama_model_load: wrong number of tensors; expected 35, got 34

三个 head 全部跟 build 10702 不相容。 正解是照 README 用 b10715（unslothai/llama.cpp PR#144）。head 和 build 必須一起對，不能只換一邊。

驗證 head 跟 target 配對的方法（用 python gguf.GGUFReader 讀兩邊 metadata 比）：同 general.architecture、同 embedding_length、head 的 block_count = target + 1、head 有 nextn_shared_target_tensors = True。

3. GPU / CPU 實際記憶體佔用

VRAM（雙卡 tensor split，1:1）

	GPU 0	GPU 1
已用	29,035 MiB	29,581 MiB
總量	32,607 MiB	32,607 MiB
剩餘	3,572 MiB	3,026 MiB
溫度	52 °C	44 °C
功耗	213.8 W	226.7 W
利用率	59 %	49 %

進程 llama-server 在兩卡各佔 29.0 GB / 29.6 GB。

RAM


進程 RSS	8.6 GB
系統已用	11 GB / 60 GB
系統可用	49 GB

注意：模型檔 77 GB > RAM 60 GB，所以開機載入時一定會有磁碟 I/O（走 page cache 分頁）。RAM 剩很多是因為 --n-cpu-moe 0 沒有把 MoE expert 留在 CPU，模型權重全在 VRAM。

️ VRAM 幾乎打滿，這是第三個坑

兩卡各只剩 3 GB 上下。log 顯示實際 request 已經吃到 25,663 tokens 的 prompt，再長一點、或改多並發（-np 加大），很可能直接 OOM 把服務打掛。這套配置目前是**單併發（-np 1）**才跑得動。

4. 參數指令

從運行中進程的 /proc/<pid>/cmdline 直接抓出來的，不是我貼的範例：

# Unsloth cuda13-portable prebuilt 需要 CUDA 13 runtime（第二個坑，見下方）
export LD_LIBRARY_PATH="/path/to/cuda-13/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

llama-server \
  -m  /models/Qwen3.8-Flash-Next-UD-IQ4_XS/UD-IQ4_XS/Qwen3.8-Flash-Next-UD-IQ3_XXS-00001-of-00003.gguf \
  --n-gpu-layers 99 \
  --split-mode tensor \
  --tensor-split 1,1 \
  -ot per_layer_token_embd.weight=CPU \
  --n-cpu-moe 0 \
  --load-mode none \
  --ctx-size 69632 \
  --flash-attn on \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --batch-size 2048 \
  --ubatch-size 512 \
  -np 1 \
  --kv-unified \
  --jinja \
  --reasoning-preserve \
  -t 32 \
  --host 0.0.0.0 \
  --port 12435 \
  --alias qwen38-nvfp4-mtp \
  --no-webui --no-mmproj \
  --spec-type draft-mtp \
  -md  /models/mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf \
  --spec-draft-n-max 2 \
  --n-gpu-layers-draft 99

關鍵參數說明：

參數	作用
`--split-mode tensor` + `--tensor-split 1,1`	雙卡等量切分，77GB 模型對半分
`-ot per_layer_token_embd.weight=CPU`	embedding 丟 CPU，省 VRAM
`--cache-type-k/v q4_0` + `--kv-unified`	KV cache 量化到 4bit，69K context 才塞得下
`--ctx-size 69632`	約 68K context
`--spec-type draft-mtp`	啟用 MTP 投機解碼
`--spec-draft-n-max 2`	每輪最多猜 2 個 token
`--n-gpu-layers-draft 99`	draft head 全數 offload 到 GPU
`-np 1`	只跑單併發，多併發 VRAM 撐不住且 MTP 會反虧

️ 第二個坑：Unsloth prebuilt 的 CUDA runtime 依賴

這是讓我卡最久的一個。換好 build 10715 之後，執行直接炸：

W common_fit_params: ... llama_params_fit is not implemented for SPLIT_MODE_TENSOR, abort
E llama_prepare_model_devices: LLAMA_SPLIT_MODE_TENSOR needs >= 1 devices

看起來像雙卡設定寫錯，其實是這支 prebuilt 看不到任何 GPU。查下去發現：

ldd libggml-cuda.so:
    libcudart.so.13 => not found      ← 缺
    libcublas.so.13 => not found      ← 缺
    libcuda.so.1 => /lib/... (OK)     ← 只有 driver API

cuda13-portable 的 libggml-cuda.so 需要 CUDA 13 的 runtime libs，而本機只裝了 driver（595.84）沒有 CUDA 13 toolkit runtime。而且這支 build 是 ggml_backend_dl: true + rpath: $ORIGIN（backend 執行期動態載入），所以 ldd llama-server 主程式看不到 CUDA 相依，要 ldd libggml-cuda.so 才看得出來。

解法不用裝 CUDA toolkit，只要把路徑指過去（我直接借用原本另一個引擎在用的同一組 CUDA 13 libs）：

export LD_LIBRARY_PATH="/path/to/cuda-13/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

加上之後 ldd 的 not found 變成 0 個，雙卡就抓到了。

關於 `borrow_shared_tensor` 錯誤行

用 shared head 啟動時 log 會出現：

E llama_model_load: error loading model: borrow_shared_tensor: this model is a draft head without its own 'token_embd.weight'; load it as a draft of its target model, not on its own
W operator(): failed to measure the memory of the extra model, fitting without it

這是正常行為（README L107-119 有說明）。shared-Q8_0 是靠借用 target model 的 tensor 來省 1.3GB VRAM，所以單獨載入時會報這個。看到不用緊張，MTP 照樣跑。

5. 效能數據

全部數字從 server log 統計得出（13 次完整生成樣本，累計 46,358 個 decode tokens），不是跑基准測試，是實際使用流量。

Decode 速度

項目	實測
平均	75.4 t/s
範圍	67.7 ~ 82.2 t/s
每 token 延遲	12.2 ~ 14.8 ms
全部樣本平均	75.0 t/s

MTP 投機解碼成效

項目	實測
draft 接受率平均	69.4%
接受率範圍	55.8% ~ 82.9%
平均草稿長度	2.39（猜 2 個，平均中 2.39 個含 draft）

接受率 69.4% 高於 README 標示的 66%（README 那個數字是greedy 下的保證值）。

Prompt Processing

項目	實測
平均	848 t/s
範圍	202 ~ 1,476 t/s
最大單次	25,663 tokens，21.09 秒（1,216.83 t/s）

pp 變異很大（202~1476），因為短 prompt 沒有足夠 batch 效應。

對照：換腦前後

引擎	decode
原 NVFP4 引擎	~10 t/s
llama.cpp b10715 + MTP	75.4 t/s

約 7 倍。

️ 關於 MTP 划算的條件（重要）

Unsloth MTP README 的數據，跟我自己觀察一致的：MTP 只在單併發下賺。

情境	MTP 表現
併發 1	1.3 ~ 1.7× 勝出
併發 8	~0.81×，反虧

而且 README 的數字是 greedy decoding 下才有；temperature 拉高後接受率會掉（我實際用非 greedy，接受率就在 55~82% 跳）。

所以這套配置是「單流高吞吐」取向。如果你的場景是多 client 併發打同一個 port，開 MTP 反而是負擔——那個情境應該關 --spec-type，或者用更大的 draft 容量去換。我目前 -np 1 就是這個理由。

總結踩過的三個坑

build 和 head 必須一起對：build 10702 + unsloth 新式 head = output_hc_norm.weight not found；舊 head + 新 build = wrong number of tensors。照 README 用 b10715（PR#144）。
cuda13-portable 需要 CUDA 13 runtime：只裝 driver 會報 needs >= 1 devices（誤導性錯誤訊息）。查 ldd libggml-cuda.so（不是 ldd 主程式），用 LD_LIBRARY_PATH 補路徑。
VRAM 只剩 3 GB/卡：77GB 模型對半切進 2×32GB，KV cache 量化到 q4_0 才擠進 69K context。想加併發或加長 context 之前先算 VRAM，-np 1 是目前的上限。

驗證 MTP 有真的在跑（給同樣配置的人）

grep 'draft acceptance' server.log
# 出現 "draft acceptance = 0.69 (N accepted / M generated), mean len = 2.39" 才是真的在跑

如果出現 draft-mtp 相關的 no nextn 之類錯誤，代表 head 或 build 不對。

David Chen

@Xiaote 妳說對了，這是我跑完後覺的怪怪的，目前NCCL還在弄...弄出來會更新上去（如果成功的話）希望能PP破2500 TG破百

David Chen

不知道有沒人分享

每次系統再跑時最討厭的兩件事

①compacting

②self improvement

都會花很多時間

其中②

background_review.enabled 系統初始值是 true（開啟）。

來源：agent/background_review.py

這可以ai關掉，如果不想失去這功能，可以改成夜深人靜跑一次

David Chen

這種30t/s光compacting的時間就整死你了，沒到100t/s真的會玩到一肚子氣，目前也無法啟動tensor parallelism ....llamacpp好像在嘗試....我丟任務給我家ai每天去追任務

David Chen

@kos-or 最近數學界對AI的數學難題突破，也提出質疑，因為有些解法被高度懷疑是從數學家還未發表的論文致敬出來的，事實上被懷疑的模型公司不置可否....機密資料上傳雲端本來就是很蠢的事哪怕DID做的完備也一樣

David Chen

看到板上幾篇 5070 Ti / 3070 Ti 異構雙卡跑 Qwen3.8 的分享，數據都很紮實。我這邊條件好一點（雙 RTX 5090 32GB），把生產環境實際在跑的 Qwen3.8-27B 數據整理出來分享，重點是「哪些優化方向實測有效、哪些是白做工」，希望對其他雙卡玩家有參考價值。

1. 硬體與軟體

項目	配置
GPU	2× RTX 5090 32GB（SM120 Blackwell）
CPU	Ryzen 9 9950X3D（16C/32T）
記憶體	60GB DDR5
系統	Ubuntu 24.04.4 LTS
引擎	llama.cpp（LM Studio 2.29.0 CUDA12 binary）
模型	Qwen3.8-27B-BF16（兩片 GGUF 共 54.6GB）＋ mmproj-F16（928MB，啟用 Vision）
Context	140,000（對齊 Hermes context_length；原 200000 多出的 70K 純佔 VRAM，已縮小）
KV	q8_0 / q8_0
Split	tensor 0.5,0.5
MTP	關閉（實測更慢，見 §4.1）
用途	Hermes Agent 主腦，長期單 slot 真實對話流量，非固定短 prompt benchmark

2. 生產啟動參數

llama-server -m Qwen3.8-27B-BF16-00001-of-00002.gguf \
  --mmproj mmproj-F16.gguf \
  --n-gpu-layers 99 \
  --split-mode tensor --tensor-split 0.5,0.5 \
  --ctx-size 140000 -fa on \
  --batch-size 4096 --ubatch-size 4096 \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  -np 1 --kv-unified \
  --jinja --metrics --no-webui

重點說明：

-np 1：單 slot 長 context，避免 KV 爆炸。--kv-unified 保留著，之後開多 slot 時兩 slot 共享總 KV pool（按需分配，不靜態平分），目前單 slot 下無副作用。
-fa on：長 context 下顯存與速度都受益，必開。
--metrics：Prometheus endpoint，MTP 接受率、prefill/decode 總量都從這裡看，比翻 log 方便。
--jinja：走模型官方 chat template，thinking 輸出行為才正確。

3. 實測數據（生產 log 為準）

以下全部取自 llama-server 自己的 print_timing 與 /metrics，不是 client 端量測（client 端 burst 量測會偏高 ~30%，這坑我踩过）。統計區間為本次啟動後 53 筆已完成任務，真實 Agent 工作流（含工具操作與上下文逐步累積）：

llamacpp:prompt_tokens_total        395739
llamacpp:prompt_seconds_total       341.57   → prefill 平均 1158.6 tok/s
llamacpp:tokens_predicted_total      86194
llamacpp:tokens_predicted_seconds   1793.85  → decode 平均 48.05 tok/s
llamacpp:n_tokens_max               99372    → 單 task 最大 context
llamacpp:requests_deferred               0

逐 task 抽樣（每 task 一個 session turn，* = 累計 context 已達 99.4K 的長任務）：

task    prompt       prefill     gen tok    decode
68781   ~1.7K        1017 t/s    119        47.72 t/s
68902   ~0.2K 增量    393 t/s     455        47.44 t/s
69995   ~2.8K        1168 t/s    433        50.01 t/s
70430   ~0.5K        678 t/s     117        50.37 t/s
74156   ~0.9K        848 t/s     1312       49.18 t/s
75470   ~4.5K        1121 t/s    1038       49.13 t/s
70549   ~4.7K        1104 t/s    3604       49.35 t/s
76862   ~1.6K *      989 t/s     9517       48.29 t/s
86382   ~1.1K        924 t/s     2728       48.43 t/s

觀察：

decode 非常平穩：47.4–52.4 t/s，約 20.5 ms/token，從 1K 短 context 到 99.4K 長 context 幾乎不衰减——BF16 權重下 5090 的 1792GB/s 頻寬在 decode 端壓力還不大。
最長 task 一次生成 9517 tok（近 3.4 分鐘持續輸出），全程 0 OOM、0 pipeline fallback、0 deferred。
prefill 在 0.5K–4.7K 增量下穩定 840–1170 tok/s（前綴快取命中時更高）。
峰值 99,372 tokens < 140K 上限，餘量健康。
VRAM：GPU0 ~31.3GB / GPU1 ~30.2GB（各 32.6GB），BF16 雙卡各分 ~27GB 權重 + KV，headroom 約 1–2.3GB/卡。想再拉 ctx 就得降量化。
載入：54.6GB BF16 兩片 mmap，NVMe 上約 30–40 秒。

4. 實測過的優化方向：哪些有效、哪些放棄

4.1 MTP（投機解碼）——實測放棄

Qwen3.8-27B GGUF 內建 MTP draft 層（blk.64），理論上 decode 可以白賺一截。實際開 --spec-type draft-mtp 實測後關閉：

接受率約 40%（這模型的 draft head 偏弱，比 Qwen3.6 系的 62–71% 低一截），--spec-draft-n-min 調低變負優化；
draft 佔 VRAM + 配置複雜度上升；
雙卡 tensor split + MTP 實測比純 decode 還慢——跨卡同步開銷吃掉了投機解碼的收益。

驗證 MTP 確已關閉的方法：啟動 log 會有 15 行 model has unused tensor blk.64.* -- ignoring，合計約 810MB——這 15 行代表內建 MTP 層被丟棄，是「MTP 已關」的正面證據，不是異常。

4.2 雙卡 split：同型號卡 tensor，異構卡 layer

同型號雙卡（我這台）：--split-mode tensor 0.5,0.5 沒問題，每層雙卡各算一半。
異構卡（如 5070 Ti + 3070 Ti）：layer split 更合理，tensor split 每層跨卡 all-reduce 會被最慢那張卡釘死。
雙 5090 走 PCIe 的 internal AllReduce（用 LM Studio binary 時 log 裡有 NCCL 行），沒另編 NCCL build——實測 NCCL 自編版沒有更快，維持現狀。

4.3 換引擎——SGLang / NInfer 都測過

SGLang 0.5.17：載不動。對 unsloth Qwen3.8 GGUF 直接報 unknown architecture: qwen35（2026-08 新架構還沒進 transformers GGUF arch map）；改載 HF 原生權重會反量化成 BF16 → 每卡 27GB OOM；--quantization gguf loader 仍找 safetensors。SM120 上 FP8/NVFP4 kernel 也不完整。結論：llama.cpp 是目前唯一完整支援 Qwen3.8 GGUF 的生產選項。
NInfer（自 build）：更快，但生態封閉。同一顆空 5090、同 ctx、同 prompt 對決：NInfer prefill ~8575 tok/s（llama.cpp ~2975，約 2.9×）、decode 180.6 vs 141.25 t/s（約 1.28×）、warm ttft 19ms vs 66ms；MTP 接受率兩邊都 ~62% 打平——差距來自引擎本體 kernel 效率，不是 MTP。NInfer 現在是我的備用腦/實驗場，生產主腦維持 llama.cpp（OpenAI 相容 API + 生態成熟 + 換模型零成本）。

4.4 有效的長期配置決策

ctx 對齊实际需求：llama.cpp 啟動時預分配整塊 n_ctx 的 KV buffer（不是按需長），200000 → 131072 一步直接省下 3–4GB/卡。
KV 量化 q8_0：Qwen3.8-27B 是 GQA-4（head_count_kv=4，不是 30——早期用 30 heads 估 KV 會高估 7.5 倍），17 層 KV，q8_0 約 37KB/token：200K ctx ≈ 7.3GB、256K ≈ 9.7GB。KV 才是長 context 的大頭，不是權重。
thinking 模型讀兩個欄位：長推理輸出落在 reasoning_content，content 會是空的——用 API 驗證時別把空 content 當成失敗。
雙卡 VRAM 統計：nvidia-smi --query-compute-apps 裡 tensor split 的 PID 每張卡各出現一次，要加總，別只看一行。

5. 給雙卡玩家的參數建議（單 slot 長 context）

-tp 2 / --split-mode tensor --tensor-split 0.5,0.5   # 同型號卡
--split-mode layer --tensor-split 16,8               # 異構卡（按 VRAM 比例）
-fa on                                               # 必開
-ctk q8_0 -ctv q8_0                                  # KV 量化
-np 1                                                # 單 slot
--ctx-size <對齊前端 context_length>                 # 別多開，KV 啟動即預分配
-b 4096 -ub 4096                                     # prefill 批大小（prefill 慢可降 ub）
--jinja --metrics                                    # 官方模板 + 可觀測性

6. 結語

雙 5090 + BF16 140K 對我這種 7×24 單 slot agent 場景是「夠用且平穩」的配置：decode ~48 t/s 穩定、99K context 無衰减、零 fallback。最大的心得是：先測再優化——MTP、NCCL、SGLang 三個「理論上應該更快」的方向全數實測過，兩個更慢、一個載不動，最後贏的是最樸素的 tensor split + q8_0 KV + 合身的 ctx。

數據全部可重現：引擎端 log（print_timing）+ /metrics，啟動參數如上。有問題歡迎直接問，踩過的坑都寫在上面了。

附：所有數據以引擎端 log 為準；client 端量測（TTFT/burst）與引擎端 print_timing 計時窗不同，會偏高，引用時請註明口徑。

David Chen

lcz.me 貼文排版規則：為什麼有些貼文漂亮、有些糊成一團

背景

目標： 搞清 lcz.me（NodeBB 論壇，https://lcz.me）的貼文渲染規則，讓技術文檔貼上去排版漂亮。
起因： 大人把 qwen38-5090x2 經驗文（含 5 欄 pipe table）貼上 lcz 預覽，整篇難看，尤其是表格。
日期： 2026-08-27

研究方法（可複現）

lcz 是 NodeBB（不是 Discourse），匿名可用的存取方式：

# 分類主題列表（注意：page 參數無效，用 nextStart/after 游標分頁）
curl -s "https://lcz.me/api/v3/categories/7/topics?pageSize=25" -H "User-Agent: Mozilla/5.0"

# 單篇貼文 raw 內容
curl -s "https://lcz.me/api/v3/posts/{pid}" -H "User-Agent: Mozilla/5.0"

# SSR 渲染 HTML（抓渲染後長相，不用開瀏覽器）
curl -s "https://lcz.me/t/{tid}" -H "User-Agent: Mozilla/5.0"

分類 7 = LLM 討論區
對照組：tid=1345（88 行 pipe table 的 R9700 實測）、tid=1349（高讚口語流貼文）、tid=917（漂亮且有表格）、8/26 後 23 篇新貼文
判定渲染結果：直接比對 SSR HTML 裡 <table> / <pre> 的數量與 class

核心結論

1. lcz 完整支援 pipe table 與 code fence

tid=1345 的 SSR 渲染出 20 個 <table class="table table-bordered table-striped"> + 50 個 <pre>，
右對齊（style="text-align:right"）、加粗（<strong>）都正常。不是「lcz 不會畫表格」。

2. 難看的原因：表格太寬，不是語法錯

lcz 帖子正文寬度約 850px。5 欄 pipe table 加中文表頭 → 每格擠成 3~4 字一行、
整張表撐出橫向捲軸，看起來糊成一團。1~2 欄 key-value 表（硬體/配置）則正常。

3. 版上「漂亮貼文」的排版慣例（實測對照組歸納）

慣例	說明	反例（難看）
pipe table 只用 2~3 欄	2 欄最常見：`項目/配置`、`場景/實測`	5 欄以上 pipe table（無一篇這樣做）
寬數據表放 code block	用 ``` 等寬文字手動對齊（如 1345 逐 task 數據）	把逐 task 大表寫成 pipe table
章節號用阿拉伯數字	`## 1. 硬體`、`## 2. 數據`	`## 一、硬體`
code fence 標語言	`bash /` text	裸 ```
短段落 + 口語 + 重點加粗	高讚貼文特徵（1349 零表格零 code fence）	大段不分行文字

4. 重寫對照（本次案例）

原稿	重寫後
5 欄逐 task 抽樣 pipe table（9 筆）	code block 等寬對齊，9 筆數據整齊不擠
`## 一、硬體`	`## 1. 硬體與軟體`
裸 ```	`bash /` text
硬體 1 欄 key-value 表	保留（2 欄化，本來就對）

重寫版：how_to/qwen38-5090x2-experience-lcz-20260827.md（大人實測：格式正確，已貼上 lcz）。

️ 教訓

先查渲染規則再排版：貼文難看 ≠ 平台不支援。用 SSR HTML 抓一篇「漂亮對照組」看實際渲染，比猜快。
寬表一律進 code block：lcz 上 >3 欄的數據表，用等寬文字對齊是版上通行做法。
pipe table 的寬度上限 ≈ 3 欄：中文表頭會更吃寬度，2 欄最安全。
匿名 API 可用端點：/api/v3/categories/{cid}/topics（after 游標分頁）、/api/v3/posts/{pid}（raw）、SSR 主題頁。/search.json 匿名被擋。
NodeBB page 參數無效：分頁用回應裡的 nextStart / after 游標（與 lcz-forum-backup-lessons.md 血淚教訓 #1 一致）。

專案狀態：2026-08-27 完成研究並實測驗證（大人貼上 lcz 確認格式正確）。本檔為快照，lcz 若改版渲染規則需重新驗證。

David Chen

我們知道ornith-1.0-35b 是 gemma4 + Qwen 和親出來的
gemma4 31B Q8 用一段時太慢又太笨，感覺只能聊天
現在正在二選一
ornith-1.0-35b Q8 與 Qwen3.6-35b-a3b Q8....大家覺的哪個更優秀?

抡锤者

David Chen

帖子