Skip to main content
GLM (General Language Model) är en ny generation av stora språkmodeller som lanserats av Zhipu AI (Zhipu AI / Z.ai), med starka förmågor inom förståelse och generering av både kinesiska och engelska. Den presterar utmärkt inom uppgifter som kinesiska scenarier, kodgenerering, resonemang och flerdialog. De nya modellerna GLM-5.3, GLM-5.2, GLM-4.7 med flera har genomgått omfattande optimeringar för långa sammanhang, verktygsanrop och koduppgifter, och kan tillämpas brett inom intelligenta frågesystem, innehållsskapande, kodassistans, kundtjänstrobotar och andra scenarier. Detta dokument beskriver huvudsakligen användningsprocessen för GLM Chat Completion API, vilket gör att du enkelt kan anropa GLM-serien av modeller via ett enhetligt OpenAI-kompatibelt gränssnitt.

Ansökningsprocess

För att använda GLM Chat Completion API, börja med att gå till Ace Data Cloud-konsolen för att hämta din API-token, som du ska spara för framtida bruk. Om du inte har loggat in eller registrerat dig, kommer du automatiskt att omdirigeras till inloggningssidan där du blir inbjuden att registrera dig och logga in. När detta är klart kommer du automatiskt att återvända till den aktuella sidan. En API-token räcker för att anropa alla tjänster på plattformen, du behöver inte ansöka separat för varje tjänst. Vid första ansökan får du en gratis kvot för att prova; om kvoten tar slut kan du ladda på allmän balans i konsolen.
📘 Fullständig dokumentation: GLM Chat Completion API →

Grundläggande Användning

Begärningsadressen för GLM Chat Completion API är https://api.acedata.cloud/glm/chat/completions, och autentisering sker med Bearer Token. Begärningskroppen är kompatibel med OpenAI Chat Completions-protokollet. Vid första användning av detta gränssnitt behöver vi fylla i minst tre innehåll:
  • authorization: Välj Bearer Token direkt från rullgardinsmenyn.
  • model: Välj den GLM-modell som ska anropas, de för närvarande stödda modellerna inkluderar:
    • glm-5.3: Den senaste flaggskeppsmodellen, stödjer 1M sammanhang och längst 128K utdata, lämplig för komplexa resonemang, kod och agentuppgifter. Resonemang är alltid aktiverat, och du kan välja reasoning_effort som low, high eller max.
    • glm-5.2: Den föregående flaggskeppsmodellen, med starka övergripande förmågor.
    • glm-5.1: En mogen flaggskeppsmodell, lämplig för allmänna komplexa uppgifter.
    • glm-4.7: Presterar utmärkt inom resonemang, verktygsanrop och koduppgifter.
    • glm-4.6: En allmän dialogmodell, balanserar effekt och kostnad.
    • glm-3-turbo: En klassisk dialogmodell, lämplig för allmänna textgenereringsuppgifter.
  • messages: En array av meddelanden, där varje meddelande innehåller role och content, där role stöder tre roller: user, assistant, system.
Vanliga valfria parametrar:
  • max_tokens: Begränsar det maximala antalet tokens för ett enda svar.
  • temperature: Genererar slumpmässighet, mellan 0-2, ju högre värde desto mer spritt.
  • top_p: Kärnprovningsparameter, kontrollerar den kumulativa sannolikhetströskeln för kandidattokens.
  • n: Hur många kandidatsvar som ska genereras åt gången.
  • stream: Om strömmande svar ska aktiveras, standard är false.
  • stop: Anpassad stoppsekvens.
Här är ett enklaste exempel på Python-anrop:
Efter anropet ser vi att returresultatet ser ut som följer:
Förklaringar av de viktigaste fälten i returresultatet:
  • id: Det unika ID:t för denna dialoguppgift.
  • created: Tiden för skapandet av denna dialoguppgift (Unix-tidsstämpel, sekunder).
  • model: Namnet på den faktiska anropade GLM-modellen.
  • choices: Listan över svar som genererats av modellen. choices[i].message.content är den specifika texten som modellen svarade med, finish_reason anger orsaken till avslutningen (stop, length, tool_calls, content_filter etc.).
  • usage: Statistik över tokenanvändningen för denna begäran, inklusive prompt_tokens, completion_tokens, total_tokens.

Strömmande Svar

Detta gränssnitt stöder strömmande svar (Server-Sent Events), vilket är mycket användbart för webbgränssnitt och kan ge en effekt av att visa texten ord för ord. Om du vill ha strömmande svar, ställ in stream-parametern i begärningskroppen till true. Exempel på Python-anropskod:
Utdataeffekten ser ut som följer (utdrag):
Du kan se att svaret innehåller många data, varje data innehåller ett inkrementellt segment. choices[i].delta.content är den aktuella chunkens nya textsegment, du kan sammanfoga dessa segment för att bilda ett komplett svar. När data innehållet är [DONE] betyder det att den strömmande svaret har avslutats. Den sista chunk som har usage kommer att sammanfatta token-användningen för denna begäran. JavaScript (Node.js) exempel:
Java exempel kod:
Andra språk kan skrivas om på liknande sätt, principen är densamma.

Flera omgångar av dialog

Om du vill implementera funktionalitet för flera omgångar av dialog, behöver du lägga in historiska dialoger i messages arrayen och behålla ordningen av user och assistant som växlar. Python exempel anropskod:
Genom att ladda upp flera frågor kan du enkelt uppnå flera omgångar av dialog och få följande svar:
Du kan se att informationen i choices är densamma som vid grundläggande användning, modellen ger svar baserat på hela dialoghistoriken, vilket stödjer flera omgångar av kontextuell interaktion.

Systemprompt (System Prompt)

Du kan lägga till ett meddelande med role som system i början av messages för att begränsa modellens roll, stil eller beteende:

Verktygsanrop (Function Calling)

GLM-modellen stöder OpenAI-kompatibla verktygsanrop, du kan deklarera anropbara funktioner genom tools parametern, modellen kommer att returnera strukturerad funktionsanropsinformation i choices[i].message.tool_calls när det behövs.
Om modellen beslutar att anropa verktyget, kommer resultatet att ha finish_reason som ändras till tool_calls, och i message.tool_calls ges funktionsnamnet och JSON-strängformatet av parametrarna. Du kan utföra den funktionen och skicka resultatet som ett meddelande med role som tool tillbaka till modellen för att slutföra den fullständiga verktygsanropscykeln.

Rekommendationer för modellval

När api_error returneras och meddelandet är Tjänsten är tillfälligt otillgänglig, vänligen försök igen senare., indikerar det vanligtvis att upstream GLM-tjänsten är tillfälligt otillgänglig, det rekommenderas att använda exponentiell backoff för att försöka igen, eller växla till en annan tillgänglig GLM-modell (till exempel från glm-5.1 tillfälligt växla till glm-4.7 eller glm-4.6).

Slutsats

Genom detta dokument har du fått en förståelse för hur man använder GLM Chat Completion API för att anropa Zhiyu AI:s GLM-serie modeller, inklusive grundläggande anrop, strömmande svar, flerdialoger, systempromptar och verktygsanrop. Vi hoppas att detta dokument kan hjälpa dig att bättre integrera och använda detta API. Om du har några frågor, tveka inte att kontakta vårt tekniska supportteam.