Vereisten
Bij het ontwerpen van moderne AI-infrastructuur is de eerste belangrijke afslag altijd hardware. Dit gaat niet alleen over het kiezen van een cloudprovider; het is een strategische investering in verwerkingskracht die de gehele kostenstructuur en het prestatieprofiel van een AI-dienst bepaalt. De keuze tussen General Processing Units (GPU's) en gespecialiseerd silicium zoals Neural Processing Units (NPU's) kan het verschil zijn tussen een winstgevende applicatie en een onhoudbare.
Het navigeren door deze "Hardwareoorlog" is een kwestie van het balanceren van pure computationele doorvoer met kostenefficiëntie. We zullen onderzoeken waarom NVIDIA's GPU-architecturen nog steeds de grootschalige modeltraining domineren en waarom op maat gemaakt silicium de inferentiestrijd op het gebied van efficiëntie beslissend wint. Mijn doel is om een duidelijke beslissingsmatrix te geven voor wanneer je bij GPU's moet blijven voor fine-tuning en wanneer je NPU's moet omarmen voor de real-time, agentische workflows die de volgende golf van AI definiëren.
Om de concepten te volgen en het agentische workflow-voorbeeld te implementeren, hebt u een paar dingen ingesteld nodig. Alle infrastructuurvoorbeelden gaan uit van Europese regio's.
- Python 3.12+: Onze applicatiecode gebruikt moderne Python-functies.
- Cloud CLI's: U hebt referenties nodig die zijn geconfigureerd voor de cloud van uw keuze. Ik geef voorbeelden voor zowel Google Cloud als Azure.
- Google Cloud SDK:
gcloud init
gcloud config set project your-gcp-project-id
gcloud config set compute/region europe-west1
* **Azure CLI**:
az login
az configure --defaults group=your-azure-resource-group location=westeurope
- Python-bibliotheken: We zullen de OpenAI-client gebruiken voor zijn tool-calling functies, wat een geweldige abstractie biedt voor het bouwen van agenten, ongeacht het uiteindelijke serving-platform.
pip install openai pydantic
Architectuur en concepten
Het AI-hardwarelandschap kan het beste worden begrepen door het werk op te splitsen in twee verschillende fasen: training en inferentie. Uw architecturale keuzes voor elk zullen dramatisch verschillen.
De trainingsmuur: NVIDIA's blijvende heerschappij
De afgelopen tien jaar, als u een grootschalig AI-model trainde, gebruikte u GPU's. Voor modellen met miljarden of zelfs biljoenen parameters is die realiteit niet veranderd. NVIDIA's Blackwell-architectuur en zijn voorgangers blijven de onbetwiste koningen van het trainingscluster.
De reden is simpel: training, met algoritmen zoals backpropagatie, vereist massale, algemene parallelle computing. Het is een oefening in brute-force floating-point operaties over enorme datasets, en de duizenden cores van een GPU zijn daar speciaal voor gebouwd. Wanneer ik infrastructuur lever voor het fine-tunen van bedrijfseigen modellen, specificeer ik altijd clusters van NVIDIA GPU's, of het nu op Google's Vertex AI of Azure Machine Learning is. Voor modellen van meer dan honderden miljarden parameters blijven de volwassenheid en prestaties van de GPU-stack ongeëvenaard.
De verborgen kosten van parallellisatie
Hoewel GPU's uitblinken in parallelle taken, kunnen de orkestratieoverhead en geheugenbandbreedte knelpunten worden. De 'decode-fase' van tokengeneratie in agentgebaseerde AI vereist bijvoorbeeld aanzienlijke gegevensoverdracht. Dit is waar gespecialiseerde hardware de algemene aard van de GPU begint uit te dagen, met name voor inferentie.
De opkomst van de NPU: De inferentiestrijd winnen
Zodra een model is getraind, verandert het spel volledig. Het doel verschuift van pure kracht naar efficiëntie, latency en kosten per query. Dit is waar Neural Processing Units (NPU's) en ander op maat gemaakt silicium zoals Groq's Language Processing Units (LPU's) een enorme impact hebben.
NPU's zijn speciaal ontworpen voor de kernoperaties van neurale netwerk inferentie – matrixvermenigvuldigingen, convoluties en activaties. Deze specialisatie stelt hen in staat om verbluffende efficiëntiewinsten te leveren. Sommige benchmarks en real-world resultaten tonen concurrerende prestaties en stroomkosten in vergelijking met GPU's voor dezelfde inferentieworkload. Google's TPU's zijn hier jarenlang het paradepaardje van geweest, en de rest van de markt haalt nu snel in.
Dit is het belangrijkst voor de real-time, agentische workflows die steeds gebruikelijker worden. Een AI-agent die autonoom externe tools kan aanroepen, een database kan bevragen of een meertrapsproces kan orkestreren, heeft lage latency en hoge doorvoer nodig. Het onderstaande diagram toont hoe deze twee werelden in kaart te brengen.
Deze taakverdeling is cruciaal voor het bouwen van een kosteneffectief AI-platform. En als u geïnteresseerd bent in de financiële kant van deze verschuiving, heb ik een technische analyse geschreven op het markten-gedeelte van de blog: Voorbij de GPU: Waarom 2026 het jaar van de NPU-transactie is.
Modelbeheer in productie
Ongeacht de hardware vereist het implementeren van agentische modellen in productie een rigoureus beheer. Een implementatiechecklist omvat altijd:
- Versiebeheer: Elk model is geverseerd en auditeerbaar in een register zoals Vertex AI Model Registry of het equivalent van Azure Machine Learning.
- Containerisatie: Modellen worden verpakt in containerimages die zijn ondertekend met Sigstore/Cosign en gescand op kwetsbaarheden om een veilige supply chain te garanderen.
- Auditlogging: Alle inferentieverzoeken, tool calls en agentbeslissingen worden gelogd voor compliance, beveiligingsmonitoring en debugging.
- Toegangscontrole: Strikte IAM-beleidsregels bepalen wie en wat model-endpoints kan aanroepen en toegang heeft tot de onderliggende gegevens.
Met die architecturale context, laten we nu overgaan tot de beslissing zelf.
Architecturaal oordeel: Een beslissingsmatrix voor praktijkmensen
Zo breek ik de keuze af op basis van workloadkenmerken:
-
Als u real-time "agentische" workflows uitvoert, kies dan voor NPU's. Wanneer subseconde latency en hoge efficiëntie cruciaal zijn voor de gebruikerservaring of operationele automatisering, is de NPU uw weg naar betere marges. Het implementeren van inferentieworkloads op NPU-geoptimaliseerde platforms (zoals Google's TPU's of opkomende serverloze LPU/NPU-aanbiedingen) zal uw operationele kosten drastisch verlagen en de prestaties verbeteren.
-
Als u bedrijfseigen modellen fine-tuned, blijf dan bij de GPU-stack. Voor de nabije toekomst, vooral voor enorme modellen of continue hertrainingspijplijnen, bieden NVIDIA's architecturen de meest kosteneffectieve oplossing voor de pure parallelle rekenkracht die nodig is voor training. Gebruik beheerde services die dedicated GPU-clusters bieden om trainingstaken te optimaliseren.
Dit is geen of-of dilemma; het is een mandaat voor strategische toewijzing van middelen. De training vindt plaats op de ene stack, en de serving vindt plaats op een andere, hooggespecialiseerde stack.
Implementatiegids: Een agentische workflow bouwen
De kern van een agentische workflow is het mogelijk maken dat een LLM intelligent externe tools kan gebruiken. Ik zal u laten zien hoe ik deze tools definieer met Python en Pydantic, en ze vervolgens integreer in een inferentiestroom met de openai-client. Dit patroon is draagbaar en kan worden geïmplementeerd op elk NPU-geoptimaliseerd platform.
Eerst hebben we een manier nodig om onze tools aan het model te beschrijven. Pydantic is hier perfect voor, omdat het een duidelijk, type-hinted schema creëert dat het model kan begrijpen.
1. Definieer de tool van de agent met Pydantic
Hier maak ik een Query-tool die een agent kan gebruiken om te interageren met een database. De Field-beschrijvingen zijn cruciaal - het is de documentatie die de LLM gebruikt om te begrijpen hoe uw functie moet worden aangeroepen.
# query_tool.py
from enum import Enum
from typing import List, Union, Optional
from pydantic import BaseModel, Field
class Table(str, Enum):
orders = "orders"
customers = "customers"
products = "products"
class Column(str, Enum):
id = "id"
status = "status"
expected_delivery_date = "expected_delivery_date"
delivered_at = "delivered_at"
shipped_at = "shipped_at"
ordered_at = "ordered_at"
canceled_at = "canceled_at"
customer_name = "customer_name"
class Operator(str, Enum):
eq = "="
gt = ">"
lt = "<"
le = "<="
ge = ">="
ne = "!="
class DynamicValue(BaseModel):
"""A dynamic value that refers to another column."""
column_name: str
class Condition(BaseModel):
column: Column
operator: Operator
value: Union[str, int, DynamicValue]
class OrderBy(str, Enum):
asc = "asc"
desc = "desc"
class Query(BaseModel):
"""Query a database table."""
table_name: Table = Field(description="The name of the database table to query.")
columns: List[Column] = Field(description="A list of columns to select from the table.")
conditions: List[Condition] = Field(default_factory=list, description="Optional list of conditions to filter the results.")
order_by: Optional[OrderBy] = Field(default=OrderBy.desc, description="The order by which to sort results.")
limit: int = Field(default=10, description="The maximum number of rows to return.")
# In a real application, this function would connect to a database and execute the query.
def execute_query(query: Query) -> List[dict]:
"""Simulates executing a database query based on the Pydantic model."""
print(f"--- Executing Query ---")
print(query.model_dump_json(indent=2))
print(f"-----------------------")
# This is a mock response for a specific, simple query.
if query.table_name == Table.customers and Column.customer_name in query.columns and query.limit == 5:
return [
{"customer_name": "Alpha Corp"},
{"customer_name": "Beta Labs"},
{"customer_name": "Gamma Ltd"},
{"customer_name": "Delta Inc"},
{"customer_name": "Epsilon Co"}
]
# Return an empty list for any other query to simulate no results found.
return []
2. Integreer de tool met de OpenAI-client
Vervolgens schrijf ik de agent-loop. Deze maakt een eerste aanroep naar de LLM om te beslissen welke tool moet worden gebruikt, voert de tool uit, en maakt vervolgens een tweede aanroep met de resultaten van de tool om een definitief, menselijk leesbaar antwoord te krijgen. Dit tweestaps proces is fundamenteel voor agentisch gedrag.
Aangezien de standaard openai-bibliotheek een JSON-schema voor tools nodig heeft, zal ik een kleine helper maken om ons Pydantic-model te converteren.
# agent_app.py
import openai
import json
from openai.types.chat.completion_create_params import Tool
from pydantic import BaseModel
from query_tool import Query, execute_query, Column, Table, Operator, Condition, DynamicValue
# Helper om een Pydantic-model te converteren naar het OpenAI-toolformaat
def pydantic_to_tool(model: type[BaseModel]) -> Tool:
schema = model.model_json_schema()
return {
"type": "function",
"function": {
"name": schema["title"],
"description": schema.get("description", ""),
"parameters": schema
}
}
# Initialiseer de client. Zorg ervoor dat de omgevingsvariabele OPENAI_API_KEY is ingesteld.
client = openai.OpenAI()
def run_agentic_workflow(user_prompt: str) -> str:
messages = [
{"role": "system", "content": "You are a helpful assistant. The current date is March 31, 2026. You help users query data by calling the Query tool."},
{"role": "user", "content": user_prompt},
]
tools = [pydantic_to_tool(Query)]
try:
# Eerste aanroep: Laat de LLM beslissen welke tool te gebruiken.
first_response = client.chat.completions.parse(
model="gpt-4o",
messages=messages,
tools=tools,
)
response_message = first_response.choices[0].message
tool_calls = response_message.tool_calls
if not tool_calls:
return response_message.content or "I was unable to process your request."
# Voeg de beslissing van de assistent om een tool aan te roepen toe aan de berichtengeschiedenis.
messages.append(response_message)
# Voer de tool calls uit.
for tool_call in tool_calls:
if tool_call.function.name == "Query":
try:
arguments = json.loads(tool_call.function.arguments)
query_instance = Query(**arguments)
tool_output = execute_query(query_instance)
messages.append(
{
"tool_call_id": tool_call.id,
"role": "tool",
"name": "Query",
"content": json.dumps(tool_output),
}
)
except (json.JSONDecodeError, TypeError) as e:
return f"Error parsing tool arguments: {e}"
# Tweede aanroep: Geef de tool-output aan de LLM om een definitief antwoord te genereren.
final_response = client.chat.completions.parse(
model="gpt-4o",
messages=messages,
)
return final_response.choices[0].message.content
except Exception as e:
return f"An error occurred: {e}"
if __name__ == "__main__":
prompt_simple = "Get me the first 5 customer names"
print(f"User: {prompt_simple}")
response_simple = run_agentic_workflow(prompt_simple)
print(f"Agent: {response_simple}")
prompt_complex = "Find all orders placed in May of last year that were fulfilled but not delivered on time, ordered by latest. Limit to 3."
print(f"\nUser: {prompt_complex}")
response_complex = run_agentic_workflow(prompt_complex)
print(f"Agent: {response_complex}")
Verwachte Output:
User: Get me the first 5 customer names
--- Executing Query ---
{
"table_name": "customers",
"columns": [
"customer_name"
],
"conditions": [],
"order_by": "desc",
"limit": 5
}
-----------------------
Agent: Here are the first 5 customer names I found: Alpha Corp, Beta Labs, Gamma Ltd, Delta Inc, and Epsilon Co.
User: Find all orders placed in May of last year that were fulfilled but not delivered on time, ordered by latest. Limit to 3.
--- Executing Query ---
{
"table_name": "orders",
"columns": [
"id",
"ordered_at",
"delivered_at",
"expected_delivery_date"
],
"conditions": [
{
"column": "ordered_at",
"operator": ">=",
"value": "2025-05-01"
},
{
"column": "ordered_at",
"operator": "<",
"value": "2025-06-01"
},
{
"column": "status",
"operator": "=",
"value": "fulfilled"
},
{
"column": "delivered_at",
"operator": ">",
"value": {
"column_name": "expected_delivery_date"
}
}
],
"order_by": "desc",
"limit": 3
}
-----------------------
Agent: I searched for orders matching your criteria but did not find any results.
Probleemoplossing en verificatie
Wanneer u LLM-aanroepen en externe tools aan elkaar koppelt, zijn er enkele veelvoorkomende faalpunten. Hier is hoe ik ze debug.
Verificatiecommando's:
Zorg er eerst voor dat uw omgeving in orde is.
python3.12 -c "import openai; print(f'OpenAI version: {openai.__version__}')"
python3.12 -c "import pydantic; print(f'Pydantic version: {pydantic.__version__}')"
# Expected output:
# OpenAI version: 1.x.x
# Pydantic version: 2.x.x
Voer vervolgens de agenttoepassing uit om de volledige lus te controleren:
python3.12 agent_app.py
Veelvoorkomende fouten en oplossingen:
-
Fout: De LLM hallucineert argumenten of slaagt er niet in de tool aan te roepen.
- Oplossing: Dit komt bijna altijd neer op de kwaliteit van de beschrijving van uw tool. Zorg ervoor dat in
query_tool.pyde hoofd-Query-docstring en elkeField(description=...)glashelder zijn. Het model gebruikt deze beschrijvingen om te beslissen wat het moet doen. Als het verward is, herschrijf ze dan om explicieter te zijn.
- Oplossing: Dit komt bijna altijd neer op de kwaliteit van de beschrijving van uw tool. Zorg ervoor dat in
-
Fout: `PydanticValidationError: 1 validation error for Query ...
* **Oplossing:** Dit betekent dat de door de LLM gegenereerde argumenten niet overeenkwamen met uw Pydantic-schema. Dit is een goede zaak – uw code vangt een modelfout op. De oorzaak is meestal hetzelfde als het eerste punt: onduidelijke beschrijvingen. Mogelijk moet u ook de systeemprompt in
agent_app.py` verfijnen om het gedrag van het model beter te sturen.
- Fout: `BadRequestError: 400 ... does not support tool calling.
* **Oplossing:** U gebruikt een model dat de tool-calling API niet ondersteunt. Controleer uw
model=-parameter. Modellen zoalsgpt-4o-2024-08-06of Google'sgemini-2.5-flash` zijn hiervoor ontworpen. Controleer altijd de officiële documentatie van de leverancier voor de mogelijkheden van het model.
Belangrijkste leerpunten
De hardwareoorlog gaat niet over één chip die wint; het gaat over het gebruik van de juiste tool voor de juiste taak. Mijn ervaring heeft aangetoond dat een gesplitste architectuur de meest effectieve benadering is voor het bouwen van duurzame, hoogwaardige AI-systemen.
-
Training = GPU's: Voor het zware werk van modeltraining en grootschalige fine-tuning blijven NVIDIA GPU's de meest performante en kosteneffectieve keuze.
-
Inferentie = NPU's: Voor real-time, lage-latency applicaties, vooral agentische workflows, is gespecialiseerd silicium (NPU's, LPU's, TPU's) onmisbaar. De efficiëntiewinst vertaalt zich direct in betere marges en een responsievere gebruikerservaring.
-
Architect voor beide: Plan uw AI-stack om beide te benutten. Uw trainingspijplijnen moeten op GPU-clusters draaien, terwijl uw inferentie-endpoints moeten worden geïmplementeerd op NPU-versnelde platforms.
-
Beheer uw uitgaven: GPU's zijn duur. Implementeer strikte FinOps-governance om inactieve trainingsclusters uit te schakelen en het gebruik te monitoren. Voor inferentie is de overstap naar NPU's op zichzelf een belangrijke kostenoptimalisatiestrategie.
Als volgende stap raad ik u ten zeerste aan om een eenvoudige agent te prototypen met uw eigen aangepaste tool, met behulp van de code in dit artikel als uitgangspunt. Het implementeren ervan en het zelf ervaren van de prestaties zal de architecturale afwegingen onmiddellijk duidelijk maken. De toekomst van AI-applicaties is efficiënt, real-time en steeds agentischer – en die toekomst draait op gespecialiseerd silicium.
