WEBVTT

00:00:00.000 --> 00:00:30.000
一台8級字節記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記記

00:00:30.000 --> 00:00:33.960
A426B、A4B跑到了Apple Silicon Mac上

00:00:33.960 --> 00:00:36.340
而且運行時權重加4K

00:00:36.340 --> 00:00:39.140
KV cache只佔大約二級字節內存

00:00:39.140 --> 00:00:40.940
這個數字最狠的地方

00:00:40.940 --> 00:00:42.580
不是省了一點內存

00:00:42.580 --> 00:00:46.320
而是把本地AI的門檻直接往下砸了一層

00:00:46.320 --> 00:00:49.880
原本14.3GB左右的模型安裝體積

00:00:49.880 --> 00:00:51.960
不需要整包塞進內存

00:00:51.960 --> 00:00:54.920
項目只把常駐核心留在內存裡

00:00:54.920 --> 00:00:58.000
把大部分專家權重放在SSD上

00:00:58.000 --> 00:01:00.000
需要哪一塊再讀哪一塊

00:01:00.000 --> 00:01:03.500
視頻裡在M3 Mac上跑到23.4 tokens

00:01:03.500 --> 00:01:07.240
項目ReadMe裡也記錄了8GBM2 MacBook Air

00:01:07.240 --> 00:01:10.400
可以跑到5.1到6.3 tokens

00:01:10.400 --> 00:01:13.800
這個速度不是數據中心級別

00:01:13.800 --> 00:01:15.440
但已經不是玩具

00:01:15.440 --> 00:01:17.400
這件事真正值得看

00:01:17.400 --> 00:01:20.160
不是某個開發者做了一個炫技項目

00:01:20.160 --> 00:01:22.860
而是本地AI的路線開始變了

00:01:22.860 --> 00:01:25.800
過去本地大模型的思路很簡單

00:01:25.800 --> 00:01:27.960
模型越大 硬件越貴

00:01:27.960 --> 00:01:29.360
想跑7B

00:01:29.360 --> 00:01:31.940
准备一块不错的消费级显卡

00:01:31.940 --> 00:01:33.600
想跑30B

00:01:33.600 --> 00:01:35.220
开始考虑大显存

00:01:35.220 --> 00:01:37.160
想跑更大的MOE

00:01:37.160 --> 00:01:38.760
就看云服务账单

00:01:38.760 --> 00:01:41.400
用户被迫接受一个隐含规则

00:01:41.400 --> 00:01:42.920
AI越聪明

00:01:42.920 --> 00:01:44.880
越远离个人电脑

00:01:44.880 --> 00:01:46.140
越强的模型

00:01:46.140 --> 00:01:47.760
越集中在云厂商

00:01:47.760 --> 00:01:50.440
GPU集群和数据中心手里

00:01:50.440 --> 00:01:53.540
TurboFuelFair给出的反方向答案是

00:01:53.540 --> 00:01:55.180
模型可以很大

00:01:55.180 --> 00:01:57.280
但每一秒真正用到的部分

00:01:57.280 --> 00:01:58.160
可能很小

00:01:58.160 --> 00:01:59.840
这要从Moei讲起

00:01:59.840 --> 00:02:02.260
Moei叫mixture of experts

00:02:02.260 --> 00:02:03.960
混合专家模型

00:02:03.960 --> 00:02:04.960
普通模型

00:02:04.960 --> 00:02:07.100
像一个巨大的统一车间

00:02:07.100 --> 00:02:08.580
每个Token进来

00:02:08.580 --> 00:02:10.560
很多权重都要参与计算

00:02:10.560 --> 00:02:14.600
MOE更像一座有128个小工位的工厂

00:02:14.600 --> 00:02:15.820
每个Token进来

00:02:15.820 --> 00:02:19.020
Router会判断这次该找哪几个专家处理

00:02:19.020 --> 00:02:20.740
Gamma 4 26B

00:02:20.740 --> 00:02:21.640
A4B

00:02:21.640 --> 00:02:23.640
总参数是26B

00:02:23.640 --> 00:02:25.400
但每个Token实际激活的

00:02:25.400 --> 00:02:27.640
大約是3.88B參數

00:02:27.640 --> 00:02:29.260
模型名義上很大

00:02:29.260 --> 00:02:32.680
但每一部真正幹活的只是其中一部分

00:02:32.680 --> 00:02:36.080
過去這件事的好處主要體現在雲端

00:02:36.080 --> 00:02:38.820
模型公司可以用更大的總參數

00:02:38.820 --> 00:02:41.280
保持相對可控的推理成本

00:02:41.280 --> 00:02:45.820
可是Turbo Fieldfare把這個特性拿到了本地機器上

00:02:45.820 --> 00:02:48.600
既然每個Token只用幾個專家

00:02:48.600 --> 00:02:51.860
那為什麼要把所有專家都常駐內存

00:02:51.860 --> 00:02:54.320
於是他把模型拆成兩堆

00:02:54.320 --> 00:02:57.000
第一堆是每個Token都要用的東西

00:02:57.000 --> 00:02:58.500
比如Attention

00:02:58.500 --> 00:02:59.560
Router

00:02:59.560 --> 00:03:00.720
Embedding

00:03:00.720 --> 00:03:02.200
Shared Expert

00:03:02.200 --> 00:03:03.860
還有KVcash

00:03:03.860 --> 00:03:06.460
這一部分大約1.35級字節

00:03:06.460 --> 00:03:08.640
加上運行需要的緩存

00:03:08.640 --> 00:03:09.960
留在內存裡

00:03:09.960 --> 00:03:11.940
第二堆是專家權重

00:03:11.940 --> 00:03:13.140
30層

00:03:13.140 --> 00:03:15.300
每層128個Expert

