企业官网建设流程全解析

Ollama 一行命令拉 Ornith 1.5？先看完这份六框架选型指南再动手

【免费下载链接】Ornith-1.5-35B-A3B-GGUF项目地址: https://ai.gitcode.com/hf_mirrors/ornith-ai/Ornith-1.5-35B-A3B-GGUF

ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF，一行命令就能把 Ornith-1.5 拉进本地。这条命令在官方 README 里被写在"Agentic Usage"第一节，看起来人畜无害——但真到动手那一刻，你会发现真正的问题从来不在"拉不下来"，而在"拉下来之后用什么跑、跑在什么硬件上、跑成什么样"。

Ornith-1.5-35B-A3B 是一个总参数 35B、每 token 只激活约 3B 参数的混合专家（MoE）模型，官方宣称其编码与 Agentic 基准全面超越同规模的 Qwen3.6-35B-A3B，并在多项任务上追平甚至超过稠密模型 Gemma-4-31B 和 Muse-Glimmer-30B。它身上叠了两层"便宜大碗"的叙事：MoE 的激活参数少，推理快；量化版体积小，显存门槛低。这也是抖音、头条上"35B 总参数推理只激活 3B""小显存部署大模型新答案"等讨论的源头。

但便宜和快都是有前提的。本文结合社区实测（六框架对比、16G 显存实战、5090 部署）与本仓库实际产物，把选型这件事一次性讲透。

一行命令的背后：这是一头怎样的"鸟"

在讨论框架之前，先明确你手里攥着的是什么。本仓库 README.md 明确定义了 Ornith-1.5-35B-A3B 的三个关键事实：

1. 它是推理模型：默认回复以<think>...</think>思维链开场，服务端需要配置 reasoning parser 才能把思维过程单独剥离到reasoning_content字段；同时它原生输出<tool_call>块，需要 tool-call parser 解析成 OpenAI 风格的tool_calls。这意味着——不是所有框架开箱即用，你的框架必须"认识"Qwen 系对话模板。
2. 它是端到端自我改进训练的产品：Ornith-1.5 在 Ornith-1.0 基础上，把自我改进循环从"脚手架与 rollout 优化"扩展为"任务生成、脚手架构建、解决方案 rollout 三路联合优化"，模型在训练中自己出题、自己找解题策略、再用强化学习改进策略。这也解释了它为何在 Agentic 编码基准上大幅领先——这是训练方式决定的，不是调参调出来的。
3. 它的原生形态是 bf16：约 70GB，官方服务配方默认跑在 2×80GB GPU 上给 256K 上下文留余量。

仓库里的产物链条很清晰：除 BF16 原版外，还提供 Q4_K_M、Q5_K_M、Q6_K、Q8_0 四个量化档位，外加一个mmproj-Ornith-1.5-35B-BF16.gguf多模态投影权重（llama.cpp 生态里用于图文理解）。这五个 GGUF 文件就是接下来所有选型讨论的物理基础。

六大框架适用场景速览

社区对 Ornith-1.5 系列部署的主流讨论，聚焦在 vLLM、SGLang、TensorRT-LLM、TGI、llama.cpp 与 Ollama 六个框架上。其中前四个是 GPU 服务化推理，后两个走 GGUF 本地路线。把官方证据（README 的 Serving 章节）与社区实测对照后，可以给出如下定位：

注意一个细节：README 的 Agentic 章节同时给了llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF与ollama run hf.co/...-GGUF两条 GGUF 路线，说明官方对"小机器跑大 MoE"这件事的态度是认真的——GGUF 路线不是妥协方案，而是被官方写进文档的一等公民。

量化格式兼容矩阵：GGUF / AWQ / GPTQ 谁跟谁是一家人

选型最容易被"一行命令"带偏的点，是量化格式。三个常见词——GGUF、AWQ、GPTQ——对应完全不同的运行时生态，混用即 404：

映射关系很直接：GGUF 属于 llama.cpp 系，AWQ/GPTQ 属于 vLLM 系。Ollama 底层就是 llama.cpp，所以它只吃 GGUF；vLLM/SGLang 虽然也能加载部分 GGUF（通过 GGUF loader），但社区对比文章里给出的主流做法，是给 vLLM 系列用原版权重配合 AWQ/GPTQ 量化。也就是说：你决定用哪个框架，基本就等于决定了模型该下载成哪个格式——本仓库是 GGUF 镜像，若走 vLLM 高吞吐路线，需要回到 HF 原版仓库另取 bf16 权重或 AWQ/GPTQ 量化版，这个步骤省不掉。

对 GGUF 内部档位的选择，则纯粹是显存与精度的天平。按 35B 权重规模估算，BF16 约 70GB，Q8_0 落在 37GB 量级，Q6_K 约 28GB，Q5_K_M 约 24GB，Q4_K_M 约 20GB 出头——估算值仅供参考，实际以加载时 llama.cpp 打印的 tensor 信息为准。需要提醒的是：MoE 的"激活 3B"只决定计算量，权重总量该多大还是多大，量化省的是驻留显存，不是推理功耗。

