Pi coding agent için LLMTR sağlayıcısı ve üretilen model kataloğu

Sağlayıcı kaydı on beş satır

Kaynağı baştan söyleyelim: bu entegrasyon upstream Pi sürümüne merge edilmedi. Sağlayıcı dosyasını ve üretilen model kataloğunu knowhycodata/pi deposunda feat/llmtr-provider dalı altında bulacaksınız. Resmi paketle kurulum yapan okuyucu llmtr sağlayıcısını göremez; önce bu dalı alıp bağımlılıkları kurun.

Pi tarafında bir sağlayıcı eklemek uzun bir iş değildir. LLMTR için yazılan dosya on beş satırdır ve tek bir fabrika fonksiyonu döndürür: kimlik, görünen ad, temel adres, kimlik doğrulama yöntemi, model listesi ve istek ailesi. Sağlayıcı bu haliyle yerleşik sağlayıcılar listesine eklenir ve ajanın kullanabileceği hale gelir.

Buradaki tasarım tercihi önemli: dosya hiçbir model bilgisi taşımaz. Modeller ayrı bir modülden içe aktarılır ve fabrika fonksiyonu yalnızca o modülün değerlerini listeye çevirir. Sağlayıcı sözleşmesi ile katalog içeriği böylece ayrı tutulur.

Sağlayıcı fabrikası, LLMTR kayıt dosyasından

export function llmtrProvider(): Provider<"openai-completions"> {
  return createProvider({
    id: "llmtr",
    name: "LLMTR",
    baseUrl: "https://llmtr.com/v1",
    auth: { apiKey: envApiKeyAuth("LLMTR API key", ["LLMTR_API_KEY"]) },
    models: Object.values(LLMTR_MODELS),
    api: openAICompletionsApi(),
  });
}

Model kataloğu elle yazılmaz, üretilir

Model listesini taşıyan dosya bir üretim çıktısıdır ve başındaki yorum bunu açıkça söyler: dosya bir üretim betiği tarafından yazılır, elle düzenlenmez, güncellemek için betiği çalıştırmak gerekir. Dosyanın kendisi yalnızca bir veri dosyasını içe aktarır ve düzleştirici bir yardımcıdan geçirir.

Bu ayrım katalog tazelemeyi rutinleştirir. Yeni bir rota yayımlandığında veya bir rota emekli edildiğinde kaynak veriyi güncelleyip üretim komutunu çalıştırmak yeterlidir; kayıt dosyasına dokunulmaz. Bir modeli elle eklemek isterseniz de doğru yer üretilen dosya değil, betiğin okuduğu veri kaynağıdır.

Üretilen katalog modülü, üst satırdaki uyarı yorumuyla birlikte (kısaltılmış)

// This file is auto-generated by scripts/generate-models.ts
// Do not edit manually - run 'npm run generate-models' to update

import values from "./data/llmtr.json" with { type: "json" };
import { flattenModelCatalog } from "../model-catalog.ts";

export const LLMTR_MODELS = flattenModelCatalog("llmtr", values);

Ortam anahtarı çözümlemesi

Kimlik doğrulama, ortam değişkeni okuyan bir yardımcıya bağlanır. Testler bu davranışı iki yönlü doğrular: sağlayıcı kimliğinden ortam değişkeni adına ulaşılabildiğini ve değişken tanımlıysa değerin okunabildiğini kontrol ederler. Tarayıcı ortamında değişken okuma mümkün olmadığı için anahtarın doğrudan geçirilmesi gerektiği paket belgesinde ayrıca not edilir.

Aşağıdaki tablo, entegrasyonun tüm sabit değerlerini ve bunların hangi dosyada tanımlandığını bir arada verir. Kurulumda bir şey tutmadığında bakılacak yer listesi de budur.

Model kimlikleri ve seçim

Üretilen katalogtaki her kayıt için testler üç şeyi zorunlu tutuyor: istek ailesi sohbet tamamlama olacak, temel adres gateway adresi olacak ve model kimliği bölü işareti içerecek. Üçüncü koşul en önemlisi, çünkü kimliklerin sağlayıcı bölü model biçimindeki kanonik yazımını koruduğunu garanti eder. Testlerdeki örnek model kimliği moonshot/kimi-k3 ve bu rota herkese açık katalogda canlı.

