部署本地大模型显存总不够，量化后效果又变差怎么办？

说实话你这需求我太懂了，3090跑13B本来就是个尴尬区。我建议别死磕量化了，直接上7B的Q4_K_M或者Q5_K_M，代码生成能力比13B的INT8强不少，而且长文本不会卡。另外试试llama.cpp的flash attention，能省不少显存，还能提速。

试试4bit的AWQ配vLLM，代码场景比INT8稳，13B留7B真没必要，量化调参更值。

试试4bit的AWQ配合vLLM，代码场景比GPTQ稳，13B砍到7B其实日常够用。

说实话你这情况我也踩过坑，3090跑13B确实尴尬，我最后是直接换7B的AWQ 4bit，代码生成质量比硬上13B的int8强多了。量化这事儿别死磕，试试最近出的llama.cpp的IQ4_XS，比GPTQ在代码任务上稳定不少。另外长文本卡的话，可以调下ollama的num_ctx参数，别让它默认吃满内存，留点给系统缓存。

24G跑13B FP16确实卡在临界点上，我之前用4090也遇到过这问题。别急着上INT8，可以先试试4bit的GPTQ配合vLLM的--quantization参数，实测代码生成比AWQ稳不少，主要是推理时显存碎片化控制得更好。ollama那个长文本卡顿大概率是context窗口开太大，把num_ctx调回4096会好很多，但代码任务建议至少留8192。至于换7B，我觉得写代码场景13B量化后比7B原版强太多，7B写复杂逻辑经常断片，你量化调参花的时间绝对比换模型值的。另外可以试下ExLlamaV2的EXL2格式，同4bit下比GPTQ再省10%显存，而且支持动态量化，长文本吞吐比ollama高不少。最后个小技巧，把KV cache量化成8bit，显存直接省出2-3G，效果几乎无损，这在官方文档里不显眼但贼好用。

我也是3090，试了一圈下来感觉量化和换小模型都得搞，但得看场景。写代码我建议直接上Q4_K_M的7B，配合llama.cpp的flash attention，长文本卡顿会好很多；查资料这种对精度要求不高的，13B的AWQ反而比7B原版强。另外你可以试试把context窗口调小点，或者用vLLM的continuous batching，比ollama省显存。不过说实话，真对代码生成要求高，不如用API，本地跑图个隐私和折腾乐趣得了。

说实话我跟你情况差不多，后来发现整个AWQ 4bit加vLLM的吞吐提升比单纯换小模型靠谱，代码任务用Qwen2.5-Coder-7B的量化版反而比13B原版更稳。你如果长文本卡，试下把max-model-len调低到8192，24G跑7B绰绰有余，生成质量和延迟能兼顾。至于调参，除非你特别执着于某个模型，否则真不如换个小参数但新架构的，省心很多。

说实话你这情况我太懂了，3090跑13B不上不下的。我后来把13B换成7B的Q4_K_M，配合vLLM做前缀缓存，代码生成速度反而上去了，质量差距在写脚本这种任务上真没那么明显。你如果特别在意效果，试试Qwen2.5-Coder-7B的AWQ版本，比通用模型强不少。另外长文本卡的话记得把context窗口调小点，或者用外挂RAG，别硬喂长上下文。

[换个风格]我最近用llama.cpp的量化版跑7B，把KV cache换成FP16的，效果比全INT8好一截，速度也没慢多少。你既然有24G，其实可以考虑用5bit或者6bit量化，比4bit质量高很多，显存也就多占2-3G。别纠结13B了，7B的Qwen调好提示词，写代码真够用，关键是别用那些一刀切的量化方案，自己多试几个粒度。

24G跑13B FP16确实很极限，我之前用4090也遇到过类似问题。说实话，量化带来的损失在代码场景特别明显，因为语法错误这种是灾难性的，不是“风格变差”能糊弄过去的。我的经验是，如果非要本地跑，优先考虑4-bit的AWQ配合vLLM的投机采样，比GPTQ在长文本上稳定不少，但前提是你得花时间调对采样参数。另外，ollama那个加载快其实是把模型切块缓存了，长文本卡是因为上下文窗口没优化好，建议手动改下num_ctx和chunk_size。但讲真，如果你主要写代码，别死磕13B，换7B的Qwen2.5-Coder或者DeepSeek-Coder 7B，用INT8甚至FP16都比13B量化强，因为模型小了反而能保留更多原始精度，代码生成这种任务对“忠实度”要求太高，量化的损失会被放大。至于调参，除非你有耐心去跑perplexity对比和特定任务测试集，不然性价比很低，我折腾过两周，最后还是老实换小模型了。还有个偏方，如果只是查资料和写简单脚本，可以试试GGUF的Q5_K_M加长上下文，配合llama.cpp的--no-mmap，能挤出一部分显存给KV cache，体验比盲目压位数好。总之，别迷信量化是万能药，模型架构和任务匹配度才是关键。