การกำหนดค่าการให้บริการ Tensorflow

ในคู่มือนี้ เราจะพูดถึงจุดการกำหนดค่าต่างๆ มากมายสำหรับการให้บริการ Tensorflow

ภาพรวม

แม้ว่าการกำหนดค่าส่วนใหญ่จะเกี่ยวข้องกับ Model Server แต่ก็มีหลายวิธีในการระบุลักษณะการทำงานของ Tensorflow Serving:

• การกำหนดค่าเซิร์ฟเวอร์โมเดล : ระบุชื่อโมเดล เส้นทาง นโยบายเวอร์ชันและป้ายกำกับ การกำหนดค่าการบันทึก และอื่นๆ
• การกำหนดค่าการตรวจสอบ : เปิดใช้งานและกำหนดค่าการตรวจสอบ Prometheus
• การกำหนดค่าแบทช์ : เปิดใช้งานการแบทช์และกำหนดค่าพารามิเตอร์
• อื่น ๆ. ธง : เบ็ดเตล็ดจำนวนหนึ่ง ธงที่สามารถจัดเตรียมไว้เพื่อปรับแต่งพฤติกรรมของการปรับใช้ Tensorflow Serving

การกำหนดค่าเซิร์ฟเวอร์โมเดล

วิธีที่ง่ายที่สุดในการให้บริการโมเดลคือการจัดเตรียมแฟล็ก --model_name และ --model_base_path (หรือการตั้งค่าตัวแปรสภาพแวดล้อม MODEL_NAME หากใช้ Docker) อย่างไรก็ตาม หากคุณต้องการให้บริการหลายรุ่น หรือกำหนดค่าตัวเลือก เช่น ความถี่ในการโพลสำหรับเวอร์ชันใหม่ คุณสามารถทำได้โดยการเขียนไฟล์กำหนดค่า Model Server

คุณสามารถจัดเตรียมไฟล์การกำหนดค่านี้โดยใช้แฟล็ก --model_config_file และสั่งให้ Tensorflow Serving สำรวจหาไฟล์การกำหนดค่าเวอร์ชันที่อัปเดตนี้เป็นระยะๆ ในเส้นทางที่ระบุโดยการตั้งค่าแฟล็ก --model_config_file_poll_wait_seconds

ตัวอย่างการใช้นักเทียบท่า:

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

กำลังโหลดการกำหนดค่าเซิร์ฟเวอร์โมเดลใหม่

มีสองวิธีในการรีโหลดการกำหนดค่า Model Server:

• โดยการตั้งค่าแฟล็ก --model_config_file_poll_wait_seconds เพื่อสั่งให้เซิร์ฟเวอร์ตรวจสอบไฟล์กำหนดค่าใหม่เป็นระยะที่ --model_config_file filepath

• โดยการออกการเรียก HandleReloadConfigRequest RPC ไปยังเซิร์ฟเวอร์และจัดหาการกำหนดค่า Model Server ใหม่โดยทางโปรแกรม

โปรดทราบว่าในแต่ละครั้งที่เซิร์ฟเวอร์โหลดไฟล์กำหนดค่าใหม่ เซิร์ฟเวอร์จะทำหน้าที่รับรู้เนื้อหาของการกำหนดค่าที่ระบุใหม่ และ เฉพาะ การกำหนดค่าที่ระบุใหม่เท่านั้น ซึ่งหมายความว่า หากมีโมเดล A อยู่ในไฟล์กำหนดค่าแรก ซึ่งถูกแทนที่ด้วยไฟล์ที่มีเฉพาะรุ่น B เซิร์ฟเวอร์จะโหลดโมเดล B และยกเลิกการโหลดโมเดล A

รายละเอียดการกำหนดค่าเซิร์ฟเวอร์โมเดล

ไฟล์คอนฟิกูเรชัน Model Server ที่ระบุต้องเป็น บัฟเฟอร์โปรโตคอล ModelServerConfig

