frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Open in hackernews

The 1979 Design Choice Breaking AI Workloads

https://www.cerebrium.ai/blog/rethinking-container-image-distribution-to-eliminate-cold-starts
22•za_mike157•3h ago

Comments

PaulHoule•2h ago
I remember dealing with this BS back in 2017. It was clear to me that containers were, more than anything else, a system for turning 15MB of I/O into 15GB of I/O.

So wow and new shiny though so if you told people that they would just plug their ears with their fingers.

pocksuppet•2h ago
This doesn't follow from anything in the article.
PaulHoule•46m ago
I was working with prototypical foundation models and having the exact same problem. My diagnosis wasn't quite the same, I think more radical gains could be had with a "stamp out unnecessary copies everywhere" policy but it looks like he did get through a bottleneck. The thing is he is happy with 3x speedup whereas I was looking for more of 300x except that, of course, if it takes you 20 min to sling containers and 5 min to do real work you'll probably be happy to 3x the container slinging.
formerly_proven•2h ago
The gzip compression of layers is actually optional in OCI images, but iirc not in legacy docker images. The two formats are not the same. On SSDs, the overhead for building an index for a tar is not that high, if we're primarily talking about large files (so the data/weights/cuda layers instead of system layers). The approach from the article is of course still faster, especially for running many minor variations of containers, though I am wondering how common it is for only some parts of weights changing? I would've assumed that most things you'll do with weights would change about 100% of them when viewed through 1M chunks. The lazy pulling probably has some rather dubious/interesting service latency implications.

The main annoyance imho with gzip here is that it was already slow when the format was new (unless you have Intel QAT and bothered to patch and recompile that into all the go binaries which handle these, which you do not).

jono_irwin•20m ago
Yeah that’s fair. For weights specifically there often isn’t a huge dedupe win across versions since retraining tends to change most of them. That said, we generally don’t advocate including model weights in container images anyway. The main benefit for us is avoiding the need to pull the full image up front and only fetching the data actually touched during startup. On the latency side, reads happen over a local network with caching and prefetching, so the impact on request latency is typically minimal.
MontyCarloHall•2h ago
I ran into a similar issue years ago, where the base infrastructure occupied the lion's share of the container size, very similar to the sizes shown in the article:

   Ubuntu base      ~29 MB compressed
   PyTorch + CUDA   7 – 13 GB
   NVIDIA NGC       4.5+ GB compressed
The easy solution that worked for us was to bake all of these into a single base container, and force all production containers built within the company to use that base. We then preloaded this base container onto our cloud VM disk images, so that pulling the model container only needed to download comparatively tiny layers for model code/weights/etc. As a benefit, this forced all production containers to be up-to-date, since we regularly updated the base container which caused automatic rebuilding of all derived containers.
jono_irwin•41m ago
That approach works really well when you have a stable shared base image.

Where it starts to get harder is when you have multiple base stacks (different CUDA versions, frameworks, etc.) or when you need to update them frequently. You end up with lots of slightly different multi-GB bases.

Chunked images keep the benefit you mentioned (we still cache heavily on the nodes) but the caching happens at a finer granularity. That makes it much more tolerant to small differences between images and to frequent updates, since unchanged chunks can still be reused.

andrewvc•2h ago
They say an ideal container system would download portions of layers on demand, however is seems far from ideal for many production workloads. What if your service starts, works fine for an hour, then needs to read one file that is only available over the network, but that endpoint is unreachable? What if it is reachable but it is very very slow?

The current system has issues with network stuff, but in a deploy process you can delineate that all to a new container deployment. Perhaps you try to deploy a new container and it fails because the network is slow or broken. Rollback is simpler there. Spreading network issues over time makes debugging much harder.

The current system is simple and resilient but clearly not fast. Trading speed for more complex failure modes for such a widely distributed technology is hardly a clear win.

The de-duplication seems like a neat win however.

