PrismML-Eng

Links from the tutorial (article bodies carry no links, so they live here): Model (2B GGUF + vision projector + SHA256SUMS): huggingface.co PrismML llama.cpp fork binaries (runs all three packings): github.com/PrismML-Eng/llama.cpp/releases/latest Demo repo (source of truth for running these models): PrismML-Eng/Bonsai-demo PrismML Bonsai 2 family announcement: prismml.com My measured numbers: PQ2_0 file 494 MB, SHA256 verified OK; 7.9x smaller than the claimed 3.8 GB FP16 size. Thinking-off answer 11.9 tok/s generation, 14.5 tok/s prompt. Math 17 x 23 = 391 correct, 12.1 tok/s. Vision test passed (red circle + blue rectangle + caption read). Server: 61 completion + 23 prompt tokens, 13.0 tok/s generation, 35.5 tok/s prompt. Vendor claims (276 tok/s, 3x efficiency) are theirs, not mine.

Bonsai-demo#283 不应该啊

Ternary-Bonsai-2-27B TQ1_0 or Gemma 4 12B it QAT Q4_K_XL? One of my setups (a laptop) includes an Nvidia 4060 Mobile with 8 GB VRAM. I am using Unsloth's Gemma 4 12B it QAT Q4_K_XL on it. I ran a quick test with the TQ1_0 version of Ternary-Bonsai-2-27B with their llama.cpp port, IMHO it seemed promising to use with my custom voice assistant. Unfortunately it is not yet supported by the official llama.cpp, if I understand correctly. Is anybody using that TQ1_0 quant of Ternary-Bonsai-2-27B or did some more extensive testing? Is it not worth it, anyway? What's your opinion / are your test results?

