“Spotlight: NAVER Place, NVIDIA TensorRT-LLM ile SLM Tabanlı Dikey Hizmetleri Optimize Ediyor”

Naver, Kore’nin önde gelen arama motoru şirketlerinden biridir ve Naver Place adlı coğrafi tabanlı hizmeti sunmaktadır. Bu hizmet, kullanıcıların Kore’deki iş yerleri ve ilgi noktaları hakkında detaylı bilgi edinmelerine olanak tanır. Kullanıcılar farklı mekanları araştırabilir, yorum bırakabilir ve anlık olarak rezervasyon ya da sipariş verebilirler.

NAVER Place dikey hizmetleri, kullanıcı deneyimini artırmak amacıyla küçük dil modelleri (SLM) üzerinde temellendirilmiştir. Bu modeller, Harita ve Seyahat uygulamalarına yönelik uzmanlaşmıştır. Bu yazıda, NVIDIA ve NAVER‘ın, SLM tahmin performansını nasıl optimize ettiğine dair bilgiler paylaşılacaktır. Bunun için NVIDIA TensorRT-LLM kullanılarak, SLM tabanlı dikey hizmetlerin NVIDIA Triton Inference Server üzerinde nasıl çalıştırıldığını göreceksiniz. NAVER’in yapay zeka kullanımı hakkında daha fazla bilgi edinmek için NAVER Place AI Geliştirme Ekibi’ne Giriş yazısını okuyabilirsiniz.

NAVER Place Yorumları İçin Küçük Dil Modelleri

Küçük dil modelleri, büyük dil modelleri (LLM)‘ne göre daha az parametre ile doğal dili anlayabilen yapay zeka modelleridir. Uygun şekilde belirli alan görevlerine ince ayar yapıldıklarında, daha az bellek ve hesaplama gücü ile etkili sonuçlar vermek üzere bilinirler. NAVER Place, kullanıcılar tarafından bırakan yorumlardan oluşan kendi veri seti ile uyumlu şekilde özel SLM’lerini kullanarak, her bir yer hakkında özet veya mikro yorumlar sunmaktadır.

İlgili Ziyaretleri İlgi Noktaları ile Eşleştirme: SLM Dönüştürücü Kullanımı

NAVER Place, kayıtlı mekanlardan alınan fişler ve ödeme geçmişlerini toplayarak, her mekan için ziyaret ve yorumları gösterir. Bu amaçla, ziyaretleri ilgilenen yerler (POI) ile eşleştiren bir sistem sunmaktadır. Sistem, blog yazılarından yeni POI’lar keşfetme veya veri bütünlüğünü sağlamak için çifte POI kontrolü yaparak hizmet kalitesini artırmaktadır.

NVIDIA TensorRT-LLM ile Üstün Tahmin Performansı Sağlama

NVIDIA TensorRT-LLM, LLM’lerin NVIDIA GPU’lar üzerindeki tahmin performansını artırır ve optimize eder. Maksimum throughput sağlamak için uçuş sırasında toplu işlemeyi destekler ve bellek verimliliğini yükseltmek için sayfalı KV önbelleği ve parçalı bağlam gibi bellek optimizasyon yöntemleri kullanır.

NAVER Place, TensorRT-LLM’i benimsedi çünkü bu çözüm, diyelim ki geçerli diğer alternatif LLM tahmin çözümlerinden daha iyi performans sergiliyor. Hem throughput hem de ilk token için geçen zaman (TTFT) ve çıktı token’ı başına süre (TPOT) açısından kesinlikle daha üstün sonuçlar sunmaktadır. TensorRT-LLM, çeşitli girdi uzunlukları ve çıktı token senaryolarında sürekli olarak yüksek performans sergilemektedir.

Şekil 3, NVIDIA A100 ve H100 GPU’ları üzerinde çeşitli girdi ve çıktı token uzunlukları için popüler bir alternatif açık kaynak LLM tahmin kütüphanesi ile TensorRT-LLM arasında throughput karşılaştırması yapmaktadır.

