浏览器端模型评估：Trunchbull与Web推理实战

过去在做模型效果评估时，我们通常需要先在本地准备好 Python 环境，拉取评估框架，下载一个动辄几十 GB 的模型权重，再对着 GPU 排队等结果。整个流程非常重，遇到团队里没有 GPU 机器、或者只想快速验证一个模型能不能干活时，往往就卡在环境搭建这一步。Trunchbull 这类项目的思路是：把真实模型直接跑在浏览器里，用浏览器环境去完成 benchmark 测试。换句话说，用户不再需要 GPU，不再需要 Python，只需要一个现代浏览器，就能加载真实模型、跑标准数据集，并得到指标结果。这篇文章会从概念、技术原理、实战示例到排错思路完整展开，帮助想了解浏览器端模型评估的开发者快速上手。

本文适合以下读者：对模型评估流程有基本概念的算法工程师，想尝试 Web AI 方向的前端工程师，以及想在低资源环境下快速做模型对比的技术决策者。读完你会理解浏览器端推理与传统推理的差异，知道如何在浏览器中加载模型并跑通一个最小 benchmark 流程，也会掌握一套排查浏览器推理问题的通用思路。

下面开始正文。

1. 背景与核心概念

1.1 传统模型评估流程的痛点

在正式讨论 Trunchbull 之前，我们先回忆一下传统的模型 benchmark 流程是怎样的。以自然语言处理领域的常见做法为例，当我们想评估一个模型在 MMLU、GSM8K、HumanEval 等数据集上的表现时，一般需要经过以下步骤：

1. 准备一台带有 NVIDIA GPU 的机器，安装 CUDA、cuDNN、PyTorch 等依赖。
2. 创建一个独立的 Python 虚拟环境，避免依赖冲突。
3. 拉取评估框架，例如 lm-evaluation-harness、OpenCompass 或 vLLM 相关工具。
4. 下载模型权重，通常是好几 GB 到几十 GB 的 checkpoint 文件。
5. 下载评估数据集，并做格式转换。
6. 运行评估脚本，等待几小时甚至几天。
7. 汇总结果，生成表格或报告。

这套流程本身很成熟，但它有几个明显的限制：

• 对硬件要求高，尤其是大模型推理阶段，显存不足会直接导致评估中断。
• 环境依赖复杂，Python 版本、CUDA 版本、框架版本稍有偏差就可能报错。
• 团队协作成本高，成员想复现结果时往往要重跑完整环境。
• 不适合轻量级验证，只想看某个小模型在某个数据集上的效果时，也需要搭一套完整工具链。

这些痛点催生了一个新的需求：能不能把模型评估变得更轻、更快、更简单？

1.2 Trunchbull 是什么

Trunchbull 是一个基于浏览器运行真实模型并执行 benchmark 的开源项目思路，它的核心特点是“浏览器端推理”。我们可以把它理解为一个 Web 端的模型评估工作台：

• 用户在浏览器页面中选择一个模型。
• 浏览器下载并加载模型权重到本地。
• 模型完全在浏览器内部执行推理。
• 评测数据集也以浏览器可读取的方式提供。
• 最后在页面上展示准确率、困惑度等指标。

这里的“真实模型”指的是不是 API 模拟返回，而是模型权重真的在浏览器中完成前向计算。这意味着推理过程真正发生在本机浏览器进程中，而不是发送到远程服务器。

网页上的模型 demo 大家应该见过不少，例如各种聊天机器人演示页面。但 Trunchbull 的定位和普通 demo 不同：

• 普通 demo 通常只展示“单个问题 -> 单个回答”的交互过程。
• benchmark 工具则要完成“批量数据输入 -> 批量推理 -> 指标计算 -> 结果可视化”的完整闭环。

所以它在工程实现上需要额外处理数据集加载、批处理调度、指标统计等问题。

1.3 为什么选择浏览器作为运行环境

浏览器作为模型推理环境，相比传统后端有以下几个突出优势：

第一，零安装、零环境配置。用户打开网址即可使用，不需要安装 Python、CUDA 或任何驱动。这大大降低了使用门槛。

第二，隐私性好。模型权重和数据都在本地浏览器中运行，不需要上传到服务器。对于敏感数据或私有模型场景，这种“本地推理”模式很有吸引力。

