Lưu ngày! Google I / O hoạt động trở lại từ ngày 18 đến 20 tháng 5 Đăng ký ngay
Trang này được dịch bởi Cloud Translation API.
Switch to English

Nền tảng và môi trường

TensorFlow.js hoạt động trên trình duyệt và Node.js, và trong cả hai nền tảng đều có nhiều cấu hình khả dụng khác nhau. Mỗi nền tảng có một tập hợp cân nhắc duy nhất sẽ ảnh hưởng đến cách ứng dụng được phát triển.

Trong trình duyệt, TensorFlow.js hỗ trợ thiết bị di động cũng như thiết bị máy tính để bàn. Mỗi thiết bị có một tập hợp các ràng buộc cụ thể, chẳng hạn như các API WebGL có sẵn, được tự động xác định và định cấu hình cho bạn.

Trong Node.js, TensorFlow.js hỗ trợ liên kết trực tiếp với API TensorFlow hoặc chạy với các triển khai CPU vani chậm hơn.

Môi trường

Khi một chương trình TensorFlow.js được thực thi, cấu hình cụ thể được gọi là môi trường. Môi trường bao gồm một chương trình phụ trợ toàn cầu duy nhất cũng như một tập hợp các cờ kiểm soát các tính năng chi tiết của TensorFlow.js.

Phụ trợ

TensorFlow.js hỗ trợ nhiều phụ trợ khác nhau thực hiện các phép toán và lưu trữ tensor. Tại bất kỳ thời điểm nào, chỉ có một chương trình phụ trợ hoạt động. Hầu hết thời gian, TensorFlow.js sẽ tự động chọn phần phụ trợ tốt nhất cho bạn trong môi trường hiện tại. Tuy nhiên, đôi khi điều quan trọng là phải biết phần phụ trợ nào đang được sử dụng và cách chuyển đổi nó.

Để tìm chương trình phụ trợ bạn đang sử dụng:

console.log(tf.getBackend());

Nếu bạn muốn thay đổi chương trình phụ trợ theo cách thủ công:

tf.setBackend('cpu');
console.log(tf.getBackend());

Phần phụ trợ WebGL

Phần mềm phụ trợ WebGL, 'webgl', hiện là phần mềm phụ trợ mạnh mẽ nhất cho trình duyệt. Phần phụ trợ này nhanh hơn tới 100 lần so với phần phụ trợ CPU vani. Hàng chục được lưu trữ dưới dạng kết cấu WebGL và các phép toán được thực hiện trong trình tạo bóng WebGL. Dưới đây là một số điều hữu ích cần biết khi sử dụng chương trình phụ trợ này: \

Tránh chặn chuỗi giao diện người dùng

Khi một phép toán được gọi, như tf.matMul (a, b), tf.Tensor kết quả được trả về đồng bộ, tuy nhiên, việc tính toán phép nhân ma trận có thể chưa thực sự sẵn sàng. Điều này có nghĩa là tf.Tensor trả về chỉ là một xử lý để tính toán. Khi bạn gọi x.data() hoặc x.array() , các giá trị sẽ phân giải khi quá trình tính toán thực sự hoàn thành. Điều này làm cho điều quan trọng là sử dụng các phương thức x.data()x.array() đồng bộ trên các bản sao đồng bộ x.dataSync()x.arraySync() để tránh chặn luồng giao diện người dùng trong khi tính toán hoàn tất.

Quản lý bộ nhớ

Một lưu ý khi sử dụng phần phụ trợ WebGL là cần phải quản lý bộ nhớ rõ ràng. WebGLTextures, là nơi cuối cùng dữ liệu Tensor được lưu trữ, không được trình duyệt tự động thu thập rác.

Để hủy bộ nhớ của tf.Tensor , bạn có thể sử dụng phương thức dispose() :

const a = tf.tensor([[1, 2], [3, 4]]);
a.dispose();

