泥潭日报 uscardforum · 内容汇总

Google欣然发布Gemma4,本地模型媲美云端大模型不是梦?

内容摘要

Gemma4 QAT本地部署遇阻,Diffusion架构引发vLLM兼容性争议。

1. 关键信息

  • Gemma 4 推出量化感知训练(QAT)检查点,旨在降低内存需求并提升设备端性能 (#53)。
  • Unsloth 已提供 Gemma 4 QAT 的 GGUF 格式模型下载 (#53)。
  • Google 发布 DiffusionGemma 技术指南,引入基于扩散的并行解码、双向上下文和自我修正机制,宣称能提升推理速度 (#54)。

2. 最新动态

  • Google 官方博客发布 Gemma 4 QAT 技术文章,强调通过训练阶段引入量化噪声来提升推理效率 (#53)。
  • Unsloth 社区迅速跟进,提供了优化后的 GGUF 文件,方便本地用户直接加载使用 (#53)。
  • 开发者关注 DiffusionGemma 的落地情况,但实测发现 vLLM nightly 版本尚不支持该架构,存在“宣称开箱即用”与实际兼容性的落差 (#54)。

3. 经验与数据点

  • 性能对比:Gemma 4 12B实测表现不佳,OCR识别差、CoT冗长,在多项测试中不如 Qwen3.5 9B/26B-A3B,无法平替后者 (#50, #51)。
  • 推理成本:本地模型推理在与 DeepSeek V4 API 对比时,无明显优势 (#52)。
  • 硬件限制:M芯片运行需高配内存(如 M5 Max 需 128G),受带宽瓶颈制约 (#10, #13, #34)。

4. 争议或不同意见

  • 基准偏差:部分用户指出 Google 的 Benchmark 存在选择性偏差,可能夸大了模型表现 (#15, #23)。
  • 能力差距:尽管小模型能力提升,但与 Claude/GPT 等云端大模型的差距依然巨大 (#44)。
  • 算力本质:峰值用量仍需集中运算,本地化无法完全消除对算力的依赖 (#3, #9)。
  • 工具链成熟度:DiffusionGemma 虽宣称支持 vLLM,但实际运行困难,引发社区对 Google 宣传与实际工程落地能力差距的质疑 (#54)。

5. 行动建议

  • 部署优化:利用 Unsloth 提供的 QAT GGUF 模型进行本地部署,可进一步降低显存占用并提升速度 (#53)。
  • 替代方案:若追求小模型顶尖水平,优先测试 Qwen3.6-35B-A3B 等密集模型 (#46);短 Prompt 长任务可利用 Cache 降成本 (#43)。
  • 跟进验证:建议等待 vLLM 正式版本支持 DiffusionGemma 后再尝试部署当前架构,避免使用不稳定的 nightly 版本 (#54)。
原始内容
--- 第 1 楼来自 zpahai 的回复 (2026-04-02 10:36:43 PDT) ---

这里是post,可以看到31B的dense模型elo分数已经逼近400B MoE的QWEN3.5模型了,虽然还够不到T0的模型但是已经很有威慑了 https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/ https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/ Gemma 4: our most intelligent open models to date, purpose-built for advanced reasoning and agentic workflows. 这里是其他核心benchmark结果,是不是意味着以后简单的工作可以交给本地模型了,但是是不是高分低能还得验证 https://ai.google.dev/gemma/docs/core/model_card_4?hl=zh-cn https://ai.google.dev/gemma/docs/core/model_card_4?hl=zh-cn

--- 第 2 楼来自 258 的回复 (2026-04-02 10:38:27 PDT) ---

还利好英伟达和数据中心吗 最伟司是储存股最严厉的父亲

--- 第 3 楼来自 zpahai 的回复 (2026-04-02 10:50:36 PDT) ---

感觉算力的需求不会消失,不然不会搞出峰值用量这种东西了

--- 第 4 楼来自 illusionwing 的回复 (2026-04-02 10:53:08 PDT) ---

31B量化下是不是24-32g就能跑了

--- 第 5 楼来自 maruha 的回复 (2026-04-02 10:58:28 PDT) ---

最大的问题不还是本地显卡用什么吗

--- 第 6 楼来自 zpahai 的回复 (2026-04-02 11:01:13 PDT) ---

/uploads/short-url/iFhkiKrutOWGcG15rzrA7Yls2DE.png?dl=1

--- 第 7 楼来自 zpahai 的回复 (2026-04-02 11:05:49 PDT) ---

基本只有4090/5090这种选择吧,这么看来魔改4090的性价比实在极高。但是趋势是目前小模型的capabilities已经到一个比较可用的水平了

--- 第 8 楼来自 kaiyoyo 的回复 (2026-04-02 11:07:37 PDT) ---

DGX Spark 跑起来给自己用 问题不大 /uploads/short-url/hdt23IbWi6ZfyfLCWIkRGiaJmBZ.png?dl=1

--- 第 9 楼来自 258 的回复 (2026-04-02 11:15:36 PDT) ---

https://www.uscardforum.com/t/topic/488959/1 现在的数据中心狂潮都是基于未来推理需求必须通过集中运算才能实现。 小模型哪天也搞了个scaling law 然后参数量对数下降 也不是没可能? 数学估算能很快达到一个5-8B的可用模型

--- 第 10 楼来自 列.伊.勃列日涅夫 的回复 (2026-04-02 11:16:55 PDT) ---

利好M5 Max? 苹果这统一内存还真走对了吗

--- 第 11 楼来自 DeusX 的回复 (2026-04-02 11:18:02 PDT) ---

很适合做 agent 里的 eval

--- 第 12 楼来自 tomandjerry 的回复 (2026-04-02 11:31:49 PDT) ---

m5 pro 48g 不行吗,带宽不够?

--- 第 13 楼来自 zpahai 的回复 (2026-04-02 11:32:18 PDT) ---

M chip的问题在于TPS太低,内存是没问题

--- 第 14 楼来自 Cookies 的回复 (2026-04-02 11:36:41 PDT) ---

让Claude做了个对比,大多数benchmark上都打不过Qwen 3.5 27B /uploads/short-url/7Qkpz4z1GFPO1vFoc2z42dT0Ryd.png?dl=1

--- 第 15 楼来自 zpahai 的回复 (2026-04-02 11:38:21 PDT) ---

那确实是PPT大师了 只选了好的benchmark

--- 第 16 楼来自 258 的回复 (2026-04-02 11:39:16 PDT) ---

qwen 27b含金量这么高吗

--- 第 17 楼来自 zpahai 的回复 (2026-04-02 11:41:44 PDT) ---

qwen3.5 27b算是小模型里面顶尖的了

--- 第 18 楼来自 xjx 的回复 (2026-04-02 11:48:12 PDT) ---

谷歌最近搞抽象水平高涨,先是用别人Cpu跑的Bench跟自己Gpu跑的对比,现在又搞这一套

--- 第 20 楼来自 gggideon 的回复 (2026-04-02 13:48:05 PDT) ---

啥Gemma 4 不行的意思吗?

--- 第 21 楼来自 EndangeredZeegull 的回复 (2026-04-02 13:58:17 PDT) ---

感情狗哥拉了坨大的

--- 第 22 楼来自 折木奉太郎 的回复 (2026-04-02 14:00:06 PDT) ---

现在利好内存了,还有苹果 不过果子那玩意卖8000不知道什么需求要自己买

--- 第 23 楼来自 xjx 的回复 (2026-04-02 14:19:55 PDT) ---

上面不是发了吗?也就是跟QWEN27B水平差不多罢了,可能某些方面更强一点,只不过搞一些春秋笔法只提好的不提坏的

--- 第 24 楼来自 天天被反薅 的回复 (2026-04-02 14:21:12 PDT) ---

是CPU的计算速度太慢吗

--- 第 25 楼来自 zpahai 的回复 (2026-04-02 15:58:16 PDT) ---

我自己没有mac但是我看m4 pro实际可用的也就是10b以下的模型。大的模型不是不能跑,是达不到可用的速度,当然有人的觉得10tps属于可用,这个就不好评价

--- 第 26 楼来自 Alila 的回复 (2026-04-02 16:30:11 PDT) ---

列.伊.勃列日涅夫: M5 Max 配环境就能配死你

--- 第 27 楼来自 Koiost 的回复 (2026-04-02 16:55:50 PDT) ---

LM Studio或者羊驼都很简单吧? /uploads/short-url/2b44zr57LyvwOqSzimeBn9W9iJY.png?dl=1

--- 第 28 楼来自 258 的回复 (2026-04-02 18:05:00 PDT) ---

等等党

--- 第 29 楼来自 jnnksn 的回复 (2026-04-02 19:12:09 PDT) ---

啥东西8000

--- 第 30 楼来自 jnnksn 的回复 (2026-04-02 19:13:14 PDT) ---

蹲一个1B

--- 第 31 楼来自 不知道是谁 的回复 (2026-04-02 19:17:03 PDT) ---

这时候都还打不过qwen也太拉了

--- 第 32 楼来自 折木奉太郎 的回复 (2026-04-02 19:18:16 PDT) ---

M5 max加128g内存的macbook

--- 第 33 楼来自 jnnksn 的回复 (2026-04-02 19:19:15 PDT) ---

Mac Studio便宜得多吧,现在才3149,键盘屏幕溢价严重

--- 第 34 楼来自 tomandjerry 的回复 (2026-04-02 19:39:27 PDT) ---

m5 max + 128g,瓶颈是m5 max了吧,空有内存,跑70b有什么速度?

--- 第 35 楼来自 折木奉太郎 的回复 (2026-04-02 19:45:14 PDT) ---

https://www.youtube.com/watch?v=A5w_k3GAwrQ jnnksn: Mac Studio便宜得多吧 主要是买M5,以后也许会便宜

--- 第 36 楼来自 tomandjerry 的回复 (2026-04-02 19:47:42 PDT) ---

买8个mac mini组集群

--- 第 37 楼来自 jnnksn 的回复 (2026-04-03 00:25:26 PDT) ---

万兆网口够用吗

--- 第 38 楼来自 tomandjerry 的回复 (2026-04-03 00:26:13 PDT) ---

不够,得十万兆的

--- 第 39 楼来自 harvey8 的回复 (2026-04-03 00:33:39 PDT) ---

十万兆?贫穷限制了我的想象力

--- 第 40 楼来自 Keiour 的回复 (2026-04-03 01:04:23 PDT) ---

自己刚量化了w,Q6_K本体略小于24G, + 64k上下文刚好31G,Q4_K_M本体17.5G,带64k上下文能塞进24G的卡。3090的含金量还在上升。 感觉Gemma 4思考挺短的,上下文再长意义不是很大。

--- 第 41 楼来自 Alila 的回复 (2026-04-03 02:11:32 PDT) ---

只跑inference当然可以,我还以为说的是用来做research,因为我想不到不依赖CUDA怎么进行finetune 只跑inference的话为什么不直接烧api或者冲subscription呢,买一个M5 Max的MacBook pro 16的钱够你冲几十年了

--- 第 42 楼来自 zuiaiwufan 的回复 (2026-04-03 02:43:07 PDT) ---

以后能不能手机跑的模型都干爆Claude4.6?

--- 第 43 楼来自 EndangeredZeegull 的回复 (2026-04-03 02:54:01 PDT) ---

Inference 的话也要看具体应用场景啊 如果prompt长,cache hit 高,本地inference的cache hit 成本是0,而且cache可以落盘,所以有几种情况合算 多个长input的prompt,超过在线api TTL 定期运行 长inout的prompt,没超过在线api ttl,但是频率很高而且没有特别多生成的token(龟速),主要为prefill

--- 第 44 楼来自 Alila 的回复 (2026-04-03 08:06:12 PDT) ---

问题是<30B的小模型相比于Claude, GPT这种上T的大模型效果差距太大了,完全无法比较 现在感觉小模型唯一用处就是VLA

--- 第 45 楼来自 Onvon 的回复 (2026-04-03 08:59:15 PDT) ---

用on-prem的小模型解决一些涉及PII的应用场景还是不错的

--- 第 46 楼来自 Keiour 的回复 (2026-04-16 14:21:40 PDT) ---

https://huggingface.co/Qwen/Qwen3.6-35B-A3B来了 简单测了几个自己的test case感觉只用半个月时间又把gemma 4 26b踢死了 就差一个dense模型了

--- 第 47 楼来自 BigCongming 的回复 (2026-04-16 16:27:34 PDT) ---

用上了,感觉确实不错

--- 第 48 楼来自 IrishCoffee 的回复 (2026-06-03 20:39:09 PDT) ---

https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemma-4-12b/ https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemma-4-12b/ An overview of Gemma 4 12B, a model designed to bring high-performance multimodal intelligence directly to your laptop. 珍码4 12B现已加入豪华套餐

--- 第 49 楼来自 jnnksn 的回复 (2026-06-03 20:52:19 PDT) ---

前几天出了个差不多的,记不起来名字了

--- 第 50 楼来自 Keiour 的回复 (2026-06-03 21:00:31 PDT) ---

测了半小时这模型,本来想试试这玩意q6能不能打赢q3的26b a4b了,结果感觉速度和质量双输 为了测unified model的图像能力给这模型喂了几个截图,结果OCR都OCR不清楚,CoT还贼长,感觉远不能平替26b a4b

--- 第 51 楼来自 cxfcxf 的回复 (2026-06-03 21:10:15 PDT) ---

测了 什么垃圾玩意儿 不如qwen3.5 9b一根毛

--- 第 52 楼来自 serelee 的回复 (2026-06-03 21:13:52 PDT) ---

本地模型和deekseek v4 api比起来都没啥优势

--- 第 53 楼来自 Keiour 的回复 (2026-06-05 12:39:03 PDT) ---

https://blog.google/innovation-and-ai/technology/developers-tools/quantization-aware-training-gemma-4/ https://blog.google/innovation-and-ai/technology/developers-tools/quantization-aware-training-gemma-4/ We’re releasing Gemma 4 quantization-aware training checkpoints, reducing memory requirements and improving on-device performance. 还有高手? https://huggingface.co/collections/unsloth/gemma-4-qat 顺便放一下Unsloth的GGUF在这里

--- 第 54 楼来自 Keiour 的回复 (2026-06-10 13:24:57 PDT) ---

https://developers.googleblog.com/diffusiongemma-the-developer-guide/ https://developers.googleblog.com/diffusiongemma-the-developer-guide/ Learn how DiffusionGemma reimagines text generation with diffusion-based parallel decoding, bidirectional context, and self-correction, delivering faster inference and new possibilities for customization and deployment. 有人把这个跑起来了吗?vLLM的nightly也不行啊怎么敢吹自己有out of the box vLLM支持的