Hugging Face on KnightLi的博客

Gemma 4 12B 怎么用？Hugging Face 模型卡和本地加载指南

Sat, 06 Jun 2026 17:34:59 +0800

Google 已经把 google/gemma-4-12B 放到 Hugging Face 上。这个模型卡比发布博客更偏开发者视角，里面写清楚了 Gemma 4 12B Unified 的模型定位、架构、输入模态、上下文长度、Transformers 用法、thinking mode 和使用限制。

如果你只是想知道“Gemma 4 12B 是什么”，看发布博客就够了。如果你准备真的下载、加载、接入应用，Hugging Face 模型卡更值得认真看。尤其是本地部署时，12B、256K、量化、显存和上下文长度这些词，不能只看参数表，要放到自己的机器上算一遍。

这是什么模型

google/gemma-4-12B 是 Gemma 4 系列里的 12B Unified 模型。它属于 dense model，不是 MoE。模型卡里给出的关键参数包括：

总参数量：11.95B
层数：48
sliding window：1024 tokens
context length：256K tokens
vocabulary size：262K
支持模态：文本、图像、音频
许可：Apache 2.0

这里的 Unified 是重点。它指的是 Gemma 4 12B 的 encoder-free 多模态架构：图像 patch 和音频波形会通过轻量线性层直接投到 LLM embedding space，而不是先经过独立视觉 encoder 或音频 encoder。

这和一些传统多模态模型不一样。传统做法通常是“图像 encoder / 音频 encoder + LLM”。Gemma 4 12B 的目标是减少外置 encoder，让多模态输入更直接地进入单一 decoder-only transformer。

和 Gemma 4 系列其他模型怎么选

Gemma 4 系列覆盖多个尺寸：

E2B
E4B
12B Unified
26B A4B MoE
31B Dense

更接地气地看，可以先按部署门槛和任务强度分层：

模型	大致定位	更适合做什么	本地部署预期
E2B	最轻量的边缘模型	手机、嵌入式设备、轻量问答、功能 demo	最容易跑，资源压力小，但能力上限也最低
E4B	边缘和本地轻量增强版	小型本地助手、移动端多模态、低成本私有应用	普通电脑更容易尝试，适合作为入门版本
12B Unified	中型 dense 多模态模型	本地代码助手、图片问答、音频理解、私有资料分析	需要更认真看显存和量化，16GB 级显存或统一内存更现实
26B A4B MoE	更大的 MoE 模型，每次只激活部分参数	更强推理、多模态任务、服务端应用	部署复杂度更高，适合工作站或小型服务器
31B Dense	更大的 dense 模型	更强文本、推理、代码和多模态能力	本地门槛明显更高，更偏高端显卡或服务器

12B Unified 的位置比较特别：它比 E2B、E4B 更强，又比 26B、31B 更容易放进个人工作站或高配笔记本里；同时它支持文本、图像和音频输入，目标不是替代云端旗舰模型，而是给本地开发环境一个“够强、还能折腾”的多模态基座。

简单选型可以这样看：

机器一般、只是想先体验：先试 E4B；
有 16GB 级别显存，或者 Apple Silicon 较大的统一内存：可以重点看 12B Unified；
要做团队服务、长时间跑任务、追求更强推理能力：再考虑 26B A4B MoE 或 31B Dense；
完全 CPU-only 或小内存核显机器：别从 12B 开始，体验大概率会比较痛苦。

256K 上下文意味着什么

模型卡显示，Gemma 4 12B 支持 256K tokens 上下文。

这对几类任务有用：

长文档分析；
多文件代码阅读；
长对话上下文；
Agent 工具调用历史；
多图、多段文本混合输入；
长音频或视频抽帧后的综合理解。

不过，长上下文不是免费午餐。上下文越长，显存、内存、KV cache、推理时间和注意力成本都会上升。即使模型支持 256K，实际本地运行时也要看你的硬件、量化方式、推理框架和 batch 设置。

更实际的用法是：把 256K 当成上限能力，而不是每次都塞满。对本地部署来说，检索、分块、缓存和上下文裁剪仍然很重要。

本地部署先看硬件和量化

12B 听起来不像 70B 那么夸张，但它也不是随便一台电脑就能舒服运行。

如果按 bf16 或 fp16 粗算，12B 参数光权重就接近 24GB，还没算运行时开销、KV cache、多模态输入和长上下文。换句话说，模型卡里的 256K 更像能力上限，不是说 16GB 显存机器可以无压力塞满 256K 上下文。

比较现实的预期是：

24GB 显存：更适合原始精度或较长上下文测试，但仍要控制 batch 和上下文长度；
16GB 显存：更建议走量化，适合日常本地推理、代码助手、图片问答和较短上下文任务；
Apple Silicon 统一内存：如果内存够大，可以尝试本地跑，但速度和框架优化很关键；
8GB 显存：可以等量化版本或缩短上下文测试，不要期待完整多模态和长上下文体验；
CPU-only 或普通小内存核显：更适合试 E2B、E4B，12B 会很慢，更多是“能不能跑起来”的实验。

