进阶 10 分钟Falcon

本地部署 Falcon H1:Mamba 混合模型,来自 阿联酋

Falcon H1是阿布扎比技术创新研究所(TII)推出的开放权重模型系列,也是TII首个在每个块中结合传统注意力机制和Mamba层的模型系列。本指南将解释这种混合架构带来的变化、如何根据您的显存容量选择在本地安装的Falcon H1参数规模、如何测量它在长上下文中的内存节省效果,以及是否值得用它替换您的Ollama技术栈中的Mistral Small或Qwen3。

作者: Samir K.·更新于 2026-09-27·已在 Windows、macOS 和 Linux 上测试

#为何关注 Falcon H1

2023 年的首批 Falcon 模型曾在开放权重模型领域留下鲜明印记,随后却被 Llama、Mistral,再到 Qwen 拉开了差距。阿布扎比的技术创新研究所(Technology Innovation Institute,TII)于 2025 年 5 月发布了 Falcon H1,改变了技术思路:TII 不再追赶传统 Transformer 模型,而是从另一种架构重新出发,将注意力机制与状态空间模型(Mamba-2)结合起来,打造能够与规模大一倍的竞争模型相媲美的紧凑模型。

对于本地使用,该系列的优势体现在三点。它覆盖各种硬件配置,从适用于树莓派或旧笔记本电脑的 5 亿参数模型,到适用于 RTX 4090 或采用统一内存的 Mac 的 340 亿参数模型。标称上下文长度达到 256,000 个 token;在传统 Transformer 架构会占满显存的情况下,混合架构让这么长的上下文在本地也真正可用。最后,Falcon H1 在训练时就原生支持包括法语和阿拉伯语在内的 18 种语言,因此是处理法语文本的有力候选,无需借助以英语或中文为中心的模型。

i
Falcon H1 和 Falcon H1R
本指南介绍 Falcon H1 基础系列(Instruct)。2026 年初发布的 Falcon H1R 7B 使用相同架构,是经过逐步推理训练的衍生版本。所有关于安装和内存的说明都适用于两者;只有回答行为不同,H1R 因为回答更冗长而速度更慢。

#注意力与 Mamba 混合架构简述

本地 AI 套件

只需 1 小时,即可在您的电脑上拥有专属的免费 ChatGPT — LM Studio、Ollama、Open WebUI、您的文档,无需云端。

  • 在线空间,终身可用
  • PDF + 文件
  • 终身更新

经典 Transformer 完全依赖注意力机制。每处理一个新 token,模型都会重新读取整个上下文,并为此前的每个 token 保存一对向量,也就是常说的 KV 缓存。它占用的内存会随对话或文档长度线性增长。当您加载一份长报告时,导致显存容量不足的是这部分缓存,而不是模型权重。

Mamba 属于另一类模型,即状态空间模型(state space models)。Mamba 层不会重新读取过去的内容:它维护一个固定大小的循环状态,用来概括此前的信息,类似于经过现代化改进的循环神经网络。每个 token 的内存开销恒定,无论上下文多长,吞吐量都保持稳定。已知的代价是,对较远处细节的召回不够准确:纯 Mamba 模型较难找回埋在第 40 页中的某个具体数字。

混合架构旨在兼取两者之长。IBM Granite 4 和 Jamba 交替使用 Mamba 层与注意力层,而 Falcon H1 采用并行方案:在每个块中,注意力头与 Mamba-2 头并行处理同一输入,其输出在进入下一层前拼接起来。TII 调整了两者的比例,使其偏向 Mamba 通道,从而让注意力所需的内存远低于同等规模的 Transformer,同时保留足够的注意力来准确找回某个细节。

经典Transformer (Mistral, Qwen, Llama)
100% 的注意力。召回质量最高,但键值缓存与上下文成正比:当上下文超过几万 token 时,VRAM 会迅速耗尽。
纯 Mamba 架构(Falcon Mamba 7B)
处理每个 token 时,内存占用保持恒定,处理长序列非常快。对较早内容中细节的回忆能力较弱,软件支持也仍然参差不齐。
串行混合架构(Granite 4,Jamba)
主要由Mamba层构成,穿插注意力层。内存占用显著降低,架构简单,易于在运行时环境中实现。
并行混合(Falcon H1)
每个模块中都包含注意力机制和 Mamba-2,两者的输出会拼接起来。模型在每一层都会决定将哪些内容交给精确记忆,哪些交给压缩记忆。
→
实际影响是什么
对于包含 2000 个 token 的提示词,您看不出它与传统 Transformer 模型有任何区别。加载一份 60 页的合同或一段三小时的对话后,差异就会显现:Falcon H1 的内存占用几乎保持不变,而 Mistral Small 或 Qwen3 则必须量化 KV 缓存或缩短上下文。

