Cấu hình phục vụ Tensorflow

Trong hướng dẫn này, chúng tôi sẽ điểm qua nhiều điểm cấu hình cho Dịch vụ Tensorflow.

Tổng quan

Mặc dù hầu hết các cấu hình đều liên quan đến Máy chủ mô hình, nhưng có nhiều cách để chỉ định hành vi của Tensorflow Serve:

  • Cấu hình máy chủ mô hình : Chỉ định tên mô hình, đường dẫn, chính sách và nhãn phiên bản, cấu hình ghi nhật ký, v.v.
  • Cấu hình giám sát : Kích hoạt và định cấu hình giám sát Prometheus
  • Cấu hình theo đợt : Kích hoạt tính năng theo đợt và định cấu hình các tham số của nó
  • Linh tinh. Cờ : Một số linh tinh. các cờ có thể được cung cấp để tinh chỉnh hoạt động triển khai Dịch vụ Tensorflow

Cấu hình máy chủ mẫu

Cách dễ nhất để phân phát một mô hình là cung cấp cờ --model_name và --model_base_path (hoặc đặt biến môi trường MODEL_NAME nếu sử dụng Docker). Tuy nhiên, nếu bạn muốn phân phối nhiều mô hình hoặc định cấu hình các tùy chọn như tần suất bỏ phiếu cho các phiên bản mới, bạn có thể làm như vậy bằng cách viết tệp cấu hình Máy chủ Mô hình.

Bạn có thể cung cấp tệp cấu hình này bằng cờ --model_config_file và hướng dẫn Dịch vụ Tensorflow thăm dò định kỳ các phiên bản cập nhật của tệp cấu hình này tại đường dẫn đã chỉ định bằng cách đặt cờ --model_config_file_poll_wait_seconds .

Ví dụ sử dụng Docker:

docker run -t --rm -p 8501:8501 \
    -v "$(pwd)/models/:/models/" tensorflow/serving \
    --model_config_file=/models/models.config \
    --model_config_file_poll_wait_seconds=60

Tải lại cấu hình máy chủ mô hình

Có hai cách để tải lại cấu hình Model Server:

  • Bằng cách đặt cờ --model_config_file_poll_wait_seconds để hướng dẫn máy chủ kiểm tra định kỳ tệp cấu hình mới tại --model_config_file filepath.

  • Bằng cách thực hiện các lệnh gọi RPC HandleReloadConfigRequest đến máy chủ và cung cấp cấu hình Máy chủ Mô hình mới theo chương trình.

Xin lưu ý rằng mỗi khi máy chủ tải tệp cấu hình mới, nó sẽ hoạt động để nhận ra nội dung của cấu hình được chỉ định mới và chỉ cấu hình được chỉ định mới. Điều này có nghĩa là nếu mô hình A có trong tệp cấu hình đầu tiên, được thay thế bằng tệp chỉ chứa mô hình B, thì máy chủ sẽ tải mô hình B và hủy tải mô hình A.

Chi tiết cấu hình máy chủ mô hình

Tệp cấu hình Model Server được cung cấp phải là bộ đệm giao thức ModelServerConfig .

Đối với tất cả các trường hợp sử dụng ngoại trừ những trường hợp sử dụng nâng cao nhất, bạn sẽ muốn sử dụng tùy chọn ModelConfigList, đây là danh sách các bộ đệm giao thức ModelConfig . Đây là một ví dụ cơ bản trước khi chúng ta đi sâu vào các tùy chọn nâng cao bên dưới.

model_config_list {
  config {
    name: 'my_first_model'
    base_path: '/tmp/my_first_model/'
    model_platform: 'tensorflow'
  }
  config {
    name: 'my_second_model'
    base_path: '/tmp/my_second_model/'
    model_platform: 'tensorflow'
  }
}

Cấu hình một mô hình

Mỗi ModelConfig chỉ định một mô hình sẽ được phân phát, bao gồm tên của nó và đường dẫn mà Máy chủ mô hình sẽ tìm kiếm các phiên bản của mô hình để phân phát, như đã thấy trong ví dụ trên. Theo mặc định, máy chủ sẽ phục vụ phiên bản có số phiên bản lớn nhất. Mặc định này có thể được ghi đè bằng cách thay đổi trường model_version_policy.