量化的意义很简单：用一点精度损失，换更低显存占用和更容易部署。对个人本地使用来说，4-bit、8-bit 量化通常比原始精度更实用。真正要长期用，还要看推理框架是否支持这个模型的多模态输入、thinking mode、长上下文和工具调用。

所以本地部署的顺序不建议一上来就追求“满血 256K”。更稳的路线是：

先用 Transformers 把 -it 版本加载起来，确认模型和环境没问题；
再找适合自己显卡或 Apple Silicon 的量化/推理方案；
把上下文长度从小到大压测，不要直接拉满；
最后再接入自己的笔记、代码库、图片或音频流程。

支持哪些能力

模型卡把 Gemma 4 的核心能力列得比较完整。对 12B Unified 来说，比较关键的是：

Thinking：支持可配置 reasoning mode；
Long Context：最高 256K tokens；
Image Understanding：支持对象识别、文档/PDF 解析、屏幕和 UI 理解、图表理解、OCR、手写识别等；
Video Understanding：通过处理视频帧序列来理解视频；
Interleaved Multimodal Input：可以在同一个 prompt 里自由混合文本和图像；
Function Calling：原生支持结构化工具调用；
Coding：代码生成、补全和修正；
Multilingual：支持多语言，预训练覆盖 140+ 语言；
Audio：支持自动语音识别和语音到翻译文本。

换成开发者语言，它适合做这些事：

本地代码助手；
图像问答；
截图和 UI 理解；
文档 OCR 和表格理解；
音频转写；
轻量视频理解；
带工具调用的 Agent demo；
私有资料分析。

但它仍然是生成文本输出的模型，不是图像生成、语音合成或完整视频生成模型。

Transformers 里怎么加载

模型卡给了 Transformers 入口。最小加载方式大致是：

from transformers import AutoProcessor, AutoModelForMultimodalLM

MODEL_ID = "google/gemma-4-12B-it"

processor = AutoProcessor.from_pretrained(MODEL_ID)
model = AutoModelForMultimodalLM.from_pretrained(
    MODEL_ID,
    dtype="auto",
    device_map="auto"
)

注意这里示例使用的是 instruction-tuned 版本：

`1`	`google/gemma-4-12B-it`

如果你只是做应用和对话，大多数情况下应该优先用 -it 版本。基础预训练模型更适合继续训练、研究或做特殊适配。

安装依赖可以从：

`1`	`pip install -U transformers torch accelerate`

如果要处理图像、音频或视频，还需要额外的依赖，例如：

`1`	`pip install -U transformers torch torchvision librosa accelerate`

实际部署时，还要根据 CUDA、PyTorch、显卡驱动和量化方案调整环境。模型卡的示例更适合当作起点，不等于所有机器复制后都能直接流畅运行。

Thinking mode 怎么开关

Gemma 4 支持 thinking mode。模型卡里提到，可以用控制 token 管理思考过程。

如果使用 Transformers 这类库，很多 chat template 的细节会被库处理掉。常见做法是通过模板参数控制：

inputs = processor.apply_chat_template(
    messages,
    tokenize=True,
    return_dict=True,
    return_tensors="pt",
    add_generation_prompt=True,
    enable_thinking=False
).to(model.device)

把 enable_thinking 设置为 True，就可以让模型进入 reasoning 模式。关闭 thinking mode 后，模型更适合快速回答、简单分类、短文本处理等场景。

实际使用时可以这样选：

复杂推理、代码修改、长文档分析：开启 thinking；
简单问答、摘要、提取字段、批量处理：关闭 thinking；
对延迟敏感的实时应用：先关闭 thinking 测速度，再按任务调优。

Thinking mode 不是越多越好。它会增加输出和计算成本，适合在需要推理质量时打开。

多模态输入顺序也有讲究

模型卡的 best practices 里提到，模态顺序会影响效果。

对于图像或视频任务，通常可以把图像或视频放在文本问题前面，让模型先看到视觉输入，再回答问题。例如：

messages = [
    {
        "role": "user",
        "content": [
            {"type": "image", "url": "https://example.com/image.png"},
            {"type": "text", "text": "What is shown in this image?"}
        ]
    }
]

音频任务则可以根据场景安排文本说明和音频位置。比如转写时，先给明确指令，再放音频输入，会让输出格式更稳定。

这些细节看起来小，但在真实应用里很重要。多模态模型不是只要“把文件塞进去”就能稳定工作，输入顺序、提示词、采样参数和输出解析都会影响结果。

Benchmark 该怎么看

