I'e been using their models pretty much daily for the past 2 months to work on the codebase of a very complex B2B2C platform written in an unusual functional language (F#) with an angular frontend.
I also use Claude premium daily for another client, and i use Codex. and i can tell you that GLM5 is at this point much more capable than Claude and Codex for complex backend end work, complex feature planning, and long horizon tasks. One thing i've noticed is that it is particularly good at following instructions and guidelines, even deep into the execution of a plan.
To me the only problem is that z.ai have had trouble with inference : the performance of their API has been pretty poor at times. It looks like this is an hardware issue related to the Huawei chips they use rather than an issue with the model itself. The situation has been substantially improving over the past few weeks.
GLM5.1, GLM5-Turbo and GLM5v are at this point better than Opus, Codex, Gemini and other claude source models. We have reached a major turning point. To me, the only closed source model still in the game is codex as it is much faster at executing simple tasks and implementing already created plans.
Try GLM5v for your PDF work, it's their last generation vision model that has been released a couple of days ago.
Does anyone have inside info on what these Huawai chips look like? I know Google has a Torus architecture unlike Nvidias fully connected one. Maybe it’s a similar architectural decision on the huawai chips that leads to bottlenecks in serving?
>For AI computing, the Atlas 950 SuperPoD, powered by UnifiedBus, integrates 64 NPUs per cabinet and can scale up to 8,192 NPUs, delivering superior performance for large-scale AI training and high-concurrency inference.
Plenty of other providers that offer much faster inference on GLM-5.1. Friendli, GMICloud, Venice, Fireworks, etc. And can be deployed through Bedrock already as well. Will probably be available generally in Bedrock soon, I would guess.
better than Opus? not even close. after struggling thru server overload for the past couple hours i finally put 5.1 thru the paces and it's....okay. failed some simple stuff that Sonnet/Opus/Gemini didn't. failed it badly and repeatedly actually. this was in typescript, btw. not sure if i'll keep the subscription or not
I appreciate that it's not working for your use case but it's unfortunate that you dismiss the experience of others. And i am not chinese, I am European. Thanks for your feedback anyway.
I tried Gemini 3.1 pro once to implement a previously designed 7-phase plan.
it only implemented a quarter of the plan before stopping, the code didnt even compile because half of the scaffolding was missing. it then confidently said everything was done.
Codex and GLM didnt have any issue following the exact same plan and getting a working app. So I would argue Gemini is the failure here.
I know my use case and my personal experience :) i am not trying to pretend that it is the best in benchmarks, just sharing my experience so people know that some folks are having a very good experience with GLM models, compared to the competition.
My only goal is to encourage people to try it out so they can see if it moves the needle for them, because there are fair chances that it will. I am not trying to start a flamewar or something.
It’s not a flame war, and you’re not just sharing your experience and encouraging others to try it out.
You’re making a claim, and I’m pointing out that it’s unsubstantiated and not consistent with any other source of data, including that internal to the company that makes the model.
I hope you can see that that’s different than saying it’s worked well for me
Sometimes we STEM folks are way too rigid, I obviously meant "IN MY OPINION, GLM models are at this point superior to...".
I do not think that anyone who read my comment understood it differently. But I grant you this point, this is just my opinion based on my personal experience not the result of a scientific study.
Once this is said, i wasn't submitting a scientific paper for preprint, just posting my opinion on an internet forum.
Not sure why you are making such a big deal out of it, especially for something for which people can decide within minutes if it works for them or not. And I haven't seen you nitpick on other people saying that all Chinese models are garbage incapable of doing even the most basic task, without quoting any study. This kind of scrutiny tends to be one-sided.
Edit: and regarding what the z.ai team is saying about their models, just check their Discord and the articles they link there. They themselves say that their latest models have leading performance on a number of aspects. It is misleading to suggest that the authors of the model are not proudly saying that their models have best in class performance.
Except it does not work that way in the US, you can freely incorporate in any state without worrying about this kind of tax drama. The EU really needs to improve the integration of their single market, as this is precisely the kind of barrier preventing people from exploring what other EU states have to offer.
It does not need to be all or nothing though. It simply needs to be true for a large enough number of people, to create an extremely valuable market.
We are over 8 billion on earth, even if as little as 1% of the population rely on it directly or indirectly due to some form of oppression real or perceived due to political opinions, a long investment thesis on bitcoin can make sense.
I am not a bitcoin holder once this is said. Arrived at the party too late IMHO, and i have better investment options for now from a risk-adjusted perspective.
However if i had more cash to invest than i know what to do with, i'd definitely take a long position on bitcoin.
I think you are making a big deal out of nothing: today adoption is tiny but there isn't any coordination problem. Anyone wanting to buy or sell bitcoins, even for very large amount has no problem doing so.
As adoption increases, liquidity (which may be what you allude to when you talk about coordination) will be even better.
I'd also note that facilitating liquity can indeed be a complex problem, but there are people specialized in making money out of it and who therefore have an incentive to continually keep the market liquid, read about "market makers".
The key thing is that on freebsd you do not risk bricking your system by installing a port. Even though this guarantee has become less true with PkgBase
> The key thing is that on freebsd you do not risk bricking your system by installing a port
What specifically are you trying to cite here? Which package can I install on Debian or Fedora or whatever that "bricks the system"? Genuinely curious to know.
I was referring to the need to be careful to not modify/update packages also used by the base system. Since all packages are treated the same on Linux, you often can't tell which package can put you in trouble if you update it along with the dependencies it drags with it.
This kind of problem happens frequently when users add repositories such as Packman on Linux providing dependencies versions different from the ones used by the base system of the distro.
Experienced people know how to avoid these mistakes, but this whole class of problem does not exist on FreeBSD.
> Since all packages are treated the same on Linux
This is no longer the case in "immutable" distros such as Bluefin/Aurora, which uses ostree for the "base" distro, while most other user packages are installed with homebrew. Nix and Guix solve it in a very different way. Then there's flatpak and snap.
A lot of poor *BSD advocacy likes to deride Linux for its diversity one moment, then switch to treating it as a monolith when it's convenient. It's a minority of the users for sure, but they naturally make an outsized share of the noise.
Done the same since 2018 circa, never looked back.
For a while even used it on the desktop, but was too much trouble due to specific tools we need that weren't supported properly. so we're using Linux on the desktop.
FreeBSD is stable, lightweight, gets out of the way, and without drama.
What you are looking for is called F#. You get native interop with C# and access to all .NET/C# libraries as a bonus. We use it as a daily driver for a complex B2B2C cloud platform.
Yes you are right, it does not properly support NativeAOT yet.
But it isn't a need for most use cases, unless you want to do mobile development and meet app store policies. But even then, mature F# frameworks like Fable transpile your F# code to React & Cie.
Since storage is a critical component, I closely watched it and engaged with the project for about 2 years circa as i contemplated adding it to our project, but the project is still immature from a reliability perspective in my opinion.
No test suite, plenty of regressions, and data loss bugs on core code paths that should have been battled tested after so many years. There are many moving parts, which is both its strength and its weakness as anything can break - and does break. Even Erasure Coding/Decoding has had problems, but a guy from Proton has contributed a lot of fixes in this area lately.
One of the big positive in my opinion, is the maintainer. He is an extremely friendly and responsive gentleman. Seaweedfs is also the most lightweight storage system you can find, and it is extremely easy to set up, and can run on servers with very little hardware resources.
Many people are happy with it, but you'd better be ready to understand their file format to fix corruption issues by hand. As far as i am concerned, i realized that after watching all these bugs, the idea of using seaweedfs was causing me more anxiety than peace of mind. Since we didn't need to store billions of files yet, not even millions, we went with creating a file storage API in ASP.NET Core in 1 or 2 hours, hosted on a VPS, that we can replicate using rsync without problem. Since i made this decision, i have peace of mind and no longer think about my storage system. Simplicity is often better, and OSes have long been optimized to cache and serve files natively.
If you are not interested in contributing fixes and digging into the file format when a problem occurs, and if your data is important to you, unless you operate at the billions of files scalability tier Seaweedfs shines at, i'd suggest rolling your own boring storage system.
I also use Claude premium daily for another client, and i use Codex. and i can tell you that GLM5 is at this point much more capable than Claude and Codex for complex backend end work, complex feature planning, and long horizon tasks. One thing i've noticed is that it is particularly good at following instructions and guidelines, even deep into the execution of a plan.
To me the only problem is that z.ai have had trouble with inference : the performance of their API has been pretty poor at times. It looks like this is an hardware issue related to the Huawei chips they use rather than an issue with the model itself. The situation has been substantially improving over the past few weeks.
GLM5.1, GLM5-Turbo and GLM5v are at this point better than Opus, Codex, Gemini and other claude source models. We have reached a major turning point. To me, the only closed source model still in the game is codex as it is much faster at executing simple tasks and implementing already created plans.
Try GLM5v for your PDF work, it's their last generation vision model that has been released a couple of days ago.
reply