#可选大小范围:从 0.5B 到 34B

TII 发布的 Falcon H1 有六种规模,每种都提供 Base(预训练)版和 Instruct(聊天)版。如果您要在 Ollama 或 LM Studio 中使用,只需关注 Instruct 版。所有版本都采用相同的架构和多语言分词器。

Falcon H1 0.5B
最小的版本。适用于嵌入式设备、流程测试或 Raspberry Pi。不要指望它胜任严肃的写作任务。
Falcon H1 1.5B
分类、简单提取、自动补全。可在任意新款CPU上运行,内存需求低于2GB。
Falcon H1 1.5B-Deep
参数数量与 1.5B 版本相同,但层数多得多,每层的宽度更小。TII 将其定位在 70 亿至 100 亿参数模型的水平。这是在没有 GPU 的笔记本电脑上值得尝试的变体。
Falcon H1 3B
适合配备 4–6 GB 显存的显卡或 16 GB 内存的 Mac 的折中选择。可用于摘要、法语聊天和轻量级 RAG。
Falcon H1 7B
主力档位的模型。性能可与 Qwen3 8B 相抗衡,并超越上一代 7B 模型。RTX 3060 12GB 可以运行它,并支持较长的上下文。
Falcon H1 34B
高端型号。TII 将其与 Qwen3 32B、Gemma 3 27B 和 Llama 4 Scout 进行比较。Q4 下至少需要 24 GB 显存,或选择配备 48 GB 统一内存的 Mac,以留出充裕空间。

1.5B-Deep 版本值得单独提一下。TII 选择了一个宽度较小但深度很大的模型,其层数接近标准 1.5B 模型的三倍。由于各层依次执行,生成每个 token 所需的时间更长,但能力明显更强。在 CPU 上,内存带宽限制着整体运行表现,因此它往往是整个系列中每 GB 内存所能获得的输出质量最好的版本。

#先决条件与 VRAM

软件方面,您需要较新版本的 Ollama。llama.cpp 在 2025 年夏季加入了对 falcon-h1 架构的支持,随后发布的 Ollama 版本也继承了这一支持。更早的 Ollama 版本会拒绝加载模型,并报出未知架构错误。守护进程默认监听 http://localhost:11434;Open WebUI 或 LM Studio 无需特殊配置即可连接。

0.5B 和 1.5B 采用 Q4_K_M 量化
少于1.5 GB。仅需CPU,且需4 GB空闲RAM。无需GPU。
3B,Q4_K_M
约 2 GB 显存。任何配备 4 GB 或更多显存的显卡均可;若使用 CPU 模式,则需 8 GB 内存。
7B,Q4_K_M量化
模型权重约需5 GB VRAM。RTX 3060 12GB 或 RTX 4070 12GB 可轻松运行,且具备支持32K tokens及以上上下文的余量。
7B,Q8_0
约8 GB。对于RTX 4080 16GB或Mac 24 GB的设备,若需最高精度的提取效果,可使用该配置。
34B 量化为 Q4_K_M
约 20 GB。RTX 4090 24GB 勉强够用,需留意上下文长度。M4 Pro 48 GB 或 Mac Studio 的余量要大得多。
34B,Q8_0 量化
≈ 36 GB。仅适用于64 GB及以上内存的Mac,或双GPU设备。
i
量化参考
Q4_K_M 仍是推荐的默认选择,在质量与模型大小之间提供最佳平衡。只有在显存允许、且您在自己的任务中测得差异时,才切换到 Q5_K_M 或 Q8_0。对于 Falcon H1,较小的 KV 缓存腾出的显存余量,往往比提高一档量化精度更有价值。

#根据可用 VRAM 在本地安装 Falcon H1

