Bonsai 27B a 1 bit i ternari: què es conserva —i què es perd— en comprimir un model nou vegades

Okay, nothing now. I'm done. Today we're going to be taking a look at the newly released Bonzai 27 billion parameter models, which are very interesting. Now, these come from Prism ML, and I have covered some of their models before in this Bonzai family. And essentially, what these are are massive reductions in size of the original models that they are based off off of, in this case being a Qwen 3.6 27B that has been shrunk down a couple of different ways, depending on what specific target device you would like this to be deployed on. So, in this announcement post, they mentioned both running this on a computer, whether it be a Linux computer, PC, or whatever, or a Mac. Additionally to that, they also talk about running these on phones. Specifically, they do mention for an iPhone 17 Pro, it is able to be run on at decent speed. I do have this running currently on an Asus ROG Phone something Pro. So, we're going to not only be able to check the performance of the one that is designed to run on a PC, but also the one that is running on a phone. As a matter of fact, I do have both of those set up and spinning right here. So, this one is the one that is running on a PC, as we could probably guess by the token speed. And this tab right here is the one that's running on the mobile phone. So, it's actually kind of cool to be able to talk to something through the web chat interface right here of Llama server, actually knowing it's running on my mobile phone sitting next to the laptop. So, before we get into it, please do feel free to subscribe so I can get that 100K plaque. And with that, let's begin just by taking a quick look at the options that we have for today in terms of these Bonzai models. So, Bonzai 27B comes in two variants. The first is a ternary Bonzai 27B, and that is the

one that is running right here in this tab on port 8080 at 65 or so tokens per second. And that is a smarter but larger version of the Bonzai model right here, where it uses ternary weights with FP16 group wise scaling, giving a true 1.71 effective bits per weight. At 5.9 GB, this is the quality-oriented quality-oriented variant. It runs on an everyday laptop with full reasoning, tool calling, and agentic capability. So, when doing some comparisons, we will really mainly want to see how this specific one, the ternary, stacks up with the FP16 version of the model it's based on, Qwen 3.6 27B. The next model version for this Bonsai 27B is the 1-bit, and this is the one that is going to be running on the mobile phone, which we can see is at port 8081 here, and running a bit slowly. However, this uses binary weights with the same group-wise scaling, giving an effective 1.125 bits per weight at 3.9 GB. So, that is a massive size reduction when considering that the full weights for the Qwen model it is based on are, as they say right here, 54 GB or somewhere around there. So, this can fit within the memory budget of an iPhone 17 Pro, bringing a 27 billion parameter class model onto a phone for the first time. I don't know if I'd say first time just based off of this Xpost I made a few months ago, but nonetheless, I am just being a bit sarcastic. So, I I don't want to get into like a big technical deep dive on how these work, because they're very complex and I don't know how much service I would do in trying to explain that. I will say, however, at the bottom of this announcement post right here, they do have a link to their white paper, which will open it for you in GitHub, and you can go through and take a peek at it. It has a lot more intricate information. No, the actual methodology that they're using

specifically to reduce the size of these models is not open source. So, just make note of that as well, but it does tell you some more pertinent information about everything that's going on here. Additionally, just to quickly touch upon it, and I'm maybe a little rusty, but from my recollection of doing some videos pertaining to their models before, essentially, the weights are shrunk down in in of 128, whether it be ternary or binary, and then that group of 128 weights has like a block-wise scaling factor that is FP16, I believe is the case. Again, don't quote me on that 100%, but basically they take like groups of 128 weights, and they become either ternary or binary depending on which specific model it is. And then a group of 128 weights gets like a scaling factor applied to them that is a higher precision than ternary or binary. Um something like that. Now, the models are available on Hugging Face in a number of different formats, and they do have some additional interesting things to note here. They have shipped this with a compatible speculative decoding setup as well, so that will speed up, as we see right here, 1.34 times decoding speed on the CUDA serving path. Additionally, they have paid respect to MLX, so Apple devices also have compatibility. Now, there's some interesting things contained here within the Hugging Face model card as well, because I find with these models, sometimes it can be confusing because it's like, "Okay, well, if the model's 5.9 GB, then if I open NVTop right here, why is my computer using 10.7 GB to serve this model right now?" And they mention that and explain it a couple of different ways. So, one of those is the kernel is storing the ternary values in a bit larger than what would be the ideal size, which is that 5.9 GB. So, the deployed size they say is around

