Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Not sure what's worse, if the AI slop content, or the AI code slop that makes the site consume 100% of a single CPU core (and if you enable GPU rendering on the browser, CPU usage is still significantly above zero.)by grg0
- Thanks for the depth-anything.cpp port. Saves us a couple of kernel OOM's, causing connection disruptions.by rurban
- Could this vllm port be faster to install? Im starting gpu machine multiple times a day and it takes 5 minutes to set vllm up. If Inise this port that time is minimized?by piterrro
- This is on my list to evaluate, I absolutely do not want to download 9gb of supply chain risk into prod every time we upgrade, when I can compile 70mb of binary. We run vLLM in a container with hardware passthrough for gitops, having the entire environment in a single container would drastically improve things and move local LLM into a pattern that more closely follows our other CI/CD systems, rather than this hulking behemoth snowflake deployment.by hadlock
- What you get: X is the A, Y is the B.
- I did took a native c++ approach when writing a relational transformers engine (RelativeDB). My journey was pytorch -> c++ -> Triton (lang). While C++ was more performant than Triton, I couldn't afford to optimize on every gpu. I just accepted the ~15% throughput loss for my cloud service, which honestly wasn't bad for the amount of flexibility I got out of it.
But the cpp port of vllm looks great, that'd be great if you'll maintain that. I hit the same limitations with vllm.
by scottcodie - I had a similar success with Model2Vec static embedder and NER inference (both GGUF, compiled for WASM), ported to plain C from ONNX Runtime.
Wasm size from 30Mb to 300kb and 1.5x speedup. It's definitely worth it for performance or distribution size.
by dennis16384 - I don’t think it would be surprising that people want to write their own kernels.
A big problem with the existing engines like llama or sd is that they don’t support optimal graph compilation. Usually this means about a real 2 or 3x multiplier loss relative to optimal. Cuda graphs do okay but they still leave a lot on the floor
It’s usually worth it to optimize in that context if you are willing to peer into the mechanics.
Of course that’s expensive. You need to know how to appropriately pipeline and merge your kernels.
by aabdi - Should have started with writing your own blog posts.by stephbook
- its so toxic when people show this kind of confidence in their ability to tell when something is ai or not.
- I went through the post because of your comment but it really doesn't look like AI slop. Can you please share why you feel like its slop and not written by a human? I can also say "should have started writing your own comments" to you and its unfalsifiable. Blanket accusations with no proof is not a good move really.by altmanaltman
- Came here to say the same. Really tiring to read these slop-infested posts, where everything has the “right shape”.by nnevatie
- Same could be said for all that talk about having Claude do their work.by pjmlp
- This witch hunting is getting tiring.
I get the motives but it's tiring. I myself sometimes check my own (unpublished) writing or have friends preview it and the same feedback comes out, it's all hand written.
by epolanski - I found the post insightful and interesting. I'm not sure it was written with AI assistance, but even if it was, I don't see that as a reason to dismiss it. For what it's worth, I spend hours everyday reading AI output and summaries.by winter_blue
- > Should have started with writing your own blog posts.
While the page looks vibe-coded[1], the content itself does not have any AI tells. What are the tells you are seeing?
[1] Too many sites I find on HN frontpage these days slow my PC to a crawl. I assume they are all using the same autogenerated HTML, Javascrip and CSS to make animated backgrounds :-( On this specific site scrolling is laggy.
by lelanthran - Ignoring the fact that this is clearly not written by a human, it's untrustworthy and the claims are dubious at best.
1. The comparison of vLLM to vLLM.cpp never shows more improvement than a handful of tokens per second. That's less than 0.05x improvement on every run, and the gap doesn't grow as concurrency increases. The comparison doesn't show any real net improvement, let alone justify the project.
2. The depth anything comparison isn't apples to apples. Of course a q8_0 quant is faster than f32. It's 4x less data to chew on.
3. This point is silly, it again fights against the argument that writing your own c++ engines are worth it. It's a bug, just fix it:
> The reason it is faster has nothing to do with writing better matmul kernels than PyTorch. Two positional embeddings, the DPT head’s UV embedding and the backbone’s bicubic position embedding, were being recomputed on every forward pass with single-threaded scalar sin, cos and bicubic loops, even though they depend only on the input geometry and are identical every call.
They argue against their own point again just after:
> For a biometric pipeline, matching the reference exactly matters more than being faster than it.
Okay, then don't rewrite it! It's not faster anyway!
4. If the argument is that the venv is large, then rewriting it in C++ doesn't seem like the answer, it seems like a lot of work and maintenance to avoid having to cull unreachable files in your venv. In a past life I maintained a simple denylist for files in node_modules. The low hanging fruit is plentiful and generally very safe.
by bastawhiz - Take a look at the code. It is a conglomeration of python, rust, go, cpp etc. I was expecting lean C or C++ but all I see is a kitchen sink of code, the AI generated kind. No problem with that, but it is inconsistent with the messaging. I appreciate the intention behind this, but dont like the execution. My prediction is that this will enter the graveyard of ai generated git repos.
For open-source code to get adoption and support, the theory of its construction needs to be understood by humans because at the end of the day, some human will be responsible for its operation. I would call this the Terrence Tao principle: Output of AI is only as useful as how well it can be digested by humans.
by bwfan123 - Getting any performance improvement over vLLM is just a bonus although the RAM reductions are very nice. The main point is that we find deploying Python based projects to be a pain. I can't imagine how you know what files are unreachable in a dynamic language, but in any case that doesn't begin to solve issues like PyTorch requiring a C++ compiler at runtime to generate optimised CPU code. This isn't exactly embedded device friendly.
Having said that if you know of some magic bullet to fix the problems with the Python ecosystem (that vLLM and Pytorch are apparently unaware of) then I will be happy to try it because our CI is constantly blocked by Python related issues.
by richiejp