9月2日的 Hacker News 首页上，有两个帖子值得国内技术人停下来看一眼：一个是 mlc-ai/web-llm(106 points),一个是 Baseten 的《The efficient frontier of LLM inference》(149 points)。这两个帖子表面不相关，其实回答了同一个问题——2026年，你到底还要不要为 AI 推理付 GPU 账单？
第一个项目直接把答案写在了脸上：把整个大模型塞进用户的浏览器里跑，服务端零 GPU、零推理账单。第二个是海外推理基础设施公司 Baseten 的方法论长文，教你当你确实要自建推理服务时，怎么把账单砍下来。这篇文章把两条路都拆开，给你可以直接抄的步骤和成本账。
WebLLM 是一个纯浏览器端的大模型推理引擎，底层靠 WebGPU 调用用户显卡做硬件加速。它出自陈天奇团队(CMU Catalyst),上海交大(SJTU)是发起单位之一，论文编号 arXiv:2412.15803。项目在 GitHub 上开源，npm 包名 @mlc-ai/web-llm。
三个关键特性，每一个都是信息差：
chat.completions.create,改成 WebLLM 几乎只换引擎初始化那几行，streaming、JSON mode、seed 复现全都支持。npm install @mlc-ai/web-llm
第1步，初始化引擎(带下载进度回调，首次要下载权重，q4f32 量化的 8B 模型约几个 GB):
import { CreateMLCEngine } from "@mlc-ai/web-llm";
const engine = await CreateMLCEngine(
"Llama-3.1-8B-Instruct-q4f32_1-MLC",
{ initProgressCallback: (p) => console.log(p.progress) }
);
第2步，直接用 OpenAI 风格的调用:
const chunks = await engine.chat.completions.create({
messages: [{ role: "user", content: "你好" }],
stream: true,
});
for await (const chunk of chunks) {
console.log(chunk.choices[0]?.delta.content);
}
第3步(生产环境必做)，把推理丢进 Web Worker。官方提供了 WebWorkerMLCEngineHandler,把计算挪出主线程，UI 不会卡死。如果你想做 PWA 离线应用，还可以用 Service Worker 模式(ServiceWorkerMLCEngineHandler),模型常驻后台，用户每次打开页面不用重新加载模型——这是很多人不知道的杀手级特性。
第4步(可选但推荐)，加完整性校验。ModelRecord 里可以配 SRI 哈希(sha256),对下载的 config、WASM、tokenizer 逐个验签，防止供应链投毒。用 openssl dgst -sha256 -binary <file> | openssl base64 -A 一行命令生成哈希。
| 项目 | 传统方案(云端API/自建GPU) | WebLLM 方案 |
|---|---|---|
| 服务器推理成本 | 按token计费或GPU月租 | 0元(用用户自己的显卡) |
| 隐私合规 | 数据出域，需协议 | 数据不出浏览器，天然合规 |
| 离线可用 | 不行 | 可以(PWA + Service Worker) |
| 首次加载 | 快 | 慢(要下权重，需做缓存) |
| 模型上限 | 无限制 | 受用户设备显存限制 |
明显适合的场景：企业内网工具(数据不能出网)、面向海外用户的浏览器插件(WebLLM 官方就有 Chrome Extension 示例)、教育演示、离线客服机器人。不适合的场景：重推理任务(长上下文、大参数模型)和低端移动端用户。
国内对比视角：国内 AI 应用的主流形态仍然是“云端 API + 前端壳”，浏览器端推理的实践非常少。而 WebLLM 恰好原生支持 Qwen——你等于可以直接拿国产开源模型做端侧方案，这在出海产品里尤其值钱：海外用户对“数据不离开设备”的敏感度远高于国内，把这句话写进产品文案就是卖点。
如果你绕不开自建推理(模型太大、延迟要求高)，9月1日 Baseten 工程师 Philip Kiely 发的这篇长文值得精读，文末还挂了作者免费开放的书《Inference Engineering》。核心框架只有一句话：推理优化分两类——沿“延迟-吞吐前沿”做取舍的技术，和把整条前沿往外推的技术。 你先想清楚业务要哪头，再选招。
可以直接抄的四招：
第一招，Batch Size 定生死。 batch 小→单用户延迟好但每 token 成本高；batch 大→吞吐高成本低但用户等得久。作者特别提醒：真实的前沿是“锯齿状”的，最优配置不直观，必须用自己的流量实测扫描(sweep),别照抄别人的参数。
第二招，量化换免费午餐。 用 MXFP4、NVFP4 这类微缩浮点格式做量化，原文的原话是“服务质量几乎无损的情况下，推理效率可以有大幅提升”——这是少有的能把整条前沿往外推的技术。KV cache 也可以量化。
第三招，投机解码(Speculative Decoding)。 用小模型先猜、大模型验。现在的 EAGLE-3、DSpark、DFlash 技术在代码生成场景特别好使——因为代码 token 序列可预测，接受率高。做 AI 编程类产品的国内团队，这是最该优先试的一招。
第四招，Prefill/Decode 分离(P/D Disaggregation)。 把“读输入”和“生成输出”拆到不同的 worker 池，两边的机器各自调优，worker 比例还能按流量动态配。原文明确说：它最大的价值是吞吐提升明显而延迟不升甚至略降，适合高并发部署。
flowchart TD
A[自建推理成本过高] --> B{数据能否留在用户设备?}
B -- 能 --> C[方案A: WebLLM 浏览器推理<br/>服务器成本归零]
B -- 不能 --> D[方案B: 服务端调优]
D --> E{瓶颈在哪?}
E -- 单用户太慢 --> F[加 Tensor Parallelism<br/>+ 投机解码 EAGLE-3]
E -- 账单太高 --> G[加大 batch<br/>+ MXFP4/NVFP4 量化]
E -- 高并发扛不住 --> H[P/D 分离<br/>+ KV cache 复用]
C --> I[Worker/Service Worker<br/>+ SRI 校验上线]
F --> J[用自己流量做 sweep 实测]
G --> J
H --> J
J --> K{达标?}
K -- 否 --> E
K -- 是 --> L[上线,持续监控前沿位置]
| 你以为的 | 实际情况 |
|---|---|
| 跑 AI 必须有 GPU 服务器或 API 账单 | 7B 级模型可在浏览器里跑，WebGPU 加速，服务端成本为 0 |
| 浏览器跑模型 = 每次打开重新下载 | Cache/IndexedDB/OPFS/跨域四种缓存后端，Service Worker 可让模型常驻 |
| 端侧方案只能用国外模型 | WebLLM 原生支持 Qwen2,也可用 MLC LLM 编译任意自有模型 |
| 推理省钱靠换更便宜的供应商 | batch/量化/投机解码/PD分离四招组合，量化是唯一“白拿”的前往外推技术 |
| 优化参数抄大厂博客就行 | 前沿是锯齿状的，必须用自己的真实流量 sweep 出最优配置 |
npm install @mlc-ai/web-llm 跑通 Qwen2-7B 的 hello world,把现有 OpenAI SDK 代码里的 client 换成 MLCEngine,感受兼容度。本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。