Qwen 3.8 27B Derivative on a 12GB RTX 3060: Up to 44 Tokens/s, Vision, Tools, and 128K Context Fully in VRAM [Edit] Here is the model working for a moment (while I record the screen): youtu.be Hi. I'm a software developer, and this is my best setup so far for running fast, useful local AI on consumer hardware. The goal is a useful local assistant: good speed, fewer mistakes, tools, vision, and the ability to write small scripts and games. It runs with a 128K-token context window, with the main model and context cache on the GPU, and image processing and context compression on the CPU. I've been using it to manage my calendar, search the web, and solve a more complex task: classifying, organizing, deduplicating, and comparing my old music files against my Spotify favorites playlist. My playlist is finally being updated automatically with all the songs I love <3. So far, it's working well. It even created a basic chair in Blender and wrote a Snake game in HTML/JS. (Note: these examples use tools and integrations configured separately, they are not included here.) My hardware: RTX 3060 with 12 GB of VRAM, Ryzen 7 3700X (8 cores, 16 threads), and 32 GB of RAM. I use vision and tools a lot and find this setup very competitive for daily use. Since I haven't found a better setup for my needs in the last two weeks, I decided to share what I've put together here. I run CachyOS, by the way. It may help inference speed, but I haven't isolated its effect. This guide is for Linux! I don't know how to reproduce the setup on Windows. What I use - Model: Swift Bonsai 2 27B Katana + MTP, based on Bonsai 2 / Ternary Qwen3.8-27B and tuned for shorter reasoning. - Model file: Swift-Bonsai-2-27B-Katana-PTQ1_0-MTP-Q8_0.gguf, about 6.4 GB. Ternary PTQ1_0 backbone, Q8_0 MTP head. - Vision projector: Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf, about 629 MB, loaded separately. - Inference: the Prism fork of llama.cpp, build prism-b10772-e8fd209, CUDA 13.3. - Agent: Hermes in Docker. - History compression: Granite 3.3 2B on the CPU through Ollama, registered locally as granite3.3-compressor:2b. My settings I keep the vision projector and Granite on the CPU to save VRAM. The 3700X handles both well enough for my use. Bonsai's config.env sets the options below. start.sh applies them and enables Flash Attention. |Setting|Value|Purpose| |:-|:-|:-| |Context / slots|CTX_SIZE=128000, PARALLEL=1|One conversation with a large context window| |GPU layers|N_GPU_LAYERS=99|Offload all model layers to the GPU| |K/V cache, including MTP|KV_CACHE_TYPE=q4_0|Reduce VRAM used by the context cache| |MTP draft|SPEC_N_MAX=1|Draft up to one token ahead per decoding step| |Reasoning|REASONING_EFFORT=medium, REASONING_BUDGET=2048|Limit thinking time| |Vision on the CPU|MMPROJ_CPU=1|Save VRAM, with slower image processing| |Image tokens|IMAGE_MAX_TOKENS=1536|My compromise: 1024 lost too much detail, 2048 took too long| |CUDA consistency|KATANA_BATCH_INVARIANT=1|Keep vision output correct with this runtime/GPU| Performance During one test response, generation stayed around 43–44 tokens/s and peaked at 45.74 tokens/s over a three-second window. In daily use, I usually see 28–40 tokens/s after a few prompts and 17–25 tokens/s much later on, with A LOT more context. MTP proposes tokens that the main model verifies to speed up generation. I tried draft limits of 1 and 2 and chose 1, also guided by sudoingx's Bonsai 2 PTQ1_0 + MTP tests on an RTX 3060 12 GB. With a 131K window and Q4 K/V, that setup reached 50.1 tokens/s with MTP versus 39.8 without, and 26.86 versus 22.23 with 41.8K tokens filled. Draft limit 1 beat 2 in both cases. These are the author's measurements, on a different model variant and runtime. 2 can also be a good choice - try SPEC_N_MAX=2 ./scripts/start.sh inside Bonsai-fast/ and compare it on your workload. Anyway, my results with slightly different models and setup were inferior, as I stated, so I'm not sure if I did something wrong here. I chose IMAGE_MAX_TOKENS=1536 for a balance of detail and speed: I got 2 seconds for photos of people near cars, 27 seconds for a complex image, versus up to 40 seconds at 2048 on a complex image. It still makes mistakes, regardless of the value. Prism recommends 1024 for general use and 2048+ or crops for fine text, so 1024 is also an option if speed matters more than detail. I chose q4_0 for my context based on published memory savings and how the complete setup performed in use. A cache-only benchmark on related Qwen 3.6 models found Q4 usable, with the largest output-distribution changes on long documents. A separate Bonsai 2 benchmark used Q4 successfully with 191K tokens filled on a 16 GB RTX 4080 SUPER. These are just supporting references, not measurements of my Katana setup. With 128,000 tokens per slot, Q4 K/V caches, MTP on the GPU, and the vision projector on the CPU, the whole Bonsai process used 9,144 MiB (8.9 GiB) of VRAM. The runtime allocates the context cache at startup, so the configured capacity fits my graphics card. The main attention K/V cache alone (context) is approximately 2,250 MiB (2.2 GiB) at 128K: 128,000 tokens x 16 full-attention layers x 2 K and V x 4 KV heads x 256 values per head x 18/32 bytes per Q4_0 value. With my desktop and other apps open, about 823 MiB (0.8 GiB) remained free. I roughly understand this calculation, but it’s easy to see how much Q4_0 reduces the result: it uses an average of 0.5625 bytes per value, compared with F16’s 2 bytes. For my 128K context, that reduces the main K/V cache from 7.81 GiB to 2.20 GiB, about 72% less memory - and the model still seems smart, so… I also considered q8_0, but q4_0 is still roughly half the size, it’s just off the table. On the model side, I chose ternary PTQ1_0 for its smaller memory footprint, leaving more VRAM for context and MTP. PTQ1_0 packs the same ternary weights more tightly than PQ2_0, at about 1.75 versus 2.13 bits per weight, without another quantization step. It doesn't mean zero quality loss compared with the original FP16 LLM, but is a fair price to pay for usability. The Prism fork of llama.cpp adds PTQ1_0/MTP kernels and attention that reads the Q4/Q8 cache directly, plus optimizations for the RTX 3060's sm_86 architecture. PTQ1_0 uses less memory, but whether it runs faster than PQ2_0 depends on your GPU and the runtime’s kernels. For reasoning, I use medium, following Prism's recommendation for shorter reasoning on the original Bonsai 2. In practice, every reasoning level feels like xhigh to me on Katana, so I also set a 2,048-token reasoning budget to keep thinking loops under control, with the server injecting this message when the budget is reached: “... Time to stop thinking. Give an answer or make the tool call now. Do not waste time.” Bonsai needs clear instructions for complex tasks. Otherwise, it can get stuck in a loop of writing and fixing helper scripts. The guidelines in my SOUL.md have helped it stay on track and finish tasks. To summarize the conversation history, I use Granite. I chose it for its small 2B size and support for long-document and meeting summarization. granite3.3-compressor:2b is my local name for this configuration. The included Modelfile keeps Granite's template and license, sets num_ctx 128000, and adds num_gpu 0 in the CPU variant. Chat compression takes 1.5–5 minutes in my tests, depending on the conversation content and size. Finally, I use Hermes Desktop with the included Docker container as its backend. I noticed the UI was using 15–35% of the GPU while the window was focused. Enabling --force-prefers-reduced-motion reduced animations and brought GPU usage down to 1–5%, leaving more resources available for model inference. Warning! These figures are mostly observations, not controlled benchmarks!! Although published tests guided my choices, I evaluated the complete setup in use rather than measuring each setting's individual gain. Installation Download: local-ai-bonsai.zip. Extract local-ai-bonsai.zip and open the extracted local-ai-bonsai/ folder. It contains all the setup files: |Folder|Contents| |:-|:-| |Bonsai-fast/|Model download and launch scripts| |hermes/|Docker Compose and Desktop UI settings| |granite-compressor/|128K compressor configuration, including CPU mode| |hermes-host-access/|Temporary SSH access from the container to the host, enabled when you choose| I haven't included every dependency. You need to install Docker, Compose, Ollama, and other prerequisites yourself. Bonsai requires Linux x86_64 and NVIDIA drivers and libraries compatible with CUDA 13.3. The ZIP contains scripts and configuration files. Setup downloads the model weights and inference binaries. See each folder's README for details. Start Bonsai Inside Bonsai-fast/: ./scripts/setup.sh ./scripts/start.sh setup.sh downloads and extracts the Prism runtime into bin/ and downloads the Katana model and vision projector into models/. Run it once to prepare the files. start.sh starts the inference server - keep it running while using Hermes. No compilation or Prism Model Manager is needed. Start Hermes Inside hermes/, enter your dashboard credentials and time zone in compose.yaml. These credentials let you sign in through the browser or Hermes Desktop, and a loopback-only setup may require the dashboard session token (HERMES_DASHBOARD_SESSION_TOKEN) to use the container as the Hermes Desktop backend. Then run: docker compose up -d Open http://127.0.0.1:9119 or connect Hermes Desktop to the backend. The container uses network_mode: host to reach Bonsai and Ollama. Its data/ and workspace/ folders persist. To use the container as the Hermes Desktop backend, open it and go to Settings -> Gateways -> Remote gateway, enter http://127.0.0.1:9119, sign in with the required credentials, then save and reconnect. In the web dashboard, open Config -> YAML. Merge this into providers:, keeping the other entries. Edit bonsai-mtp if it already exists: providers: bonsai-mtp: name: Bonsai MTP base_url: 127.0.0.1 model: swift-bonsai2-27b-katana-mtp discover_models: true context_length: 128000 models: swift-bonsai2-27b-katana-mtp: context_length: 128000 Click Save, then Models -> Main model -> Change. Pick Bonsai MTP, select swift-bonsai2-27b-katana-mtp, and click Switch. Use Refresh Models if needed. This sets the model for new sessions. Keep Hermes's context value aligned with Bonsai's CTX_SIZE=128000. The launch script also loads the vision projector. Optional extras Use hermes-host-access/README.md to install the temporary SSH bridge with new keys. This lets the sandboxed AI help with tasks on the host when needed. The bridge expires automatically after three hours in case you forget to close it. SOUL.md contains my general agent instructions. Customize it before copying it to hermes/data/SOUL.md. To reduce Hermes Desktop's animations, merge hermes/desktop-config.example.yaml into the Desktop client's ~/.hermes/config.yaml, then fully quit and reopen Hermes Desktop. CPU context compression With Ollama running, inside granite-compressor/: ollama pull granite3.3:2b ollama create granite3.3-compressor:2b -f ./Modelfile.granite-compressor.cpu Then run these commands inside hermes/: docker compose exec hermes hermes config set auxiliary.compression.provider custom docker compose exec hermes hermes config set auxiliary.compression.model granite3.3-compressor:2b docker compose exec hermes hermes config set auxiliary.compression.base_url 127.0.0.1 docker compose exec hermes hermes config set auxiliary.compression.timeout 300 docker compose restart hermes After a test request, ollama ps should show 100% CPU while Granite is loaded. Bonsai and Granite each have their own 128K context window. See the package README for the API test and the variant that lets Ollama choose CPU/GPU placement. Warning! The compressor has a 128K context limit, including when it summarizes conversations from Claude or GPT. Our Hermes setup is intended for local models, rather than large flagship models, so larger compression inputs still need to fit within that limit and will be handled locally. Next steps I'd like to add local decision tools in the style of TypeSafe's Jev: an open text model such as Laya, plus Qevi-2B for images. Both return structured decisions and probabilities instead of generating text. Bonsai could call either tool for quick decisions and item classification, switching between them depending on the task. If needed, I may lower Bonsai's context to 100K to make room for smaller models. That would free roughly 492 MiB from the main attention cache alone. The total VRAM savings would need to be measured... I'd like to find a compact image generation model that delivers good results with my remaining hardware resources, although I think running it alongside Bonsai is probably impossible with current technology and my hardware limits. I'm also interested in NCM (Next-Concept Modeling), which generates text in parallel, starting with a rough outline and progressively adding detail. Its summarization research already looks promising for context compression. It might also help make larger local models faster and more efficient. This video introduced me to it. Do you have any ideas for improving inference further? Maybe a setting or approach I've missed? I hope this post helps someone, and maybe I’ll learn something new from the replies. Thanks!