模型卡列了不少 benchmark。12B Unified 的几个结果包括：

MMLU Pro：77.2%
AIME 2026 no tools：77.5%
LiveCodeBench v6：72.0%
Codeforces ELO：1659
GPQA Diamond：78.8%
MMMU Pro：69.1%
MATH-Vision：79.7%
MRCR v2 8 needle 128k：43.4%

这些数字说明 Gemma 4 12B 在推理、代码、视觉和长上下文上都有不错基础。但 benchmark 不是实际体验的全部。

如果你要用它做中文写作、企业知识库、私有代码库问答、语音转写或本地 Agent，仍然需要自己测：

中文表达是否自然；
领域术语是否稳定；
多轮上下文是否保持；
工具调用格式是否可靠；
长文档检索是否会遗漏；
本地硬件上延迟能不能接受。

模型卡能告诉你上限和能力方向，不能替你完成业务验证。

使用限制和安全注意

Gemma 4 12B 是开放模型，许可证是 Apache 2.0，这对开发者很友好。但开放权重不等于没有风险。

你仍然需要关注：

模型可能生成错误信息；
长上下文下可能遗漏关键细节；
多模态输入可能被误读；
代码生成需要审查和测试；
Agent 工具调用需要权限隔离；
涉及个人信息、医疗、法律、金融等场景要额外谨慎。

如果你把 Gemma 4 12B 接到本地文件、命令行、浏览器或数据库上，不要直接给它无限权限。至少要有日志、确认步骤、沙箱和回滚方案。

适合优先尝试的人

我会优先推荐这几类人试 google/gemma-4-12B：

正在做本地多模态助手的开发者；
想在本地跑图像、音频、文本混合任务的人；
做代码助手、桌面 Agent、私有知识库的人；
想研究 encoder-free 多模态架构的人；
有 16GB 级别显存或 Apple Silicon 统一内存设备的人；
想用 Apache 2.0 开放模型做二次开发的团队。

如果你只是普通聊天，或者机器配置比较低，可能应该先试更小的 E2B、E4B，或者直接用托管服务体验。

小结

google/gemma-4-12B 的 Hugging Face 模型卡，真正有价值的地方在于它把 Gemma 4 12B 从“发布新闻”落到了“开发者怎么用”。

它告诉我们：这是一个 12B dense、256K context、encoder-free、多模态输入、Apache 2.0 许可的开放模型。它支持图像、音频、视频和文本输入，支持 thinking mode、function calling、coding 和多语言任务。

但它也不是魔法按钮。真正落地时，你还需要考虑硬件、量化、推理框架、提示词、多模态输入顺序、采样参数、安全边界和业务测试。把模型卡当作起点，而不是终点，才是更靠谱的用法。

参考来源

google/gemma-4-12B - Hugging Face

LongCat-Video-Avatar-1.5：美团开源音频驱动数字人视频模型

Mon, 25 May 2026 07:53:43 +0800

LongCat-Video-Avatar-1.5 是美团 LongCat 团队发布的音频驱动数字人视频生成模型。

项目地址：https://huggingface.co/meituan-longcat/LongCat-Video-Avatar-1.5

它面向的不是普通文生视频，而是“给一段语音和角色条件，生成会说话、动作稳定、身份一致的视频”。从模型卡看，它支持 Audio-Text-to-Video、Audio-Text-Image-to-Video 和 Video Continuation，也支持单路音频和多路音频输入。

截至写作时，Hugging Face 页面显示该模型采用 MIT License，标签包括 audio-text-to-video、audio-image-text-to-video、audio-driven-video-continuation、avatar 和 video-generation。

这次 1.5 版更新了什么

官方模型卡把 LongCat-Video-Avatar 1.5 描述为一个更偏生产可用的开源框架，目标是提升音频驱动人物视频生成的稳定性。

几个重点变化比较明确。

第一，音频编码器从 Wav2Vec2 换成了 Whisper-Large。官方说法是，这能带来更平滑、更自然的唇部动态。实际使用时，对口型同步要求高的场景，应该优先使用 --model_type avatar-v1.5。

第二，它强调长视频稳定性和身份一致性。数字人视频最怕两类问题：短片里嘴型对不上，长片里脸、身体、衣服和动作逐渐漂移。LongCat-Video-Avatar-1.5 的卖点之一，就是同时关注 lip sync、full-body temporal stability 和 identity consistency。

第三，它不只面向真人播报。模型卡提到它可以泛化到动漫、动物、多人互动、拿取物体等更复杂条件。这意味着它的应用范围不局限于新闻播报式数字人，也可以覆盖短剧、唱歌、电商口播、动画角色和动物角色。

第四，它提供 8-step 推理。官方提到通过 DMD2-based step distillation，把推理压到 8 NFE，用来平衡服务成本和画质。这对视频模型很关键，因为视频生成通常算力成本高，推理步数少会直接影响可部署性。

