部署开源大模型要多少显存？4090能跑70B吗？

24G跑7B其实有点浪费，我拿同款卡跑14B的Q4_K_M大概10G出头，速度能到25 token/s左右，代码补全够用了。70B想都别想，量化再狠也得40G+。4bit量化对代码任务影响不大，但长上下文确实容易崩，你试试把ctx砍到8k，效果会稳很多。llama.cpp真香，vLLM那种主要是为了高并发，单机玩真没必要。

4090跑70B其实挺吃力的，我试过Q4_K_M的GGUF，速度大概就5-8 token/s，代码补全凑合能用，但长上下文确实容易慢到怀疑人生。量化到4bit对代码类任务影响不大，反而文档总结偶尔会丢细节，建议拿7B或14B专门跑总结。vLLM对显存管理更高效，但24G上70B还是得配合量化，而且主要吃内存带宽，体验未必比llama.cpp好。我最后是双开：7B跑对话，14B跑总结，省心不少。

24G跑70B基本没戏，除非上4bit量化加超长上下文裁剪，但那个输出质量做代码补全勉强够用，文档总结就有点飘了。llama.cpp的GGUF确实省显存，但速度比vLLM慢不少，尤其长上下文时token生成肉眼可见地卡。vLLM对显存要求高是因为要留KV cache，但吞吐量上去了，单卡24G建议还是老老实实玩14B以内的模型。量化到4bit我个人感觉代码任务掉点不明显，但自然语言生成会变啰嗦，建议拿同模型不同量化级别跑几个测试集对比下再定。

4090 24G跑70B其实挺尴尬的，量化到4bit大概需要40G左右显存，24G只能靠llama.cpp的offload到内存硬扛，速度会掉到每秒几个token，体验基本就是打字机。我自己试过Qwen2.5-72B的Q4_K_M，开8层offload到CPU，上下文拉到8k就明显卡顿，代码补全这种需要连续输出的场景基本没法忍。

建议别死磕70B，试试32B级别的模型，比如Qwen2.5-32B或者CodeLlama-34B的量化版，24G吃满能全offload到GPU，速度能到15-20 token/s，体感就完全不同了。llama.cpp的GGUF格式确实省显存，但4bit和8bit的差距在代码任务上挺明显的，尤其是长上下文时，4bit偶尔会丢括号或变量名，写文档还行，补全代码容易翻车。

vLLM和TGI那些框架主要优化高并发吞吐，单卡跑反而更吃显存，因为要做KV cache预分配，建议本地单用户还是老老实实llama.cpp或者ollama。另外量化损失这事得分模型，Qwen系列对量化比较皮实，我测试下来4bit和8bit的困惑度差距不大，但Llama-3就敏感些，尤其数学和逻辑推理会掉点。

补充个偏方：如果只做代码补全，试试DeepSeek-Coder-33B的Q8，效果比70B的Q4好很多，因为代码任务吃的是清晰度不是参数规模。上下文爆显存的话，可以调低llama.cpp的ctx大小到4k，然后配合外挂的检索或者分段落总结，别指望单模型一口气吞整篇文档。

24G跑70B得靠4bit量化加长上下文裁剪，代码补全凑合，但文档总结容易逻辑稀碎。

24G跑70B其实挺极限的，但也不是完全没戏。我试过用llama.cpp的Q4_K_M量化，70B大概要40多G，得靠mmap把权重塞到内存里，CPU+GPU混合推理，速度慢到怀疑人生，大概就2-3 token/s，做代码补全勉强能忍，文档总结就别指望了。真正靠谱点的路子是上8bit或者Q5量化的小一点的模型，比如32B的Qwen，24G刚好能塞下，速度能到10 token/s以上，质量损失体感不大。vLLM和TGI主要是为了高并发吞吐设计的，单卡本地玩反而更吃显存，因为要预留KV cache，而且它们对量化支持不如llama.cpp灵活。你这个需求其实不如考虑下14B级别的模型，比如Qwen2.5-14B-Q4，配合长上下文窗口的优化，4090跑起来很轻松，输出质量做代码补全完全够用了。对了，上下文爆显存的话，可以试试llama.cpp的--ctx-size参数手动限制，虽然会截断，但比直接OOM强。量化到4bit对代码任务影响确实有，主要在复杂逻辑推理和长文本一致性上，但日常用感知不明显。

4090跑70B得靠4bit量化，llama.cpp比vLLM省显存但速度拉胯，代码补全7B其实够用了。

24G跑70B基本得靠4bit量化，llama.cpp的GGUF Q4_K_M能用但速度也就10来token/s，写代码凑合，长上下文确实容易爆。vLLM那类框架主要吃显存优化但不适合单卡低显存，反而更推荐带offload的Ollama。量化到4bit对代码补全影响不大，文档总结偶尔会丢细节，建议拿Qwen2.5-14B的Q5_K_M试试，比硬上70B实用多了。

4090跑70B基本告别流畅了，我试过Q4_K_M的GGUF，生成速度大概就4-5 token/s，写个文档还行，代码补全卡得没法用。vLLM确实吃显存，24G连14B的fp16都费劲，老老实实llama.cpp吧。4bit量化写代码影响不大，但长上下文确实会掉智力，建议把context window压到8K以内。你要是主要做代码补全，不如试试DeepSeek-Coder 6.7B的Q5量化版，性价比比硬冲70B高多了。

4090跑70B基本得靠4bit量化，llama.cpp的GGUF确实能塞进去，但生成速度大概就几token每秒，当玩具行，干活急死人。vLLM那类框架主要是优化高并发推理，单卡低延迟场景反而没优势，内存占用也更狠。代码补全这种任务建议试试Qwen2.5-Coder-7B的Q4_K_M版，专门调优过，效果比通用70B瞎折腾强。上下文爆显存的话，把ctx长度砍到4k以内，或者开KV cache量化，体感损失很小。

4090跑70B就别想了，量化到2bit都够呛塞进去，还得留余量给上下文。7B或14B的4bit量化才是你的甜点区，Q4_K_M效果损失很小，日常代码补全基本感觉不出来。llama.cpp确实省显存，但并发和长上下文不如vLLM，vLLM吃显存换速度，24G跑14B 4bit大概能撑8k上下文。建议先拿14B的GGUF试水，别硬上70B。

4090跑70B基本别想，4bit量化也得分片才勉强，单卡还是老实玩32B以内吧。

4090跑70B基本别想，光权重4bit量化也得35G往上，除非上CPU+GPU混合推理，那速度你肯定受不了。7B量化版爆显存多半是上下文设太长了，试试llama.cpp把KV cache也量化一下，能省不少。vLLM确实吃显存更凶，它预分配机制摆在那，24G跑13B都够呛。4bit质量损失日常总结和补全其实感知不强，但代码补全建议用Qwen2.5-Coder的GPTQ，比GGUF快。