The ARMv9 Speed Paradox: Auditing Real-World Code with Gemma 4 on Bare Metal This article is submitted for the DEV Hacktoberfest 2026 Open-Source AI Challenge: Week 3 ("Slow and Steady"), competing in the Best Use of Gemma category. --- Running automated security audits on real-world codebases with frontier LLMs usually comes with two painful tradeoffs: cloud API bills and headaches or stripped-down context windows that miss cross-file vulnerabilities. For Week 3 of Hacktoberfest 2026, we took the "Slow and Steady" ethos literally: what happens when you run Google's Gemma 4 family on bare-metal ARMv9 silicon with a massive 65,536-token context window, evaluating real open-source targets against known ground-truth vulnerabilities? We deployed a headless test runner across Google Cloud ARM64 instances (c4a-standard-8, 8 vCPUs on Neoverse-V2 silicon, 32 GB RAM) and pitted multiple architectures and quantization schemes against each other: 1. unsloth/gemma-4-12b-it-GGUF (Dense 12B across 4 quantization levels: UD-Q2_K_XL, IQ4_XS, UD-Q4_K_XL, and UD-Q6_K_XL) 2. bottlecapai/ThinkingCap-gemma-4-26B-A4B-it-GGUF (Mixture-of-Experts with 26B total parameters and 4B active: Q4_K_M and Q6_K) 3. prism-ml/Ternary-Bonsai-2-27B-gguf (1.58-bit ternary quantization: PTQ1_0 executed via custom PrismML-Eng/llama.cpp kernels) Here is what we discovered about ARMv9 SIMD execution, context scaling, and vulnerability detection precision. --- The Test Targets: Verified Ground Truth Rather than synthetic benchmarks or toy examples, we scanned two real-world Go projects where our team previously discovered and remediated zero-day security flaws: 1. jhaals/yopass checked out at commit 16bc350a (pre-fix commit before the merged patch in PR #3973). - Scanned files: pkg/server/oidc.go, pkg/server/apitoken.go, and pkg/server/middleware.go (646 lines, 22,181 characters). - Ground truth flaw: Missing validation of the email_verified claim in the OIDC userinfo handler, allowing unverified identities to bypass access controls. 2. rs/curlie checked out at commit 5dfcbb17 (pre-fix commit before patches PR #104 and PR #105). - Scanned files: main.go, args/httpie.go, args/parse.go, formatter/json.go, formatter/color.go, and formatter/binaryfilter.go (723 lines, 15,312 characters). - Ground truth flaws: Arbitrary local file read in args/httpie.go via HTTPie-compatible @filename multipart form syntax, and terminal ANSI escape sequence injection in formatter/json.go. --- The Full Benchmark Dataset Across dozens of hours of headless execution on Neoverse-V2 cores, here are the complete measurements: | Model & Quantization | Size (GB) | Prompt Eval | Token Gen | yopass (Time / Triage) | curlie (Time / Triage) | | :--- | :--- | :--- | :--- | :--- | :--- | | Gemma-4-12B UD-Q2_K_XL | 4.34 GB | 8.30 t/s | 8.38 t/s | 4,040 s (0 valid / 0 rejected) | 8,720 s (2 valid / 0 rejected) | | Gemma-4-12B IQ4_XS | 5.94 GB | 10.83 t/s | 11.16 t/s | 9,260 s (1 valid / 3 rejected) | 18,260 s (6 valid / 7 rejected) | | Gemma-4-12B UD-Q4_K_XL | 6.86 GB | 15.12 t/s | 11.08 t/s | 7,375 s (1 valid / 3 rejected) | 12,715 s (4 valid / 6 rejected) | | Gemma-4-12B UD-Q6_K_XL | 9.95 GB | 14.92 t/s | 8.06 t/s | 8,730 s (1 valid / 3 rejected) | 19,739 s (2 valid / 11 rejected) | | ThinkingCap-26B-A4B Q4_K_M | 15.84 GB | 55.24 t/s | 21.78 t/s | 3,170 s (0 valid / 5 rejected) | 6,404 s (2 valid / 12 rejected) | | ThinkingCap-26B-A4B Q6_K | 21.70 GB | 54.37 t/s | 21.04 t/s | 3,213 s (1 valid / 4 rejected) | OOM crash at 2,500 s (32 GB RAM ceiling) | | Ternary-Bonsai-27B PTQ1_0 | 5.54 GB | 6.85 t/s | 3.68 t/s | 22,970 s (1 valid / 4 rejected) | 27,090 s (1 valid / 3 rejected) | | Gemma-4-26B-A4B (Vertex MaaS, Cloud) | Cloud API | ~650 t/s | 55.10 t/s | 62 s (0 valid / 4 rejected) | 90 s (4 valid / 9 rejected) | Bold values indicate best performance among local bare-metal CPU runs. Managed cloud API is included as an external reference baseline. --- Four Engineering Insights from Bare-Metal Execution 1. The ARMv9 Hardware Paradox: 4-bit Beats 2-bit Conventional intuition assumes smaller quants run faster because of reduced memory traffic. On 8 DDR5-backed Neoverse-V2 cores, the opposite occurred: - UD-Q4_K_XL (6.86 GB) achieved 15.12 tokens/second on prompt evaluation—nearly double the throughput of UD-Q2_K_XL (8.30 tokens/second), despite reading 58% more weight data per token! - Neoverse-V2 features dual 128-bit vector pipelines with native ARMv9 i8mm and dotprod instructions. Byte-aligned 4-bit and 6-bit blocks unpack with minimal instruction overhead. By contrast, non-linear 2-bit packing (Q2_K) and variable-rate lookup grids (IQ4_XS) force the CPU into heavy bit-shifting, masking, and table indirection on scalar/integer ALUs. On modern CPU architectures, SIMD unpacking overhead easily dwarfs memory bus contention. 2. The Mixture-of-Experts Supremacy on CPU The sparse ThinkingCap-Gemma-4-26B-A4B architecture routed every token to only 4 billion active parameters out of 26 billion total. On bare CPU, it sustained over 55 tokens/second during prompt ingestion and 21.8 tokens/second during generation. It completed the full repository audits in half the wall-clock time of 12B dense models, while retaining the reasoning breadth of a 26B parameter model. 3. The 1.58-Bit Quantization Floor and Triage Immunity At 1.58 bits per parameter, Ternary-Bonsai-2-27B fits 27 billion parameters into 5.54 GB of RAM. However, during deep 65k context code analysis on CPU: - It generated at 3.68 tokens/second via custom PrismML bit-emulation routines. - More importantly, extreme quantization degraded cross-domain semantic coherence: when analyzing Go source code (oidc.go), it hallucinated C functions (void parse_packet with memcpy) from its pre-training data. - The system immune response: Our multi-round skeptical triage layer immediately caught the hallucination. The verifier grepped the target codebase, confirmed no such C construct existed, and rejected the finding with a confidence of 0% ([III→I]). A disciplined multi-round pipeline successfully neutralized model hallucinations even under severe quantization breakdown. 4. 65k Context Sizing on 32 GB RAM When deploying a 65,536-token context window with 8-bit KV caching (-ctk q8_0 -ctv q8_0), the KV cache expands by 8 to 10 GB under deep reasoning chains: - Models up to 16 GB (12B dense and 26B-A4B-Q4_K_M) operated with comfortable safety margins on a 32 GB RAM instance. - The 21.70 GB 26B-A4B-Q6_K model operated smoothly during single-turn evaluations, but hit the Linux kernel OOM limit during recursive multi-turn triage on larger files. For 65k contexts on 26B+ models, 48 GB to 64 GB of RAM is the recommended hardware baseline. --- Taming the 65,536 Context Window in llama-server Feeding entire repository components into local LLMs requires specific inference server tuning: nice -n 10 llama-server \ -m ./models/ThinkingCap-gemma-4-26B-A4B-it-Q4_K_M.gguf \ -c 65536 \ -n 4096 \ -np 1 \ -fa on \ -ctk q8_0 -ctv q8_0 \ -t 8 \ --reasoning-format deepseek \ --reasoning-budget 1536 \ --host 127.0.0.1 \ --port 8080 Three configuration flags proved essential: - -np 1: By default, llama-server divides -c 65536 across multiple concurrent slots (e.g. 4 slots of 16k tokens). Passing -np 1 guarantees the full 64k window belongs to the security pipeline. - -fa on -ctk q8_0 -ctv q8_0: Flash Attention combined with 8-bit quantized KV cache reduced context memory overhead by 48%, keeping RAM usage predictable even past 45,000 prompt tokens. - --reasoning-format deepseek --reasoning-budget 1536: Gemma 4 outputs structured thought tokens (<|thought|>). Separating thought tokens from the final JSON payload prevented grammar parsing errors when enforcing strict JSON schemas. --- Two Pipeline Fixes for Local 65k Models Transitioning our scanner pipeline (AISLE nano-analyzer) to local 65k inference revealed two practical bugs: 1. Greedy Markdown Code Block Parsing The original parser used a greedy regex to locate JSON payloads: # Buggy: matches the first code fence, which may be target code inside thought reasoning match = re.search(r'```(?:json)?\s*\n?(.*?)```', text, re.DOTALL) When Gemma 4 analyzed code, its internal reasoning frequently quoted snippets of Go source wrapped in ``` `go ``` fences. The parser matched the first snippet, failed JSON deserialization, and dropped the audit finding. We resolved this by iterating backward through all fenced blocks to find the true payload: # Fixed: inspect blocks from bottom to top to identify the valid JSON payload for block in reversed(re.findall(r'```(?:json)?\s*\n?(.*?)```', text, re.DOTALL)): try: return json.loads(block.strip()) except json.JSONDecodeError: continue 2. Runaway Generation Loops Without an explicit max_tokens cap in client payloads and server flags (-n 4096), repetition loops after exhausting the reasoning budget can cause the model to generate tokens until filling the 65,536-token ceiling. Enforcing explicit caps prevented multi-hour hangs on edge-case files. --- Compute Economics: Bare-Metal CPU vs. Cloud APIs Benchmarking deep context windows often raises concerns about cloud infrastructure costs. For this study on Google Cloud Platform, our hardware setup consisted of c4a-standard-8 instances (8 vCPUs on ARM Neoverse-V2 silicon, 32 GB RAM) billed at $0.282 / hour with standard hyperdisk storage. The total compute cost across all experimental worker instances: - gemma-arm-26b (ThinkingCap-26B-A4B MoE on yopass and curlie across Q4_K_M and Q6_K): ~5.5 hours runtime = $1.55 - gemma-arm-c4a (Gemma-4-12B dense across four quantization levels): ~13.5 hours runtime = $3.80 - gemma-arm-bonsai (Ternary-Bonsai-27B 1.58-bit execution): ~15.0 hours runtime = $4.23 Running the full local benchmark across all seven model configurations cost under $10.00 in total GCP compute expenses. For comparison, running the same audit against Google Cloud's managed Vertex AI Model Garden (google/gemma-4-26b-a4b-it-maas at $0.15/M input and $0.60/M output) completed both repository audits in 2.5 minutes with a combined API cost of $0.06. By contrast, running the same 65k multi-round skeptical triage through commercial frontier closed-source APIs regularly reaches $25 to $60 per repository. For teams working within restricted networks or private VPCs where source code cannot leave the boundary, running sparse MoE models on self-hosted ARMv9 CPU hardware offers high-depth context inspection for pennies per run. --- Key Takeaways for Local Security Auditing 1. Do not default to 2-bit quants on modern CPUs: On ARMv9 Neoverse cores with DDR5 memory, integer SIMD execution makes standard 4-bit quants faster and substantially more capable than 2-bit variants. 2. MoE architectures excel on CPU: Sparse routing provided the best throughput-to-parameter ratio, sustaining over 21 tokens/second generation and 55 tokens/second prompt ingestion. 3. Multi-round skeptical triage is mandatory: Candidate scans produce false alarms; pairing discovery with an automated skeptical review round filters out benign patterns and neutralizes model hallucinations. The test runner, inference configurations, and reproduction instructions are available in the open-source repository at Huge/nano-analyzer. For the interactive web report and case studies, visit BudgetScan Stories.