00:03:15.300 --> 00:03:17.300
每個Expert只有幾MB

00:03:17.300 --> 00:03:19.120
加起來是主要體積

00:03:19.120 --> 00:03:20.980
這一堆不常駐內存

00:03:20.980 --> 00:03:22.820
只放在SSD上

00:03:22.820 --> 00:03:24.260
每生成一個Token

00:03:24.260 --> 00:03:26.020
模型先完成Attention

00:03:26.020 --> 00:03:29.760
再由Router決定當前程要用哪8個專家

00:03:29.760 --> 00:03:31.420
CPU接到名單之後

00:03:31.420 --> 00:03:33.900
去SSD讀取對應Expert

00:03:33.900 --> 00:03:36.700
放到GPU能看到的內存區域裡

00:03:36.700 --> 00:03:38.260
Metal接著算

00:03:38.260 --> 00:03:40.140
這個過程聽起來麻煩

00:03:40.140 --> 00:03:42.300
但關鍵在Apple Silicon

00:03:42.300 --> 00:03:43.580
傳統PC上

00:03:43.580 --> 00:03:47.340
CPU和獨立GPU通常分兩套內存

00:03:47.340 --> 00:03:50.620
SSD讀出來的數據先進系統內存

00:03:50.620 --> 00:03:53.820
再通過PCIe總線搬到顯卡VRAM

00:03:53.820 --> 00:03:57.820
模型如果每個Token都要頻繁從SSD拉權重

00:03:57.820 --> 00:04:01.200
再搬進VRAM中間的拷貝和總線延遲

00:04:01.200 --> 00:04:03.260
會直接把速度打穿

00:04:03.260 --> 00:04:04.700
數據不是不會動

00:04:04.700 --> 00:04:06.860
而是動得太慢、動得太貴

00:04:06.860 --> 00:04:11.000
Apple Silicon的統一內存架構把這個問題變小了

00:04:11.000 --> 00:04:14.540
CPU和GPU看的是同一塊物理內存

00:04:14.540 --> 00:04:17.040
CPU從SSD讀進來的數據

00:04:17.040 --> 00:04:20.480
可以直接成為GPU要用的Metal Buffer

00:04:20.480 --> 00:04:21.880
少了一次拷貝

00:04:21.880 --> 00:04:23.780
少了一段總線搬運

00:04:23.780 --> 00:04:25.880
也少了傳統讀顯架構裡

00:04:25.880 --> 00:04:27.820
最難受的VRAM牆

00:04:27.820 --> 00:04:30.980
這就是為什麼這個項目特別像一把鑰匙

00:04:30.980 --> 00:04:34.280
它不是證明蘋果芯片算力天下無敵

00:04:34.280 --> 00:04:36.580
而是證明Apple Silicon的結構

00:04:36.580 --> 00:04:40.480
剛好適合一種邊讀邊算的本地推理路線

00:04:40.480 --> 00:04:41.580
還不只這個

00:04:41.580 --> 00:04:44.380
Turbo Fieldfare沒有把磁盤上的權重

00:04:44.380 --> 00:04:46.280
用普通格式存著

00:04:46.280 --> 00:04:48.780
等讀取之後再解包

00:04:48.780 --> 00:04:51.340
再轉成GPU需要的佈局

00:04:51.340 --> 00:04:55.700
他在安裝階段就把模型重新打包成Double格式

00:04:55.700 --> 00:05:00.040
盡量讓磁盤裡的數據就是Metal kernel可以消費的樣子

00:05:00.040 --> 00:05:02.600
讀文件就是加載權重

00:05:02.600 --> 00:05:06.960
中間少一次轉換就少一次內存浪費和時間浪費

00:05:06.960 --> 00:05:08.240
他還用了緩存

00:05:08.240 --> 00:05:10.540
每一層128個expert

00:05:10.540 --> 00:05:13.620
不可能每次都從SSD讀

00:05:13.620 --> 00:05:16.180
項目給每層留了16個expert

00:05:16.180 --> 00:05:19.000
槽位常用的expert放在內存裡

00:05:19.000 --> 00:05:21.900
Router如果選中已經緩存的expert

00:05:21.900 --> 00:05:23.600
立刻就能用

00:05:23.600 --> 00:05:24.880
如果沒命中

00:05:24.880 --> 00:05:26.680
再從SSD讀取

00:05:26.680 --> 00:05:28.340
把不常用的擠出去

00:05:28.340 --> 00:05:29.500
他用的是

00:05:29.500 --> 00:05:30.780
LFU

00:05:30.780 --> 00:05:32.820
Least Frequently Used

00:05:32.820 --> 00:05:35.760
也就是踢掉使用頻率最低的專家

00:05:35.760 --> 00:05:38.200
而不是簡單踢掉最久沒用的

00:05:38.200 --> 00:05:39.820
這個選擇很重要

00:05:39.820 --> 00:05:42.940
因為MOE的路由並不是完全隨機

00:05:42.940 --> 00:05:46.520
有些專家在很多Token上都會被反覆選中

00:05:46.520 --> 00:05:48.320
有些專家很少出現

00:05:48.320 --> 00:05:50.620
按頻率留下熱門專家

00:05:50.620 --> 00:05:54.200
比按時間留下最近專家更適合這個任務

00:05:54.200 --> 00:05:55.740
項目壓住的是

00:05:55.740 --> 00:05:58.560
語言深層的專家選擇有規律

00:05:58.560 --> 00:06:00.100
只要規律足夠強

00:06:00.100 --> 00:06:02.900
SSD讀取就不會把速度拖死

00:06:02.900 --> 00:06:05.980
所以它能做到一個很奇怪的效果

00:06:05.980 --> 00:06:10.080
明明模型大部分權重還在SSD上

