So vermeiden Sie Kostenexplosionen beim Ausführen von Code in der Vercel Sandbox
TuBrief 편집팀
2026년 7월 23일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Das Ausführen von durch LLMs generiertem Code auf einem Server hinterlässt immer ein mulmiges Gefühl. Um unberechenbaren Code einzudämmen, ist eine isolierte Umgebung unerlässlich. Die Vercel Sandbox liefert eine sauber verpackte Firecracker microVM, doch wer sie unüberlegt nutzt, wird doppelt getroffen: von der Abrechnung und von der Latenz.
Von der Abrechnungsstruktur, die ohne durchdachtes Konzept schnell Ihr Bankkonto leert, über 16-sekündige Cold-Start-Verzögerungen bis hin zu MCP-Server-Problemen, die den Kontext auffressen – hier sind praxiserprobte Lösungen direkt aus dem Arbeitsalltag zusammengestellt.
Ein Blick auf die Preisliste der Vercel Sandbox zeigt, dass Active CPU und Provisioned Memory getrennt abgerechnet werden. Im Pro-Tarif kostet Active CPU $0,128 pro vCPU-Stunde, abgerechnet auf Millisekundenbasis. Das Interessante daran: Während I/O-Wait-Zeiten, in denen auf externe LLM-Antworten oder DB-Queries gewartet wird, betragen die CPU-Kosten genau $0.
Das eigentliche Problem ist der Arbeitsspeicher. Für Provisioned Memory werden basierend auf der zugewiesenen Kapazität über die gesamte verstrichene Zeit (Wall-clock time), in der die Sandbox aktiv ist, $0,0212 pro GB-Stunde fällig. Da auf mindestens 1 Minute aufgerundet wird, bezahlen Sie selbst bei einer Nutzung von nur 5 Sekunden die volle Minute. Hinzu kommen Instanz-Erstellungskosten von $0,60 pro 1.000.000 Aufrufe.
[Benutzeranfrage] -> [Sandbox-Erstellung ($0,60/1 Mio. Aufrufe)] | +--> Active CPU: $0,128 pro vCPU-Stunde (ms-genau, I/O Wait $0) +--> Provisioned Memory: $0,0212 pro GB-Stunde (Laufzeit, 1-Min-Aufrundung) | [Aufgabe abgeschlossen] -> [sandbox.stop() explizit aufrufen] -> [Speicherabrechnung sofort gestoppt]
Wenn Sie auf einem nackten Container ohne Konfiguration TypeScript, Zod und Axios über npm installieren, dauert der Bootvorgang stolze 16,49 Sekunden. Für einen Echtzeitdienst ist das inakzeptabel – die Nutzer wären längst abgesprungen. Erst durch die Kombination von Instanz-Kaskadierung und Snapshots sinkt die Zeit auf unter 500 ms.
sandbox.snapshot().snapshotId an. Die Bootzeit verringert sich dadurch auf 410 ms.sandbox.stop() auf, sobald die Codeausführung beendet ist. Andernfalls summieren sich die Speicherkosten während der Leerlaufzeit weiter auf. Allein diese Struktur reduziert die Rechenkosten um 40 %.`typescript
import { Sandbox, Snapshot } from '@vercel/sandbox';
import { config } from 'dotenv';
config({ path: '.env.local' });
export class SandboxWarmPoolManager {
private static cachedSnapshotId: string | null = null;
public async getOrCreateBaseSnapshot(): Promise {
if (SandboxWarmPoolManager.cachedSnapshotId) {
return SandboxWarmPoolManager.cachedSnapshotId;
}
const sandbox = await Sandbox.create({
runtime: 'node24',
timeout: 5 * 60 * 1000,
});
try {
await sandbox.runCommand({
cmd: 'npm',
args: ['install', 'typescript', 'zod', 'axios', 'lodash'],
});
const snapshot = await sandbox.snapshot({
expiration: 14 * 24 * 60 * 60 * 1000,
});
SandboxWarmPoolManager.cachedSnapshotId = snapshot.snapshotId;
return snapshot.snapshotId;
} finally {
await sandbox.stop();
}
}
public async acquireWarmSandbox(tenantId: string): Promise {
const snapshotId = await this.getOrCreateBaseSnapshot();
const sandbox = await Sandbox.create({
source: { type: 'snapshot', snapshotId },
timeout: 2 * 60 * 1000,
resources: { vcpus: 2 },
tags: { tenantId },
});
return sandbox;
}
public async safeRelease(sandbox: Sandbox): Promise {
try {
await sandbox.stop();
} catch (error) {
console.error(Sandbox termination failed: ${sandbox.name}, error);
}
}
}
`
Bei der Nutzung des Model Context Protocol (MCP) stößt man schnell an Grenzen. Mit jedem Tool, das dem Server hinzugefügt wird, füllt sich der obere Teil des Prompts zunehmend mit JSON-Schemata. Ein einzelnes Tool verbraucht etwa 550 bis 1.400 Token. Verbindet man mehrere MCP-Server mit insgesamt über 50 Tools, verdampfen 55.000 Token, bevor überhaupt die eigentliche Benutzerfrage verarbeitet wird. Neben den reinen Token-Kosten führt dies dazu, dass das LLM den Überblick verliert und erfundene Parameter generiert.
| Vergleichspunkt | Traditioneller Upfront-Ansatz (Vorab-Injektion) | Einzel-Orchestrator Code Mode Ansatz |
|---|---|---|
| Kontext-Vorabverbrauch | 30.000 ~ 55.000+ Token | ~800 Token (nur Meta-Tool-Schema) |
| Mehrstufige Task-Roundtrips | 12 ~ 19 sequenzielle LLM-Aufrufe | Unter 4 Ausführungen via einzelnem Codeblock |
| Antwortzeit & Kosten | Hohe Token-Kosten, 3~5s Latenz | 58 % weniger Token-Verbrauch, >2s schneller |
| Parameter-Präzision | Halluzinationen durch hohe Schemadichte | Exakte Übergabe dank TypeScript-Typprüfung |
Das Auflisten von Dutzenden Schemata im Prompt ist ineffizient. Besser ist es, einen TypeScript-Orchestrator in der Sandbox auszuführen und nur minimale Schnittstellen offenzulegen.
`typescript
import { Sandbox } from '@vercel/sandbox';
interface OrchestrationRequest {
userQuery: string;
targetModules: string[];
generatedCode: string;
}
export class MCPCodeOrchestrator {
private sandbox: Sandbox | null = null;
public async initializeOrchestrator(): Promise {
this.sandbox = await Sandbox.create({
runtime: 'node24',
timeout: 3 * 60 * 1000,
resources: { vcpus: 2 },
});
await this.sandbox.writeFiles([
{
path: '/vercel/sandbox/runner.ts',
content: Buffer.from(`
const moduleRegistry = new Map<string, any>();
export async function executeTask(code: string, activeModules: string[]) {
for (const mod of activeModules) {
if (!moduleRegistry.has(mod)) {
const loaded = await import(\`./modules/\${mod}.js\`);
moduleRegistry.set(mod, loaded);
}
}
const asyncFn = new Function('registry', 'console', \`
return (async () => {
\${code}
})();
\`);
return await asyncFn(moduleRegistry, console);
}
`),
},
]);
}
public async dispatchExecution(request: OrchestrationRequest) {
if (!this.sandbox) throw new Error('Orchestrator not initialized');
const executionScript = `
import { executeTask } from './runner.js';
executeTask(${JSON.stringify(request.generatedCode)}, ${JSON.stringify(request.targetModules)})
.then(result => console.log('__RESULT__:' + JSON.stringify(result)))
.catch(err => console.error('__ERROR__:' + err.message));
`;
await this.sandbox.writeFiles([
{
path: '/vercel/sandbox/exec-spec.ts',
content: Buffer.from(executionScript),
},
]);
const commandResult = await this.sandbox.runCommand({
cmd: 'npx',
args: ['tsx', '/vercel/sandbox/exec-spec.ts'],
});
const stdout = await commandResult.stdout();
const stderr = await commandResult.stderr();
if (commandResult.exitCode !== 0) {
throw new Error(`Execution failed: ${stderr}`);
}
const resultMatch = stdout.match(/__RESULT__:(.*)/);
return resultMatch ? JSON.parse(resultMatch[1]) : stdout;
}
}
`
Das schlimmste Szenario beim Ausführen von fremdem Code auf dem eigenen Server ist das Ausspähen des internen Netzwerks oder das Entwenden von Tokens über externe C2-Server. Auch wenn Vercel Sandbox standardmäßig unter dem Non-Root-Account vercel-sandbox läuft, sollten Sie sich nicht allein darauf verlassen. Der Zugriff muss an den Netzwerkgrenzen konsequent abgesichert werden.
`
[Schrittweiser Ablauf der Netzwerk-Firewall-Umschaltung]
Paketinstallationsphase
[Sandbox] ---> (SNI Allow: registry.npmjs.org) ---> [NPM Registry]
Codeausführungs- und LLM-Aufrufphase
[Sandbox] ---> (SNI Allow: ai-gateway.vercel.sh + Header Injection) ---> [AI Gateway]
Ergebnisübertragung und Sitzungsbeendigungsphase
[Sandbox] ---> (S3/R2 Datei-Upload) ---> [rm -rf Dateilöschung] ---> (deny-all Einstellung vor Vernichtung)
`
Dynamische Egress-Steuerung: Öffnen Sie während der npm-Installation nur registry.npmjs.org. Bei der Ausführung schränken Sie die Verbindungen über sandbox.updateNetworkPolicy() so ein, dass ausschließlich konfigurierte Gateway-Domains erlaubt sind.
Verbergen von API-Keys: OpenAI- oder Anthropic-Keys direkt in die Umgebungsvariablen der Sandbox einzufügen, stellt ein Sicherheitsrisiko dar. Indem der x-api-key-Header an der Firewall-Grenze injiziert wird (Header Injection), bleibt die Existenz des Schlüssels innerhalb des Containers komplett verborgen.
Dateien extrahieren und verwerfen: Generierte Medien oder Dateien werden zu Cloudflare R2 oder S3 übertragen, anschließend mittels rm -rf bereinigt und nach dem Setzen von deny-all beendet.
`typescript
import { Sandbox } from '@vercel/sandbox';
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
export class SecureSandboxRunner {
private s3Client: S3Client;
constructor() {
this.s3Client = new S3Client({
region: 'auto',
endpoint: https://${process.env.R2_ACCOUNT_ID}.r2.cloudflarestorage.com,
credentials: {
accessKeyId: process.env.R2_ACCESS_KEY_ID!,
secretAccessKey: process.env.R2_SECRET_ACCESS_KEY!,
},
});
}
public async runUntrustedPipeline(userCode: string, tenantId: string) {
const sandbox = await Sandbox.create({
runtime: 'node24',
timeout: 5 * 60 * 1000,
networkPolicy: {
allow: ['registry.npmjs.org'],
},
});
try {
await sandbox.updateNetworkPolicy({
allow: {
'ai-gateway.vercel.sh': [
{
transform: [
{
headers: {
'x-api-key': process.env.AI_GATEWAY_API_KEY!,
},
},
],
},
],
},
});
await sandbox.writeFiles([
{ path: '/vercel/sandbox/index.js', content: Buffer.from(userCode) },
]);
const execResult = await sandbox.runCommand('node', ['/vercel/sandbox/index.js']);
if (execResult.exitCode !== 0) {
throw new Error(`Execution error: ${await execResult.stderr()}`);
}
const mediaBuffer = await sandbox.fs.readFile('/vercel/sandbox/output.mp4');
const storageKey = `tenants/${tenantId}/exports/${Date.now()}_output.mp4`;
await this.s3Client.send(
new PutObjectCommand({
Bucket: process.env.R2_BUCKET_NAME!,
Key: storageKey,
Body: mediaBuffer,
ContentType: 'video/mp4',
})
);
await sandbox.runCommand('rm', ['-rf', '/vercel/sandbox/*']);
return {
success: true,
mediaUrl: `https://${process.env.R2_PUBLIC_DOMAIN}/${storageKey}`,
};
} finally {
await sandbox.updateNetworkPolicy('deny-all');
await sandbox.stop();
}
}
}
`
Vercel Sandbox Pro bietet 2 GB RAM pro vCPU. Bei einer Konfiguration mit 8 vCPUs stehen 16 GB zur Verfügung, was auf den ersten Blick ausreichend wirkt. Startet man jedoch innerhalb der Sandbox ein Headless Chromium über Remotion und führt FFmpeg aus, füllt der Framebuffer den Speicher rasch auf, bis der Linux OOM Killer eingreift. Das ist der Grund, warum Prozesse mitten im Rendering mit einem SIGKILL abbrechen.
Um dieses Problem zu vermeiden, sollte der speicherintensive monolithische Rendering-Ansatz durch eine aufgeteilte, parallele Verarbeitung ersetzt werden.
offthreadVideoCacheSizeInBytes auf maximal 512 MB und begrenzen Sie die Nebenläufigkeit (concurrency) auf maximal die Anzahl der CPU-Kerne..ts-Format (h264-ts), um das spätere Zusammenfügen zu erleichtern.combineChunks() aus @remotion/renderer ohne Re-Encodierung zusammen.`typescript
import { Queue, Worker, Job } from 'bullmq';
import { Sandbox } from '@vercel/sandbox';
import { combineChunks } from '@remotion/renderer';
import Redis from 'ioredis';
import { writeFileSync, mkdirSync } from 'fs';
import { join } from 'path';
const connection = new Redis(process.env.REDIS_URL || 'redis://localhost:6379', {
maxRetriesPerRequest: null,
});
export interface RenderChunkJobData {
compositionId: string;
serveUrl: string;
frameRange: [number, number];
chunkIndex: number;
totalChunks: number;
fps: number;
}
export const renderQueue = new Queue('video-render-queue', { connection });
export const renderWorker = new Worker(
'video-render-queue',
async (job: Job) => {
const { compositionId, serveUrl, frameRange, chunkIndex } = job.data;
const sandbox = await Sandbox.create({
runtime: 'node24',
timeout: 10 * 60 * 1000,
resources: { vcpus: 4 },
});
try {
const renderScript = `
import { renderMedia } from '@remotion/renderer';
async function run() {
await renderMedia({
composition: ${JSON.stringify({ id: compositionId })},
serveUrl: ${JSON.stringify(serveUrl)},
outputLocation: '/vercel/sandbox/chunk_${chunkIndex}.ts',
frameRange: ${JSON.stringify(frameRange)},
codec: 'h264-ts',
audioCodec: 'pcm-16',
enforceAudioTrack: true,
concurrency: 2,
offthreadVideoCacheSizeInBytes: 512 * 1024 * 1024,
});
}
run().catch(err => { console.error(err); process.exit(1); });
`;
await sandbox.writeFiles([
{ path: '/vercel/sandbox/render-chunk.ts', content: Buffer.from(renderScript) },
]);
const result = await sandbox.runCommand('npx', ['tsx', '/vercel/sandbox/render-chunk.ts']);
if (result.exitCode !== 0) {
throw new Error(`Chunk ${chunkIndex} failed: ${await result.stderr()}`);
}
const chunkBuffer = await sandbox.fs.readFile(`/vercel/sandbox/chunk_${chunkIndex}.ts`);
return { chunkIndex, chunkData: chunkBuffer.toString('base64') };
} finally {
await sandbox.stop();
}
},
{
connection,
concurrency: 4,
limiter: {
max: 10,
duration: 1000,
},
}
);
export async function orchestrateParallelRender(
compositionId: string,
serveUrl: string,
totalFrames: number,
fps: number
): Promise {
const framesPerChunk = 150;
const chunkPromises = [];
const totalChunks = Math.ceil(totalFrames / framesPerChunk);
for (let i = 0; i < totalChunks; i++) {
const startFrame = i * framesPerChunk;
const endFrame = Math.min((i + 1) * framesPerChunk - 1, totalFrames - 1);
const job = await renderQueue.add(`chunk-${i}`, {
compositionId,
serveUrl,
frameRange: [startFrame, endFrame],
chunkIndex: i,
totalChunks,
fps,
});
chunkPromises.push(job.waitUntilFinished(renderWorker.opts.queueEvents!));
}
const results = await Promise.all(chunkPromises);
results.sort((a, b) => a.chunkIndex - b.chunkIndex);
const workDir = join(process.cwd(), tmp_render_${Date.now()});
mkdirSync(workDir, { recursive: true });
const videoFiles: string[] = [];
results.forEach((res, idx) => {
const filePath = join(workDir, chunk_${idx}.ts);
writeFileSync(filePath, Buffer.from(res.chunkData, 'base64'));
videoFiles.push(filePath);
});
const finalOutputPath = join(workDir, 'final_output.mp4');
await combineChunks({
videoFiles,
audioFiles: [],
outputLocation: finalOutputPath,
codec: 'h264',
fps,
framesPerChunk,
compositionDurationInFrames: totalFrames,
});
return finalOutputPath;
}
`
Vercel Sandbox ist komfortabel, kann aber ohne die richtigen Vorkehrungen schnell zu hohen Infrastrukturkosten und Sicherheitsrisiken führen. Beginnen Sie damit, den Ressourcenverbrauch durch Snapshot-basiertes Caching zu reduzieren und Verschwendung bei Prompts durch den Einsatz eines Orchestrators zu verhindern.