LiteRT.js：浏览器端AI推理的性能革命与TensorFlow.js对比-三亩地-编程学习日记

这次我们来看一个可能改变浏览器端 AI 推理格局的新工具：Google 发布的 LiteRT.js。它不是另一个普通的 JavaScript 库，而是瞄准了在浏览器中直接、高效运行 AI 模型的核心痛点——性能。当大家都在讨论如何把大模型塞进手机或边缘设备时，Google 选择在离用户最近的地方（浏览器）发起一场性能革命。那么，它真的能撼动 TensorFlow.js 多年的积累吗？对于前端开发者和 AI 应用集成者来说，这又意味着什么？

简单说，LiteRT.js 是一个专注于在浏览器和 Node.js 环境中进行高性能机器学习推理的 JavaScript 库。它的核心目标非常直接：在给定的硬件上，以更快的速度、更低的内存占用运行模型。这听起来像是 TensorFlow.js 一直在做的事，但 LiteRT.js 从架构层面就选择了不同的路径。它不追求成为一个全功能的训练框架，而是将全部精力押注在推理优化上，尤其是在 WebGPU 这个下一代图形 API 上。

对于开发者而言，最关心的几个问题无非是：我的现有 TensorFlow.js 模型能不能用？需要多少学习成本？在低端设备上表现如何？是否支持关键的算子？以及，最重要的，性能提升到底有多明显？本文将围绕这些核心问题，带你快速了解 LiteRT.js 的能力边界、上手步骤，并通过一个实际的性能对比测试，看看它是否值得你现在就投入时间。

1. 核心能力速览

在深入细节之前，我们先通过一个表格快速把握 LiteRT.js 的核心特性，并与 TensorFlow.js 进行初步对比。

能力项	LiteRT.js	TensorFlow.js (对比参考)
项目定位	专注于浏览器/Node.js端高性能推理的轻量级库。	完整的机器学习平台，支持训练与推理。
性能焦点	极致推理性能，特别是利用 WebGPU/WebAssembly 后端。	平衡训练与推理，支持多后端（WebGL, WASM, CPU）。
模型格式	支持ONNX格式作为一等公民。可能通过转换支持其他格式。	原生支持TensorFlow SavedModel、Keras、TensorFlow.js 模型格式。
硬件加速	深度优化WebGPU支持，旨在释放现代 GPU 全部潜力。也支持 WebAssembly。	主要依赖WebGL后端进行 GPU 加速，也支持 WebAssembly 和纯 CPU。
包体积	设计目标为极简，核心运行时库体积显著小于全功能框架。	功能全面，但核心库体积相对较大，可能影响页面加载速度。
上手门槛	需要熟悉 ONNX 模型生态，API 可能更接近底层性能接口。	API 高层且完善，文档丰富，社区庞大，上手更容易。
适用场景	对推理延迟和吞吐量有极致要求的 Web AI 应用，如实时视频处理、交互式AI。	需要在浏览器中进行模型微调/训练，或依赖完整 TF 生态的原型开发与部署。

从上表可以看出，LiteRT.js 和 TensorFlow.js 并非简单的“取代”关系，而是“聚焦”与“全能”的路线差异。如果你的场景是纯粹的、对性能敏感的生产环境推理，LiteRT.js 值得重点关注。

2. 适用场景与使用边界

理解一个工具适合做什么，不适合做什么，比盲目追新更重要。

LiteRT.js 的典型适用场景包括：

高性能实时交互应用：例如，在视频会议中实时运行背景虚化、美颜或手势识别模型；在网页游戏中集成实时风格迁移或超分辨率模型。这些场景下，每一毫秒的延迟都影响用户体验。
边缘AI赋能的前端应用：希望将AI能力深度集成到单页应用（SPA）或渐进式Web应用（PWA）中，完全在客户端完成推理，避免网络往返延迟和数据隐私问题。
模型即服务（MaaS）的客户端补充：作为服务器端推理的补充或降级方案，在网络不佳或服务器负载高时，由客户端接管部分轻量级推理任务。
对包体积敏感的场景：需要将AI功能嵌入到已有的大型Web应用中，必须严格控制新增JavaScript库的体积，以避免影响整体加载性能。

需要谨慎考虑或可能不适用的情况：

