很多人第一次聽說 onnxruntime大概是在某個模型部署的項目里。但它真正讓我覺得“離不開”的時刻是在瀏覽器里跑 AI 模型那段時間。當(dāng)時為了給一個純前端的圖像處理應(yīng)用加點智能功能既不想上云又不想讓用戶裝 Python 環(huán)境折騰了一圈最后發(fā)現(xiàn)所有路幾乎都指向同一個東西——微軟開源的 onnxruntime。先說結(jié)論瀏覽器 AI 這件事目前階段ONNX Runtime Web 幾乎是最成熟、最穩(wěn)的落地方案。不管你手里是 PyTorch、TensorFlow 訓(xùn)練出來的模型還是 HuggingFace 上下載的 transformer 模型只要轉(zhuǎn)換成 ONNX 格式就能用這個運行時在瀏覽器里做推理。這篇不是泛泛介紹而是把從模型轉(zhuǎn)換到在瀏覽器里真正跑通的完整鏈路拆開揉碎包括為什么是 ONNX、WASM 和 WebGPU 兩個后端怎么選、實際接入時最容易被卡住的幾個坑以及最近社區(qū)里討論度很高的 chromadb 初始化失敗和 5060 端口這兩件事到底怎么回事。1. 為什么瀏覽器端 AI 繞不開 onnxruntime1.1 瀏覽器環(huán)境的兩道硬門檻瀏覽器里跑模型天然比服務(wù)端多兩重限制。第一重是算力限制JavaScript 單線程、弱類型跑起純計算密集型的神經(jīng)網(wǎng)絡(luò)任務(wù)性能和本地 Python CUDA 完全是兩個世界。第二重是環(huán)境隔離你不能在瀏覽器里隨便裝一個 Python 庫也不能直接訪問系統(tǒng)級的 GPU 驅(qū)動能做的一切操作都被限定在 Web 標(biāo)準(zhǔn)接口之內(nèi)。所以瀏覽器 AI 的實質(zhì)就是在“網(wǎng)頁沙箱”里重新搭一套模型推理環(huán)境。再往下拆又分成兩派谷歌主導(dǎo)的 TensorFlow.js 走的是 TF 模型直接轉(zhuǎn)格式的路線而微軟主導(dǎo)的 onnxruntime 走的是通用中間格式路線。從模型生態(tài)兼容性的角度看后者的覆蓋面明顯更廣——PyTorch 是當(dāng)前學(xué)術(shù)界、工業(yè)界用最多的框架而 PyTorch 官方推薦的導(dǎo)出格式就是 ONNX。這意味著你從 HuggingFace 下載一個模型用 torch.onnx.export 導(dǎo)出來一個 .onnx 文件onnxruntime 就能直接吃下去。這個“能吃下”的背后是微軟對 ONNX 運行時生態(tài)的持續(xù)投入。從 2017 年開源到現(xiàn)在項目從最初的 CPU 推理庫一路擴(kuò)展出 onnxruntime-gpu、onnxruntime-web、onnxruntime-mobile 的完整矩陣。瀏覽器端這一支負(fù)責(zé)把圖優(yōu)化、算子實現(xiàn)、內(nèi)存管理這些復(fù)雜邏輯全部封裝在 WebAssembly 和 WebGPU 的底層適配里對外暴露的 JS API 卻非常簡單。1.2 和 TensorFlow.js 的路線對比有對比才有說服力。當(dāng)時我在一個視頻摳圖項目里比較過 TF.js 和 onnxruntime 的實際表現(xiàn)同樣一個 MobileNetV3 語義分割模型對比項TensorFlow.jsONNX Runtime Web模型來源主要面向 TF/Keras 生態(tài)支持 PyTorch、TF、Keras、TFLite 等轉(zhuǎn)換工具鏈tfjs-convertertorch.onnx.export / tf2onnx瀏覽器后端WebGL 早期、WebGPU 逐步支持WASM 成熟、WebGPU 持續(xù)迭代算子覆蓋偏向 TF 原生算子社區(qū)匯總的常用算子覆蓋面更廣包體積依賴 TensorFlow.js 全家桶可按需選擇 ort-wasm 或 ort-webgpu相對輕量在實際操作里除非你的模型本來就是 TF 系訓(xùn)練且不打算動結(jié)構(gòu)否則從 PyTorch 到 ONNX 再到瀏覽器鏈路的順滑程度明顯優(yōu)于 PyTorch 轉(zhuǎn) TF.js。這也是社區(qū)里做瀏覽器端 Stable Diffusion、OCR、摳圖、人像分割等項目時首選 onnxruntime 的直接原因。1.3 一個運行時解決從服務(wù)器到瀏覽器的規(guī)模問題還有一個很多人忽略的好處同一份 .onnx 模型在服務(wù)端用 onnxruntime Python 包推理在瀏覽器端用 onnxruntime-web 推理完全無差別。這意味著你可以先在小規(guī)模場景下做前端全本地推理當(dāng)模型越來越大、算力扛不住的時候無縫把推理請求切到服務(wù)端模型文件不用動一行。這種彈性是其他框架很難給的。TF.js 模型想遷移到服務(wù)端還得先轉(zhuǎn) SavedModelONNX 本身就是服務(wù)端推理的主流格式之一兩邊順手就能銜接。2. ONNX Runtime Web 的兩條腿WASM 與 WebGPU 內(nèi)核2.1 WASM 內(nèi)核的“下限兜底”onnxruntime-web 的第一套執(zhí)行方式是 WebAssembly。這套方案的核心思路是把 C 寫的推理引擎編譯成 .wasm 文件然后瀏覽器直接加載執(zhí)行。具體到實現(xiàn)它用 Emscripten 工具鏈把 onnxruntime 的 C 源碼交叉編譯到 wasm同時在 SIMD單指令多數(shù)據(jù)指令集開啟時能利用 CPU 的向量化能力加速矩陣運算。對于不支持 WebGPU 的舊瀏覽器或者對兼容性要求極高的場景WASM 就是唯一的退路。這里有一個很多人容易忽略的細(xì)節(jié)wasm 文件也分版本。ONNX Runtime Web 發(fā)布的 .wasm 文件有普通版和 SIMD 版普通版兼容性最好SIMD 版需要瀏覽器支持 WASM SIMD 指令但推理速度通?？?1.5 到 3 倍。項目管理時最好在前端構(gòu)建階段做 feature detect 動態(tài)加載而不是寫死一個路徑。2.2 WebGPU 內(nèi)核的“性能上限”WebGPU API 是新一代瀏覽器圖形與計算接口相比 WebGL 最大的改進(jìn)是支持通用計算著色器Compute Shader。ONNX Runtime Web 的 WebGPU 后端就是把算子實現(xiàn)映射成計算著色器把 GPU 的大規(guī)模并行能力引導(dǎo)到矩陣乘法、卷積這類算子上去。我實際跑過 MobileNetV2 在 GPU 和 CPU 的差距WebGPU 大約是 WASM 的 4 到 6 倍速度提升。這是目前瀏覽器端 AI 推理性能的天花板——只要瀏覽器支持 WebGPU優(yōu)先用 WebGPU幾乎是共識。但 WebGPU 不是萬能的。首先是顯存管理問題瀏覽器端的 GPU 顯存和系統(tǒng)內(nèi)存之間的數(shù)據(jù)搬運靠 GPU 緩沖區(qū)來回拷貝如果模型輸入輸出頻繁變動就會出現(xiàn)不必要的傳輸開銷。其次WebGPU 后端目前對某些算子支持還不完整一旦模型里出現(xiàn)不支持的算子運行時不會自動幫你“翻譯”而是直接上演“路線不支持”的戲碼結(jié)果要么報錯要么在 WASM 上默默執(zhí)行。這就是為什么很多人推薦“混合執(zhí)行”模式——全局主流程在 WebGPU 上跑遇到不支持算子時自動 Fallback 到 WASM。onnxruntime 內(nèi)部有一個圖優(yōu)化機(jī)制會把模型按照支持情況拆分成可執(zhí)行子圖分配到不同 EPExecution Provider上。2.3 開發(fā)者需要關(guān)心哪些文件ort-wasm-simd-threaded.wasmWASM 后端主力版本帶 SIMD 和線程推理快但需要 COOP/COEP 跨源隔離頭支持。ort-wasm-simd-threaded.jsep.mjsWebGPU 后端的核心 JS 文件內(nèi)部同時封裝了訪存調(diào)度和算子執(zhí)行。.mjsES Module 格式配合 import 使用現(xiàn)代前端首推。.wasm二進(jìn)制內(nèi)核由 JS 文件在運行時動態(tài)加載。實際操作時我習(xí)慣把 wasm 文件放在 CDN 上用ort.env.wasm.wasmPaths指定路徑避免打進(jìn)前端 bundle 造成體積負(fù)擔(dān)。3. 從模型導(dǎo)出到瀏覽器推理的完整實操3.1 把 PyTorch 模型轉(zhuǎn)成 ONNX這是整條鏈路里最容易出幺蛾子的一步因為不同版本的 PyTorch 對 ONNX 導(dǎo)出的支持程度不一樣。我自己用的 PyTorch 2.x 版本導(dǎo)出接口已經(jīng)非常穩(wěn)定了。核心代碼長這樣import torch import torch.onnx model YourModel() model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, your_model.onnx, input_names[input], output_names[output], dynamic_axes{ input: {0: batch_size}, output: {0: batch_size} }, opset_version17 )這里有個小細(xì)節(jié)需要特別注意dynamic_axes里聲明了第一維為動態(tài) batch。如果不加這個參數(shù)ONNX 模型里的輸入 shape 會被固定死之后在瀏覽器里就算換了張不同大小的圖片也只能先 resize 固定尺寸再推理極其不方便。動態(tài)軸設(shè)置好之后后續(xù)在 JS 里傳 blobs 數(shù)組給不同 batch 就不用重新導(dǎo)出模型了。3.2 前端環(huán)境搭建與初始化前端項目直接用 npm 安裝npm install onnxruntime-web然后引入并初始化運行時實例import * as ort from onnxruntime-web/webgpu; ort.env.wasm.wasmPaths https://your-cdn-path/; const session await ort.InferenceSession.create(/models/your_model.onnx, { executionProviders: [webgpu, wasm], graphOptimizationLevel: all });executionProviders數(shù)組里寫兩個值是有講究的。onnxruntime 會按順序嘗試使用 ProviderWebGPU 不可用時自動降到 WASM。這是接入時最省心的容錯策略比在前端用navigator.gpu手動判斷要靠譜得多。3.3 推理流程示例假設(shè)我們做一個人像分割模型輸入是 1x3x256x256 的張量輸出是 1x1x256x256 的掩碼const inputTensor new ort.Tensor(float32, inputArray, [1, 3, 256, 256]); const feeds { input: inputTensor }; const results await session.run(feeds); const outputData results.output.data;這里的inputArray需要預(yù)處理成模型訓(xùn)練時一致的格式圖片解碼、去均值歸一化、通道順序從 HWC 轉(zhuǎn)成 CHW并且 float32 數(shù)組的排列順序要和 ONNX 里 NCHW 布局一致。這是前端 AI 推理新手踩得最多的坑——預(yù)處理不對模型精度直接崩。3.4 實際性能數(shù)據(jù)參考我在一臺普通 M1 MacBook Air 上跑過 MobileNetV3-Segmentation輸入 256x256的推理后端首次推理耗時平均推理耗時預(yù)熱后備注WASM無 SIMD約 380ms約 220ms兼容性最好性能較差WASMSIMD約 220ms約 110ms推薦兜底方案WebGPU約 90ms約 35ms性能最好需現(xiàn)代瀏覽器這個數(shù)據(jù)說明兩件事一是 SIMD 的收益非常明顯如果你還在用沒有 SIMD 的舊方案建議盡快升級二是 WebGPU 確實是瓶頸突破的關(guān)鍵但 Memory 分配和 Buffer 復(fù)用沒做好WebGPU 的優(yōu)勢會被傳輸開銷吃掉。4. 瀏覽器側(cè)的性能優(yōu)化不只在算子層4.1 動態(tài) shape 的代價動態(tài)軸很好用但頻繁改變輸入 shape 會讓 onnxruntime 內(nèi)部重新做內(nèi)存池分配和圖優(yōu)化推理耗時明顯增加。如果你的業(yè)務(wù)場景里輸入圖片尺寸基本一致建議固定靜態(tài) shape 導(dǎo)出模型換取推理性能的穩(wěn)定。實測下來固定 shape 的 MobileNet在 WebGPU 上比動態(tài) shape 快大約 15% 到 20%。這個差異來源主要是 GPU 緩沖區(qū)復(fù)用shape 固定緩沖區(qū)可以預(yù)分配好反復(fù)使用動態(tài) shape 則每次都要重新計算和分配。4.2 輸入輸出的 GPU 零拷貝策略在 WebGPU 后端最耗時的活動其實不是 GPU 算子計算而是 CPU 和 GPU 之間的數(shù)據(jù)搬運。session.run()之前你要把圖像數(shù)據(jù)填到一個ort.Tensor里這個 Tensor 如果直接作為參數(shù)傳給 run它默認(rèn)是 CPU 側(cè)的 ArrayBuffer。這塊數(shù)據(jù)要先上傳到 GPU計算完再下載回來。一個有效的優(yōu)化策略是直接構(gòu)造 GPU 側(cè)的 Tensor避免中間那份不必要的拷貝。原理是先用device.createBuffer創(chuàng)建 GPU 緩沖區(qū)給 ort 的 Tensor 提供 underlying buffer 地址。這部分 API 在 onnxruntime-web 的 WebGPU 實現(xiàn)里已經(jīng)支持代碼類似const gpuBuffer device.createBuffer({ size: inputArray.byteLength, usage: GPUBufferUsage.STORAGE | GPUBufferUsage.COPY_DST // ... }); const inputTensor new ort.Tensor(float32, gpuBuffer, [1, 3, 256, 256]);不過這個能力對內(nèi)存管理要求更高如果不熟悉 WebGPU 底層模型先用 CPU 側(cè)的 Tensor 把功能跑通再考慮往零拷貝方向優(yōu)化。4.3 模型裁剪與量化瀏覽器端加載體積直接影響首屏性能。一個 100MB 的 ONNX 模型下載慢還是次要的解析和優(yōu)化階段耗費的時間也會拖后腿。常見的優(yōu)化手段有兩個算子融合和量化。onnxruntime 的圖優(yōu)化本身就帶有算子融合功能比如把 Conv BatchNorm Relu 融合成一個 FusedConv能顯著減少算子執(zhí)行次數(shù)。graphOptimizationLevel: all就是開啟全部優(yōu)化。量化則依賴模型導(dǎo)出階段的處理。情感上一個 FP32 的模型可以壓縮到 INT8體積縮小 75%同時 WebGPU 上跑 INT8 算子在某些芯片上會有額外的速度加成。但量化不是哪里都能用的——不是所有算子都有 INT8 實現(xiàn)遇不到的算子會中途回退到 FP32 執(zhí)行性能反而可能更差所以量化之前建議在真實瀏覽器里做 App 級測試。4.4 線程與多會話并發(fā)WASM 線程模式需要跨源隔離也就是給服務(wù)器配置Cross-Origin-Opener-Policy和Cross-Origin-Embedder-Policy響應(yīng)頭。沒有這兩個頭ort-wasm-simd-threaded.wasm里依賴的SharedArrayBuffer會被瀏覽器禁用線程跑不起來性能直接倒退一大截。對于多會話并發(fā)onnxruntime-web 的 WebGPU 后端目前支持多實例并行但 GPU 內(nèi)存占用會線性增長。如果頁面同時開三四個 inference session建議評估一下顯存周期不能毫無節(jié)制地創(chuàng)建。5. 那些被反復(fù)問起的失敗與異常5.1 為什么會出現(xiàn) chromadb backend init failed最近好幾個項目組在接 onnxruntime 的時候都撞到過一條詭異的報錯chromadb backend init failed, falling back: the onnxruntime python package i。乍一看完全不懂 chromadb 和 onnxruntime 有什么關(guān)系其實這是一個環(huán)境沖突問題。chromadb 在做向量索引的時候內(nèi)部依賴一個獨立的 JVM 端的 hnswlib 擴(kuò)展而這個擴(kuò)展在安裝時會嘗試加載 nmslib / hnswlib 的原生庫。當(dāng) Python 環(huán)境里同時存在多個版本的 onnxruntime 動態(tài)庫或者 onnxruntime 的原生.so文件路徑干擾了 chromadb 對核心 native 庫的查找順序初始化階段就會失敗于是 chromadb 打出“fall back”的警告退回到純 Python 模式。這個報錯出現(xiàn)的高頻場景是同一臺設(shè)備里既用 pip 管理器安裝了一個 onnxruntime 包又用 conda 裝了另一個。兩個版本的二進(jìn)制庫同時存在于 sys.pathchromadb 初始化時拿到的是錯誤的庫句柄才會失敗。解決辦法是逐一排查環(huán)境冗余pip list | grep -i onnx一旦出現(xiàn)多個 onnxruntime 版本把 conda 環(huán)境里的那個卸載掉保留一個即可。5.2 onnxruntime 5060 是什么意思另一個在網(wǎng)上被頻繁搜索的熱詞是“onnxruntime 5060”。這不是 HTTP 狀態(tài)碼也不是端口號。真實的來源是 onnxruntime 在某些服務(wù)化部署方案里的默認(rèn)日志輸出比如在基于 FastAPI 或 Triton 的部署腳本里啟動 onnxruntime 推理實例時會打印一條包含端口信息的日志這個端口 5060 往往被誤認(rèn)為 onnxruntime 本身占用的服務(wù)端口。實際上 onnxruntime 本身不是一個常駐服務(wù)進(jìn)程而是一個被嵌入到 Python 或 Node.js 進(jìn)程里的運行時庫。所謂 5060 通常是用戶自己在部署腳本里指定的監(jiān)聽端口。如果遇到“onnxruntime 5060 連接超時”之類的提示排查方向應(yīng)該是應(yīng)用層服務(wù)器的啟動參數(shù)、防火墻規(guī)則或反向代理配置而不是去翻 onnxruntime 的源碼。5.3 瀏覽器端最常遇到的三個 Runtime ErrorTensor is not initialized輸入 Tensor 數(shù)據(jù)沒有正確填充常見于傳入的ArrayBuffer未正確對齊或者在 WebWorker 里傳數(shù)據(jù)時被結(jié)構(gòu)化克隆搞丟了類型。No FEAT_LOWP for operatorWebGPU EP 當(dāng)前版本的算子覆蓋不全所致需要升級 onnxruntime-web 版本或檢查模型里是否用了冷門算子。AbortError: shared memory is not availableWASM 線程模式需要 SharedArrayBuffer 而跨源隔離頭沒配置好檢查服務(wù)端響應(yīng)頭即可。在處理這些報錯時一個成熟的做法是每次升級 onnxruntime-web 版本后統(tǒng)一回歸一遍模型推理流程因為這個庫迭代很快某些算子實現(xiàn)會變化不回歸測試很容易等到上線后才暴雷。6. 動態(tài)鏈接庫版本混亂的根因與解法6.1 系統(tǒng)級動態(tài)庫的覆蓋關(guān)系服務(wù)端場景下onnxruntime 的動態(tài)庫問題比瀏覽器端更隱蔽。往往用戶環(huán)境里已經(jīng)有一個 onnxruntime 依賴的系統(tǒng)級.so文件比如/usr/lib/libonnxruntime.so然后 pip 安裝的 onnxruntime 包里又帶了一個更完整或不同版本的.so。運行時加載器默認(rèn)會按系統(tǒng)路徑優(yōu)先查找于是 pip 包里新版本庫被系統(tǒng)里的舊庫覆蓋行為完全不可控。這解釋了為什么“chromadb backend init failed”這種錯誤會莫名其妙地跨越不同包出現(xiàn)——根本原因不是 chromadb 和 onnxruntime 有什么業(yè)務(wù)關(guān)聯(lián)而是共享動態(tài)庫加載順序被污染。6.2 干凈的隔離方案推薦在項目里建立虛擬環(huán)境或容器化環(huán)境保證 onnxruntime 的庫路徑唯一python -m venv .venv source .venv/bin/activate pip install onnxruntime chromadb這種環(huán)境下Python 包的庫路徑集中在 virtualenv 的site-packages中不會和系統(tǒng)級庫產(chǎn)生沖突。如果是部署到 Linux 服務(wù)器推薦加一層 Docker 隔離沉淀出帶固定版本的鏡像。6.3 怎么確認(rèn)當(dāng)前 onnxruntime 版本和被加載路徑排查環(huán)境問題時一條命令就能看清楚import onnxruntime as ort print(ort.__version__) print(ort.__file__)輸出會顯示當(dāng)前 Python 是從哪個路徑加載的 onnxruntime。如果發(fā)現(xiàn)有兩個不同的路徑就說明環(huán)境變量PYTHONPATH或LD_LIBRARY_PATH里有人為插入的干擾項。清理思路是把不確定的路徑逐個去掉再用命令驗證。6.4 版本敏感性模型轉(zhuǎn)換版本與運行時版本另外ONNX 模型本身的 opset 版本和 onnxruntime 的兼容性問題也容易引發(fā)異常。新版 onnxruntime 通常向后兼容舊版 opset但太新的 opset 版本在老版運行時上會導(dǎo)致“Unsupported opset version”錯誤。保證模型導(dǎo)出的 opset 版本比運行時支持的最大版本低一兩個版本是比較穩(wěn)妥的方案。我自己的習(xí)慣是開發(fā)機(jī)上用和線上完全一致的 onnxruntime 版本同時用python -c import onnx; print(onnx.defs.onnx_opset_version())檢查模型 opset 版本做到心里有數(shù)。7. 常見問題排查與實戰(zhàn)經(jīng)驗7.1 推理結(jié)果全零或 NaN遇到這種問題90% 的可能性是輸入預(yù)處理不對。ONNX 模型里普遍要求輸入是float32且歸一化到 0~1 或者 -1~1但瀏覽器里直接從 Canvas 拿到的數(shù)據(jù)往往是Uint8ClampedArray通道順序是 RGBA 或 BGRA。如果你直接把這堆整型數(shù)據(jù)塞進(jìn)ort.Tensor(uint8)算子運算時數(shù)值范圍完全對不上輸出結(jié)果自然全零。正確做法是const imageData ctx.getImageData(0, 0, width, height); const float32Data new Float32Array(3 * 256 * 256); for (let i 0; i width * height; i) { float32Data[i] imageData.data[i * 4] / 255.0; float32Data[i width * height] imageData.data[i * 4 1] / 255.0; float32Data[i width * height * 2] imageData.data[i * 4 2] / 255.0; }注意這里把 RGB 三個通道拆開分別存到 CHW 連續(xù)內(nèi)存區(qū)塊里順序不能亂。7.2 WebGPU 下推理結(jié)果正確但掉幀掉幀問題通常不是模型計算慢而是 JS 主線程在session.run()前后做了太多同步工作。把輸入數(shù)據(jù)的預(yù)處理、Tensor 構(gòu)造、輸出后處理全部挪到 Web Worker 里主線程只負(fù)責(zé) UI 渲染和等待消息能明顯改善卡頓。7.3 如何打通“瀏覽器里只跑一個模型”的局限瀏覽器 AI 目前最大的瓶頸不是推理而是模型體積和內(nèi)存。單個幾十 MB 的小模型適合落地大模型如 7B 參數(shù)級別即使量化成 INT4也要 4GB 以上瀏覽器端內(nèi)存直接吃不消且 WebGPU 的顯存管理遠(yuǎn)沒有桌面端成熟。現(xiàn)階段更務(wù)實的做法是混合推理輕量模型在瀏覽器本地推理重量模型走服務(wù)端 API。7.4 給初學(xué)者的兩條實操建議第一先跑通一個極簡 Demo 再換自己的模型。onnxruntime-web 官方倉庫里有基于 SqueezeNet 的圖像分類示例代碼量不大先把這條路走通再切自己的業(yè)務(wù)模型能避免把“模型問題”和“代碼問題”混在一起難以排錯。第二訓(xùn)練模型時盡量少用自定義算子。雖然 ONNX 支持自定義算子擴(kuò)展但每增加一個自定義算子瀏覽器端的 wasm/WebGPU 實現(xiàn)就要多寫一套邏輯跨平臺兼容性迅速惡化。能用的 PyTorch 原生算子就能完成的就別造輪子。說到底o(hù)nnxruntime 之所以能在瀏覽器 AI 領(lǐng)域站穩(wěn)腳跟核心在于“生態(tài)杠桿”太強(qiáng)了——它把 Python 服務(wù)端和瀏覽器端拉進(jìn)同一個模型格式、同一個運行時兼容層。對做產(chǎn)品的人來說這意味著不用分裂維護(hù)兩套推理代碼模型訓(xùn)完導(dǎo)成 ONNX前端的活基本就完成了一大半。而一旦踩過動態(tài)庫、算子兼容、內(nèi)存分配這些坑之后你會發(fā)現(xiàn)在瀏覽器里跑 AI 這件事真的沒想象中那么玄乎。