Learning AI Infrastructure Through Two Lenses AI Infrastructure 学习总览

01 Why I Started

The reason was simple at first: I was interviewing with an AI infrastructure startup.

I read through the company's website, its GitHub, and its public technical material. I also looked at the team's backgrounds and open roles on LinkedIn. It turned out to be a field that sits deep in the technical stack.

Before anything else, I needed to understand the technical world it operates in. I also wanted to actually learn it: why these technologies exist, what problems they solve, and how they turn into real value.

So I built my own learning roadmap from scratch.

02 How I Designed My Learning

I split my learning into two tracks that complement each other.

Track A: Understand the Technology. The first track closes my most direct knowledge gap. I want to understand what problems engineers are solving and why they make the technical decisions they do.

Track B: Understand the Users & Business. I enjoy technology. I also enjoy turning complex knowledge into something simple that other people can use. I've always been interested in user needs, user experience, and how products get adopted.

But good technology doesn't guarantee a valuable product.

As a user, I don't buy a product to admire the technology behind it. I buy it because it solves my problem, improves my experience, or creates some kind of value for me.

How, then, do we close the gap between technical capability and user value? That question is why Track B exists.

Track A helps me understand what the technology can do. Track B helps me understand who needs it, why they need it, and how to get it used.

How I Study

I start by using AI to collect and organize public material: project docs, GitHub, company websites, technical write-ups, and job postings. I add what I've seen of the team's backgrounds and use all of it to understand the basic structure of the field.

Next, I ask the AI to build a knowledge tree. I check how the modules connect and revise the structure until it holds together. Only then do I go deep on each module, one at a time.

For each topic, I start with the what, the why, and the how. Then I test my understanding against concrete scenarios and questions. I also write my misunderstandings, my corrections, and new ideas into these notes.

03 My Learning Map

I wanted each module to be a question worth answering, not just a term. The map moves from a single computation to a full system, then from technical capability to user value.

Track A — Technology

It starts with a single LLM computation, then moves to the resource limits of GPUs. From there it covers LLM serving for many users, inference engines, and post-training. That is the technology line. Turning an open-source project into a business sits in Track B, not here.

Track B — Product & Business

It starts with the market and real developer problems, then asks how a technical capability becomes product value. Adoption and building a business are one phase: developer experience, go-to-market, and how an open-source project gets used and paid for. It ends with work you can actually contribute.

04 What I've Learned So Far

01 From One AI User to Inference at Scale

I used to understand AI mostly as an everyday user: send a request, then wait for the model's answer.

Now I can see the other side. When many requests hit the system at once, the question isn't just whether the model can produce an answer. It's also how GPU resources get allocated, how requests get scheduled, which computation can be reused, and how to balance cost, latency, and throughput.

For the first time, I started to understand what infrastructure it takes to run AI applications at scale.

02 Higher Metrics Aren't Always Better

A higher cache hit rate, for example, doesn't necessarily mean lower end-to-end latency. It says even less about developer experience.

Caching takes up resources, and requests may have to wait. Improving one technical metric doesn't guarantee that the whole system, or the user experience, gets better.

Before optimizing anything, I should understand the real workload and what users actually care about. Only then can I decide which metrics to optimize and how to measure the result.

05 Reflections & Open Questions

I used to focus on consumer products and the experience of everyday users.

AI infrastructure introduced me to completely different perspectives: developers, infrastructure teams, enterprises, and people building complex agent systems.

I've really enjoyed the process. It feels like exploring a map. At first you only know the small area where you live, and it's hard to picture what lies beyond it. Once you start walking outward, you find how many different problems, technologies, and ways of working are out there.

And the more I learn, the more I see how much I still don't know.

Next, I want to connect what I understand about the technology to real developer research instead of keeping it theoretical.

The questions I most want to explore next:

1. When developers choose an AI infrastructure product, what do they weigh besides performance and cost?
2. How can we tell whether a technical optimization actually improves the user experience?
3. What does a strong open-source project need to become a widely adopted, sustainable product?

I hope this roadmap helps me understand a new industry. I also hope it helps me find the value I can create where technology, users, and business meet.