Việc xâu chuỗi nhiều hoạt động với nhau trong một ứng dụng là rất phổ biến. Giữ tham chiếu đến tất cả các biến trung gian để loại bỏ chúng có thể làm giảm khả năng đọc mã. Để giải quyết vấn đề này, TensorFlow.js cung cấp một phương thức tf.tidy() để xóa tất cả các tf.Tensor không được hàm trả về sau khi thực thi nó, tương tự như cách các biến cục bộ được dọn dẹp khi một hàm được thực thi:

const a = tf.tensor([[1, 2], [3, 4]]);
const y = tf.tidy(() => {
  const result = a.square().log().neg();
  return result;
});
Độ chính xác

Trên thiết bị di động, WebGL có thể chỉ hỗ trợ kết cấu dấu chấm động 16 bit. Tuy nhiên, hầu hết các mô hình học máy được đào tạo với trọng số và kích hoạt dấu chấm động 32 bit. Điều này có thể gây ra các vấn đề về độ chính xác khi chuyển mô hình cho thiết bị di động vì số thực 16 bit chỉ có thể đại diện cho các số trong phạm vi [0.000000059605, 65504] . Điều này có nghĩa là bạn nên cẩn thận rằng trọng lượng và kích hoạt trong mô hình của bạn không vượt quá phạm vi này. Để kiểm tra xem thiết bị có hỗ trợ họa tiết 32 bit hay không, hãy kiểm tra giá trị của tf.ENV.getBool('WEBGL_RENDER_FLOAT32_CAPABLE') , nếu điều này là sai thì thiết bị chỉ hỗ trợ họa tiết dấu chấm động 16 bit. Bạn có thể sử dụng tf.ENV.getBool('WEBGL_RENDER_FLOAT32_ENABLED') để kiểm tra xem TensorFlow.js hiện có đang sử dụng kết cấu 32 bit hay không.

Tổng hợp Shader và tải lên kết cấu

TensorFlow.js thực thi các hoạt động trên GPU bằng cách chạy các chương trình đổ bóng WebGL. Các trình tạo bóng này được lắp ráp và biên dịch một cách lười biếng khi người dùng yêu cầu thực hiện một thao tác. Quá trình biên dịch bộ đổ bóng xảy ra trên CPU trên luồng chính và có thể chậm. TensorFlow.js sẽ tự động lưu trữ các trình tạo bóng đã biên dịch, làm cho lần gọi thứ hai đến cùng một hoạt động với các tenxơ đầu vào và đầu ra có cùng hình dạng nhanh hơn nhiều. Thông thường, các ứng dụng TensorFlow.js sẽ sử dụng các thao tác giống nhau nhiều lần trong thời gian tồn tại của ứng dụng, do đó lần thứ hai thông qua mô hình học máy nhanh hơn nhiều.

TensorFlow.js cũng lưu trữ dữ liệu tf.Tensor dưới dạng WebGLTextures. Khi tf.Tensor được tạo, chúng tôi không tải dữ liệu lên GPU ngay lập tức, thay vào đó chúng tôi giữ dữ liệu trên CPU cho đến khi tf.Tensor được sử dụng trong một hoạt động. Nếu tf.Tensor được sử dụng lần thứ hai, dữ liệu đã có trên GPU nên không có phí tải lên. Trong một mô hình học máy điển hình, điều này có nghĩa là trọng số được tải lên trong lần dự đoán đầu tiên thông qua mô hình và lần truyền thứ hai qua mô hình sẽ nhanh hơn nhiều.

Nếu bạn quan tâm đến hiệu suất của dự đoán đầu tiên thông qua mô hình hoặc mã TensorFlow.js của mình, chúng tôi khuyên bạn nên hâm nóng mô hình bằng cách chuyển một Tensor đầu vào có cùng hình dạng trước khi dữ liệu thực được sử dụng.

Ví dụ:

const model = await tf.loadLayersModel(modelUrl);

// Warmup the model before using real data.
const warmupResult = model.predict(tf.zeros(inputShape));
warmupResult.dataSync();
warmupResult.dispose();

// The second predict() will be much faster
const result = model.predict(userData);

Node.js TensorFlow phụ trợ

