「機械学習」カテゴリーアーカイブ

決定木アンサンブルモデルのデプロイを容易にするライブラリtreeliteの紹介(2)

技術開発部の安井です。前回に引き続き、treeliteの紹介をしたいと思います。今回はtreeliteの予測速度について検証しようと思います。ドキュメント上では2~6倍のスループットが出ると書かれています。この点に関して実際にpython上とgolang上の2つの言語環境で検証しようと思います。

使用データと学習について

今回予測速度を検証する際に使用するデータはAvazuのclick予測のデータセットを使用します。全データ使用すると学習に時間がかかるので、300万件のデータのみを使用して学習を行います。Avazuのデータセットは変数がすべてカテゴリカル変数になっています。今回はこれらの変数をFeeatureHasherを使用して特徴量に変換します。今回FeatureHasherを使用する理由は後述します。FeatureHasherの次元数として今回は16、64、256次元でそれぞれ検証を行います。学習には前回に引き続きLightGBMを使用し、num_boost_roundを100で設定します。これで弱学習器として決定木が100本生成されることになります。学習するときに使用したコードを以下に記述します。

#! /usr/bin/env python
    
import sys
import pandas as pd
import lightgbm as lgb
import treelite
import treelite.runtime
from sklearn.feature_extraction import FeatureHasher
from sklearn.model_selection import train_test_split

train = pd.read_csv('input/train', nrows=4000000)
    
dim = int(sys.argv[1])
fh = FeatureHasher(dim)
X = fh.transform(train.drop(['id', 'click'], axis=1).to_dict('records'))
y = train['click']
    
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.25, random_state=47)
dtrain = lgb.Dataset(X_train, label=y_train)
dtest = lgb.Dataset(X_test, label=y_test)
    
params = {
    'objective': 'binary',
    'metric': 'auc',
    'boosting': 'gbdt',
    'learning_rate': 0.01,
    'seed': 47,
}
    
bst = lgb.train(
    params,
    dtrain,
    num_boost_round=100,
    valid_sets=[dtrain, dtest],
    valid_names=['train', 'test'],
)
lgb_preds = bst.predict(X_test)
    
bst.save_model(f'fh_lgb_dim_{dim}.model')
    
model = treelite.Model.load(f'fh_lgb_dim_{dim}.model', model_format='lightgbm')
model.export_lib(toolchain='gcc', libpath=f'./fh_lgb_dim_{dim}.so', verbose=True)
    
pd.DataFrame(X_test.toarray(), columns=['var_{}'.format(i + 1) for i in range(dim)]).to_csv(f'X_test_fh_dim_{dim}.csv', index=False)

#! /usr/bin/env python

import sys

import pandas as pd

import lightgbm as lgb

import treelite

import treelite.runtime

from sklearn.feature_extraction import FeatureHasher

from sklearn.model_selection import train_test_split

train = pd.read_csv('input/train', nrows=4000000)

dim = int(sys.argv[1])

fh = FeatureHasher(dim)

X = fh.transform(train.drop(['id', 'click'], axis=1).to_dict('records'))

y = train['click']

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.25, random_state=47)

dtrain = lgb.Dataset(X_train, label=y_train)

dtest = lgb.Dataset(X_test, label=y_test)

params = {

'objective': 'binary',

'metric': 'auc',

'boosting': 'gbdt',

'learning_rate': 0.01,

'seed': 47,

}

bst = lgb.train(

params,

dtrain,

num_boost_round=100,

valid_sets=[dtrain, dtest],

valid_names=['train', 'test'],

)

lgb_preds = bst.predict(X_test)

bst.save_model(f'fh_lgb_dim_{dim}.model')

model = treelite.Model.load(f'fh_lgb_dim_{dim}.model', model_format='lightgbm')

model.export_lib(toolchain='gcc', libpath=f'./fh_lgb_dim_{dim}.so', verbose=True)

pd.DataFrame(X_test.toarray(), columns=['var_{}'.format(i + 1) for i in range(dim)]).to_csv(f'X_test_fh_dim_{dim}.csv', index=False)

pythonでの予測速度比較

