OpenCompany iş akışlarında LLMTR sağlayıcısı kurulumu

LLMTR, OpenCompany'nin sağlayıcı katmanında nereye oturuyor

OpenCompany React Flow tabanlı bir iş akışı otomasyon platformu. Model çağrıları LangChain üzerinden değil, server/services/llm/ altındaki native SDK cephesinden geçiyor; her sağlayıcı bir protokol uygulaması olarak kayıtlı. knowhycodata/OpenCompany deposundaki feat/llmtr-provider dalı bu listeye llmtr adında bir sağlayıcı ekliyor ve sağlayıcı sayısını 14'e çıkarıyor.

Dalın kendi belgesindeki ayrım önemli: bu 14 sağlayıcının ikisi tek satıcıya değil, bir gateway'e bakıyor. Gateway olmak burada somut bir sonuç doğuruyor. Model kimlikleri satıcı/model biçiminde olduğu için llmtr, is_model_valid_for_provider içindeki açık dünya demetine ve model_registry içindeki _ROUTER_PROVIDERS kümesine giriyor. Birincisi katalogdaki her satırın geçerli sayılmasını sağlıyor, ikincisi bağlam ve çıktı limitlerinin satıcı önekini soyarak router önbelleğinden okunmasına izin veriyor.

Sağlayıcı sınıfı LLMTRProvider, OpenAIProvider'ı olduğu gibi miras alıyor ve tek bir metodu geçersiz kılıyor. Kablo biçimi düz OpenAI olduğu için taban adres dışında değiştirilecek bir şey yok; taban adres https://llmtr.com/v1 olarak ProviderSpec içinde client_kwargs ile sabitleniyor. Saklanmış bir llmtr_proxy kimlik bilgisi bu değeri çağrı anında yine de geçersiz kılabiliyor, yani kendi barındırdığınız bir kurulum kod değişikliği istemiyor.

Kimlik bilgisi kaydı: tek alan, farklı bir doğrulama

Sağlayıcının kullanıcıya görünen yüzü server/config/credential_providers.json içindeki llmtr bloğu. Blok _ai_base şablonunu genişletiyor ve tek bir apiKey alanı tanımlıyor; alanın placeholder değeri anahtar biçimini gösteriyor. Simge alanı @lobehub/icons paketinde LLMTR markası bulunmadığı için arka uçtaki kimlik bilgisi simge uç noktasına işaret ediyor, bu da sarvam ve stripe gibi girişlerin zaten kullandığı biçim.

Asıl fark doğrulamada. Diğer LLM kimlik bilgileri model listesini çekebiliyorsa anahtarı geçerli sayan ortak bir kontrol kullanıyor. LLMTR'de bu kontrol işe yaramaz, çünkü model listesi uç noktası herkese açık: anahtarsız da, geçersiz anahtarla da 200 dönüyor. Bu yüzden LLMTRCredential kendi kontrolünü yazıyor ve anahtarı bir token'lık gerçek tamamlama isteğiyle sınıyor.

Kontrolün sırası da dalda test altına alınmış: önce sohbet isteği, sonra model listesi. Reddedilen bir anahtarın yanında dolu bir model açılır listesi görünmesi kullanıcıyı yanıltacağı için bu sıra korunuyor. Ayrıca hata çevirisi kapatılarak ham hata nesnesi sınıflandırıcıya ulaştırılıyor; durum kodu orada okunuyor.

credential_providers.json içindeki llmtr bloğunun çekirdeği

{
  "llmtr": {
    "extends": "_ai_base",
    "name": "LLMTR",
    "color": "#E11D48",
    "icon_ref": "/api/schemas/credentials/llmtr/icon",
    "fields": [
      {
        "key": "apiKey",
        "placeholder": "llmtr-..."
      }
    ]
  }
}

Chat model node'u modeli nasıl çözüyor

Tuvale eklenen node'un tipi llmtrChatModel, görünen adı LLMTR ve alt başlığı Chat Model. Parametre yüzeyi bilinçli olarak genel tutulmuş: node yalnızca frequency_penalty ve presence_penalty alanlarını ekliyor, ayrı bir düşünme alanı tanımlamıyor. Gerekçesi node'un kendi belgesinde yazıyor. Seçilen satıcı/model kimliğinin hangi satıcıya düştüğü değiştikçe geçerli parametre kümesi de değişiyor; modelin kabul etmediği bir alan istek anında 400 olarak dönüyor, kapalı bir kontrol olarak değil. ChatModelParams'tan miras alınan thinking_enabled ve reasoning_effort yine kullanılabiliyor.