สำหรับการใช้งานทั้งหมดยกเว้นกรณีการใช้งานขั้นสูงสุด คุณจะต้องใช้ตัวเลือก ModelConfigList ซึ่งเป็นรายการบัฟเฟอร์โปรโตคอล ModelConfig นี่เป็นตัวอย่างพื้นฐาน ก่อนที่เราจะเจาะลึกตัวเลือกขั้นสูงด้านล่าง

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'
  }
}

การกำหนดค่าหนึ่งรุ่น

ModelConfig แต่ละรายการจะระบุโมเดลหนึ่งรายการที่จะให้บริการ รวมถึงชื่อและเส้นทางที่ Model Server ควรค้นหาเวอร์ชันของโมเดลที่จะให้บริการ ดังที่เห็นในตัวอย่างข้างต้น ตามค่าเริ่มต้น เซิร์ฟเวอร์จะให้บริการเวอร์ชันที่มีหมายเลขเวอร์ชันมากที่สุด ค่าเริ่มต้นนี้สามารถแทนที่ได้โดยการเปลี่ยนฟิลด์ model_version_policy

ให้บริการรุ่นเฉพาะของโมเดล

หากต้องการให้บริการเวอร์ชันเฉพาะของโมเดล แทนที่จะเปลี่ยนไปใช้เวอร์ชันที่มีหมายเลขเวอร์ชันมากที่สุดเสมอ ให้ตั้งค่า model_version_policy เป็น "เฉพาะ" และระบุหมายเลขเวอร์ชันที่คุณต้องการให้บริการ ตัวอย่างเช่น หากต้องการปักหมุดเวอร์ชัน 42 ให้เป็นเวอร์ชันที่ให้บริการ ให้ทำดังนี้

model_version_policy {
  specific {
    versions: 42
  }
}

ตัวเลือกนี้มีประโยชน์สำหรับการย้อนกลับไปเป็นเวอร์ชันที่ทราบดี ในกรณีที่พบปัญหาในเวอร์ชันล่าสุด

ให้บริการโมเดลหลายเวอร์ชัน

หากต้องการให้บริการโมเดลหลายเวอร์ชันพร้อมกัน เช่น หากต้องการเปิดใช้งานคานารีเวอร์ชันใหม่เบื้องต้นพร้อมการแบ่งส่วนข้อมูล ให้ตั้งค่า model_version_policy เป็น "เฉพาะ" และระบุหมายเลขเวอร์ชันหลายรายการ ตัวอย่างเช่น หากต้องการให้บริการเวอร์ชัน 42 และ 43:

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

การกำหนดป้ายกำกับสตริงให้กับเวอร์ชันของโมเดล เพื่อลดความซับซ้อนของ Canary และการย้อนกลับ

บางครั้งการเพิ่มระดับการอ้อมให้กับเวอร์ชันโมเดลก็มีประโยชน์ แทนที่จะแจ้งให้ลูกค้าของคุณทุกคนทราบว่าพวกเขาควรจะสืบค้นเวอร์ชัน 42 คุณสามารถกำหนดนามแฝง เช่น "เสถียร" ให้กับเวอร์ชันใดก็ตามที่เป็นเวอร์ชันที่ไคลเอ็นต์ควรสืบค้นในปัจจุบัน หากคุณต้องการเปลี่ยนเส้นทางการรับส่งข้อมูลบางส่วนไปยังเวอร์ชันโมเดล Canary เบื้องต้น คุณสามารถใช้นามแฝงที่สอง "canary" ได้

คุณสามารถกำหนดค่านามแฝงหรือป้ายกำกับเวอร์ชันโมเดลเหล่านี้ได้ เช่น:

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

ในตัวอย่างข้างต้น คุณกำลังให้บริการเวอร์ชัน 42 และ 43 และเชื่อมโยงป้ายกำกับ "stable" กับเวอร์ชัน 42 และป้ายกำกับ "canary" กับเวอร์ชัน 43 คุณสามารถให้ลูกค้าของคุณสอบถามโดยตรงไปยังป้ายกำกับ "stable" หรือ "canary" (อาจขึ้นอยู่กับการแฮชรหัสผู้ใช้) โดยใช้ฟิลด์ version_label ของบัฟเฟอร์โปรโตคอล ModelSpec และย้ายป้ายกำกับบนเซิร์ฟเวอร์โดยไม่แจ้งให้ลูกค้าทราบ เมื่อคุณทำ canarying เวอร์ชัน 43 เสร็จแล้ว และพร้อมที่จะเลื่อนระดับให้เป็นเวอร์ชันเสถียร คุณสามารถอัปเดตการกำหนดค่าเป็น:

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

