27 days ago
-
整理中文 model card 與 SSD streaming 定位
-
model card (README.md): 重點整理 + 使用方法 + 證據對照; 修正 memwatch 證據檔互相覆蓋的 bug (probe 後重啟會覆蓋 1K 驗證的 json, 改用 -restart tag); 1K 峰值改報區間 0.35-0.67 GiB (三次量測, 參考上緣)
Auto Upload Agent
-
文件更新: 262144 達成結果 + 更正磁碟頻寬 (舊 4.3-5.1GB/s 是上一台機器, 本機 325MB/s) + 5 個量測陷阱
Auto Upload Agent
-
262144 理論最高上下文達成: KV 檔案 mmap 4.78 GiB @SSD , 峰值總 RSS 2.118 GiB < 3GB, swap 0, 實際推理成功; 修正 LLAMA_KV_SSD 決定被上一次啟動污染的 bug (start_server 覆寫變數 -> probe 誤判不放 SSD)
Auto Upload Agent
-
1K 驗證全數通過 (all_passed=true): 峰值總 RSS 0.668 GiB, swap 0 MiB; 新增 tools/io_probe.py 實測本機 SSD (單執行緒 325 MB/s, 4 threads 1213 MB/s) — 舊 STATUS.md 的 4.3-5.1GB/s 是上一台機器, 導致舊 0.33 tok/s 證據虛高; V3 max_tokens 96->8 (每 token 約 44s, 96 token 會逾時)
Auto Upload Agent
-
swap 違規已修正 (VmSwap 612MiB->0), 峰值總 RSS 0.67 GiB @1K
Auto Upload Agent
-
swap 違規根因修復驗證成功: 加上 --sweep 後 VmSwap 612 MiB -> 0, 峰值總 RSS 0.67 GiB; 修正 0001/0002 互相影響導致的 patch 誤判 (改用符號確認); sweep 間隔 0.25->1.0s (實測 0.25s 只是重做 4 倍功); 推論逾時 900->2400s; 修掉 -Wmissing-declarations
Auto Upload Agent
-
checkpoint: 1K baseline + swap root-cause fix + SSD KV patch (0002)
Auto Upload Agent
-
1K 驗證重現 (峰值總 RSS 0.565 GiB); 找出並修掉 swap 違規根因: installpi.sh 從未傳 --sweep, GGUF page cache 灌滿 16GB cgroup -> 核心把本行程匿名頁換出 (VmSwap 612 MiB); 新增 --sweep + patches/0002-kv-ssd-pager.patch (SSD-backed KV cache) 與 262144 實際推理探測
Auto Upload Agent
-
禁止 swap: KV cache 用 mlock 釘在 RAM (llama.cpp LLAMA_KV_MLOCK), 移除 setup_swap/swapfile 路徑, V6 換出量>1MiB 即失敗; 修正 memwatch /proc/limits 解析 (單位已是 bytes, 之前誤乘 1024 使驗證失效)
Auto Upload Agent
-
checkpoint: 1K 驗證證據已保存 (峰值總 RSS 0.586 GiB)
Auto Upload Agent
-
1K 端到端驗證通過: 峰值總 RSS 0.586 GiB (<3GB), 0.33 tok/s; pi_config 改為 skip 而非 fail; swap 使用量誠實記錄
Auto Upload Agent
-
installpi.sh: 1K 驗證 + 套用 SSD 權重釋放 patch, 更正 KV 容量計算 (17層/q4_0=0.5625), 記憶體判準改為總 RSS; 加 AGENTS.md 崩潰續作指引
Auto Upload Agent
-
v1: 真 3GB 總 RSS 約束成立 (789 MiB @1K ctx)
SDQwen Agent
修正核心概念錯誤: 舊版只驗證匿名記憶體, 但 GGUF 以 mmap(MAP_SHARED) 對映,
權重頁算進 RSS 且真的佔用系統 RAM。舊證據 peak_rss 15.2GiB 不是 3GB 方案。
改為以「總 RSS <= 3GB」為硬約束:
- llama.cpp patch: madvise(MADV_DONTNEED) 釋放權重常駐頁
(實測 posix_fadvise 從外部呼叫無效, 必須行程內部 madvise)
- 背景 sweeper 而非 compute 後釋放: 後者峰值仍 8.8GiB, 因為單次 decode
走完 65 層才釋放已太晚
- memwatch.py 重寫: metric=total_rss, 強制手段降級階梯 + 核心層級回讀驗證
結果: 峰值總 RSS 789MiB (從 8.8GiB), 1K ctx, 0.323 tok/s
0.323 tok/s 是 dense 模型在 3GB 的物理下限, 非未調好: 每 token 重讀
15.33GiB 權重, 零重複使用。對照 MoE 的 sddqwen35a3b 6.28 tok/s 不可比。
同時更正舊版 KV 容量計算錯誤 (16層->17層, q4_0 0.355->0.5625 B/elem),
舊算法高估約 3 倍, 照它設定 262144 會 OOM。
-
pin llama.cpp to validated commit 0504396 for reproducible SSD-streaming patch + build
Auto Upload Agent
-
limit build parallelism by available RAM to avoid OOM on 2-3GB machines
Auto Upload Agent
-
recovery checkpoint: merged storage history, verified 4k evidence, plan low-RAM rebuild
Auto Upload Agent
-
merge storage initial commit with validated 4k SSD inference
Auto Upload Agent
-
update STATUS.md with push info
Auto Upload Agent
-
merge storage repo
Auto Upload Agent
-
initial working 4k validation
Auto Upload Agent
-
initial working 4k validation: SSD-streamed Qwen3.8-27B with 3GB RAM limit
Auto Upload Agent
- Fixed llama.cpp AMX compile flags to disable 13.9 GiB weight copy
- Added SSD streaming patch (LLAMA_MMAP_PREFETCH=0) to keep weights on SSD
- Fixed memwatch.py anonymous memory calculation (uses /proc/PID/smaps_rollup Anonymous field)
- Disabled weight repack (--no-repack) to avoid 3.5 GiB allocation
- Validated 4K context with 0.84 GiB anonymous memory (within 3 GB limit)
- Model weights (15.33 GiB) stay on SSD via mmap, faulted in on demand
- Pi coding agent configured with theoretical max context 262144 -
Merge branch 'main' of https://huggingface.co/HelloSun/sddqwen38-27b
Auto Upload Agent
-
initial commit
-
Add auto_upload.py (token from env)
Auto Upload Agent
-
Recovery: uncommitted changes from crash
Auto Upload Agent
-
Enforce 3GB hard memory constraint: mmap/SSD streaming, 4K validation context