まずはじめにpythonでの予測速度の比較を行います。予測速度は以下の3パターンのデータ量で比較を行います。

instance: 1件
batch: 1,000件
big batch: 1,000,000件

予測速度は複数回予測したときの平均時間を記載しています。

16次元の場合

lightgbm instance:  0.00010517575740814209s
treelite instance:  0.00003566386699676514s
lightgbm batch:     0.0007027374267578125s
treelite batch:     0.0003089529752731323s
lightgbm big batch: 0.6247398257255554s
treelite big batch: 0.2774349188804626s

lightgbm instance: 0.00010517575740814209s

treelite instance: 0.00003566386699676514s

lightgbm batch: 0.0007027374267578125s

treelite batch: 0.0003089529752731323s

lightgbm big batch: 0.6247398257255554s

treelite big batch: 0.2774349188804626s

16次元の場合、treeliteの方がおおよそ1/2~1/3の時間で予測ができており、概ねドキュメントの記載の通りであることが見受けられます。

64次元の場合

lightgbm instance:  0.0001033491849899292s
treelite instance:  0.00009161360263824462s
lightgbm batch:     0.0007573297739028931s
treelite batch:     0.00035665130615234375s
lightgbm big batch: 0.79298579454422s
treelite big batch: 0.32156704187393187s

lightgbm instance: 0.0001033491849899292s

treelite instance: 0.00009161360263824462s

lightgbm batch: 0.0007573297739028931s

treelite batch: 0.00035665130615234375s

lightgbm big batch: 0.79298579454422s

treelite big batch: 0.32156704187393187s

64次元の場合、バッチ予測の場合は16次元と同様にtreeliteの方がおおよそ1/2~1/3の時間で予測ができています。しかし、instance予測の場合lightgbmとtreeliteの予測速度はそこまで差がないように見受けられます。

256次元の場合

lightgbm instance:  0.00010415022373199463s
treelite instance:  0.0003009482145309448s
lightgbm batch:     0.0011013625144958496s
treelite batch:     0.00042464187145233154s
lightgbm big batch: 1.5125486660003662s
treelite big batch: 0.38220595598220825s

lightgbm instance: 0.00010415022373199463s

treelite instance: 0.0003009482145309448s

lightgbm batch: 0.0011013625144958496s

treelite batch: 0.00042464187145233154s

lightgbm big batch: 1.5125486660003662s

treelite big batch: 0.38220595598220825s

256次元の場合、バッチ予測の場合はtreeliteの方が1/3~1/4の時間で予測ができており、treeliteの効果が最も出ていると考えられます。対象的に、instance予測の場合はtreeliteの方が予測に3倍の時間がかがっていることがわかります。

まとめ

バッチ予測の場合は概ね期待している効果が出ていますが、インスタンス予測の場合は予測する特徴量のサイズが増えるほどの効果が出ないばかりか、悪化する場合も存在します。これに関してはtreelite側のメソッドがバッチ予測の場合とインスタンス予測の場合で異なることが原因として考えられます。

バッチ予測: treelite.Predictor.predict(batch, verbose=False, pred_margin=False)
インスタンス予測: treelite.Predictor.predict_instance(inst, missing=None, pred_margin=False)

この2つの違いに関してですが、batchの方はtreelite側で処理をしやすいようなデータ型を期待していますが、instの方ではnumpy.ndarrayやscipy.sparse.csr_matrix等のarray objectを期待しています。この差により予測速度に差が出ているのではないかと想像していますが、詳しくは引き続き調査を続けていきたいと思います。

golangでの予測速度比較

golangでの予測速度比較にはtreeliteで生成したモデルコードの予測と以下のGBDT予測ライブラリの予測での速度比較を行います。

dmitryikh/leaves

このライブラリはXGBboost/LightGBm/scikit-learnで学習したGBDTのモデルをロードしてgolang上で予測を行えるようにしたライブラリです。こちらはインスタンス予測のみを比較することとします。以下がgolanで測定したベンチマークの結果です。