模型训练与微调：LiteRT.js 的核心是推理。如果你需要在浏览器中基于用户数据进行模型训练或微调（联邦学习的一种形式），TensorFlow.js 目前是更成熟的选择。
复杂的TensorFlow生态依赖：如果你的模型严重依赖 TensorFlow 独有的算子、自定义层或特定的 SavedModel 结构，直接迁移到 LiteRT.js 可能需要额外的转换和适配工作，成本较高。
需要广泛浏览器兼容性：LiteRT.js 的性能优势很大程度上依赖于 WebGPU。虽然 WebGPU 已成为 Chrome、Edge、Safari 等现代浏览器的标准，但在一些旧版本浏览器或特定环境下可能不可用。此时需要准备好回退方案（如 WASM 后端）。
项目处于早期原型阶段：如果正处于快速验证想法和迭代模型的阶段，TensorFlow.js 丰富的工具链、示例和社区支持能让你更快地搭建出可运行的原型。

合规与安全边界：与所有客户端AI技术一样，使用 LiteRT.js 时需注意：

模型版权：确保部署到客户端的模型拥有合法的分发与使用授权。
用户隐私：在客户端处理用户数据（如图片、音频）时，需在隐私政策中明确说明，并确保数据不会未经同意上传。
计算资源：长时间或高强度的模型推理会消耗用户设备的电量和计算资源，应有适当的提示或设置选项。

3. 环境准备与前置条件

在开始动手之前，请确保你的开发环境满足以下要求。由于 LiteRT.js 较新，以下信息基于其设计目标和常见实践，具体请以官方文档为准。

现代浏览器：
- 首选 Chrome/Edge 113+ 或 Safari 16.4+：以获取完整的 WebGPU 支持。你可以在浏览器中访问chrome://gpu或edge://gpu来查看 WebGPU 状态。
- 确保浏览器设置中已启用 WebGPU（通常默认开启）。
Node.js 环境（如需在 Node.js 中运行）：
- 建议使用最新的 LTS 版本（如 Node.js 18+）。
- 需要确保系统已安装合适的 GPU 驱动，并且 Node.js 能够访问本地 GPU 资源（通常通过类似@webgpu/wgpu-native的绑定库）。
开发工具：
- 一个代码编辑器（如 VS Code）。
- 一个本地 Web 服务器用于测试（如使用npm install -g http-server或python3 -m http.server）。
模型准备：
- LiteRT.js 主要面向 ONNX 模型。你需要将你的模型（无论是 PyTorch.pt、TensorFlow.pb还是其他格式）转换为 ONNX 格式。
- 准备一些测试用的输入数据（如一张图片、一段音频波形或一个文本向量）。

4. 安装部署与启动方式

LiteRT.js 的安装预计会通过 npm 进行，方式非常标准。下面我们以假设的包名为@google/litert来演示（实际包名请以官方发布为准）。

步骤 1：创建项目并初始化

mkdir litert-demo && cd litert-demo npm init -y

步骤 2：安装 LiteRT.js

# 假设的安装命令，请替换为官方实际包名 npm install @google/litert

同时，你可能需要安装构建工具和类型定义（如果提供）：

npm install --save-dev typescript webpack webpack-cli # 如果提供类型包 npm install --save-dev @types/google__litert

步骤 3：准备一个简单的 HTML 和 JavaScript 文件index.html:

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>LiteRT.js Demo</title> </head> <body> <h1>LiteRT.js 性能测试</h1> <input type="file" id="imageUpload" accept="image/*"> <button id="runBtn">运行推理</button> <div id="result">等待上传图片并推理...</div> <div id="perf">性能指标：-</div> <script src="./dist/main.js"></script> <!-- 假设打包后的文件 --> </body> </html>

src/index.js(或src/index.ts):

