用 YOGA27 ULTRA9-285H 32G1TSSD 6GRTX4050 27 给三星 S24 Ultra 补算力：端侧大模型的边界与实测

dctc_青龙

三星 S24 Ultra 的 Galaxy AI，把通话实时翻译、录音转写、笔记摘要这些活压在了本地跑。但端侧模型到底多大，三星一直不说，公开资料只提到这些功能离线也能用。

用起来的分界线挺清楚：一旦是长文档理解，或者多轮代码推理，系统就悄悄把请求扔回云端了。Galaxy AI 的端侧能力大概停在 3B 这个级别——这既是手机 NPU 的物理上限，也是散热和功耗预算一起定下来的结果。

那能不能把一部分推理分给近端设备？这大概是眼下比较务实的做法。我拿一台 YOGA27 ULTRA9-285H 32G1TSSD 6GRTX4050 27 一体机当推理宿主，让 S24 Ultra 走局域网调它，看看这条链路到底能不能用。

## 手机为什么卡在 3B：三个硬约束

要说清楚近端链路为什么有必要，得先讲手机自己为什么扛不住。

骁龙 8 Gen 3 for Galaxy 的 Hexagon NPU 标称 45 TOPS，纸面上是 Core Ultra 9 285H 那颗 13 TOPS NPU 的三倍多。但这数字基本不能直接换算成"能跑多大模型"。

**头一个是内存带宽。** S24 Ultra 用的是 LPDDR5X-4800，四通道加起来 76.8 GB/s。大模型解码时，每出一个 token 都要把全部活跃权重从内存搬到计算单元一遍，几乎不复用。所以生成速度的上限，近似就是"带宽 ÷ 模型体积"。

3B 的 Q4 量化权重大概 2.0 GB，76.8 GB/s 的理论天花板是 38 tok/s 左右。实测通常落在 15–20 tok/s，效率五成上下，已经算不错了。同一个模型换到 7B（约 4.4 GB），天花板立刻掉到 17 tok/s。而且还没算一件事：手机根本不可能让 7B 常驻内存——系统、相机、微信一起来抢，模型直接被杀。

**第二个是功耗和散热。** 手机 SoC 的持续功耗预算就在 3–5W 这个量级，短时爆发能上 10W 以上，但玻璃后盖加被动散热，长时间满载是撑不住的。跑 30 秒翻译没问题，跑 10 分钟长文档摘要就开始降频，速度断崖式往下掉。

**第三个是内存容量。** 12GB LPDDR5X 要分给 Android、常驻应用、相机缓冲，真正留给模型的常驻空间只有 3–4GB。厂商的端侧模型都停在这个尺寸，不是算力不够，是放不下、也喂不饱。

## 测试环境和部署路径

宿主是这台 YOGA27 ULTRA9-285H 32G1TSSD 6GRTX4050 27：Core Ultra 9 285H（6P+8E+2LPE 共 16 核，NPU 标称 13 TOPS，平台 AI 算力合计约 99 TOPS）、32GB LPDDR5x、1TB SSD，加一块 RTX 4050 Laptop 6GB GDDR6。

**整台机器跑推理的关键，其实是这块独显的 192 GB/s 显存带宽。** 96 位宽听着窄，但对比手机那 76.8 GB/s，已经是 2.5 倍了。终端是 S24 Ultra（骁龙 8 Gen 3 for Galaxy，12GB 内存，One UI 6.1）。

部署三步搞定，全程不用 root，也不用 adb。

**第一步，宿主侧装 Ollama，开放监听。** 装完设环境变量：

```
OLLAMA_HOST=0.0.0.0:11434
OLLAMA_KEEP_ALIVE=30m
OLLAMA_FLASH_ATTENTION=1
OLLAMA_KV_CACHE_TYPE=q8_0
OLLAMA_NUM_PARALLEL=1
```

`FLASH_ATTENTION` 能明显压住长上下文的显存占用，`KV_CACHE_TYPE=q8_0` 把 KV Cache 从 fp16 压到 8 位，精度损失极小。6GB 的卡上，这两个基本是必开项。

**第二步，放行端口。** Windows 防火墙对专用网络默认是拒绝入站，管理员 PowerShell 加一条规则：

```
netsh advfirewall firewall add rule name="Ollama-11434" dir=in action=allow protocol=TCP localport=11434
```

这里踩坑的人不少。手机端表现出来是"连接超时"，不是"连接被拒绝"，看着像 IP 写错了，其实是包被防火墙静默丢了。加完规则，先用手机浏览器访问 `http://<宿主IP>:11434/api/tags`，能返回 JSON 列表再往下走。

