I’ve been deeply inspired by Kimi K3, but found it hard to put into words. After letting it sit for a day, I think it comes down to two things. It raises a question I don’t have a clear answer to: how much compute does reaching the frontier actually take? K3 makes me think the number is lower, maybe much lower, than I’d have assumed. I have some rough estimate on their compute and am looking forward to their report for more calibration. The other thing is that the technical depth has a wider range of leverage than I expected. K3 got near parity with the world’s frontier on materially less compute, carried by very strong research and engineering. They’re sharing their weights and learnings openly, in an otherwise increasingly closed world. None of this makes resources less important. What K3 challenges is a narrower belief I quietly held: that frontier performance is out of reach for anyone outside the two or three labs with the most chips. I want to live in a world where there’s more opportunity, and K3 gives me more hope.

Big news: Kimi-K3 by @Kimi_Moonshot is now #1# in the Frontend Code Arena with 1679 pts, surpassing Claude Fable 5. This is a 17-place jump from Kimi-k2.6 (#18# -> #1#). In Frontend, Kimi-K3 ranked #1# in 6 of 7 domains: Brand & Marketing, Reference-Based Design, Data & Analytics, Consumer Product, Simulations, and Content Creation Tools, landing #2# only in Gaming behind Fable 5. The full model weights will be released by July 27. Congrats to the @Kimi_Moonshot team on this major milestone!

Released just a month after Reve 2.0, Reve 2.1 brings a real jump in visual intelligence and reasoning. It lands 2nd overall, and remains the world's top 4K model, from an independent lab training on 10x fewer GPUs.

reve 2.1 is an upgrade that we've been cooking since last month! i had a lot of fun (and stress hehe) scaling its pretraining with async DP. it is a cross-cluster distributed algorithm that allowed us training with more compute, while staying within our existing provision. we implemented it from scratch and derisked across a few scaling rungs. it matches sync DP after getting knobs right, costs minimal overhead, and offers elasticity at the same time. cool stuffs 🦋 (also sharing a comic from our model)

Huge respect to @Guodzh and @imhaotian and everyone on the team for building a culture focused on solving hard problems, shipping better models, and improving usability and user experience. Ideas are cheap, talking is easy, and titles/narratives are easy after the fact. Being solid and making things actually work is the hard part.

we made a new model for text-to-image generation and editing. the results are looking good and the leaderboard is looking strong. it turns out that nano banana 2 is not impossible to beat, which felt like the case at the beginning of the year. there are a lot of great models out there that get released often. why should you care about reve 2.0? to me, there are mainly two reasons. one being that reve is an underdog, reasonably funded but magnitudes less than other big labs, e.g. oai, google, meta, etc. you might be curious about how we managed to make it to the top. two being that reve 2.0 is a decent model, and we as a team are willing to talk openly about some of our learnings and thoughts that could be helpful. in this post, i want to share mine on reve 2.0 and multimodal in general as a person working on it. first things first, reve 2.0 is a pixel diffusion model with a thing that we call "layout" as the rendering representation. these two things are our research bets that turned out to work amazingly well. pixel diffusion lets us go 4k without sacrificing quality or speed. layout lets us scale better and have better control, which are two sides of the same coin. the field standard has been to use long upsampled prompts for rendering. yet this results in an awkward situation where captioners and users need to describe precise controls with text, which can be inaccurate. this inaccuracy amounts to bad reconstruction and control at test time. it gets worse with scale. and this inherent ambiguity is a curse in current multimodal generators. so what's a layout? a layout is a css of an image, which can be either defined by humans or learned by models. we end up capitalizing a lot on regions, which are good for 2D space. yet this idea naturally generalizes. it turns out to be a standard VLM mid-training task, and that's solvable in good hands. it also brings many good properties in pretraining and post-training, which i am not going to expand on. ideogram independently verified that layout is useful (released on the same day, congrats!). to be clear, these bets are not novel, but to put together a system that makes them work is (and showing it beats nano banana 2). second, it's nice that these bets, among others, worked out. however, like in many cases, there was a long time when things were underperforming. our competitor models are great, and most likely didn't make many risky bets. it is a big pipelining and engineering problem. why should we risk it? in retrospect, the culture of our team and leadership helped a lot. our priorities didn't swing and have stayed focused during our development. the idea makes sense, the execution is good, if things don't work out it's a bug, let's go find it and try more things. by and large, reve remains a research lab with big computers. this is rare. let me tag some amazing ppl here: @Taesung @m_gharbi @Songwei_Ge @TianweiY James Hong @dima_smirnov_ @theSidlak, ... the list goes on. third, we spent most of our time improving text-to-image and didn't do much on editing. and our arena ranks show that. to date, we are #2# on text-to-image yet #9# on image editing. it's honestly a bit embarrassing that we didn't do well in editing, as layout promises to do well. but i am confident that this will improve, as we are juggling bandwidth and resources (we are a small team, and hey, come join us!). fourth, talking about leaderboards and the state of multimodal, i genuinely feel that the gap between labs is shrinking. compared to LLMs, multimodal gen is at least half a year to a year behind. i am talking about architectures and core pipelines. to do good multimodal, you need to do good LLMs. reve has been helped by the OSS community a lot, but we've realized we need to own our language stack. and scaling follows naturally. leaderboards, in turn, are a noisy approximation and average of the real environments that you care about in deployment. they chase scaling and generalizable post-training. reve 2.0 ended up not being driven much by leaderboard evaluation, but relying on our intuition instead. finally, how can multimodal be more useful? this is a question that keeps me up at night. coding has found its product-market fit and is driving up societal productivity. how can multimodal do that too? to me, we are nailing a single-round rollout that leads to an infinite one. this infinite rollout will drive our digital interaction and creation. for this rollout to be good, it needs to be precise. otherwise rollout efficiency is too low for either humans or agents. we are making bets and concrete progress towards that goal, such as converting images into a css-like layout. if you are interested in this topic, i recommend @stuffyokodraws's post for a high-level digest: the success of multimodal depends on whether or not it can find a good product-market fit. that's the top question to figure out, then it's the model. it's quite non-linear to be honest, as critical pieces are still missing. but to me it's an area worth pouring my thoughts and efforts into. give our model a spin, try your tasks, move some boxes. in case you find any bugs, please let me know in a reply or DM. hope it can help you.