00:06:10.080 --> 00:06:12.840
实际体验却没有慢到不能用

00:06:12.840 --> 00:06:15.620
这件事对普通用户意味着什么

00:06:15.620 --> 00:06:16.300
第一

00:06:16.300 --> 00:06:19.080
本地AI不一定只能靠堆硬件

00:06:19.080 --> 00:06:21.160
过去用户想跑更好的模型

00:06:21.160 --> 00:06:23.540
唯一办法是买更大内存

00:06:23.540 --> 00:06:24.780
更大显存

00:06:24.780 --> 00:06:25.900
更贵显卡

00:06:25.900 --> 00:06:29.560
这个逻辑会把个人电脑推向数据中心的反面

00:06:29.560 --> 00:06:31.140
云越来越强

00:06:31.140 --> 00:06:33.140
个人设备越来越像终端

00:06:33.140 --> 00:06:36.140
Turbo Field Fair展示的是另一条路

00:06:36.140 --> 00:06:37.840
如果模型结构

00:06:37.840 --> 00:06:38.760
文件布局

00:06:38.760 --> 00:06:43.160
操作系統、芯片內存架構和運行時配合的足夠好

00:06:43.160 --> 00:06:46.480
小機器也能吃下一部分大模型能力

00:06:46.480 --> 00:06:48.100
它不是免費午餐

00:06:48.100 --> 00:06:50.280
SSD讀取有延遲模型

00:06:50.280 --> 00:06:54.060
限制在特定結構速度和雲端旗艦模型沒法比

00:06:54.060 --> 00:06:55.940
但它證明了一個方向

00:06:55.940 --> 00:06:59.200
優化路線不是只剩買更貴的GPU

00:06:59.200 --> 00:07:00.020
第二

00:07:00.020 --> 00:07:03.600
Apple Silicon的AI價值可能被低估了

00:07:03.600 --> 00:07:05.340
過去評價AI硬件

00:07:05.340 --> 00:07:07.040
大家喜歡看TOPS

00:07:07.040 --> 00:07:08.300
看GPU

00:07:08.300 --> 00:07:09.720
看顯存大小

00:07:09.720 --> 00:07:12.600
蘋果在這場敘事裡經常顯得尷尬

00:07:12.600 --> 00:07:14.220
它的Neural Engine很強

00:07:14.220 --> 00:07:16.140
但開發生態不如Cuda

00:07:16.140 --> 00:07:17.700
統一內存很漂亮

00:07:17.700 --> 00:07:19.660
但高配內存價格很貴

00:07:19.660 --> 00:07:21.920
Mac很適合創作和開發

00:07:21.920 --> 00:07:23.940
但說到本地大模型

00:07:23.940 --> 00:07:26.080
很多人還是先想到NVIDIA

00:07:26.080 --> 00:07:29.040
Turbo FeelFair把問題換了一個角度

00:07:29.040 --> 00:07:32.000
蘋果真正的優勢不一定是單點算力

00:07:32.000 --> 00:07:36.280
而是CPU、GPU、內存、SSD、Metal

00:07:36.280 --> 00:07:38.200
和系統API的整合

00:07:38.200 --> 00:07:40.720
只要工作負債設計的夠貼合

00:07:40.720 --> 00:07:43.680
它可以用更少的數據搬運換性能

00:07:43.680 --> 00:07:45.440
這和手機時代很像

00:07:45.440 --> 00:07:48.600
蘋果不一定每個硬件參數都最大

00:07:48.600 --> 00:07:54.140
但它能把芯片、系統、應用和框架整在一起

00:07:54.140 --> 00:07:56.380
讓開發者吃到一體化紅利

00:08:04.854 --> 00:08:10.994
寫作、翻譯、代碼補權、文件整理、私人知識庫、

00:08:11.254 --> 00:08:14.334
離線助手、隱私敏感的資料分析

00:08:14.574 --> 00:08:17.134
如果這些場景能在普通Mac上運行

00:08:17.654 --> 00:08:19.194
蘋果就不是旁觀者

00:08:19.694 --> 00:08:20.214
第三

00:08:20.474 --> 00:08:23.034
雲端AI的壟斷感會被削弱

00:08:23.294 --> 00:08:25.854
過去AI服務天然集中在雲端

00:08:26.094 --> 00:08:27.134
因為模型太大

00:08:27.374 --> 00:08:28.154
推理太貴

00:08:28.414 --> 00:08:29.694
用戶設備跑不動

00:08:29.934 --> 00:08:31.734
集中在雲端就帶來幾個問題

00:08:31.994 --> 00:08:33.274
數據要上傳

00:08:33.534 --> 00:08:34.554
隱私要交出去

00:08:34.554 --> 00:08:36.154
订阅费要长期付

00:08:36.154 --> 00:08:37.874
网络断了就没法用

00:08:37.874 --> 00:08:39.354
模型公司改规则

00:08:39.354 --> 00:08:40.834
用户只能接受

00:08:40.834 --> 00:08:41.654
本地AI

00:08:41.654 --> 00:08:43.094
如果慢慢可用

00:08:43.094 --> 00:08:45.074
用户会多一个选择

00:08:45.074 --> 00:08:46.954
不是所有任务都要上云

00:08:46.954 --> 00:08:48.074
私人笔记

00:08:48.074 --> 00:08:49.494
公司内部文档

00:08:49.494 --> 00:08:50.914
离线代码助手

00:08:50.914 --> 00:08:51.974
本地搜索

00:08:51.974 --> 00:08:53.174
个人自动化

00:08:53.174 --> 00:08:56.114
这些场景其实很适合在设备端完成

00:08:56.114 --> 00:08:57.934
云端负责最强模型

00:08:57.934 --> 00:08:59.474
本地负责高频