หากคุณจำเป็นต้องทำการย้อนกลับในภายหลัง คุณสามารถเปลี่ยนกลับไปใช้การกำหนดค่าเก่าที่มีเวอร์ชัน 42 เป็น "เสถียร" ได้ มิฉะนั้น คุณสามารถเดินหน้าต่อไปได้ด้วยการยกเลิกการโหลดเวอร์ชัน 42 และโหลดเวอร์ชันใหม่ 44 เมื่อพร้อม จากนั้นจึงเลื่อนป้ายกำกับ Canary เป็น 44 และอื่นๆ

โปรดทราบว่าสามารถกำหนดป้ายกำกับให้กับเวอร์ชันโมเดลที่โหลด แล้ว และพร้อมสำหรับการให้บริการเท่านั้น เมื่อเวอร์ชันโมเดลพร้อมใช้งานแล้ว เราอาจโหลดการกำหนดค่าโมเดลซ้ำได้ทันทีเพื่อกำหนดป้ายกำกับให้กับเวอร์ชันนั้น ซึ่งสามารถทำได้โดยใช้ HandleReloadConfigRequest RPC หรือหากเซิร์ฟเวอร์ได้รับการตั้งค่าให้สำรวจระบบไฟล์สำหรับไฟล์กำหนดค่าเป็นระยะ ตามที่อธิบาย ไว้ข้างต้น

หากคุณต้องการกำหนดป้ายกำกับให้กับเวอร์ชันที่ยังไม่ได้โหลด (เช่น โดยการระบุทั้งเวอร์ชันของโมเดลและป้ายกำกับ ณ เวลาเริ่มต้น) คุณต้องตั้งค่าแฟล็ก --allow_version_labels_for_unavailable_models เป็นจริง ซึ่งอนุญาตให้ป้ายกำกับใหม่สามารถ กำหนดให้กับเวอร์ชันโมเดลที่ยังไม่ได้โหลด

โปรดทราบว่าสิ่งนี้ใช้ได้กับป้ายกำกับเวอร์ชันใหม่เท่านั้น (เช่น ป้ายกำกับที่ยังไม่ได้กำหนดให้กับเวอร์ชันในปัจจุบัน) ทั้งนี้เพื่อให้แน่ใจว่าในระหว่างการสลับเวอร์ชัน เซิร์ฟเวอร์จะไม่กำหนดป้ายกำกับให้กับเวอร์ชันใหม่ก่อนกำหนด ดังนั้นจึงละทิ้งคำขอทั้งหมดที่กำหนดไว้สำหรับป้ายกำกับนั้นในขณะที่กำลังโหลดเวอร์ชันใหม่

เพื่อให้เป็นไปตามการตรวจสอบความปลอดภัยนี้ หากมีการกำหนดป้ายกำกับเวอร์ชันที่ใช้งานอยู่แล้วอีกครั้ง คุณต้องกำหนดให้กับเวอร์ชันที่โหลดแล้วเท่านั้น ตัวอย่างเช่น หากคุณต้องการย้ายป้ายกำกับจากการชี้ไปที่เวอร์ชัน N ไปยังเวอร์ชัน N+1 คุณอาจส่งการกำหนดค่าที่มีเวอร์ชัน N และ N+1 ก่อน จากนั้นจึงส่งการกำหนดค่าที่มีเวอร์ชัน N+1 ป้ายกำกับ ชี้ไปที่ N+1 และไม่มีเวอร์ชัน N

การใช้งานส่วนที่เหลือ

หากคุณใช้พื้นผิว REST API เพื่อส่งคำขออนุมาน แทนที่จะใช้

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