7.2 GB. Following that, and additionally in terms of why this is using a bit more weight or VRAM than one would expect even with the deployed size, they do have a chart here just showing the actual memory footprint of this deployed over a number of different context lengths. So, we can see that 10K contexts with this model that we're running right here would be around 8.7 GB of VRAM, and 100 would go up to 14.7. So, keep that in mind, and if you wanted to run this at absolutely full context of 262K and change, it would go up even higher than that. So, keep that in mind that these are not going to be using that 6 gigs of VRAM to run this 27B model, but it's a step closer to getting there. So, I want to do a really proper comparison test to showcase these models because a lot of folks, the interest is going to be in how well do these actually stack up to the original full precision version of this model. So, in this tab right here, we are running the binary version of the model. This is running entirely on a mobile phone that is just attached to this computer just so I can get power and things like this. Given a very simple prompt. Now, in the middle tab right here, this is running on the laptop that I'm using to control this entire demo. This is a 5090 mobile and this is using the ternary version of this model. So, the more performant one as we see right here, that is the ternary that is used in the middle tab and it is the binary that is used in the left most tab. Now, all the way in the right, this is running the full precision version of this model. It's not quantized or anything and this is running on a 6000 Pro Blackwell just on the computer behind me. So, we're going to be able to see proper side-by-side results for the two Bonsai versions of this model as well as the full-blown

full precision original model. That way we can just get some more educational I suppose value out of seeing these demonstrations. Now, for this first test, I have disabled reasoning for all of these because the mobile phone one is extremely slow. The one running on the Blackwell is not super slow, but it can end up taking quite a while and then the one running on this computer right here is rather quick and I'm not using the MTP thing that is included with it. So, that would speed things up a bit, but for now we're just going to see the results we get for a simpler Steve's PC Repair website. All right, so all of our simple website comparisons have concluded. I do have to say I somewhat regret opting to run the one-bit binary off of a phone because that took a little under 3 hours to generate this website At the highest total token count for this result, so it was an overall speed of 1.56 tokens per second. Perhaps let's not focus too heavily on the speed metric there um for that specific phone and that specific model. Nonetheless, we have our ternary version in the middle tab, which took 4 minutes and 23 seconds at a speed of 58.68 tokens per second on a 5090 mobile not using the additional draft model that they have for this. Then finally, we have the full-fledged full precision version, which ran at 28.73 tokens per second on a Blackwell RTX 6000 Pro, not the Max-Q like the full non-power limited one. And that was significantly less tokens, so I need to make sure everything's all set here with the sampling parameters. But nonetheless, I do have these all saved, so let's take a look at them. So, let's just start with the binary one as we want to I guess get a feel for the smallest first. That's honestly

not bad for a one-bit binary version. This is actually decently aesthetically pleasing. Yes, there's some oddities to it such as the randomly scattered around things. Trusted by 10,000 plus clients. That's quite impressive. We do have hover effects on the buttons. And did you see the way these metrics actually had effects in terms of when they reached their final number? That's actually pretty good. We do have hover effects on these cards. Steve's PC repair, 15 years expert, and that would ideally be a photo of Steve. Book an appointment, how we fix your PC, what our clients say, transparent pricing. Not bad. These pricing cards do look quite good. Ready to get your PC fixed. And we have a nice clean good-looking contact card. And the footer's very well done, too. All right, so that's That's kind of cool. I mean, like this entire thing was generated just using a mobile phone running the binary version of this model, which is quite awesome. Nonetheless, let's take a look now at the ternary one, which was like the middle tab, the middle intelligence to size one. Okay. Ooh. And we'll notice that throughout this, there going to be similarities because it's the same model, but there are differences in like how hard it goes. This one's only trusted by 2,000 clients as opposed to 10,000 plus, so this Steve is a smaller business. We do actually have some interactive particle effects in the background. Hover effects here and a more kind of neon like synthwave aesthetic, which I personally am a big fan of. Okay, our pricing cards Oh, no, these are just services and their specific prices. Not bad, good hover effects, and they all have some nice transparency to them. About us, okay, established 2009. All

