Flower 模型 Lizzy 7B 运行指南Transformers、vLLM 与 GGUF 本地推理全路径详解【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本文是 Flower 模型文档中 how-to-run-lizzy.rst 的完整技术指南系统讲解如何以 BF16 Safetensors 检查点与 GGUF 量化两种发布格式分别在 Transformers、vLLM、llama.cpp、llama-cpp-python、Ollama 等运行时上运行 Flower Labs 的 Lizzy 7B 开源模型。读完本文你将掌握每种运行时适用场景、完整可复制的安装与调用命令、硬件与内存规划依据以及常见加载错误的排查思路。Lizzy 7B 与两种发布格式Lizzy 7B 是 Flower Labs 发布的 7B 级开源权重语言模型定位为通用助手模型面向推理、编码辅助以及英国UK导向的语言与知识场景。模型在 Hugging Face 上以两种格式发布详见 lizzy-7b.rstBF16 Safetensors 检查点flwrlabs/Lizzy-7B适用于 Transformers、vLLM、SGLang 等 GPU 服务栈保留全精度支持张量并行与微调。GGUF 量化文件flwrlabs/Lizzy-7B-GGUF适用于支持 Lizzy GGUF 架构的本地推理运行时文件更小、加载更快。从 lizzy-gguf.rst 可以确认 GGUF 发布版的面向服务配置32 层 post-norm 架构、hidden size 4096、滑动窗口注意力4096 token 窗口 全注意力行为、YaRN RoPE 缩放factor 8.0原始上下文 8192、100,278 token 词表、65,536 token 上下文共 355 个张量含attn_post_norm与ffn_post_norm。选择格式的核心原则需要全精度、Transformers/vLLM 服务、张量并行或微调时使用 BF16 检查点本地运行时支持 Lizzy GGUF 架构且需要更小文件或本地推理时使用 GGUF。在选定运行时之前建议先阅读 hardware-requirements.rst按内存、磁盘与长上下文场景做好规划。硬件与内存规划要点在动手运行前先按 hardware-requirements.rst 的指导评估硬件。以下数字是规划参考而非保证需在实际运行时与提示长度上验证使用场景实用起点说明Transformers BF16短提示24 GB GPU 显存BF16 权重约 14 GB未计入运行时开销与 KV cacheTransformers BF16长上下文40 GB 及以上 GPU 显存长提示可能额外增加数十 GB KV cachevLLM 服务24 GB 及以上 GPU 显存单卡 A40/H100 冒烟测试通过2x H100、4x A40 张量并行进程内生成通过GGUF Q4_K_M8 GB 统一内存/RAM 起步推荐 16 GB需要支持 Lizzy GGUF 架构的运行时GGUF Q5_K_M 或 Q6_K推荐 16 GB 统一内存/RAM本地资源充足且看重质量时选用GGUF Q8_0推荐 24 GB 统一内存/RAM近无损量化需要更多内存余量GGUF f16推荐 32 GB 统一内存/RAM仅在内存充裕时用于本地质量检查磁盘空间GGUF 仓库从 Q4_K_M 约 4.5 GB 到 f16 约 14.6 GB 不等BF16 Safetensors 检查点比 GGUF 量化文件占用更多磁盘。建议预留至少所选模型大小 2 倍的空间以容纳 Hugging Face 缓存、未完成下载与运行时元数据。KV cache 与上下文长度Lizzy 使用 32 层、hidden size 4096、32 个注意力头。BF16/FP16 KV cache 下batch size 1 时粗略上界约为每 token 0.5 MB。4,096 token 约 2 GB、8,192 token 约 4 GB、32,768 token 约 16 GB、65,536 token 约 32 GB。批处理与并发请求会成倍放大 KV cache 占用若运行时启用了 KV cache 量化或 paged attention内存可能更低但需实测确认。CPU 与内存GGUF 本地推理优先选择高内存带宽的现代 CPU。Apple Silicon 机器在运行时支持对应架构并能访问 Metal 设备时可有效利用统一内存在虚拟化、沙箱化或受限的 macOS 环境中先做 CPU-only 冒烟测试再启用 GPU offload。已知在 Apple M3 Ultra Mac Studio Lizzy 兼容 llama.cpp 分支上Q4_K_M 文件将全部 33 层 offload 到 Metal 并完成了短生成与服务测试——这只是能力验证不构成对其他提示、量化级别或机器的吞吐保证。GPU 服务尤其 vLLM优先选择支持 CUDA 的 Linux 系统。使用 Transformers 运行BF16 全精度路径环境要求Python 3.10 或更高版本安装 PyTorch、Transformers 5.x、jinja2与protobuf。Transformers 5.x 内置了 Lizzy tokenizer 元数据所用的TokenizersBackendtokenizer 类这是AutoTokenizer能正确加载的前提。pip install transformers5,6 torch accelerate jinja2 protobuf然后以trust_remote_codeTrue加载基础检查点import torch from transformers import AutoModelForCausalLM, AutoTokenizer repo_id flwrlabs/Lizzy-7B tokenizer AutoTokenizer.from_pretrained(repo_id, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( repo_id, trust_remote_codeTrue, torch_dtypetorch.bfloat16, device_mapauto, ) messages [ {role: system, content: You are Lizzy 7B.}, {role: user, content: Summarise why queue etiquette matters in the UK.}, ] prompt tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue, ) inputs tokenizer(prompt, return_tensorspt).to(model.device) output_ids model.generate( **inputs, max_new_tokens512, do_sampleFalse, ) response tokenizer.decode( output_ids[0][inputs[input_ids].shape[-1] :], skip_special_tokensTrue, ) print(response)已验证环境该路径在 macOS Python 3.13、torch2.12.0、transformers5.9.0 BF16 检查点下通过测试AutoTokenizer、chat-template 渲染与默认缓存生成均返回了符合预期的短回复。常见失败点与排查详见 troubleshooting.rstTokenizer class TokenizersBackend does not exist or is not currently importedTransformers 版本过低请升级到 5.x 并确保 Python 3.10。若被固定在旧版 Transformers 4.x 栈或使用手动PreTrainedTokenizerFast变通方案生成可能因多余的token_type_ids或缓存处理报错如int object has no attribute shape此时需在生成前移除token_type_ids并传入use_cacheFalse。推荐的 Transformers 5.x 路径不需要这两个变通。加载 Transformers 配置时可能看到关于显式 RoPE 因子与隐式因子不一致的警告这来自模型配置本身部署时应固定模型 revision 并在目标运行时验证生成质量。使用 vLLM 进行 GPU 服务OpenAI 兼容 APIvLLM 提供 OpenAI 兼容 API适用于 Linux GPU 服务器或其他 vLLM 版本支持的环境pip install vllm vllm serve flwrlabs/Lizzy-7B --trust-remote-code创建request.json{ model: flwrlabs/Lizzy-7B, messages: [ { role: user, content: What is the capital of France? } ] }调用服务curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ --data request.json已验证环境与限制单卡 NVIDIA A40 与 H100 上以vllm0.21.0、torch2.11.0cu130完成冒烟测试OpenAI 兼容服务器在 H100 上响应正常进程内生成在 H100 上最高测试到max_model_len32768。A40 路径使用 FlashAttention 2H100 路径使用 FlashAttention 3。张量并行进程内生成通过tensor_parallel_size2于 2x H100、tensor_parallel_size4于 4x A40。这是基于 Lizzy 注意力实现已改为使用分片投影张量的本地张量并行头数后通过验证的见 troubleshooting.rst。tensor_parallel_size8与带张量并行的 OpenAI 兼容服务未在此轮测试中完成生产环境的多卡服务配置需自行验证。vLLM 使用其 Transformers 建模后端加载 Lizzy因此吞吐与功能覆盖需在实际部署配置上验证。旧版 Lizzy 模型快照在 vLLM 张量并行下可能报注意力 reshape 错误如shape [1, 16384, 32, 128] is invalid出现时应清理 Hugging Face 缓存或固定到包含modeling_lizzy.py本地张量并行头数处理的新 revision。其他环境注意H100 Slurm 节点上 FlashInfer 的采样 JIT 需要ninja可执行文件在PATH上干净环境中 Triton/CUDA 工具编译失败时先检查编译器、CUDA 驱动库、Python 头文件与TMPDIR。V100compute capability 7.0无法运行torch2.11.0cu130的 CUDA kernel会报no kernel image is available for execution on the device生产环境建议使用受当前 vLLM 与 PyTorch CUDA wheel 支持的较新 NVIDIA GPU。使用 llama.cpp 运行 GGUF 模型GGUF 发布版面向支持 Lizzy GGUF 架构的本地运行时。Hugging Face 快速开始使用Q4_K_M变体。下面的命令使用当前测试过的 Lizzy 兼容 llama.cpp fork 与分支一旦上游 llama.cpp 或打包运行时支持general.architecture lizzy即可改用上游版本。git clone --branch lorenzo-dev https://github.com/relogu/llama.cpp.git cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release --target llama-completion llama-server ./build/bin/llama-server \ -hf flwrlabs/Lizzy-7B-GGUF:Q4_K_M \ -c 1024如果运行时报告unknown model architecture: lizzy说明它不含 Lizzy GGUF 支持应改用 Lizzy 兼容构建或改回 Transformers 运行 BF16 检查点详见 troubleshooting.rst 的冒烟测试结论。终端直接补全./build/bin/llama-completion \ -hf flwrlabs/Lizzy-7B-GGUF:Q4_K_M \ -p Q: 22? A: \ -n 16 \ -c 1024受限 macOS/虚拟化/沙箱环境的 CPU-only 冒烟测试Metal 设备初始化可能失败如ggml_metal_init: error: failed to create command queue这是环境或设备访问问题而非模型架构问题。强制小规模 CPU-only 测试./build/bin/llama-completion \ -hf flwrlabs/Lizzy-7B-GGUF:Q4_K_M \ -p Q: 22? A: \ -n 16 \ -c 1024 \ -t 2 \ -dev none \ -ngl 0 \ --no-op-offload已验证信息lorenzo-dev分支commit991a41b以lizzy-7b-q4_k_m.gguf完成过llama-completion、-hf加载、Metal offload、CPU-only 推理与 OpenAI 兼容llama-server推理的冒烟测试在 Apple M3 Ultra Mac Studio 上 Q4_K_M 将全部 33 层 offload 到 Metal短补全测试约 100 tokens/s。GGUF 仓库全部文件Q4_K_M、Q5_K_M、Q6_K、Q8_0、f16均以 CPU-only、n_ctx512、短提示冒烟测试通过。缓存相关提示-hf快捷方式可能读取其自身缓存与 Hugging Face 缓存若想避免意外的下载或写主目录可设置临时缓存位置HF_HOME/tmp/lizzy-hf-cache \ LLAMA_CACHE/tmp/lizzy-llama-cache \ ./build/bin/llama-completion \ -hf flwrlabs/Lizzy-7B-GGUF:Q4_K_M \ -p Q: Say hi. A: \ -n 8 \ -c 1024离线模式下若报告缺少小的 preset 或元数据文件先不带--offline运行一次填充临时 llama.cpp 缓存或改用直接的-m /path/to/lizzy-7b-q4_k_m.gguf形式。探测过程中出现的非致命HEAD failed, status: 404不影响后续加载。使用 llama-cpp-python 运行 GGUF 模型该路径要求 llama-cpp-python 构建链接到支持 Lizzy GGUF 架构的 llama.cpp 版本并可能需要支持 Lizzy 内嵌 chat template。若初始化时出现未知 Jinjageneration标签可使用 llama.cpp 服务器路径或参考 troubleshooting.rst。已知在llama-cpp-python0.3.23源码构建 vendoredrelogu/llama.cppcommit991a41b下模型可加载Metal offload但在解析内嵌 chat template 时因不识别generation标签失败Encountered unknown tag generation。临时兼容方案是在编译内嵌模板前剥除这两个块标签import llama_cpp.llama_chat_format as chat_format from llama_cpp import Llama original_init chat_format.Jinja2ChatFormatter.__init__ def lizzy_chat_template_init( self, template, eos_token, bos_token, add_generation_promptTrue, stop_token_idsNone, ): template template.replace({% generation %}, ) template template.replace({% endgeneration %}, ) return original_init( self, template, eos_token, bos_token, add_generation_prompt, stop_token_ids, ) chat_format.Jinja2ChatFormatter.__init__ lizzy_chat_template_init llm Llama( model_path/path/to/lizzy-7b-q4_k_m.gguf, n_ctx1024, n_gpu_layers-1, ) output llm.create_chat_completion( messages[ {role: system, content: /no_think}, {role: user, content: Reply with exactly: ok}, ], max_tokens16, temperature0, ) print(output[choices][0][message][content])需在构造Llama之前应用该 shim。此路径在 Q4_K_M 文件上验证了create_chat_completion返回预期响应但属于临时兼容变通需在 Python wrapper 原生支持 Lizzy chat template 后才算端到端受支持。使用 Ollama 与桌面 GGUF 应用进行中Ollama 支持尚在开发中当前公开构建可能尚未包含 Lizzy GGUF 架构的后端支持。可用命令如下但直到后端支持就绪前建议优先使用上述 Lizzy 兼容 llama.cpp 路径ollama run hf.co/flwrlabs/Lizzy-7B-GGUF:Q4_K_M已知冒烟测试中 Ollama 0.23.4 会下载模型后返回unable to load model详见 troubleshooting.rst 的运行时对照表。LM Studio、Jan 等桌面 GGUF 应用同样处于进行中状态。使用前先确认应用版本自带的 llama.cpp 后端能识别general.architecture lizzy若应用支持自定义后端可指向 Lizzy 兼容的 llama.cpp 构建并导入flwrlabs/Lizzy-7B-GGUF的任一量化文件。若报unknown model architecture: lizzy更新应用后端或直接用 llama.cpp。运行时选型对照运行时适用场景Transformers需要 Python 集成、全精度、自定义模型代码或微调工作流vLLM需要 GPU 服务、OpenAI 兼容 API、批处理或张量并行llama.cpp拥有支持 Lizzy GGUF 的构建需要本地推理、CPU 支持、灵活 GPU offload 或较小部署足迹Ollama、LM Studio、Jan进行中。仅在确认应用后端包含 Lizzy GGUF 支持后使用GGUF 量化变体与推荐默认从 lizzy-gguf.rst 的变体表可以规划量化选择变体文件大小质量保留推荐用途Q4_K_M4.2 GB92%资源受限环境Q5_K_M4.8 GB95%质量与体积最佳平衡Q6_K5.6 GB97%介于 Q5 与 Q8 之间Q8_07.2 GB99%近无损压缩f1613.6 GB100%最高质量与基准测试推荐默认质量优先且希望体积紧凑时选Q5_K_M内存或磁盘紧张时选Q4_K_M质量敏感型基准测试或本地资源充足时选Q8_0或f16。llama.cpp 服务器示例默认使用-hf flwrlabs/Lizzy-7B-GGUF:Q5_K_M说明服务场景同样建议从 Q5_K_M 起步。Hugging Face 文件浏览器显示的大小可能因取整与元数据视角不同而略有差异。生成参数建议GGUF 示例默认使用temperature0.6与top_p0.95。对于确定性的文档、编码或提取任务从更低温度如0.2开始需要更口语化输出时逐步提高温度并持续评估输出的事实性与风格。另外需要注意Lizzy 7B 在给出最终答案前可能输出推理 token。直接对外暴露模型输出的应用应根据产品与安全需求决定展示、隐藏或后处理推理痕迹见 lizzy-gguf.rst。模型背景与安全提示Lizzy 7B 采用多阶段训练大规模公开语料预训练文本、文档、代码、数学与百科语料、指令/对话/推理/工具使用 SFT、DPO 偏好优化以及带可验证奖励的强化学习详见 lizzy-training-and-evaluation.rst。它应被视为可能出错的助手模型——可能产生错误、过时或过度自信的回复高风险工作流需要人工监督、领域审查与下游审核。UK 导向的调优在改善本地风格与文化对齐的同时也可能使语气与假设偏向英国惯例详见 lizzy-7b.rst。相关文档导航模型总体信息与架构 lizzy-7b.rst硬件、内存与 KV cache 规划 hardware-requirements.rstGGUF 变体选择与架构细节 lizzy-gguf.rst训练方法与评测概览 lizzy-training-and-evaluation.rst各运行时冒烟测试结论与报错排查 troubleshooting.rst企业级评估、部署与适配 enterprise.rst【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Flower 模型 Lizzy 7B 运行指南：Transformers、vLLM 与 GGUF 本地推理全路径详解
Flower 模型 Lizzy 7B 运行指南Transformers、vLLM 与 GGUF 本地推理全路径详解【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本文是 Flower 模型文档中 how-to-run-lizzy.rst 的完整技术指南系统讲解如何以 BF16 Safetensors 检查点与 GGUF 量化两种发布格式分别在 Transformers、vLLM、llama.cpp、llama-cpp-python、Ollama 等运行时上运行 Flower Labs 的 Lizzy 7B 开源模型。读完本文你将掌握每种运行时适用场景、完整可复制的安装与调用命令、硬件与内存规划依据以及常见加载错误的排查思路。Lizzy 7B 与两种发布格式Lizzy 7B 是 Flower Labs 发布的 7B 级开源权重语言模型定位为通用助手模型面向推理、编码辅助以及英国UK导向的语言与知识场景。模型在 Hugging Face 上以两种格式发布详见 lizzy-7b.rstBF16 Safetensors 检查点flwrlabs/Lizzy-7B适用于 Transformers、vLLM、SGLang 等 GPU 服务栈保留全精度支持张量并行与微调。GGUF 量化文件flwrlabs/Lizzy-7B-GGUF适用于支持 Lizzy GGUF 架构的本地推理运行时文件更小、加载更快。从 lizzy-gguf.rst 可以确认 GGUF 发布版的面向服务配置32 层 post-norm 架构、hidden size 4096、滑动窗口注意力4096 token 窗口 全注意力行为、YaRN RoPE 缩放factor 8.0原始上下文 8192、100,278 token 词表、65,536 token 上下文共 355 个张量含attn_post_norm与ffn_post_norm。选择格式的核心原则需要全精度、Transformers/vLLM 服务、张量并行或微调时使用 BF16 检查点本地运行时支持 Lizzy GGUF 架构且需要更小文件或本地推理时使用 GGUF。在选定运行时之前建议先阅读 hardware-requirements.rst按内存、磁盘与长上下文场景做好规划。硬件与内存规划要点在动手运行前先按 hardware-requirements.rst 的指导评估硬件。以下数字是规划参考而非保证需在实际运行时与提示长度上验证使用场景实用起点说明Transformers BF16短提示24 GB GPU 显存BF16 权重约 14 GB未计入运行时开销与 KV cacheTransformers BF16长上下文40 GB 及以上 GPU 显存长提示可能额外增加数十 GB KV cachevLLM 服务24 GB 及以上 GPU 显存单卡 A40/H100 冒烟测试通过2x H100、4x A40 张量并行进程内生成通过GGUF Q4_K_M8 GB 统一内存/RAM 起步推荐 16 GB需要支持 Lizzy GGUF 架构的运行时GGUF Q5_K_M 或 Q6_K推荐 16 GB 统一内存/RAM本地资源充足且看重质量时选用GGUF Q8_0推荐 24 GB 统一内存/RAM近无损量化需要更多内存余量GGUF f16推荐 32 GB 统一内存/RAM仅在内存充裕时用于本地质量检查磁盘空间GGUF 仓库从 Q4_K_M 约 4.5 GB 到 f16 约 14.6 GB 不等BF16 Safetensors 检查点比 GGUF 量化文件占用更多磁盘。建议预留至少所选模型大小 2 倍的空间以容纳 Hugging Face 缓存、未完成下载与运行时元数据。KV cache 与上下文长度Lizzy 使用 32 层、hidden size 4096、32 个注意力头。BF16/FP16 KV cache 下batch size 1 时粗略上界约为每 token 0.5 MB。4,096 token 约 2 GB、8,192 token 约 4 GB、32,768 token 约 16 GB、65,536 token 约 32 GB。批处理与并发请求会成倍放大 KV cache 占用若运行时启用了 KV cache 量化或 paged attention内存可能更低但需实测确认。CPU 与内存GGUF 本地推理优先选择高内存带宽的现代 CPU。Apple Silicon 机器在运行时支持对应架构并能访问 Metal 设备时可有效利用统一内存在虚拟化、沙箱化或受限的 macOS 环境中先做 CPU-only 冒烟测试再启用 GPU offload。已知在 Apple M3 Ultra Mac Studio Lizzy 兼容 llama.cpp 分支上Q4_K_M 文件将全部 33 层 offload 到 Metal 并完成了短生成与服务测试——这只是能力验证不构成对其他提示、量化级别或机器的吞吐保证。GPU 服务尤其 vLLM优先选择支持 CUDA 的 Linux 系统。使用 Transformers 运行BF16 全精度路径环境要求Python 3.10 或更高版本安装 PyTorch、Transformers 5.x、jinja2与protobuf。Transformers 5.x 内置了 Lizzy tokenizer 元数据所用的TokenizersBackendtokenizer 类这是AutoTokenizer能正确加载的前提。pip install transformers5,6 torch accelerate jinja2 protobuf然后以trust_remote_codeTrue加载基础检查点import torch from transformers import AutoModelForCausalLM, AutoTokenizer repo_id flwrlabs/Lizzy-7B tokenizer AutoTokenizer.from_pretrained(repo_id, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( repo_id, trust_remote_codeTrue, torch_dtypetorch.bfloat16, device_mapauto, ) messages [ {role: system, content: You are Lizzy 7B.}, {role: user, content: Summarise why queue etiquette matters in the UK.}, ] prompt tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue, ) inputs tokenizer(prompt, return_tensorspt).to(model.device) output_ids model.generate( **inputs, max_new_tokens512, do_sampleFalse, ) response tokenizer.decode( output_ids[0][inputs[input_ids].shape[-1] :], skip_special_tokensTrue, ) print(response)已验证环境该路径在 macOS Python 3.13、torch2.12.0、transformers5.9.0 BF16 检查点下通过测试AutoTokenizer、chat-template 渲染与默认缓存生成均返回了符合预期的短回复。常见失败点与排查详见 troubleshooting.rstTokenizer class TokenizersBackend does not exist or is not currently importedTransformers 版本过低请升级到 5.x 并确保 Python 3.10。若被固定在旧版 Transformers 4.x 栈或使用手动PreTrainedTokenizerFast变通方案生成可能因多余的token_type_ids或缓存处理报错如int object has no attribute shape此时需在生成前移除token_type_ids并传入use_cacheFalse。推荐的 Transformers 5.x 路径不需要这两个变通。加载 Transformers 配置时可能看到关于显式 RoPE 因子与隐式因子不一致的警告这来自模型配置本身部署时应固定模型 revision 并在目标运行时验证生成质量。使用 vLLM 进行 GPU 服务OpenAI 兼容 APIvLLM 提供 OpenAI 兼容 API适用于 Linux GPU 服务器或其他 vLLM 版本支持的环境pip install vllm vllm serve flwrlabs/Lizzy-7B --trust-remote-code创建request.json{ model: flwrlabs/Lizzy-7B, messages: [ { role: user, content: What is the capital of France? } ] }调用服务curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ --data request.json已验证环境与限制单卡 NVIDIA A40 与 H100 上以vllm0.21.0、torch2.11.0cu130完成冒烟测试OpenAI 兼容服务器在 H100 上响应正常进程内生成在 H100 上最高测试到max_model_len32768。A40 路径使用 FlashAttention 2H100 路径使用 FlashAttention 3。张量并行进程内生成通过tensor_parallel_size2于 2x H100、tensor_parallel_size4于 4x A40。这是基于 Lizzy 注意力实现已改为使用分片投影张量的本地张量并行头数后通过验证的见 troubleshooting.rst。tensor_parallel_size8与带张量并行的 OpenAI 兼容服务未在此轮测试中完成生产环境的多卡服务配置需自行验证。vLLM 使用其 Transformers 建模后端加载 Lizzy因此吞吐与功能覆盖需在实际部署配置上验证。旧版 Lizzy 模型快照在 vLLM 张量并行下可能报注意力 reshape 错误如shape [1, 16384, 32, 128] is invalid出现时应清理 Hugging Face 缓存或固定到包含modeling_lizzy.py本地张量并行头数处理的新 revision。其他环境注意H100 Slurm 节点上 FlashInfer 的采样 JIT 需要ninja可执行文件在PATH上干净环境中 Triton/CUDA 工具编译失败时先检查编译器、CUDA 驱动库、Python 头文件与TMPDIR。V100compute capability 7.0无法运行torch2.11.0cu130的 CUDA kernel会报no kernel image is available for execution on the device生产环境建议使用受当前 vLLM 与 PyTorch CUDA wheel 支持的较新 NVIDIA GPU。使用 llama.cpp 运行 GGUF 模型GGUF 发布版面向支持 Lizzy GGUF 架构的本地运行时。Hugging Face 快速开始使用Q4_K_M变体。下面的命令使用当前测试过的 Lizzy 兼容 llama.cpp fork 与分支一旦上游 llama.cpp 或打包运行时支持general.architecture lizzy即可改用上游版本。git clone --branch lorenzo-dev https://github.com/relogu/llama.cpp.git cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release --target llama-completion llama-server ./build/bin/llama-server \ -hf flwrlabs/Lizzy-7B-GGUF:Q4_K_M \ -c 1024如果运行时报告unknown model architecture: lizzy说明它不含 Lizzy GGUF 支持应改用 Lizzy 兼容构建或改回 Transformers 运行 BF16 检查点详见 troubleshooting.rst 的冒烟测试结论。终端直接补全./build/bin/llama-completion \ -hf flwrlabs/Lizzy-7B-GGUF:Q4_K_M \ -p Q: 22? A: \ -n 16 \ -c 1024受限 macOS/虚拟化/沙箱环境的 CPU-only 冒烟测试Metal 设备初始化可能失败如ggml_metal_init: error: failed to create command queue这是环境或设备访问问题而非模型架构问题。强制小规模 CPU-only 测试./build/bin/llama-completion \ -hf flwrlabs/Lizzy-7B-GGUF:Q4_K_M \ -p Q: 22? A: \ -n 16 \ -c 1024 \ -t 2 \ -dev none \ -ngl 0 \ --no-op-offload已验证信息lorenzo-dev分支commit991a41b以lizzy-7b-q4_k_m.gguf完成过llama-completion、-hf加载、Metal offload、CPU-only 推理与 OpenAI 兼容llama-server推理的冒烟测试在 Apple M3 Ultra Mac Studio 上 Q4_K_M 将全部 33 层 offload 到 Metal短补全测试约 100 tokens/s。GGUF 仓库全部文件Q4_K_M、Q5_K_M、Q6_K、Q8_0、f16均以 CPU-only、n_ctx512、短提示冒烟测试通过。缓存相关提示-hf快捷方式可能读取其自身缓存与 Hugging Face 缓存若想避免意外的下载或写主目录可设置临时缓存位置HF_HOME/tmp/lizzy-hf-cache \ LLAMA_CACHE/tmp/lizzy-llama-cache \ ./build/bin/llama-completion \ -hf flwrlabs/Lizzy-7B-GGUF:Q4_K_M \ -p Q: Say hi. A: \ -n 8 \ -c 1024离线模式下若报告缺少小的 preset 或元数据文件先不带--offline运行一次填充临时 llama.cpp 缓存或改用直接的-m /path/to/lizzy-7b-q4_k_m.gguf形式。探测过程中出现的非致命HEAD failed, status: 404不影响后续加载。使用 llama-cpp-python 运行 GGUF 模型该路径要求 llama-cpp-python 构建链接到支持 Lizzy GGUF 架构的 llama.cpp 版本并可能需要支持 Lizzy 内嵌 chat template。若初始化时出现未知 Jinjageneration标签可使用 llama.cpp 服务器路径或参考 troubleshooting.rst。已知在llama-cpp-python0.3.23源码构建 vendoredrelogu/llama.cppcommit991a41b下模型可加载Metal offload但在解析内嵌 chat template 时因不识别generation标签失败Encountered unknown tag generation。临时兼容方案是在编译内嵌模板前剥除这两个块标签import llama_cpp.llama_chat_format as chat_format from llama_cpp import Llama original_init chat_format.Jinja2ChatFormatter.__init__ def lizzy_chat_template_init( self, template, eos_token, bos_token, add_generation_promptTrue, stop_token_idsNone, ): template template.replace({% generation %}, ) template template.replace({% endgeneration %}, ) return original_init( self, template, eos_token, bos_token, add_generation_prompt, stop_token_ids, ) chat_format.Jinja2ChatFormatter.__init__ lizzy_chat_template_init llm Llama( model_path/path/to/lizzy-7b-q4_k_m.gguf, n_ctx1024, n_gpu_layers-1, ) output llm.create_chat_completion( messages[ {role: system, content: /no_think}, {role: user, content: Reply with exactly: ok}, ], max_tokens16, temperature0, ) print(output[choices][0][message][content])需在构造Llama之前应用该 shim。此路径在 Q4_K_M 文件上验证了create_chat_completion返回预期响应但属于临时兼容变通需在 Python wrapper 原生支持 Lizzy chat template 后才算端到端受支持。使用 Ollama 与桌面 GGUF 应用进行中Ollama 支持尚在开发中当前公开构建可能尚未包含 Lizzy GGUF 架构的后端支持。可用命令如下但直到后端支持就绪前建议优先使用上述 Lizzy 兼容 llama.cpp 路径ollama run hf.co/flwrlabs/Lizzy-7B-GGUF:Q4_K_M已知冒烟测试中 Ollama 0.23.4 会下载模型后返回unable to load model详见 troubleshooting.rst 的运行时对照表。LM Studio、Jan 等桌面 GGUF 应用同样处于进行中状态。使用前先确认应用版本自带的 llama.cpp 后端能识别general.architecture lizzy若应用支持自定义后端可指向 Lizzy 兼容的 llama.cpp 构建并导入flwrlabs/Lizzy-7B-GGUF的任一量化文件。若报unknown model architecture: lizzy更新应用后端或直接用 llama.cpp。运行时选型对照运行时适用场景Transformers需要 Python 集成、全精度、自定义模型代码或微调工作流vLLM需要 GPU 服务、OpenAI 兼容 API、批处理或张量并行llama.cpp拥有支持 Lizzy GGUF 的构建需要本地推理、CPU 支持、灵活 GPU offload 或较小部署足迹Ollama、LM Studio、Jan进行中。仅在确认应用后端包含 Lizzy GGUF 支持后使用GGUF 量化变体与推荐默认从 lizzy-gguf.rst 的变体表可以规划量化选择变体文件大小质量保留推荐用途Q4_K_M4.2 GB92%资源受限环境Q5_K_M4.8 GB95%质量与体积最佳平衡Q6_K5.6 GB97%介于 Q5 与 Q8 之间Q8_07.2 GB99%近无损压缩f1613.6 GB100%最高质量与基准测试推荐默认质量优先且希望体积紧凑时选Q5_K_M内存或磁盘紧张时选Q4_K_M质量敏感型基准测试或本地资源充足时选Q8_0或f16。llama.cpp 服务器示例默认使用-hf flwrlabs/Lizzy-7B-GGUF:Q5_K_M说明服务场景同样建议从 Q5_K_M 起步。Hugging Face 文件浏览器显示的大小可能因取整与元数据视角不同而略有差异。生成参数建议GGUF 示例默认使用temperature0.6与top_p0.95。对于确定性的文档、编码或提取任务从更低温度如0.2开始需要更口语化输出时逐步提高温度并持续评估输出的事实性与风格。另外需要注意Lizzy 7B 在给出最终答案前可能输出推理 token。直接对外暴露模型输出的应用应根据产品与安全需求决定展示、隐藏或后处理推理痕迹见 lizzy-gguf.rst。模型背景与安全提示Lizzy 7B 采用多阶段训练大规模公开语料预训练文本、文档、代码、数学与百科语料、指令/对话/推理/工具使用 SFT、DPO 偏好优化以及带可验证奖励的强化学习详见 lizzy-training-and-evaluation.rst。它应被视为可能出错的助手模型——可能产生错误、过时或过度自信的回复高风险工作流需要人工监督、领域审查与下游审核。UK 导向的调优在改善本地风格与文化对齐的同时也可能使语气与假设偏向英国惯例详见 lizzy-7b.rst。相关文档导航模型总体信息与架构 lizzy-7b.rst硬件、内存与 KV cache 规划 hardware-requirements.rstGGUF 变体选择与架构细节 lizzy-gguf.rst训练方法与评测概览 lizzy-training-and-evaluation.rst各运行时冒烟测试结论与报错排查 troubleshooting.rst企业级评估、部署与适配 enterprise.rst【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考