第三，跨平台。只要浏览器支持相关技术标准，Windows、macOS、Linux、甚至部分移动设备都能运行，无需针对操作系统单独适配。

第四，分布式潜力。每个打开页面的浏览器都可以变成一个推理节点，理论上可以借助 WebRTC 等协议组成浏览器集群，适合做一些轻量级分布式评估实验。

当然，浏览器环境也有明显限制，例如内存上限、GPU 资源受浏览器调度、无法利用完整显存等。这些问题会在后面的章节详细讨论。

2. 环境准备与版本说明

2.1 浏览器要求

在浏览器中运行模型，主要依赖 WebAssembly 和 WebGPU 这两项技术。不同的推理库对浏览器的支持程度不同，因此建议先确认目标用户的浏览器版本。

以 WebGPU 为例，Chrome 和 Edge 从较新版本开始默认支持 WebGPU，Firefox 和 Safari 的支持进度相对保守。如果你的项目依赖 WebGPU 加速大模型推理，那么建议以 Chrome/Edge 作为主测试浏览器。

在开发阶段，你还需要开启浏览器开发者工具，用来查看 Console 报错、Network 请求和 GPU 相关信息。许多浏览器推理问题，例如模型文件跨域加载失败、WebGPU 设备创建失败，都会在 Console 中留下明确提示。

需要特别说明的是：如果你的用户浏览器版本较旧，页面可以降级到 CPU 推理，但速度会慢很多。所以建议在页面上做一个兼容性检测，提示用户使用最新版 Chrome 或 Edge 获得最佳体验。

2.2 浏览器端推理框架选择

目前常用的浏览器端模型推理方案有：

• Transformers.js：Hugging Face 推出的浏览器端推理库，API 设计接近 Python 版 Transformers，适合快速加载各类 Transformer 模型。
• WebLLM：专注于大语言模型的浏览器端推理引擎，支持流式输出和 WebGPU 加速。
• ONNX Runtime Web：微软开源的 ONNX 模型浏览器端运行时，可以加载 ONNX 格式模型，支持 WebAssembly 和 WebGPU 两个后端。
• GGML / llama.cpp 的 Web 版本：通过 WebAssembly 运行 GGUF 格式模型，社区有一些封装库，例如 llama.cpp 的 web 示例。

选择哪个库，取决于你的模型格式和目标场景。Trunchbull 这类工具通常不会只绑定一个推理框架，而是把不同框架封装成统一接口，让用户按“模型格式”自动选择推理后端。

由于具体框架版本更新较快，本文不写死版本号。你在实际项目中应以官方仓库 README 为准，建议锁定框架版本后再进行功能开发。

2.3 开发环境准备

如果你想在本地搭建一个类似 Trunchbull 的最小 demo，建议准备以下环境：

• Node.js（用于启动本地静态服务器）。
• 一个现代浏览器（推荐 Chrome）。
• 一个静态文件服务器，例如npx serve或 Vite。
• 一个文本编辑器或 IDE。

为什么需要本地服务器？因为浏览器在加载模型权重这类外部资源时，通常会受同源策略限制。直接双击打开 HTML 文件，可能会遇到 CORS 跨域问题。使用本地静态服务器可以避免这一坑。

项目结构可以参考：

trunchbull-demo/ ├── index.html ├── main.js ├── package.json └── models/ └── README.md

这里的main.js是我们的入口脚本，models目录用于存放模型说明或本地模型映射。

3. 核心原理拆解

3.1 浏览器端推理的底层技术

浏览器之所以能运行真实模型，离不开两项基础技术：WebAssembly 和 WebGPU。

WebAssembly 是一种以接近原生性能运行的字节码格式。C++、Rust 等语言编写的推理内核可以通过 Emscripten 或 wasm-bindgen 等工具编译成 WebAssembly，从而在浏览器中执行。CPU 推理场景下，WebAssembly 是主力技术。

WebGPU 则是浏览器提供的下一代图形和计算 API，允许开发者直接调用 GPU 进行通用计算。模型推理中的矩阵乘法、注意力计算等大规模并行任务，都可以在 WebGPU 上加速。对于大语言模型，WebGPU 的加速效果远比 CPU 推理明显。