00:08:59.474 --> 00:09:00.274
隐私

00:09:00.274 --> 00:09:02.054
低成本和机式响应

00:09:02.054 --> 00:09:03.754
这会改变产品形态

00:09:03.754 --> 00:09:07.594
未來AI助手可能不是一個純雲端聊天窗口

00:09:07.594 --> 00:09:09.294
而是一套混合系統

00:09:09.294 --> 00:09:10.994
簡單任務本地完成

00:09:10.994 --> 00:09:12.634
複雜任務再上雲

00:09:12.634 --> 00:09:14.734
敏感文件本地分析

00:09:14.734 --> 00:09:16.674
公開資料雲端補充

00:09:16.674 --> 00:09:18.914
離線場景用本地模型

00:09:18.914 --> 00:09:20.774
聯網場景用大模型

00:09:20.774 --> 00:09:22.854
用戶感覺不到背後切換

00:09:22.854 --> 00:09:24.614
只知道電腦更聰明了

00:09:24.614 --> 00:09:26.934
這也是蘋果真正想要的方向

00:09:26.934 --> 00:09:29.154
蘋果不會輕易把用戶數據

00:09:29.154 --> 00:09:30.974
全部交給第三方雲模型

00:09:30.974 --> 00:09:34.814
他更喜欢把智能功能藏进设备和系统

00:09:34.814 --> 00:09:39.274
Apple Intelligence的战略一直强调设备端处理和隐私边界

00:09:39.274 --> 00:09:40.534
问题在于

00:09:40.534 --> 00:09:42.834
设备端模型能力如果太弱

00:09:42.834 --> 00:09:45.074
体验就会被云端模型拉开

00:09:45.074 --> 00:09:46.494
Turbo Fieldfare

00:09:46.494 --> 00:09:50.054
这种项目说明设备端的能力上限

00:09:50.054 --> 00:09:51.634
还有很多工程空间

00:09:51.634 --> 00:09:53.834
这里要把苹果的处境讲透

00:09:53.834 --> 00:09:55.574
AI这轮浪潮里

00:09:55.574 --> 00:09:57.354
苹果一直显得慢半排

00:09:57.354 --> 00:09:59.474
OpenAI抢走聊天入口

00:09:59.474 --> 00:10:01.514
Google抢搜索和Android

00:10:01.514 --> 00:10:04.914
Microsoft把Copilot塞进Windows和Office

00:10:04.914 --> 00:10:06.734
NVIDIA拿走算力叙事

00:10:06.734 --> 00:10:09.394
苹果虽然发布Apple Intelligence

00:10:09.394 --> 00:10:11.894
但市场反应一直不算兴奋

00:10:11.894 --> 00:10:13.194
原因很简单

00:10:13.194 --> 00:10:16.894
苹果不是靠开放API和云模型赚钱的公司

00:10:16.894 --> 00:10:19.914
它擅长的是把能力变成系统体验

00:10:19.914 --> 00:10:22.994
可大模型初期最耀眼的能力都在云端

00:10:22.994 --> 00:10:25.514
苹果的优势一时很难展示

00:10:25.514 --> 00:10:27.914
Turbo Fieldfare这类项目的意义

00:10:27.914 --> 00:10:28.894
就在于

00:10:28.894 --> 00:10:31.454
它让苹果的优势重新有用

00:10:31.454 --> 00:10:34.714
如果AI的未来只是谁有最大数据中心

00:10:34.714 --> 00:10:36.754
苹果确实不占足场

00:10:36.754 --> 00:10:39.314
它没有NVIDIA那种GPU生态

00:10:39.314 --> 00:10:43.354
也没有Microsoft Azure或Google Cloud那种云入口

00:10:43.354 --> 00:10:47.094
但如果未来一部分AI工作要回到设备端

00:10:47.094 --> 00:10:49.374
苹果手里的筹码就多了

00:10:49.374 --> 00:10:50.654
它有统一内存

00:10:50.654 --> 00:10:51.834
有自研芯片

00:10:51.834 --> 00:10:52.654
有Metal

00:10:52.654 --> 00:10:54.494
有强控制的操作系统

00:10:54.494 --> 00:10:56.094
有高端用户设备

00:10:56.094 --> 00:10:59.514
也有一群愿意花钱买稳定体验的用户

00:10:59.514 --> 00:11:02.514
这件事最适合用一个普通场景理解

00:11:02.514 --> 00:11:05.194
一个用户坐在飞机上没有网路

00:11:05.194 --> 00:11:07.534
想让电脑整理本地笔记

00:11:07.534 --> 00:11:08.814
总结PDF

00:11:08.814 --> 00:11:10.394
查找项目文档

00:11:10.394 --> 00:11:12.214
生成一段邮件草稿

00:11:12.214 --> 00:11:14.414
如果所有AI都依赖云端

00:11:14.414 --> 00:11:16.814
这些任务马上变成半残废

00:11:16.814 --> 00:11:20.194
可是如果Mac本地能跑一个够用的模型

00:11:20.194 --> 00:11:22.314
很多事情就能直接做

00:11:22.314 --> 00:11:23.934
速度不一定顶级

00:11:23.934 --> 00:11:25.674
能力不一定最强

00:11:25.674 --> 00:11:29.094
但它能离线、私密、低延迟

00:11:29.094 --> 00:11:32.094
而且不需要每次把资料传出去

00:11:32.094 --> 00:11:33.654
对企业也是一样

00:11:33.654 --> 00:11:36.014
很多公司不是不想用AI

00:11:36.014 --> 00:11:39.654
而是不敢把内部资料全部丢给外部API

00:11:39.654 --> 00:11:45.074
法律合同、原代码、客户数据、医疗资料、财务表格