// 这是一个假设性的 API 演示，实际 API 可能不同 import { InferenceSession, Tensor } from '@google/litert'; async function runDemo() { const statusDiv = document.getElementById('result'); const perfDiv = document.getElementById('perf'); try { statusDiv.textContent = '正在加载模型和初始化运行时...'; // 1. 创建推理会话 // 假设 API：new InferenceSession(modelPath, options) const session = await InferenceSession.create('./models/mobilenet.onnx', { executionProviders: ['webgpu', 'wasm'], // 优先使用 WebGPU，失败则回退到 WASM logSeverityLevel: 3 // 信息级别日志 }); statusDiv.textContent = '模型加载成功。请上传图片。'; document.getElementById('runBtn').onclick = async () => { const fileInput = document.getElementById('imageUpload'); if (!fileInput.files[0]) { alert('请先选择一张图片'); return; } const imageFile = fileInput.files[0]; // 2. 图像预处理（此处简化，实际需要调整尺寸、归一化等） const imageTensor = await preprocessImage(imageFile, session.inputDimensions); statusDiv.textContent = '正在推理...'; const startTime = performance.now(); // 3. 运行推理 // 假设 API：session.run(inputs) const outputs = await session.run({ 'input': imageTensor }); const endTime = performance.now(); const inferenceTime = endTime - startTime; // 4. 处理输出 const topResult = processOutput(outputs); statusDiv.innerHTML = `识别结果：<strong>${topResult.label}</strong> (置信度: ${topResult.confidence.toFixed(4)})`; perfDiv.textContent = `推理耗时：${inferenceTime.toFixed(2)} ms`; }; } catch (error) { console.error('初始化失败:', error); statusDiv.textContent = `初始化失败: ${error.message}`; } } // 简化的预处理和后续处理函数（需根据具体模型实现） async function preprocessImage(file, inputDims) { /* ... */ } function processOutput(outputs) { /* ... */ } // 启动应用 runDemo();

步骤 4：构建与运行如果你使用了模块打包器（如 webpack），需要配置并构建：

npx webpack --mode development

然后使用本地服务器启动：

npx http-server .

打开浏览器访问http://localhost:8080，即可看到测试页面。

5. 功能测试与效果验证

对于一个新的推理引擎，我们最需要验证的是其功能正确性和性能表现。下面设计一个简单的对比测试流程。

5.1 测试目标

使用同一个 ONNX 格式的轻量级图像分类模型（如 MobileNetV2），分别在 LiteRT.js (WebGPU后端) 和 TensorFlow.js (WebGL后端) 下运行，对比：

首次加载与初始化时间：从开始加载模型到会话准备就绪的时间。
单次推理延迟：从输入张量到获得输出张量的时间。
连续推理稳定性与内存：连续推理 100 次，观察耗时曲线是否平稳，并通过浏览器开发者工具的 Memory 面板观察内存增长。
输出一致性：确保两个引擎对同一输入给出基本相同的分类结果（允许微小浮点误差）。

5.2 测试代码结构（概念性）

你需要准备两个版本的测试页面，一个引用 LiteRT.js，一个引用 TensorFlow.js。

LiteRT.js 测试核心片段：

// 初始化 const litertSession = await InferenceSession.create(MODEL_URL, {executionProviders: ['webgpu']}); // 预热 await litertSession.run(warmupInput); // 正式测试 const start = performance.now(); for (let i = 0; i < 100; i++) { await litertSession.run(testInput); } const litertTotalTime = performance.now() - start; console.log(`LiteRT.js 总耗时：${litertTotalTime}ms`);

TensorFlow.js 测试核心片段：

// 加载模型 const tfjsModel = await tf.loadGraphModel(MODEL_URL); // 预热 tfjsModel.predict(warmupInput).dispose(); // 正式测试 const start = performance.now(); for (let i = 0; i < 100; i++) { const result = tfjsModel.predict(testInput); result.dispose(); // 重要：及时释放张量内存 } const tfjsTotalTime = performance.now() - start; console.log(`TensorFlow.js 总耗时：${tfjsTotalTime}ms`);

5.3 预期结果与判断

功能正确性：两个引擎都应成功加载模型并输出合理的分类结果。如果 LiteRT.js 输出完全错误或崩溃，可能是模型转换有问题或算子不支持。
性能对比：我们期望在支持 WebGPU 的现代设备上，LiteRT.js 的单次推理延迟和连续推理总耗时能显著低于 TensorFlow.js（例如，有 20%-50% 或更高的提升）。这是其核心价值主张。
内存占用：在连续推理测试中，观察浏览器任务管理器的“JavaScript 内存”或“GPU 内存”占用。一个优秀的设计应在多次推理后内存保持稳定或缓慢增长，而非持续泄漏。

5.4 常见失败原因

模型加载失败：检查模型路径是否正确，模型文件是否完整，以及是否是对应的 ONNX 格式。
WebGPU 初始化失败：检查浏览器版本和 flags，确保 WebGPU 已启用且未被硬件或驱动问题阻止。
推理出错：可能是输入张量的形状、数据类型与模型期望不匹配。仔细对照模型文档检查预处理步骤。
性能提升不明显：如果模型本身非常小，或者计算瓶颈不在 GPU 而在数据搬运上，性能差异可能不大。尝试使用更复杂、计算量更大的模型进行测试。