16次元の場合
$ go test -bench . -benchmem
goos: linux
goarch: amd64
pkg: treelite_bench/dim16
BenchmarkPredictTreelite-8       2000000               849 ns/op              64 B/op          1 allocs/op
BenchmarkPredictLeaves-8          500000              3655 ns/op               8 B/op          1 allocs/op
PASS
ok      treelite_bench/dim16       4.426s

64次元の場合
$ go test -bench . -benchmem
goos: linux
goarch: amd64
pkg: treelite_bench/dim64
BenchmarkPredictTreelite-8       2000000               637 ns/op             256 B/op          1 allocs/op
BenchmarkPredictLeaves-8          500000              3546 ns/op               8 B/op          1 allocs/op
PASS
ok      treelite_bench/dim64       3.717s

256次元の場合
$ go test -bench . -benchmem
goos: linux
goarch: amd64
pkg: treelite_bench/dim256
BenchmarkPredictTreelite-8       2000000               890 ns/op            1024 B/op          1 allocs/op
BenchmarkPredictLeaves-8          300000              4220 ns/op               8 B/op          1 allocs/op
PASS
ok      treelite_bench/dim256       3.981s

16次元の場合

$ go test -bench . -benchmem

goos: linux

goarch: amd64

pkg: treelite_bench/dim16

BenchmarkPredictTreelite-8 2000000 849 ns/op 64 B/op 1 allocs/op

BenchmarkPredictLeaves-8 500000 3655 ns/op 8 B/op 1 allocs/op

PASS

ok treelite_bench/dim16 4.426s

64次元の場合

$ go test -bench . -benchmem

goos: linux

goarch: amd64

pkg: treelite_bench/dim64

BenchmarkPredictTreelite-8 2000000 637 ns/op 256 B/op 1 allocs/op

BenchmarkPredictLeaves-8 500000 3546 ns/op 8 B/op 1 allocs/op

PASS

ok treelite_bench/dim64 3.717s

256次元の場合

$ go test -bench . -benchmem

goos: linux

goarch: amd64

pkg: treelite_bench/dim256

BenchmarkPredictTreelite-8 2000000 890 ns/op 1024 B/op 1 allocs/op

BenchmarkPredictLeaves-8 300000 4220 ns/op 8 B/op 1 allocs/op

PASS

ok treelite_bench/dim256 3.981s

BenchmarkPredictTreelite-8がtreeliteで予測した場合のベンチマークで、BenchmarkPredictLeaves-8がleavesで予測した場合のベンチマークです。 treeliteの予測モデルのほうが1/4~1/6の時間で予測が行えれていることがわかります。これを見ると動的にロードしたleavesの予測モデルより、はじめに実行バイナリに組みこんでおいたtreeliteの予測モデルのほうがパフォーマンスが良いことがわかります。

treelite使用上の注意

冒頭でも述べましたが今回はカテゴリカル変数をFeatureHasherを使用して学習するときに使用する特徴量を作成しました。しかし、LightGBMではカテゴリカル変数をそのまま特徴量として入力することができるようになっています。(厳密にはint型のidへの変換は必要) 今回カテゴリカル変数をそのまま学習に用いなかった理由としてはLightGBMでカテゴリカル変数を使用して学習を行うとtreeliteの予測結果と異なってしまうという事象が発生したためです。しかし、現在では以下のissueによってこの問題も解決されたようです。

https://github.com/dmlc/treelite/issues/77

実際手元の環境でカテゴリカル変数を用いた場合でもLightGBMの予測モデルとtreeliteの予測モデルの結果が一致することを確認しました。古いバージョンのtreeliteを使用する場合はご注意ください。

さいごに

今回はtreeliteの予測速度性能に関してpython, golang上で比較を行いました。 golangでの予測、pythonでのバッチ予測に関してはスピードアップしていることが確認できました。最近は予測に特化したライブラリが他にも出てきているので実環境に組み込むといった観点でこういった予測に特化したライブラリもチェックしていきたいと思います。

決定木アンサンブルモデルのデプロイを容易にするライブラリtreeliteの紹介(1)

はじめまして。技術開発部の安井です。現在は弊社で運営しているDSPにおける広告効果の分析や機械学習モデルの構築/運用を行なっています。

