Servis özeti — bir modelin reposu nasıl servis edileceği hakkında ne diyor
Bir model reposunda config.json'dan fazlası var. Sohbet şablonu araç çağırmayı ve düşünmeyi, generation_config.json örnekleme varsayılanlarını ve yanıtın nerede bittiğini belirler; tensör adları da neyin gerçekten quantize edildiğini ve çoklu token tahmin (MTP) katmanlarının gelip gelmediğini gösterir. Bir model seç: bu sayfa o dosyaları tarayıcında okur, bir kurulumun takılacağı yerleri işaretler ve gereken vLLM ve SGLang bayraklarını yazar.
Reposunu okumak için bir model seç
Ya da bunlardan biriyle başla:
Bir model seçildiğinde bu sayfa şunları cevaplar:
- Bu repoda ne var?
- Nasıl sohbet ediyor — araçlar, düşünme, görseller?
- Hangi örnekleme ayarlarıyla geliyor?
- Ağırlıklar nasıl saklanmış?
- Kendi token taslağını çıkarabiliyor mu (MTP)?
- Ne kadar uzun bir context için yapılandırılmış?
- Yüklemek için ne gerekiyor?
Repo nasıl okunuyor
Sayfa bir repoyu, bir motorun yüklemeden önce okuduğu gibi okur: dosya listesini ve boyutlarını Hugging Face API'sinden; repoda varsa config.json, generation_config.json, tokenizer_config.json ya da chat_template.jinja, hf_quant_config.json, adapter_config.json ve params.json dosyalarını; ve tensör adlarını, model.safetensors.index.json'dan ya da tek dosyalı bir modelde safetensors başlığından. Başlık, dosyayı indirmek yerine iki küçük aralıklı (Range) istekle okunur. Hepsi tarayıcında çalışır.
Bir bayrak yalnız vLLM 0.31.0 ya da SGLang 0.5.21 onu belgelerinde ya da parser kayıtlarında adlandırıyorsa yazılır; ikisinin de adlandırmadığı bir model ailesi tahmin yerine bayraksız kalır. MTP desteği, her motorun taslak modelini kurduğu koddan okunur. Bellek, paralellik ve batch ayarları boyutlandırma ve vLLM sayfalarına bırakılır.
Sık sorulanlar
- MTP nedir, tensörleri neden kontrol ediyoruz?
- Çoklu token tahmin (MTP) katmanları, bir sonraki token'dan daha ilerisini tahmin etmek için eğitilmiş ek katmanlardır. vLLM ve SGLang onları spekülatif decoding'de yerleşik bir taslak model olarak kullanabilir. config.json yalnız kaç tane olması gerektiğini söyler ve quantize edilmiş kopyalar bazen onları atar: DeepSeek-V3'ün AWQ kopyası bir MTP katmanı bildiriyor ama özgün modelde o katmana ait 1.564 tensörün hiçbiri onda yok. Sayfa bu yüzden tensör adlarına bakıyor.
- generation_config.json neden önemli?
- vLLM ve SGLang varsayılan temperature, top_p ve top_k değerlerini ve bir yanıtı bitiren token'ları ondan alır. Qwen3'ünki, config.json'un bir tane saydığı yerde iki bitiş token'ı sayar; gpt-oss'unki iki tane ekler. vLLM, oradaki bir max_new_tokens değerini de sunucu genelinde bir sınıra çevirir.
- Bir model hangi araç çağırma parser'ına ihtiyaç duyar?
- Sohbet şablonunun yazdığı biçimi okuyana: Qwen için <tool_call> bloklarında JSON, gpt-oss için harmony kanalları, Qwen3-Coder için <function=…> XML'i. Sayfa şablonu ve model tipini okur, her motorun belgesinin o aile için verdiği parser'ı adlandırır. Adlar motordan motora değişir: Qwen, vLLM'de hermes, SGLang'da qwen.
- Bir reponun bildirdiği quantization'a güvenebilir miyim?
- Genellikle, ama kanıt tensör adlarıdır. Blok ölçekli FP8 weight_scale_inv tensörleri bırakır, NVFP4 weight_scale_2, MXFP4 _blocks ve _scales, AWQ ve GPTQ qweight ve qzeros. NVIDIA'nın NVFP4 checkpoint'leri bunu config.json yerine hf_quant_config.json'da bildirir. Sayfa ikisini de okur ve adlarla bildirim çeliştiğinde bunu söyler.