jono_irwin•48m ago
Good point, network dependency is a valid concern.

In practice these systems typically fetch data over a local, highly available network and aggressively cache anything that gets read. If that network path becomes unavailable, it usually indicates a much larger infrastructure issue since many other parts of the system rely on the same storage or registry endpoints.

So while it does introduce a different failure mode, in most production environments it ends up being a low practical risk compared to the startup latency improvements.

For us and our customers, the trade off is worth it.

pocksuppet•2h ago
Clickbait title. Summary: Their AI docker containers are slow to start up because they are 10GB layers that have to be gunzipped, and gzip doesn't support random access.
alanfranz•2h ago
Looks like they'd like something git repositories (maybe with transparent compression on top) rather than .tar.gz files. Just pull the latest head and you're done.
cosmotic•1h ago
Why does the model data need to be stored in the image? Download the model data on container startup using whatever method works best.
jono_irwin•58m ago
hey cosmotic, we're not really advocating for storing model weights in the container image.

even the smaller nvidia images (like nvidia/cuda:13.1.1-cudnn-runtime-ubuntu24.04) are about 2Gb before adding any python deps and that is a problem.

if you split the image into chunks and pull on-demand, your container will start much faster.

za_mike157•57m ago
You are correct! From our tests, storing model weights in the image actually isn't a preferred approach for model weights larger than ~1GB. We run a distributed, multi-layer cache system to combat this and we can load roughly 6-7GB of files in p99 of <2.5s
dsr_•1h ago
The problem: "containers that take far too long to start".

Somehow, they don't hit upon the solution other organizations use: having software running all the time.

I suppose if you have a lousy economic model where the cost of running your software is a large percentage of your overall costs, that's a problem. I can only advise them to move to a model where they provide more value for their clients.

za_mike157•59m ago
A lot of AI workloads require GPUs which are expensive so customers would waste money running idle machines 24/7 with low utilisation which kills gross margins. By loading containers quickly means, means we can scale up quickly as requests come in and you only need to pay for usage.

This is successful for CPU workloads (AWS Lambda) but AI models and images are 50x the size

dsr_•56m ago
As I said, if only you were providing more value rather than being a commodity, you could avoid all this.
notyourbiz•1h ago
Super helpful.
za_mike157•57m ago
Glad you liked it!

Building a Procedural Hex Map with Wave Function Collapse

https://felixturner.github.io/hex-map-wfc/article/
185•imadr•3h ago•30 comments

JSLinux Now Supports x86_64

https://bellard.org/jslinux/
107•TechTechTech•3h ago•20 comments

Show HN: The Mog Programming Language

https://moglang.org
54•belisarius222•2h ago•16 comments

DARPA's new X-76

https://www.darpa.mil/news/2026/darpa-new-x-76-speed-of-jet-freedom-of-helicopter
73•newer_vienna•3h ago•61 comments

Bluesky CEO Jay Graber is stepping down

https://bsky.social/about/blog/03-09-2026-a-new-chapter-for-bluesky
90•minimaxir•57m ago•77 comments

Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

46•filipbalucha•3h ago•25 comments

Fixfest is a global gathering of repairers, tinkerers, and activists

https://fixfest.therestartproject.org/
100•robtherobber•2h ago•9 comments

Restoring a Sun SPARCstation IPX part 1: PSU and NVRAM (2020)

https://www.rs-online.com/designspark/restoring-a-sun-sparcstation-ipx-part-1-psu-and-nvram
70•ibobev•4h ago•36 comments

Fontcrafter: Turn Your Handwriting into a Real Font

https://arcade.pirillo.com/fontcrafter.html
366•rendx•10h ago•122 comments

Flash media longevity testing – 6 years later

https://old.reddit.com/r/DataHoarder/comments/1q6xnun/flash_media_longevity_testing_6_years_later/
100•1970-01-01•1d ago•46 comments

Show HN: DenchClaw – Local CRM on Top of OpenClaw