00:11:45.074 --> 00:11:46.654
这些内容一旦上传

00:11:46.654 --> 00:11:51.154
就牵涉权限、审计、地区合规和数据泄漏风险

00:11:51.254 --> 00:11:55.514
如果本地或私有设备端模型能处理一部分任务

00:11:55.514 --> 00:11:57.894
企业的AI使用门槛会下降

00:11:57.894 --> 00:12:01.474
它不需要替代GPT5这种旗舰模型

00:12:01.474 --> 00:12:05.014
只要把70%的日常任务吃下来

00:12:05.014 --> 00:12:06.674
价值就已经很大

00:12:06.674 --> 00:12:08.754
这也是为什么二级字节内存

00:12:08.754 --> 00:12:10.674
这个数字有流量潜力

00:12:10.674 --> 00:12:13.554
它让观众立刻听懂一个变化

00:12:13.554 --> 00:12:16.714
AI不再只属于云端巨头

00:12:16.714 --> 00:12:19.534
哪怕这个结论现在还不能完全成立

00:12:19.534 --> 00:12:21.494
它已经打开想象空间

00:12:21.494 --> 00:12:23.694
但这件事不能吹过头

00:12:23.694 --> 00:12:26.074
Turbo Fieldfare不是通用魔法

00:12:26.074 --> 00:12:30.634
它目前主要针对Gemma 426BA4B文本推理

00:12:30.634 --> 00:12:33.274
不支持图像、音频、视频

00:12:33.274 --> 00:12:35.694
也不是一个完整的Agent系统

00:12:35.694 --> 00:12:37.774
项目Redmi也写得很清楚

00:12:37.774 --> 00:12:39.614
它是Model Specific

00:12:39.614 --> 00:12:43.714
不是MLX或Lama.CPP那种通用包装器

00:12:43.714 --> 00:12:45.594
换模型不一定能照搬

00:12:45.594 --> 00:12:47.654
换硬件也不一定成立

00:12:47.654 --> 00:12:49.294
它需要Apple Silicon

00:12:49.294 --> 00:12:51.234
需要MacOS 26

00:12:51.234 --> 00:12:52.374
Metal 4

00:12:52.374 --> 00:12:56.534
Swift 6.2还需要足够的SSD空间

00:12:56.534 --> 00:12:58.354
它还有一个限时限制

00:12:58.354 --> 00:13:00.354
SSD不是内存

00:13:00.354 --> 00:13:03.354
SSD再快也比内存慢得多

00:13:03.354 --> 00:13:05.794
频繁读取权重会带来延迟

00:13:05.794 --> 00:13:08.674
也可能增加能耗和存储磨损

00:13:08.674 --> 00:13:10.634
缓存命中率如果不好

00:13:10.634 --> 00:13:11.914
速度就会掉

00:13:11.914 --> 00:13:13.194
掌上下文

00:13:13.194 --> 00:13:14.334
复杂提示

00:13:14.334 --> 00:13:16.394
多轮对话并发请求

00:13:16.394 --> 00:13:18.074
都会挑战这套设计

00:13:18.074 --> 00:13:20.014
视频里的23TOKENS

00:13:20.014 --> 00:13:22.054
是M3MAX上的演示

00:13:22.054 --> 00:13:23.414
8集字節MR

00:13:23.414 --> 00:13:26.014
MacBook Air的5到6Token

00:13:26.014 --> 00:13:28.934
更接近低配用戶会看到的体验

00:13:28.934 --> 00:13:31.074
能用不等于湿滑

00:13:31.074 --> 00:13:32.774
所以正确的判断

00:13:32.774 --> 00:13:33.994
不是MacBook

00:13:33.994 --> 00:13:35.734
从此取代云GPU

00:13:35.734 --> 00:13:38.634
而是本地AI的下限被抬高了

00:13:38.634 --> 00:13:39.834
这已经很重要

00:13:39.834 --> 00:13:42.674
还要补一个容易被忽略的成本账

00:13:42.674 --> 00:13:45.114
云端AI看起来省心

00:13:45.114 --> 00:13:47.594
但它的成本是持续性的

00:13:47.594 --> 00:13:49.314
用户每个月付订阅

00:13:49.314 --> 00:13:51.274
开发者按Token付费

00:13:51.274 --> 00:13:53.854
企业按席位和调用量付钱

00:13:53.854 --> 00:13:56.054
用的越多账单越高

00:13:56.054 --> 00:13:58.894
本地AI的成本更像买设备

00:13:58.894 --> 00:14:00.954
前期花钱买Mac

00:14:00.954 --> 00:14:03.594
后面用本地算力跑任务

00:14:03.594 --> 00:14:04.914
对高频任务来说

00:14:04.914 --> 00:14:07.334
本地推理会越来越有吸引力

00:14:07.334 --> 00:14:09.814
当然本地也不是不要成本

00:14:09.814 --> 00:14:12.894
它吃电、吃存储、吃内存

00:14:12.894 --> 00:14:14.834
也吃开发者优化时间

00:14:14.834 --> 00:14:18.434
可它的账单不再完全掌握在模型公司手里

00:14:18.434 --> 00:14:20.234
用户买了机器之后

00:14:20.234 --> 00:14:23.074
至少有一部分智能能力可以自己用

00:14:23.074 --> 00:14:25.054
这种心理差异很重要

00:14:25.054 --> 00:14:26.114
订阅时代

00:14:26.114 --> 00:14:29.494
用户越来越讨厌每个功能都按月收费

00:14:29.494 --> 00:14:32.194
本地AI如果能提供购用体验

00:14:32.194 --> 00:14:34.654
就会成为反订阅情绪的出口

00:14:34.654 --> 00:14:36.694
这会影响应用开发