两者的关系可以简单理解为：WebAssembly 负责 CPU 上的高性能计算，WebGPU 负责 GPU 上的并行计算。一个成熟的浏览器推理框架通常会先用 WebAssembly 做兜底兼容，再在支持 WebGPU 的环境中自动切换加速模式。

3.2 从 Python 评估到浏览器评估

在 Python 环境中，评估一个模型通常是这样做的：

1. 用AutoModel.from_pretrained加载语言模型。
2. 用AutoTokenizer.from_pretrained加载分词器。
3. 把测试集数据逐条进行编码。
4. 将编码后的张量输入模型，得到 logits。
5. 用 logits 和标签计算损失、准确率等指标。

到了浏览器端，流程并没有本质变化，只是把“张量计算”从 Python 运行时换成了浏览器推理引擎。以 Transformers.js 为例，加载模型的写法非常接近 Python Transformers：

// 注意：以下代码为浏览器端 Transformers.js 示例，具体 API 以安装版本为准 import { pipeline } from '@huggingface/transformers'; const classifier = await pipeline( 'sentiment-analysis', 'Xenova/distilbert-base-uncased-finetuned-sst-2-english' ); const result = await classifier('I love this project!'); console.log(result);

这段代码如果放在传统后端，你需要先准备 Python 环境和 PyTorch；但在浏览器中，用户只需要打开页面即可。

3.3 Benchmark 的核心指标概念

在理解浏览器端 benchmark 工具之前，先回顾几个常见指标。

准确率（Accuracy）是最直观的分类指标，代表预测正确的样本数占总样本数的比例。在情感分类、主题分类等任务中经常使用。

困惑度（Perplexity）是语言模型常用的指标，反映模型对文本序列的建模能力。困惑度越低，说明模型对训练数据的拟合程度越好。不过，困惑度并不等于下游任务效果，两者要分开看待。

Pass@k 是代码生成和数学推理任务中常用的指标，表示在生成的 k 个结果中，至少有一个结果正确的概率。这个指标对采样策略非常敏感，评估时需要固定随机种子。

在浏览器端 benchmark 工具中，指标计算逻辑和 Python 端是相同的，区别只在于数据来源和运行位置。

3.4 浏览器端数据集处理的挑战

传统评估框架可以直接读取 Hugging Face Hub 上的数据集，也可以通过 dataloader 按 batch 加载。但浏览器环境有几个限制：

第一，内存受限。如果一次性加载完整测试集，大型数据集可能直接挤爆浏览器内存。解决方案是分片加载，或者对测试集做随机采样，只评测一个子集。

第二，网络加载。浏览器获取数据集需要走 HTTP 请求，如果数据集很大，体验会很差。因此浏览器端 benchmark 工具通常提供“精简版数据集”，例如每个类别只保留几十条样本。

第三，数据格式。浏览器不能直接读取本地的 parquet 文件，需要把数据转换成 JSON、JSONL 等浏览器友好的格式，或者使用浏览器端的解析库来处理。

Trunchbull 这类工具在设计时，通常会把“数据集适配层”抽象出来，让用户既能选择内置的轻量数据集，也能通过 URL 加载自定义 JSONL 测试集。

4. 完整实战案例

下面我们来动手实现一个极简版“Trunchbull 思想”的浏览器端 benchmark 工具。这个示例不会真正实现 MMLU 那么大的数据集，而是聚焦在“浏览器加载真实模型 + 跑少量数据 + 计算指标”这条主链路上。

4.1 创建项目结构

在本地新建一个目录，命名为browser-benchmark-demo，并创建以下文件：

browser-benchmark-demo/ ├── index.html ├── main.js └── package.json

我们选择 Transformers.js 作为推理框架，因为它的 API 对熟悉 Python Transformers 的开发者非常友好。

4.2 初始化项目并安装依赖

在项目目录下执行：

npm init -y npm install @huggingface/transformers

安装完成后，package.json中会自动出现依赖。这一步会从 npm 拉取浏览器端推理库，后续 HTML 页面通过 ES Module 方式引入。

4.3 编写 HTML 页面