支持哪些任务

从模型卡和示例命令看，主要可以分成三类。

第一类是单人动画。

它支持从音频和文本生成视频，也支持从音频和图片生成视频。常见用途是给一段语音，让某个角色说话、表演或播报。

第二类是视频续写。

示例里通过 --num_segments=5、--ref_img_index=10、--mask_frame_range=3 等参数，让模型在已有角色条件下继续生成更长片段。这个能力适合长口播、课程讲解、唱歌和连续表演。

第三类是多人动画。

多人模式使用 run_demo_avatar_multi_audio_to_video.py，支持多路音频。模型卡里还说明了两种双音频模式：audio_type 设为 para 时是 merge mode，需要两段等长音频；设为 add 时是 concatenation mode，可以按顺序拼接两段音频，并用静音填充间隔。

安装和模型下载

官方推荐先克隆 LongCat-Video 仓库：

1
2

git clone --single-branch --branch main https://github.com/meituan-longcat/LongCat-Video
cd LongCat-Video

然后创建 Python 3.10 环境，并按 CUDA 版本安装 PyTorch。模型卡给出的 CUDA 12.4 示例是：

1
2
3

conda create -n longcat-video python=3.10
conda activate longcat-video
pip install torch==2.6.0+cu124 torchvision==0.21.0+cu124 torchaudio==2.6.0 --index-url https://download.pytorch.org/whl/cu124

后续还需要安装 flash_attn==2.7.4.post1、项目依赖、librosa、ffmpeg 和 requirements_avatar.txt。模型卡说明，配置里默认启用 FlashAttention-2，也可以改成 FlashAttention-3 或 xformers。

模型权重可以用 huggingface-cli 下载：

1
2
3

pip install "huggingface_hub[cli]"
huggingface-cli download meituan-longcat/LongCat-Video --local-dir ./weights/LongCat-Video
huggingface-cli download meituan-longcat/LongCat-Video-Avatar-1.5 --local-dir ./weights/LongCat-Video-Avatar-1.5

这里要注意，它依赖两个权重目录：一个是 LongCat-Video 基础视频生成模型，另一个是 LongCat-Video-Avatar-1.5 数字人模型。

快速推理示例

单人 Audio-Text-to-Video 示例：

torchrun --nproc_per_node=2 run_demo_avatar_single_audio_to_video.py --context_parallel_size=2 --checkpoint_dir=./weights/LongCat-Video-Avatar-1.5 --stage_1=at2v --input_json=assets/avatar/single_example_1.json --use_distill --model_type avatar-v1.5 --use_int8

单人 Audio-Image-to-Video 示例：

torchrun --nproc_per_node=2 run_demo_avatar_single_audio_to_video.py --context_parallel_size=2 --checkpoint_dir=./weights/LongCat-Video-Avatar-1.5  --stage_1=ai2v --input_json=assets/avatar/single_example_1.json --use_distill --model_type avatar-v1.5 --use_int8

多人 Audio-Image-to-Video 示例：

torchrun --nproc_per_node=2 run_demo_avatar_multi_audio_to_video.py --context_parallel_size=2 --checkpoint_dir=./weights/LongCat-Video-Avatar-1.5 --input_json=assets/avatar/multi_example_1.json --use_distill --model_type avatar-v1.5 --use_int8

这些命令有几个共同点：都使用 --model_type avatar-v1.5，都带 --use_distill，并且示例里都打开了 --use_int8。模型卡明确说，--use_distill 是使用 avatar-v1.5 时需要的选项；--use_int8 用于加载 INT8 量化 DiT 模型，降低显存占用，并且只支持 avatar-v1.5。

参数怎么调

模型卡给了几条实用建议。

如果口型同步不够好，可以调高 audio CFG。官方建议区间是 3 到 5，数值更高通常有利于同步。

Prompt 不要写得太短。更长、更具体的描述通常能带来更好的角色一致性和自然度。比如角色外观、动作、场景、衣着、表情都可以写进去。

如果出现重复动作，可以调整 --ref_img_index 和 --mask_frame_range。模型卡建议 --ref_img_index 在 0 到 24 之间更利于一致性，设为 30 有助于减少重复动作；增大 --mask_frame_range 也可能缓解重复，但过大可能引入伪影。

分辨率方面，模型兼容 480P 和 720P，可以通过 --resolution 控制。

适合哪些场景

官方预览覆盖了播报、表演、唱歌、电商营销、多人对话、动画和动物角色。

从实际用途看，它比较适合这些方向：

新闻播报、知识讲解、课程口播。
电商商品介绍和营销短视频。
虚拟主播、虚拟角色短剧、唱歌表演。
动漫或动物角色的音频驱动动画。
多人对话型数字人视频。