Yani Pi tarafında model seçerken gateway kataloğundaki kimliği olduğu gibi kullanırsınız; sağlayıcıya özgü bir yeniden adlandırma yoktur. Sağlayıcı kimliği llmtr, model kimliği ise kanonik yazımdır. Komut satırında model bayrağının tam yazımı bu daldaki değişiklik kümesinde yer almadığı için burada bir bayrak örneği vermiyoruz; bu sürümde doğrulanmadı.

• Sağlayıcı kimliği: llmtr
• Model kimliği: gateway kataloğundaki kanonik yazım, örneğin moonshot/kimi-k3
• Her üretilen kayıt gateway adresini ve sohbet tamamlama ailesini taşır
• Anahtar ortam değişkeninden okunur, tarayıcıda doğrudan geçirilir

Akıl yürütme parametresi gövdeye nasıl giriyor

Uyumluluk testleri istek gövdesini yakalayıp içine bakıyor ve üç davranışı sabitliyor. Birincisi, akıl yürütme gücü düz bir alan olarak değil, içinde efor değeri taşıyan bir nesne olarak gönderiliyor. İkincisi, hiç efor seviyesi yayımlamayan bir model için bu alan gövdeye hiç eklenmiyor. Üçüncüsü, gövde bir gateway'e gidiyormuş gibi kuruluyor ve sunucu tarafı saklama alanı gönderilmiyor.

İkinci maddenin gerekçesi test yorumunda açıklanmış: modelin yayımlamadığı bir efor seviyesi gönderildiğinde gateway desteklenmeyen yetenek hatasıyla dönüyor. Bu yüzden efor listesi boş olan modelde alan tümüyle çıkarılıyor ve model gateway tarafındaki varsayılanıyla çalışıyor.

Sohbet tamamlama ailesi ve uç nokta uyumu

Sağlayıcı kaydı istek ailesini sohbet tamamlama olarak sabitler. Gateway tarafında sohbet tamamlama isteği, modelin sohbet tamamlama veya yanıtlar bağlaması varsa karşılanır; yanıtlar ucuna yapılan istek ise yalnızca yanıtlar bağlaması olan modellerde geçerlidir. Köprü tek yönlüdür, ters yönde çalışmaz.

Pratikte bu, bir modeli katalogda görüp doğrudan sabitlemeden önce hangi işlemleri yayımladığına bakmanız gerektiği anlamına gelir. Gömme, görsel, video ve ses rotaları sohbet döngüsünü hiç çalıştıramaz. Katalog uç noktası anahtar gerektirmeden okunabildiği için bu kontrolü kurulum yapmadan önce de yapabilirsiniz.

Sık sorulan sorular

Üretilen model dosyasını elle düzenleyebilir miyim?

Dosyanın ilk satırı bunu açıkça yasaklıyor: dosya üretim betiğinin çıktısıdır ve bir sonraki üretimde üzerine yazılır. Kalıcı bir değişiklik istiyorsanız betiğin okuduğu veri kaynağını güncelleyip üretim komutunu yeniden çalıştırın.

Anahtarı ortam değişkeni yerine doğrudan verebilir miyim?

Paket belgesi, ortam değişkeni çözümlemesinin çalıştığı yeri sunucu tarafı olarak tanımlıyor ve tarayıcı ortamında anahtarın doğrudan geçirilmesi gerektiğini not ediyor. Sunucu tarafında kalıyorsanız ortam değişkeni yolunu kullanmak daha güvenli olur.

Akıl yürütme gücünü belirleyen düz alan neden gövdede yok?

Bu entegrasyon gücü iç içe bir nesne olarak taşıyor. Testler düz alanın gönderilmediğini ayrıca doğruluyor; ikisini birden göndermek gereksiz olurdu. Modelin hiç efor seviyesi yoksa alan tamamen çıkarılıyor.

Maliyeti nasıl kontrol ederim?

Ücretlendirme jeton bazlıdır ve harcama kredi bakiyesinden düşer; model başına rakam vermek yerine kullanım sayaçlarını izlemek daha sağlıklıdır. Platform marjı yalnızca kredi yüklemede uygulanır ve yüzde sekizdir; model fiyatlarına marj eklenmez.

İlgili yazılar

• LLMTR entegre geliştirici araçları: 21 aracın bağlanma biçimi
• Trae Agent ile LLMTR: Python yapılandırması ve çalışma kaydı
• DeepSeek Harness LLMTR eklentisi: LLM dikişi ve katalog

• Model katalogu
• Chat Completions rehberi
• API anahtarlari
• Fiyatlandirma