**第三步，拉模型、填端点。** 拉 `qwen2.5:3b-instruct-q4_K_M`、`llama3.2:3b`、`qwen2.5:7b-instruct-q4_K_M` 三个量化权重。手机端用支持自定义 OpenAI 兼容端点的客户端，Chatbox、Enchanted、NextChat 都行。Base URL 填 `http://<宿主内网IP>:11434/v1`，API Key 随便填个非空字符串就行。

顺手在路由器上把宿主的内网 IP 做静态绑定。不然 DHCP 一续租换了地址，手机端每次都得重配一遍。

## 实测数据

连续 20 轮对话取均值，提示词统一 512 token，输出上限 512 token，环境温度 24℃：

| 模型（Q4_K_M） | 驻留方式 | 首 token | 生成速度 | 显存占用 |
|---|---|---|---|---|
| Gemma2-2B | 全 GPU | 0.22 s | 58 tok/s | 2.2 GB |
| Llama3.2-3B | 全 GPU | 0.28 s | 44 tok/s | 2.9 GB |
| Qwen2.5-3B | 全 GPU | 0.31 s | 46 tok/s | 3.0 GB |
| Qwen2.5-7B | 24/29 层卸载 | 0.94 s | 17 tok/s | 5.7 GB + 1.4 GB 共享 |

拿这张表跟带宽上限对一下，规律挺明显。

2B 权重约 1.4 GB，192 GB/s 的理论天花板是 137 tok/s，实测 58，达成率 42%；3B 权重约 2.0 GB，天花板 96 tok/s，实测 44–46，达成率 48%。**不到一半是正常的。** KV Cache 读写、注意力计算、采样、tokenize 都在占时间，工程上能到 50%，已经算调得不错了。

7B 那一行不能按同一个口径看。24/29 层卸载，意味着大部分计算走 CPU 和系统内存，而 DDR5-6400 双通道带宽只有 100 GB/s 出头，还得和操作系统分。所以 17 tok/s 的瓶颈已经从显存换成内存总线了，跟上下文长度强相关。

对照一下：S24 Ultra 本地跑摘要，延迟在 0.4–0.8 s 量级，但能处理的上下文长度和任务类型是系统限死的，不接受任意提示词。近端链路的价值从来不在速度，在于任务可以自由定义——你可以让它按自己的模板输出，可以往里面塞三万字会议记录，也可以让它连续调工具。

## 端到端延迟，其实分三段

用户感觉"卡不卡"，是三段延迟叠出来的。

**预填充（prefill）**：把 512 token 的提示词过一遍。这步是算力密集型，不是带宽密集型，RTX 4050 大概 0.1–0.15 s。上下文越长这块钱越贵，而且是按平方涨（注意力那部分），三万 token 的长文本，预填充能到 1.5 s 以上。

**解码（decode）**：逐 token 生成，带宽密集型。3B 模型 46 tok/s，等于每 token 21.7 ms，生成 300 字要 6.5 秒。这项没法靠换更强 GPU 大幅改善，只能靠更高带宽或者更小的模型。

**网络往返**：手机和宿主同连 5GHz Wi-Fi 6，空载 RTT 6–9 ms，512 token 的首包端到端多 40 ms 左右，用户基本察觉不到。切到 4G 就完了，上传带宽成瓶颈，首 token 延迟飙到 1.6 s 以上，没有实用价值。**这条链路的前提是同一个局域网，不是"有网就行"。**

三段加起来，3B 模型答一个 300 字的回复，总耗时约 7 秒；7B 约 18 秒。前者勉强算"能对话"，后者更像"提交完任务去看别的"。

## 6GB 显存的真实边界

关键卡在显存。6GB GDDR6，7B Q4 光权重就 4.4GB，加 KV Cache 直接溢出，Ollama 会自动把部分层退回 CPU，吞吐跟着明显下滑。3B 及以下倒是能全驻 GPU。

KV Cache 吃多少，其实能手算。Qwen2.5-7B 是 28 层、4 个 KV 头、head_dim 128。每个 token 每层要存 K 和 V 两份：2 × 4 × 128 = 1024 个数值，fp16 下 2 KB，乘 28 层约 57 KB/token。8K 上下文就是 470 MB，32K 就是 1.87 GB。

4.4 + 1.87 = 6.27 GB，已经超了。这就是 7B 在 6GB 卡上"能跑但跑不好"的原因——上下文一长，卸载层数就变，延迟跟着抖。

Qwen2.5-3B 是 36 层、2 个 KV 头，只有 37 KB/token，8K 上下文 295 MB，加上 2.0 GB 权重才 2.3 GB。6GB 卡余量很足，上下文拉到 32K 都还有富余。