00:14:36.694 --> 00:14:38.414
现在很多AI app

00:14:38.414 --> 00:14:40.934
只是套一层云端API用户

00:14:40.934 --> 00:14:42.674
输入文字服务器

00:14:42.674 --> 00:14:44.014
转发给模型

00:14:44.014 --> 00:14:46.254
再把结果显示回来

00:14:46.254 --> 00:14:48.394
这种产品门槛低替代也快

00:14:48.394 --> 00:14:50.234
未来真正有壁垒的应用

00:14:50.234 --> 00:14:51.834
可能会把本地模型

00:14:51.834 --> 00:14:52.914
云端模型

00:14:52.914 --> 00:14:53.914
本地文件

00:14:53.914 --> 00:14:54.974
隐私权限

00:14:54.974 --> 00:14:57.034
系统操作结合起来

00:14:57.034 --> 00:14:58.654
Mac上的本地AI应用

00:14:58.654 --> 00:15:00.434
尤其适合这么做

00:15:00.434 --> 00:15:03.294
因为它能直接贴近用户的文件

00:15:03.294 --> 00:15:04.134
日历

00:15:04.134 --> 00:15:04.994
邮件

00:15:04.994 --> 00:15:05.834
代码

00:15:05.834 --> 00:15:07.874
仓库和创作软件

00:15:07.874 --> 00:15:08.954
这样一来

00:15:08.954 --> 00:15:10.734
竞争重点就从

00:15:10.734 --> 00:15:12.314
谁接了最强API

00:15:12.314 --> 00:15:14.894
变成谁把AI放进真实工作流

00:15:14.894 --> 00:15:16.154
Turbo Field Fair

00:15:16.154 --> 00:15:17.934
没有解决所有产品问题

00:15:17.934 --> 00:15:20.654
但它说明底层可行性在提升

00:15:20.654 --> 00:15:22.354
底层每提升一点

00:15:22.354 --> 00:15:24.314
应用层就多一批可能

00:15:24.314 --> 00:15:28.114
AI行业过去几年一直在讲更大模型

00:15:28.114 --> 00:15:29.154
更大集群

00:15:29.154 --> 00:15:30.194
更大融资

00:15:30.194 --> 00:15:31.614
模型越来越强

00:15:31.614 --> 00:15:33.974
但普通用户越来越像租客

00:15:33.974 --> 00:15:34.914
账号

00:15:34.914 --> 00:15:35.754
订阅

00:15:35.754 --> 00:15:36.854
API

00:15:36.854 --> 00:15:38.114
云端限制

00:15:38.114 --> 00:15:39.234
数据上传

00:15:39.234 --> 00:15:41.574
所有能力都隔着一层平台

00:15:41.574 --> 00:15:43.214
Turbo Field Fair

00:15:43.214 --> 00:15:45.634
这种项目提醒了一件事

00:15:45.634 --> 00:15:46.854
AI的未来

00:15:46.854 --> 00:15:48.854
不一定只有超級數據中心

00:15:48.854 --> 00:15:51.614
也可以有一部分回到個人電腦

00:15:51.614 --> 00:15:53.314
這對開發者也有啟發

00:15:53.314 --> 00:15:55.134
以後做本地AI應用

00:15:55.134 --> 00:15:56.854
不能只問模型能不能跑

00:16:11.854 --> 00:16:14.974
誰能少搬一次數據誰就多一點性能

00:16:14.974 --> 00:16:16.974
誰能少佔一點內存

00:16:16.974 --> 00:16:18.894
誰就多一批用戶

00:16:18.894 --> 00:16:22.094
誰能把模型結構和硬件結構對齊

00:16:22.094 --> 00:16:24.654
誰就能把不可能變成勉強可用

00:16:24.654 --> 00:16:28.014
這也是蘋果生態裡可能出現機會的地方

00:16:28.014 --> 00:16:29.974
如果開發者圍繞Metal

00:16:29.974 --> 00:16:31.294
統一內存

00:16:31.294 --> 00:16:32.574
Neural Engine

00:16:32.574 --> 00:16:34.174
本地文件鎖影

00:16:34.174 --> 00:16:35.374
Spotlight

00:16:35.374 --> 00:16:37.374
Shortcuts做AI工具

00:16:37.374 --> 00:16:41.134
Mac可能會變成一個很獨特的本地AI開發平台

00:16:41.134 --> 00:16:43.714
不是為了和雲端模型硬碰硬

00:16:43.714 --> 00:16:46.334
而是做那些雲端不適合做的任務

00:16:46.334 --> 00:16:49.214
私密、離線、低延遲

00:16:49.214 --> 00:16:51.134
貼近個人文件系統

00:16:51.134 --> 00:16:54.314
真正的競爭不是本地和雲端誰消滅誰

00:16:54.314 --> 00:16:56.314
而是誰掌握默認入口

00:16:56.314 --> 00:16:58.414
雲端模型會繼續強

00:16:58.414 --> 00:17:02.254
因為訓練和最強推理都離不開巨量算力

00:17:02.254 --> 00:17:04.414
可是本地模型一旦夠用

00:17:04.414 --> 00:17:06.394
就會吃掉大量日常任務

00:17:06.394 --> 00:17:09.054
用戶不需要每次都請最強模型

00:17:09.054 --> 00:17:12.814
寫一封邮件 整理會議記錄 搜索本地文檔

00:17:12.814 --> 00:17:15.534
解釋一段代碼 生成一個小腳本

00:17:15.534 --> 00:17:19.554
夠快 夠私密 夠便宜 比絕對最強更重要

00:17:19.554 --> 00:17:23.134
這就是Turbo Fuel Fair事件的流量價值

00:17:23.134 --> 00:17:26.974
表面看 它只是內存減少7倍的技術新聞