Asıl çözüm _model_policy içinde yapılıyor ve dal bu fonksiyonu ikiye ayırıyor. Gateway JSON bloğunda routes_vendor_prefixed_models bayrağını taşıyorsa ve model kimliğinde eğik çizgi varsa, önek vendor_aliases üzerinden bir sağlayıcı bloğuna çevriliyor. Kablo biçimi o bloktan, düşünme ayarı ise gateway'in kendi bloğundan okunuyor.

Bu ayrımın nedeni test dosyasında canlı gözlemle gerekçelendirilmiş. Bir satıcının akıl yürütme modeli, önüne kim geçerse geçsin max_tokens ve temperature ikilisini reddediyor; dolayısıyla kablo biçimi satıcının özelliği. Buna karşılık gateway akıl yürütmeyi kendi tekilleştirdiği biçimde alıyor, satıcıya özel gövde alanlarını iletmiyor, açmadığı satırlarda parametreyi doğrudan reddediyor. Satıcının kendi düşünme türünü buraya taşımak, çalışan çağrıları kullanıcı düşünmeyi işaretlediği anda bozardı.

Katalog filtresi ve açılır listede görünmeyen satırlar

LLMTRProvider'ın geçersiz kıldığı tek metot fetch_models. Ortak OpenAI yolu model listesindeki her satırı döndürüyor; LLMTR kataloğu ise karışık modaliteli. Sohbet satırlarının yanında embedding, görsel, video, yeniden sıralama ve ses satırları da var. Filtrelenmemiş bir liste, sohbet node'unun açılır menüsüne bir embedding modeli koyar ve kullanıcı bunu seçim anında değil, çalışma anında opak bir hatayla öğrenir. Filtre tahmine dayanmıyor: katalog her satır için supported_operations alanını yayımlıyor, kod da bu alanı okuyor.

Alan hiç yoksa veya boşsa satır sohbet kabul ediliyor. Bu izin verici davranış bilinçli; eksik bir bildirimin çalışan bir modeli sessizce gizlemesi istenmiyor.

Bir noktada filtre gereğinden dar kalıyor. Kod, yalnızca RESPONSES bağlantısı bulunan satırları listeden çıkarıyor ve gerekçe olarak bu satırların her çağrıda 404 döneceğini varsayıyor. LLMTR'de köprü yönü asimetrik: sohbet tamamlama isteği, modelin CHAT_COMPLETIONS veya RESPONSES bağlantısı varsa çalışıyor. Köprüsü olmayan yön diğeri, yani Responses yoluna yalnızca RESPONSES bağlantılı satırlar gidebiliyor. Pratik sonucu şu: bugün public katalogda yalnızca RESPONSES bağlantısıyla yayımlanan bazı satırlar node'un açılır listesinde görünmüyor, oysa node'un gönderdiği istek biçimiyle erişilebilirler. Bu bir veri kaybı değil, dar tutulmuş bir liste; genişletmek isterseniz kabul kümesini değiştirmeniz gerekiyor.

• Filtre supported_operations alanına bakıyor, model adına değil.
• Alan boşsa satır sohbete uygun kabul ediliyor.
• Yalnızca RESPONSES bağlantılı satırlar bu sürümde listelenmiyor.
• Sohbet tamamlama yolu bu satırları köprülediği için kısıt kodun kendi tercihi.

Embedding tarafı: aynı anahtar, ikinci kablo yüzeyi

Dal LLMTR'yi yalnızca sohbet sağlayıcısı olarak eklemiyor. Vektör deposu tarafında da seçilebilir bir embedding sağlayıcısı olarak kayıtlı ve doküman tarafındaki embedding üretici node'u llmtr seçeneğini gösterirken anahtar alanını da birlikte açıyor. Ayrı bir adapter yazılmamış: embedding uç noktası sohbetle aynı OpenAI kablo biçiminde konuştuğu için mevcut OpenAI embedder yeniden kullanılıyor.