Trong phần phụ trợ TensorFlow Node.js, 'nút', API TensorFlow C được sử dụng để tăng tốc các hoạt động. Điều này sẽ sử dụng khả năng tăng tốc phần cứng có sẵn của máy, như CUDA, nếu có.

Trong phần phụ trợ này, cũng giống như phần phụ trợ WebGL, các hoạt động trả về tf.Tensor s một cách đồng bộ. Tuy nhiên, không giống như phần phụ trợ WebGL, hoạt động được hoàn thành trước khi bạn lấy lại tensor. Điều này có nghĩa là một lệnh gọi tới tf.matMul(a, b) sẽ chặn luồng giao diện người dùng.

Vì lý do này, nếu bạn định sử dụng nó trong một ứng dụng sản xuất, bạn nên chạy TensorFlow.js trong các luồng công nhân để không chặn luồng chính.

Để biết thêm thông tin về Node.js, hãy xem hướng dẫn này.

Chương trình phụ trợ WASM

TensorFlow.js cung cấp phần phụ trợ WebAssembly ( wasm ), cung cấp khả năng tăng tốc CPU và có thể được sử dụng như một giải pháp thay thế cho phần phụ trợ CPU JavaScript vani ( cpu ) và phụ trợ tăng tốc WebGL ( webgl ). Để dùng nó:

// Set the backend to WASM and wait for the module to be ready.
tf.setBackend('wasm');
tf.ready().then(() => {...});

Nếu máy chủ của bạn đang cung .wasm tệp .wasm trên một đường dẫn khác hoặc một tên khác, hãy sử dụng setWasmPath trước khi bạn khởi tạo chương trình phụ trợ. Xem phần "Sử dụng gói" trong README để biết thêm thông tin:

import {setWasmPath} from '@tensorflow/tfjs-backend-wasm';
setWasmPath(yourCustomPath);
tf.setBackend('wasm');
tf.ready().then(() => {...});
Tại sao WASM?

WASM được giới thiệu vào năm 2015 dưới dạng định dạng nhị phân dựa trên web mới, cung cấp các chương trình được viết bằng JavaScript, C, C ++, v.v. một mục tiêu biên dịch để chạy trên web. WASM đã được hỗ trợ bởi Chrome, Safari, Firefox và Edge kể từ năm 2017 và được hỗ trợ bởi 90% thiết bị trên toàn thế giới.

Hiệu suất

Phần phụ trợ WASM tận dụng thư viện XNNPACK để triển khai tối ưu hóa các nhà khai thác mạng thần kinh.

So với JavaScript : Các mã nhị phân WASM thường nhanh hơn nhiều so với các gói JavaScript để trình duyệt tải, phân tích cú pháp và thực thi. JavaScript được nhập động và thu thập rác, điều này có thể gây chậm máy khi chạy.

So với WebGL : WebGL nhanh hơn WASM đối với hầu hết các mô hình, nhưng đối với các mô hình nhỏ, WASM có thể hoạt động tốt hơn WebGL do chi phí cố định của việc thực hiện trình tạo bóng WebGL. Phần “Khi nào tôi nên sử dụng WASM” bên dưới thảo luận về kinh nghiệm để đưa ra quyết định này.

Tính di động và tính ổn định

WASM có số học float 32 bit di động, cung cấp tính chẵn lẻ chính xác trên tất cả các thiết bị. Mặt khác, WebGL dành riêng cho phần cứng và các thiết bị khác nhau có thể có độ chính xác khác nhau (ví dụ: dự phòng về số nổi 16 bit trên thiết bị iOS).

Giống như WebGL, WASM được hỗ trợ chính thức bởi tất cả các trình duyệt chính. Không giống như WebGL, WASM có thể chạy trong Node.js và được sử dụng phía máy chủ mà không cần biên dịch thư viện gốc.

Khi nào tôi nên sử dụng WASM?

Kích thước mô hình và nhu cầu tính toán

