L2 可复现实测实测手记编辑结论：值得关注

开源可自托管本地运行无需KeyCPU推理量化

执行主体：WorkBuddy 手机小程序端 AI 智能体（主理人发起指令，AI 在云端实际执行全部命令）

核验日期：2026-07-15（复核到期 2026-10-15）

8GB 内存、无 GPU 的云端沙箱，能跑多大的本地模型？

实测手记（field_note）· 核验等级 L2 可复现实测 · 2026-07-15

执行方式说明：这篇实测的所有动手环节——开沙箱、装 Ollama、拉模型、发接口请求、读返回、判定内存瓶颈——不是人手工敲的，而是我（主理人）在手机上通过一个 AI 助手的小程序，用自然语言发出指令，由 AI 智能体在云端逐条执行完成的。我全程只在手机上看它跑。这一点本身也是这次实测的一部分，文末单独说。

一、这个实验到底想回答什么

一个很多人都有的疑问：现在的大模型，如果没有独立显卡、只有一台内存不大的普通机器，到底能不能在本地把模型跑起来、跑起来能用到什么程度？

网上的"本地部署"教程，配置动辄 16–32GB 内存、4090 / A100。对只想"先试试 AI 到底能干啥"的人，这个门槛劝退。所以真正的问题不是"能不能装上"，而是：

在一台 8GB 内存、没有 GPU 的机器上，纯靠 CPU，能跑多大参数的模型？边界在哪？

手头正好有一个云端开发沙箱（CloudStudio）：cgroup 限制下真实可用内存 8GB、无 GPU、多核 CPU。用它做实验，好处是零成本、随开随关、跑坏了不心疼本机。

二、谁做的、怎么做的（方法与可复现步骤）

执行主体：本次实验由 WorkBuddy 手机小程序端的 AI 智能体执行。主理人用自然语言下达目标（"在这个 8GB 无 GPU 的沙箱里装 Ollama，看看能跑多大的模型"），AI 负责把目标拆成命令、连到云端沙箱、逐条执行、读回结果、判断瓶颈。主理人没有手动敲任何一条命令——这既是实验方式，也是一个可被复述的事实。

技术栈：Ollama 作为模型运行器，其推理后端是 llama.cpp（这是当前 CPU 推理生态的事实标准，负责把 GGUF 格式的量化权重加载进内存并做逐 token 计算）。

可复现步骤（任何有 Docker 的 Linux 环境都能照做）：

用 Docker 拉起 Ollama 容器，监听 11434 端口；
拉取模型 qwen2.5:3b（Q4_K_M 量化，约 1.9GB 磁盘）；
通过 Ollama 的 HTTP 接口做最小验证：GET /api/tags（列模型）、POST /api/generate（生成）、POST /v1/chat/completions（OpenAI 兼容接口）；
逐步尝试更大的模型（7B、14B），观察内存与速度边界。

合规前提：以下步骤仅用于在符合平台条款的个人或学习环境内复现本实验；不鼓励将免费沙箱用于长期服务或生产流量，也不提供任何绕过限制的做法。

一个必须澄清的坑：沙箱里 free -h 显示约 123GB 内存，这是误读——它读的是宿主机总量，容器实际被 cgroup 限制在 8GB。判断"能不能跑",必须以 cgroup 限额为准，不能看 free。这个坑很常见，是 AI 在执行中主动识别并纠正的。

三、它真的跑起来了（真实输出，非描述）

最小验证的真实返回：

GET /api/tags → HTTP 200，模型列表含 qwen2.5:3b ✅
POST /api/generate，输入"1+1 等于几"，返回：

1+1等于2。

总耗时约 5.19 秒，其中约 3.36 秒是首次加载模型权重进内存（冷启动），真正生成只占 ~1.8 秒；
POST /v1/chat/completions（OpenAI 兼容）同样正常返回。

先给结论：3B 级别的模型，在 8GB 内存、无 GPU 的机器上，确实能跑、能答对、响应在秒级。 对"想零成本试本地模型"的人，这是个实打实的好消息。

四、技术拆解：为什么 3B 能跑、14B 跑不动（这才是关键）

这一节是这篇的核心，把"能/不能"背后的内存账算清楚。

4.1 量化：把模型"压小"到能进内存

原始模型权重是 FP16（每个参数 2 字节）。3B 模型 FP16 就要 3.09e9 × 2 ≈ 6.2GB，加上运行开销，8GB 会很紧张。

Q4_K_M 量化把权重压到平均约 4.5 bit/参数（K 系列是 llama.cpp 的分块量化，对不同层用不同精度，比朴素 Q4_0 更省且质量损失更小）。于是：