它最值得关注的点，是把“口型同步”和“长视频稳定”放在同一个框架里处理。很多数字人模型短片效果可以，但一旦拉长到多段生成，就容易出现身份漂移、动作重复、身体不稳。LongCat-Video-Avatar-1.5 明确把这些问题作为优化目标。

使用时要注意什么

第一，它不是 Hugging Face Inference Provider 上直接可用的托管模型。页面显示目前没有部署到 Inference Provider，实际使用需要自己准备环境、下载权重、运行 LongCat-Video 代码。

第二，本地部署门槛不低。示例命令使用 torchrun --nproc_per_node=2 和 context_parallel_size=2，依赖 PyTorch、FlashAttention、ffmpeg、librosa 和多份模型权重。即使有 INT8 量化，仍然更适合有较强 GPU 环境的用户。

第三，数字人视频涉及肖像、声音、隐私和内容安全。模型卡也提醒开发者需要自行评估准确性、安全性、公平性，并遵守数据保护、隐私和内容安全相关法律法规。用它生成真人形象或商业视频时，授权和合规比技术效果更重要。

第四，不要把模型卡里的通用 Hugging Face “Diffusers/Transformers 使用片段”当成本项目的完整推理方式。真正的 avatar 推理还是应该参考 LongCat-Video 仓库和模型卡里的 run_demo_avatar_* 示例。

小结

LongCat-Video-Avatar-1.5 是一个值得关注的开源数字人视频模型。它不只是做一张脸说话，而是把音频驱动、角色一致性、长视频稳定、多人音频和蒸馏推理放到同一个框架里。

如果你关注虚拟主播、电商口播、课程讲解、动画角色或多人对话视频，它值得测试。但它更像研究和工程团队可以部署调优的模型，不是开箱即用的网页工具。真正落地时，要同时准备算力、素材授权、提示词调参和内容合规流程。

参考资料

LongCat-Video-Avatar-1.5 Hugging Face：https://huggingface.co/meituan-longcat/LongCat-Video-Avatar-1.5
LongCat-Video GitHub：https://github.com/meituan-longcat/LongCat-Video
LongCat-Video-Avatar-1.5 Technical Report：https://github.com/meituan-longcat/LongCat-Video

Gemma 4 E4B 越狱版和官方普通版有什么区别

Sat, 18 Apr 2026 10:20:00 +0800

如果你看到 HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive 这种模型，最关键的一点是：它不是 Google 新发的另一套 Gemma 4，而是建立在官方 google/gemma-4-E4B-it 之上的一个非官方衍生版本，重点是把模型行为调到“更少拒答”。

所以它和普通版真正拉开的，通常不是底层架构，而是对齐策略和输出风格。

这个衍生版模型卡自己说了什么

Hugging Face 模型卡里，这个 HauhauCS 版本明确写了几件事：

它基于 google/gemma-4-E4B-it
它声称“没有改数据集或能力”
它声称变化只是“去掉拒答”
Aggressive 版本被描述为“完全解锁，不会拒绝提示词”

这些是作者自己的表述，不是独立第三方测评结果。但从定位上已经很清楚：这就是一个以“减少安全拒答”为目标的非官方衍生版。

官方版 vs 所谓“越狱版”

维度	官方 `google/gemma-4-E4B-it`	`Gemma-4-E4B-Uncensored-HauhauCS-Aggressive`
来源	Google 官方发布	Hugging Face 第三方衍生版
基础模型	Gemma 4 E4B 指令微调版	同一模型家族，且模型卡明确写明基于 `google/gemma-4-E4B-it`
核心目标	通用助理能力 + 负责任使用框架	尽量减少拒答，让模型继续输出
安全取向	与 Gemma 家族的安全文档、禁止用途政策一致	明确削弱拒答与护栏行为
回答风格	更可能拒绝、转向或保守回答敏感请求	更可能直接继续回答原本会被拦下的问题
风险水平	默认风险更低，但仍不代表绝对安全	默认风险更高，更容易输出不安全或不合规内容
用于产品/团队	更容易通过评审和落地	更难用于公开产品、企业环境或合规场景
额外防护需求	仍需要应用层防护	更依赖你自己做额外的审核、过滤和限制

核心区别是“对齐方式”变了，不是“能力等级”突然变高

很多人会把“uncensored”理解成“更强”，这个判断通常并不准确。

对这种衍生版来说，最先变化的是：

拒答频率
对敏感请求的服从程度
最终答案里剩下多少安全过滤

而不会因为名字里写了 Uncensored，就自动意味着下面这些也一起升级：

模型架构突然更强
上下文窗口突然更大
多模态能力突然更完整
推理上限明显更高

更准确的理解是：它通常只是同一模型家族里，行为调校不同的一版，而不是更高档的新模型。

为什么官方普通版会更保守

