【AI 大模型】Ollama 本地部署大模型 ④ ( Qwen 文本大模型选型 | 显存预算 | GGUF 量化 | Qwen3.8 与 Qwen3 系列模型选择攻略 )

前言

随着国产开源大模型的快速迭代 , 在本地部署一个真正能用的模型早已不是难事 ;

真正卡住大多数人的环节 , 往往不是 " 能不能跑起来 " , 而是" 这块显卡到底该配多大的模型、哪一档量化、哪一类衍生版本 " ;

本文以一张 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 ;

结论很直接 :9B 是这块卡的舒适区 , 14B 是质量上限 ,19B 及以上不建议 ;

二、GGUF 量化

1、量化档位

GGUF 是 llama.cpp 生态通用的模型文件格式, 后缀代表每参数平均占用的 bit 数 ;

下图中 红色矩形框 中 , 5 个文件 ,是 Qwen/Qwen3-14B 模型的 5 个不同的量化模型, 每个都可以独立部署到 Ollama 中 ;

以 9B 模型为例 :

以 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 版, 但 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_LENGTH=65536ollama 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-gpu=memory.used,memory.total--format=csv# 每秒刷新 , 观察推理过程中的显存波动watch-n1nvidia-smi

2、一份真实输出的逐行解读

下面是一张 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 的百分比拆分 :说明显存不足 , 部分层已溢出到内存 , 生成速度会断崖式下跌 ;

发现溢出后的处理顺序 :

1. 关闭不必要的浏览器标签页与常驻桌面应用 , 通常可回收 0.5 GB 到 1 GB ;
2. 降低num_ctx;
3. 降低量化档位 , 例如从 Q5_K_M 退到 Q4_K_M , 或从 Q4_K_M 退到 IQ4_XS ;
4. 换成 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_LENGTH=65536ollama serve

设置完成后用ollama ps确认 PROCESSOR 列为100% GPU, 一旦出现 CPU 拆分就说明上下文开太大了 ;

3、能力边界 : 诚实评估

以 Qwen3-14B 为例 , 公开数据大致是这样 :

可以看到 , 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 显存 本地大模型选型 :

1. 先扣掉环境占用 :真实可用约 9.5 GB 到 10 GB, 而不是 11 GB ;
2. 再定规模 :9B 是舒适区 , 14B 是质量上限, 19B 及以上不建议 ;
3. 后选量化 :同规模下优先选 i1 版, 9B 用 Q4_K_M 到 Q6_K , 14B 用 Q4_K_M ;
4. 最后定用途 :通用对话选官方蒸馏源,工具调用选 Hermes 或 xLAM 系列,写作用 SLERP 或 Encore 系列,本地编码助手建议搭配 Aider 或 Cline 而非强格式约束的客户端 ;
5. 上线前必查 :nvidia-smi看真实占用 ,ollama ps看是否有层溢出到 CPU ;

模型选型的本质从来不是 " 越大越好 " , 而是在确定的硬件约束下 , 让显存预算、上下文长度与输出质量三者达成平衡 ;