Quantization and Pruning Methods to Make Your LLM Leaner
TL;DR · AI 摘要
量化和剪枝技术能显著减小LLM体积，降低部署成本，避免因模型过大导致的资源浪费和延迟。
核心要点
- 量化将16位浮点数转为4位整数，减少存储空间且加速计算
- 剪枝通过删除冗余结构（如注意力头）直接减少参数数量
- 生产环境中已有5种量化剪枝方法的实战代码可直接复用
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- LLM优化技术
- 量化
- 精度压缩（16→4位）
- 存储优化
- 剪枝
- 结构删除
- 参数精简
- 组合应用
- 体积缩减60%
- 延迟降低40%
金句 / Highlights
值得收藏与分享的关键句。
量化将16位浮点数转为4位整数，减少存储空间且加速计算
剪枝通过删除冗余结构（如注意力头）直接减少参数数量
生产环境中已有5种量化剪枝方法的实战代码可直接复用
某团队通过组合技术将模型体积缩减60%，推理延迟降低40%
量化和剪枝方法让您的大型语言模型更轻量 - KDnuggets
publ: 2026年8月28日
- 博客热门文章
- 主题 人工智能 职业建议 计算机视觉 数据工程 数据科学 语言模型 机器学习 MLOps NLP 编程 Python SQL
- 数据集
- 活动
- 资源 快速参考指南 推荐 技术简报
- 广告
订阅简报
#header end
/ad_wrapper
量化和剪枝方法让您的大型语言模型更轻量
本文将逐步介绍每种技术的实际作用，说明跳过它们会导致真实成本和延迟增加，然后通过五种当前正在生产环境中运行的具体方法进行实操演示。
作者：
Shittu Olumide，技术内容专家，2026年8月28日发布于
语言模型
<div class="addthis_native_toolbox"></div>
一个团队花费三周时间微调模型，获得了理想的评估指标，但随后尝试实际部署时却遇到难题。仅检查点文件就达到140GB，这个数字几乎排除了普通公司机架中所有GPU的使用可能，迫使重新制定部署计划，将本应是发布周的安排变成了紧急寻找四块未预算的A100 GPU的混乱局面。
这种场景出现的频率比人们想象的要高，而且几乎总是可以避免。模型并不需要以全精度和完整参数状态部署，它只需要以仍能完成任务的最精简版本上线。实现这一目标的两种技术——量化和剪枝——既不神秘也不新奇，只是被那些认为"让模型变小"就等于"让性能变差"的团队低估了。
本文将逐步介绍每种技术的实际作用，说明跳过它们会导致真实成本和延迟增加，然后通过五种当前正在生产环境中运行的具体方法进行实操演示，每种方法都附有可立即应用的代码示例。
量化和剪枝的本质
这两种技术经常被混为一谈，在继续深入之前有必要清晰区分它们，因为它们通过不同方式解决不同问题。
量化降低模型所用数字的精度。一个以16位浮点数存储的权重（例如0.0023847）会被四舍五入并用更少的位数重新表示——例如8位整数或4位整数。模型的参数数量完全不变。所有先前存在的权重依然存在，只是占用空间更少且计算速度更快，就像以较低位深度保存的高清照片仍然能显示画面中的每个物体，只是阴影部分的精度有所降低。
剪枝则直接移除权重或整个结构。两个神经元之间的连接、一个注意力头，有时甚至整个层都会被删除，因为模型最终发现并不需要它们。参数数量本身会减少。这类似于编辑长文档时直接删除没有增加任何内容的句子，而不是仅仅将所有内容改用较小字体。
这两种技术都能缩小模型体积，只是沿着不同维度进行压缩。正如本文后文将展示的，它们可以很好地叠加使用，而非争夺同一任务。
规模问题在看到实际数字之前往往容易被低估。根据Pristren对LLM压缩成本的分析，一个700亿参数的模型以FP16格式存储时，仅加载就需要约140GB的VRAM，这意味着在单个请求被处理之前需要使用四块A100 GPU。这相当于在模型产生任何实际价值之前，硬件成本就高达8万到10万美元。
量化技术直接改变了这个计算公式。通过使用AWQ或GPTQ将相同的700亿参数模型压缩到4位，内存需求会降至约35到40GB——这个规模足以在一块高端工作站显卡上运行，而无需使用小型集群，如Fungies在2026年量化指南中所描述的。这并非边缘优化，而是决定模型需要数据中心还是可以在单个工程师桌面上运行的硬件差异。
这并非仅限于本地运行模型的爱好者关注的边缘问题。它正在塑造2026年最大实验室部署模型的方式。根据TensorFoundry的2026年量化实践指南，Google的Gemma 3将270亿参数模型从54GB压缩到4位时的约14GB，同时将量化损失降低到普通训练后量化损失的一半左右。其后续版本Gemma 4更进一步，推出了量化感知检查点，使最小的20亿参数版本压缩到约1GB——小到足以在手机上完整运行。目前iPhone上的设备端模型也采用相同技术，通过量化感知训练将权重压缩到2位，而非事后猜测量化尺度。
实际收益包括：减少需要购买或租赁的GPU数量、每个请求的延迟更低（因为需要通过内存传输的数据更少），以及在那些根本无法容纳完整模型的硬件上部署真实能力。
如果跳过量化或执行不当会发生什么
坦率地讲，失败的另一面同样值得关注，因为两种方向的失败在实践中都会频繁出现。
如果完全跳过压缩，失败通常是简单且代价高昂的：模型规模超出实际拥有的硬件部署能力，推理账单使产品失去商业可行性，或延迟高到足以破坏任何需要快速响应的使用场景——实时聊天界面、语音助手、自动补全工具。这些都不是假设情况，而是任何训练大模型并假设服务问题由他人后续解决的团队的默认结果。
相反的失败模式更加隐蔽且危险，因为它不像内存不足错误那样会明确发出警告。如果在没有适当校准数据集的情况下过于激进地进行量化，或忽略了那些虽然数量极少却承载着模型实际能力的异常权重，准确性会以不易被快速烟雾测试发现的方式下降。红帽公司对超过500,000个量化模型的评估研究发现，质量损失会根据模型、任务和方法的不同而显著变化——有些模型能很好地容忍激进压缩，有些则会迅速崩溃，唯一能确定你面对的是哪种情况的方法，是实际在与实际应用场景相似的任务上对压缩版本进行基准测试，而不是仅仅检查它是否还能生成语法正确的句子。粗心地进行剪枝时，会出现相同的模式：对最简单的幅度剪枝方法的研究发现，即使在相对较低的稀疏度水平下，它在大型语言模型（LLMs）上也会显著失效，正如Wanda剪枝方法的研究团队直接记录的那样。事实证明，与幅度剪枝最初设计用于的小型网络相比，LLMs的安全剪枝要困难得多。
本文介绍的五种方法正是为了填补这两种失败模式之间的空白：通过足够谨慎的实施，实现真正有意义的压缩，避免悄无声息地破坏你耗费数周构建的模型。
五种方法概览
在深入探讨每种方法之前，先来看这张图。其中三种是量化方法，两种是剪枝方法，它们在所需的配置量和实际优化目标上存在显著差异。
| 方法 | 类别 | 典型尺寸缩减 | 是否需要重新训练 | 最佳适用场景 | |------|------|--------------|------------------|--------------| | bitsandbytes (NF4) | 量化 | ~4倍 | 否（支持通过QLoRA进行可选微调） | 快速部署，且是唯一支持微调的选项 | | GPTQ | 量化 | 否，仅需校准 | 成熟的GPU服务，广泛预量化模型可用性 | | AWQ | 量化 | 生产级GPU服务，在现代内核上具有最佳质量与速度比 | | SparseGPT | 剪枝 | ~2倍（50%稀疏度） | 否，单次更新权重 | 大型模型，结构化2:4稀疏度实现真实硬件加速 | | Wanda | 剪枝 | 否，单次前向传递 | 极大型模型，剪枝速度本身至关重要 |
方法一：bitsandbytes（NF4 4位量化）
这是大多数团队应首先尝试的方法，许多指南中对它的宣传力度不足恰恰是因为它足够简单，可以通过单个函数调用实现。该方法围绕一种名为NF4（NormalFloat4）的数据类型构建，该类型专门针对神经网络权重通常遵循近似正态分布而非在数轴上均匀分布这一事实进行设计，因此可用的4位值被放置在实际权重聚集的位置，而非均匀分布。
它也是本列表中唯一支持QLoRA的方法，这意味着你可以加载一个4位模型，同时通过训练小型低秩适配器权重进行微调，而无需直接修改冻结的4位基础权重。如果微调在你的计划中，这将是自然的起点。
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
import torch
model_id = "meta-llama/Llama-3.1-8B-Instruct"
# 配置 4-bit NF4 量化并启用双重量化
bnb_config = BitsAndBytesConfig(
load_in_4bit=True, # 以 4-bit 而非 16-bit 加载权重
bnb_4bit_quant_type="nf4", # NormalFloat4：一种针对
# 神经网络权重近似正态分布的
# 数据类型
bnb_4bit_compute_dtype=torch.bfloat16, # 在计算时将矩阵乘法临时提升至
# bfloat16 精度，权重仍以 4-bit 存储
bnb_4bit_use_double_quant=True, # 对量化常数本身进行量化
# 可再节省约每个参数 0.4 bit 的内存
)
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
model_id,
quantization_config=bnb_config,
device_map="auto", # 将模型层分布到可用
# GPU 上，必要时回退到 CPU
)
inputs = tokenizer("Explain quantization in one sentence.", return_tensors="pt").to(model.device)
output = model.generate(**inputs, max_new_tokens=40)
print(tokenizer.decode(output[0], skip_special_tokens=True))关键点解析：load_in_4bit=True 是触发整个量化流程的开关，它在加载模型时直接将所有线性层权重转换为 4-bit，无需预先进行离线量化，这正是该方法运行最快的根源。bnb_4bit_quant_type="nf4" 选择分布感知格式而非普通 4-bit 整数，这使得量化后模型质量更接近原始模型而非盲目舍入。
bnb_4bit_compute_dtype=torch.bfloat16 至关重要，因为权重以 4-bit 存储在内存中，但在实际矩阵乘法时会临时提升至 bfloat16 精度（当前 GPU 尚无原生 4-bit 计算内核）。bnb_4bit_use_double_quant=True 是一个微小但真正免费的优化：对最初量化权重时使用的缩放常数再次进行量化，可在不显著影响精度的情况下进一步节省内存。
方法 2：GPTQ（校准后训练量化）
GPTQ 是首个在大模型上表现良好的 4-bit 量化方法，由 Frantar 等人在 2022 年的原始论文中提出。其核心机制使其区别于简单舍入：它逐层量化模型，每层内部使用二阶信息（海森矩阵的近似）来判断某个权重的舍入如何影响周围权重的理想值，然后调整该层剩余未量化权重以补偿刚引入的误差。这是直接内置在量化过程中的误差校正机制，而非独立量化每个权重并希望误差不累积。
该机制需要校准数据集，通常使用几百个代表性文本样本，以准确估计这些海森矩阵统计量。
from transformers import AutoModelForCausalLM, AutoTokenizer, GPTQConfig
import torch
model_id = "meta-llama/Llama-3.1-8B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_id)
# GPTQConfig 驱动校准和量化过程
gptq_config = GPTQConfig(
bits=4, # 每个权重的目标位宽
dataset="c4", # 用于估计基于海森矩阵的误差补偿的校准文本
tokenizer=tokenizer,
group_size=128, # 权重以128为一组进行量化，在压缩比和精度之间取得平衡
desc_act=False, # 跳过激活顺序排列以加快推理速度，略微牺牲精度
)
model = AutoModelForCausalLM.from_pretrained(
model_id,
quantization_config=gptq_config,
device_map="auto",
torch_dtype=torch.float16,
)
model.save_pretrained("./llama-3.1-8b-gptq-int4")
tokenizer.save_pretrained("./llama-3.1-8b-gptq-int4")dataset="c4" 这一行是整个代码片段中真正起作用的部分：模型会在此数据集上运行前向传递以收集 GPTQ 计算分层误差校正所需的激活统计信息。使用与实际流量相似的数据集，通常比使用通用数据集能产生更好的实际效果。group_size=128 控制量化的粒度——较小的分组意味着存储更多的缩放常数（略微增加内存占用），以换取更高的精度，而 128 是社区认可的标准折中值。desc_act=False 禁用一个重新排序步骤（该步骤优先处理影响最大的权重列），虽然会略微提高精度，但会减慢量化过程，某些服务架构中甚至会影响推理速度，因此在以 GPU 服务为主的场景中通常关闭此选项。
有必要坦率指出 GPTQ 的实际局限性，而不仅仅是称赞它：Jarvis Labs 2026 年 1 月的一项基准测试在相同硬件上并行运行所有四种主流 4 位格式，发现 GPTQ 在代码生成任务上表现落后，HumanEval 评分约为 46%，而 AWQ 和 GGUF 分别达到约 51.8%（详见《The AI Engineer》的格式对比分析）。可能的原因是 GPTQ 的逐列误差传播在长矩阵计算中累积效应更明显，这对需要多步推理的代码生成任务影响更大，而对简单的下一个词预测影响较小。尽管如此，GPTQ 仍然是一个成熟、广泛支持的可靠选择，特别是如果你已经有一个运行良好的 GPTQ 检查点。但在 2026 年的新部署中，它已不再是首选方案。
方法三：AWQ（激活感知权重量化）
AWQ 在 Lin 及其同事 2023 年的论文中提出，从不同角度切入同一根本问题。与 GPTQ 事后修正误差的方式不同，它基于一个关键观察：通过短时间校准过程观察激活值，可以识别出少量"显著"权重通道——这些通道持续产生最大激活值幅度，对模型输出产生不成比例的影响。这些显著权重通过一种缩放技巧进行保护，保持其有效精度，而其他权重则被激进量化。
这种针对性保护正是 AWQ 在 2026 年成为生产级 GPU 服务默认选择的重要原因，特别是在指令微调模型中，少量承载真实语义权重的参数会对输出质量产生显著影响。
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer
model_path = "meta-llama/Llama-3.1-8B-Instruct"
quant_path = "llama-3.1-8b-awq"
quant_config = {
"zero_point": True, # 非对称量化：通过偏移零点而非强制权重围绕零中心分布
# 来调整量化范围
"q_group_size": 128, # 与 GPTQ 相同的分组理念，每组 128 个权重
"w_bit": 4, # 4 位权重
"version": "GEMM", # 为批量 GPU 推理优化的内核变体
}
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
# quantize() 执行校准过程，通过观察激活值幅度识别显著权重
# 通道，在激进量化其他内容的同时保护这些权重
model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)zero_point=True 允许量化范围偏移而非强制对称围绕零，这很重要，因为真实权重分布很少完美居中，非对称量化能更忠实还原这种分布形态。q_group_size=128 与 GPTQ 的作用相同，控制组级精度与内存的权衡。w_bit=4 是目标精度。version="GEMM" 选择 AWQ 在推理时编译的内核；GEMM 是专为服务器处理多个并发请求时发生的批量矩阵乘法优化的变体，这正是生产级服务的实际场景。
数据验证了其优势：根据 Premai 2026 年量化对比研究，使用 Marlin 推理内核时，AWQ 相比原始 FP16 模型快约 1.6 倍，同时保持约 92% 的代码生成准确性。需要诚实指出：如果没有优化内核支持，AWQ 实际上可能比普通 FP16 运行更慢，因此格式和运行的推理栈必须协同选择，而非单独决定。
方法 4：SparseGPT（一次性结构化剪枝）
这是文章从减少参数数量转向完全移除权重的关键转折点。Frantar和Alistarh在2023年论文中提出的SparseGPT方法首次证明，大型语言模型可以通过激进剪枝实现性能提升而无需重新训练。在当时主流观点（基于简单幅度剪枝）认为这种规模的模型根本无法实现有效剪枝的背景下，该方法将剪枝视为逐层重建问题：对每一层决定移除哪些权重，并在同一过程中利用二阶Hessian信息（与GPTQ方法精神相似）更新剩余权重以补偿被删除的权重。
此处最关键的实际细节是稀疏模式的选择。非结构化稀疏（随机移除最低幅度的权重）虽然能减少磁盘存储占用，但无法在标准GPU硬件上提升速度，因为硬件仍需加载所有权重。NVIDIA的2:4结构化稀疏模式（每4个连续权重中强制包含2个零）改变了这一现状：Ampere、Hopper和Blackwell GPU的稀疏张量核心可在矩阵运算时完全跳过零权重，实现实际可测量的速度提升而非单纯减小文件体积，如Spheron在《在GPU云硬件上运行SparseGPT和Wanda的指南》中所述。
# 克隆官方SparseGPT仓库
git clone https://github.com/IST-DASLab/sparsegpt
cd sparsegpt
# 使用结构化2:4稀疏模式进行单次剪枝
python llama.py meta-llama/Llama-3.1-8B-Instruct c4 \
--sparsity 0.5 \ # 目标：总体移除50%权重
--prunen 2 --prunem 4 \ # 强制使用2:4模式（每4个权重中包含2个零）
# 实现稀疏张量核心的实际加速
--save llama-3.1-8b-sparsegpt-2-4两个位置参数——模型标识符和c4——告诉脚本要剪枝哪个模型以及使用哪个校准数据集运行前向传递以估计剪枝决策所依赖的Hessian统计量，其功能作用与GPTQ中校准数据的作用相同。--sparsity 0.5设置总体目标；被剪枝层中的一半权重将被移除。--prunen 2 --prunem 4是强制使用2:4结构化模式而非保留非结构化剪枝的标志组合，如果目标是实现实际推理加速而非单纯减小磁盘检查点体积，这是该命令中最重要的设置。预计在单个H100 GPU上对70B模型执行此操作需要约1小时，7B到8B规模模型所需时间则显著减少。
方法5：Wanda（基于权重和激活的剪枝）
Wanda（Weight and Activation-based Pruning）是Sun及其同事在2023年论文中提出的剪枝方法，其核心思想是对SparseGPT方法的简化。该方法不再通过Hessian矩阵求逆解决完整的逐层重建问题，而是仅通过权重幅度与对应输入激活L2范数的乘积对每个权重进行评分——这一指标可通过单次模型前向传递计算。完全不需要后续的权重更新步骤，剩余权重将保持原样不变。
# 克隆官方 Wanda 仓库
git clone https://github.com/locuslab/wanda
cd wanda
# 运行一次性剪枝：单次前向传播，无需 Hessian 矩阵，无需权重更新
python main.py \
--model meta-llama/Llama-3.1-8B-Instruct \
--prune_method wanda \ # 选择幅度乘以激活值的评估指标
--sparsity_ratio 0.5 \ # 总体移除 50% 的权重
--sparsity_type 2:4 \ # 结构化模式实现真实 GPU 性能提升
--save out/llama-3.1-8b-wanda-2-4--prune_method wanda 是选择这种特定评分方法而非脚本支持的其他方法（包括普通幅度剪枝和 SparseGPT 本身）的参数，因为这两种方法通常在相同工具链中并行实现以便直接比较。--sparsity_ratio 和 --sparsity_type 几乎与 SparseGPT 的标志完全一致，移除一半权重并结构化为硬件可利用的 2:4 模式。选择 Wanda 而非 SparseGPT 的实际原因在于当模型足够大或校准数据集足够多时，SparseGPT 的 Hessian 矩阵求逆会成为工作流程的瓶颈而非剪枝决策本身。
组合使用：剪枝与量化协同
这五种方法不是只能二选一的菜单。剪枝和量化针对同一问题的不同部分，可以直接结合使用，组合效果往往优于任一技术单独使用。以 70B 模型为例，先用 SparseGPT 或 Wanda 剪枝至 50% 结构化稀疏性，再用 AWQ 或 GPTQ 对剩余部分进行量化，原本需要 140GB 的 FP16 模型可压缩至约 17-18GB —— 根据 Spheron 的联合基准测试，这个规模已能舒适运行在单块高端消费级 GPU 上。
顺序至关重要且并非随意。先剪枝后量化有效是因为量化步骤会基于模型实际最终权重分布（包括剪枝已引入的空缺）进行校准。若反向操作，先量化再剪枝，剪枝步骤将基于已被四舍五入和扭曲的权重做移除决策，导致两个误差源相互叠加，而非让后续步骤能清晰修正前序变化。
在手头有五种实际选择的情况下，最终决策通常取决于你正在优化的目标，而之前提到的对比表格与现实中的选择具有直接对应关系。如果计划中包含微调（不仅限于推理阶段），那么 bitsandbytes 配合 QLoRA 是本列表中唯一从底层架构专门为此设计的方法。如果你通过 vLLM 等工具进行大规模服务，且原始吞吐量是首要考虑因素，那么 AWQ 配合 Marlin 内核是当前默认方案，这并非没有原因。如果你已经在生产环境中稳定运行了 GPTQ 检查点，除非有特殊需求，否则很少有理由单纯为了迁移而更换方案，但新项目今天更推荐从 AWQ 开始。如果你部署到笔记本电脑、边缘设备，或通过 Ollama、LM Studio 等工具运行，那么 GGUF 格式才是这个领域的主流方案，而非上述三种量化方法。这是因为 GGUF 特别针对 CPU 推理的效率进行了优化，而且大多数压缩模型最终都会转换为 GGUF 格式以完成最后的部署环节。
就剪枝而言，选择通常取决于模型规模以及你愿意为剪枝过程本身投入多少计算资源。SparseGPT 额外的权重更新步骤通常会在 7B 级别的小型模型上超越 Wanda 的效果。而 Wanda 显著更低的计算成本使其在模型规模增大时更具实用性，因为此时 SparseGPT 的 Hessian 计算会逐渐成为真正的瓶颈，而不仅仅是时间线上的微小误差。
结论
只要正确实施，这五种方法都不会以任何有意义的方式降低模型表现。它们让模型回归本质。大多数大型模型在发布时都携带了比实际任务需求更高的精度和更多参数，这些参数源自训练阶段针对不同目标进行的优化。量化和剪枝正是你发现模型真正需要保留的内容以维持良好表现，并剔除其余冗余部分的手段。
从这五种方法中选择时，应优先考虑当前实际面临的限制条件——内存、延迟、缺乏的硬件资源，或仍需执行的微调步骤——而非盲目追求在非自身任务上表现最佳的基准方法。在信任模型之前，务必在与实际流量相似的场景中对其结果进行基准测试。这就是整个领域的核心原则，其可接近性远超这些模型规模带来的表面印象。
Shittu Olumide 是一名软件工程师兼技术作家，热衷于利用前沿技术创作引人入胜的叙事，具备敏锐的细节洞察力和将复杂概念简化的独特能力。你也可以在 Twitter 上关注 Shittu。
更多相关内容
- 量化与大语言模型：将模型压缩为可管理规模
- 语言模型量化是什么鬼？？！
- 理解 Python 的迭代与成员检查：指南…
- 5 个 NotebookLM 小技巧让工作日更轻松
- 用 Redash 让公司数据驱动决策
- 测量提示效果：指标与方法
<hr class="grey-line"><br> <div><h3>我们推荐的 5 门免费课程</h3><br> </div>
Mailchimp for WordPress v4.14.0 - https://wordpress.org/plugins/mailchimp-for-wp/
/ Mailchimp for WordPress 插件
你可以从此处开始编辑。
如果评论已关闭。
<= 上一篇
下一篇 =>
#content end
<script type="text/javascript">kda_sid_write(kda_sid_n);</script>
最新文章
- 使用DSpark推测解码加速LLM推理 7个Python初学者常见错误（以及正确的做法） 用于高效SLMs的本地AI堆栈 量化和剪枝方法让您的LLM更轻量 从谷歌工程师不可或缺的提示中可以学到什么 理解AI对就业市场的影响
热门文章
- 用于高效SLMs的本地AI堆栈
- 如何利用本地小型语言模型推进您的项目
- 如何在AI领域构建职业道路：3条明确路径
- 从AI编码代理获取更好结果的10条规则
- AI代理在产业变革中的5个实际应用案例
- 构建端到端数据科学作品集项目
- 2026年AI编码代理的十大开源基准测试
- 超越模板的Python数据类
- 从谷歌工程师不可或缺的提示中可以学到什么
- 仅用3条命令即可将Qwen3.8-27B作为本地AI编码代理运行
#content_wrapper end
© 2026
Guiding Tech Media
|
关于
联系我们
广告合作
隐私政策
服务条款
2026年8月28日由Olumide Shittu发布
blank
不，谢谢！
/.main_wrapper
<script defer type="text/javascript" src="https://s7.addthis.com/js/300/addthis_widget.js#pubid=gpsaddthis"></script>
noptimize
/noptimize