TII 在 Hugging Face 上为每种模型规模发布官方 GGUF 文件,仓库名为 tiiuae/Falcon-H1-<taille>-Instruct-GGUF。Ollama 可以使用 hf.co 前缀直接从 Hugging Face 拉取 GGUF 文件,并在冒号后指定所需的量化方式。请顺便在 ollama.com/library 上检查,自本指南撰写以来是否出现了官方 falcon-h1 标签;如果有,请优先使用它,因为其中包含经过验证的聊天模板。

  1. 01
    更新 Ollama
    重新运行官方安装程序或包管理器,然后检查版本。这一步人人都会跳过,而跳过它正是大多数加载失败的原因。
  2. 02
    根据 VRAM 选择模型大小
    12 GB 或更少:使用 Q4_K_M 量化的 7B 模型。4 到 6 GB:3B。无 GPU:1.5B-Deep。24 GB 或配备 48 GB 内存的 Mac:34B。不要一次性下载多个尺寸的模型,每个 GGUF 文件的大小在 1 到 20 GB 之间。
  3. 03
    从 Hugging Face 拉取 GGUF
    使用 ollama pull 命令,结合 hf.co 仓库路径和量化标签。Ollama 会下载文件、读取其元数据,并据此生成聊天模板。
  4. 04
    启动会话并以法语进行测试
    ollama run 会打开一个交互式聊天窗口。请提出一个真实任务,例如总结文本或提取字段,而不是出谜题。确认模型能够用法语回答,不会逐渐切换到英语。
  5. 05
    检查 GPU/CPU 的分配情况
    ollama ps 会显示加载到 GPU 上的模型百分比。如果有一部分位于 CPU,请减小模型大小或降低量化级别,否则吞吐量会骤降。
终端 — 在 12 GB 显存的显卡上运行 Falcon H1 7B
# 1. Vérifier la version d'Ollama (doit dater d'après l'été 2025)
ollama --version

# 2. Tirer le GGUF officiel TII en Q4_K_M (~4,5 Go)
ollama pull hf.co/tiiuae/Falcon-H1-7B-Instruct-GGUF:Q4_K_M

# 3. Lancer une session interactive
ollama run hf.co/tiiuae/Falcon-H1-7B-Instruct-GGUF:Q4_K_M

# 4. Vérifier que tout est sur le GPU
ollama ps
终端 — 其他模型规模
# Sans GPU : la variante 1.5B-Deep, étroite mais très profonde
ollama pull hf.co/tiiuae/Falcon-H1-1.5B-Deep-Instruct-GGUF:Q4_K_M

# Carte 4-6 Go ou Mac 16 Go
ollama pull hf.co/tiiuae/Falcon-H1-3B-Instruct-GGUF:Q4_K_M

# RTX 4090 24 Go ou Mac 48 Go
ollama pull hf.co/tiiuae/Falcon-H1-34B-Instruct-GGUF:Q4_K_M

带有 hf.co 前缀的完整名称输入起来很长,在 Open WebUI 中也不易阅读。用 Modelfile 创建一个本地别名:您可以顺便设置上下文长度和法语系统提示词,模型就会在您的所有界面中以简短名称显示。

终端 — 使用 Modelfile 的简短别名
cat > Modelfile.falcon-h1 <<'EOF'
FROM hf.co/tiiuae/Falcon-H1-7B-Instruct-GGUF:Q4_K_M
PARAMETER num_ctx 32768
PARAMETER temperature 0.3
SYSTEM "Tu es un assistant précis. Tu réponds en français, de façon concise."
EOF

ollama create falcon-h1:7b -f Modelfile.falcon-h1
ollama run falcon-h1:7b

在应用程序中使用时,Ollama 在同一端口提供 HTTP API,并提供兼容 OpenAI 的端点。所有现有客户端只需更改基础 URL 和模型名称即可运行。

终端 — 调用本地 API
curl http://localhost:11434/api/chat -d '{
  "model": "falcon-h1:7b",
  "messages": [
    { "role": "user", "content": "Résume ce texte en trois points : ..." }
  ],
  "options": { "num_ctx": 32768 },
  "stream": false
}'
!
llama.cpp 和 LM Studio 用户
llama.cpp 使用 -hf 选项加载相同的 GGUF 模型,例如 llama-server -hf tiiuae/Falcon-H1-7B-Instruct-GGUF:Q4_K_M。LM Studio 依赖相同的引擎:在查找其目录中的 Falcon H1 之前,请先更新它,旧版本不会将该文件列为兼容项。