TensorRT-LLM, tüm kodlama ön tanımlı yoğun, önceden doldurulmuş, yoğun kodlama ve yoğun kodlama ön tanımı ağır işlem modlarında alternatif kütüphaneden daha iyi performans gösterir. Bunlar arasında, SLM’lerle kullanılan yoğun kodlama modu en yüksek performansı sunmaktadır. Ayrıca, TensorRT-LLM, en yeni GPU’lar için optimize edilmiş çekirdekler sağladığı için NVIDIA Hopper mimarisi üzerinde de özellikle yüksek bir performans sergilemektedir.

TensorRT-LLM ile performans değerlendirmeleri hakkında daha fazla bilgi için performans genel tablosuına> bakabilirsiniz. TensorRT-LLM motorları oluşturmak için temel ayar teknikleri hakkında daha fazla bilgi için ise performansı en iyi şekilde ayarlama için en iyi uygulamalar yazısına göz atabilirsiniz.

Tahmin Optimizasyonu: Üst Üste Aşama ve Gecikme Arasındaki Denge

Bu bölüm, LLM tahmin işlemlerinde throughput ve gecikme arasındaki dengeyi sağlamak için farklı stratejileri incelemektedir. Bu stratejiler, toplu işlem boyutu ve bellek optimizasyon teknikleri gibi yöntemleri içermektedir.

Toplu İşlem Boyutu

Bir LLM tahmin sunucusu, talepleri topluca işleyerek maksimum throughput sağlar. Ancak bu, aynı zamanda yüksek gecikmelere yol açabilir. Yani, daha büyük bir toplu işlem boyutu daha yüksek throughput sağlarken, cevap sürelerini artırabilir; bu nedenle, kullanıcı deneyimi ile verimlilik arasında dikkatle bir denge kurulmalıdır. Toplu işlem boyutunu, hedef TTFT ve TPOT’a göre dikkatlice ayarlayarak, sisteminizin performansını belirlediğiniz hizmet gereksinimleriyle uyumlu hale getirebilirsiniz.

Sayfalı KV Önbelleği ve Uçuşta Toplu İşlem

TensorRT-LLM, bellek verimliliğini artırmak için varsayılan olarak etkinleştirilen sayfalı KV önbelleği seçeneği sunar. Bu, gecikme gereksinimi olan ve yüksek throughput gerektiren görevler için üst-bulunma boyutunu artırarak modeli ölçeklendirmeye yardımcı olur. Bu varsayılan ayar, aşırı hızlı, gerçek zamanlı talepler ile daha yüksek throughput gerektiren büyük işleme senaryolarını karşılayarak daha esnek ve dayanıklı bir çözüm sağlamaktadır.

TensorRT-LLM’deki uçuşta toplu işleme de varsayılan olarak etkinleştirilmiştir ve throughput’u artırmaktadır. NAVER ekibi, çoğu iş için bu iki seçeneği varsayılan olarak kullanmaktadır. Ancak gerçek zamanlı, düşük gecikmeli bir hizmet gerektiren küçük bir model ve eski GPU’lar için bazı durumlar bu iki seçeneği devre dışı bırakmayı gerektirebilir. Örneğin, POI eşleştirme işlemleri, talep edilen tüm işlemlerin gerçek zamanlı olarak gerçekleştirilmesini gerektirdiği için en düşük gecikmeyi sağlamalıdır.

Bunun yanı sıra, 1.3 milyar parametreli daha küçük bir model kullanıldığında ve toplu işlem boyutu 1 olarak belirlendiğinde sayfalı KV önbelleğinin kullanılması, bellek gereksinimi neredeyse sıfıra düştüğü için daha yüksek gecikme ve azaltılmış QPS ile sonuçlanmaktadır. Bu durumu çözmek için, NAVER ekibi, bellek yükü sorunlarına neden olmasına rağmen, sayfalı KV önbelleğine kıyasla sürekli KV önbelleğini tercih etmiştir. Bu seçim, POI eşleştirme gibi gerçek zamanlı gereksinimlerin karşılanmasına olanak tanımıştır.

