Reid Burke

Daniel & Michael Han:

DeepSeek-R1 has been making waves recently by rivaling OpenAI’s O1 reasoning model while being fully open-source. We explored how to enable more local users to run it and managed to quantize DeepSeek’s R1 671B parameter model to 131GB in size, a 80% reduction in size from the original 720GB, whilst being very functional.

By studying DeepSeek R1’s architecture, we managed to selectively quantize certain layers to higher bits (like 4bit), and leave most MoE layers (like those used in GPT-4) to 1.5bit (see Unsloth Dynamic 4-bit). Naively quantizing all layers breaks the model entirely, causing endless loops and gibberish outputs. Our dynamic quants solve this.

The 1.58bit quantization should fit in 160GB of VRAM for fast inference (2x H100 80GB), with it attaining around 140 tokens per second. You don’t need VRAM (GPU) to run 1.58bit R1, just 20GB of RAM (CPU) will work however it maybe slow. For optimal performance, we recommend the sum of VRAM + RAM to be at least 80GB+.

Jay Alammar explains R1 visually.

Guillermo Rauch, Vercel CEO:

React has become the ‘linux kernel’ of modern software development. The industry has broadly standardized around its ‘syscall interface’, from vendors shipping hooks or components as their SDKs, to LLMs being trained to generate it.

The metaphor holds further. Today, Linux is mostly used in the form of distributions that bundle it. Most users are oblivious to what kernel version they’re even running, because they’re interested in a working operating system with all the necessary tools to be productive, as well as an app ecosystem, support, and security patches.

A lot of people start using React by (sometimes unknowingly) assembling their own ‘distributions’ aka frameworks. This is akin to checking out the Linux source, running `make vmlinux`, then re-assembling the operating system by hand. I think this is a very cool thing to learn and do, and early in my career I’m very thankful I bootstrapped my own Linux systems with projects like LFS and Gentoo. It built character and foundational knowledge.

If you’re building a product or a company, I strongly recommend you pick a distribution, not assemble one. Next.js is the most popular, but naturally many others have emerged: TanStack, Remix, Astro, Waku to name a few great ones, built by passionate, expert “kernel” engineers.

One of the responsibilities of my first job was administering a fleet of Gentoo Linux servers hosting websites for K-12 schools. It definitely built character.

These days reading and understanding React Router and Next.js source build foundational knowledge. (But I still like building modern Linux systems and understanding how they work too.)

See also the excellent answer to “Can I use React without a framework?” in the React guide:

You can definitely use React without a framework—that’s how you’d use React for a part of your page. However, if you’re building a new app or a site fully with React, we recommend using a framework.

Here’s why.

Even if you don’t need routing or data fetching at first, you’ll likely want to add some libraries for them. As your JavaScript bundle grows with every new feature, you might have to figure out how to split code for every route individually. As your data fetching needs get more complex, you are likely to encounter server-client network waterfalls that make your app feel very slow. As your audience includes more users with poor network conditions and low-end devices, you might need to generate HTML from your components to display content early—either on the server, or during the build time. Changing your setup to run some of your code on the server or during the build can be very tricky.

These problems are not React-specific. This is why Svelte has SvelteKit, Vue has Nuxt, and so on. To solve these problems on your own, you’ll need to integrate your bundler with your router and with your data fetching library. It’s not hard to get an initial setup working, but there are a lot of subtleties involved in making an app that loads quickly even as it grows over time. You’ll want to send down the minimal amount of app code but do so in a single client–server roundtrip, in parallel with any data required for the page. You’ll likely want the page to be interactive before your JavaScript code even runs, to support progressive enhancement. You may want to generate a folder of fully static HTML files for your marketing pages that can be hosted anywhere and still work with JavaScript disabled. Building these capabilities yourself takes real work.

React frameworks on this page solve problems like these by default, with no extra work from your side. They let you start very lean and then scale your app with your needs. Each React framework has a community, so finding answers to questions and upgrading tooling is easier. Frameworks also give structure to your code, helping you and others retain context and skills between different projects. Conversely, with a custom setup it’s easier to get stuck on unsupported dependency versions, and you’ll essentially end up creating your own framework—albeit one with no community or upgrade path (and if it’s anything like the ones we’ve made in the past, more haphazardly designed).

Building your own framework means you’re taking on a lot of maintenance overhead which will come at the expense of time spent building your actual product.

Sometimes you need to innovate and do something nobody else is doing. You might want to modify or extend a great existing framework in a strategic and targeted way instead of building everything custom.

Be careful how you spend your innovation tokens.

Via X

React has become the 'linux kernel' of modern software development. The industry has broadly standardized around its 'syscall interface', from vendors shipping hooks or components as their SDKs, to LLMs being trained to generate it.

The metaphor holds further. Today, Linux is…

— Guillermo Rauch (@rauchg) January 25, 2025