很多人是在某一次具体需求上卡住的：想把公司合同丢给模型读，又担心内容上传；或者想试个新模型，本地装了 Ollama 才发现笔记本风扇狂转、回答还慢。这篇不堆参数，按普通用户真实关心的几件事——怎么用、花不花钱、数据在哪、卡不卡、能不能离线——把 Ollama 和豆包摆在一起比，最后给一份照着勾就能定的选择清单。
很多人是在某一次具体需求上卡住的：想把公司合同丢给模型读，又担心内容上传；或者想试个新模型，本地装了 Ollama 才发现笔记本风扇狂转、回答还慢。这两种踩坑方式正好对应两条完全不同的路线，一条是自己养，一条是直接买。
这篇不堆参数，按普通用户真正关心的几件事——怎么用、花不花钱、数据在哪、卡不卡、能不能离线——把 Ollama 和豆包摆在一起比。最后给一份照着勾就能定的清单，以及万一选错了该怎么换过去。
先把两样东西的身份分清楚
Ollama 是本地跑模型的工具，模型权重下载到你自己的电脑上，靠本机显卡和内存出结果；豆包是云端服务，模型跑在厂商机房里，你只用浏览器或 App 发请求。一个是「工具加权重」，一个是「成品服务」，所以对比的实质是自己养和直接买这两条路，不是两个同层产品。
还有一个容易混淆的点：Ollama 自己不生产模型，它只是负责拉取和运行别人开源的模型。也就是说，你换一个权重，能力表现就会变一截，它本身没有固定的能力水平。可以顺手到 /models 的模型库里看看有哪些权重可用、各自大概擅长什么。
- Ollama：你提供硬件和电费，它提供运行环境，模型来自开源社区
- 豆包：你提供问题，厂商提供从模型到机房到前端的完整链路
- 两者不是替代关系，可以同时存在，敏感活儿给本地，泛问答给云端
上手方式：装软件 vs 注册账号
Ollama 的启动顺序是：装客户端、拉模型权重、起本地服务、接前端或写代码调用。中间任何一步卡住，对外都可能表现为「没反应」，所以排查必须按这个顺序走，别一上来就怀疑模型不行。想先知道自己这台机器到底能不能跑得动，可以到 /tools/speed-test 量一下本机基线。
- 第 1 步：确认硬件看显存和内存够不够你打算跑的权重档位，不够就先降档，别硬上；具体门槛到 /models/deploy 按机型算。
- 第 2 步：拉权重并本地起服务权重没拉完就调用，表现就是连不上或超时，先确认服务真的起来了再往下走。
- 第 3 步：接一个前端验证用最简单的对话界面跑通一轮，确认能出字、能连续对话，再谈接业务。
- 第 4 步：固定参数把温度、上下文长度这类参数记在文档里，否则下次复现不出来会以为是模型退化。
豆包这一侧的门槛几乎只有注册登录，手机和网页都能直接用，不用管显卡型号、驱动版本、量化格式。判断标准很直接：如果你只想今天就用上、明天就要出活，云端起步更快；如果你要反复调同一个模型、或者要把它嵌进自己的程序里，本地的可控性才值钱。
不适用的情况也要说清楚：团队里没人愿意碰命令行，硬上 Ollama 大概率是装完就闲置，最后大家还是回去用网页版。
花钱的方式完全不同，别只比一个数字
Ollama 的账是一次性硬件加电费加时间。模型本身多数不要钱，但你要为显存和硬盘买单，而且这笔钱在跑不动的时候会变成换机器的钱。云端是订阅或按量计费，用多少算多少，不想用了随时停。各家当前的档位、额度和计费口径不一样，到 /plans 和 /official-api 核对当时的数字，别按旧印象下单。
| 对比项 | Ollama 本地 | 豆包云端 |
|---|---|---|
| 谁出硬件 | 你自己 | 厂商 |
| 付费节奏 | 一次性投入加电费 | 订阅或按量 |
| 额度上限 | 受本机算力限制 | 受套餐额度限制 |
| 不用的代价 | 硬件闲置 | 停掉即可 |
| 超支风险 | 换机器的支出 | 超额度后单价变化 |
两类隐藏成本不一样：本地的隐藏成本是「跑不动要换机器」，云端的隐藏成本是「用量超了之后单价口径变了」。这两件事都要提前想好兜底方案。算总账的方法在 /tools/model-cost-calculator，把你自己的月用量填进去再比，比看别人的结论靠谱得多。
数据往哪走，决定了很多场景只能选一边
本地跑的时候，输入内容不出你的机器，断网也能用，这一点对合同、病历、内部文档这类材料是硬需求。云端服务的请求要经过网络到厂商侧，能不能接受取决于你的材料敏感度和所在单位的合规要求。这事别自己拍脑袋，先问清楚再动手。
- 材料完全不能外传：只能本地，没有折中余地
- 材料可以脱敏后再问：先处理掉关键字段，再走云端
- 普通问答和写作：数据流向不是主要矛盾，看哪个顺手
- 归属不清的材料：按最严口径先假设，事后改比事后补救容易
一个常见的折中做法是两套并存：敏感内容走本地、泛化问答走云端。它们不冲突，只是你要多花点心思做分流，比如给不同任务定个默认走哪边的规矩。
日常体验差在哪：速度、能力、稳定性
速度上，本地取决于你的显卡和内存，同一台机器上模型越大越慢；云端速度相对稳定，但高峰期也可能排队变慢。能力上，云端服务后面往往挂的是参数更大的模型，复杂推理、长文档处理通常更稳；本地能跑的多是小一点的或量化过的权重，能力会打折扣。量化档位怎么取舍可以看 /ai-dict/category/tech 里的解释。
稳定性上，本地不怕断网但怕你自己把服务关了或者机器休眠；云端不怕你关机但依赖网络和平台可用性，出问题的时候可以到 /ai-status 看服务状态，先排除是不是平台侧的事。
- 任务简单且高频、对延迟敏感：本地反而有优势，省去了网络往返
- 要处理长文档或多模态：云端通常更省事
- 要一个永远在线的固定接口：本地的可控性更强，但要保证机器不休眠
- 只是偶尔问几句：本地的硬件投入收不回来
按场景对照：这几类人该选哪边
| 你的情况 | 更合适的选择 |
|---|---|
| 材料不能外传、要离线 | 本地 Ollama |
| 只是问答写作、要处理长文档 | 云端豆包 |
| 用量波动大、不想压硬件 | 云端豆包 |
| 要长期高频调用并接进自己的脚本 | 本地 Ollama |
| 涉密环节加普通问答混合 | 两边并存做分流 |
| 一个月只问几十次 | 云端豆包 |
两边都要的情况其实很常见：主流程走云端、涉密环节走本地，或者反过来本地做草稿、云端做终稿。关键是别指望一套方案覆盖所有任务，那通常意味着两边都不好用。
不适用的情况也要提醒一句：如果你的用量小到一个月只问几十次，本地那笔硬件钱基本收不回来，直接云端更省心，省下的时间成本比电费值钱。
真要从一边换到另一边，按这个顺序动
- 第 1 步：先备份本地要记下模型名和自定义参数，云端要导出历史会话与提示词模板，换过去之后想回看还有依据。
- 第 2 步：对齐能力换过去之后拿同一批真实任务各跑一遍，别用别人的榜单结论代替自己的样本；榜单怎么读参考 /guides/model-select。
- 第 3 步：改接入点接口地址、鉴权方式、超时设置都要重建，接口形态的差异先看 /ai-dict/category/infra。
- 第 4 步：留回退路旧方案并行保留一到两周，确认新方案在你的真实任务上不掉链子再切干净。
新手最容易踩的几个坑
- 以为装了 Ollama 就等于有了模型，其实还要单独拉权重，第一次用别跳过这步
- 拿本地小模型的结果去评价「开源模型不行」，样本本身就选偏了，开源与闭源的差别可以看 /guides/open-vs-closed-model-basics
- 只看单价不看额度口径，订阅制和按量的计费方式不一样，换算方法到 /tools/token-price-calculator 对一遍
- 模型换了但提示词没改，效果变差却怪模型，换模型时提示词也要跟着调
- 把本地机器休眠当成服务挂了，排查顺序里先确认进程和电源设置
选本地还是选云端，本质是问自己：这份材料能不能出这台机器，以及这个活儿值不值得为它养一台机器。下一步先把你的真实任务列出三条，再到站内价格与模型页面按当时的数字算一遍，两边各跑一轮再决定；顺便看一眼中转站的检测结果，能帮你避开接入环节的坑。→
常见问题
Ollama 和豆包是同一类东西吗？能不能直接比？
不是同一层。Ollama 是本地运行模型的工具，模型权重在你机器上；豆包是云端成品服务，模型跑在厂商机房。所以比的是「自己养」和「直接买」两条路，比的时候要按使用方式、成本、数据流向分开看，不能只看回答质量。
本地跑 Ollama 就一定能保证数据不外传吗？
基本前提是你全程不联网调用外部接口，模型权重和对话都在本机。但如果你在 Ollama 上接了联网搜索、云端知识库或者第三方前端，数据还是会出去。要真正不出内网，得把整条链路都检查一遍，别只看模型这一层。
普通笔记本装 Ollama 能跑得动吗？
能装，但能跑多大的模型取决于显存和内存，小模型或者量化版本通常跑得起来，大模型会明显变慢甚至装不下。具体到你机型的上限，到 /models/deploy 按配置填一遍，比问别人「我的电脑行不行」准确。
豆包这种云端服务是不是一定比本地强？
在同档任务上云端通常更稳，因为后面挂的模型更大、机器更好。但如果你只是做简单分类、格式转换，本地小模型够用而且不花钱；反过来，长文档、复杂推理这类活，本地笔记本硬扛体验会很难受。
能不能两个一起用？怎么分工？
可以，而且对很多人是最优解。常见分工是敏感材料、离线场景走本地，长文档、多模态、能力要求高的走云端。麻烦的地方在于你要维护两套接入和两套提示词，团队小的话先想清楚谁来管。
