Konfigurasi Penyajian Tensorflow

Dalam panduan ini, kita akan membahas berbagai titik konfigurasi untuk Tensorflow Serving.

Ringkasan

Meskipun sebagian besar konfigurasi berhubungan dengan Server Model, ada banyak cara untuk menentukan perilaku Tensorflow Serving:

Konfigurasi Server Model

Cara termudah untuk menyajikan model adalah dengan memberikan flag --model_name dan --model_base_path (atau menyetel variabel lingkungan MODEL_NAME jika menggunakan Docker). Namun, jika Anda ingin menyajikan beberapa model, atau mengonfigurasi opsi seperti frekuensi polling untuk versi baru, Anda dapat melakukannya dengan menulis file konfigurasi Model Server.

Anda dapat menyediakan file konfigurasi ini menggunakan flag --model_config_file dan menginstruksikan Tensorflow Serving untuk melakukan polling secara berkala untuk versi terbaru dari file konfigurasi ini di jalur yang ditentukan dengan menyetel flag --model_config_file_poll_wait_seconds .

Contoh menggunakan 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

Memuat Ulang Konfigurasi Server Model

Ada dua cara untuk memuat ulang konfigurasi Model Server:

  • Dengan menyetel flag --model_config_file_poll_wait_seconds untuk menginstruksikan server agar secara berkala memeriksa file konfigurasi baru di jalur file --model_config_file .

  • Dengan mengeluarkan panggilan RPC HandleReloadConfigRequest ke server dan menyediakan konfigurasi Server Model baru secara terprogram.

Harap dicatat bahwa setiap kali server memuat file konfigurasi baru, server akan bertindak untuk merealisasikan konten konfigurasi baru yang ditentukan dan hanya konfigurasi baru yang ditentukan. Artinya jika model A ada di file konfigurasi pertama, yang diganti dengan file yang hanya berisi model B, server akan memuat model B dan membongkar model A.

Detail Konfigurasi Server Model

File konfigurasi Model Server yang disediakan harus berupa buffering protokol ModelServerConfig .

Untuk semua kecuali kasus penggunaan tingkat lanjut, Anda dapat menggunakan opsi ModelConfigList, yang merupakan daftar buffer protokol ModelConfig . Berikut adalah contoh dasarnya, sebelum kita mendalami opsi lanjutan di bawah.

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

Mengonfigurasi Satu Model

Setiap ModelConfig menentukan satu model yang akan dilayani, termasuk namanya dan jalur di mana Server Model harus mencari versi model yang akan dilayani, seperti yang terlihat pada contoh di atas. Secara default server akan menyajikan versi dengan nomor versi terbesar. Default ini dapat diganti dengan mengubah kolom model_version_policy.

Melayani Versi Model Tertentu

Untuk menayangkan versi model tertentu, daripada selalu bertransisi ke versi dengan nomor versi terbesar, tetapkan model_version_policy ke "spesifik" dan berikan nomor versi yang ingin Anda tayangkan. Misalnya, untuk menyematkan versi 42 sebagai versi yang akan ditayangkan:

model_version_policy {
  specific {
    versions: 42
  }
}

Opsi ini berguna untuk mengembalikan ke versi yang diketahui baik, jika ditemukan masalah dengan versi terbaru.

Melayani Beberapa Versi Model

Untuk melayani beberapa versi model secara bersamaan, misalnya untuk mengaktifkan versi baru sementara dengan sepotong lalu lintas, setel model_version_policy ke "spesifik" dan berikan beberapa nomor versi. Misalnya, untuk melayani versi 42 dan 43:

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

Menetapkan Label String ke Versi Model, Untuk Menyederhanakan Canary dan Rollback

Terkadang ada gunanya menambahkan tingkat tipuan ke versi model. Daripada memberi tahu semua klien bahwa mereka harus menanyakan versi 42, Anda dapat menetapkan alias seperti "stable" ke versi mana pun yang saat ini harus ditanyakan oleh klien. Jika Anda ingin mengalihkan sebagian lalu lintas ke versi model canary tentatif, Anda dapat menggunakan alias kedua "canary".

Anda dapat mengonfigurasi alias atau label versi model ini, seperti:

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

Dalam contoh di atas, Anda menyajikan versi 42 dan 43, dan mengaitkan label "stable" dengan versi 42 dan label "canary" dengan versi 43. Anda dapat meminta klien mengarahkan kueri ke salah satu "stable" atau "canary" (mungkin berdasarkan hashing id pengguna) menggunakan bidang version_label buffer protokol ModelSpec , dan meneruskan label di server tanpa memberi tahu klien. Setelah Anda selesai membuat versi 43 dan siap untuk mempromosikannya ke versi stabil, Anda dapat memperbarui konfigurasi ke:

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