POI eşleştirme, düşük gecikme gerektirdiğinden dolayı arka planda yüksek throughput sağlamalıdır. Bu nedenle, her bir iş için farklı yapılandırma seçenekleri uygulamaktayız.

"build_config": {
        "max_input_len": 512,
        "max_output_len": 32,
        "max_batch_size": 1,
        "max_beam_width": 1,
        "max_num_tokens": 4096,
        ...
        "plugin_config": {
            ...
            "paged_kv_cache": false,
            ...
        }
    }

"build_config": {
        "max_input_len": 512,
        "max_output_len": 32,
        "max_batch_size": 8,
        "max_beam_width": 1,
        "max_num_tokens": 4096,
        ...
        "plugin_config": {
            ...


            "paged_kv_cache": true,
            ...
        }
    }

Tahmin Optimizasyonu: Aşağı Akış Önbelleği

Bu bölüm, önbellekleme tekniklerini kullanarak aşağı akış tahmin görevlerini optimize eden stratejileri incelemektedir. Öncelikle, ön ek ve yanıt önbelleklemenin nasıl gereksiz hesaplamaları azaltabileceği ve genel verimliliği artırabileceği ele alınmaktadır.

Ön Ek Önbellekleme

Aşağı akış görevleri tarafından üretilen istemlerin sık sık ortak bir öne sahip olduğu dikkate alındığında, her bir talep için tüm ön doldurmayı hesaplamak kaynak israfıdır. Bunu önlemek amacıyla, TensorRT-LLM ön ek önbellekleme seçeneği sunmaktadır. Bu, bellek kullanımını ve hesaplama yükünü önemli ölçüde azaltabilir. Daha fazla bilgi için KV önbellek yeniden kullanımı talimatlarına göz atabilirsiniz.

Bu yaklaşım, TTFT’nin önemli ölçüde artırılmasına yardımcı olmaktadır ve uzun girdi uzunluklarına, ortak sistem istemlerine ve kısa çıktı uzunluklarına sahip görevler için idealdir. Özellikle mikro yorumlar için etkili bir şekilde çalışmaktadır. Çünkü bir mikro yorumun üretilmesi ortalama 40 adımda gerçekleşmektedir ve her adım ortak öne dayanmaktadır.

Ancak, ön ek önbellekleme, yüksek çeşitlilikteki sistem istemlerine sahip görevlerde daha düşük önbellek performansı ve yüksek yönetim yükü gibi verimliliği etkileyen durumlarla karşılaşabilir.

Yanıt Önbellekleme

Yanıt önbellekleme, NVIDIA Triton Inference Server’ın bir özelliği olup, gereksiz ve tekrarlayan tahminlerden kaçınmaya yardımcı olmaktadır. Triton, yanıt önbelleğini, tahmin isteği için model adı, sürümü ve girişler ile birlikte bir karma kullanarak erişmektedir. Yanıt önbellekleme, çoklu örnekleme kodlaması gibi yeniden tahminlerin gerekmeyen durumlar haricinde etkilidir. POI eşleştirmede, gerçek zamanlı olarak dört beş önbellek vuruşu gerçekleşerek hesaplama yükü %17 oranında azaltılmaktadır.

Triton ile TensorRT-LLM Sunumu

Bir SLM motoru, Triton Inference Server üzerinde sunulmaktadır. Triton, modelikenlerini bir dizi token, postişleme veya çok adımlı tahmin yapma sürecini birleştirme özelliği sunar. NAVER Place, bu esnekliği sağladığı için BLS (Business Logic Scripting) özelliğini tercih etmiştir. Bu bölüm, NAVER Place’ın Triton BLS’nin avantajlarını ve kullanılabilirliğini nasıl artırdığını ele almaktadır.

İyi Tanımlanmış İstem/Cevap Şeması ile Kullanılabilirliği Artırma