#长上下文下的内存优势:实测结果

这正是 Falcon H1 在本地运行时的核心承诺,十分钟内即可验证。测试方法很简单:分别以两种上下文长度加载同一个模型,并比较 ollama ps 报告的内存占用。对于传统 Transformer 模型,将上下文从 8K 增至 64K token 会使内存消耗增加数 GB。Falcon H1 的内存占用也会增加,因为其中的注意力部分仍保留 KV 缓存,但增幅明显更小。

终端 — 测量上下文成本
# Contexte 8K : noter la colonne SIZE de ollama ps
OLLAMA_CONTEXT_LENGTH=8192 ollama run falcon-h1:7b "Bonjour" && ollama ps

# Décharger, puis recharger avec 64K
ollama stop falcon-h1:7b
OLLAMA_CONTEXT_LENGTH=65536 ollama run falcon-h1:7b "Bonjour" && ollama ps

# Même exercice avec un transformeur classique pour comparer
ollama stop falcon-h1:7b
OLLAMA_CONTEXT_LENGTH=65536 ollama run qwen3:8b "Bonjour" && ollama ps

解读这些数字时,需要注意两点。首先,Ollama 会为所请求的整个上下文提前预留 KV 缓存:因此,显示的内存占用反映的是预留容量,而不是您的提示词实际占用的内存。其次,如果您在 Ollama 配置中启用了 KV 缓存量化,它也会应用于 Falcon H1 的注意力部分,从而进一步缩小测得的差距,但不会改变结论:在显存容量相同的情况下,Falcon H1 能支持的上下文远长于同等规模的 Transformer 模型。

在12GB显存的显卡上,Falcon H1 7B采用Q4_K_M量化后可支持64K token的上下文长度,且不会溢出CPU内存,而Qwen3 8B或Mistral 7B则需对KV缓存进行量化或限制在32K以内。随着上下文长度增加,生成速度的下降幅度远小于前者:Mamba模块能以恒定时间处理每个新token。

!
长上下文并不意味着能完美找回其中的信息
Falcon H1 支持 256K token,但能接收不等于能理解。与所有模型一样,对于埋在提示词深处的细节,它的准确率会下降,Mamba 部分也是导致这种下降的因素之一。要在 200 页文档中找到一个确切数字,采用分块和检索的 RAG 仍比超大上下文更可靠。Falcon H1 的长上下文擅长摘要、综合归纳和跟进对话,而不是“大海捞针”式的检索。

#与 Mistral Small 和 Qwen3 相比:最终结论

大家普遍关心的问题:是否需要替换现有模型?答案取决于模型大小,因为不同变体的 Falcon H1 所属类别并不相同。

Falcon H1 7B 对比 Qwen3 8B
整体质量相当,Qwen3 在代码和结构化推理方面保持优势,Falcon H1 在法语方面更自然,且随着上下文变长,其资源消耗显著更低。对于 12 GB 显存下的文档摘要和法语聊天,Falcon H1 占优。若要编写代码,请坚持使用 Qwen3。
Falcon H1 7B 对比 Mistral Small 3.2
这不是同一类模型:Mistral Small 参数量为 240 亿,Q4 情况下需 14 至 15 GB 显存。如果您有充足的显存,Mistral Small 在大多数任务上表现更优。当显存为 12 GB 或上下文长度需超过 32K 时,Falcon H1 7B 是更合适的选择。
Falcon H1 34B 对比 Mistral Small 3.2
值得关注的对决。Falcon H1 34B在知识和推理基准测试中表现更优,且能更好地处理超长上下文,但Q4量化需额外5GB显存且不具备视觉能力。Mistral Small可运行于16GB显存的显卡上,支持图像输入,采用Apache 2.0许可,且生态更成熟,尤其在函数调用方面。
Falcon H1 34B 对比 Qwen3 32B
在显存容量相近的情况下,Qwen3 32B 仍是代码和智能体任务的标杆。处理法语或阿拉伯语长文档时,Falcon H1 34B 更值得选择;在 Mac 上也是如此,因为统一内存可轻松容纳它所需的 20 GB。