https://github.com/DenchHQ/DenchClaw
49•kumar_abhirup•5h ago•48 comments

Florida judge rules red light camera tickets are unconstitutional

https://cbs12.com/news/local/florida-news-judge-rules-red-light-camera-tickets-unconstitutional
119•1970-01-01•2h ago•193 comments

Durdraw – ANSI art editor for Unix-like systems

https://durdraw.org/
6•caminanteblanco•1h ago•1 comments

Rethinking Syntax: Binding by Adjacency

https://github.com/manifold-systems/manifold/blob/master/docs/articles/binding_exprs.md
18•owlstuffing•1d ago•4 comments

Ireland shuts last coal plant, becomes 15th coal-free country in Europe (2025)

https://www.pv-magazine.com/2025/06/20/ireland-coal-free-ends-coal-power-generation-moneypoint/
731•robin_reala•9h ago•442 comments

Jolla on track to ship new phone with Sailfish OS, user-replaceable battery

https://liliputing.com/the-new-jolla-phone-with-sailfish-os-is-on-track-to-start-shipping-in-the-...
127•heresie-dabord•3h ago•80 comments

Reverse-engineering the UniFi inform protocol

https://tamarack.cloud/blog/reverse-engineering-unifi-inform-protocol
120•baconomatic•7h ago•49 comments

An opinionated take on how to do important research that matters

https://nicholas.carlini.com/writing/2026/how-to-win-a-best-paper-award.html
33•mad•3h ago•3 comments

FreeBSD Capsicum vs. Linux Seccomp Process Sandboxing

https://vivianvoss.net/blog/capsicum-vs-seccomp
92•vermaden•7h ago•34 comments

What I Always Wanted to Know about Second Class Values

https://dl.acm.org/doi/epdf/10.1145/3759427.3760373
16•todsacerdoti•3h ago•8 comments

US Court of Appeals: TOS may be updated by email, use can imply consent [pdf]

https://cdn.ca9.uscourts.gov/datastore/memoranda/2026/03/03/25-403.pdf
488•dryadin•13h ago•376 comments

Algebraic topology: knots links and braids

https://aeb.win.tue.nl/at/algtop-5.html
47•marysminefnuf•5h ago•4 comments

The Most Beautiful Freezer in the World: Notes on Baking at the South Pole

https://www.newyorker.com/culture/the-weekend-essay/the-most-beautiful-freezer-in-the-world
5•mitchbob•54m ago•1 comments

Velxio, Arduino Emulator

https://velxio.dev/
6•dmonterocrespo•1d ago•4 comments

Workers report watching Ray-Ban Meta-shot footage of people using the bathroom

https://arstechnica.com/gadgets/2026/03/workers-report-watching-ray-ban-meta-shot-footage-of-peop...
34•randycupertino•1h ago•7 comments

Uber reported to the state that I was fired for "annoying a coworker."

https://anon-ex-uber.medium.com/uber-reported-to-the-state-that-i-was-fired-for-annoying-a-cowork...
45•anon-ex-uber•41m ago•14 comments

Is legal the same as legitimate: AI reimplementation and the erosion of copyleft

https://writings.hongminhee.org/2026/03/legal-vs-legitimate/
152•dahlia•4h ago•144 comments

Unlocking Python's Cores:Energy Implications of Removing the GIL

https://arxiv.org/abs/2603.04782
110•runningmike•3d ago•76 comments

Show HN: VS Code Agent Kanban: Task Management for the AI-Assisted Developer

https://www.appsoftware.com/blog/introducing-vs-code-agent-kanban-task-management-for-the-ai-assi...
82•gbro3n•9h ago•40 comments

Grammarly is offering ‘expert’ AI reviews from famous dead and living writers

https://www.wired.com/story/grammarly-is-offering-expert-ai-reviews-from-your-favorite-authors-de...
111•jmsflknr•4d ago•147 comments