Triton modelleri verileri pb_tensor formatında değiş tokuş etmektedir. Seçilen BLS yapısı, iletişim verimliliği ve LLM tahmin optimizasyonunu sağlamak amacıyla ön işleme ve son işleme kodlarını içerir. Her modelin veri türünü pb_tensor formatında NumPy dizisine ve geri dönerek pb_tensor formatında döndürmek zorluğu taşımaktadır.

Bu süreçte iki ana sorun ortaya çıkmaktadır. Birincisi, her modelin girdi/çıktı verilerinin doğrulanmaması durumunda hata ayıklama zorluğu yaşanmaktadır çünkü geçersiz veri formatları veya eksik alanlar, yalnızca çalışma zamanında tespit edilmektedir. İkincisi, ön işleme ve son süreçleri BLS içinde birleştirmek, kodu daha karmaşık hale getirebilir ve genişletmeyi zorlaştırabilir.

Tüm bu zorluklar, çok sayıda modelin birbiriyle zincirlenerek çalıştığı durumlarda, runtime hatalarını azaltmak ve kodun yönetimini kolaylaştırmak için iyi tanımlanmış bir istem/cevap şemasının önemini vurgulamaktadır.

Girdi/Çıktı Şeması Yönetimini Standartlaştırma

NVIDIA Python veri sınıfları baz alınarak, Pydantic kullanarak IO şemaları tanımlanmıştır. Bu, tüm Triton modellerinin istek ve yanıtları arasındaki yapısal tutarlılığı sağlarken veri doğruluğunu da artırmaktadır. Erken aşamada iyi tanımlanmış bir şema kullanarak, geliştiriciler veri sorunlarını daha kolay tespit edebilirler ve verilerin tutarlı bir şekilde akmasını sağlanabilir.

Örneğin, Triton isteklerinin girdi veri formatlarını yönetmek ve doğrulama işlemini gerçekleştirmek için bir BlsRequest sınıfı tanımlanmıştır ve aşağıda yer almaktadır:

# NOT: Triton, pb_tensor ve Numpy nesneleri kullandığı için
# Python varsayılan türlerinde tanımlanmış olmayan alanları yönetsel olarak tanımlamak gereklidir.
# Bu nedenle, alan türlerini açıkça yönetmek için Pydantic'in json_schema_extra alanını ekledik.
class BlsRequest(TritonFieldModel):
      name: Optional[str] = Field(None, json_schema_extra={'data_type': "TYPE_STRING"})
      subname: Optional[str] = Field(None, json_schema_extra={'data_type': "TYPE_STRING"})
      biznum: Optional[str] = Field(None, json_schema_extra={'data_type': "TYPE_STRING"})
      address: Optional[List[str]] = Field(None, json_schema_extra={'data_type': "TYPE_STRING"})
      tel: Optional[List[str]] = Field(None, json_schema_extra={'data_type': "TYPE_STRING"})
      @root_validator(pre=True)
      def check_all_fields_empty(cls, values):
          if not any(bool(v) for v in values.values()):
              raise ValidationError("Tüm alanlar boş olamaz", model=cls.__name__)

Model Başına Girdi/Çıktı Tür Dönüşümünü Modülerleştirme

Her bir model için IO veri dönüşüm sürecini kapsülleyerek, pb_tensor ve Pydantic arasında dönüşüm yapmak amacıyla ortak bir işlev oluşturulmuştur. Bu, modelleri tutarlı bir şekilde çağırmayı sağlar ve iç veri dönüşüm süreçleri için ise herhangi bir endişe yaşanmaz.

Aşağıda, bir Pydantic İstek nesnesini alan, Triton pb_tensor formatına çeviren ve bir model tahmini sonucunu Pydantic Cevap nesnesi olarak döndüren bir işlev örneği yer almaktadır:

