企业官网建设流程全解析

5.1MB 的 Shimmy 和 680MB 的 Ollama，本地大模型到底该选谁？

项目地址先放这里：

• Shimmy：https://github.com/Michael-A-Kuykendall/shimmy
• Ollama：https://ollama.com/search

最近把这两个项目放在一起看，越看越觉得它们不是一路人。Ollama 想把本地模型做成平台，Shimmy 只想做一个极简的推理服务器。选哪个，取决于你在什么场景下跑模型。

先说结论

• 普通开发者，想省事，机器还行，Ollama 仍然是默认答案。
• 如果你要把推理塞进 CI/CD、边缘设备，或者频繁切 LoRA，Shimmy 值得看一眼。
• 它们不是互相替代，更像是两个不同尺寸的螺丝刀。

Shimmy 是什么

Shimmy 是一个用 Rust 写的单二进制推理服务器，体积 5.1MB。它提供 100% OpenAI 兼容接口，跑 GGUF 模型。不需要 Python，不需要 C++ 工具链，也不依赖 llama.cpp。

底层是 Airframe，一个纯 Rust 的 WebGPU（WGSL）transformer 引擎。官方认证了 26 个模型/量化组合，覆盖 12 个模型家族，认证包括 MATH、INFERENCE、DETERMINISM 三部分。

Ollama 是什么

Ollama 是本地大模型里的老面孔。最早是 llama.cpp 的封装，现在变成了完整的模型管理守护进程。有自己的 registry，CLI 用起来像 Docker。支持多模态，也能连云端模型。

模型库覆盖 Llama、Gemma、Qwen、Mistral、DeepSeek、Phi 等等。现在还有云模型，比如 deepseek-v4.1-flash，输入价格每百万 token 0.30 美元。本地和托管之间的界线越来越模糊。

资源差距很直接

这些数字不是跑分，是开发者每天能感受到的东西。

• 二进制体积：Shimmy 5.1MB，Ollama 680MB
• 启动时间：Shimmy 100ms 以内，Ollama 5 到 10 秒
• 内存开销：Shimmy 约 50MB，Ollama 200MB+
• OpenAI API 兼容：Shimmy 100%，Ollama 部分兼容

跑同一个模型、同一个量化时，GPU 显存和功耗基本一样，因为底层都是 GGUF，都在 GPU 上跑 transformer。差别主要在 CPU 内存占用和启动延迟。

Ollama 强在哪

Ollama 的优势不是推理性能，是周围那一圈生态。

• 模型发现太方便：ollama pull llama3.2就完事。不用 Hugging Face CLI，不用手动下 GGUF，不用配路径。Shimmy 虽然会自动扫描 Hugging Face 缓存、Ollama 模型目录和本地文件夹，但模型本身得先存在。
• 企业集成案例多：有文档提到，完全本地的 RAG 客服机器人，在技术支援查询上做到 89.2% 准确率，Ollama 负责本地 LLM 托管，Qdrant 做向量存储。重庆彭水水电也用过 Ollama + Docker + Dify 搭离线 Qwen3-30B 企业知识库。
• 编码 Agent 支持：Ollama 的launch命令能配合 Claude Code、Hermes Agent、OpenClaw，前提是模型支持 tool calling。
• 云端逃生通道：本地硬件不够时，Ollama Cloud 提供托管路径，价格从 20 美元/月起。

Shimmy 强在哪

Shimmy 的优势是“没有东西”。

• CI/CD 流水线：5.1MB 二进制，没有运行时依赖，丢进任何容器或构建系统都干净。没有 Python，没有共享库，没有版本冲突。Shimmy 自己的 CI/CD 就用 Docker 交叉编译，因为 C++ 依赖（ring crate、llama.cpp）在 ARM64 构建里老出问题。
• 边缘和嵌入式：680MB 放不进去的地方，5.1MB 可以。树莓派、瘦客户端、锁死的工作站。Shimmy 的 CPU 开销不到 50MB。
• LoRA 工作流：Shimmy 原生支持 LoRA，运行时合并，不需要转换步骤。指向基础模型和 .gguf LoRA 适配器，直接服务微调后的模型。对频繁迭代领域微调的团队，这能省掉部署环节最烦的一段。
• 确定性推理：Shimmy 的认证会验证同一模型、同一种子、同一参数输出完全一致。测试和复现场景有意义。

一些真实的取舍

有中文评测说 Shimmy 一般使用“没优势”，因为安装不如 Ollama 一行命令方便，模型生态也窄。对只想跟模型聊天的普通开发者，这个评价没问题。

但角度不对。Shimmy 不是要做“更好的 Ollama”。它想做最小的 OpenAI 兼容推理服务器。问题不是“它比 Ollama 好用吗”，而是“它有没有必要存在”。

三种场景下，有必要：

• 你要在 CI/CD 里跑推理测试，不想让容器镜像膨胀
• 你要部署到 680MB 依赖不可接受的硬件
• 你想迭代 LoRA 适配器，又不想在训练和推理之间加转换步骤

和其他工具比

• llama.cpp：Ollama 和 LM Studio 底下的引擎。控制力最强，但要手动编译和配置。适合性能调优，不适合产品化流程。
• LM Studio：带 GUI 的闭源桌面应用。想要可视化、不想碰终端的人会喜欢。无头服务器和自动化流水线就算了。
• vLLM：高吞吐、多用户场景的 serving 引擎，有 PagedAttention 和连续批处理。适合生产级大规模推理，不适合单开发者工作站。
• Shimmy：占的生态位很具体。给已经有 OpenAI 兼容工具的开发者，提供最简单的本地推理服务器。二进制体积和启动时间没得挑，生态和模型广度比不了。

市场怎么看

本地 LLM serving 平台市场年复合增长 23.8%，2026 年到 38.1 亿美元。大约 65% 企业在评估 open-weight 模型，20% 已经把本地 LLM 放进生产。

两个趋势在推这件事。

• 企业需要合规的本地推理。GDPR、数据驻留、有些数据不能出楼，这些都在推采用。
• 开发者越来越把本地推理当默认，云当扩展。

Ollama 瞄准企业中间层。集成、文档、云回退、品牌都有。限制也真实：基于 VRAM 的上下文长度默认值出过问题，模型删除没文档，AMD ROCm 支持退步。但这些都是执行问题，不是架构问题。

Shimmy 瞄准边缘：CI/CD、嵌入式、隐私敏感工作站、LoRA 重度工作流。限制也清楚。一个维护者、认证模型列表窄、没有企业支持。它不会替掉大多数人的 Ollama。

总结

普通开发者，想少折腾，机器还行，Ollama 仍是默认。模型库没得比，CLI 干净，Open WebUI、FastGPT、Dify 这些生态让它成了本地 AI 工作流的重心。

如果你做的东西里，推理服务器的二进制体积很重要，启动延迟按毫秒算，或者你要直接服务 LoRA 适配器又不想搞转换流水线，Shimmy 值得下那 5.1MB。

这俩不是抢同一个位置。Ollama 正在变成平台，Shimmy 坚持做服务器。都有用。知道你需要哪个，才是真的省时间。