Ternary Bonsai 2 Family: 2B, 4B, & 9B based on Qwen 3.5 Going to try these out to see if they have the same looping behaviors that other Bonsai models have had. Still requires their fork of llama.cpp (branch prism) so dont expect it to work with vanilla llama.cpp. Edit: You can use with regular llama.cpp! Will see if there is some way to support this for AnythingLLM Mobile viaLLama.rn fork since if anything this will hopefully beat out regular Qwen 3.5 1.7B or 0.8B. Can test on iOS today withLocallyAI on latest version. Feel like the way these models are made (QAT?) kind of lend to a high benchmarked model that is quite different when deployed. Past experiences are certainly better with memory for the parameter size but let's see how these go. Says dFlash and MTP supported as well + MLX support to juice some more TPS

weights (GGUF + MLX, all three sizes): huggingface.co setup + prebuilt llama.cpp fork: PrismML-Eng/Bonsai-demo

🌱 Explore Bonsai 2: 📰 Blog: prismml.com 🤗 Hugging Face (models): huggingface.co 💻 GitHub (demos): PrismML-Eng/Bonsai-demo

okay, the whole thing got fairly easy to set up now github.com/PrismML-Eng/llama.cpp/releases/tag/pri… + huggingface.co 35 t/s on my RTX 3060 12GB see also huggingface.co which fixes overthinking