Jika nanti Anda perlu melakukan rollback, Anda dapat kembali ke konfigurasi lama yang memiliki versi 42 sebagai "stabil". Jika tidak, Anda dapat melanjutkan dengan membongkar versi 42 dan memuat versi baru 44 jika sudah siap, lalu memajukan label canary ke 44, dan seterusnya.

Harap perhatikan bahwa label hanya dapat ditetapkan ke versi model yang sudah dimuat dan tersedia untuk ditayangkan. Setelah versi model tersedia, seseorang dapat memuat ulang konfigurasi model dengan cepat untuk menetapkan label padanya. Hal ini dapat dicapai dengan menggunakan RPC HandleReloadConfigRequest atau jika server diatur untuk melakukan polling sistem file secara berkala untuk file konfigurasi, seperti dijelaskan di atas .

Jika Anda ingin menetapkan label ke versi yang belum dimuat (misalnya dengan menyediakan versi model dan label pada waktu startup) maka Anda harus menyetel tanda --allow_version_labels_for_unavailable_models ke true, yang memungkinkan label baru untuk ditugaskan ke versi model yang belum dimuat.

Harap dicatat bahwa ini hanya berlaku untuk label versi baru (yaitu label yang tidak ditetapkan ke versi saat ini). Hal ini untuk memastikan bahwa selama pertukaran versi, server tidak menetapkan label ke versi baru sebelum waktunya, sehingga membatalkan semua permintaan yang ditujukan untuk label tersebut saat versi baru sedang dimuat.

Untuk mematuhi pemeriksaan keamanan ini, jika menetapkan ulang label versi yang sudah digunakan, Anda harus menetapkannya hanya ke versi yang sudah dimuat. Misalnya, jika Anda ingin memindahkan label dari yang mengarah ke versi N ke versi N+1, Anda dapat terlebih dahulu mengirimkan konfigurasi yang berisi versi N dan N+1, lalu mengirimkan konfigurasi yang berisi versi N+1, labelnya menunjuk ke N+1 dan tidak ada versi N.

Penggunaan SISA

Jika Anda menggunakan permukaan REST API untuk membuat permintaan inferensi, alih-alih menggunakan

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

cukup minta versi menggunakan label dengan menyusun jalur permintaan Anda seperti itu

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

Perhatikan bahwa label versi dibatasi pada rangkaian karakter Word, terdiri dari karakter alfanumeral dan garis bawah (yaitu [a-zA-Z0-9_]+ ).

Konfigurasi Pemantauan

Anda dapat memberikan konfigurasi pemantauan ke server dengan menggunakan flag --monitoring_config_file untuk menentukan file yang berisi buffer protokol MonitoringConfig . Berikut ini contohnya:

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

Untuk membaca metrik dari URL pemantauan di atas, Anda harus mengaktifkan server HTTP terlebih dahulu dengan menyetel tanda --rest_api_port . Anda kemudian dapat mengonfigurasi Server Prometheus untuk menarik metrik dari Server Model dengan meneruskan nilai --rest_api_port dan path .

Tensorflow Serving mengumpulkan semua metrik yang ditangkap oleh Serving serta Tensorflow inti.

Konfigurasi Batch

Model Server memiliki kemampuan untuk mengelompokkan permintaan dalam berbagai pengaturan untuk mewujudkan throughput yang lebih baik. Penjadwalan batching ini dilakukan secara global untuk semua model dan versi model di server untuk memastikan pemanfaatan sumber daya yang mendasarinya sebaik mungkin, tidak peduli berapa banyak model atau versi model yang saat ini dilayani oleh server ( detail lebih lanjut ). Anda dapat mengaktifkan perilaku ini dengan menyetel flag --enable_batching dan mengontrolnya dengan meneruskan konfigurasi ke flag --batching_parameters_file .

Contoh file parameter batching:

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

Silakan merujuk ke panduan batching untuk diskusi mendalam dan lihat bagian parameter untuk memahami cara mengatur parameter.

Bendera Lain-Lain

Selain bendera yang dibahas sejauh ini dalam panduan ini, berikut kami mencantumkan beberapa bendera penting lainnya. Untuk daftar selengkapnya, silakan lihat kode sumbernya .

  • --port : Port untuk mendengarkan API gRPC
  • --rest_api_port : Port untuk mendengarkan HTTP/REST API
  • --rest_api_timeout_in_ms : Batas waktu untuk panggilan HTTP/REST API
  • --file_system_poll_wait_seconds : Periode saat server melakukan polling pada sistem file untuk versi model baru di masing-masing model_base_path model
  • --enable_model_warmup : Mengaktifkan pemanasan model menggunakan PredictionLogs yang disediakan pengguna di direktori aset.extra/
  • --mixed_precision=bfloat16 : Mengaktifkan Presisi Campuran Otomatis BF16