Google 的 Gemma 官方资料一直把这个系列放在“负责任 AI 开发”的框架里。Gemma 模型卡会明确谈到误用、有害内容、隐私和偏见等风险；Gemma Prohibited Use Policy 也明确禁止把 Gemma 或其衍生模型用于：

危险、违法或恶意活动
生成有害、误导、欺骗性内容
覆盖或绕过安全过滤

所以官方版并不是“碰巧更保守”，而是它从文档、许可和部署定位上，本来就是那样设计的。

什么情况下普通版更合适

如果你更在意下面这些，优先用官方 google/gemma-4-E4B-it：

产品部署
团队协作
企业或对外场景
较低的政策与法律风险
更容易解释和审查的输出行为

对大多数正常应用来说，这通常才是默认优先项。

什么情况下有人会去试越狱版

选择这类 uncensored 衍生版的人，常见目的通常是：

本地私人实验
测试官方版是否“过早拒答”
角色扮演或更开放的创作场景
对比不同对齐版本的行为差异

但对应的代价也很明确：模型提供方少做的那部分安全约束，需要你自己补回来。

结论

所谓 Gemma 4 E4B “越狱版”和官方普通版，最本质的区别其实是：

官方版追求的是“有护栏的可用能力”
越狱版追求的是“更少拒答的可输出性”

它不自动等于更强，更多只是更放开。

如果你的目标是稳定、可解释、适合部署，先用官方版更合理。
如果你的目标是本地实验，并且你清楚知道安全、合规和输出风险都要自己承担，那这类 uncensored 衍生版可以当成“行为差异版本”来测试，但不应该直接理解成普通版的全面升级替代品。

参考来源

Hugging Face: HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive
Hugging Face: google/gemma-4-E4B-it
Google AI for Developers: Gemma Prohibited Use Policy
Google AI for Developers: Gemma model card

llama-cli -hf 下载 Hugging Face 模型默认保存在哪里

Fri, 17 Apr 2026 14:48:04 +0800

如果你使用的是 llama-cli 直接从 Hugging Face 下载并运行模型，例如：

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

这是 llama.cpp 自带的 Hugging Face 下载能力。新版 llama.cpp 会把 -hf 下载的模型放进标准 Hugging Face Hub 缓存目录。

默认缓存位置

llama-cli -hf 下载的模型缓存位置优先由 LLAMA_CACHE 环境变量控制。如果没有设置 LLAMA_CACHE，则会继续检查 Hugging Face 相关缓存变量，例如 HF_HUB_CACHE、HUGGINGFACE_HUB_CACHE 和 HF_HOME。

如果这些变量都没有设置，常见默认路径如下：

系统	默认缓存目录
Linux	`~/.cache/huggingface/hub`
macOS	`~/.cache/huggingface/hub`
Windows	`%USERPROFILE%\.cache\huggingface\hub`

在 Windows 上，%USERPROFILE% 通常对应：

`1`	`C:\Users\用户名`

所以默认缓存目录大致是：

`1`	`C:\Users\用户名\.cache\huggingface\hub`

想修改 llama-cli 的缓存目录怎么办

可以设置 LLAMA_CACHE，把模型缓存放到指定磁盘或目录。也可以按 Hugging Face 的习惯设置 HF_HOME，此时实际 Hub 缓存目录会是 $HF_HOME/hub。

Windows 临时设置示例：

1
2

set LLAMA_CACHE=D:\models\llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

PowerShell 临时设置示例：

1
2

$env:LLAMA_CACHE="D:\models\llama-cache"
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Linux / macOS 临时设置示例：

1
2

export LLAMA_CACHE=/data/models/llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

小结

llama-cli -hf ... 使用的是 llama.cpp 下载逻辑，但新版默认落到 Hugging Face Hub 缓存。
Linux / macOS 默认：~/.cache/huggingface/hub
Windows 默认：%USERPROFILE%\.cache\huggingface\hub
想换目录：设置 LLAMA_CACHE，或设置 HF_HOME / HF_HUB_CACHE

Windows 下 llama-cli 直连 Hugging Face 报 SSL 证书验证失败怎么办

Fri, 17 Apr 2026 14:20:29 +0800

如果你在 Windows 下运行下面这条命令：

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

并看到类似报错：

1
2

get_repo_commit: error: HTTPLIB failed: SSL server verification failed
error: failed to download model from Hugging Face

通常不是 CUDA 或 llama.cpp 本身有问题，而是程序在当前环境里没有正确拿到系统证书链，导致 HTTPS 校验失败。

从报错来看，ggml-rpc.dll 和 ggml-cpu-alderlake.dll 都已经正常加载，说明运行环境本身大体可用，问题主要集中在模型下载阶段。

最省事的办法：先手动下载模型

如果你只是想尽快跑起来，本地手动下载通常最稳。