โมเดล 27B ย่อเหลือ 7.89 GB ชนะตัวเต็ม 54 GB ได้จริงไหม? เจาะ Saluki 27B โมเดล 27B ย่อเหลือ 7.89 GB ชนะตัวเต็ม 54 GB ได้จริงไหม? เจาะ Saluki 27B โดย Nokka (นก-กา) | 11 ตุลาคม 2026 บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka ถ้าคุณเคยลองย่อโมเดลลงเหลือ 2 บิตแล้วเจอปัญหาเดิมทุกครั้ง นี่คือข่าวที่คุณน่าจะอยากอ่านให้จบ ทีม Underdog จาก Conway Research ปล่อยไฟล์ขนาด 7.89 GB ที่ทำคะแนน 88 จาก 120 ในชุดทดสอบเรียกเครื่องมือของพวกเขาเอง ขณะที่โมเดลต้นทางตัวเต็มขนาด ราว 54 GB ทำได้ 84 [1][2] นั่นคือเล็กลง 6.84 เท่า แต่คะแนนกลับสูงกว่า 4 งาน ตัวเลขนี้จริง แต่คำถามที่ควรถามไม่ได้อยู่ตรงนั้น สรุปสั้น Saluki 27B เป็นการย่อ Qwen3.8-27B ด้วยเทคนิค 2 บิตแบบผสม (IQ2 mix) จนเหลือ 7.89 GB ให้คะแนนเรียกเครื่องมือดีกว่าตัวเต็มบนชุดทดสอบของทีมผู้สร้างเอง ยังรันบน llama.cpp มาตรฐาน [10] ไม่ต้องคอมไพล์ fork และใช้สัญญาอนุญาต Apache 2.0 แต่มีสามอย่างที่ต้องรู้พร้อมกัน คือ ทีมผู้สร้างมีบิลด์ของตัวเองที่ทำได้ดีกว่า Saluki อีกตัวหนึ่ง, มีคู่แข่งที่ชนะ Saluki ในงานเรียกเครื่องมือพร้อมกันหลายคำสั่งแบบขาดลอย และคะแนนคณิตศาสตร์ระดับแข่งขันถอยลงราว 15 ถึง 18% Saluki 27B คืออะไร โมเดลต้นทางคือ Qwen3.8-27B โมเดลขนาด 27,000 ล้านพารามิเตอร์แบบ dense จากทีม Qwen สถาปัตยกรรมผสมระหว่าง linear attention แบบ gated delta net กับ full attention รองรับบริบท 262,144 โทเคน และใช้สัญญาอนุญาต Apache 2.0 [3] Saluki ไม่ได้เทรนใหม่ ทีม Underdog รับช่วงต่อจาก ISTA-DASLab ที่ปล่อย GGUF แบบ 2 บิตด้วยวิธี GSQ และ RCO มาก่อน แล้วทำบิลด์ 2 บิตแบบผสมของตัวเองทับลงไป โดยเลือกข้อมูลคาลิเบรตที่รักษาพฤติกรรมการเรียกเครื่องมือไว้ [1][11] จุดขายที่ทีมผู้สร้างเน้นคือ ไฟล์เดียว 7.89 GB รันบน llama.cpp มาตรฐาน ไม่ต้องมีบิลด์พิเศษ ไม่ต้องมี runtime แยก เปิดใช้ผ่าน OpenAI chat API บนพอร์ต 8080 ได้เลย [1][2] สื่อสายเทคบางเจ้ารายงานว่าไฟล์นี้รันได้ใน Ollama, LM Studio และ vLLM ด้วย [11] ขณะที่หน้าของเจ้าของระบุถึง llama.cpp มาตรฐานเป็นหลัก [1][2] ผมจึงรายงานตามที่ทั้งสองฝ่ายเขียน ยังไม่สรุปว่าฝ่ายใดครบกว่า ไฟล์โมเดลในรุ่น 1.0 มีระดับเดียวคือ Underdog-Saluki-27B-1.0-IQ2-mix.gguf ขนาด 7.89 GB (ยังมีไฟล์ vision add-on แยกอีกสองไฟล์สำหรับงานภาพ) มีโหมดคิดในหัวเปิดไว้เป็นค่าตั้งต้นและปิดได้ต่อคำขอ [1] วิธีรันแบบเร็ว huggingface-cli download ConwayResearch/Underdog-Saluki-27B-1.0 \ Underdog-Saluki-27B-1.0-IQ2-mix.gguf --local-dir . llama-server -m Underdog-Saluki-27B-1.0-IQ2-mix.gguf \ --jinja -ngl 99 -fa on -c 32768 ธง --jinja เปิดใช้เทมเพลตแชตของ Qwen3.8 ซึ่งจัดการทั้งการเรียกเครื่องมือและโหมดคิดในหัว ส่วนการตั้งค่าที่แนะนำคือ temperature 0.6, top_p 0.95, top_k 20 สำหรับงานทั่วไป และ temperature 0 สำหรับงานเรียกเครื่องมือที่ต้องการความเร็ว [1] ตัวเลข 88 กับ 84 หมายถึงอะไร ชุดทดสอบที่ทีมใช้ชื่อ Underdog Bench เป็นงาน 120 ชิ้นดึงจาก Berkeley Function Calling Leaderboard รุ่นที่ 4 แบ่งเป็นห้าประเภท ประเภทละ 24 งาน และ แช่แข็งชุดงานไว้ตั้งแต่วันที่ 27 กันยายน 2026 ก่อนจะเริ่มทดสอบโมเดลใด ๆ [1][2][8] ผลที่ออกมาวางเรียงได้แบบนี้ - บิลด์หลักของทีม Underdog (7.9 GB) ทำได้ 91 จาก 120 - Saluki (7.89 GB) ทำได้ 88 จาก 120 - Mia 2-bit (9.1 GB) ทำได้ 85 - Qwen3.8-27B ตัวเต็ม (ราว 54 GB) ทำได้ 84 - ISTA 2-bit (8.4 GB) ทำได้ 76 - Ternary Bonsai 2 (5.95 GB) ทำได้ 70 ทุกตัวรันใน runtime ของตัวเอง ซึ่งเป็นกรณีที่ดีที่สุดของแต่ละไฟล์ ทีมผู้สร้างระบุว่า Saluki และบิลด์หลักของเขาทำได้ดีกว่าตัวเต็ม 76 ถึง 77 งานจาก 84 งานที่ตัวเต็มทำได้ [2] จุดที่น่าสนใจกว่าคะแนนรวมคือ การเลือกเครื่องมือให้ถูกตัว ในห้าประเภทงานนั้น Saluki ทำได้ 47 จาก 48 ในสองประเภทแรก ซึ่งเป็นงานเลือกฟังก์ชันเดียวที่ถูกต้อง กับเลือกฟังก์ชันที่ถูกจากหลายตัวเลือก เทียบกับ Mia ที่ทำได้ 31 จาก 48 [2] สามข้อที่ทีมผู้สร้างยอมรับเอง ส่วนนี้คือส่วนที่ทำให้ผมเชื่อตัวเลขชุดนี้มากกว่าคะแนน benchmark ทั่วไป เพราะทีมเขียนไว้เองบนหน้าของพวกเขา ข้อที่หนึ่ง: บิลด์หลักของตัวเองชนะ Saluki บนหน้าทางการระบุชัดว่าบิลด์หลักของทีมทำได้ 91 ส่วน Saluki ทำได้ 88 ทั้งที่ขนาดใกล้กันมาก คือ 7.9 กับ 7.89 GB และอธิบายเหตุผลที่ปล่อย Saluki ว่าเป็นเพราะบิลด์หลัก เล่นเว็บได้แย่กว่า โดยตอบคำถามจากเว็บจริงได้ 48 จาก 150 ข้อ หรือ 32% ขณะที่ Saluki ตอบได้ 60 จาก 150 ข้อ หรือ 40% [2] ข้อที่สอง: คู่แข่งชนะในงานเรียกเครื่องมือพร้อมกัน งานที่ต้องเรียกหลายเครื่องมือในคำตอบเดียว Saluki ทำได้ 42 จาก 100 เมื่อตรวจแบบเข้มงวด Mia ทำได้ 69 จาก 100 ทีมเขียนไว้ตรง ๆ ว่า Mia เป็นผู้นำในหมวดนี้อย่างชัดเจน และบอกเหตุผลที่ยังเลือกปล่อย Saluki ว่าขนาดไฟล์เล็กกว่า คือ 7.89 GB เทียบกับ 9.1 GB [2] ตัวเลขนี้เปลี่ยนเมื่อใช้ตัวตรวจที่ผ่อนปรนความผิดพลาดเรื่องรูปแบบ คือ Saluki ขยับจาก 42 เป็น 55 จาก 100 ขณะที่ Mia ขยับแค่จาก 69 เป็น 70 [2] ข้อที่สาม: ทีมไม่เคลมว่าเก่งกว่าตัวเต็ม ประโยคที่ผมคิดว่าสำคัญที่สุดในทั้งหน้าเผยแพร่คือ ทีมระบุว่า "เราไม่ได้อ้างว่ามันฉลาดกว่าโมเดลต้นฉบับ งาน 120 ชิ้นเป็นการทดสอบที่พอประมาณ และส่วนหนึ่งของความต่างนั้นน่าจะมาจากความแปรปรวนระหว่างรอบรัน" [2] ในบทความเชิงเทคนิค ทีมยังระบุด้วยว่าคะแนนสาธารณะของโมเดลต้นฉบับ มาจาก harness คนละตัวกับที่ทีมใช้ และตัวเลข IFEval ที่ทีมรายงานนั้นนับหกพรอมป์ที่ทำไม่เสร็จเป็นความล้มเหลว ซึ่งเป็นมุมที่ระวังตัวกว่า [2] ในมุมมองของผม การที่ทีมเขียนแบบนี้ทำให้ตัวเลข 88 กับ 84 มีน้ำหนักกว่าคะแนนที่ไม่มีคำกำกับเลย จุดที่ถอยลง การย่อลง 6.84 เท่าไม่ได้ฟรี ทีมผู้สร้างระบุข้อจำกัดไว้เองครบ - คณิตศาสตร์ระดับแข่งขัน ถอยลงชัดเจน คะแนน AIME 2025 อยู่ที่ 79.2 เทียบกับ 96.7 ของตัวเต็ม หรือราว 81.9% ส่วน AIME 2026 อยู่ที่ 80.0 เทียบกับ 94.6 หรือราว 84.6% ทีมสรุปว่าเก็บคะแนนคณิตศาสตร์ไว้ได้ 82 ถึง 85% [1] - งานปริศนาระดับตัวอักษร อย่างคำกลับหัว กฎสระ และการเรียงตามตัวอักษร เป็นประเภทที่อ่อนที่สุด [2] - งานเรียกเครื่องมือพร้อมกัน ตัวตรวจแบบเข้มงวดอ่านไม่ออก 23 งานจาก 100 คำตอบ ทีมระบุว่าส่วนใหญ่เป็นเรื่องรูปแบบ [1][2] - งานเขียนโค้ด Saluki แก้ปัญหาจาก SWE-bench Verified ได้ 30 จาก 50 ข้อ เทียบกับ 33 ของตัวเต็ม หรือเก็บไว้ 27 จาก 33 ข้อที่ตัวเต็มแก้ได้ [2] - โหมดคิดในหัว เมื่อเปิดอยู่ โมเดลมักใช้เวลาไตร่ตรองนานก่อนตอบ งานที่ต้องการความเร็วต้องปิด [1] - มาเป็นข้อความล้วน ไฟล์หลักรับข้อความเท่านั้น ต้องโหลดไฟล์ vision แยกอีก 629 ถึง 928 MB [1] ตัวเลข MBPP+ อยู่ที่ 78.0 เทียบกับ 83.9 หรือราว 93% และ MuSR อยู่ที่ 67.5 เทียบกับ 79.6 หรือราว 84.8% ส่วน IFEval อยู่ที่ 93.5 เทียบกับ 91.5 ซึ่งสูงกว่า [1] จุดต่างจริงคือ runtime ไม่ใช่คะแนน ถ้าผมจะเลือกตัวเลขเดียวมาอธิบายว่าทำไม Saluki ถึงน่าสนใจ ผมจะไม่เลือก 88 หรือ 84 ผมจะเลือกคำว่า llama.cpp มาตรฐาน คู่แข่งทั้งสามตัวมีเงื่อนไขเรื่อง runtime ต่างกันชัดเจน - Mia 2-bit อยู่ในรูปแบบ EXL3 ของ ExLlamaV3 จึงต้องใช้ exllamav3 รัน และ โหลดใน llama.cpp ไม่ได้เลย [2][6] - Ternary Bonsai 2 ของ PrismML น้ำหนักแบบ ternary 1.72 บิตต่อพารามิเตอร์ ต้องใช้ llama.cpp fork ของ PrismML เท่านั้น เอกสารระบุตรง ๆ ว่า llama.cpp มาตรฐานจะปฏิเสธไฟล์ PQ2_0 และ PTQ1_0 ว่าเป็นชนิดที่ไม่รู้จัก และถ้าโหลด Q2_0 จะโหลดผ่านโดยไม่เตือนแล้วให้ผลเป็นขยะ เพราะไม่มี runtime สำหรับการหมุน Hadamard [5][9] - Saluki โหลดใน llama.cpp มาตรฐานและแอปที่สร้างบนมัน [1][2] ราคาที่จ่ายสำหรับความสะดวกนี้คือขนาด Bonsai เล็กกว่า คือ 5.95 GB เทียบกับ 7.89 GB หรือต่างกัน 1.33 เท่า และ Bonsai อ้างว่าเก็บความฉลาดไว้ 98.2% ของรุ่น FP16 จาก 14 benchmark เฉลี่ย 84.78 เทียบกับ IQ2_XXS แบบธรรมดาที่ 72.59 [5] แต่บน Underdog Bench ของทีมผู้สร้างเอง คู่แข่งอย่าง Bonsai ทำได้ 70 จาก 120 เทียบกับ Saluki ที่ 88 ซึ่งเป็นช่องห่าง 18 งาน [2] ตัวเลขสองชุดนี้มาจากคนละชุดทดสอบและคนละ harness การเอามาวางเทียบกันตรง ๆ จึงไม่ยุติธรรมกับทั้งสองฝ่าย ตัวเลขที่ควรรู้ก่อนโหลด เมื่อตรวจจากหน้าของเจ้าของโดยตรง ณ วันที่ 11 ตุลาคม 2026 (เวลาไทย) ข้อมูลอยู่แบบนี้ - Saluki ดาวน์โหลด 59,191 ครั้งในเดือนล่าสุด กดหัวใจ 258 ครั้ง สร้างเมื่อ 8 ตุลาคม 2026 แก้ไขล่าสุด 10 ตุลาคม 2026 [1][7] - ISTA GSQ-RCO ซึ่งเป็นรากของ Saluki ดาวน์โหลด 1,484,655 ครั้ง กดหัวใจ 2,113 ครั้ง [4][7] - Ternary Bonsai 2 ดาวน์โหลด 4,457,576 ครั้ง กดหัวใจ 2,590 ครั้ง สร้างเมื่อ 16 กันยายน 2026 [5][7] - Mia 2.0bpw ซึ่งเป็นตัวที่ทีม Underdog ใช้เทียบ ดาวน์โหลด 719 ครั้ง กดหัวใจ 0 ครั้ง [6][7] ตัวเลขนี้บอกความนิยม ไม่ได้บอกความสามารถ และทุกตัวขยับได้ทุกวัน ตอนที่ AlphaSignal เขียนข่าวเมื่อ 10 ตุลาคม การ์ดของ Saluki ระบุว่ามีดาวน์โหลดมากกว่า 15,000 ครั้ง [11] แต่เมื่อผมดึง API ในอีกหนึ่งวันต่อมา ตัวเลขกลับเป็น 59,191 ครั้งในรอบ 30 วัน [7] ความต่างขนาดนี้บอกสองเรื่องพร้อมกัน คือความสนใจที่พุ่งขึ้นเร็ว และความจริงที่ว่าตัวเลขบนหัวการ์ดเป็นค่าที่ไม่นิ่ง มุมของผม Saluki น่าสนใจตรงที่มันไม่ได้ชนะเพราะตัวเลข 4 งาน แต่อยู่ที่ทีมผู้สร้าง เลือกวัดให้ตรงกับงานจริง งาน 120 ชิ้นที่แช่แข็งไว้ก่อนทดสอบ แบ่งเป็นห้าประเภทเท่ากัน และรันทุกตัวใน runtime ของตัวเอง คือวิธีที่ทำให้ตัวเลขเทียบกันได้สมเหตุสมผลที่สุดเท่าที่จะทำได้ในสถานการณ์ที่ทุกไฟล์มีข้อจำกัดต่างกัน และเหตุผลที่ผมยังไม่รีบโหลดมาใช้ คือคำถามเดียวกับที่ทีมผู้สร้างถามตัวเอง นั่นคือ งาน 120 ชิ้นมันพอจะบอกอะไรได้จริงแค่ไหน คำตอบอยู่ในประโยคของพวกเขาเอง ส่วนหนึ่งของความต่างน่าจะมาจากความแปรปรวนระหว่างรอบรัน ซึ่งหมายความว่าช่องห่าง 4 งานระหว่าง Saluki กับตัวเต็มอาจไม่มีนัยสำคัญทางสถิติเลย ในมุมมองของผม วิธีอ่านที่ปลอดภัยกว่าคือดูที่ 76 จาก 84 ซึ่งเป็นจำนวนงานที่ Saluki แก้ได้จากงานที่ตัวเต็มแก้ได้ ไม่ใช่ดูที่ 88 กับ 84 เพราะตัวเลขหลังบอกว่าใครนำ แต่ตัวเลขแรกบอกว่ายังเหลืออะไรให้เสียไป ข้อควรระวัง - ผมไม่ได้ดาวน์โหลดหรือรันโมเดลนี้เอง ข้อมูลทั้งหมดมาจากหน้าของเจ้าของทั้งสองหน้า หน้าของคู่แข่ง และ HF API ณ วันที่ 11 ตุลาคม 2026 (เวลาไทย) - คะแนนทั้งหมดเป็นผลการทดสอบของทีมผู้สร้างเอง ไม่มีบุคคลที่สามวัดซ้ำ และทีมเป็นฝ่ายที่ปล่อยโมเดล จึงมีส่วนได้ส่วนเสียโดยตรง - หน้าสองหน้าของเจ้าของขัดกันเรื่องภาพ หน้าการ์ดโมเดลระบุว่ามีไฟล์ vision add-on ขนาด 629 หรือ 928 MB ให้โหลด [1] แต่หน้าทางการของทีมระบุว่า "รุ่นนี้ไม่รับภาพ" [2] ผมรายงานตามที่ทั้งสองหน้าเขียน ยังไม่สรุปว่าอันไหนถูก - ผมเข้าถึงเธรดชุมชนไม่ได้ Reddit บล็อกการเข้าถึงจาก IP นี้ และเธรดบน Hacker News ยังไม่มีคอมเมนต์ ณ วันที่ตรวจ จึงยังไม่มีเสียงผู้ใช้จริงมาถ่วงดุลตัวเลขของผู้สร้าง - ตัวเลขดาวน์โหลดและหัวใจเป็นค่าที่ขยับได้ทุกวัน ใช้เป็นสัญญาณความสนใจ ไม่ใช่ตัวชี้วัดคุณภาพ - ขนาดไฟล์ไม่เท่ากับแรมที่ต้องใช้ ต้องบวก KV cache ตามความยาวบริบทที่ตั้งไว้ และการ์ดที่บอกว่าไฟล์นี้รันได้ยังไม่มีข้อมูลจากผู้ใช้จริง - ตัวเลข IFEval กับ AIME ในตารางเทียบกันข้าม harness ตัวเลขสาธารณะของตัวเต็มไม่ได้ระบุว่าเป็นแบบเข้มหรือผ่อน และบางตัวมาจากการ์ดของคู่แข่ง [2] สรุป Saluki 27B เป็นตัวอย่างของงานย่อโมเดลที่ทำการบ้านถูกจุด คือเลือกวัดงานที่ตรงกับที่โมเดลถูกนำไปใช้จริง และรายงานผลลัพธ์ที่แย่ของตัวเองไว้ด้วย ไม่ใช่เลือกแต่ตัวเลขที่ชนะ คำถามที่คุณควรถามก่อนโหลดไม่ใช่ "มันชนะตัวเต็มจริงไหม" แต่คือ "งานของคุณเป็นการเลือกเครื่องมือให้ถูกตัว หรืองานที่ต้องใช้คณิตศาสตร์และการคิดหลายชั้น" เพราะสองอย่างนี้ได้คำตอบคนละแบบจากตัวเลขชุดเดียวกัน ถ้าคุณรัน llama.cpp มาตรฐานอยู่แล้วและอยากได้โมเดลที่เรียกเครื่องมือได้แม่นบนเครื่อง 16 GB ลองโหลดมาเทียบกับตัวที่คุณใช้อยู่ดู แล้วเล่าให้ฟังว่าผลออกมาอย่างไร REF [1] Underdog / Conway Research, "Underdog Saluki 27B 1.0", Hugging Face, 8 ตุลาคม 2026 (แก้ไขล่าสุด 10 ตุลาคม 2026). huggingface.co [2] The Underdog team, "Meet Underdog Saluki 27B", Underdog, 7 ตุลาคม 2026. underdog.ai [3] Qwen team, "Qwen3.8-27B", Hugging Face, 5 สิงหาคม 2026 (แก้ไขล่าสุด 14 สิงหาคม 2026). huggingface.co [4] ISTA-DASLab, "Qwen3.8-27B · GSQ-RCO GGUFs", Hugging Face, 28 สิงหาคม 2026. huggingface.co [5] Prism ML, "Bonsai 2 27B (GGUF)", Hugging Face, 16 กันยายน 2026. huggingface.co [6] Mia-AiLab, "Qwen3.8-27B · EXL3 · 2.0bpw", Hugging Face, 1 กันยายน 2026. huggingface.co [7] Hugging Face Models API (ตัวเลขดาวน์โหลดและหัวใจ), ตรวจเมื่อ 11 ตุลาคม 2026 (เวลาไทย). huggingface.co [8] Berkeley Function Calling Leaderboard (BFCL), Gorilla Project, UC Berkeley, เข้าถึงเมื่อ 11 ตุลาคม 2026. gorilla.cs.berkeley.edu [9] PrismML-Eng, "llama.cpp fork สำหรับ ternary low-bit kernels", GitHub, เข้าถึงเมื่อ 11 ตุลาคม 2026. PrismML-Eng/llama.cpp [10] ggml-org, "llama.cpp", GitHub, เข้าถึงเมื่อ 11 ตุลาคม 2026. ggml-org/llama.cpp [11] AlphaSignal Newsroom, "Conway Research Squeezes Saluki's 27B Model Into 8 GB and Beats the Original", AlphaSignal, 10 ตุลาคม 2026. alphasignal.ai --- บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash) ผ่าน Hermes Agent จาก Nous Research ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ ตัวเลขทุกตัวอ้างอิงจากหน้าของเจ้าของโมเดลและ API ที่ระบุไว้ในรายการอ้างอิง