right, I don't know why this just came to mind, but like a random like side note, back a long time ago, I used to think this EST meant like estimated, and I would always be like, how do they not know like the date these businesses were created? And I realized that it meant established. So, that clarified that for me. Just, you know, little um side note. Okay, we have a good-looking same simple repair process. I'm looking to see if there's a good aesthetically pleasing pricing card like we got with the binary version. We do have fake customer testimonials. Very good. Okay, no, and it just goes down to a contact card. Interesting though, there's no And the footer looks good and everything. Designed with love and coffee. The other one was designed with love and solder. Now, finally, and again, I do need to check the sampling parameters because this one was so suspiciously smaller in terms of overall generation length than the other two. Oh, goodness. Okay. So, this is the full precision one. Steve's PC repair, system optimized, initiate repair. Good hover effect. Service modules. Okay. And they all have a similar kind of thing. 2K systems fixed. So, this one has the same stats as the ternary one. Okay, now, something There's no way. Something has to be a bit off here because the full precision one should have not been this bad. All right, next up I have enabled thinking for all of these and I do believe that the behavior we saw where the full precision version of the model was actually a much shorter script. I think that's behavioral because we had thinking off. So, it is possible that the bonsai models as part of the way they're trained in order to

retain their intelligence are given like front-end examples that have a lot of aesthetically pleasing things in them and that could be attributed to why those were so much longer. Nonetheless, don't quote me on that, but I just wanted to give some at least thought on whether or not that was normal behavior or not. So, now with thinking on I would imagine we will begin to see hopefully some more difference in the favor of the full precision model here, but nonetheless, this is a bit more difficult and will give us some more interesting demos. This is of course a 3D subway station first-person shooter test. Now, the binary and ternary are both being run on this 5090 mobile laptop. So, if the speeds are not as fast, it's because this is handling both of these here at the same time. And then the full precision is being run on the 6000 Pro Box. So, we'll get our results at some point. I'm happy to see though and something I was a little worried about is whether or not the smaller models would be inclined to just overthink massively. Fortunately, we didn't see that. The reasoning was actually fairly concise and that's always definitely a risk. I do believe when Okay, I just saw you're dead. Okay, that's good. It's good to see that these didn't overthink massively. All right, let's start with the binary subway FPS. Okay, subway station survive the infestation. Now, the mouse disappears as soon as it gets on the page. Sometimes when this happens, we just need to find the enter station button and it will still let us in. So, we'll hold off on that. Let's just take a look at the ternary version model versions. Okay, subway station zombies. Same weird cursor

glitch issue. And the same complete failure of the start button actually doing anything at all. Okay, well, this is going quicker than I anticipated. Finally, let's try the the full precision version and hope that it's not a disaster like those. Are you Oh, okay. All right, so yes, this is makes a bit more Wow, this is quite good. This model is really like a just punches above its weight to a very high degree. At least in my testing. Okay, we're getting some lag pretty bad, but that's okay. This computer does have about like 20 gigs of VRAM hold up right now. Okay, so this is the only one that actually worked. Definitely showing us some differences. Actually, look at these like these models are not even that bad. This model never fails to amaze. There are rumors that there could be like a Qwen 3.8 coming out. Don't quote me on that, but that'd be really exciting for the local enthusiast among us. Good. All right. So, let's take a look and see what specific errors these are having. Okay, so that just has a syntax error and that was the ternary one. Let's check the binary one. That also has a syntax error as well. So, both of them just kind of weren't all there together and the 16-bit obviously was. All right, next up we're going to try some agentic coding with these models because I want to see what we get for that. And I think that's going to show a bit more insight beyond just the single file like zero-shot generations that we're doing, even though those are fun. However, I am going to base our agentic coding test just on the errors that these two models, the binary and ternary, have for

the subway FPS test. So, we're I'm going to give them the specific error that is showing up for either of their respective generations starting with the binary model where we have this uncaught syntax error and we'll see what it does. I need to change it. That is currently the ternary. So, if we go into models, I do have the configs all set up here. And I'm specifically not telling it in what script because it's in the dedicated directory which only the script is in. So, that's kind of an additional test is to see if it understands, okay, I need to fix this issue that's happening in the script that is in the directory I'm being run from within. Ignore the Q1 lingo there. It's not necessarily accurate for the way we're representing this. Found the issue on line 953. There's Okay, and then it changed it before. Yeah, all right. That would That's likely going to do it assuming that there are no more errors beyond this one. Okay, it's compacting a lot. It's running at 64K context length, but for now we're going to just assume because it does seem like it actually did remedy that one issue. Okay, so we have another one unfortunately. But it did fix the issue that was happening at least in that it's no longer appearing here. All right, so I've changed it so the context length is maxed out to 262144 and I'm opening it back up from the same directory within the same model and I'm giving it the new error that it has received here and we'll see. My fear is that we may just have a bunch of errors to get through going back and forth where it will fix one like it did before and then another one will pop up and then we'll have to fix that. But nonetheless, we'll give it some time to see if we can get this to a functional point. That was very quick.