Phục vụ một phiên bản cụ thể của một mô hình

Để phân phối một phiên bản cụ thể của mô hình, thay vì luôn chuyển sang phiên bản có số phiên bản lớn nhất, hãy đặt model_version_policy thành "cụ thể" và cung cấp số phiên bản bạn muốn phân phối. Ví dụ: để ghim phiên bản 42 làm phiên bản phục vụ:

model_version_policy {
  specific {
    versions: 42
  }
}

Tùy chọn này hữu ích để quay lại phiên bản đã biết rõ, trong trường hợp phát hiện thấy sự cố với (các) phiên bản mới nhất.

Phục vụ nhiều phiên bản của một mô hình

Để phân phối đồng thời nhiều phiên bản của mô hình, ví dụ: để cho phép sắp xếp một phiên bản mới dự kiến ​​với một phần lưu lượng truy cập, hãy đặt model_version_policy thành "cụ thể" và cung cấp nhiều số phiên bản. Ví dụ: để phục vụ phiên bản 42 và 43:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}

Gán nhãn chuỗi cho các phiên bản mô hình, để đơn giản hóa Canary và Rollback

Đôi khi việc thêm mức độ gián tiếp vào các phiên bản mô hình sẽ rất hữu ích. Thay vì để tất cả khách hàng của bạn biết rằng họ nên truy vấn phiên bản 42, bạn có thể chỉ định bí danh như "ổn định" cho bất kỳ phiên bản nào hiện tại mà khách hàng nên truy vấn. Nếu bạn muốn chuyển hướng một phần lưu lượng truy cập sang phiên bản mô hình canary dự kiến, bạn có thể sử dụng bí danh thứ hai là "canary".

Bạn có thể định cấu hình các bí danh hoặc nhãn phiên bản mô hình này như sau:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 42
}
version_labels {
  key: 'canary'
  value: 43
}

Trong ví dụ trên, bạn đang phân phát phiên bản 42 và 43, đồng thời liên kết nhãn "ổn định" với phiên bản 42 và nhãn "canary" với phiên bản 43. Bạn có thể yêu cầu khách hàng của mình truy vấn trực tiếp tới một trong những phiên bản "ổn định" hoặc "canary" (có lẽ dựa trên việc băm id người dùng) bằng cách sử dụng trường version_label của bộ đệm giao thức ModelSpec và chuyển tiếp nhãn trên máy chủ mà không thông báo cho khách hàng. Khi bạn đã hoàn tất việc chỉnh sửa phiên bản 43 và sẵn sàng nâng cấp nó lên phiên bản ổn định, bạn có thể cập nhật cấu hình thành:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 43
}
version_labels {
  key: 'canary'
  value: 43
}

Nếu sau đó bạn cần thực hiện khôi phục, bạn có thể hoàn nguyên về cấu hình cũ có phiên bản 42 là "ổn định". Nếu không, bạn có thể tiếp tục bằng cách dỡ bỏ phiên bản 42 và tải phiên bản 44 mới khi nó sẵn sàng, sau đó nâng nhãn canary lên 44, v.v.

Xin lưu ý rằng bạn chỉ có thể gán nhãn cho các phiên bản mô hình đã được tải và có sẵn để phân phối. Khi có sẵn phiên bản mô hình, người ta có thể tải lại cấu hình mô hình một cách nhanh chóng để gán nhãn cho nó. Điều này có thể đạt được bằng cách sử dụng RPC HandleReloadConfigRequest hoặc nếu máy chủ được thiết lập để thăm dò định kỳ hệ thống tệp cho tệp cấu hình, như được mô tả ở trên .

Nếu bạn muốn gán nhãn cho một phiên bản chưa được tải (ví dụ: bằng cách cung cấp cả phiên bản mô hình và nhãn khi khởi động) thì bạn phải đặt cờ --allow_version_labels_for_unavailable_models thành true, cho phép các nhãn mới được gán cho các phiên bản mô hình chưa được tải.

