/v1/models
Modelle abfragen
Liefert die über die OpenAI-kompatible API sichtbaren Modellinformationen und eignet sich zugleich als einfacher Erreichbarkeitstest.
Hier findest du konkrete Aufrufbeispiele für Chats, laufende Antworten, , Bildanalysen und selbst definierte Funktionen. Die Diagramme erklären, wie daraus mehrstufige KI-Agenten werden.
Deine Anwendung kommuniziert über die Wiss-KI-Pur-API. Im Hintergrund übernimmt der lokale Inferenzserver die Verarbeitung.
/v1/models
Liefert die über die OpenAI-kompatible API sichtbaren Modellinformationen und eignet sich zugleich als einfacher Erreichbarkeitstest.
/v1/chat/completions
Ein zentraler Endpunkt für Text-Chats, , Reasoning, strukturierte Tool-Aufrufe und nachgewiesene Bildanalyse per multimodaler Nachricht.
/wisskipur/capabilities
Der Statusendpunkt informiert über wichtige Serverfähigkeiten, etwa über die Unterstützung strukturierter Funktionsaufrufe und die Reasoning-Voreinstellung.
Ein separater Datei-Upload über
/v1/files
sowie native PDF- und Office-Dateieingaben sind derzeit
nicht als unterstützte Funktionen dokumentiert
. Für Textdateien und Bilder gibt es unten Beispiele zur Übergabe innerhalb einer Chat-Anfrage.
/v1/models
Ein einfacher Aufruf ohne Nutzdaten.
curl -s https://<Wiss-KI-Pur-host>/v1/models
Die konkrete Modellkennung wird aus der Antwort übernommen und anschließend im Chat-Request verwendet.
Bei aktiviertem Zugriffsschutz muss der Client die dafür vorgesehenen Zugangsdaten mitsenden. Die erreichbare Basisadresse hängt von der jeweiligen Installation ab.
/v1/chat/completions
: normaler Chat
curl -s https://<Wiss-KI-Pur-host>/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "<modellkennung>",
"messages": [
{"role": "user", "content": "Fasse diesen Text kurz zusammen."}
],
"stream": false
}'
model
Modellkennung aus
/v1/models
.
messages
OpenAI-kompatible Nachrichtenfolge mit Rollen wie
system
,
user
,
assistant
und im Tool-Flow
tool
.
stream
false
für eine vollständige Antwort oder
true
für Streaming.
temperature
/
max_tokens
Übliche Sampling- bzw. Ausgabelimits, soweit vom Modell/Backend akzeptiert.
Antwortformat: OpenAI-artiges JSON mit
choices[].message.content
und
usage
. Auch Bilder und Tool-Schemata werden als zusätzliche Felder an diesen Endpunkt gesendet.
curl -N https://<Wiss-KI-Pur-host>/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "<modellkennung>",
"messages": [{"role": "user", "content": "Erkläre den Ablauf."}],
"stream": true
}'
Der Endpunkt bleibt derselbe. Der Client verarbeitet die Antwort stückweise, anstatt auf die vollständige Fertigstellung zu warten.
Der Client empfängt Streaming-Ereignisse schrittweise (Server-Sent Events). Für lokale Tests kann statt HTTPS die freigegebene LAN-Adresse mit dem dafür vorgesehenen Port genutzt werden.
{
"model": "<modellkennung>",
"messages": [{"role":"user","content":"Prüfe die Angaben auf Widersprüche."}],
"reasoning_effort": "medium",
"stream": false
}
off
low
medium
high
Wiss-KI-Pur verwendet standardmäßig Reasoning aus, sofern der Client keinen anderen Modus vorgibt. Höhere Stufen können die Ergebnisqualität bei komplexen Aufgaben verbessern, benötigen aber mehr Zeit und .
Die Werte
off
,
low
,
medium
und
high
gelten für die Reasoning-Steuerung über den Wiss-KI-Pur-Proxy. Modellabhängige Zusatzoptionen wie
chat_template_kwargs.reasoning_effort = "xhigh"
und
enable_thinking = true
werden im Bildbeispiel gezeigt.
Das Modell führt keine Funktionen auf dem Wiss-KI-Pur-Server aus. Es kann einen strukturierten Funktionsaufruf anfordern. Die aufrufende Anwendung führt die Funktion aus und sendet das Ergebnis anschließend wieder an denselben Chat-Endpunkt.
{
"model": "<modellkennung>",
"messages": [{"role":"user","content":"Wo befindet sich Auftrag A-000123?"}],
"tools": [{
"type": "function",
"function": {
"name": "get_order",
"description": "Liest einen Auftrag.",
"parameters": {
"type": "object",
"properties": {"order_id":{"type":"string"}},
"required": ["order_id"],
"additionalProperties": false
}
}
}],
"tool_choice": "auto"
}
Bei einer Werkzeugentscheidung enthält die Modellantwort einen strukturierten
tool_calls
-Eintrag. Nach der lokalen Ausführung wird das Ergebnis mit passender
tool_call_id
als Nachricht mit
role: "tool"
zurückgesendet.
{
"model": "<modellkennung>",
"messages": [
{"role":"user","content":"Wo befindet sich Auftrag A-000123?"},
{"role":"assistant","tool_calls":[{"id":"<call-id>","type":"function","function":{"name":"get_order","arguments":"{\"order_id\":\"A-000123\"}"}}]},
{"role":"tool","tool_call_id":"<call-id>","content":"{\"shipment_id\":\"SHIP-000123\"}"}
],
"tools": [{
"type": "function",
"function": {
"name": "get_order",
"description": "Liest einen Auftrag.",
"parameters": {
"type": "object",
"properties": {"order_id":{"type":"string"}},
"required": ["order_id"],
"additionalProperties": false
}
}
}],
"tool_choice": "auto"
}
messages
+
tools
tool_calls
role: tool
+ Ergebnis
Schritte 3 bis 5 können sich mehrfach wiederholen. Genau diese Schleife macht aus einfachem Function Calling einen mehrstufigen Agentenablauf.
GET /v1/models
zur Modellkennung und
GET /wisskipur/capabilities
zur Proxy-Funktionsprüfung.
POST /v1/chat/completions
mit
messages
,
tools
und
tool_choice: "auto"
; optional mit Bildinhalt oder Reasoning-Parametern.
choices[].message.tool_calls
mit Name, Argumenten und
id
; alternativ direkte Textantwort ohne Werkzeugbedarf.
get_order
.
Das ist kein HTTP-Aufruf auf einen Wiss-KI-Pur-Funktionsendpunkt.
POST /v1/chat/completions
erneut mit bisheriger Historie, der ursprünglichen Assistant-Tool-Anforderung und
role: "tool"
samt passender
tool_call_id
.
Für UTF-8-Text liest der Client die Datei lokal ein und sendet den Text als Bestandteil der nächsten messages-Nachricht an POST /v1/chat/completions. Damit wird kein Dateiobjekt auf dem Server abgelegt.
Ein eigenständiger POST /v1/files-Upload ist für diese Wiss-KI-Pur-API nicht bestätigt.
Bestätigt: Ein PNG-Bild wird auf Clientseite als Base64-kodierte
data:image/png;base64,…
-URL erzeugt und als
type: "image_url"
zusammen mit Text in
messages[].content
an
POST /v1/chat/completions
gesendet.
Das ist eine multimodale Eingabe, kein separater Bild-Upload-Endpunkt.
Die Bilddatei wird in der Anfrage übertragen. Ob weitere Bildformate oder Größen unterstützt werden, hängt von der jeweiligen Modellkonfiguration ab.
Die Datei wird vom aufrufenden Client eingelesen und der Inhalt als Text übertragen. Es findet kein
multipart/form-data
-Upload statt.
jq -n --rawfile txt beispiel.txt '{
"model": "<modellkennung>",
messages: [{role:"user",content:("Bitte fasse zusammen:\n" + $txt)}]
}' > /tmp/text-request.json
curl -sS http://localhost:9000/v1/chat/completions \
-H 'Content-Type: application/json' \
--data-binary @/tmp/text-request.json
Dieses Beispiel zeigt, wie ein Bild zusammen mit einer Frage übermittelt wird. Die Bilddatei liegt auf dem Client und wird in die JSON-Anfrage eingebettet.
base64 -w0 r.png > /tmp/r.b64
jq -n --rawfile img /tmp/r.b64 '{
"model": "<modellkennung>",
messages: [{
role: "user",
content: [
{type:"image_url",image_url:{url:("data:image/png;base64," + $img)}},
{type:"text",text:"Was ist zu sehen und in welcher Anordnung?"}
]
}],
max_tokens: 4096,
chat_template_kwargs: {
enable_thinking: true,
reasoning_effort: "xhigh"
}
}' > /tmp/vision-request-high.json
curl -sS http://localhost:9000/v1/chat/completions \
-H 'Content-Type: application/json' \
--data-binary @/tmp/vision-request-high.json | jq
Die
chat_template_kwargs
steuern das Modellverhalten in der gezeigten Konfiguration. Je nach Modell können die unterstützten Zusatzoptionen abweichen. Für Zugriffe außerhalb des lokalen Netzes ist eine passend geschützte HTTPS-Adresse erforderlich.
Bildnachweis: Rome Montage 2017 . Urheber: AlexTref871, Jebulon, Diliff, Keith Yahl und Thomas Wolf (foto-tw.de). Lizenz: CC BY-SA 2.5 . Für die Webdarstellung als WebP konvertiert und komprimiert.
In dieser Collage muss die KI nicht nur einzelne Motive erkennen, sondern auch deren Anordnung zueinander beschreiben. Bei solchen Aufgaben kann aktiviertes Reasoning helfen, komplexe Bildstrukturen genauer zu erfassen.
Komplexe Bildanalysen können zusätzliche Reasoning- und Ausgabe-Token beanspruchen. Der tatsächliche Bedarf hängt von Bildgröße, Inhalt, Anfrage und Konfiguration ab.
image_url
als Dokumente verarbeitet. Für diese Formate ist eine vorherige Aufbereitung in Text- oder Bildinhalte erforderlich. Ein separater
/v1/files
-Upload ist nicht als unterstützter API-Aufruf dokumentiert.
/wisskipur/capabilities
Dieser Endpunkt gehört zur Wiss-KI-Pur-Schicht und nicht zum OpenAI-Standard. Er dient dazu, den tatsächlich wirksamen Funktionsumfang des Servers sichtbar zu machen.
curl -s https://<Wiss-KI-Pur-host>/wisskipur/capabilities
Praktisch genutzt wird der Status unter anderem für die Prüfung, ob natives Tool Calling erfolgreich verifiziert wurde, welcher Reasoning-Standard gilt und wie der vorgesehene Zugriffsschutz konfiguriert ist.
Diese Funktionen stammen aus dem synthetischen Agenten-Benchmark. Sie sind keine eingebauten Wiss-KI-Pur-Endpunkte , sondern zeigen, wie eine Kundenanwendung eigene Werkzeuge an das Modell übergeben kann.
| Funktion | Parameter | Beispielhafte Rolle |
|---|---|---|
get_order
|
order_id
|
Auftragsdaten lesen |
get_stock
|
item_id
|
Bestand prüfen |
get_supplier
|
supplier_id
|
Lieferantendaten lesen |
get_customer
|
customer_id
|
Kundendaten lesen |
get_policy
|
policy_id
|
Regel/Policy prüfen |
get_quality
|
item_id
|
Qualitätsstatus prüfen |
get_ticket
|
ticket_id
|
Support-/Vorgangsdaten lesen |
get_document
|
document_id
|
Dokumentinhalt lesen |
get_shipping
|
shipment_id
|
Versandstatus lesen |
get_invoice
|
invoice_id
|
Rechnungsdaten lesen |
Die Diagramme stammen aus dem veröffentlichten Agenten-Benchmark und zeigen unterschiedliche Werkzeugketten, Kontrollprüfungen und Fehlerfälle.
Die Diagramme stellen Szenen aus dem Benchmark dar, keine automatisch mitgelieferten Serverfunktionen. Jede im Diagramm genannte
get_…
-Funktion muss der jeweilige Client selbst bereitstellen.