Live data from Hacker News

llama.cpp

llama.app

151–160 of 177 posts

Re: llama.cpp

#151
post #23

Earlier quoted context omitted.

You're not wrong about the appearance of sketchiness of that, but.... dude, come on. "It's not hard" is only true because you already know how to do it.

GP is saying "it's not hard", yet you seem to be hearing "you should already know how to do this without ever looking it up". Those aren't the same assertions. It's not a sensible assumption that a process must necessarily be difficult or complex just because you don't already know how to do it. There are an unenumerable number of tasks each of us don't know how to do and have never done before which are not difficul…

Yes, and that's exactly why the curl|sh exists; you don't need to know the weird esoterica of a 26 year old piece of software. Accessibility matters.

Re: llama.cpp

#152

If I said, “I want a setup that is usable for an agentic coding workflow, and it MUST be local”, what’s the smallest/cheapest option right now? It’s _technically_ possible to get agents running on all kinds of setups but there seems to be an (undefined) floor for useful setups. A lot of the stories people have about getting setups running on relatively low end hardware turn out to have huge compromises or run into is…

straightforward solution is probably Qwen3.6-27B-Q4 running on a used RTX 3090. price on those is unfortunately high, in fact so high that getting a new Radeon AI PRO R9700 might be a better deal

a solid step up from there is anything that can run Deepseek V4 Flash but the hardware ask there is a bit higher

Re: llama.cpp

#153

If I said, “I want a setup that is usable for an agentic coding workflow, and it MUST be local”, what’s the smallest/cheapest option right now? It’s _technically_ possible to get agents running on all kinds of setups but there seems to be an (undefined) floor for useful setups. A lot of the stories people have about getting setups running on relatively low end hardware turn out to have huge compromises or run into is…

I actually have been exploring this very thing!

I think the best option right now, since Apple has raised prices and Mac minis are basically impossible to get your hands on, is to build your own micro-itx machine. I actually built a mini-itx machine, but it does restrict your options a bit.

The Arc series Intel GPUs are what I think make this possible. I built a machine with an Arc b50 - it runs Gemma 26b a4b qat at around 30tok/s with their MTP head and prompt processing sits at around 500 tok/s. The really beautiful thing about this setup is the entire energy envelope of this machine sits at 120w at full load - when idle, it's at 40w and i've done some work in ubuntu to basically intelligently hibernate, which drops it to 0 watts when not in use. You can use a raspberry pi and Wake on Lan to wake the machine up for a overall draw of around 5 watts when not in use.

All in all this machine cost me 1.4k to build - but if you used micro-itx instead of mini-itx parts you could do it for under 1k - it has just 16gb of ddr5 but you don't really need more if you use models that can fit in vram.

I think it's pretty incredible that you can run an actually useful coding agent on a machine with a power envelope that is less than an incandescent light bulb. If you go up to micro-itx you can do even large cards like an intel b60 with 24gb or a b70 with 32gb and run even more powerful models. For all of these intel GPU's you'll want to compile the latest llama.cpp version with SYCL support - they are getting speedups every day, so worth staying on the edge.

Re: llama.cpp

#154

Earlier quoted context omitted.

I think it is due to the new website? it now looks like every other vibe coded site,the only upside is that is looks more saleable for people unfamiliar with it, e.g., explaining OSPO,IT the stack you are using. they should also add a pricing page for eenterprise where they promise 99.9% uptime for local models*.

Wow it’s aggressively vibe coded. Nothing inherently wrong with that, but it looks a bit amateurish which is funny. I’m still waiting on 98.css to become the standard for vibe coded sites. You don’t have to read docs anyway if you’re just using LLMs! All you have to do is say “use 98.css” and you have a 10/10 site https://jdan.github.io/98.css/

Using 98.css would still leave you with the AI slop text wording.

The core problem is that some people don't even seem to notice / care.

Re: llama.cpp

#155

Earlier quoted context omitted.

VERY

Haha ok, like click & run sort of levels? They do package builds on their github releases depending on your architecture (CUDA or not etc.) so it should be close to "very lazy" levels of ease. I find it useful, but the models I run are pretty rubbish due to my lack of RAM, which is a pity.

The whole AI "industry" needs to take a course in digital marketing.

Then spend about 5-10 years minimum building web apps to get an idea how releasing a build and distribution works.

Very unimpressed by how everything in "AI" is brought to market.

It's like Apple Watch fanboys but with Linux style evangelism. Nobody wants that and it doesn't make us think you are "smart" and we're "dumb" if your tech is not easy to install and your docs are not easy to follow.

I use Ollama (CLI and their npm as a dev) + HF because it just works.

Re: llama.cpp

#156

Earlier quoted context omitted.

I wish you people would go away. Want people to use yours? Make it better

