尧图网站建设 
后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载PostgresML 在 2.6.0 版本起为pgml.transform引入了 GPTQ 与 GGML 两种量化模型支持让你可以直接在 PostgreSQL 中调用 Hugging Face 上经过 4-bit / 5-bit / 8-bit 量化的 LLaMA、Falcon、MPT 等大语言模型用更少的显存和内存跑起更大的模型。本文以官方发布公告为主体结合仓库源码剖析量化原理、参数含义与自动路由机制读完你就能在 GPU 和 CPU 上分别配置并调优量化模型推理。为什么 LLM 需要量化大语言模型LLM之所以大是因为其内部神经网络层由海量参数weights 与 biases构成。这些参数通常以单个 32 位浮点数表示一个拥有 15 亿参数的 GPT-2 模型就需要4 bytes × 1,500,000,000 6GB内存而 LLaMA、Alpaca、Guanaco 这类当时领先的开源模型拥有 650 亿参数直接以 float32 加载需要约 260GB 内存——这还没有算上存储输入输出数据所需的空间。在实际推理时内存与 CPU 之间的带宽往往成为瓶颈而不是处理器核心数或核心速度处理器会因为等数据而饿死。降低内存占用与带宽需求的最直接办法就是使用更小的数据类型例如 16 位浮点数可以让模型在内存中的体积减半。16 位有几种互相竞争的格式标准其中 NVIDIA 在新一代硬件上引入了 bfloat16它保留了 float32 的完整指数范围但牺牲了约 2/3 的尾数精度。大量研究表明这是一个不错的质量/性能折中——截断最低有效位时模型输出不会出现剧烈劣化。三种格式的位布局对比如下格式尾数Significand指数Exponentbfloat168 bits8 bitsfloat1611 bits5 bitsfloat3224 bits8 bits在 PostgresML 中你可以通过pgml.transform的torch_dtype参数为 torch 张量选择数据类型。默认是float32也可以使用float16或bfloat16。下面的示例用bfloat16加载 Falcon-7B Instruct 模型SELECT pgml.transform( task { model: tiiuae/falcon-7b-instruct, device_map: auto, torch_dtype: bfloat16, trust_remote_code: true }::JSONB, args { max_new_tokens: 100 }::JSONB, inputs ARRAY[ Complete the story: Once upon a time, ] ) AS result;在该公告的实测中这段查询在 bfloat16 下耗时约 4.5 秒。对于交互式应用来说这仍偏慢因此值得进一步探索更激进的优化手段。关于torch_dtype的取值边界可以参考仓库 transformers.py 中的DTYPE_MAP它把字符串映射为 torch 原生 dtype支持uint8、int8、int16、int32、int64、bfloat16、float16、float32、float64、complex64、complex128、bool等类型create_pipeline在构建模型前会通过convert_dtype完成字符串到 torch dtype 的转换。量化原理从 16 位走向 4 位继续从 16 位降到 8 位甚至 4 位是可行的但无法再依赖硬件加速的浮点运算。若想在更小的类型上获得硬件加速就需要使用带向量化指令集的小整数类型——这就是量化Quantization。量化可以直接作用于已用 32 位浮点训练好的模型把权重转换成更小的整数原语仍然受益于 Intel AVX 这类硬件加速指令集。最简单的量化方式是训练后量化post-training quantization先找出权重的最大值与最小值然后把数值范围等分成整数类型所能容纳的桶数量8 位为 256 桶4 位为 16 桶把每个权重映射到最近的桶。这是最直接的量化思路也是社区工具普遍采用的基础原理。在具体实现上公告提到了两条主线GPTQ源自研究论文《GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers》arXiv:2210.17323专门描述如何在模型以完整 float32 精度训练完成之后再做量化及其权衡。其开源实现被 AutoGPTQ 适配到 Hugging Face Transformers 生态。PostgresML 会在 Hugging Face 模型名包含 GPTQ 时自动使用 AutoGPTQ。GGML另一种量化实现专注于 CPU 优化尤其是 Apple M1 与 M2 芯片。它依赖相同原理但底层实现完全不同。一般经验法则是使用 NVIDIA 硬件且整个模型能放进显存时GPTQ 更快使用 Apple 或 Intel 硬件时GGML 通常更快。社区例如 TheBloke已经把这些量化方法大量应用到 Hugging Face Transformers 库的 LLM 上很多常用模型现在都有更高效的量化版本可供下载——这让你有机会升级到更大的模型或在同样的内存里塞进更多模型。环境准备版本与 Python 依赖要使用 GPTQ 或 GGML需要升级到PostgresML 2.6.0 或更高版本并更新 PostgresML 的 Python 依赖pip install -r requirements.txt从仓库 requirements.txt 可以看到与量化相关的关键依赖auto-gptq仅 Linux且只在 NVIDIA 硬件上运行、ctransformersGGML 模型的推理库、bitsandbytes、transformers、accelerate、xformers仅 Linux / NVIDIA等。公告特别提示AutoGPTQ 官方提供预编译的 Python wheels如果 pip 从源码构建安装遇到困难可以直接下载对应平台的 wheel 安装。GPU 支持按模型名自动路由PostgresML 会自动使用 GPTQ 或 GGML——只要 Hugging Face 模型名中包含对应库的名称。默认情况下PostgresML 会优先使用 CUDA 设备。三个示例在同一台 RTX 3090 上、全部模型都放得进显存的前提下耗时差异极小GPTQ 模型约 281msSELECT pgml.transform( task { task: text-generation, model: mlabonne/gpt2-GPTQ-4bit, model_basename: gptq_model-4bit-128g, use_triton: true, use_safetensors: true }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );这里的model_basename用于指定权重文件名前缀use_triton启用 Triton 内核加速use_safetensors使用 safetensors 格式加载——这些参数会原样透传给底层 AutoGPTQ / Transformers 加载逻辑。GGML 模型约 252msSELECT pgml.transform( task { task: text-generation, model: marella/gpt-2-ggml }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );未量化的 GPT-2 对照约 280msSELECT pgml.transform( task { task: text-generation, model: gpt2 }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );从源码角度看这种按模型名自动路由的实现位于 transformers.py 的create_pipeline模型名小写后若包含-ggml或-gguf就构造GGMLPipeline内部使用 ctransformers 的AutoModelForCausalLM.from_pretrained见 transformers.py否则构造StandardPipeline走 Hugging Face Transformers 的AutoModelForCausalLM加载路径并在检测到quantization_config参数时构造GPTQConfig传入模型见 transformers.py。CPU 支持量化带来数量级差异向task传入device: cpu即可强制在 CPU 上执行。GGML 模型在 CPU 上约 267msSELECT pgml.transform( task { task: text-generation, model: marella/gpt-2-ggml, device: cpu }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );未量化的 GPT-2 在 CPU 上约 33.2 秒SELECT pgml.transform( task { task: text-generation, model: gpt2, device: cpu }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );两者一对比差距立现同一台 Intel i9-13900 上量化版本比原生 float32 版本快了接近 100 倍甚至可以说CPU 上的量化版本速度与 GPU 上的原生版本相当。对纯 CPU 用户来说这是巨大的收益。设备选择的默认逻辑同样在 transformers.py 的ensure_device中只有当task里既没传device也没传device_map时才会根据torch.cuda.is_available()自动选择cuda:pid 对设备数的余数或cpu。更大的模型补充 model_type 等参数Hugging Face 和这些库提供了大量优秀模型但并非所有模型都带有完整的config.json此时你可能需要在task中补充额外参数例如model_type。LLaMATheBloke/robin-7B-v2-GGML约 3.4 秒SELECT pgml.transform( task { task: text-generation, model: TheBloke/robin-7B-v2-GGML, model_type: llama }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );MPTTheBloke/MPT-7B-Storywriter-GGML约 4.2 秒SELECT pgml.transform( task { task: text-generation, model: TheBloke/MPT-7B-Storywriter-GGML, model_type: mpt }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );FalconTheBloke/falcon-40b-instruct-GPTQ约 4.2 秒SELECT pgml.transform( task { task: text-generation, model: TheBloke/falcon-40b-instruct-GPTQ, trust_remote_code: true }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );注意 Falcon 40B 是 400 亿参数级别的模型在 requirements.txt 的依赖支持下用 GPTQ 量化后即可加载推理。trust_remote_code: true表示允许执行模型仓库附带的自定义代码仅在你信任该模型来源时使用。指定具体量化文件model_file 参数许多模型会在同一仓库下发布多种量化方法的产物例如 4-bit、5-bit、8-bit 各自保存成不同的文件。你可以在task中通过model_file参数指定具体使用哪个量化文件具体文件名需要查阅模型卡model card确认。例如选择 MPT-7B-Storywriter 的q8_08-bitGGML 文件SELECT pgml.transform( task { task: text-generation, model: TheBloke/MPT-7B-Storywriter-GGML, model_file: mpt-7b-storywriter.ggmlv3.q8_0.bin }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );这些参数会通过taskJSON 透传给 ctransformers 的from_pretrained见 transformers.py 中GGMLPipeline.__init__对model、task、device之外的其余参数原样转发因此凡是 ctransformers 支持的加载参数都可以这样传入。完整示例Vicuna-7B 的端到端配置PostgresML 的目标是为底层库提供灵活统一的 APItask中的参数可以直接透传给AutoModel.from_pretrained(...)args中的参数则在推理时传给生成的 pipeline。PostgresML 会基于task参数对模型做缓存因此对相同 task 的重复调用会尽可能快。不同模型可用的参数取决于其推理实现具体需要查看模型卡与底层库文档。公告附带了一个完整的 Vicuna-7B GGML 示例由社区成员 Tostino 提供SELECT pgml.transform( task { task: text-generation, model: TheBloke/vicuna-7B-v1.3-GGML, model_type: llama, model_file: vicuna-7b-v1.3.ggmlv3.q5_K_M.bin, gpu_layers: 256 }::JSONB, inputs ARRAY[ $$A chat between a curious user and an artificial intelligence assistant. The assistant gives helpful, detailed, and polite answers to the users questions. USER: Please write an intro to a story about a woman living in New York. ASSISTANT:$$ ], args { max_new_tokens: 512, threads: 16, stop: [USER:,USER] }::JSONB );这个示例集中体现了量化模型的调优手法model_type: llama补齐模型架构信息model_file精确选择q5_K_M5-bit K 量化权重文件gpu_layers: 256指定将 256 层计算放入 GPU其余留在 CPU实现 GPU/CPU 混合推理args中的max_new_tokens、threadsCPU 线程数、stop遇到USER:即停止生成控制推理行为输入使用$$...$$美元符引用字符串以便在 SQL 中嵌入多行对话文本。源码视角缓存、设备与故障排查如果想深入理解这套机制可以沿着以下链路阅读仓库SQL 入口pgml.transform在 api.rs 中以#[pg_extern]暴露多个重载JSONB 或字符串形式的 task、普通或对话式输入执行前会调用whitelist::verify_task校验任务随后调用 Rust 侧的transform。Rust → Python 桥接transform.rs 将 task/args/inputs 序列化为 JSON 字符串通过 pyo3 调用 Python 模块中的transform函数返回结果再反序列化为serde_json::Value。Python 核心transformers.py 的transform用排序后的 task 键值对拼出缓存 key命中__cache_transform_pipeline_by_task则直接复用 pipeline未命中则调用create_pipeline按模型名路由到 GGMLPipeline 或 StandardPipeline。GPU 占用确认公告特别提醒模型会缓存在 GPU 上只要数据库连接保持打开模型就会留在进程列表中可以用nvidia-smi检查 GPU 是否按预期被占用。仓库中还提供了pgml.clear_gpu_cache见 api.rs用于按内存阈值主动释放显存缓存。公告也坦率地指出了当前的工程权衡GPU 加速可能还依赖编译依赖项、下载 Python wheels 以及为不默认跑 GPU 的库如 Hugging Face Transformers传入正确参数。PostgresML 团队测试了大量模型与配置以保证云服务的广泛兼容缺失的场景欢迎以 GitHub issue 形式反馈。同时虽然 Python 依赖让迭代与采纳最新创新变得很快但它在性能与健壮性上不如原生代码——社区正在把大量此类功能迁移到 rustformers 等原生实现PostgresML 也计划在通往 3.0 的路上逐步移除 Python。结语GPTQ 与 GGML 对性能和内存占用是双重红利GPU 上 GPTQ 通常占优Apple / Intel 硬件上 GGML 往往更快。如果你还没有目标模型可以查阅 Hugging Face 上的开源 LLM 排行榜并直接搜索 GPTQ 与 GGML 关键词寻找社区量化版本如果想要的模型没有量化版也可以自行量化并分享回社区。结合torch_dtype、model_type、model_file、gpu_layers、device等参数PostgresML 让这一切都可以在一条 SQL 查询内完成。赞分享后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载相关推荐工具输出摘要提示词设计HelloCodeAgentCli 如何用 summarize_observation 控制 Code Agent 的上下文预算工具输出摘要提示词设计HelloCodeAgentCli 如何用 summarize_observation 控制 Code Agent 的上下文预算 导读后端人工智能机器学习RAG向量数据库LMDeploy 使用 llm-compressor 量化模型AWQ/GPTQ 的量化、部署与精度评测实战指南LMDeploy 使用 llm compressor 量化模型AWQ/GPTQ 的量化、部署与精度评测实战指南 本指南介绍如何借助 vllm project/人工智能大模型模型推理服务推理引擎本地部署模型量化Yi 模型 GPTQ 量化实战使用 AutoGPTQ 对 Yi-1.5-6B-Chat 进行 8-bit 量化、保存与推理Yi 模型 GPTQ 量化实战使用 AutoGPTQ 对 Yi 1.5 6B Chat 进行 8 bit 量化、保存与推理 本文以 01 ai 开源仓库中的大模型微调模型量化多模态本地部署上一篇30 分钟做出可引导的 OpenCore EFIOpCore Simplify 黑苹果配置指南下一篇XUnity.AutoTranslator打破语言障碍的Unity游戏实时翻译终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PostgresML 量化 LLM 实战：在 pgml.transform 中使用 GPTQ 与 GGML 模型
后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载PostgresML 在 2.6.0 版本起为pgml.transform引入了 GPTQ 与 GGML 两种量化模型支持让你可以直接在 PostgreSQL 中调用 Hugging Face 上经过 4-bit / 5-bit / 8-bit 量化的 LLaMA、Falcon、MPT 等大语言模型用更少的显存和内存跑起更大的模型。本文以官方发布公告为主体结合仓库源码剖析量化原理、参数含义与自动路由机制读完你就能在 GPU 和 CPU 上分别配置并调优量化模型推理。为什么 LLM 需要量化大语言模型LLM之所以大是因为其内部神经网络层由海量参数weights 与 biases构成。这些参数通常以单个 32 位浮点数表示一个拥有 15 亿参数的 GPT-2 模型就需要4 bytes × 1,500,000,000 6GB内存而 LLaMA、Alpaca、Guanaco 这类当时领先的开源模型拥有 650 亿参数直接以 float32 加载需要约 260GB 内存——这还没有算上存储输入输出数据所需的空间。在实际推理时内存与 CPU 之间的带宽往往成为瓶颈而不是处理器核心数或核心速度处理器会因为等数据而饿死。降低内存占用与带宽需求的最直接办法就是使用更小的数据类型例如 16 位浮点数可以让模型在内存中的体积减半。16 位有几种互相竞争的格式标准其中 NVIDIA 在新一代硬件上引入了 bfloat16它保留了 float32 的完整指数范围但牺牲了约 2/3 的尾数精度。大量研究表明这是一个不错的质量/性能折中——截断最低有效位时模型输出不会出现剧烈劣化。三种格式的位布局对比如下格式尾数Significand指数Exponentbfloat168 bits8 bitsfloat1611 bits5 bitsfloat3224 bits8 bits在 PostgresML 中你可以通过pgml.transform的torch_dtype参数为 torch 张量选择数据类型。默认是float32也可以使用float16或bfloat16。下面的示例用bfloat16加载 Falcon-7B Instruct 模型SELECT pgml.transform( task { model: tiiuae/falcon-7b-instruct, device_map: auto, torch_dtype: bfloat16, trust_remote_code: true }::JSONB, args { max_new_tokens: 100 }::JSONB, inputs ARRAY[ Complete the story: Once upon a time, ] ) AS result;在该公告的实测中这段查询在 bfloat16 下耗时约 4.5 秒。对于交互式应用来说这仍偏慢因此值得进一步探索更激进的优化手段。关于torch_dtype的取值边界可以参考仓库 transformers.py 中的DTYPE_MAP它把字符串映射为 torch 原生 dtype支持uint8、int8、int16、int32、int64、bfloat16、float16、float32、float64、complex64、complex128、bool等类型create_pipeline在构建模型前会通过convert_dtype完成字符串到 torch dtype 的转换。量化原理从 16 位走向 4 位继续从 16 位降到 8 位甚至 4 位是可行的但无法再依赖硬件加速的浮点运算。若想在更小的类型上获得硬件加速就需要使用带向量化指令集的小整数类型——这就是量化Quantization。量化可以直接作用于已用 32 位浮点训练好的模型把权重转换成更小的整数原语仍然受益于 Intel AVX 这类硬件加速指令集。最简单的量化方式是训练后量化post-training quantization先找出权重的最大值与最小值然后把数值范围等分成整数类型所能容纳的桶数量8 位为 256 桶4 位为 16 桶把每个权重映射到最近的桶。这是最直接的量化思路也是社区工具普遍采用的基础原理。在具体实现上公告提到了两条主线GPTQ源自研究论文《GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers》arXiv:2210.17323专门描述如何在模型以完整 float32 精度训练完成之后再做量化及其权衡。其开源实现被 AutoGPTQ 适配到 Hugging Face Transformers 生态。PostgresML 会在 Hugging Face 模型名包含 GPTQ 时自动使用 AutoGPTQ。GGML另一种量化实现专注于 CPU 优化尤其是 Apple M1 与 M2 芯片。它依赖相同原理但底层实现完全不同。一般经验法则是使用 NVIDIA 硬件且整个模型能放进显存时GPTQ 更快使用 Apple 或 Intel 硬件时GGML 通常更快。社区例如 TheBloke已经把这些量化方法大量应用到 Hugging Face Transformers 库的 LLM 上很多常用模型现在都有更高效的量化版本可供下载——这让你有机会升级到更大的模型或在同样的内存里塞进更多模型。环境准备版本与 Python 依赖要使用 GPTQ 或 GGML需要升级到PostgresML 2.6.0 或更高版本并更新 PostgresML 的 Python 依赖pip install -r requirements.txt从仓库 requirements.txt 可以看到与量化相关的关键依赖auto-gptq仅 Linux且只在 NVIDIA 硬件上运行、ctransformersGGML 模型的推理库、bitsandbytes、transformers、accelerate、xformers仅 Linux / NVIDIA等。公告特别提示AutoGPTQ 官方提供预编译的 Python wheels如果 pip 从源码构建安装遇到困难可以直接下载对应平台的 wheel 安装。GPU 支持按模型名自动路由PostgresML 会自动使用 GPTQ 或 GGML——只要 Hugging Face 模型名中包含对应库的名称。默认情况下PostgresML 会优先使用 CUDA 设备。三个示例在同一台 RTX 3090 上、全部模型都放得进显存的前提下耗时差异极小GPTQ 模型约 281msSELECT pgml.transform( task { task: text-generation, model: mlabonne/gpt2-GPTQ-4bit, model_basename: gptq_model-4bit-128g, use_triton: true, use_safetensors: true }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );这里的model_basename用于指定权重文件名前缀use_triton启用 Triton 内核加速use_safetensors使用 safetensors 格式加载——这些参数会原样透传给底层 AutoGPTQ / Transformers 加载逻辑。GGML 模型约 252msSELECT pgml.transform( task { task: text-generation, model: marella/gpt-2-ggml }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );未量化的 GPT-2 对照约 280msSELECT pgml.transform( task { task: text-generation, model: gpt2 }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );从源码角度看这种按模型名自动路由的实现位于 transformers.py 的create_pipeline模型名小写后若包含-ggml或-gguf就构造GGMLPipeline内部使用 ctransformers 的AutoModelForCausalLM.from_pretrained见 transformers.py否则构造StandardPipeline走 Hugging Face Transformers 的AutoModelForCausalLM加载路径并在检测到quantization_config参数时构造GPTQConfig传入模型见 transformers.py。CPU 支持量化带来数量级差异向task传入device: cpu即可强制在 CPU 上执行。GGML 模型在 CPU 上约 267msSELECT pgml.transform( task { task: text-generation, model: marella/gpt-2-ggml, device: cpu }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );未量化的 GPT-2 在 CPU 上约 33.2 秒SELECT pgml.transform( task { task: text-generation, model: gpt2, device: cpu }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );两者一对比差距立现同一台 Intel i9-13900 上量化版本比原生 float32 版本快了接近 100 倍甚至可以说CPU 上的量化版本速度与 GPU 上的原生版本相当。对纯 CPU 用户来说这是巨大的收益。设备选择的默认逻辑同样在 transformers.py 的ensure_device中只有当task里既没传device也没传device_map时才会根据torch.cuda.is_available()自动选择cuda:pid 对设备数的余数或cpu。更大的模型补充 model_type 等参数Hugging Face 和这些库提供了大量优秀模型但并非所有模型都带有完整的config.json此时你可能需要在task中补充额外参数例如model_type。LLaMATheBloke/robin-7B-v2-GGML约 3.4 秒SELECT pgml.transform( task { task: text-generation, model: TheBloke/robin-7B-v2-GGML, model_type: llama }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );MPTTheBloke/MPT-7B-Storywriter-GGML约 4.2 秒SELECT pgml.transform( task { task: text-generation, model: TheBloke/MPT-7B-Storywriter-GGML, model_type: mpt }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );FalconTheBloke/falcon-40b-instruct-GPTQ约 4.2 秒SELECT pgml.transform( task { task: text-generation, model: TheBloke/falcon-40b-instruct-GPTQ, trust_remote_code: true }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );注意 Falcon 40B 是 400 亿参数级别的模型在 requirements.txt 的依赖支持下用 GPTQ 量化后即可加载推理。trust_remote_code: true表示允许执行模型仓库附带的自定义代码仅在你信任该模型来源时使用。指定具体量化文件model_file 参数许多模型会在同一仓库下发布多种量化方法的产物例如 4-bit、5-bit、8-bit 各自保存成不同的文件。你可以在task中通过model_file参数指定具体使用哪个量化文件具体文件名需要查阅模型卡model card确认。例如选择 MPT-7B-Storywriter 的q8_08-bitGGML 文件SELECT pgml.transform( task { task: text-generation, model: TheBloke/MPT-7B-Storywriter-GGML, model_file: mpt-7b-storywriter.ggmlv3.q8_0.bin }::JSONB, inputs ARRAY[ Once upon a time, ], args {max_new_tokens: 32}::JSONB );这些参数会通过taskJSON 透传给 ctransformers 的from_pretrained见 transformers.py 中GGMLPipeline.__init__对model、task、device之外的其余参数原样转发因此凡是 ctransformers 支持的加载参数都可以这样传入。完整示例Vicuna-7B 的端到端配置PostgresML 的目标是为底层库提供灵活统一的 APItask中的参数可以直接透传给AutoModel.from_pretrained(...)args中的参数则在推理时传给生成的 pipeline。PostgresML 会基于task参数对模型做缓存因此对相同 task 的重复调用会尽可能快。不同模型可用的参数取决于其推理实现具体需要查看模型卡与底层库文档。公告附带了一个完整的 Vicuna-7B GGML 示例由社区成员 Tostino 提供SELECT pgml.transform( task { task: text-generation, model: TheBloke/vicuna-7B-v1.3-GGML, model_type: llama, model_file: vicuna-7b-v1.3.ggmlv3.q5_K_M.bin, gpu_layers: 256 }::JSONB, inputs ARRAY[ $$A chat between a curious user and an artificial intelligence assistant. The assistant gives helpful, detailed, and polite answers to the users questions. USER: Please write an intro to a story about a woman living in New York. ASSISTANT:$$ ], args { max_new_tokens: 512, threads: 16, stop: [USER:,USER] }::JSONB );这个示例集中体现了量化模型的调优手法model_type: llama补齐模型架构信息model_file精确选择q5_K_M5-bit K 量化权重文件gpu_layers: 256指定将 256 层计算放入 GPU其余留在 CPU实现 GPU/CPU 混合推理args中的max_new_tokens、threadsCPU 线程数、stop遇到USER:即停止生成控制推理行为输入使用$$...$$美元符引用字符串以便在 SQL 中嵌入多行对话文本。源码视角缓存、设备与故障排查如果想深入理解这套机制可以沿着以下链路阅读仓库SQL 入口pgml.transform在 api.rs 中以#[pg_extern]暴露多个重载JSONB 或字符串形式的 task、普通或对话式输入执行前会调用whitelist::verify_task校验任务随后调用 Rust 侧的transform。Rust → Python 桥接transform.rs 将 task/args/inputs 序列化为 JSON 字符串通过 pyo3 调用 Python 模块中的transform函数返回结果再反序列化为serde_json::Value。Python 核心transformers.py 的transform用排序后的 task 键值对拼出缓存 key命中__cache_transform_pipeline_by_task则直接复用 pipeline未命中则调用create_pipeline按模型名路由到 GGMLPipeline 或 StandardPipeline。GPU 占用确认公告特别提醒模型会缓存在 GPU 上只要数据库连接保持打开模型就会留在进程列表中可以用nvidia-smi检查 GPU 是否按预期被占用。仓库中还提供了pgml.clear_gpu_cache见 api.rs用于按内存阈值主动释放显存缓存。公告也坦率地指出了当前的工程权衡GPU 加速可能还依赖编译依赖项、下载 Python wheels 以及为不默认跑 GPU 的库如 Hugging Face Transformers传入正确参数。PostgresML 团队测试了大量模型与配置以保证云服务的广泛兼容缺失的场景欢迎以 GitHub issue 形式反馈。同时虽然 Python 依赖让迭代与采纳最新创新变得很快但它在性能与健壮性上不如原生代码——社区正在把大量此类功能迁移到 rustformers 等原生实现PostgresML 也计划在通往 3.0 的路上逐步移除 Python。结语GPTQ 与 GGML 对性能和内存占用是双重红利GPU 上 GPTQ 通常占优Apple / Intel 硬件上 GGML 往往更快。如果你还没有目标模型可以查阅 Hugging Face 上的开源 LLM 排行榜并直接搜索 GPTQ 与 GGML 关键词寻找社区量化版本如果想要的模型没有量化版也可以自行量化并分享回社区。结合torch_dtype、model_type、model_file、gpu_layers、device等参数PostgresML 让这一切都可以在一条 SQL 查询内完成。赞分享后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载相关推荐工具输出摘要提示词设计HelloCodeAgentCli 如何用 summarize_observation 控制 Code Agent 的上下文预算工具输出摘要提示词设计HelloCodeAgentCli 如何用 summarize_observation 控制 Code Agent 的上下文预算 导读后端人工智能机器学习RAG向量数据库LMDeploy 使用 llm-compressor 量化模型AWQ/GPTQ 的量化、部署与精度评测实战指南LMDeploy 使用 llm compressor 量化模型AWQ/GPTQ 的量化、部署与精度评测实战指南 本指南介绍如何借助 vllm project/人工智能大模型模型推理服务推理引擎本地部署模型量化Yi 模型 GPTQ 量化实战使用 AutoGPTQ 对 Yi-1.5-6B-Chat 进行 8-bit 量化、保存与推理Yi 模型 GPTQ 量化实战使用 AutoGPTQ 对 Yi 1.5 6B Chat 进行 8 bit 量化、保存与推理 本文以 01 ai 开源仓库中的大模型微调模型量化多模态本地部署上一篇30 分钟做出可引导的 OpenCore EFIOpCore Simplify 黑苹果配置指南下一篇XUnity.AutoTranslator打破语言障碍的Unity游戏实时翻译终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考