俗话说：士别三日，当刮目相看。在AI圈，这话得改成“士别三小时”。让我看看，到底是谁这么大阵仗？
刚打算喝口水，一看GitHub，Ollama竟然为了跑通Google最新的Gemma 4模型，直接将版本升级到了v0.20.0。要知道，我们上次测试的时候（8G显存跑AI：Llama3.1完胜Qwen3.5？Ubuntu下四大模型横评，速度竟差一倍！），ollama的版本还是v0.18.4，而这，仅仅是上周的事情！
换句话说，上个版本v0.19.0，也仅仅保持了4天不到。
自古好马配好鞍，咱手里的RTX4070又是时候拉出来溜溜了。接下来，让我们见识一下最新版ollama叠加Gemma 4的变态性能！还是老问题：
你是一个资深网络工程师。我现在的网络拓扑如下：R1和R2运行OSPF，都在Area 0。R2和R3运行BGP（eBGP）。R2将OSPF路由重分发进了BGP。
现在出现了一个故障：R3能够学习到R1的Loopback接口路由，但是R3无法ping通R1的Loopback接口。请列出排查此故障的3个最可能原因，并给出具体的排查命令（假设设备为华为VRP操作系统）。要求逻辑严密，不要有废话。
看，输出速率109.58 TPS，相比上次测试的冠军选手llama3.1:8B的50.4 TPS，大幅提升117 %。简直是天下武功、唯快不破。
注意看，这次gemma4的模型参数跟以往有所不同，这里面别有洞天。
对于以往的常规模性参数（目前来看，ollama量化过的DeepSeek模型应该就是最具性价比的选择），文件大小是可以预估的。比如bf16精度，模型文件大小近似为模型参数量的2倍，例如gemma4:31b-it-bf16的模型大小为63 GB；如果是INT8量化，模型文件大小比模型参数量稍大一些，例如gemma4:31b-it-q8_0的模型大小为34 GB；如果是INT4量化，模型文件大小比模型参数量的一半稍大一些，例如gemma4:31b-it-q4_K_M的模型大小为20 GB。我们之前测试的llama3.1:8B的INT4量化版本模型文件大小为4.9 GB，qwen3.5:9B的INT4量化版本模型文件大小为6.6 GB。
如果按照这个规律，这个gemma4:e2b-it-q4_K_M模型文件的大小应该不超过2 GB，但实际呢？
7.2 GB，这还是Gemma 4所有模型里面最小的模型了，也是我RTX4070能运行的最大模型。
如果按照常规模型文件大小反推，7.2 GB比9B模型的6.6 GB还要大，那实际模型参数可能已经达到10B。模型名称中的e实际上就是“Effective”系列，虽然逻辑表现对标2B，但其物理参数可能高达10B。而Effective的效果就是，Google为了让它拥有超越量级的智商，往里面塞了海量的知识密度。它的脑容量很大，但思考路径很短。浓缩的都是精华，膨胀的都是显存。
据说，Gemma 4 E2B-IT的整体能力已经逼近Gemma 3 27B，甚至在AIME 2026（数学/逻辑）、LiveCodeBench v6（编程）、τ2-bench（Agent任务流）等方面大幅领先。
对了，它还支持图像识别呢，我们换成截图再试试。
依旧很稳定，输出速度为105.62 TPS。
资源占用方面，显存相对吃紧，达到了7383 MB，超过90 %，再大估计就要卸载到CPU了。
那我们试试搭配codex一起跑一下。
可以看到，因为模型参数比较小，显存也比较小，跑任务还是有点难度，分明有128K上下文却没有七秒钟的记忆，竟然还跟我玩起了“马什么梅啊”的梗。看来在本地工具调用的协议上，这头猛兽还有点水土不服。
虽然目前它还像一个四肢发达、头脑简单的壮汉，但别担心，谷歌这次更新的Effective架构肯定会被其他家跟进。而且他是开源的，应该很快，我们就能看到国内模型跟进这种以小博大的思路，实现遥遥领先的弯道超车了！
你觉得Google这种“虚报参数、实打实占显存”的策略，是技术革新还是显存刺客？如果让你用RTX 4070跑模型，你是要体积小、功能弱的轻量级，还是体积大、功能全的全能王？
行配置呢？
声明：来自铁军哥，仅代表创作者观点。链接：https://eyangzhen.com/7258.html
