Live data from Hacker News

Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon

github.com

21–30 of 101 posts

Re: Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon

#21
post #2

[flagged]

Don't post generated/AI-edited comments. HN is for conversation between humans https://news.ycombinator.com/item?id=47340079

That doesn't read like an AI-generated comment to me. He did mention he vibe-coded the project but that's not against the guidelines.

Re: Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon

#22
post #15

There needs to be something like this from Ollama. At the moment Ollama has a lot of flaws that prevent it from getting great performance. (My understanding is better GPU/CPU splits, etc). But Ollama is the only way to host an LLM and have it switch out on demand. Sigh.

Ollama has very substandard support for mmap at present, which hurts inference with larger models. There are some recent pull requests in flight that should help address this to at least some extent https://github.com/ollama/ollama/pull/14525 https://github.com/ollama/ollama/pull/14134 https://github.com/ollama/ollama/pull/14864 but progress seems to be stalling. Their support for recent Qwen models seems to also have some bespoke incompatibilities with llama.cpp, which doesn't help matters; it's difficult to test the same model with both.

Re: Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon

#23
post #21

Earlier quoted context omitted.

Don't post generated/AI-edited comments. HN is for conversation between humans https://news.ycombinator.com/item?id=47340079

That doesn't read like an AI-generated comment to me. He did mention he vibe-coded the project but that's not against the guidelines.

> The core insight:

That's a telltale sign of ai written text.

Re: Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon

#24
post #2

[flagged]

Have you ever generated access frequency statistics for the experts in these models, something like a histogram?

ktransformers can do dynamic placement of experts and could presumably produce such a histogram, though currently its activation statistics are just a ".pt" file. https://github.com/kvcache-ai/ktransformers/blob/main/doc/en...

FWIW I never got it to work and did not dig into it much.

Re: Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon

#26
post #21

Earlier quoted context omitted.

Don't post generated/AI-edited comments. HN is for conversation between humans https://news.ycombinator.com/item?id=47340079

That doesn't read like an AI-generated comment to me. He did mention he vibe-coded the project but that's not against the guidelines.

gptzero says 99% chance it’s AI-generated

It certainly has a lot of telltale signs

Re: Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon

#27
post #20
post #18

Intel Optane rolling in its grave.

Still have 4 brand new ones in my storage unit. Just in case these moments. Joke aside (I do have them tho!), I don't think Optane is that much use (not to mention it is only 256GiB for my unit). It is useful legacy crutch if you have legacy software that is not designed to issue multiple reads / writes in parallel. If you do, it is really not faster than NVMe, especially these modern ones.

It's not about being faster (except for small reads where latency dominates, which is actually relevant when reading a handful of expert-layers immediately after routing), it's the wearout resistance which opens up the possibility of storing KV-cache (including the "linear" KV-cache of recent Qwen, which is not append-only as it was with the pure attention model) and maybe even per-layer activations - though this has the least use given how ephemeral these are.

Re: Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon

#29
OS paging would be significantly worse here. The kernel's page fault handler is reactive — it doesn't know you're about to read layer 47's FFN weights, so it can't prefetch. You stall on every fault, wait for the 4KB/16KB page to load, then resume. With 80 layers of dense FFN streaming, that's thousands of cold faults per token.

  What makes this approach faster is that the model's access pattern is completely deterministic during         
  inference. You know exactly which tensors are needed next because transformer layers execute sequentially. So
  you can issue large sequential reads and prefetch the next layer while the current one is computing on Metal. 
  The OS page cache can't do that — it has no concept of "layer N+1 comes after layer N."

  For MoE it's even more stark. The OS would page in all 8 experts on the first token that routes to each one,  
  then evict them under memory pressure with LRU, which has no idea that expert 3 fires 10x more often than
  expert 7. The neuron cache here is basically a domain-specific replacement policy.

Re: Hypura – A storage-tier-aware LLM inference scheduler for Apple Silicon

#30

OS paging would be significantly worse here. The kernel's page fault handler is reactive — it doesn't know you're about to read layer 47's FFN weights, so it can't prefetch. You stall on every fault, wait for the 4KB/16KB page to load, then resume. With 80 layers of dense FFN streaming, that's thousands of cold faults per token. What makes this approach faster is that the model's access pattern is completely determin…

> The kernel's page fault handler is reactive — it doesn't know you're about to read layer 47's FFN weights, so it can't prefetch.

man 2 madvise

Post reply on HN