Xin lưu ý rằng điều này chỉ áp dụng cho nhãn phiên bản mới (tức là những nhãn hiện chưa được gán cho phiên bản). Điều này nhằm đảm bảo rằng trong quá trình hoán đổi phiên bản, máy chủ không gán nhãn sớm cho phiên bản mới, do đó loại bỏ tất cả các yêu cầu dành cho nhãn đó trong khi phiên bản mới đang tải.

Để tuân thủ kiểm tra an toàn này, nếu gán lại nhãn phiên bản đã được sử dụng, bạn chỉ được gán nhãn đó cho các phiên bản đã được tải sẵn. Ví dụ: nếu bạn muốn di chuyển nhãn từ trỏ đến phiên bản N sang phiên bản N+1, trước tiên bạn có thể gửi cấu hình chứa phiên bản N và N+1, sau đó gửi cấu hình chứa phiên bản N+1, nhãn trỏ tới N+1 và không có phiên bản N.

Cách sử dụng phần còn lại

Nếu bạn đang sử dụng bề mặt API REST để thực hiện các yêu cầu suy luận, thay vì sử dụng

/v1/models/<model name>/versions/<version number>

chỉ cần yêu cầu một phiên bản sử dụng nhãn bằng cách cấu trúc đường dẫn yêu cầu của bạn như vậy

/v1/models/<model name>/labels/<version label> .

Lưu ý rằng nhãn phiên bản bị giới hạn ở một chuỗi ký tự Word, bao gồm các ký tự chữ và số và dấu gạch dưới (tức là [a-zA-Z0-9_]+ ).

Cấu hình giám sát

Bạn có thể cung cấp cấu hình giám sát cho máy chủ bằng cách sử dụng cờ --monitoring_config_file để chỉ định tệp chứa bộ đệm giao thức MonitorConfig . Đây là một ví dụ:

prometheus_config {
  enable: true,
  path: "/monitoring/prometheus/metrics"
}

Để đọc số liệu từ URL giám sát ở trên, trước tiên bạn cần bật máy chủ HTTP bằng cách đặt cờ --rest_api_port . Sau đó, bạn có thể định cấu hình Máy chủ Prometheus của mình để lấy số liệu từ Máy chủ mô hình bằng cách chuyển cho nó các giá trị của --rest_api_port và path .

Dịch vụ Tensorflow thu thập tất cả các số liệu được Dịch vụ cũng như Tensorflow cốt lõi thu thập.

Cấu hình hàng loạt

Model Server có khả năng xử lý các yêu cầu hàng loạt trong nhiều cài đặt khác nhau để đạt được thông lượng tốt hơn. Việc lập kế hoạch cho đợt này được thực hiện trên toàn cầu cho tất cả các mô hình và phiên bản mô hình trên máy chủ để đảm bảo việc sử dụng tốt nhất các tài nguyên cơ bản cho dù máy chủ hiện đang phục vụ bao nhiêu mô hình hoặc phiên bản mô hình ( chi tiết hơn ). Bạn có thể kích hoạt hành vi này bằng cách đặt cờ --enable_batching và kiểm soát nó bằng cách chuyển cấu hình tới cờ --batching_parameters_file .

Ví dụ về tệp tham số batching:

max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }

Vui lòng tham khảo hướng dẫn tạo khối để thảo luận chuyên sâu và tham khảo phần thông số để hiểu cách đặt tham số.

Cờ khác

Ngoài những lá cờ được đề cập trong hướng dẫn cho đến nay, ở đây chúng tôi liệt kê một số lá cờ đáng chú ý khác. Để có danh sách đầy đủ, vui lòng tham khảo mã nguồn .

  • --port : Cổng để nghe API gRPC
  • --rest_api_port : Cổng để nghe API HTTP/REST
  • --rest_api_timeout_in_ms : Hết thời gian chờ cho lệnh gọi API HTTP/REST
  • --file_system_poll_wait_seconds : Khoảng thời gian mà máy chủ thăm dò hệ thống tệp để tìm các phiên bản mô hình mới tại model_base_path tương ứng của mỗi mô hình
  • --enable_model_warmup : Cho phép khởi động mô hình bằng cách sử dụng PredictionLogs do người dùng cung cấp trong thư mục assets.extra/
  • --mixed_precision=bfloat16 : Kích hoạt độ chính xác hỗn hợp tự động BF16