docs: how the Uncensored payload is really fetched (it is shipped in parts)
Correcting a claim I made from a bad query: Q4_K_S does exist for this finetune. `mradermacher/Qwen3.8-Flash-Next-Uncensored-i1-GGUF` ships the large quants as `.partNofM` fragments — Q4_K_M 37.00+37.00+36.97 = 110.97 GiB (which is how the deployed file was assembled) and Q4_K_S 35.00+35.00+34.09 = 104.09 GiB — while the smaller rungs are single files. A tree listing filtered on `.gguf` makes Q4_K_S invisible, which is exactly how I concluded it did not exist. Also records the fetch trap that hid it for a moment: `curl -o FILE URL` exits 0 on 401/403, so a gated repo produced three 153-byte "shards" with identical sha256 values and a cheerful DOWNLOAD_DONE in 20 s for 104 GiB. -f plus the Hub's declared size plus the LFS sha256 is the standard the fleet's own download-frank-medium-gguf.sh already meets.
This commit is contained in:
1 parent
ad18d2ddd8
commit
88f0d79021
2 files changed
+26
No files matched your search
@@ -591,6 +591,23 @@ linked runbooks.
|
||||
(169.254.1.2). This is what 502'd `hermes.franksdank.cloud` until the Caddyfile
|
||||
upstream was changed on 2026-09-16 (its vhost comment had claimed the LAN IP
|
||||
was open from that bridge — it never was).
|
||||
- **A `*.gguf` filter misses mradermacher's payloads: large quants ship as
|
||||
`.partNofM` fragments.** `mradermacher/Qwen3.8-Flash-Next-Uncensored-i1-GGUF`
|
||||
carries Q4_K_M (37.00 + 37.00 + 36.97 = 110.97 GiB) and Q4_K_S (35.00 + 35.00
|
||||
+ 34.09 = 104.09 GiB) as parts, while the smaller rungs (Q2_K, Q3_K_*, IQ3_*,
|
||||
IQ4_XS) are single files. Fetch the parts, verify each against the Hub's LFS
|
||||
sha256, concatenate in numeric order — that is how the deployed 111 GiB file
|
||||
was assembled. Listing the Hub tree and filtering `endswith(".gguf")` makes
|
||||
Q4_K_S look like it does not exist.
|
||||
- **A fetch script must `-f` and verify, or it reports success on an access
|
||||
error.** `curl -o FILE URL` exits 0 on HTTP 401/403 and writes the error body
|
||||
as the "artifact": a gated repo yielded three 153-byte shards with identical
|
||||
sha256 values and a cheerful `DOWNLOAD_DONE` in 20 seconds for 104 GiB. Use
|
||||
`-f`/`--fail-with-body`, compare each file's byte count to the Hub's declared
|
||||
size, and check the LFS sha256 — `scripts/download-frank-medium-gguf.sh`
|
||||
already does all three; ad-hoc fetches tend not to. Gated repos (e.g.
|
||||
`orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF`, same 104.09 GiB Q4_K_S)
|
||||
return 403 even with the host's HF token until that account accepts the gate.
|
||||
|
||||
## Runbook Index
|
||||
|
||||
|
||||
Reference in new issue
Block a user