"litellm routes LLM calls across providers and translates between message formats. That core is buried under 100k+ LOC"
Seriously anybody considering 100k+ LOC not a bloat? You made my day!
Let's just say the author's and my definition of bloat is not the same. Full disclosure, I'm the guy who reimplemented etcher (over 400Mb) in a mere 300Kb, Capstone (over 1Mb) in only 66Kb and who compressed LPC charactersheets (over 700Mb) into 4Mb. That's my interpretation of "non-bloated".
No, you forgot about the dependencies (others said it to be 700Mb). And 2,900 LOC is still way too much for handling a remote API call, especially in a high level language such as Python where the biggest part of the task is delegated to separate modules.
On the contrary, the readme for this project, `litelm`, is contrasting with the bloat project, `litellm`. This project subty deboats an L.
The bloat (or featuritis) project has the 700mb and 100k+ LOC, this de-bloat has 2k LOC and specifies its only two deps ones most people want as deps (although httpx should be swapped to its successor).
So this response is off base, the 700Mb isn't forgotten, it's been dropped.
I've also implemented a SIMD accelerated, but case in-sensitive (*) search algorithm as an stb-style single header library, also based on Wojciech Muła's work.
See the performance comparison in the README, it's about 6 times faster than libc.
(*) - full UTF-8 support, but only works for UNICODE codepoints where the UTF-8 encoding lengths are the same for lowercase and uppercase. There are only 27 out of 40576 pairs which aren't handled (listed in the README).
> UNICODE codepoints where the UTF-8 encoding lengths are the same for lowercase and uppercase.
This very same property got me to post this [1], which sent me down the rabbithole of learning about Unicode in earnest and building my Unicode tool. Which may have an initial release some time this millennia... maybe.
Sometimes there's an offset (like with Latin, +/- 32), sometimes lowercase and uppercase is interleaved (eg. Latin extended), and sometimes they are in totally different blocks simply because they forgot to add both letter cases at once... (the distance of the codepoints affects UTF-8 encoding difference the most).
I've also paid attention to optimize the most common case where both UTF-8 encodings' first bytes are the same (that's 40508 pairs out of 40549). But no escape, it must handle the remaining 41 pairs specially in a slower code path, which would not be needed at all should UNICODE guys did their homework better.
One of my favourite ones in the post I linked is the "ff" ligature. It uppercases to "FF", meaning in UTF-8 it goes from one encoded character to two, and from 3 bytes total to 2 bytes total.
Lots to read about here for those interested (and that's without getting into `Casefold`, `NFKC_Casefold`, simple vs complex case mappings, the CLDR, etc.):
> Just wait until they manage to apply it to physical goods like cars and dishwashers.
This already happened... It's called subscription or mortgage loan.
Most households don't have that kind of money at once, they are already forced into a loan with regular payments. This means not the buyer but the bank owns the car until the last penny is paid.
> Especially getting rid of physical second hand sells/buys will force consumer to buy the games straight from Sony
That's what lawyers and other corporate drones think, but they are plain wrong.
The only reason why people want to buy a copy from second hand is because they can't afford the price of a new one. In reality these people will never ever buy straight from Sony, simply because it's too expensive for them. Simple as that. They much more likely to turn to free pirate copies instead.
Yeah, okay, I made the same mistake as Sony. I wrote "buy", but what I meant was "spending money" in a general sense (regardless if it's buying ownership or paying a license fee). Second hand customers simply can't afford (or willing to pay) the price of a new copy. Trying to force these people to the Sony shop is a really bad move and won't work.
Otherwise you're right, it's absurd that license fee is the same as the price of an owned copy.
> What’s the most dangerous thing that’s happened with an LLM so far?
That it's built solely on "trust me, bro"?
> right now I am not concerned at all.
You should be. There's no scenario where this ends well: if AI labs succeed, we all will loose our jobs. If they fail, then the bubble bursts. Economic crisis is inevitable either way, and that's just the tip of the iceberg.
> 14.5. Class Action Waiver.
> YOU AND THE SONY ENTITY WITH WHICH YOU HAVE A DISPUTE AGREE THAT ARBITRATION WILL BE CONDUCTED ONLY ON AN INDIVIDUAL BASIS AND NOT IN A CLASS OR REPRESENTATIVE ACTION [...]
> Regardless, these sorts of things have been fought before, over and over.
I'm no lawyer, but IMHO they probably will reply that Sony has indeed violated CA. AB 2426 (effective since 01-jan-2025) and that Sony illegally tried to restrict customer rights in the first place, as per McGill v. Citibank https://law.justia.com/cases/california/supreme-court/2017/s...
No AI companies were able to make profit so far, and unemployed masses surely won't buy expensive ChatGPT subscriptions.
Will AI labs make profit from AI using companies? Hardly, unemployed masses can't and won't buy their products either, therefore they won't be able to afford even more expensive ChatGPT Enterprise subscriptions. (For crying out loud, even big corps like Uber can't pay all their AI bills.)
And if AI labs have no profits, how are they supposed to pay the hyperscalers for computing capacity? They will run out of investor money pretty soon.
And if hyperscalers can't rent out their data centers to AI labs, how are they supposed to pay for the electricity (gas/diesel/etc.) and water bills and repay their already enormous debts?
I honestly don't see how replacing all workers with AI could be profitable at all.
A few are deciding to take a massive, extremely risky bet on behalf of the entire world population. And of course they are the ones insulated from any potential disaster
Meta is planning to use their own AI to replace their workers. They are spending hundreds of billions of datacenters. If they cut 30,000 workers thats around 15 billion a year in savings. Once their own workers are replaced they plan to sell their AI agents to small businesses for use on their platforms.
"Without the Bloat"
vs.
"litellm routes LLM calls across providers and translates between message formats. That core is buried under 100k+ LOC"
Seriously anybody considering 100k+ LOC not a bloat? You made my day!
Let's just say the author's and my definition of bloat is not the same. Full disclosure, I'm the guy who reimplemented etcher (over 400Mb) in a mere 300Kb, Capstone (over 1Mb) in only 66Kb and who compressed LPC charactersheets (over 700Mb) into 4Mb. That's my interpretation of "non-bloated".
reply