6. 接口 API 与批量任务

LiteRT.js 的 API 设计预计会围绕InferenceSession这个核心类展开，提供加载、运行和配置推理会话的能力。

6.1 核心 API 概念（假设）

// 概念性 API 示意，非官方 class InferenceSession { // 静态工厂方法，异步创建会话 static create(modelPath: string | ArrayBuffer, options?: SessionOptions): Promise<InferenceSession>; // 运行模型 run(inputs: Record<string, Tensor>): Promise<Record<string, Tensor>>; // 获取模型输入/输出信息 get inputNames(): string[]; get outputNames(): string[]; // ... 其他方法如释放资源等 } interface SessionOptions { executionProviders?: ('webgpu' | 'wasm' | 'cpu')[]; // 执行后端优先级 logSeverityLevel?: number; // 日志级别 // ... 其他优化选项，如线程数、缓存策略等 } class Tensor { constructor(data: TypedArray, dims: number[], type: DataType); // ... 数据访问方法 }

6.2 处理批量输入

虽然浏览器端通常以单次推理为主，但 LiteRT.js 很可能通过支持输入张量的批处理维度（batch dimension）来隐式支持“批量任务”。

例如，一个图像分类模型的输入形状是[batch, height, width, channels]。当batch=1时是单张图，当batch=4时是一次性处理4张图。

// 假设预处理了4张图片到一个张量中 const batchSize = 4; const batchedInputTensor = new Tensor(float32Data, [batchSize, 224, 224, 3], 'float32'); const outputs = await session.run({ 'input': batchedInputTensor }); // outputs 中的张量也会包含 batch 维度

优势：对于 WebGPU 等并行计算架构，一次处理一个批次的数据通常比循环处理单条数据更高效，能更好地利用 GPU 的并行计算能力。

6.3 构建简单的推理服务

你可以在 Node.js 环境中使用 LiteRT.js 构建一个本地的推理 API 服务，用于处理文件队列。

// server.js - 一个极简的 Express 服务示例 const express = require('express'); const multer = require('multer'); const { InferenceSession, Tensor } = require('@google/litert'); const app = express(); const upload = multer({ dest: 'uploads/' }); let session; (async () => { session = await InferenceSession.create('./model.onnx'); console.log('模型加载完毕，服务启动'); })(); app.post('/predict', upload.single('image'), async (req, res) => { if (!session) { return res.status(503).json({ error: '模型未就绪' }); } try { const imagePath = req.file.path; const inputTensor = await preprocessImageFile(imagePath); // 自定义预处理函数 const outputs = await session.run({ 'input': inputTensor }); const result = postProcess(outputs); // 自定义后处理函数 res.json({ success: true, result }); } catch (error) { console.error('推理失败:', error); res.status(500).json({ error: '推理失败', detail: error.message }); } }); app.listen(3000, () => console.log('推理服务运行在 http://localhost:3000'));

这为需要集中处理大量任务的场景（如后台批量处理用户上传的图片）提供了可能。

7. 资源占用与性能观察

在浏览器中运行 AI 模型，性能监控至关重要。以下是如何观察和评估 LiteRT.js 运行时表现的方法。

使用浏览器开发者工具：
- Performance 面板：录制一次完整的“上传-推理-显示”操作。重点关注Event: click、Scripting和Rendering时间线，找出瓶颈是在 JavaScript 执行、GPU 计算还是界面渲染。
- Memory 面板：定期进行“垃圾回收”并拍摄堆快照。观察@google/litert相关对象（如Tensor、InferenceSession）是否被正确创建和释放，防止内存泄漏。连续推理测试后，内存应趋于稳定。
- Task Manager (Chrome)：直接查看当前标签页的“JavaScript Memory”和“GPU Memory”使用情况。运行模型时，GPU 内存应有明显上升，并在推理结束后部分释放（缓存可能保留）。

自定义性能打点：在你的代码中精确测量各个阶段耗时。

const timings = {}; // 模型加载阶段 timings.loadStart = performance.now(); const session = await InferenceSession.create(MODEL_URL); timings.loadEnd = performance.now(); console.log(`模型加载耗时: ${timings.loadEnd - timings.loadStart}ms`); // 单次推理阶段 timings.inferenceStart = performance.now(); const output = await session.run(inputs); timings.inferenceEnd = performance.now(); console.log(`推理耗时: ${timings.inferenceEnd - timings.inferenceStart}ms`); // 首帧时间 (FCP, FMP) 对于用户体验至关重要

