News for hackers. Stuff that matters.
Re:Bagel: The Open-Source Unified Multimodal Model by mnky9800n on Monday May 26, 2025 @03:09AM (#44094786)
I couldn’t find it, what are the hardware expectations for bagel?
Re:Bagel: The Open-Source Unified Multimodal Model by gunalx on Monday May 26, 2025 @03:32AM (#44094927)
If you follow the hugginface link at the bottom you get to te actual model. Here https://huggingface.co/ByteDance-Seed/BAGEL-7B-MoT

It seems to be 7b, but like with other new architectures expect to not be able to run it quantizised.

Re:Bagel: The Open-Source Unified Multimodal Model by tonii141 on Monday May 26, 2025 @03:34AM (#44094936)
If the model uses FP16 precision and has 7 billion active parameters, it would require approximately 14 GB of VRAM. I didn't read the paper.
Re:Bagel: The Open-Source Unified Multimodal Model by sfphoton on Monday May 26, 2025 @04:02AM (#44095105)
How can you calculate required VRAM from precision and parameter number?
Re:Bagel: The Open-Source Unified Multimodal Model by a_t48 on Monday May 26, 2025 @04:05AM (#44095126)
A float16 is 2 bytes. 7B * 2 bytes = 14GB. I can't say if that's an accurate number, but that's almost certainly how tonii141 calculated it.
Re:Bagel: The Open-Source Unified Multimodal Model by sfphoton on Monday May 26, 2025 @04:11AM (#44095157)
Oh, so FP16 means FloatingPoint16? I'm glad to learn something today, thanks!
Re:Bagel: The Open-Source Unified Multimodal Model by NitpickLawyer on Monday May 26, 2025 @04:28AM (#44095252)
Rule of thumb is parameter_count * precision. Precision can be anything [32,16,8,4] bits. 32bits is sometimes used in training (although less now I guess), and rarely in inference. For a while now "full" precision is 16bit (fp16, bf16), fp8 is 8bit, int4 is 4bit, and so on. Everything that's not "full" precision is also known as quantised. fp8 is a quantised version of the "full" model.

So quick napkin math can give you the VRAM usage for loading the model. 7b can be ~14GB full, 7GB in fp8 and ~3.5GB in 4bit (AWQ, int4, q4_k_m, etc). But that's just to load the model in VRAM. You also need some available VRAM to run inference, and there are a lot of things to consider there too. You need to be able to run a forward pass on the required context, you can keep a kv cache to speed up inference, you can do multiple sessions in parallel, and so on.

Context length is important to take into account because images take a lot of tokens. So what you could do with a 7b LLM at full precision on a 16GB VRAM GPU might not be possible with a VLM, because the context of your query might not fit into the remaining 2GB.

Re:Bagel: The Open-Source Unified Multimodal Model by Havoc on Monday May 26, 2025 @04:48AM (#44095366)
Realistically you probably just want to look at the file size on huggingface and add ~2 gigs for OS/Firefox tabs and and a bit for context (depends but lets say 1-2)

The direct parm conversion math tends to be much less reliable than one would expect once quants are involved.

e.g.

7B @ Q8 = 7.1gb [0]

30B @ Q8 = 34.6gb [1]

btw you can also roughly estimate expected output speed too if you know the device memory throughput. Noting that this doesn't work for MoEs

Also recently discovered that in CPU mode llama.cpp does memory mapping. For some models it loads less than a quarter into memory.

https://huggingface.co/TheBloke/Llama-2-7B-GGUF/tree/main

https://huggingface.co/TheBloke/LLaMA-30b-GGUF/tree/main