文章目录前言一、显存预算1、GTX 1080 Ti 的规格与现实定位2、显存预算公式二、GGUF 量化1、量化档位2、静态量化 与 imatrix 量化 ( i1 ) 的区别3、选档决策表三、Qwen3.8 与 Qwen3 系列模型1、Qwen3.8 基座与 9B 蒸馏版2、Qwen3.8-14B-Instruct-Turbo : 剪枝路线的代表作四、Qwen3.8 9B 衍生版本如何分类1、通用蒸馏类2、函数调用与智能体类3、写作与创意类4、安全研究与网络安全类5、特殊格式与跨架构类五、Qwen3.8 14B 及以上型号盘点1、可以安装的三类2、不建议尝试的两类3、实验性架构需要留意六、Qwen3 14B 社区微调全景1、基座与指令版2、对齐调整类3、数学与推理类4、智能体与工具调用类5、角色扮演与创意写作类6、语言与领域专家类7、对齐算法实验类七、Ollama 落地 : 命令、参数与上下文控制1、基础安装与拉取2、上下文长度的正确设置3、采样参数与常见故障八、显存监控 : 看懂 nvidia-smi 的每一行1、三个必会命令2、一份真实输出的逐行解读3、溢出判断与优化动作九、用本地模型驱动编码助手 : Codex CLI 接入与边界1、配置方式2、必须同步调整的地方3、能力边界 : 诚实评估十、注意事项与避坑清单1、选型避坑2、运行避坑3、合规提醒总结前言随着国产开源大模型的快速迭代 , 在本地部署一个真正能用的模型早已不是难事 ;真正卡住大多数人的环节 , 往往不是 能不能跑起来 , 而是 这块显卡到底该配多大的模型、哪一档量化、哪一类衍生版本 ;本文以一张 GTX 1080 Ti 11 GB 显存的老卡作为基准硬件 , 结合Qwen3.8 系列 ( 含 9B 蒸馏版、14B 剪枝版与 27B 底座 )以及Qwen3 14B 的完整社区生态, 把显存预算、量化选型、衍生版本分类、Ollama 落地命令、显存监控、本地模型驱动编码助手这六个环节一次讲透 ;文中所有命令均可直接复制运行 ;一、显存预算1、GTX 1080 Ti 的规格与现实定位GTX 1080 Ti 发布于 Pascal 时代 , 拥有3584 个 CUDA 核心、 11 GB GDDR5X 显存、 352 bit 显存位宽、约 484 GB/s 显存带宽 ;在 nvidia-smi 中它会被识别为 11264 MiB 的总显存 ;需要注意两点 :没有 Tensor Core :Pascal 架构不支持混合精度矩阵加速, 相同模型在同代新卡上跑得更快 ;功耗与温度 :250W 标称功耗 , 满载时风扇噪音与温度都需要留意 , 长期推理建议保证机箱风道 ;2、显存预算公式可用显存并不是 11 GB 整 , 而是要减去系统与桌面应用的占用 :可用显存 总显存 - 桌面与系统占用 - 其他应用 剩余给上下文的预算 可用显存 - 权重文件大小在 Windows WDDM 模式下 ,浏览器、远程桌面、桌面端 AI 工具、办公套件插件等常驻程序合计通常会吃掉 1 GB 到 1.5 GB ;因此一张 11 GB 的卡 , 实际能给模型用的大约是 9.5 GB 到 10 GB ;各规模模型在 11 GB 上的可行区间 :表中体积为权重文件大小 , 判断标准是 权重 桌面占用 上下文缓存 不超过 11264 MiB ;模型规模推荐量化权重体积11 GB 显存结论9BQ4_K_M 或 Q5_K_M5.7 GB 或 6.6 GB非常宽松 , 甚至可以上 Q6_K 并开长上下文14B 到 15BQ4_K_M9.1 GB可用 , 上下文需控制在 8K 到 16K14B 到 15BQ5_K_M10.6 GB极限 , 上下文需压到 4K 左右19BQ3_K_M约 9.4 GB能跑 , 质量明显下降22BQ3_K_M约 10.5 GB极限 , 几乎没有上下文余量27B仅 Q2_K约 10.5 GB不建议 , 收益远低于代价结论很直接 :9B 是这块卡的舒适区 , 14B 是质量上限 ,19B 及以上不建议 ;二、GGUF 量化1、量化档位GGUF 是 llama.cpp 生态通用的模型文件格式, 后缀代表每参数平均占用的 bit 数 ;下图中 红色矩形框 中 , 5 个文件 ,是 Qwen/Qwen3-14B 模型的 5 个不同的量化模型, 每个都可以独立部署到 Ollama 中 ;以 9B 模型为例 :量化档位平均 bit9B 体积适用建议Q2_K约 2.63.8 GB极限压缩 , 损失明显Q3_K_M约 3.94.8 GB低显存折中Q4_K_M约 4.85.7 GB通用首选Q5_K_M约 5.56.6 GB质量更好Q6_K约 6.67.7 GB接近无损Q8_0约 8.510 GB几乎无损 , 体积大以 15B 模型为例 , 常见档位为 Q2_K 5.9 GB、 Q3_K_M 7.4 GB、 IQ4_XS 8.3 GB、 Q4_K_M 9.1 GB、 Q5_K_M 10.6 GB、 Q6_K 12.2 GB、 Q8_0 15.8 GB ;2、静态量化 与 imatrix 量化 ( i1 ) 的区别同一上游模型在社区里通常会有两个量化仓库 ,后缀分别为-GGUF与-i1-GGUF;静态量化 :对所有权重按统一规则压缩, 实现简单 , 提供 Q2_K 到 Q8_0 全档 ;imatrix 量化 :先用校准数据集统计每一层、每个通道的重要性, 量化时对重要权重给予更高精度,同等体积下质量更好; 仓库通常标注 22 个档位 , 从 IQ1_S 一直到 Q6_K ;两者的实际差异 :差异集中在低比特区间 ;对比维度静态版i1 版量化方法统一规则压缩重要性矩阵加权档位数量约 11 档约 22 档Q2 到 Q3 区间质量下降明显同体积明显更好Q4 到 Q5 区间正常略优或持平Q6 及以上正常基本无差别一个容易忽略的观察指标是点赞率 : 不少模型的热度榜上 ,静态版下载量远高于 i1 版, 但 i1 版的点赞数反而更高 , 说明实际用过 i1 版的人满意度更高; 这与显存受限设备更依赖中低比特档位是吻合的 ;3、选档决策表按场景直接套用 :优先级依次为显存、上下文长度、输出质量 ;8 GB 及以下显卡 :9B 模型选 Q3_K_M 或 IQ4_XS ;11 GB 显卡 :9B 模型选 Q4_K_M 到 Q6_K ;14B 模型选 Q4_K_M ;12 GB 到 16 GB 显卡 :9B 模型可上 Q8_0 ; 14B 模型可上 Q5_K_M ;需要长上下文 :在同体积前提下优先选 i1 档, 把省下的显存留给 KV 缓存 ;三、Qwen3.8 与 Qwen3 系列模型1、Qwen3.8 基座与 9B 蒸馏版Qwen3.8 是阿里巴巴在 2026 年 8 月发布的新一代基座 , 采用稀疏 MoE 架构 ,总参数 2.4T、激活 95B ,编程与长程任务能力进入全球第一梯队 ;但这个体量显然无法在单张消费级显卡上运行 ;社区给出的答案是蒸馏 :代表作品是由 Empero 发布的empero-ai/Qwen3.8-9B-Distill;训练方式 :以 Qwen3.5-9B 为学生模型 ,用约 70000 条经过质量过滤的教师思维链轨迹做全参数 SFT, 不是 LoRA 适配器 ;关键指标 :MMLU ( CoT ) 从 0.546 提升到 0.751 , 提升约 20 个百分点 ; GSM8K 基本持平 , 有小幅回落 ;上下文 :原生支持 262144 token ;能力 :按 Qwen3.5 规范原生支持函数调用 , 无需外挂封装 ;部署依赖 :需要支持 Qwen3.5 架构的 transformers 版本 , 以及 Gated DeltaNet 相关算子 ( flash-linear-attention 与匹配版本的 causal_conv1d ) , 否则线性注意力层会退化到低效实现 ;2、Qwen3.8-14B-Instruct-Turbo : 剪枝路线的代表作另一个思路是剪枝 : 代表作品是ewinregirgojr/Qwen3.8-14B-Instruct-Turbo,从 Qwen3.8-27B 通过 LoRA 辅助的剪枝与蒸馏压到约 15B;特点包括保留 Deltanet 混合注意力、262144 token 原生上下文、原生工具调用、Apache 2.0 许可;mradermacher 提供了它的全档位 GGUF , 其中 i1 版把 i1-Q4_K_S ( 8.8 GB ) 标注为体积、速度与质量的最优平衡点 ;四、Qwen3.8 9B 衍生版本如何分类1、通用蒸馏类这一类是所有衍生的源头 , 适合当作基准线使用 ;empero-ai/Qwen3.8-9B-Distill-GGUF:官方级别量化 , 下载量最高 , 数学与代码能力突出 , 优先推荐 ;Atomic-Germ/Qwen3.8-9B-Distill-GGUF、hakergeniusz/Qwen3.8-9B-Distill-GGUF:社区搬运的等价量化 , 可作为备用下载源 ;Twobombs/qwen3.8-9B-imatrix:自制重要性矩阵量化 , 低比特场景可尝试 ;gat45/qwen-3.8-for-1080-8gb:专门为 8 GB 显存挑选的量化组合 , 8 GB 以下设备的兜底方案 ;Beathazard/Qwen3.8-9B-Q2_K-GGUF:仅提供 Q2_K 单档 , 用于极限压缩验证 ;2、函数调用与智能体类这一类围绕结 构化工具调用 做强化 , 适合作为本地 Agent 的大脑 ;mradermacher/qwen3.8-9b-hermes-fc-tooluse-GGUF:Hermes 格式工具调用强化 , 通用性好 ;mradermacher/qwen3.8-9b-hermes-function-calling-v2-GGUF:v2 数据集 , 覆盖更多工具模式 ;mradermacher/qwen3.8-9b-hermes-fc-clean-restraint-GGUF:强化 不该调用时就别调用 的判断 , 减少无效工具调用 ;ermiaazarkhalili/Qwen3.8-9B-Function-Calling-xLAM-Unsloth-GGUF:基于 xLAM 数据集与 Unsloth 训练管线 , 工具调用格式稳定 ;JamieBradfield系列 :包含 real-traces ( 真实轨迹 ) 、 balanced ( 通用与工具能力平衡 ) 、 todo ( 任务规划拆解 ) 、 clean-restraint 等多个配方的自量化版本 ;3、写作与创意类mradermacher/Qwen3.8-9B-Distill-SLERP-F451-Pro-Writer-Uncensored-GGUF:SLERP 合并配方 , 长文稳定性好 ;ermiaazarkhalili/Qwen3.8-9B-SFT-Fable5-Glint-GGUF:Fable5 叙事风格微调 ;本地化版本 :例如面向芬兰语方向的kataguru版本 ;4、安全研究与网络安全类这一类在渗透测试、CTF、代码审计语料上做了专项微调 , 模型行为更贴近安全工程师的工作流 ;例如 Krypto-Whitehat 与 Neurona 的 cyber-exploit-agent 系列 ;这类模型的定位是安全研究辅助 , 使用范围应严格限定在自有环境或取得书面授权的目标环境 , 在任何未授权系统上投入使用都不合规 ;5、特殊格式与跨架构类uqer1244/Qwen3.8-27B-GSQ-RCO-MLX:MLX 格式 , 面向 Apple Silicon , Ollama 无法直接加载 , 需要 mlx-lm ;rcmorano/empero-ai-Qwen3.8-9B-ROCMFPX:面向 AMD ROCm 平台的转换版本 ;projectj/Instinct-Python-Coder-Gemma4-12B-Qwen3.8-27B:跨家族合并模型 , Python 编程方向 ;五、Qwen3.8 14B 及以上型号盘点1、可以安装的三类mradermacher/Qwen3.8-14B-Instruct-Turbo-GGUF:下载量与认可度最高的 14B 级选择 , Q4_K_M 为 9.3 GB , 与 11 GB 显存匹配 ; i1 版的 Q4_K_S ( 8.8 GB ) 是官方标注的最优平衡点 ;logic65/Qwen3.8-Whittle-16B:对 Qwen3.8-27B-FP8 做深度与宽度剪枝后再训练的 16B 密集模型 , 保留 262144 token 上下文 , 仓库自带 GGUF ;mradermacher/Qwen3.8-20B-Minitron-GGUF:19B 规模 , 只能跑 Q3_K_M ( 约 9.4 GB ) , Q4_K_M 已超出显存 ;2、不建议尝试的两类Mini-Me 22B 系列 :Q3_K_M 约 10.5 GB , 压线塞入后几乎没有上下文空间 ; Q4_K_M 约 13.4 GB , 直接超出显存 ;27B 系列 :11 GB 显存下只有 Q2_K 能勉强塞入 , 质量损失过大 , 性价比不成立 ;3、实验性架构需要留意logic65/Qwen3.8-Whittle-Next-19.8B-A10B-base是一个值得单独说明的例子 ;它采用实验性的 MoE 裁切思路 , 总参约 19.8B、每 token 激活约 10B , 附带 40 亿参数的 n-gram 记忆表 ;作者在模型卡中明确写出 : 这是实验研究产物 , 尚未完成指令微调 , 在标准对话循环测试中失败率很高 , 不应面向用户部署 ;因此想体验该架构应当选择对应的 chat 版本 , 而不是 base 版本 ;六、Qwen3 14B 社区微调全景Qwen3 14B 是社区微调最活跃的 14B 基座之一 , 从 2025 年 4 月发布至今衍生出上百个版本 ; 在 mradermacher 的量化仓库列表中 , 相关条目超过 150 个 ; 按用途可以归为以下几类 :1、基座与指令版Qwen3-14B-GGUF与-i1-GGUF:官方指令版量化 , 一切微调的对照基准 ;Qwen3-14B-Base-GGUF:官方基座版 , 无指令对齐 , 适合继续训练 ;2、对齐调整类这一类通过权重方向层面的技术调整 , 改变模型的拒绝倾向 , 是社区条目数量最多的一组 ;下载量居前的包括 Huihui 的 abliteration v2 系列、Qwen3-14B-Uncensored、raw-uncensored-heretic 系列、以及经过 KL 散度控制的 abliterated 版本 ;其中 RootMonsteR 发布的版本公开了完整复现配方 , 测得 KL 为 0.0333、拒绝率由 99/100 降到 10/100 , 属于 力度与能力保留兼顾 的工程解法 ;3、数学与推理类深度搜索推理 :Qwen3-14B-ARPO-DeepSearch, 下载量在本类中最高 ;数学专项 :Fast-Math、MathSmith-HC ( 短思维链 , 节省 token ) 、General-Reasoner ;数据高效 :s1与s1.1系列 , 复现测试时扩展思路 ;Qwen3-14B-ft-limo走少样本推理激发路线 ;结构化推理 :Qwen3-14B-DAG-Reasoning, UniReason 系列提供 think、no-think、RL 三种版本 ;强化学习 :GRPO、A3、以及 R3 系列的不同训练步数与 LoRA 消融版本 ;4、智能体与工具调用类YiXin-Agentic-Qwen3-14B:Agent 工作流专项微调 ;Qwen3-14B-heretic-tools:同时兼顾工具调用与降低拒答 , 定位独特 ;Medina-Qwen3-14B-OpenClaw-Merged:面向 OpenClaw 类 Agent 框架 ;git-commit-message-splitter:提交信息生成这类单一任务的专用小模型 ;5、角色扮演与创意写作类QiMing-Holos-Plus 与 QiMing-Pantheon :叙事与角色扮演方向口碑较好 ;Qwen3-Gutenberg-Encore-14B:公版书语料增强 , 长文风格突出 ;InnerVerse v1 到 v5 :迭代五个版本的沉浸式角色扮演系列 ;Esper3、GrayLine、VitriousGrey、Dawnwhisper 等 :不同风格取向的合并版本 ;6、语言与领域专家类语言特化 :Slava 塞尔维亚语、Malaysian、Myanmar、Sindhi、XPlus 多语言版本 ;中文方向 :Xiaolong 风格微调、huatuo 中文医疗问答、Qwen3-14B-gwb-press-conference-sft-merged;科学领域 :Scientist、V-Science ( 含 v2 ) 、MegaScience、TechGPT 3.0 ;安全与风控 :qwen3-14b-thinking-cti面向威胁情报 , BingoGuard 反向做内容审核分类 , Guardpoint、UNO-Scorer 用于打分与安全判定 ;代码评审 :CriticLeanGPT 采用 RL 训练 ;7、对齐算法实验类WildFeedback 系列的 seed、DRIFT、iterDPO、SPIN 四种算法横向对比 , 以及 Tulu-SFT、知识编辑对比实验 KE-strict 与 KE-indecisive 等 ; 这类仓库下载量普遍偏低 , 价值在于复现论文 , 不建议作为日常主力 ;七、Ollama 落地 : 命令、参数与上下文控制1、基础安装与拉取Ollama 支持直接从 Hugging Face 拉取 GGUF , 语法为ollama run hf.co/仓库名 :量化标签;# 9B 级推荐 : i1 量化 Q4_K_M , 约 5.7 GB , 适合 11 GB 显存ollama run hf.co/mradermacher/Qwen3.8-9B-heretic-uncensored-i1-GGUF:Q4_K_M# 9B 级质量优先 : Q5_K_M , 约 6.6 GBollama run hf.co/mradermacher/Qwen3.8-9B-heretic-uncensored-i1-GGUF:Q5_K_M# 14B 级首选 : Qwen3.8 剪枝蒸馏版ollama run hf.co/mradermacher/Qwen3.8-14B-Instruct-Turbo-i1-GGUF:Q4_K_S# 14B 级 : Huihui 对齐调整 v2 版ollama run hf.co/mradermacher/Huihui-Qwen3-14B-abliterated-v2-i1-GGUF:Q4_K_M常用辅助命令 :ollama list# 查看本地已安装模型及其体积ollamaps# 查看当前已加载模型、实际占用、GPU 与 CPU 分布ollamarm模型名# 删除不再使用的模型释放磁盘空间2、上下文长度的正确设置Ollama 默认上下文窗口为 4096 token , 而 Qwen3.8 系列原生支持 262144 token ; 若直接启用长上下文 , 显存会迅速吃紧 ; 正确做法是按需设置 :# 服务端启动前设置全局上下文上限 , 64K 是常见的 Agent 场景推荐值OLLAMA_CONTEXT_LENGTH65536ollama serve按次请求指定也是可以的 , 在 Modelfile 或 API 参数中使用num_ctx即可 ; 经验值是 : 上下文每增加 8K , 大约多消耗 0.5 GB 到 1 GB 显存 , 具体取决于架构的 KV 结构 ; 在 11 GB 卡上运行 14B Q4_K_M 时 ,num_ctx控制在 8192 到 16384 比较稳妥 ;3、采样参数与常见故障这一代模型属于推理型 , 输出前会先产生思维链 ; 推荐参数如下 :temperature 0.6 top_p 0.95 top_k 20 max_new_tokens 16384常见故障与处理 :输出陷入复读 :原因是使用了贪心解码 ; 务必保持采样 , 不要设置 temperature 为 0 ;长输出被截断 :输出上限给得太小 , 推理型模型需要 16K 级别的生成空间 ;首次响应慢 :模型正在从磁盘加载到显存 , 属正常现象 ;回答前有一大段思考文本 :这是该模型类的固有行为 , 生产环境需要在代码中解析并剥离这段内容 ;八、显存监控 : 看懂 nvidia-smi 的每一行1、三个必会命令# 完整状态快照 : 包含显存总量、已用量、利用率、温度、功耗与进程列表nvidia-smi# 只输出显存数字 , 方便脚本判断nvidia-smi --query-gpumemory.used,memory.total--formatcsv# 每秒刷新 , 观察推理过程中的显存波动watch-n1nvidia-smi2、一份真实输出的逐行解读下面是一张 GTX 1080 Ti 在推理过程中的真实输出 :| GPU Name Driver-Model | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | 0 NVIDIA GeForce GTX 1080 Ti WDDM | 00000000:01:00.0 On | N/A | | 35% 67C P0 257W / 250W | 10514MiB / 11264MiB | 94% Default |对应的解读 :10514MiB / 11264MiB:已使用约 10.27 GB , 剩余约 750 MB , 属于贴着上限运行 ;94%:GPU 利用率 , 说明正在高强度生成 ;67C与257W / 250W:温度正常 , 瞬时功耗略微超过标称功耗墙属于 boost 正常现象 ;WDDM:Windows 显示驱动模型 , 该模式下进程列表中的 GPU Memory 列会全部显示为 N/A , 属于系统限制而非故障 , Linux 环境才会给出逐进程数值 ;进程列表中同时出现了 llama-server 与多个桌面应用 : 浏览器、远程桌面、桌面 AI 工具、办公套件插件等 ; 这些常驻程序合计通常占用 1 GB 到 1.5 GB , 是 明明模型只有 9 GB、却看到 10.5 GB 的主要原因 ;3、溢出判断与优化动作ollama ps的 SIZE 列只反映模型自身的占用 , 真实情况必须配合nvidia-smi一起看 ; 判断标准如下 :PROCESSOR 列显示100% GPU:完全驻留显存 , 状态健康 ;PROCESSOR 列出现 CPU 与 GPU 的百分比拆分 :说明显存不足 , 部分层已溢出到内存 , 生成速度会断崖式下跌 ;发现溢出后的处理顺序 :关闭不必要的浏览器标签页与常驻桌面应用 , 通常可回收 0.5 GB 到 1 GB ;降低num_ctx;降低量化档位 , 例如从 Q5_K_M 退到 Q4_K_M , 或从 Q4_K_M 退到 IQ4_XS ;换成 i1 版 , 在同体积下获得更好质量 , 相当于间接 升级 ;九、用本地模型驱动编码助手 : Codex CLI 接入与边界1、配置方式Codex CLI 支持把本地 OpenAI 兼容服务作为后端 ; 新版已经把 Ollama 与 LM Studio 做成内置 provider , 因此不再需要自定义 provider 表 ;# 文件路径 : ~/.codex/config.toml # oss_provider 指定本地运行时 , 可填 ollama 或 lmstudio oss_provider ollama model qwen3:14b命令行直接指定也是可以的 :# 使用内置本地 provider 启动 , -m 后接本地已安装的模型名codex--oss-mqwen3:14b一个容易踩的坑来自过期教程 : 老版本文档要求手写[model_providers.ollama]配置块 , 新版会直接报 保留 provider ID 不可覆盖 的错误 ; 只需要保留oss_provider一行 ; 另外 , 涉及需要自定义的服务端时 , 新版要求 Responses 协议 , 仅提供 Chat Completions 的网关无法直接对接 ;2、必须同步调整的地方Codex 类编码助手要求至少 32K 上下文 , 而 Ollama 在显存小于 24 GB 的机器上默认只给 4K ; 这就是 装好了但助手跑两步就失忆 的头号原因 ; 处理办法只有一个 :# 服务端优先 , 建议设置为 64000 , 若显存吃紧再降到 32000OLLAMA_CONTEXT_LENGTH65536ollama serve设置完成后用ollama ps确认 PROCESSOR 列为100% GPU, 一旦出现 CPU 拆分就说明上下文开太大了 ;3、能力边界 : 诚实评估以 Qwen3-14B 为例 , 公开数据大致是这样 :能力维度表现工具调用格式原生支持 , 单次调用基本可靠单文件问答与改写可靠LiveCodeBench约 52 到 63 分SWE-bench Verified 独立实测约 32 到 35 分参考基准Codex 本地默认推荐的 gpt-oss:20b 为 53 到 60 分可以看到 , 14B 距离 能流畅跑完整自主编码循环 仍有明显差距 ; 多步任务中容易出现补丁格式错误、上下文丢失、工具循环原地打转等问题 , 需要频繁人工纠偏 ;更务实的做法 :单文件修改、代码解释、脚本生成 :本地 14B 完全胜任 ;跨文件重构、长链路 Agent :建议改用对模型格式更宽容的工具 , 例如 Aider 或 Cline , 可用性明显高于强制补丁格式的客户端 ;高质量自主交付 :使用云端 API , 或等待 16 GB 以上显存设备运行更大的本地模型 ;十、注意事项与避坑清单1、选型避坑不要迷信参数 :27B 跑 Q2_K 的实际体验远不如 9B 跑 Q5_K_M ;宁小勿大 ;优先看下载量与点赞率 :生态里存在大量下载量不足 1K 的实验性仓库, 质量参差 , 除复现论文外不建议投入 ;每个模型先核对架构 :MLX 格式只能跑 Apple Silicon , 部分实验性 MoE 或自定义算子需要特定版本的 llama.cpp ;base 版本不要当助手用 :未完成指令微调的底座 , 对话能力不可用 ;2、运行避坑上下文是隐形显存杀手 :显存吃紧时优先压num_ctx, 而不是先降量化 ;禁止贪心解码 :推理型模型在 temperature 为 0 时极易复读 ;Windows 环境记得看进程列表 :浏览器常驻会显著侵占显存 ;先验证再长跑 :一次ollama ps加上nvidia-smi, 就能提前发现溢出 , 避免长时间低效运行 ;3、合规提醒社区中存在经过行为倾向调整的特殊衍生版本 , 这类模型缺少默认的安全护栏 ;在选用时应当确认其许可协议、上游声明与使用范围 , 并确保部署环境与实际用途符合所在地法律法规与单位合规要求 ;涉及网络安全方向的专项模型 , 仅限自有环境或取得书面授权的目标环境 , 不得用于任何未授权场景 ;总结GTX 1080 Ti 11 GB 显存 本地大模型选型 :先扣掉环境占用 :真实可用约 9.5 GB 到 10 GB, 而不是 11 GB ;再定规模 :9B 是舒适区 , 14B 是质量上限, 19B 及以上不建议 ;后选量化 :同规模下优先选 i1 版, 9B 用 Q4_K_M 到 Q6_K , 14B 用 Q4_K_M ;最后定用途 :通用对话选官方蒸馏源,工具调用选 Hermes 或 xLAM 系列,写作用 SLERP 或 Encore 系列,本地编码助手建议搭配 Aider 或 Cline 而非强格式约束的客户端 ;上线前必查 :nvidia-smi看真实占用 ,ollama ps看是否有层溢出到 CPU ;模型选型的本质从来不是 越大越好 , 而是在确定的硬件约束下 , 让显存预算、上下文长度与输出质量三者达成平衡 ;