影响性能的关键因素：
- 模型复杂度：参数量、算子类型（卷积、矩阵乘等）直接影响计算量。
- 输入分辨率：对于视觉模型，输入图像尺寸越大，计算量和内存占用呈平方级增长。
- 执行后端：WebGPU > WebAssembly (SIMD) > 纯 JavaScript。务必在用户设备上测试回退方案的表现。
- 数据预处理/后处理：将图片解码、调整大小、归一化等操作放在主线程可能成为瓶颈。考虑使用 Web Workers 或 OffscreenCanvas 进行异步处理。
优化建议：
- 预热：在用户交互前，用零张量或小张量先运行一次推理，触发模型加载和编译，减少首次真实推理的延迟。
- 模型量化：如果 LiteRT.js 支持，使用 INT8 量化模型可以大幅减少内存占用并提升速度，精度损失通常可控。
- 缓存推理会话：避免重复创建InferenceSession，应在应用生命周期内复用。
- 及时释放张量：对于中间张量，如果不再使用，主动调用类似dispose()的方法（如果 API 提供）来释放 GPU/CPU 内存。

8. 常见问题与排查方法

在探索和使用 LiteRT.js 的过程中，你可能会遇到以下典型问题。

问题现象	可能原因	排查方式	解决方案
模型加载失败，报错“无法解析模型”	1. 模型文件路径错误或损坏。 2. 模型格式不是 ONNX 或版本不兼容。 3. 模型包含 LiteRT.js 尚未支持的算子。	1. 检查网络请求，确认模型文件成功下载。 2. 使用 Netron 等工具打开模型，确认其为有效 ONNX 文件。 3. 查看浏览器控制台或 LiteRT.js 日志，是否有具体的算子不支持错误。	1. 修正文件路径或重新下载模型。 2. 使用官方支持的 ONNX opset 版本重新导出模型。 3. 简化模型或等待未来版本支持。
初始化失败，提示“WebGPU not available”	1. 浏览器版本过旧。 2. WebGPU 被标志或设置禁用。 3. 操作系统或显卡驱动不支持。	1. 访问`chrome://gpu`，查看“Graphics Feature Status”中“WebGPU”的状态。 2. 检查`chrome://flags`中 “WebGPU Developer Features” 等是否启用。 3. 更新显卡驱动。	1. 将 Chrome/Edge 升级到最新稳定版。 2. 在代码中设置执行后端优先级，如`['wasm', 'cpu']`作为回退。
推理结果不正确或 NaN	1. 输入数据预处理错误（尺寸、归一化范围、颜色通道顺序）。 2. 模型输出后处理逻辑错误。 3. 模型本身有问题。	1. 逐步骤检查预处理代码，与模型训练时的预处理对齐。 2. 使用一个已知正确输出的简单输入（如全1张量）测试，看输出是否合理。 3. 用 ONNX Runtime (Python) 运行相同模型和输入，对比结果。	1. 严格对照模型文档或原始训练代码修正预处理。 2. 检查后处理代码，特别是 argmax、softmax 等操作。 3. 验证模型在标准环境下的正确性。
推理性能远低于预期	1. 使用了性能较差的执行后端（如回退到 CPU）。 2. 输入数据在 CPU 和 GPU 间频繁拷贝。 3. 模型不适合在 WebGPU 上运行（包含大量小众或顺序算子）。	1. 打印或检查`session`的配置，确认实际使用的后端。 2. 使用 Performance 面板分析，看是否有不必要的`ArrayBuffer`复制。 3. 尝试更小或更经典的模型（如 MobileNet）进行基准测试。	1. 确保 WebGPU 可用，并优先配置。 2. 尽量在 GPU 内存中完成数据准备（如使用 WebGPU 计算着色器预处理）。 3. 考虑对模型进行图优化或选择更适合的模型架构。
内存使用量持续增长（内存泄漏）	1. 推理中创建的中间张量未释放。 2.`InferenceSession`或`Tensor`对象被意外持有引用，无法垃圾回收。	1. 使用 Memory 面板拍摄堆快照，过滤`Tensor`或相关对象，查看数量是否只增不减。 2. 检查代码，确保没有在全局数组或闭包中累积推理结果。	1. 如果 API 提供`dispose()`方法，在张量使用完毕后立即调用。 2. 避免在循环或高频触发函数中无节制地创建新会话或大张量。 3. 定期检查并管理缓存。
在 Node.js 中运行报错	1. Node.js 版本不兼容。 2. 缺少本地绑定库（如`@webgpu/wgpu-native`）。 3. 系统权限或环境变量问题。	1. 检查 Node.js 版本和 LiteRT.js 的版本要求。 2. 查看安装时的警告或错误信息，确认原生模块是否编译成功。 3. 在 Linux/Mac 上，可能需要安装额外的开发工具链（如`build-essential`,`cmake`）。	1. 升级 Node.js 到指定版本。 2. 根据错误信息，安装缺失的系统依赖或原生绑定库。 3. 在干净的系统中按照官方指南重新安装。