Bu yeniden kullanımın bedeli taban adresin elle sabitlenmesi. Sabitleme kaybolursa llmtr seçimi sessizce OpenAI'ın kendi adresine bakan bir istemci kuruyor ve kullanıcının LLMTR anahtarını oraya gönderiyor. Dal bunu bir testle kilitliyor; ayrıca boş anahtarla istemci kurulmasını hata fırlatarak engelliyor, çünkü sessiz bir istemci hatayı ancak toplu bir işin ortasında gösterirdi.

Varsayılan embedding modelinin llmtr önekiyle başlaması da test altında. Gerekçe veri yerelliği: bu gateway'i seçmenin nedeni buysa varsayılanın yabancı bir satıcıya düşmemesi gerekiyor. Public katalogda llmtr önekiyle yayımlanan tek canlı embedding satırı llmtr/embeddinggemma-300m; farklı bir varsayılan kullanacaksanız katalogdan doğrulayın. Not: dalın birim testlerinde geçen katalog satırları sahte yükler, gerçek katalog satırları değil.

Node açılır listesinin göreceği satırları anahtarsız doğrulama

# Sohbet node'unun listeleyeceği satırlar
curl -s https://llmtr.com/v1/models \
  | jq -r '.data[] | select((.supported_operations // []) | index("CHAT_COMPLETIONS")) | .id' \
  | head

# Embedding node'unun kullanabileceği satırlar
curl -s https://llmtr.com/v1/models \
  | jq -r '.data[] | select((.supported_operations // []) | index("EMBEDDINGS")) | .id'

Doğrulama ve sık karşılaşılan hatalar

Kurulumdan sonra sırayla üç şeyi doğrulayın: kimlik bilgisi kaydediliyor mu, node'un açılır listesi doluyor mu, seçilen model gerçekten yanıt veriyor mu. Üçü ayrı katmanlar ve biri geçtiği için diğeri geçmiş sayılmıyor. Özellikle model listesinin dolması anahtarın geçerli olduğunu göstermiyor.

Aşağıdaki tablo bu dalın ürettiği belirtileri ve kaynaklarını topluyor. Hepsi kodda ya da testlerde karşılığı olan durumlar; ölçüm değil, davranış eşlemesi.

Sık sorulan sorular

llmtrChatModel node'unda neden ayrı düşünme alanları yok?

Node bir gateway'in önünde duruyor ve geçerli parametre kümesi seçilen satıcı/model kimliğine göre değişiyor. Kod bunu kabul edip parametre yüzeyini genel bırakıyor; modelin kabul etmediği alan istek anında hata olarak dönüyor. Miras alınan düşünme alanları destekleyen satırlarda kullanılmaya devam ediyor.

Aynı LLMTR anahtarı hem sohbet hem embedding node'unda kullanılabilir mi?

Evet. Embedding uç noktası sohbetle aynı OpenAI kablo biçiminde konuştuğu için dal ayrı bir adapter yazmıyor, mevcut embedder'ı taban adresi sabitleyerek yeniden kullanıyor. Doküman tarafındaki embedding üretici node'u llmtr seçildiğinde anahtar alanını da gösteriyor.

Model listesi yükleniyorsa anahtarım geçerli midir?

Hayır. LLMTR'nin model listesi uç noktası herkese açık; anahtarsız da başarı dönüyor. Dal bu yüzden kimlik bilgisi kontrolünü bir token'lık gerçek tamamlamayla yapıyor ve bu kontrolü model listesinden önce çalıştırıyor.

llmtr önekiyle başlayan satırlarda parametreler nasıl çözülüyor?

Bu satırların karşılığı bir satıcı bloğu olmadığı için gateway'in genel bloğu kullanılıyor. Kod bunu bilinçli bir varsayılan olarak tanımlıyor; tanımadığı bir öneki kendi kestirdiği bir satıcıya eşlemek yerine muhafazakâr biçimi koruyor.

İlgili yazılar

• LLMTR entegre geliştirici araçları: 21 aracın bağlanma biçimi
• OpenStory'de LLMTR gateway'ini takım anahtarıyla bağlama
• Pool ile LLMTR: üç ortam değişkeni ve Laguna kimlikleri

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