So, let's refresh it. Okay, we do have another one and like I said, I do have some concern that it may just end up being a bunch of this, but we'll push it till we can't anymore. I will say even if we don't get this to a functional point, it is inspiring to see that it's seeing these errors and quickly fixing them and it's not getting stuck in loops or overthinking massively which I find to be pretty impressive. Okay? Okay, we're not getting any errors. Good. It got us to a point where we are actually in the game. Now, yes, it's not working fully and we're getting more errors now, but the thing is it got us past that first blocker, which I'm happy about. So, I'm going to continue just pasting these errors in. Ideally, I think the best thing to do would be to tell it like, "Okay, listen, I'm sick of pasting these errors in. I need you to build a little pipeline for yourself so you can autonomously pull these errors from developer tools, fix them, and then test again, and then fix, and then keep iterating until it doesn't give us errors anymore." No errors yet. Okay. So, it seems like this may be where we end with this. Where if we actually restart it, look up at the top right, and let me close the developer tools for now. You're going to see our ammo starts at 50, and if I turn the speaker up all the way, and I click, it will go down to 49, and we'll hear a sound. Unfortunately, then after that, nothing seems to happen. Nonetheless, it did take us to a point where it fixed all of the issues, and the ones that are left over are issues in actual like implementation of the game, and not things that are going to be shown to us just from the developer tool console

there. So, I'm satisfied with what I saw there, and the fact that it did actually handle a bunch of different errors from within the same thread, and didn't freak out and didn't start overthinking. It fixed them all one by one, which I think considering like what this is is rather impressive. All right, next up I have the ternary model loaded in through Open Code here, and this is with a 131 in change context length, because um getting it to the full one, I don't think will be necessary here. Additionally to that, it also would just tap out the card. I have neglected to actually tell it like, "Fix this error." I just ended up pasting it in, but it's the same situation where it's only in a repository with the specific script it created here. So, it will very likely understand, "Okay, I need to figure this out based off of what's in this repository or folder, I should say." Found the bug and fixed it. I would assume we'll have a couple more, probably. I need to remember that I moved the folders. Okay, nothing now. I'm done. >> [laughter] [snorts] >> Well, that was unpleasant. So, all right. I mean, yes, we Oh, wow. Okay. Uh yeah, I'm just going to I'm just going to paste that in because, quite frankly, I don't even have the words to describe the specific issue here without probably using language that is not appropriate for this platform. So, we'll see what happens here. Nonetheless, it did have one specific error and then it fixed it. And we did get the game working. So, a quicker and more complete result than we saw with the binary. Um also more jarring and stress-inducing. All right,

unfortunately, we've seemingly just hit a bit of an impasse here. Nonetheless, I was satisfied with what we saw because it did fix the one error that was blocking it from actually showing us the game, and the game was a bit more um playable than the one-bit one. So, it was This was very proper in terms of showcasing like the one-bit was just didn't really do anything. The ternary kind of worked, and then the full-precision one was arguably fantastic considering the size. So, uh interesting, and I wanted to throw in some agentic coding there just at least for the binary and ternary ones to see if they can handle open code, and they could. All right, so, the next thing I did is a bit different, but I know folks have often times, especially for models like this, wanted to know how they do with existing code bases. So, I gave them each access to a simple diffusion demo that I have where it's essentially a 3D model of a keyboard, and a small trained diffusion model predicts out of potential keyboard layouts like QWERTY, Dvorak, et cetera. I had to use that for my Gemini diffusion model video. So, the prompt here was essentially to give these each some questions about this specific code base in an isolated copy via open code with identical sampling parameters and ask them some targeted questions about this repo and then just grade how they did in terms of their quality and depth. So, apparently they all passed five of five. However, we do have some more fine-grain detail in terms of the actual specific questions that were asked and where things started to fall apart in terms of like wrong answers. So, let's just go through our per question details. So, question one was to describe the full training to browser pipeline and what happens if the