index.html负责提供页面骨架，包括模型选择、启动评估按钮、结果展示区域和日志区域。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>浏览器端模型评估示例</title> <style> body { font-family: system-ui, -apple-system, sans-serif; max-width: 900px; margin: 40px auto; padding: 0 16px; line-height: 1.7; } button { padding: 8px 16px; cursor: pointer; } #result, #log { margin-top: 16px; padding: 12px; background: #f6f8fa; border-radius: 8px; white-space: pre-wrap; word-break: break-all; } </style> </head> <body> <h1>浏览器端模型评估示例</h1> <div> <label>模型 ID：</label> <input id="modelId" type="text" value="Xenova/distilbert-base-uncased-finetuned-sst-2-english" style="width: 420px;" /> </div> <div style="margin-top: 12px;"> <button id="runBtn">开始评估</button> <span id="status"></span> </div> <h2>评估结果</h2> <div id="result">等待执行...</div> <h2>运行日志</h2> <div id="log"></div> <script type="module" src="./main.js"></script> </body> </html>

4.4 编写核心代码

main.js是核心逻辑所在。我们定义一个非常小的测试集，只包含 6 句英文情感文本，3 句正面、3 句负面，用于演示准确率计算流程。

// 文件路径：main.js import { pipeline } from '@huggingface/transformers'; // 测试集：真实场景中可以从 JSON 或 JSONL 读取 // label 的 1 表示正面，0 表示负面 const testSet = [ { text: 'I love this project!', label: 1 }, { text: 'This is absolutely amazing.', label: 1 }, { text: 'I feel so happy today.', label: 1 }, { text: 'This is a terrible experience.', label: 0 }, { text: 'I am very disappointed.', label: 0 }, { text: 'The worst product I have ever used.', label: 0 }, ]; const logEl = document.getElementById('log'); const resultEl = document.getElementById('result'); const statusEl = document.getElementById('status'); function appendLog(message) { logEl.textContent += message + '\n'; console.log(message); } // 情感分类的标签映射 const labelMap = { 'POSITIVE': 1, 'NEGATIVE': 0, }; async function runBenchmark() { const modelId = document.getElementById('modelId').value.trim(); if (!modelId) { alert('请填写模型 ID'); return; } const runBtn = document.getElementById('runBtn'); runBtn.disabled = true; statusEl.textContent = '正在加载模型...'; try { appendLog(`[1/4] 开始加载模型：${modelId}`); const classifier = await pipeline('sentiment-analysis', modelId); appendLog('[2/4] 模型加载完成'); statusEl.textContent = '正在执行推理...'; appendLog(`[3/4] 开始评估，测试集样本数：${testSet.length}`); let correct = 0; const details = []; // 逐条推理 for (let i = 0; i < testSet.length; i++) { const { text, label } = testSet[i]; // 单条推理 const output = await classifier(text); const predictedLabel = labelMap[output[0].label] ?? -1; const isCorrect = predictedLabel === label; if (isCorrect) correct++; details.push({ index: i, text, expected: label, predicted: predictedLabel, score: output[0].score, correct: isCorrect, }); appendLog( ` 样本 ${i}: 预测标签=${predictedLabel}, 真实标签=${label}, ` + `confidence=${output[0].score.toFixed(4)}, ${isCorrect ? '正确' : '错误'}` ); } const accuracy = correct / testSet.length; appendLog(`[4/4] 评估完成`); appendLog(`正确数：${correct} / ${testSet.length}`); appendLog(`准确率：${(accuracy * 100).toFixed(2)}%`); resultEl.textContent = JSON.stringify( { model: modelId, total: testSet.length, correct: correct, accuracy: accuracy, details: details, }, null, 2 ); statusEl.textContent = '评估完成'; } catch (err) { console.error(err); statusEl.textContent = '评估失败'; appendLog(`错误信息：${err.message}`); appendLog(`错误堆栈：${err.stack || '无堆栈信息'}`); } finally { runBtn.disabled = false; } } document.getElementById('runBtn').addEventListener('click', runBenchmark);

4.5 运行与验证

在项目目录下启动静态服务器：

npx serve .

然后在浏览器中打开http://localhost:3000，点击“开始评估”按钮。你会看到：

1. 浏览器开始下载模型权重到本地缓存。
2. 模型加载完成后，逐条执行推理。
3. 日志区域逐行输出每个样本的预测结果。
4. 最终展示准确率。

注意：第一次加载模型时，需要从 Hugging Face Hub 下载权重，速度取决于你的网络环境。模型下载完成后会被浏览器缓存，后续加载会明显变快。

如果运行顺利，你会在日志中看到类似结果：