00:17:26.974 --> 00:17:30.634
往深一層看 它在挑戰一個行業共識

00:17:30.634 --> 00:17:33.054
大模型必須被雲端壟斷

00:17:33.054 --> 00:17:36.814
它沒有推翻雲端AI 但它撕開了一條縫

00:17:36.814 --> 00:17:41.494
接下來要看的不是這個項目本身能不能變成大眾產品

00:17:41.494 --> 00:17:44.814
而是它代表的工程路線會不會擴散

00:17:44.814 --> 00:17:49.094
更多MOE模型會不會被專門打包成本地流氏格式

00:17:49.094 --> 00:17:53.834
更多Mac應用會不會接入本地OpenAI Compatible Server

00:17:53.834 --> 00:17:57.374
Apple會不會把類似思路放進系統級框架

00:17:57.374 --> 00:18:02.774
開發者會不會開始為8級字節、16級字節設備認真優化

00:18:02.774 --> 00:18:06.974
而不是默認要求64級字節內存和大顯卡

00:18:06.974 --> 00:18:08.774
如果這些事情發生

00:18:08.774 --> 00:18:12.874
本地AI就會從即刻演示變成產品基礎設施

00:18:12.874 --> 00:18:15.874
還有一個變量是模型公司本身

00:18:15.874 --> 00:18:18.274
如果更多模型採用MOE

00:18:18.274 --> 00:18:20.674
如果更多模型公開權重

00:18:20.674 --> 00:18:23.874
如果更多小模型追上日常任務能力

00:18:23.874 --> 00:18:26.174
本地推理就會更快普及

00:18:26.174 --> 00:18:29.474
Turbo Field Fair依賴Gamma-4這種結構

00:18:29.474 --> 00:18:31.774
不代表所有模型都能這麼跑

00:18:31.774 --> 00:18:34.674
但AI行業已經在往稀疏激活

00:18:34.674 --> 00:18:38.614
專用小模型、端側模型、模型路由方向走

00:18:38.614 --> 00:18:41.214
雲端超級模型負責難題

00:18:41.214 --> 00:18:43.314
端側模型負責日常

00:18:43.314 --> 00:18:45.854
多個模型組合起來完成任務

00:18:45.854 --> 00:18:48.654
這個方向對NVIDIA是提醒

00:18:48.654 --> 00:18:50.254
對蘋果是機會

00:18:50.254 --> 00:18:51.954
對開發者是新戰場

00:18:51.954 --> 00:18:55.234
NVIDIA仍然會統治訓練和高端推理

00:18:55.234 --> 00:18:58.834
可是如果越來越多日常推理回到端側

00:18:58.834 --> 00:19:02.634
市場對所有AI都必須上癮GPU的想像

00:19:02.634 --> 00:19:03.534
會降溫

00:19:03.534 --> 00:19:06.134
蘋果不一定搶走數據中心的錢

00:19:06.134 --> 00:19:08.834
但可以搶回個人設備的智能入口

00:19:08.834 --> 00:19:11.474
開發者如果能把本地模型用好

00:19:11.474 --> 00:19:14.554
就不用完全被API成本牽著走

00:19:14.554 --> 00:19:17.714
觀眾繼續聽下去應該帶走的判斷是

00:19:17.714 --> 00:19:19.914
這不是一個小工具新聞

00:19:19.914 --> 00:19:22.754
而是AI權力結構的小變化

00:19:22.754 --> 00:19:24.354
以前能力在雲端

00:19:24.354 --> 00:19:25.994
用戶只是調用者

00:19:25.994 --> 00:19:28.634
現在一部分能力開始回到設備

00:19:28.634 --> 00:19:31.074
用戶重新擁有一點控制權

00:19:31.074 --> 00:19:32.674
這一點現在還小

00:19:32.674 --> 00:19:34.214
但方向很清楚

00:19:34.214 --> 00:19:36.374
只要端側模型繼續變強

00:19:36.374 --> 00:19:39.774
本地AI就會從能跑走向好用

00:19:39.774 --> 00:19:42.374
再從好用走向默認存在

00:19:42.374 --> 00:19:44.814
接下來還要看一個更現實的變量

00:19:44.814 --> 00:19:46.054
內存配置

00:19:46.054 --> 00:19:48.654
蘋果這些年一直被吐槽入門

00:19:48.654 --> 00:19:50.054
Mac內存太小

00:19:50.054 --> 00:19:51.494
升級內存太貴

00:19:51.494 --> 00:19:53.494
過去這個潮點主要影響

00:19:53.494 --> 00:19:56.434
檢視頻、跑虛擬機、開大型項目

00:19:56.434 --> 00:19:58.034
到了本地AI時代

00:19:58.034 --> 00:20:00.334
它會變成更核心的購買理由

00:20:00.334 --> 00:20:03.914
8級字節能跑不代表8級字節最舒服

00:20:03.914 --> 00:20:07.514
16級字節會成為更合理的AI入門線

00:20:07.514 --> 00:20:09.174
32級字節

00:20:09.174 --> 00:20:14.014
64級字節會變成開發者和重度用戶的新分界

00:20:14.014 --> 00:20:16.594
Turbo Fuel Fair把門檻打低

00:20:16.594 --> 00:20:18.594
不代表硬件需求消失

00:20:18.594 --> 00:20:21.654
而是讓更多人第一次有資格進場

00:20:21.654 --> 00:20:24.494
這對蘋果的產品策略很微妙

00:20:24.494 --> 00:20:28.334
如果本地AI真的變成Mac的重要賣點

00:20:28.334 --> 00:20:33.074
蘋果就會有更強理由推動用戶買更高內存版本

00:20:33.074 --> 00:20:37.034
用戶過去買內存是為了今天的軟件