llama.cpp is better and it's what everyone switches to after dipping their toes in with ollama, I don't get your point

If it's so good then why is Ollama way faster and 4x as popular as llama.cpp lol

Beating you at your own game

If Ollama is so bad then why did llama.cpp had to rip off their entire site, branding, even down to their install method

Re: llama.cpp

#157

Earlier quoted context omitted.

Just run /goal to optimise it and you should be good in less than an hour. Also best to use models that support speculative decoding.

Optimize llama.cpp? Hmm. WRT speculative decode, basically zero finetunes keep it. I'm testing with some ridiculous abliterated amalgamation so spec decode has been gone for most of its ancestry. Fable recommended n-gram speculation so I'm working on that now.

Optimize startup params for llama-server for your hardware (not llama.cpp itself), on my 2x 4090 I got ~20% speedup after maybe 40 mins.

ps. ngram didn't work for me very well, but dedicated speculative model works very well

ps. 2. in my case I'm just maintaining Makefile that does everything from update/upgrade (git pull/recompile) to starting server with different models, stuff like:

    # over baseline at temp 0.6 (95 vs 45 tok/s), ~4x over naive layer-split baseline.
    Qwen3.6-27B-MTP-UD-Q8_K_XL:
      ./llama.cpp/llama-server \
        -hf unsloth/Qwen3.6-27B-MTP-GGUF:UD-Q8_K_XL \
        --no-mmproj \
        --parallel 1 \
        --kv-unified \
        --flash-attn on \
        --fit off \
        --split-mode tensor \
        -ngl 99 \
        --cache-type-k q8_0 \
        --cache-type-v q8_0 \
        --host 0.0.0.0 \
        --tools all \
        --jinja \
        --ctx-size 262144 \
        --spec-type draft-mtp \
        --spec-draft-n-max 6 \
        --temp 0.6 \
        --top-p 0.95 \
        --top-k 20 \
        --min-p 0.0 \
        --repeat-penalty 1.0 \
        --presence-penalty 1.1 \
        --threads 8 \
        --reasoning-budget 2048 \
        --reasoning on \
        --chat-template-kwargs '{"preserve_thinking": true}' \
        --reasoning-budget-message "reasoning budget consumed, time to answer now"

    ...

    Qwen: Qwen3.6
    Qwen3.6: Qwen3.6-27B
    Qwen3.6-35B-A3B: Qwen3.6-35B-A3B-MTP
    Qwen3.6-35B-A3B-MTP: Qwen3.6-35B-A3B-MTP-UD-Q8_K_XL
    Qwen3.6-27B: Qwen3.6-27B-MTP
    Qwen3.6-27B-MTP: Qwen3.6-27B-MTP-UD-Q8_K_XL

Re: llama.cpp

#158
post #24

llama.cpp works pretty well for me on the Framework 13 laptop, but the current era of "move fast, break things, rarely fix" (sorry, that's how it feels), bites here quite a bit. Two examples: - https://github.com/ggml-org/llama.cpp/pull/25863 Someone's few lines change broke the native (ROCm) support for the AMD GPU inside Framework (and other integrated systems), and any rollback or proper fix is pending for almost…

For updated/validated updates, Donato Capitella maintains independent Strix Halo "toolboxes": https://strix-halo-toolboxes.com/

A team from AMD maintains Lemonade, another all-in-one setp with convenient installers for setting everything up: https://lemonade-server.ai/

These are probably better than running against llama.cpp ROCm directly as there are frequent/constant regressions on the main branch, especially for gfx1151 (Strix Halo), but RDNA in general.

There are number of AMD-focused llama.cpp forks (nathanw1014, charlie12345, ciru-ai, justinappler, etc) - as well as a few alternatives like hipfire or my hipEngine. While ROCm has gotten a lot better, one of the things I've found after writing an inference engine that has completely custom tuned/fused C++/HIP kernels, is that while it's been pretty straightforward to match/beat llama.cpp ROCm performance, that Vulkan RADV has been a lot harder since RDNA3 support for ROCm has a few issues that make it underperform ACO on some common operations on both gfx1100 and gfx1151 (see: https://github.com/ROCm/ROCm/issues/6409 )

In general, for anyone just looking to run LLM models on an AMD card, I'd just recommend going with llama.cpp Vulkan and skipping ROCm completely.

Re: llama.cpp

#160
post #19

Not sure why it's on the front page now, but I highly recommend using llama.cpp for running AI model locally vs using other inference framework, unless you have a very specific requirement. ggerganov and the team have done a stellar job maintaining the quality while still being fast to implement new models/improvements.

true, switched from ollama to llama.cpp these days and it's good. wonder if this is also the best option for edge ai deployment(currently use it on desktop)
Post reply on HN