[1/4] 开始加载模型：Xenova/distilbert-base-uncased-finetuned-sst-2-english [2/4] 模型加载完成 [3/4] 开始评估，测试集样本数：6 样本 0: 预测标签=1, 真实标签=1, confidence=0.9998, 正确 样本 1: 预测标签=1, 真实标签=1, confidence=0.9997, 正确 样本 2: 预测标签=1, 真实标签=1, confidence=0.9996, 正确 样本 3: 预测标签=0, 真实标签=0, confidence=0.9995, 正确 样本 4: 预测标签=0, 真实标签=0, confidence=0.9995, 正确 样本 5: 预测标签=0, 真实标签=0, confidence=0.9993, 正确 [4/4] 评估完成 正确数：6 / 6 准确率：100.00%

这个例子虽然简单，但已经完整覆盖了“加载真实模型 -> 运行推理 -> 计算指标 -> 展示结果”的 benchmark 主链路。

5. 常见问题与排查思路

浏览器端模型评估最让人头疼的问题通常集中在环境兼容性、资源限制和结果一致性三个方面。下面这张表格可以作为排查参考。

接下来逐个展开说明。

5.1 CORS 跨域问题

直接双击 HTML 文件运行，或者模型文件存放在另一个域名时，经常出现 CORS 错误。浏览器出于安全策略，会阻止网页读取跨域资源。解决办法是使用本地静态服务器，或者在后端配置 CORS 响应头。

如果你使用的是 Hugging Face Hub 上的模型，通常情况下对方已经配置了允许跨域访问的响应头。但自建模型服务器时，一定要检查 CORS 配置。

5.2 WebGPU 兼容性

WebGPU 是目前浏览器端大模型推理的首选加速方案，但它的兼容性并不完美。如果你的目标用户大量使用旧版浏览器，建议在页面加载时做能力检测：

// 简单检测当前浏览器是否支持 WebGPU const isWebGPUSupported = 'gpu' in navigator; if (!isWebGPUSupported) { console.warn('当前浏览器不支持 WebGPU，将回退到 CPU 推理或功能受限模式'); }

这个检测逻辑可以作为功能开关的基础。在不支持 WebGPU 的环境中，我们可以提示用户升级浏览器，或者自动切换到 WebAssembly 后端。

5.3 内存溢出与标签页崩溃

浏览器页面能使用的内存并不是无限的。一个 7B 参数的模型，即使用 4-bit 量化，也需要数 GB 内存，这很可能压垮普通浏览器标签页。Trunchbull 这类工具在实际使用中，更适合跑中小型模型，例如 0.5B 到 3B 参数范围的模型。

如果页面频繁崩溃，可以尝试以下方案：

• 选择参数量更小的模型。
• 使用量化版本模型，例如 4-bit、8-bit 量化。
• 减少测试集样本数，分批推理。
• 关闭其他占用内存的标签页。

5.4 结果不一致问题

同一个模型、同一份测试集，浏览器端跑出来的结果和 Python 端跑出来的结果可能会有细微差异。原因通常有几种：

• 模型导出的量化精度不同。
• 采样参数不同，例如 temperature、top_p 不同。
• 推理引擎使用的算子实现精度不同。
• 随机种子没有固定。

为了解决这个问题，需要在评估脚本中显式设置随机种子，并保留完整的评估配置记录。例如在结果 JSON 中同时记录模型 ID、量化类型、temperature、测试集版本等信息。

6. 最佳实践与工程建议

6.1 模型选型：匹配浏览器资源

浏览器端模型评估不是越大越好。在设计 Trunchbull 这类工具时，建议按用户设备能力提供模型推荐列表：

• 低端设备：优先推荐 100M 到 300M 参数模型。
• 中端设备：可以尝试 0.5B 到 2B 参数模型。
• 高端设备：在 WebGPU 支持下，可以尝试 3B 到 7B 参数的量化模型。

同时要区分“CPU 推理”和“GPU 推理”。GPU 推理能处理的模型规模更大，但并非所有设备都有独立显卡。建议在页面中展示实时资源占用，帮助用户理解当前评估任务的硬件开销。

6.2 统一评估配置，保证可复现

Benchmark 最重要的价值是可复现。如果两次运行结果差异过大，那么评估就失去了意义。为了保证结果一致性，建议做到以下几点：