exported weights fail verification. Then we have our expected answer right here. Reports the failure in the HUD and the demo keeps running on exact analytic base. So, exactly there was a fallback there where it would just kind of fake what would happen were there a properly trained model and that is the answer we're looking for. Complete chain with correct line numbers also identified the separate fetch failure fallback path beyond the rubric. So, that is the full precision version of the Qwen 27B model. The ternary version complete chain including exact HUD failure message and no wrong predictions just a fallback called the JS engine a 200 line source comments as 100 trivial and then binary correct chain and threshold for the maximum error. Correct fallback least detail on what the UI reports. So, all of these did actually get that correct, which is cool to see. So, question two, exactly how many training sequences, what are they and how is a batch of 64 built? The expected answer is exactly four sequences, the 40 character layout strings sampled with replacement via torch random integer to 64 rows. Each row independently gets up to this per position masking with a probability of this masked position enforced. So, our BF16 got quoted all four exact strings, described clamp subtly wrong. The clamp creates a point mass here, not uniform, only modeled to make that claim precisely enough to be wrong. Interesting. Ternary, quoted all four exact strings, noted one mass guard and one T waiting, didn't mention the clamp. Okay. Then again, these are I mean, this is not necessarily my favorite way of measuring things, but it is important for models like these just to see. Binary, named the four layouts, didn't quote the strings, got with replacement sampling, mass guard. Okay. So, they all

overall got that kind of correct, which is cool, but it was interesting that it mentioned the full precision one only model to make that claim precisely enough to be wrong. Question three, why is probs for recomputed inside the commit loop? What breaks without it and where does the JS handle it? Expected ancestral sampling, each committed token must condition subsequent value sampling. The model is bidirectional, refusing steps hard marginals, let's position sample from incompatible layouts, incoherent output and the demos exact posterior zeros out. JS counterpart and then we have some additional info right here. BF16, textbook answer, correct citations. Good, named commit key explicitly. Ternary, correct mechanism and named commit key uniquely added that disk cache is keyed on committed state, so self invalidates. True and beyond the rubric, but cited lines 304 for commit key and line 217 elsewhere, wrong locations. Then binary, correct concept with a concrete two-position example, identified the JS mechanism, but never named commit key. So, we see different levels. Interesting, the ternary one there seems to be like fairly robust, even if it got some line numbers wrong. So, question four, every mechanism that keeps mask out of the generated output and then the expected, we have a bunch of Python information here and then what specific like math would cause that to happen. Skips mask ID in the soft max and only enumerates real chars real characters. Bonus the analytic base path can only propose layout characters by construction. BF16 all required guards with correct lines plus the analytic path bonus cleanest answer of the five questions. Ternary both required guards correct extra claims about top of commit flow correct

in substance but wrong line numbers again. Interesting that it seems to be a consistent thing here that it's getting the wrong line numbers. Then finally binary both required guards correct but credited posterior from is guard that function computes the layout posterior not character distributions. The analytic character path lives in get distributions misattribution. Okay. Then finally question five Why can the layout posterior panel disagree with hover tool tips when the net is active? Expected the panel always computes the exact analytic base posterior from as ground truth. Tool tips ghosts use get distributions which switches to the train net. The disagreement is the point comparing the net equals base. All right. So BF16 complete correct citations and articulated the layout level versus character level distinction plus what divergence reveals. Ternary complete correctly traced the net base commit comment to sample.py. Good framing of learned approximat approximation versus exact reference. Binary correct and concise cited the design comment line 90 actually 89 but trivial. Okay. Pretty interesting. They actually seem to perform fairly strong on this. Now this is not a super complicated code base. I mean if we look at it right here it is in the diffusion folder. We can see there's not too much to it but it is a tiny little diffusion model trained to predict the layouts of a keyboard based off of like potential ones that appear. Then it re-masks and then it makes new guesses based off of what's been unmasked and things like diffusion. So it's not necessarily like a super trivial like 3 JS scene or front end or something of the sort. So that's cool to see. Then we have some information about how they worked well. Read-only compliance, so