两个能动手的地方：把 `OLLAMA_KV_CACHE_TYPE` 设成 `q8_0`，KV Cache 直接减半；或者管住 `num_ctx`，别默认给到 32K，按实际需要设 8K。很多"7B 跑不动"的抱怨，根源是 `num_ctx` 开太大，KV Cache 把显存撑爆了。

14B 这个级别，在这台机器上只能走 CPU。32GB 内存放得下 Q4 权重（约 9GB），实测生成 4 tok/s 左右，只适合离线批处理，交互别想。整机 32GB 内存是这台一体机的隐形优势：就算模型全在 CPU 上跑，也不会把系统拖进 swap。

## 散热和功耗

散热比轻薄本强。RTX 4050 在 45W 功耗墙下连续推理 30 分钟，GPU 温度稳在 72℃，频率没见阶梯下降。一体机的风道空间在这里体现出来了。同样配置的 14 寸轻薄本跑同一个负载，十分钟内就摸到 80℃ 以上开始降频。

整机推理功耗约 85W，是手机端侧方案的十几倍。这也是近端只能当补充、替代不了端侧的根本原因。

顺手算笔账。85W 满载一小时 0.085 度电，按 0.6 元/度约 0.05 元；这段时间 3B 模型能生成约 16 万 token。按国产 API 每百万输出 token 两元估算，同等量约 0.33 元。再加上机器摊销（8000 元、三年、每天满载 8 小时，约 0.9 元/小时），本地其实不比云端便宜多少。

**选本地不是为了省 API 费。** 是为了数据不出内网、没有速率限制、提示词可以无限次试错。

## 兼容性和几个高频问题

三类问题最常见。

**模型被卸载。** Ollama 默认 `keep_alive` 是 5 分钟，超时就卸载，下次请求要重新加载，冷启动 3–6 s。建议改成 `keep_alive: "30m"`，或者用环境变量全局设。症状很好认：聊几句停一会儿，再问就特别慢。

**端口通不了。** Windows 防火墙对专用网络默认不放行 11434，手机那头表现是连接超时而不是拒绝。另外注意别把服务绑在 `127.0.0.1`，那样局域网设备永远连不上。

**7B 延迟不稳定。** 6GB 显存上 7B 虽然能跑，但卸载层数随上下文增长而波动，同一个提示词首 token 延迟能差 30%。做延迟敏感的应用，直接锁 3B。

还有两个安全项值得提一句。Ollama 的 11434 端口没有任何鉴权，能连到这个 IP 的设备都能调用，也能通过 `/api/pull` 拉模型把硬盘占满。**只在家里或办公室内网开，绝不要做公网端口映射。** 要外网访问就走 Tailscale 或者 SSH 隧道，加密和身份验证都是现成的。另外 `/api/delete` 没有二次确认，误删一个模型，几个 GB 得重新下。

想要更细的控制——自定义量化、`n-gpu-layers` 精确调参、投机解码——可以换 llama.cpp 或者 LM Studio。Ollama 底层就是 llama.cpp，只是把这些旋钮封装掉了。

## 谁适合这么干

开发者用它验证提示词工程和工具调用链路，成本远低于云端 API，数据还不出内网。文字工作者处理长篇素材时，7B 的理解深度明显强过手机端侧 3B，代价是等待从秒级变成十几秒。对隐私敏感的用户，本地闭环基本是唯一选项。

但如果需求只是翻译、摘要、通话辅助，S24 Ultra 自带的 Galaxy AI 已经够了。额外搭一套近端推理，属于过度设计。

## 趋势判断

端侧 3B 管即时响应和隐私任务，近端 7–14B 管深度推理——这种分层架构在 2026 年会成主流，而不是互相替代。

真正的瓶颈不在 NPU 的 TOPS 数字上，而在手机的内存带宽和持续功耗预算。标称 45 TOPS，实际能长期调用的比例远低于此。三星在 Hot Chips 上展示的 LPDDR5X-PIM 给了一个方向：把乘加运算搬进内存颗粒，绕开总线瓶颈。官方口径是 Llama-3.1-8B 的生成速度从 27 tok/s 提到 81 tok/s。这类方案要是能在 2027 年落到量产机上，手机端侧的模型尺寸上限就得重写。

不过在 LPDDR6 和更高效的稀疏推理真正落地之前，把重负载外迁还是理性选择。华强北这边一体机的价格波动比笔记本小，32GB 内存加 6GB 独显这套配置拿来当近端推理宿主，性价比窗口还在。

话说回来，你们现在是把长文本丢云端，还是已经在家搭了一套？评论区聊聊你们的实际延迟体感。