karan retweeted
i've been away for a while so some updates were naturally due
1. sundial got acquired by @meta (i was the second designer on a team of two). had so much fun working with @joulee and @aditshri_. ride of a lifetime.
2. a bit old now, but lica got acquired by @gammaapp (i was the first designer)
3. building something new. more on this soon.
Today, we're announcing that Sundial has been acquired by @Meta!
Chandra Narayanan and I are joining along with some other incredible members of our team.
Nearly six years ago, Chandra and I started Sundial with two core beliefs: 1) better decisions come from using data well, and 2) great things come from working on hard problems with people you like.
Sundial automated away many of the obstacles involved in getting to meaningful analysis (Cleaning data! Creating semantic layers! Writing SQL! Storytelling!), and we were proud to support some of the fastest-growing AI companies from OpenAI to Gamma.
We started before the AI wave and rebuilt ourselves to be AI-native. We raised our first round when interest rates were near zero, and our Series A when they were the highest in two decades. We watched customers hyperscale and then close shop, new grads grow into leaders, and software development change completely.
Entrepreneurship has been my dream since college, when I first took a class on start-ups (shoutout Mayfield Fellows!). I wish I'd been brave enough sooner because there’s no better way to learn how the world works and who you really are than betting on yourself to launch a business.
Meta is my former home and where I learned product and design. It's also one of the most analytically rigorous places on the planet. So many of Sundial's values came from there: questioning assumptions, diagnosing with data, owning the user’s experience. I'm thrilled to bring what we've learned to the place where it all started and continue our mission of improving the quality and velocity of business decisions with people we like.
To Team Sundial past and present, THANK YOU thank you thank you. You created that special feeling within our team, and I bask in the memories of having walked those lush miles and eaten those breakfast dosas with you.
To our investors and supporters especially @dpatil, David Fischer + the whole 01A advisors team, @mvernal, @sequoia: how did we get so lucky to have your counsel and support? And to my beloved @mikesego and kiddos: I could not have made it without you.
These have been some of the hardest, most humbling, and most alive years of my life. I hope I'm wiser for it and will have many chances to pay it forward!
axios.com/2026/10/23/meta-ai…
“you can literally iterate your way into heaven, given enough time. there’s no end to iterations anyway. iterate until you die.”
Asking yourself "what do I want" and trying to come up with the answers from scratch (as if life is a blank slate) is a learned helplessness response imo.
Because it generates more confusion, doesn't answer much - its fruit is being stuck instead of movement. Which means, unconsciously, it's serving that - instead of getting you to clarity. So, that's the use of it. It's trying to keep you from facing the actual (perceived) screwedupness of your situation.
Sometimes big shifts, huge leaps are possible but if you have to force even the idea of it, usually it won't work. So what to do instead?
Asking huge broad questions like that is futile but you can look at your life, look at the primary problems/things you're not happy about and ask yourself: "What do I want instead?"
Now this is the magic question. Because it's not a heroic effort question of trying to come up with a new depiction of reality with a blank canvas - but it's asking you to ITERATE.
And you can literally iterate your way into heaven, given enough time. There's no end to iterations anyway. Iterate until you die.
this post is meant to eliminate most reasons you put yourself in a state of inaction/hopelessness
1. you weigh some past experiences of your failure far too greatly to be able to realise your present state has always been detached from past losses.
2. lack of real life evidence of people around you succeeding has compelled your brain into thinking that there exists some information without which you cannot make any substantial progress so you stay in the constant comfort of never having to make the first messy thing.
3. you wish to avoid the discomfort that comes with taking action. you wish to never have shaky hands. this is simply not possible. getting used to uncertainty and still getting an absurd amount of work done is the only real way.
4. you overestimate competition/ the volume of total existing competitors. the numbers may be real. but the distribution of skill amongst all players never changed and it never can.
none of this is meant to motivate you. only to make you think long enough for you to figure out what it will take for you to work like you dream of working.
the single greatest project you should do if you are trying to become better at ai systems is to take an open weights model and build the entire production system around it. do this by yourself and watching tutorials only when needed.
1. take a pretrained model and understand its inference path. this will help you learn what computational work happens for every token that is generated.
2. build an inference server. put your model behind something like vllm/sglang. then expose it through and api, handle multiple users
3. understand why inference is fast or slow. learn about batching, kv cache, quantization, gpu memory, scheduling, and the tradeoff between speed, cost, and quality.
4. build the backend around the model. add users, login, chat history, databases, caching, request limits, error handling, and basic security.
5. build a simple chat product around it. create a frontend where users can start conversations, send messages, receive streamed responses, and manage their chat history.
6. give the model access to outside knowledge. build a simple rag system that can load documents, retrieve relevant information, and give that information to the model before it answers.
7. give the model the ability to take actions. add tool calling so it can use apis, search, databases, or other functions. then build a simple agent loop around these tools.
8. build evaluation and monitoring. measure answer quality, retrieval quality, latency, errors, token usage, gpu usage, and cost. make sure you can tell when a change makes the system better or worse.
9. make the system reliable and safe. learn about authentication, rate limits, retries, timeouts, failures, data isolation, prompt injection, and safe tool use.
10. deploy the whole system. run it on a cloud gpu, containerize it, and learn how the different parts communicate with each other in production.
11. test it under real load. send many requests at the same time, find the bottlenecks, and learn how to improve throughput, latency, gpu usage, and cost.
12. scale it. move from one model server to multiple servers and eventually learn multi-gpu and distributed inference.
13. automate the whole lifecycle. add testing, model versions, evaluation before deployment, automatic deployment, monitoring, and rollback.
14. keep improving the system. whenever you find a bottleneck, don't immediately watch a tutorial. first understand the problem, form a hypothesis, test it, and only then look for outside help if you are stuck.
this isn't meant to be built in two weeks and will take you months to build depending on your understanding of software engineering. but this has by far been my steepest learning curve in a project coming from a core ml background.
karan retweeted
besides the regular serving side optimizations for llms, studying model architectures designs has been quite important as well to accelerating inference on gpus.
i found this llm that recently released called Ling 3.0 flash by @AntLingAGI , and it seemed like an excellent case study to do since it has tons of the new architectural designs rather than the regular serving side optimization.
ill do a 5 day case study on this model and towards the end youd have a more stronger idea to why this matters.
breakdown 1 - ling 3.0 flash architecture deep dive
this is a 124b moe model with a hybrid linear architecture. it has 512 routed experts, 8 active experts with 1 shared expert.
sounds like a lot but lets unpack one at a time.
whats an moe?
moes are a type of sparse model where unlike the normal transformer block which has one FFN(feed forward layer), it replaces that FFN with multiple experts.
these experts are basically FFN layers.
so instead of every token going through one big FFN, the model has many FFNs sitting there and a router decides which ones should handle each token.
the important word here is sparse.
in a dense model, every token uses almost all the weights in every layer.
in an moe model, the model can have a huge number of total parameters, but only a small subset of them are active for any given token.
this is why you will see numbers like:
124b total parameters
5.5b active parameters
at first this sounds weird. how can it be a 124b model but only use 5.5b?
the reason is the model stores many experts, but it does not invoke all of them for every token.
the core idea is: given a token, route it to a few experts, run only those experts, then combine their outputs.
so what do we need to achieve this?
- a router - the layer that looks at the token representation and decides which experts to use.
- the experts themselves - these are the FFN blocks.
- a combine step - after the selected experts run, their outputs are weighted and added back together.
now training this is the tricky part.
say we have 10 experts. early in training, the router does not really know which expert is useful for which token.
if it keeps picking the same 1 or 2 experts, those experts get trained more, become better, and then get picked even more.
some experts become overloaded, and some experts basically do nothing. that is bad because you paid for a large expert pool, but you are only using a tiny part of it.
use a top-k routing method.
instead of activating all experts, the router scores all experts and picks only the top-k.
for Ling -
512 routed experts
8 active experts
1 shared expert
so for each token, the model does not run all 512 routed experts.
it chooses 8 of them.
there is also 1 shared expert that is always available, which helps keep some common/general capacity around instead of forcing everything through routed experts.
this is where the efficiency comes from. the model has the capacity of a large model because there are many experts.
but the compute per token is closer to a much smaller model because only a few experts are active.
so moe gives you this tradeoff -
more total parameters for knowledge/capacity
less active parameters for inference cost
not free, obviously since you now have routing overhead, expert load balancing problems, and communication overhead during distributed inference.
but if done well, moe is a very strong way to improve the capability per unit of active compute.
cool, now lets focus on hybrid linear attention architecture.
the model has 42 transformer layers -
35 KDA layers
7 gated MLA layers
that is a 5:1 pattern.
attention is another major inference bottleneck, especially for long context. at smaller contexts it usually memory bound but for the longer context it is compute bound.
normal full attention needs to keep growing the KV cache as the context grows, but linear attention layers are quite different.
for the linear layers, unlike full attention, the computed state in linear attention is superimposed on the previous historical intermediate matrix. this intermediate matrix is also called an SSM. Each new SSM can be directly added to all previous SSMs.
the major difference is full attention scales with L(seq len), but in linear attention it stays fixed at d x d(hidden dim).
do you see a problem here? because at each step, the attention just keeps getting added on top, you dont really know the state at each particular step is.
no key points, no important information, no discard anything, everything is there just in a big bowl.
so Ling mixes in MLA layers. the general idea for MLA is instead of sharing key and value heads like GQA, MLA compresses the key and value tensors into a lower-dimensional space before storing them in the KV cache.
in the next posts, we will look at this with more detail and more practical numbers as well.
karan retweeted
nth order effects of ai progress will hopefully include the demolition of glass offices in favour of humans working in more naturesque environments. tech confined us in boxes, tech will take us back to grasslands.
you can just finetune qwen
🚨 NEW MODEL ALERT
Singapore just dropped a model that's putting up frontier-level numbers.
Agnes 2.5 Pro:
• 82.7 on SWE-bench Verified
• 78.7 multilingual
• Strong gains on SWE Atlas
• Beating GLM 5.2 and DeepSeek V4 Pro on multiple cuts
• Free API available today
The biggest takeaway isn't the benchmark here.
It's the country.
NOW frontier is no longer just a US vs China story.
exactly why you should still be learning everything as though ai does not exist. you must learn to learn to reason about what you know, what you don’t know and how to close that gap.
the pace of inference efficiency improvements is far more important than improvement in model capability
karan retweeted
Hey everyone!
Finally, I, with Claude, was able to make simple, educational and interactive playground for RL come to life!
This is the first step towards a interactive learning website I wanted to have when I first started with RL, and here I think I'll be bale to make it possible for everyone now.
So, through you'll a lot of algorithms, from beginner to fairly advanced one on the website, I have only tested DQN out. So please play it with for now on the playground only!
The theory and all for all algorithms is still in works but I am pushing every day so it'll be completed soon too with easy to follow theory with only required math (though its there as way to revise concepts for me primarily haha!)
Let's learn together!





