this wrote answer.txt into the folder. I do believe the binary one did, which you know, it happens. Avoided dumping weights.json, good. Citation precision high, line accurate, medium right function several wrong lines, low mostly file level. Verified factual errors, one minor clamp described as uniform, three minor wrong line numbers, two misattribution plus wrong line plus instruction violation, which would be writing the answer to the directory. So, takeaways, all three models demonstrated genuine cross-file comprehension. Every substantive substantive claim about how the system works was correct from all of them, including the subtle ancestral sampling point that requires connecting a Python comment to its JavaScript counterpart. The quantization gradient showed up not as wrong understanding, but as eroding precision. Full precision was line accurate and found bonus mechanisms. The two-bit model kept them, so the ternary kept all the insight and contributed the best original observation, but fabricated specific line numbers. The one-bit model, so the binary, stayed correct at a coarser altitude and was the only one to break the read-only instruction. That ordering matches PrismML's own benchmark deltas 100 to 94 to 89.5, far better than the earlier website tested. So, those deltas being the comparisons that they have in quality degradation from the full precision version to the ternary to the binary. So, that was actually kind of interesting, I think. Hopefully you found it interesting. I found it interesting. So, next up for the final thing, we're just going to do something a little lighter on the brain, and that is going to be a front-end web design test for the Slap Ass Watch Co company. This must create a good front-end, but additionally to that, it needs to create a 3D model of the watch and then have

that with a cinematic panning shot in the hero section, something like you'd get with the KeyShot program. So, as usual, we have the binary running in the leftmost pane, the ternary running in the center, and then the full precision one running on the right and we'll see what we get for some simple front end. Are you kidding me? Then let's see if we can get this back up and running. All right, good. The good thing is that this will be much quicker now because it's not running concurrently with the ternary version. So it should take only five or six minutes. With that, let's just take a look at what we have so far. So we'll start with the full precision result, okay? This is This is genuinely like this model's a freak. Well, we're going to notice there are some Oh, actually so it does have all of the hour markers in the correct spot. It's just these two center ones are and it's a counterclockwise watch, but that's okay. Those, you know, those exist. This is actually really quite good though. If you've seen some of our recent model tests in doing this task, this goes toe-to-toe with models that are significantly, significantly larger than this. Crafted for those who define time. It even put it here in this section. I don't know that I've ever actually seen that. Then we have the collection with two different ones in different colors. I love it. We have the Meridian and the Aethon, Ethon. Don't ask. These are very expensive and the difference in price between the two is quite significant. Oh, that's why cuz this has a uh special movement to it. Interesting. All

right. Oh, okay, there's more. Each Slap City Time Piece is a dialogue between the past and the future. Very good. Then we have a nice, well-made footer, 2026, Swiss made since 1984. Very well done. Now let's take a look at our ternary result. Okay, so this This is definitely going to highlight some of the differences in raw capability between the versions of the model and the original. I mean, yes, there's elements of similarity here, but at the same time Uh yeah, so it it you know, self-explanatory is the word that comes to mind. All right, good. This will hopefully finish sooner than later if it doesn't freak out again. And now we have our binary result to compare. So, here's the binary result. Yeah, all right. And this definitely it shows us the descent in capability across the different quantizations or whatever you want to call it. Though I will say that the binary one at least had like a proper follow-up section. The ternary one was quite troubled. The binary one also quite troubled, but they had different strength areas. So, overall that's probably going to conclude this test. I wanted to do something that was kind of more scientific where we had proper side-by-side comparisons for the binary, the ternary against the full precision version of this model as well because that'll show us some true capability. And I wanted to do a gen decoding, I wanted to do code base understanding, and then also some fun visual comparisons like that Subway game that nearly gave me a heart attack. So,

that's probably going to conclude this. I don't have too much to say. I think overall these models are incredibly incredibly impressive considering that they do have such intelligence retained with a massive massive reduction in size. I think the thing that really stood out was probably the binary model running in open code giving it those errors consistently back and forth until it fixed all of them. The game never really ended up working properly, but it did get rid of all the errors that were blocking us from even finding that out. And I think that's pretty impressive. They didn't get stuck in thinking loops, they didn't freak out. Well, the binary the ternary one kind of just got stuck trying to fix some of the further errors in its Subway game result, but still, I mean, it's just cool to see capabilities being retained at such reductions in size. And this is very exciting, especially for the local AI enthusiast. The 27B Qwen even at like a Q8 or something, is a very, very potent and capable local model and it kind of makes me laugh sometimes when I see folks saying like local AI is useless and it's like mhm Have you used one to like do anything? So, with that that's probably going to conclude it. I wanted to test this. There's a lot of interest about these models and for darn good reason. So, I do believe there were some rumors that they may be working on doing this to a significantly larger open weights model. That would be very, very exciting to see and test. And yeah, so with that, that's going to wrap it up. If you have any questions, please feel free to leave them in the comments. Stop telling me to review Kimmy K3 because one, it's not out as of the time of me speaking this and two, of course I'm going to do it when it gets out. So, with that thanks for watching and take care.