打开对应的 Hugging Face 仓库页面。
在 Files and versions 里下载需要的 .gguf 文件。
下载完成后，直接用本地文件路径运行：

`1`	`llama-cli -m C:\Users\knightli\Downloads\gemma-4-e4b-it.gguf`

这样可以绕过 -hf 下载阶段的 SSL 校验问题，适合先验证模型能不能正常推理。

如果还想继续用 `-hf` 自动下载

可以手动指定证书文件路径，让程序在当前会话里找到可用的 CA 证书。

cacert.pem 可以从 curl 官方维护的 CA Extract 页面获取：

页面地址：https://curl.se/docs/caextract.html
直接下载：https://curl.se/ca/cacert.pem

如果用浏览器下载，打开上面的直接下载地址后保存为 cacert.pem 即可。也可以在 PowerShell 里下载到固定目录，例如：

1
2

New-Item -ItemType Directory -Force C:\certs
Invoke-WebRequest -Uri https://curl.se/ca/cacert.pem -OutFile C:\certs\cacert.pem

下载完成后，在命令行里设置：

1
2

set SSL_CERT_FILE=C:\certs\cacert.pem
set CURL_CA_BUNDLE=C:\certs\cacert.pem

再重新执行原命令：

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

如果问题确实来自证书链，这种方式通常能直接解决。

llama.cpp 如何从 Hugging Face 获取 GGUF 模型

Sun, 12 Apr 2026 09:31:38 +0800

llama.cpp 可以直接配合 Hugging Face 上的 GGUF 模型使用，不一定要先手动把文件下载到本地。

如果模型仓库本身已经提供了 GGUF 文件，可以直接在命令行里使用 -hf 参数，例如：

`1`	`llama-cli -hf ggml-org/gemma-3-1b-it-GGUF`

默认情况下，这个参数会从 Hugging Face 下载模型。
如果你使用的是其他兼容 Hugging Face API 的模型托管服务，也可以通过环境变量 MODEL_ENDPOINT 切换下载端点。

需要注意的是，llama.cpp 只能直接使用 GGUF 格式。
如果拿到的是其他格式的模型文件，就需要先用仓库里的 convert_*.py 脚本转换成 GGUF。

Hugging Face 还提供了一些和 llama.cpp 相关的在线工具，常见用途包括：

把模型转换为 GGUF
对模型做量化，减小体积
转换 LoRA 适配器
在线编辑 GGUF 元数据
直接托管 llama.cpp 推理服务

如果只想记住一个最实用的结论：优先找已经提供 GGUF 的模型仓库，然后直接用 llama-cli -hf <user>/<model>，通常是最省事的做法。

Hugging Face 选择 Llama 的 GGUF 模型时，量化怎么选：从 Q8 到 Q2 的实用建议

Sat, 11 Apr 2026 20:07:29 +0800

在 Hugging Face 选择 Llama 的 GGUF 模型时，可以先把量化等级理解成“分辨率”。分辨率越低，占用的 VRAM/RAM 越少，但质量也会逐步下降。

先理解 32、16 和 Q 系列

32：可理解为原始未压缩版本，质量最高，但硬件要求非常高。
16：仍接近原始质量，体积约为 32 的一半，实用性更高。
Q8：从这里开始进入量化版本，通常写作 Q8_0 或 Q8。
Q6、Q5、Q4、Q3、Q2：数字越小，资源占用越低，质量也越容易出现可见损失。

`K_M` / `K_S` 是什么

K_M 和 K_S 表示混合量化策略：

大部分权重使用当前量化等级
一些关键部分保留更高精度

因此同级别下，Qx_K_M 或 Qx_K_S 通常会比纯 Qx 略好。

实用选型建议

硬件足够：优先 Q8。
显存或内存紧张：逐级下调到 Q6 / Q5 / Q4。
下限建议：尽量不要低于 Q4，优先 Q4_K_M。
Q3 及以下：质量下降会越来越明显。

质量梯度（高到低）

32
16

– 在这一点之上，质量是一样的，但是硬件要求太疯狂了 –

Q8
Q6_K_M
Q6_K_S
Q6
Q5_K_M
Q5_K_S
Q5

– 这是典型的甜蜜点 –

Q4_K_M
Q4_K_S
Q4

– 在这一点之下，质量下降变得可见 –

Q3_K_M
Q3_K_S
Q3
Q2_K_M
Q2_K_S
Q2

如果你只想要一个简单结论：多数场景从 Q8 或 Q6_K_M 起步，不够再降到 Q5 或 Q4_K_M，通常更稳妥。

从 Hugging Face 下载 GGUF 模型并导入 Ollama

Thu, 09 Apr 2026 11:00:07 +0800

如果某个模型在 Ollama 官方库里没有现成版本，或者你想使用 Hugging Face 上的特定 GGUF 文件，可以手动下载后再导入 Ollama。