DSPと機械学習

詳細なDSPに関する説明は省きますが、DSPではSSPから受け取った広告リクエストに対して以下の事項を決定して広告オークションにおける入札応答を行わなければいけません。

入札可能な広告の内、どの広告で入札を行うのか
いくらで入札を行うのか

入札する広告、金額を決定にはクリック率、コンバージョン率等の広告リクエストに対する実際のパフォーマンスの値をを活用しています。これらの広告パフォーマンスを入札サーバ上で予測するために弊社では機械学習モデルを活用しています。しかし、DSPにおける機械学習モデルの活用には以下のようなハードルが存在します。

入札サーバを構築しているプログラムと機械学習モデルを学習しているプログラムでは使用しているプログラミング言語が異なる
SSPへの入札応答にはシビアな時間制約が存在する

これらを解決するための方法として今回はtreeliteというライブラリをご紹介します。

treelite

treeliteとは近年巷でよく使われているXGBoostやLightGBM等のGBDTの実装ライブラリやscikit-learnに実装されているRandomForestRegressor(Classifier)、GradientBoostingRegressor(Classifier)等のいわゆる決定木をアンサンブルしているモデルのデプロイを容易にするためのライブラリになっています。加えて、モデルが直接Cコードとして吐き出されるため、推論時間の高速化も期待できる実装となっています。開発は以下のリポジトリで行われています。

dmlc/treelite

Referenceはこちら

Treelite: toolbox for decision tree deployment

treeliteを用いたモデルのデプロイのオプションとして次の3つのオプションが示されています。

1.デプロイターゲットのマシンにtreeliteをインストールする

こちらはデプロイ先のマシンにtreeliteをインストールしておくシンプルな方法です。ゆえにデプロイ先のマシンにpythonがインストールされている必要があります。

2.デプロイターゲットのマシンにランタイムパッケージと一緒にデプロイする

treeliteではランタイムパッケージをアウトプットすることができます。このランタイムパッケージをデプロイプロセスで同時にターゲットマシンにデプロイすることで、モデルを使用できるようにする方法です。こちらもデプロイ先のマシンにpythonがインストールされている必要があります。

3.モデルとなるCコードのみデプロイする

こちらはCコードとしてアウトプットされたモデルのみをターゲットマシンに送る方法です。 Cコードに変換されたモデルは以下のインタフェースから予測値を取得できます。

float predict(union Entry* data, int pred_margin);

1	float predict(union Entry* data, int pred_margin);

dataが予測を行うときに必要となる特徴量の集合で、pred_marginはモデルがアウトプットした値をシグモイド関数に通すか通さないかというフラグとなっています(2値分類タスクの場合)。union Entryに関しては以下のように定義されており、特徴量が存在しない場合はmissingに-1が設定されており、特徴量が存在する場合はfvalueに値が格納されている状態を定義します。qvalueに関しては現状使われていないように見受けられます。

union Entry {
  int missing;
  float fvalue;
  int qvalue;
};

union Entry {

int missing;

float fvalue;

int qvalue;

};

golangでのtreeliteモデルの使用方法

上記3種類のデプロイ方法のうち、3番目のCコードのみをデプロイする方法であればpredict関数とのつなぎ込みの部分さえ実装すればpython以外の言語でもアンサンブルモデルを使用できます。弊社の入札サーバではgolangが採用されており、cgoを使うことでアンサンブルモデルのつなぎ込みを実現することができます。今回はLightGBMのモデルをtreeliteのモデルに変換し、golangから参照する部分までご紹介します。まずは、LightGBMのモデルを読み込みtreeliteのモデルをアウトプットする部分です。LightGBMのモデルはlgb.modelというファイルに保存されていることとします。

#! /usr/bin/env python
    
import treelite
    
model = treelite.Model.load('lgb.model', model_format='lightgbm')
model.export_lib(toolchain='gcc', libpath='./lgb.so', verbose=True)
model.export_srcpkg(platform='unix', toolchain='gcc',
                    pkgpath='./lgb.zip', libname='lgb.so',
                    verbose=True)