เพียงขอเวอร์ชันโดยใช้ป้ายกำกับโดยจัดโครงสร้างเส้นทางคำขอของคุณเช่นนั้น

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

โปรดทราบว่าป้ายกำกับเวอร์ชันจำกัดเฉพาะลำดับอักขระ Word ซึ่งประกอบด้วยอักขระตัวอักษรและตัวเลขและขีดล่าง (เช่น [a-zA-Z0-9_]+ )

การกำหนดค่าการตรวจสอบ

คุณอาจจัดเตรียมคอนฟิกูเรชันการมอนิเตอร์ให้กับเซิร์ฟเวอร์โดยใช้แฟล็ก --monitoring_config_file เพื่อระบุไฟล์ที่มีบัฟเฟอร์โปรโตคอล MonitoringConfig นี่คือตัวอย่าง:

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

หากต้องการอ่านเมตริกจาก URL การตรวจสอบข้างต้น คุณต้องเปิดใช้งานเซิร์ฟเวอร์ HTTP ก่อนโดยการตั้งค่าแฟล็ก --rest_api_port จากนั้น คุณสามารถกำหนดค่า Prometheus Server ของคุณให้ดึงตัววัดจาก Model Server ได้โดยส่งค่า --rest_api_port และ path ไปให้

Tensorflow Serving รวบรวมเมตริกทั้งหมดที่ Serving บันทึกไว้ เช่นเดียวกับ Tensorflow หลัก

การกำหนดค่าแบทช์

Model Server มีความสามารถในการแบทช์คำขอในการตั้งค่าที่หลากหลายเพื่อให้ได้รับปริมาณงานที่ดีขึ้น การกำหนดเวลาสำหรับการจัดชุดนี้จะดำเนินการทั่วโลกสำหรับโมเดลและเวอร์ชันโมเดลทั้งหมดบนเซิร์ฟเวอร์ เพื่อให้มั่นใจว่ามีการใช้ทรัพยากรพื้นฐานให้เกิดประโยชน์สูงสุดเท่าที่จะเป็นไปได้ ไม่ว่าเซิร์ฟเวอร์จะให้บริการโมเดลหรือเวอร์ชันโมเดลจำนวนเท่าใด ( รายละเอียดเพิ่มเติม ) คุณสามารถเปิดใช้งานลักษณะการทำงานนี้ได้โดยการตั้งค่าแฟล็ก --enable_batching และควบคุมโดยส่งการกำหนดค่าไปยังแฟล็ก --batching_parameters_file

ตัวอย่างไฟล์พารามิเตอร์การแบตช์:

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

โปรดดู คู่มือการจัดชุด สำหรับการสนทนาเชิงลึก และดู หัวข้อพารามิเตอร์ เพื่อทำความเข้าใจวิธีตั้งค่าพารามิเตอร์

ธงเบ็ดเตล็ด

นอกเหนือจากธงที่กล่าวถึงในคู่มือนี้แล้ว เรายังมีรายการธงอื่นๆ ที่น่าสนใจอีกสองสามรายการด้วย สำหรับรายการทั้งหมด โปรดดูที่ ซอร์สโค้ด

• --port : พอร์ตที่จะฟังสำหรับ gRPC API
• --rest_api_port : พอร์ตที่จะฟังสำหรับ HTTP/REST API
• --rest_api_timeout_in_ms : หมดเวลาสำหรับการเรียก HTTP/REST API
• --file_system_poll_wait_seconds : ช่วงเวลาที่เซิร์ฟเวอร์สำรวจระบบไฟล์สำหรับเวอร์ชันรุ่นใหม่ที่ model_base_path ของแต่ละรุ่นตามลำดับ
• --enable_model_warmup : เปิดใช้งาน การอุ่นเครื่องโมเดล โดยใช้ PredictionLogs ที่ผู้ใช้จัดเตรียมไว้ในไดเร็กทอรี Assets.extra/
• --mixed_precision=bfloat16 : เปิดใช้งาน BF16 Automatic Mixed Precision