Nói chung, WASM là một lựa chọn tốt khi các mô hình nhỏ hơn hoặc bạn quan tâm đến các thiết bị cấp thấp hơn thiếu hỗ trợ WebGL (phần mở rộng OES_texture_float ) hoặc có GPU kém mạnh mẽ hơn. Biểu đồ dưới đây cho thấy suy luận lần (tính TensorFlow.js 1.5.2) trong Chrome trên 2018 MacBook Pro cho 5 hỗ trợ chính thức của chúng tôi mô hình trên WebGL, WASM, và backends CPU:

Các mô hình nhỏ hơn

Mô hình WebGL ĐÃ M CPU Ký ức
BlazeFace 22,5 mili giây 15,6 mili giây 315,2 mili giây .4 MB
FaceMesh 19,3 mili giây 19,2 mili giây 335 mili giây 2,8 MB

Các mô hình lớn hơn

Mô hình WebGL ĐÃ M CPU Ký ức
PoseNet 42,5 mili giây 173,9 mili giây 1514,7 mili giây 4,5 MB
BodyPix 77 mili giây 188,4 mili giây 2683 mili giây 4,6 MB
MobileNet v2 37 mili giây 94 mili giây 923,6 mili giây 13 MB

Bảng trên cho thấy rằng WASM nhanh hơn 10-30 lần so với phụ trợ CPU JS đơn giản trên các mô hình và cạnh tranh với WebGL cho các mô hình nhỏ hơn như BlazeFace , nhẹ (400KB), nhưng có một số hoạt động tốt (~ 140). Do các chương trình WebGL có chi phí cố định trên mỗi lần thực thi op, điều này giải thích tại sao các mô hình như BlazeFace nhanh hơn trên WASM.

Các kết quả này sẽ khác nhau tùy thuộc vào thiết bị của bạn. Cách tốt nhất để xác định xem WASM có phù hợp với ứng dụng của bạn hay không là kiểm tra nó trên các chương trình phụ trợ khác nhau của chúng tôi.

Suy luận so với Đào tạo

Để giải quyết trường hợp sử dụng chính cho việc triển khai các mô hình được đào tạo trước, việc phát triển phần phụ trợ WASM sẽ ưu tiên suy luận hơn hỗ trợ đào tạo . Xem danh sách cập nhật các hoạt động được hỗ trợ trong WASM và cho chúng tôi biết nếu mô hình của bạn có tùy chọn không được hỗ trợ. Đối với các mô hình đào tạo, chúng tôi khuyên bạn nên sử dụng phần phụ trợ Node (TensorFlow C ++) hoặc phần phụ trợ WebGL.

Chương trình phụ trợ CPU

Phần phụ trợ CPU, 'cpu', là phần phụ trợ kém hiệu quả nhất, tuy nhiên nó là phần mềm đơn giản nhất. Tất cả các hoạt động đều được triển khai bằng JavaScript vani, điều này làm cho chúng ít khả năng song song hóa hơn. Họ cũng chặn chuỗi giao diện người dùng.

Phần phụ trợ này có thể rất hữu ích để thử nghiệm hoặc trên các thiết bị không có WebGL.

Cờ

TensorFlow.js có một tập hợp các cờ môi trường được tự động đánh giá và xác định cấu hình tốt nhất trong nền tảng hiện tại. Các cờ này chủ yếu là nội bộ, nhưng một số cờ toàn cầu có thể được kiểm soát bằng API công khai.

  • tf.enableProdMode(): chế độ sản xuất, chế độ này sẽ loại bỏ xác thực mô hình, kiểm tra NaN và các kiểm tra tính đúng đắn khác có lợi cho hiệu suất.
  • tf.enableDebugMode() : bật chế độ gỡ lỗi, chế độ này sẽ đăng nhập vào bảng điều khiển mọi hoạt động được thực thi, cũng như thông tin hiệu suất thời gian chạy như dấu chân bộ nhớ và tổng thời gian thực thi hạt nhân. Lưu ý rằng điều này sẽ làm chậm ứng dụng của bạn rất nhiều, không sử dụng điều này trong sản xuất.