#! /usr/bin/env python

import treelite

model = treelite.Model.load('lgb.model', model_format='lightgbm')

model.export_lib(toolchain='gcc', libpath='./lgb.so', verbose=True)

model.export_srcpkg(platform='unix', toolchain='gcc',

pkgpath='./lgb.zip', libname='lgb.so',

verbose=True)

5行目のloadでLightGBMのモデルを読み込み6行目で共有ライブラリに変換を行います。その後、7行目で変換した共有ライブラリから必要なヘッダーとCコード、メタ情報を抽出し、zipファイルにまとめます。デフォルトだとzipファイルには以下のファイルがまとめられています。

header.h
main.c
Makefile
recipe.json

header.h

main.c

Makefile

recipe.json

header.hとmain.cが実際のモデル部分でそれらをコンパイルフローがMakefileにまとまっています。recipe.jsonにはモデルコードのメタ情報が格納されています。それではこれらのモデルをgolangから参照できるようにしましょう。コードはこちらとなります。

package main

//#cgo LDFLAGS: -lm
//#include "header.h"
import "C"
import (
    "encoding/binary"
    "fmt"
    "github.com/dmitryikh/leaves"
    "math"
    "unsafe"
)

func float32ToByteArray(flt float32) [4]byte {
    b := make([]byte, 4)
    binary.LittleEndian.PutUint32(b, math.Float32bits(flt))
    return *(*[4]byte)(unsafe.Pointer(&b[0]))
}

func predictTreelite(fvals []float32) float32 {
    cfvals := [16][4]byte{}
    for i, fval := range fvals {
        cfvals[i] = float32ToByteArray(fval)
    }
    p := C.predict(&cfvals[0], C.int(0))
    return float32(p)
}

func main() {
    fvals32 := make([]float32, 16)
    fmt.Println(predictTreelite(fvals32))
}

package main

//#cgo LDFLAGS: -lm

//#include "header.h"

import "C"

import (

"encoding/binary"

"fmt"

"github.com/dmitryikh/leaves"

"math"

"unsafe"

)

func float32ToByteArray(flt float32) [4]byte {

b := make([]byte, 4)

binary.LittleEndian.PutUint32(b, math.Float32bits(flt))

return *(*[4]byte)(unsafe.Pointer(&b[0]))

}

func predictTreelite(fvals []float32) float32 {

cfvals := [16][4]byte{}

for i, fval := range fvals {

cfvals[i] = float32ToByteArray(fval)

}

p := C.predict(&cfvals[0], C.int(0))

return float32(p)

}

func main() {

fvals32 := make([]float32, 16)

fmt.Println(predictTreelite(fvals32))

}

ディレクトリ構成は以下のようになっていることを想定しており、こちらのコードはmain.goに記述されています。

.
├── main.go
├── header.h
└── main.c

├── main.go

├── header.h

└── main.c

こちらのコードは16次元のベクトルを受け取り0~1までの確率値を返すモデルを想定しています。予測を行う関数はfunc predictTreelite(fvals []float32) float32ですがまず最初に受け取ったベクトルをバイナリ列の配列に変換しています。これはunion Entryを表現するための型がgolang側に存在しないためこのような形を取っています。今回はベクトルの中にmissingが存在しない想定で実装がされていますが、missingが存在しうる場合は-1のバイナリ列を代わりに入れてあげるようにします。このようにしてバイナリ列の配列に変換されたベクトルをモデルファイルのpredictに渡してあげることでモデルの予測値を獲得します。実際にビルドして実行すると以下のように0~1までの確率値が出力されます。

$ ./predict
0.3820182

1 2	$ ./predict 0.3820182

さいごに

今回はtreeliteでLightGBMで学習されたモデルをtreeliteのモデルに変換して、golangから参照するところまで紹介しました。次回はtreeliteのモデルとLightGBMのモデルとの予測速度比較、golangから参照したtreeliteモデルとgolangで記述されたアンサンブルモデル予測ライブラリleavesとの予測速度比較を行いたいと思います。

treeliteのドキュメント