00:20:37.034 --> 00:20:41.394
未來買內存可能是為了未來幾年的本地模型

00:20:41.394 --> 00:20:43.174
蘋果當然喜歡這個股市

00:20:43.174 --> 00:20:45.734
因為它能提高Mac的平均售價

00:20:45.734 --> 00:20:47.534
但用戶也會更敏感

00:20:47.534 --> 00:20:49.834
既然AI要在設備端跑入門

00:20:49.834 --> 00:20:51.634
配置就不能太寒酸

00:20:51.634 --> 00:20:54.034
苹果如果繼續把內存升級

00:20:54.034 --> 00:20:55.674
價格定得很高

00:20:55.674 --> 00:20:58.414
反而會限制本地AI的普及

00:20:58.414 --> 00:21:00.734
另一個變量是SSD

00:21:00.734 --> 00:21:03.014
Turbo Fieldfare 的路線

00:21:03.014 --> 00:21:04.914
把SSD從單純存儲

00:21:04.914 --> 00:21:06.954
變成推理鏈路的一部分

00:21:06.954 --> 00:21:11.154
SSD速度、壽命、文件佈局、系統緩存

00:21:11.154 --> 00:21:12.394
都會影響體驗

00:21:12.394 --> 00:21:13.794
過去用戶選電腦

00:21:13.794 --> 00:21:16.194
看SSD主要是容量

00:21:16.194 --> 00:21:18.494
未來本地AI應用多了

00:21:18.494 --> 00:21:21.634
SSD讀寫性能也會被重新關注

00:21:21.634 --> 00:21:25.454
模型權重不再只是躺在硬盤裡的大文件

00:21:25.454 --> 00:21:29.754
而是生成每個Token時可能被反覆訪問的工作材料

00:21:29.754 --> 00:21:32.494
這會把電腦硬件評價體系改掉

00:21:32.494 --> 00:21:35.794
過去AI電腦宣傳喜歡堆TOPS

00:21:35.794 --> 00:21:39.094
以後真正懂行的人會看一整套鏈路

00:21:39.094 --> 00:21:40.694
內存帶寬夠不夠

00:21:40.694 --> 00:21:43.994
CPU和GPU是否共享內存

00:21:43.994 --> 00:21:46.994
SSD讀取延遲如何系統

00:21:46.994 --> 00:21:49.674
API能不能減少拷貝模型

00:21:49.674 --> 00:21:51.614
格式是不是貼合硬件

00:21:51.614 --> 00:21:54.394
單看一個算力數字很容易被騙

00:21:54.394 --> 00:21:57.174
AI推理的瓶頸可能不在算力

00:21:57.174 --> 00:21:58.674
而在數據搬運

00:21:58.674 --> 00:22:02.554
這也是Turbo Fieldfare給普通觀眾上的一刻

00:22:02.554 --> 00:22:05.414
AI不是只有模型聰不聰明

00:22:05.414 --> 00:22:07.194
還有數據怎麼流動

00:22:07.194 --> 00:22:10.614
同一個模型放在不同硬件結構上

00:22:10.614 --> 00:22:12.554
體驗可能完全不一樣

00:22:12.554 --> 00:22:15.134
未來優秀的本地AI產品

00:22:15.134 --> 00:22:18.214
背後一定不是簡單下載一個模型

00:22:18.214 --> 00:22:21.014
而是圍繞設備做深度優化

00:22:21.014 --> 00:22:22.694
最後給一個明確判斷

00:22:22.694 --> 00:22:25.634
蘋果芯片這次贏的不是模型參數

00:22:25.634 --> 00:22:27.674
也不是Benchmark排名

00:22:27.674 --> 00:22:30.234
而是設備端AI的敘事權

00:22:30.234 --> 00:22:33.814
過去AI敘事被NVIDIA和雲廠商拿走

00:22:33.814 --> 00:22:38.434
大家談的都是GPU、集群、數據中心和API

00:22:38.434 --> 00:22:40.474
Turbo Fieldfare

00:22:40.474 --> 00:22:43.034
讓另一個問題重新回到桌面

00:22:43.034 --> 00:22:45.534
如果模型不必全部進內存

00:22:45.534 --> 00:22:48.234
如果CPU和GPU共享內存

00:22:48.234 --> 00:22:50.574
如果SSD能參與推理

00:22:50.574 --> 00:22:53.754
如果應用能直接貼著硬件寫本地

00:22:53.754 --> 00:22:56.114
設備還能不能變成AI的主廠

00:22:56.114 --> 00:22:57.174
檔案還沒訂

00:22:57.174 --> 00:23:00.814
但這次Mac不再只是調用雲模型的屏幕

00:23:00.814 --> 00:23:04.614
它開始像一台真正能存在AI的個人機器

00:23:04.614 --> 00:23:06.594
如果這個趨勢繼續

00:23:06.594 --> 00:23:09.754
未來買電腦時就會多一個新問題

00:23:09.754 --> 00:23:12.294
這台機器能不能把個人資料

00:23:12.294 --> 00:23:15.054
工作流和本地模型連起來

00:23:15.054 --> 00:23:17.274
過去電腦拼的是性能

00:23:17.274 --> 00:23:19.794
後來拼的是續航和生態

00:23:19.794 --> 00:23:22.234
接下來可能要拼本地智能密度

00:23:22.234 --> 00:23:25.434
蘋果芯片這次露出的牌就在這裡

00:23:25.434 --> 00:23:28.634
誰能讓AI更貼近用戶自己的設備

00:23:28.634 --> 00:23:30.014
自己的文件

00:23:30.014 --> 00:23:31.714
自己的隱私邊界

00:23:31.714 --> 00:23:34.814
誰就能在雲端巨頭之外拿回一塊入口