按显卡与场景给出选型建议

把框架、格式和硬件三条线拧在一起，社区实测（16G 显存对比、5090 FP16/Q8 实操）与本仓库产物能支撑如下决策逻辑：

场景 A：Apple Silicon 笔记本 / 16GB 内存 Mac。ollama run或llama-server直接上 Q4_K_M，靠 Metal 加速 + GGUF 的 CPU/GPU 异构加载把 20GB 权重挤进 16GB 统一内存。这是"一行命令"叙事真正成立的地方——但请把预期调低：MoE 激活 3B 在 Mac 上只保证"能跑"，不保证"飞快"。

场景 B：16GB 显存消费级显卡（如 RTX 4080）。社区实测表明 Q4_K_M 是 16GB 下的最佳平衡点，模型约 13.2GB 显存占用、推理速度约 18.2 tokens/s（对比同环境 Qwen 35B 的 16.8 tokens/s），4-bit 量化对 Ornith 的代码生成与推理速度有可见加成。注意实测用的是 vLLM 路线，说明 16G 显存用户其实有两条路：llama.cpp + Q4_K_M（简单），或 vLLM + AWQ 4bit（高吞吐，但要处理依赖与显存水位）。

场景 C：24GB 单卡（RTX 4090）。可以上 Q6_K 或 Q8_0，精度余量更足；若要跑 256K 长上下文，KV Cache 会吃满剩余显存，需配合--gpu-memory-utilization控制。

场景 D：32GB+ 高端卡（如 RTX 5090）。社区已给出 FP16 与 Q8 两档实操，FP16 直跑原版权重拿满精度，Q8_0 换取显存余量。这类机器上 Ollama 反而成为瓶颈——请直接切 vLLM/SGLang 拿并发与吞吐。

场景 E：多卡服务器（2×80GB，官方默认配方）。README 的 vLLM/SGLang 命令均以--tensor-parallel-size 2/--tp 2起步，BF16 全量加载 + 256K 上下文，这是跑满官方 benchmark 数值（SWE-bench Verified 79、Terminal-Bench 2.1 67.8、GPQA Diamond 89.2）的硬件前提。若需求超过 256K，README 提供 YaRN 方案，factor=4.0可把有效窗口扩展到约 1M token，但官方明确提示静态缩放会影响普通长度请求的质量，非必要不开启。

场景 F：企业 GPU 集群。TensorRT-LLM 与 TGI 不在官方 README 中，属于社区对比中提及的工程化路线，适合已有相应基础设施、追求极限延迟或深度绑定 HF 生态的团队，代价是需要自行完成权重格式转换与算子适配。

一句话总结选型：个人与笔记本走 Ollama/llama.cpp + GGUF（Q4_K_M 起），消费级 GPU 走 Q5/Q6 平衡档，有服务化需求立刻切 vLLM/SGLang + 原版/AWQ，多卡才谈 BF16 全量。

实战：Ollama 一行命令，与它的"含金量"

最后把三套官方命令摆在一起，对照着看，选型才算闭环。

Ollama（个人快速体验）——README 原样给出的命令：

ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF

llama.cpp（本地 OpenAI 兼容服务）——需要显式给足上下文窗口：

llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF --port 8000 -c 262144

vLLM（生产服务化）——注意 reasoning 与 tool 两个 parser 是"推理模型"能否正确工作的关键：

vllm serve ornith-ai/Ornith-1.5-35B-A3B \ --served-model-name Ornith-1.5-35B-A3B \ --host 0.0.0.0 --port 8000 \ --tensor-parallel-size 2 \ --max-model-len 262144 \ --gpu-memory-utilization 0.90 \ --enable-prefix-caching \ --enable-auto-tool-choice --tool-call-parser qwen3_xml \ --reasoning-parser qwen3 \ --trust-remote-code

三者的差别就是本文的结论：Ollama 一行命令背后是 llama.cpp，它替你选了 GGUF、选了本地、选了个人场景；当你要的是吞吐、并发、256K 长上下文和 Agent 工具调用流水线，答案自动滑向 vLLM/SGLang，代价是多装几个运行时、多配一套参数。

还有一个 README 明确给出的采样基线值得抄进配置：通用任务temperature=0.6, top_p=0.95, top_k=20；要复现官方 benchmark 数据则需temperature=1.0。至于ollama run那条命令本身——它没骗你，真的能跑；但跑之前，先把这份选型看完，你才知道自己该在哪个档位的 GGUF 上按回车。

【免费下载链接】Ornith-1.5-35B-A3B-GGUF项目地址: https://ai.gitcode.com/hf_mirrors/ornith-ai/Ornith-1.5-35B-A3B-GGUF