第 1 步：从 Hugging Face 下载 GGUF 文件

先在 Hugging Face 上找到目标模型对应的 GGUF 文件。通常会看到多个量化版本，例如：

Q4_K_M
Q5_K_M
Q8_0

选择哪个版本，取决于你的显存、内存和你对速度、质量的取舍。下载后把 .gguf 文件放到固定目录，后面在 Modelfile 里直接引用。

第 2 步：编写 Modelfile

在模型文件同目录新建一个 Modelfile。最基本的写法如下：

`1`	`FROM ./model.gguf`

如果文件名不同，就改成实际文件名，例如：

`1`	`FROM ./gemma-3-12b-it-q4_k_m.gguf`

如果只是先跑起来，通常这一行 FROM 就够了。

第 3 步：导入到 Ollama

然后执行：

`1`	`ollama create myModelName -f Modelfile`

myModelName 是你希望在 Ollama 里使用的本地模型名
-f Modelfile 表示从这个配置文件创建模型

创建成功后，这个 GGUF 文件就会成为一个可直接调用的本地模型。

第 4 步：运行模型

创建完成后直接运行：

`1`	`ollama run myModelName`

之后它的使用方式就和 ollama pull 下来的模型基本一致。

如何查看现有模型的 Modelfile

如果你不确定 Modelfile 应该怎么写，可以直接查看现有模型的配置：

`1`	`ollama show --modelfile llama3.2`

这条命令会输出 llama3.2 的 Modelfile 内容，适合拿来参考：

FROM 应该怎么写
模板和 system prompt 是怎么组织的
参数是如何声明的

什么时候适合用这条路线

下面这些场景适合从 Hugging Face 手动导入：

Ollama 官方库里还没有你要的模型
你想使用某个特定量化版本
你已经手动下载好了 GGUF 文件
你想更精细地控制模型封装方式

如果官方库里已经有现成版本，直接 pull 通常更省事；但当你需要特定量化或自定义封装时，GGUF + Modelfile 会更灵活。

常见注意点

FROM 后面的路径必须和实际 .gguf 文件位置一致。
文件名里如果有空格或特殊字符，建议先改成更简单的名字。
不同 GGUF 量化版本对内存和速度影响很大，导入成功不代表运行一定流畅。
如果模型是聊天模型，后续通常还需要根据其格式调整 prompt 模板，效果才会更稳定。

结论

从 Hugging Face 下载 GGUF 文件再导入 Ollama 并不复杂。准备好模型文件，写一个最小可用的 Modelfile，再执行 ollama create，就可以把第三方 GGUF 模型接入 Ollama。

Hugging Face on KnightLi的博客

Gemma 4 12B 怎么用？Hugging Face 模型卡和本地加载指南

这是什么模型

和 Gemma 4 系列其他模型怎么选

256K 上下文意味着什么

本地部署先看硬件和量化

支持哪些能力

Transformers 里怎么加载

Thinking mode 怎么开关

多模态输入顺序也有讲究

推荐采样参数

Benchmark 该怎么看

使用限制和安全注意

适合优先尝试的人

小结

参考来源

LongCat-Video-Avatar-1.5：美团开源音频驱动数字人视频模型

这次 1.5 版更新了什么

支持哪些任务

安装和模型下载

快速推理示例

参数怎么调

适合哪些场景

使用时要注意什么

小结

参考资料

Gemma 4 E4B 越狱版和官方普通版有什么区别

这个衍生版模型卡自己说了什么

官方版 vs 所谓“越狱版”

核心区别是“对齐方式”变了，不是“能力等级”突然变高

为什么官方普通版会更保守

什么情况下普通版更合适

什么情况下有人会去试越狱版

结论

参考来源

llama-cli -hf 下载 Hugging Face 模型默认保存在哪里

默认缓存位置

想修改 llama-cli 的缓存目录怎么办

小结

Windows 下 llama-cli 直连 Hugging Face 报 SSL 证书验证失败怎么办

最省事的办法：先手动下载模型

如果还想继续用 -hf 自动下载

llama.cpp 如何从 Hugging Face 获取 GGUF 模型

Hugging Face 选择 Llama 的 GGUF 模型时，量化怎么选：从 Q8 到 Q2 的实用建议

先理解 32、16 和 Q 系列

K_M / K_S 是什么

实用选型建议

质量梯度（高到低）

从 Hugging Face 下载 GGUF 模型并导入 Ollama

第 1 步：从 Hugging Face 下载 GGUF 文件

第 2 步：编写 Modelfile

第 3 步：导入到 Ollama

第 4 步：运行模型

如何查看现有模型的 Modelfile

什么时候适合用这条路线

常见注意点

结论

如果还想继续用 `-hf` 自动下载

`K_M` / `K_S` 是什么