def _infer_model(self, request_model, response_model_cls, model_name, request_model, **infer_kwargs):
     # Pydantic İsteğini Triton pb_tensor’a çevirir.
     pb_tensors = self.convert_pydantic_to_pb_tensors(request_model, batch_inference)
     # Model tahminini gerçekleştirir.
     infer_request = pb_utils.InferenceRequest(
         model_name=model_name,
         inputs=pb_tensors,
         requested_output_names=response_model_cls.get_field_names(),
         **infer_kwargs,
     )
     infer_response = infer_request.exec()
     # Triton Cevabını (pb_tensor) Pydantic Cevap formatına çevirir.
     return self.convert_pb_tensors_to_pydantic(response, response_model_cls)

Aşağıdaki kod örneği, _infer_model işlevini kullanarak bir modeli çağırır. Sadece GeneratorRequest ve GeneratorResponse sınıflarını tanımlamak yeterlidir ve karmaşık veri dönüşüm veya model çağırma işlemleri ile ilgili herhangi bir kaygı taşımak zorunda kalmazsınız.

def infer_generator(self, request, text_input, max_tokens):
      response_model_cls = schema.GeneratorResponse
      request_model = schema.GeneratorRequest(text_input=text_input, max_tokens=max_tokens)
      return self._infer_model(
          request=request,
          model_name="generator_bls",
          request_model=request_model,
          response_model_cls=response_model_cls,
      )

BLS İş Mantığını Modülerleştirme ve Test Edilebilirliği Artırma

NAVER ekibi, iş mantığını ve BLS içindeki ön işleme ile son işleme kodunu modüler hale getirerek daha düşük bir bağımlılık sağladılar. Bu, kodu karmaşık hale getirmeden test edilebilirliği ve bakım ömrünü artırmıştır.

• Ön işleme ve son işlemenin modüler hale getirilmesi ve birim testlerinin tanıtılması
  • Model eğitimine yönelik iş mantığını ve ön işleme ile son işleme kodunu modülerleştirilmiştir.
  • Test kodları, Triton çalışma zamanı olmadan, bağımsız bir Python çalışma süresinde çalışacak şekilde tasarlanmıştır. Bu sayede, her model için ön işleme ve son işlem doğrulaması gerçekleştirilebilir.
• BLS’nin rollerinin yeniden tanımlanması
  • BLS, yalnızca model çağrısı ve uçtan uca test için sorumlu hale getirilmiştir. Bu, yeni gereksinimler eklense bile sisteme minimum etki sağlayarak BLS kodunun etkisini azaltmıştır.
• Sürekli Entegrasyon Durumu
  • İş mantığı ile ön işleme ve son işleme kodları için bir CI test süreci oluşturulmuştur. Bu, model eğitim sürecinde yapılan değişikliklerin, hizmeti etkilememesini sağlamak için hızlı bir doğrulama imkanı sağlar. CI sürecine bu testlerin entegre edilmesi, sorunların daha erken tespitini ve hızlı bir şekilde çözüm yolunu sağlar.

Bu yaklaşım sayesinde, veri doğruluğunu artırmayı, kodun bakımını ve geliştirme verimliliğini artırmayı, sonuç olarak Triton tabanlı LLM sunum geliştirmede verimliliği artırmayı başardık.

Sonuç

NAVER Place, NVIDIA TensorRT-LLM kullanarak LLM motorlarını optimize etmeyi başarmış ve NVIDIA Triton Inference Server‘ın kullanılabilirliğini artırmıştır. Bu optimizasyon sayesinde, ekip GPU kullanımını da en üst düzeye çıkararak genel sistem verimliliğini artırabilmiştir. Tüm bu süreç, SLM tabanlı dikey hizmetleri optimize ederek NAVER Place’ı kullanıcı dostu hale getirmiştir. Bu deneyim üzerine, ekibimiz yeni dikey modeller geliştirmeye ve bunları hizmetlerimize uygulamaya devam edecektir.

Başlamak için NVIDIA TensorRT-LLM ve NVIDIA Triton Inference Server‘ı keşfedin.