• 固定随机种子，在代码中显式声明。
• 记录模型 ID 和模型文件哈希值。
• 记录测试集版本和采样数量。
• 记录推理引擎版本和浏览器版本。
• 将以上信息一并写入结果报告中。

在实际项目中，可以把这些信息封装成一个EvaluationConfig对象，随结果一起展示。

6.3 模型缓存与加载体验

浏览器首次加载大模型时，等待时间通常很长，很容易劝退用户。改善体验的方法有：

• 使用浏览器 IndexedDB 缓存模型文件，避免每次刷新都重新下载。
• 在页面中显示模型下载进度条。
• 支持后台预热，页面打开后立即加载默认模型。
• 提供模型离线包，允许用户下载后通过本地路径加载。

Transformers.js 等库已经内置了基于浏览器缓存的文件缓存机制，但你可以根据实际场景进一步定制。

6.4 安全边界与隐私保护

浏览器端推理在隐私保护方面有天然优势，因为数据不需要离开本地设备。但在工程实现上仍然需要注意：

• 如果测试集中包含敏感数据，务必通过本地文件选择器导入，而不是从远程 URL 拉取。
• 不要将模型评估结果自动上传到第三方服务，除非用户明确授权。
• 如果页面涉及用户自定义数据集，不要读取用户文件系统之外的数据。
• 浏览器 Console 日志不要输出敏感样本内容，防止信息泄露。

总的来说，默认原则是：一切推理都在本地发生，数据不出浏览器。

6.5 前后端混合架构的思考

纯浏览器端评估适合轻量场景，但如果要评估超大模型，或者需要多人共享测试集，完全脱离后端并不现实。一种合理的架构是：

• 浏览器端负责小模型的快速评估和交互展示。
• 后端 GPU 集群负责大模型评估和批量任务调度。
• 前端通过 API 提交评估任务，后端返回结果。

Trunchbull 这类项目更适合定位成“轻量级快速验证工具”，而线下大规模评测仍然离不开传统评估框架。两者是互补关系，而不是替代关系。

7. 总结与学习路线

7.1 本文核心要点

通过 Trunchbull 这个切入点，我们讨论了浏览器端运行真实模型做 benchmark 的完整技术链路：

• 浏览器端推理解决了传统模型评估需要 GPU、Python 环境和复杂依赖的问题。
• WebAssembly 和 WebGPU 是浏览器端推理的两大底层技术。
• 浏览器端评估并没有改变模型评估的本质，它仍然是“加载模型 -> 编码数据 -> 推理 -> 计算指标”的流程。
• 数据加载、内存限制、结果可复现性是浏览器端评估需要特别关注的三个工程问题。

在实战部分，我们使用 Transformers.js 实现了一个最小可运行的浏览器评估示例。虽然测试集只有 6 条样本，但它已经把整个链路跑通了。后续你可以把这个示例扩展成更完整的工具，例如支持自定义 JSONL 测试集、支持多个模型对比、支持日志导出等。

7.2 下一步学习建议

如果你对这个方向感兴趣，可以按下面的路径继续深入学习：

• 学习 WebGPU 基础：了解如何编写简单的计算着色器，理解 GPU 并行计算的基本模型。
• 学习模型量化：掌握 GPTQ、AWQ、GGUF 等量化格式，理解量化对推理速度和准确率的影响。
• 学习浏览器存储：深入了解 IndexedDB、Cache API，为模型文件缓存设计更好的方案。
• 了解 WASM 生态：熟悉 Rust 或 C++ 编译到 WebAssembly 的流程，这能帮助你定制推理内核。
• 研究评估框架源码：阅读 Hugging Face evaluation 工具或 lm-evaluation-harness 的实现，理解指标计算的边界情况。

7.3 实际项目中优先关注的风险

在把浏览器端评估方案用到实际项目中之前，建议先用小规模实验验证几件事：目标用户浏览器的 WebGPU 覆盖率有多高；量化模型在浏览器上的精度损失是否在可接受范围；测试集从远程加载到本地缓存的体验是否顺畅。

只要你把这些问题想清楚，浏览器端模型评估完全可以在教学演示、快速选型、内部分享等场景中发挥很大价值。如果本文对你有帮助，可以收藏备用，也欢迎在实践中多尝试不同的模型和测试集，积累属于你自己的浏览器端评估经验。