|---|---|---|---|---|

| Llama 3.2 1B | 1B | ~0.7GB | ~1.5GB | ✅ 轻松 |

| Gemma 2 2B | 2B | ~1.4GB | ~2–3GB | ✅ 可以 |

| Qwen2.5 3B | 3.09B | ~1.9GB | ~2.5–4GB | ✅ 本次实测通过 |

| Phi-3.5 mini | 3.8B | ~2.4GB | ~4–5GB | ⚠️ 勉强 |

| 7B 级 | 7B | ~4.5GB | ~6–8GB | ⚠️ 边缘，易抖动 |

| 14B 级 | 14B | ~8GB | ~9–10GB+ | ❌ 本次实测 OOM |

数据交叉自 Ollama 官方模型页、多份 CPU 实测评测（见文末参考），并与本次沙箱实测吻合。

4.2 为什么 14B 必然 OOM

14B 参数即使 Q4_K_M 压到 ~4.5 bit，光权重就约 14e9 × 4.5 / 8 ≈ 7.9GB——已经逼近 8GB 上限。再叠加：

KV cache（上下文缓存，随对话长度线性增长）；
推理时的激活值与运行时开销；

总需求突破 8GB，内核 OOM killer 直接杀进程。这不是"调一调就能过"的问题，而是内存账本身就不够——除非换更激进的量化（Q2_K/Q3，但质量明显下降）或加内存。

4.3 为什么 7B "能跑但难受"

7B Q4_K_M 权重约 4.5GB，理论上 8GB 装得下，但留给 KV cache 和系统的余量很小。一旦上下文变长或系统吃点内存，就会触发 swap（换页到磁盘），而磁盘比内存慢几个数量级——多份评测显示，此时单次响应会从秒级劣化到几十秒级，失去实用价值。所以 7B 在 8GB 上是"能演示、不能用"。

4.4 纯 CPU 推理的代价

无 GPU 时，全部矩阵运算落在 CPU 上。多核能并行、缓解一部分，但相比 GPU 的大规模并行仍慢一个量级。本次 3B 能到秒级，是因为模型足够小 + 量化到位 + 多核三者叠加的结果，不是"CPU 也能随便跑大模型"。

五、它有明确的天花板（不写全就是误导）

除了模型大小，环境本身也有硬限制：

沙箱会话是临时的：空闲后容器会被回收，这正是它作为"一次性实验环境"的设计——不应试图让它长期常驻，那既违背免费沙箱的用途，本身也不稳定。
web 网关不是稳定公开接口：外部访问走的是带会话令牌的调试网关（形如 …sandbox.cloudstudio.club?x-cs-sandbox-id=…&x-cs-sandbox-port=11434），它是给开发者在浏览器里预览用的，不是设计来当长期公开 API。
平台条款限制用法：该沙箱 FAQ 明确"不可执行消耗大量资源的任务"、每日限约 4 小时、空间数与并发受限，服务为 best-effort 的 beta，可能随时关停且不保留数据。

所以——这是实验场、学习场，不是生产后端。 这是本次实测最重要的边界结论。

六、合规立场：只做测评，不钻空子

写这一节，是因为这次实验用的是一个免费的云端开发沙箱，而测评类内容最容易被读歪成"教人白嫖、钻漏洞"。先把底线说清楚：

1. 实验全程在平台条款内进行，没有绕过任何限制。

CloudStudio 的免费沙箱有明确约定：不可用于消耗大量资源的任务、每日有使用时长上限、空间与并发数量受限、服务为 best-effort 的 beta、可能随时关停且不保留数据。本次实测严格遵守这些边界——只在沙箱里做了一次性的模型加载与调用验证，没有把它当长期服务挂起、没有试图突破时长或并发、没有写入任何生产流量。它证明了"在这种环境下能做这样的实验"，仅此而已。

2. 不把免费资源当羊毛薅，也不教人这么干。

本文的结论之一是"沙箱非生产"。这既是技术事实，也是态度：免费沙箱是给开发者学习、试错用的，不是用来替代付费托管的。本文不提供任何"如何让免费沙箱常驻""如何绕开限制"的做法，也不建议把这类环境当成业务后端——既违反平台条款，也极不稳定，对使用者自己也没好处。

3. 我们是做测评的，不是找漏洞的。

作为中文测评站，我们持一个朴素的立场：守规矩、讲真话。本篇的立场是：如实记录能力边界、如实标注限制与风险、不夸大、不诱导绕过规则。Ollama 能在 8GB 无 GPU 上跑 3B，是它真实的优点；沙箱会回收、14B 会 OOM、免费服务可被关停，是它真实的限制。把"能"和"不能"都讲清楚，就是一次合格的测评——而不是一份"怎么占便宜"的攻略。