9. 最佳实践与使用建议

基于对 LiteRT.js 设计目标的分析和潜在挑战的预判，以下是一些上手和深度使用的建议。

从“对标测试”开始：不要直接将生产项目迁移。而是为你现有的 TensorFlow.js 应用创建一个使用 LiteRT.js 的并行分支或独立测试页面，进行严格的正确性和性能对比。用数据决定是否迁移。
建立模型转换流水线：如果决定采用 LiteRT.js，需要建立从训练框架（PyTorch/TensorFlow）到 ONNX 的稳定转换流程。使用onnx-simplifier等工具对转换后的模型进行优化和验证。
实现优雅的后备方案：在初始化 LiteRT.js 时，主动检测 WebGPU 的可用性。如果不可用，应无缝降级到 TensorFlow.js (WASM/WebGL) 或提供一个友好的功能降级界面（如提示用户升级浏览器）。
```
async function getAIBackend() { if (await isWebGPUSupported()) { try { return await initLiteRT(); } catch (e) { console.warn('LiteRT 初始化失败，回退到 TF.js', e); } } return await initTFJS(); // 回退到 TensorFlow.js }
```
关注内存生命周期：Web 环境对内存敏感。明确每个Tensor的生命周期，在不再需要时及时清理。避免在单次页面交互中反复加载和释放大型模型。
性能监控与上报：在生产环境中，收集用户设备上的模型加载时间、推理延迟等关键指标。这能帮助你了解真实世界的性能表现，并发现特定设备或浏览器版本的兼容性问题。
社区与官方动态：LiteRT.js 处于早期阶段，API 和功能可能快速迭代。密切关注其官方 GitHub 仓库、问题讨论和版本发布说明，及时调整你的代码。
安全与合规考量：部署到客户端的模型即代码。确保模型本身不包含敏感信息，并考虑对模型文件进行适当的混淆或加密（虽然无法绝对防止提取）。在用户协议中明确说明 AI 功能在本地运行的数据处理方式。

10. 总结与下一步

LiteRT.js 的出现，标志着浏览器端 AI 推理从“能用”向“好用”、“高效”迈进的关键一步。它并非要彻底淘汰 TensorFlow.js，而是在 TensorFlow.js 开拓的道路上，为那些对性能有极致要求的场景，提供了一把更锋利的“手术刀”。

对于前端开发者和 AI 应用架构师来说，现在最值得做的事情是：

保持关注并尝试：在非核心业务或实验性项目中尝试集成 LiteRT.js，熟悉其 API 设计、工作流程和性能特性。
夯实模型转换能力：无论最终选择哪个前端推理引擎，掌握 ONNX 模型转换和优化技能都将变得越来越重要，这是模型跨平台部署的桥梁。
设计可插拔的 AI 后端架构：将你应用中的模型加载、推理执行部分抽象成统一的接口。这样，你可以轻松地在 LiteRT.js、TensorFlow.js 甚至未来的其他引擎之间切换，选择最适合当前环境和需求的实现。

短期内，TensorFlow.js 凭借其成熟度、丰富的模型库和社区，依然是大多数 Web AI 项目的稳妥选择。但如果你正在构建一个对实时性要求极高的交互式 AI 应用，或者受困于模型体积和加载速度，那么 LiteRT.js 所代表的性能优先路线，无疑是你必须认真评估的技术选项。这场浏览器里的性能革命，才刚刚开始。

日记详情

LiteRT.js：浏览器端AI推理的性能革命与TensorFlow.js对比