结论可以概括为一句话:当您面临长上下文带来的内存问题,或以法语和阿拉伯语作为工作语言时,Falcon H1 是最适合安装的模型。它并不是适用于所有场景的最佳通用模型,其生态系统也没有 Mistral 或 Qwen 那么成熟。在配备 24 GB 内存的工作站上,Mistral Small 仍是日常助手的稳妥选择;Falcon H1 34B 则适合作为额外模型,用来处理大型文档。

→
做决定前该进行的测试
选取三份实际业务中的真实文档,每份 20–80 页,在相同上下文条件下,向 Falcon H1 7B 和您当前的模型提出同一组问题。比较摘要质量、所引用数字的准确性,以及使用 ollama run 的 --verbose 选项时在回答末尾显示的吞吐量。这比任何公开基准测试都更有参考价值。

#Falcon-LLM 许可证:部署前请务必阅读

Falcon H1 以 TII 的 Falcon-LLM 许可证发布。该许可证衍生自 Apache 2.0,允许商业使用、修改和再分发,但增加了可接受使用政策和一些署名义务。它不像 Mistral Small 或 Granite 所采用的 Apache 2.0 那样提供完全的自由,也不像 Llama 那样属于带有用户数量门槛的限制性许可证。

个人或内部使用无需考虑这个问题。对于再分发的商业产品,请花十分钟阅读 TII 网站上的许可文本,确认您的使用情形不属于被排除的用途。网站的模型目录在每个 Falcon 条目中列出了许可证,其版本可能随模型代际而变化。

#故障排除

错误:unknown model architecture falcon-h1
您的 Ollama、LM Studio 或 llama.cpp 版本过旧,无法识别混合架构。请更新,重启守护进程并重新拉取。无其他变通方法:在缺少引擎支持的情况下,Mamba-2 层将无法加载。
无法从hf.co拉取模型或未找到指定标签
请在Hugging Face页面上核对存储库和量化格式的准确拼写,特别是Q4_K_M的大小写。如果存储库未提供所需标签,请切换到‘Files’选项卡,查看可用的GGUF文件列表。
使用英文回复,而您输入的是法语
添加系统提示,以指定语言,例如在上方的Modelfile中所示。Falcon H1的多语言分词器对法语处理非常良好,但无明确指令的Instruct模型有时会遵循其数据中的主流语言。
34B 模型的生成吞吐量很低
ollama ps 可能会显示模型只有一部分分配在 CPU 上。在 24 GB 内存下,请将上下文缩小到 16K,或改用 Q4_K_S。在 Mac 上,如果系统预留了过多内存,请提高可分配给 GPU 的内存上限。
长上下文下的内存占用高于预期
这是正常的:Ollama 会按设定的完整上下文长度预留注意力 KV 缓存,即使上下文为空也一样。与其他模型比较时,务必使用相同的上下文长度;如果还想再节省一些内存,可以启用 KV 缓存量化。
聊天模板错误,回复中可见标签
Ollama 根据 GGUF 的元数据生成模板。若出现标签,应优先使用官方 TII GGUF 文件而非第三方转换版本,或在您的 Modelfile 中显式定义 TEMPLATE。

#深入了解

掌握Falcon H1所利用的上下文和内存概念后,才能充分理解它的价值。本网站的以下指南可补充本篇指南:

理解上下文窗口
8K、32K 或 256K 个 token 意味着什么,需要消耗多少显存,以及为什么 KV 缓存是传统 Transformer 的真正瓶颈。
量化KV缓存以节省VRAM
另一个扩展上下文的手段,可与Falcon H1的混合架构叠加使用。
在本地运行 IBM 的 Granite 4
当前另一款 Mamba 混合模型,采用序列式架构,按 Apache 2.0 许可发布。将其与 Falcon H1 对比,有助于理解 TII 的选择。
选择量化方案(Q4、Q5、Q8、FP16)
根据您的显存容量,为各个规模的 Falcon H1 模型在 Q4_K_M 和 Q8_0 之间作出选择。
这份指南对您有帮助吗?

有反馈、发现了错误,或想补充说明?请告诉我们,让这份指南对每个人都更有帮助。