一句话收口：这篇只是证明了"现有工具 + 一台普通配置的云端环境，足以完成一次本地模型的真实验证"。能力到位了，分寸也要到位。

七、适合谁 / 不适合谁

适合：

想零成本、不填信用卡、不拿 API Key 就试本地模型的人；
想搞懂 Ollama / llama.cpp / 量化 / CPU 推理到底怎么回事的学习者；
重视隐私、不想把数据发第三方 API 的人（本地跑，数据不出机）；
做一次性实验、草稿、分类、简单问答。

不适合：

想要稳定常驻的公开服务（沙箱会回收、网关非生产）；
需要 7B 以上模型但只有 8GB 内存、无 GPU；
对响应速度敏感的真实业务；
完全不碰命令行的人（虽然本次是 AI 代跑，但你自己复现仍需基础环境）。

八、真想长期用，怎么办

本机升级：内存加到 16–32GB，或加一块入门显卡，就能舒服跑 7B–14B；
正规托管 API：用有明确 ToS 的托管服务（含免费档），比把沙箱当生产后端靠谱得多；
继续当实验场：就在这儿学、做一次性验证，接受它会回收、会慢。

九、两点观察（这是观点，标注为观点）

前面都是可复现的事实。下面两点是我的主观判断，读者可不同意：

1. 软件层面——"AI 代跑"这件事本身，比结论更值得注意。

这次从判断内存瓶颈、识别 free 误读、到逐个模型试边界，是 AI 智能体自己在云端完成的，我只在手机上发了一句目标。也就是说，一个非专业用户，靠一部手机 + 一个 AI 小程序，就完成了一次过去需要懂 Docker、懂 llama.cpp、懂量化的人才能做的实验。工具把门槛降到这个程度，是这两年最实在的变化——不夸张地说，这类"能动手执行、能自我纠错"的智能体，正在把"会不会"重新定义成"会不会问"。

2. 硬件与模型层面——国产开源模型在小尺寸段确实能打。

本次跑的 Qwen2.5-3B 出自阿里云 Qwen 团队，Q4_K_M 下不到 2GB、8GB 内存无 GPU 就能中英文问答且答得稳。这不是"因为它国产所以夸"，而是它在 3B 这个尺寸段的实测表现，对"想在弱硬件上落地"的场景是真的合适。小尺寸、强中文、开源可自托管——这几条叠起来，对国内普通用户的门槛友好度是实打实的。

需要说清楚的分寸：以上两点是实测之后的感想，不构成对任何产品的背书。这篇的骨架仍是"3B 能跑、14B 不能、沙箱非生产"这三个可复现的事实。

十、编辑结论

Ollama 是值得关注的开源项目：一条命令、无需 Key、MIT 协议、活跃维护，把"本地跑模型"的门槛压到极低。本次实验验证了"8GB 无 GPU 也能跑 3B 级模型"为真，并把"14B 为何必然 OOM、7B 为何能跑但难受"的内存账算清楚了。

但本次验证仅限实验沙箱，未在任何真实项目里长期部署，故核验等级标 L2 可复现实测，不标 L3。把沙箱当生产后端既不合规也不可靠——这是本篇最重要的边界。

*收录 ≠ 推荐。本篇是实验记录，不是购买 / 部署建议。*

---

参考资料（Sources）

Ollama 官方 · qwen2.5 模型页（3.09B 参数、Qwen2 架构、32K 上下文、Q4_K_M ~1.9GB、RAM ~2.5GB、CPU-only）— https://ollama.com/library/qwen2.5
Qwen 团队（阿里云）· Qwen2.5-3B-Instruct 模型说明（Qwen Research License）
llama.cpp 项目 · GGUF 量化与 K-quant 分块量化说明 — https://github.com/ggml-org/llama.cpp
多份纯 CPU / 商务本 Ollama 实测评测（Qwen2.5-3B ~2GB 内存、7B+ 在低内存 CPU 上因 swap 抖动至数十秒级，失去实用价值）
CSDN 技术问答 · Qwen2.5-3B INT4 量化最低配置（3B 约需 3–4GB 内存、7B 需 6–8GB）
CloudStudio 沙箱 FAQ · 资源与时长限制、beta 可关停条款

引用说明：以上为本次实测的技术依据来源，数据均与本次沙箱实测结果交叉核对一致。参考文献不构成对上述第三方内容准确性的独立担保。