Verwalten von Cortex-AI-Funktionskosten mit Kontonutzung¶
Snowflake Cortex-AI-Funktionen (AI_COMPLETE, AI_SUMMARIZE, AI_TRANSLATE, AI_SENTIMENT und andere) verbrauchen Credits auf Basis der Nutzung von Token oder Seiten. Ohne Überwachung und Kontrolle können die Kosten für die Nutzung dieser Funktionen aus folgenden Gründen schnell ansteigen:
Nicht optimierte Eingabeaufforderungen, die zu viele Token generieren
Zeitintensive oder unkontrollierte Abfragen
Fehlende Ausgabenlimits pro Benutzendem
Unzureichender Einblick in die Nutzungsmuster
Unter diesem Thema werden Strategien zur Überwachung, Verwaltung und Kontrolle der mit Snowflake Cortex-AI-Funktionen verbundenen Kosten vorgeschlagen. Mit der Ansicht CORTEX_AI_FUNCTIONS_USAGE_HISTORY können Sie Nutzungsmuster verfolgen und eine automatische Kostenkontrolle implementieren. Mit diesen Techniken können Sie die Nutzung überwachen, bei Überschreitung von Ausgabenlimits warnen, den Zugriff auf Funktionen auf der Grundlage monatlicher Limits kontrollieren und unkontrollierbare Abfragen stoppen.
Ansicht des Nutzungsverlaufs¶
Die Ansicht SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY bietet detaillierte Telemetrie für alle Cortex-AI-Funktionen, die über SQL aufgerufen werden. Die Ansicht hat eine maximale Latenz von 60 Minuten, obwohl Daten bereits zehn Minuten nach Beginn der Ausführung der Funktion verfügbar sein können. Weitere Informationen zu dieser Ansicht finden Sie unter Ansicht CORTEX_AI_FUNCTIONS_USAGE_HISTORY.
Überwachung der grundlegenden Nutzung¶
Die folgenden Abfragen helfen Ihnen, Ihre Nutzungsmuster von AI-Funktionen zu verstehen. Führen Sie diese regelmäßig selbst aus, oder integrieren Sie sie in Dashboards, um die Sichtbarkeit zu erhalten.
Täglicher Credit-Verbrauch nach Funktion und Modell¶
Verfolgen Sie die täglichen Ausgabentrends, um Nutzungsspitzen zu erkennen und zu verstehen, welche Funktionen und Modelle die meisten Credits verbrauchen.
SELECT
DATE_TRUNC('day', START_TIME) AS usage_date,
FUNCTION_NAME,
MODEL_NAME,
SUM(CREDITS) AS total_credits,
COUNT(DISTINCT QUERY_ID) AS query_count
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3
ORDER BY usage_date DESC, total_credits DESC;
Monatlicher Credit-Verbrauch nach Benutzendem¶
Identifizieren Sie die Verbrauchenden, die die meisten Ressourcen nutzen, und verfolgen Sie die Ausgaben pro Benutzendem über die Zeit. Diese Abfrage wird mit der USERS-Ansicht verknüpft, um Benutzerdetails wie E-Mail-Adresse und Standardrolle bereitzustellen, um die Identifizierung und Nachverfolgung zu erleichtern.
SELECT
DATE_TRUNC('month', h.START_TIME) AS usage_month,
u.NAME AS user_name,
u.EMAIL,
u.DEFAULT_ROLE,
SUM(h.CREDITS) AS total_credits,
COUNT(DISTINCT h.QUERY_ID) AS query_count
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY h
JOIN SNOWFLAKE.ACCOUNT_USAGE.USERS u
ON h.USER_ID = u.USER_ID
WHERE h.START_TIME >= DATEADD('month', -3, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3, 4
ORDER BY usage_month DESC, total_credits DESC;
Kostenkontrolle¶
Definieren Sie automatisierte Mechanismen, um übermäßige Ausgaben zu erkennen und Korrekturmaßnahmen zu ergreifen. Diese Abfragen können unabhängig voneinander oder kombiniert werden, um eine umfassende Kostenkontrolle zu ermöglichen.
Monatlicher Ausgaben-Alert auf Kontoebene¶
Richten Sie einen automatischen Alert ein, der monatlich die Gesamtsumme für den Credit-Verbrauch bezüglich der AI-Funktionen über Ihr gesamtes Konto hinweg überwacht. Wenn die Ausgaben einen definierten Schwellenwert überschreiten, sendet der Alert eine E-Mail-Benachrichtigung an die entsprechenden Benutzenden mit Administratorrechten. Das Einrichten des Alerts erfordert die folgenden Voraussetzungen:
ACCOUNTADMIN-Rolle oder entsprechende Berechtigungen für das Erstellen von Benachrichtigungsintegrationen und Alerts
Ein Warehouse zur Ausführung der Prüfung der Alert-Bedingung
Verifizierte E-Mail-Adressen der Empfänger von Alerts
Erstellen Sie zunächst eine Benachrichtigungsintegration, falls noch keine vorhanden ist. Dieses Beispiel ersetzt jede vorhandene Integration namens ai_cost_alerts.
CREATE OR REPLACE NOTIFICATION INTEGRATION ai_cost_alerts
TYPE = EMAIL
ENABLED = TRUE
ALLOWED_RECIPIENTS = ('admin@company.com', 'finops@company.com')
Als Nächstes erstellen Sie eine Tabelle, um zu verfolgen, wann in jedem Monat Alerts gesendet wurden. Dies wird verwendet, um doppelte Alerts innerhalb eines Monats zu vermeiden.
CREATE TABLE IF NOT EXISTS AI_FUNCTIONS_ALERT_STATE (
ALERT_NAME VARCHAR NOT NULL,
ALERT_MONTH DATE NOT NULL,
SENT_AT TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP(),
CREDITS_AT_ALERT NUMBER(38,6),
PRIMARY KEY (ALERT_NAME, ALERT_MONTH)
);
Erstellen Sie nun eine gespeicherte Prozedur, um zu prüfen, ob in diesem Monat bereits ein Alert gesendet wurde, um den Alert-Status zu erfassen und um die Benachrichtigung per E-Mail zu versenden.
CREATE OR REPLACE PROCEDURE SEND_MONTHLY_SPEND_ALERT(P_THRESHOLD FLOAT)
RETURNS VARCHAR
LANGUAGE JAVASCRIPT
EXECUTE AS CALLER
AS
$$
// Check if alert already sent this month
var check_sent = snowflake.execute({
sqlText: `SELECT COUNT(*) AS cnt FROM AI_FUNCTIONS_ALERT_STATE
WHERE ALERT_NAME = 'monthly_spend'
AND ALERT_MONTH = DATE_TRUNC('month', CURRENT_DATE())`
});
check_sent.next();
var already_sent = check_sent.getColumnValue(1);
if (already_sent > 0) {
return 'Alert already sent for this month';
}
// Get current spend
var spend_result = snowflake.execute({
sqlText: `SELECT COALESCE(SUM(CREDITS), 0) AS total
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATE_TRUNC('month', CURRENT_TIMESTAMP())`
});
spend_result.next();
var v_credits = spend_result.getColumnValue(1);
// Check threshold
if (v_credits <= P_THRESHOLD) {
return 'Threshold not exceeded. Current: ' + v_credits + ' / ' + P_THRESHOLD;
}
// Record alert
snowflake.execute({
sqlText: `INSERT INTO AI_FUNCTIONS_ALERT_STATE (ALERT_NAME, ALERT_MONTH, CREDITS_AT_ALERT)
VALUES ('monthly_spend', DATE_TRUNC('month', CURRENT_DATE()), ?)`,
binds: [v_credits]
});
// Send email - update the recipient email address
snowflake.execute({
sqlText: `CALL SYSTEM$SEND_EMAIL(
'ai_cost_alerts',
'admin@company.com',
'AI Functions Monthly Spend Alert',
'Monthly AI Function credit consumption has exceeded the threshold.\\n\\n' ||
'Current spend: ' || ${v_credits}::VARCHAR || ' credits\\n' ||
'Threshold: ' || ${P_THRESHOLD}::VARCHAR || ' credits\\n\\n' ||
'Please review usage accordingly.'
)`
});
return 'Alert sent. Credits: ' + v_credits;
$$;
Erstellen Sie schließlich einen Alert, der die Nutzung jede Stunde anhand des Ausgabenschwellenwerts prüft und die Prozedur aufruft, um die Benachrichtigung bei Bedarf zu senden. Sie sollten das Limit von 1.000 Credits, das im folgenden Beispiel an zwei Stellen angezeigt wird, auf den gewünschten Schwellenwert einstellen.
CREATE OR REPLACE ALERT ai_functions_monthly_spend_alert
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 * * * * UTC' -- Runs every hour
IF (EXISTS (
SELECT 1
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATE_TRUNC('month', CURRENT_TIMESTAMP())
HAVING SUM(CREDITS) > 1000 -- adjust the limit accordingly
))
THEN
CALL SEND_MONTHLY_SPEND_ALERT(1000); -- please adjust the limit accordingly
-- enable the alert
ALTER ALERT ai_functions_monthly_spend_alert RESUME;
Tipp
Zu Testzwecken setzen Sie das Limit zunächst auf 0, um den Alert sofort auszulösen. Erstellen Sie den Alert mit dem gewünschten Schwellenwert neu, nachdem Sie sicher sind, dass er wie erwartet funktioniert.
Nachdem Sie mit einem Schwellenwert von 0 getestet haben, führen Sie die folgende SQL aus, damit der Alert im aktuellen Monat erneut ausgelöst werden kann.
DELETE FROM AI_FUNCTIONS_ALERT_STATE
WHERE ALERT_NAME = 'monthly_spend'
AND ALERT_MONTH = DATE_TRUNC('month', CURRENT_DATE());
Sie können sicherstellen, dass der Alert funktioniert, indem Sie den Alert-Verlauf und die Tabelle mit dem Alert-Status wie folgt abfragen:
-- Make sure alert exists
SHOW ALERTS LIKE 'ai_functions_monthly_spend_alert';
-- Check alert history
SELECT *
FROM TABLE(INFORMATION_SCHEMA.ALERT_HISTORY(
SCHEDULED_TIME_RANGE_START => DATEADD('day', -1, CURRENT_TIMESTAMP()),
ALERT_NAME => 'ai_functions_monthly_spend_alert'
))
ORDER BY SCHEDULED_TIME DESC;
-- Check which months have had alerts sent
SELECT * FROM AI_FUNCTIONS_ALERT_STATE ORDER BY ALERT_MONTH DESC;
Monatliche Ausgabenlimits pro Benutzendem¶
In diesem Beispiel werden monatliche Ausgabenlimits pro Benutzendem implementiert. Benutzenden wird eine eigene kundenspezifische AI_FUNCTIONS_USER_ROLE zugewiesen, die Zugang zu Cortex-AI-Funktionen bietet. In einer Tabelle wird das monatliche Token-Budget der einzelnen Benutzenden gespeichert. Wenn ein Benutzender sein Budget für den Monat überschreitet, wird ihm durch eine stündliche Aufgabe der Zugriff auf die AI-Funktionen durch Entfernen der AI_FUNCTIONS_USER_ROLE entzogen. Eine monatliche Aufgabe stellt die Rolle zu Beginn des nächsten Monats wieder her.
Wichtig
Standardmäßig haben alle Benutzenden Zugriff auf die AI-Funktionen (und weitere Snowflake Cortex-Features), da die SNOWFLAKE.CORTEX_USER-Datenbankrolle der PUBLIC-Rolle zugewiesen wird. Um Limits pro Benutzendem durchzusetzen, müssen Sie für SNOWFLAKE.CORTEX_USER PUBLIC widerrufen und nur über die AI_FUNCTIONS_USER_ROLE gewähren. Verwenden Sie die folgende SQL, um die Rolle PUBLIC zu widerrufen:
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER FROM ROLE PUBLIC;
Stellen Sie sicher, dass alle Benutzenden, die Zugriff auf Cortex-Features benötigen, nur die AI_FUNCTIONS_USER_ROLE erhalten. Die Verwendung einer beliebigen anderen Rolle, die SNOWFLAKE.CORTEX_USER einschließt, ermöglicht es Benutzenden, die in diesem Beispiel implementierten Kontrollen für Ausgabenlimits zu umgehen. In einigen Fällen können Sie eine spezifischere Rolle verwenden. So kann beispielsweise Benutzenden, die nur Zugriff auf Cortex Analyst benötigen, die SNOWFLAKE.CORTEX_ANALYST_USER-Rolle anstelle vonSNOWFLAKE.CORTEX_USER zugewiesen werden.
Um Limits für die Ausgaben pro Benutzendem festzulegen, erstellen Sie zunächst eine Rolle, die den Zugriff auf die AI-Funktionen steuert, sodass dieser Zugriff getrennt von anderen Berechtigungen verwaltet werden kann.
-- Create a role specifically for AI Function access
CREATE ROLE IF NOT EXISTS AI_FUNCTIONS_USER_ROLE;
-- Grant necessary privileges to the role
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE AI_FUNCTIONS_USER_ROLE;
-- Grant usage on warehouse
GRANT USAGE ON WAREHOUSE AI_FUNCTIONS_WAREHOUSE TO ROLE AI_FUNCTIONS_USER_ROLE;
Richten Sie nun die Zugriffssteuerungstabelle ein, die verfolgt, welche Benutzenden AI-Funktionszugriff haben und die ihre individuellen Ausgabenlimits und deren Sperrverlauf verfolgt. Sie dient als Quelle der Wahrheit für die automatisierten Überwachungs- und Wiederherstellungsprozesse für den Zugriff.
CREATE TABLE IF NOT EXISTS AI_FUNCTIONS_ACCESS_CONTROL (
USER_NAME VARCHAR NOT NULL,
USER_ID NUMBER,
GRANTED_AT TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP(),
MONTHLY_CREDIT_LIMIT NUMBER(38,6) DEFAULT 100, -- adjust the limit accordingly
IS_ACTIVE BOOLEAN DEFAULT TRUE,
REVOKED_AT TIMESTAMP_LTZ,
REVOCATION_REASON VARCHAR,
PRIMARY KEY (USER_NAME)
);
Als Nächstes erstellen Sie eine gespeicherte Prozedur, um AI-Funktionszugriff für einen Benutzenden zu gewähren und registrieren ihn in der Zugriffssteuerungstabelle mit dem entsprechenden Ausgabenlimit. Der Code sucht die Benutzer-ID in der Account Usage-Ansicht, um effiziente Verknüpfungen bei der Überwachung von Abfragen zu ermöglichen.
CREATE OR REPLACE PROCEDURE GRANT_AI_FUNCTIONS_ACCESS(
P_USER_NAME VARCHAR,
P_MONTHLY_LIMIT NUMBER(38,6) DEFAULT 100 -- adjust the limit accordingly
)
RETURNS VARCHAR
LANGUAGE SQL
AS
$$
DECLARE
v_user_id NUMBER;
BEGIN
-- Look up USER_ID from account usage
SELECT USER_ID INTO :v_user_id
FROM SNOWFLAKE.ACCOUNT_USAGE.USERS
WHERE NAME = :P_USER_NAME
LIMIT 1;
-- Grant the AI Functions role to the user
EXECUTE IMMEDIATE 'GRANT ROLE AI_FUNCTIONS_USER_ROLE TO USER ' || P_USER_NAME;
-- Register or update the user in the access control table
MERGE INTO AI_FUNCTIONS_ACCESS_CONTROL tgt
USING (SELECT :P_USER_NAME AS USER_NAME) src
ON tgt.USER_NAME = src.USER_NAME
WHEN MATCHED THEN
UPDATE SET
USER_ID = :v_user_id,
IS_ACTIVE = TRUE,
MONTHLY_CREDIT_LIMIT = :P_MONTHLY_LIMIT,
GRANTED_AT = CURRENT_TIMESTAMP(),
REVOKED_AT = NULL,
REVOCATION_REASON = NULL
WHEN NOT MATCHED THEN
INSERT (USER_NAME, USER_ID, MONTHLY_CREDIT_LIMIT, IS_ACTIVE)
VALUES (:P_USER_NAME, :v_user_id, :P_MONTHLY_LIMIT, TRUE);
RETURN 'Access granted to ' || P_USER_NAME || ' with monthly limit of ' || P_MONTHLY_LIMIT || ' credits';
END;
$$;
Verwenden Sie diese gespeicherte Prozedur, um Benutzende und deren Credit-Kontingente zur Zugriffssteuerungstabelle hinzuzufügen.
CALL GRANT_AI_FUNCTIONS_ACCESS('ALICE', 1000); -- grants access to user ALICE with a monthly limit of 100 credits
CALL GRANT_AI_FUNCTIONS_ACCESS('BOB', 2000); -- grants access to user BOB with a monthly limit of 200 credits
Erstellen Sie als Nächstes die Aufgabe für die monatliche Aktualisierung des Zugriffs. Diese Aufgabe wird am ersten Tag jedes Monats ausgeführt, um den AI-Funktionszugriff für alle berechtigten Benutzenden wiederherzustellen. Wenn der Zugriff eines Benutzenden aufgrund einer Überschreitung seines Limits im Vormonat widerrufen wurde, wird ihm durch diese Aufgabe ein neues Budget für den neuen Monat gewährt.
-- Create a procedure to re-grant access to all entitled users
CREATE OR REPLACE PROCEDURE GRANT_ALL_ENTITLED_USERS()
RETURNS TABLE (USER_NAME VARCHAR, CREDIT_LIMIT NUMBER, ACTION VARCHAR)
LANGUAGE SQL
AS
$$
DECLARE
result RESULTSET;
BEGIN
result := (
SELECT
USER_NAME,
MONTHLY_CREDIT_LIMIT AS CREDIT_LIMIT,
'GRANTED' AS ACTION
FROM AI_FUNCTIONS_ACCESS_CONTROL
);
-- Re-grant access for each entitled user
FOR rec IN result DO
CALL GRANT_AI_FUNCTIONS_ACCESS(rec.USER_NAME, rec.CREDIT_LIMIT);
END FOR;
RETURN TABLE(result);
END;
$$;
-- Create a task to run on the 1st of each month at midnight UTC
CREATE OR REPLACE TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 0 1 * * UTC' -- 1st day of each month at 00:00 UTC
AS
CALL GRANT_ALL_ENTITLED_USERS();
-- Enable the task
ALTER TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH RESUME;
-- Run once initially to populate grantees
CALL GRANT_ALL_ENTITLED_USERS();
-- Verify task status
SHOW TASKS LIKE 'MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH';
Erstellen Sie schließlich eine stündliche Aufgabe, um die Ausgaben der Benutzenden zu überwachen und jedem Benutzenden den Zugriff zu entziehen, der sein monatliches Limit überschreitet.
-- Create a procedure to re-grant access to all entitled users
CREATE OR REPLACE PROCEDURE GRANT_ALL_ENTITLED_USERS()
RETURNS TABLE (USER_NAME VARCHAR, CREDIT_LIMIT NUMBER, ACTION VARCHAR)
LANGUAGE SQL
AS
$$
DECLARE
result RESULTSET;
BEGIN
result := (
SELECT
USER_NAME,
MONTHLY_CREDIT_LIMIT AS CREDIT_LIMIT,
'GRANTED' AS ACTION
FROM AI_FUNCTIONS_ACCESS_CONTROL
);
-- Re-grant access for each entitled user
FOR rec IN result DO
CALL GRANT_AI_FUNCTIONS_ACCESS(rec.USER_NAME, rec.CREDIT_LIMIT);
END FOR;
RETURN TABLE(result);
END;
$$;
-- Create a task to run on the 1st of each month at midnight UTC
CREATE OR REPLACE TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 0 1 * * UTC' -- 1st day of each month at 00:00 UTC
AS
CALL GRANT_ALL_ENTITLED_USERS();
-- Enable the task
ALTER TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH RESUME;
-- Run once initially to populate grantees
CALL GRANT_ALL_ENTITLED_USERS();
-- Verify task status
SHOW TASKS LIKE 'MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH';
Erkennen und Abbrechen von unkontrollierten Abfragen¶
Für zeitintensive AI-Funktionsabfragen können erhebliche Kosten anfallen. In diesem Beispiel wird ein automatisiertes System implementiert, das Abfragen, die einen Credit-Schwellenwert überschreiten, erkennt und abbricht, bevor sie noch mehr Ressourcen verbrauchen. Es wird eine E-Mail-Benachrichtigung mit vollständigen Abfragedetails gesendet.
Bemerkung
Wenn eine Abfrage abgebrochen wird, werden dem Client immer noch alle bis zum Zeitpunkt des Abbruchs verbrauchten Ressourcen in Rechnung gestellt. Das Abbrechen einer aus dem Ruder gelaufenen Abfrage verhindert weitere Kosten, stellt aber keine bereits ausgegebenen Credits zurück.
Diese Prozedur findet AI-Funktionsabfragen der letzten 48 Stunden, die den Credit-Schwellenwert überschritten haben und noch ausgeführt werden, bricht diese ab und meldet sie an einen Benutzenden mit Administratorrechten.
-- Create a procedure to detect and cancel expensive runaway queries
CREATE OR REPLACE PROCEDURE MONITOR_AND_CANCEL_RUNAWAY_QUERIES(
P_CREDIT_THRESHOLD NUMBER DEFAULT 50 -- adjust the limit accordingly
)
RETURNS TABLE (
QUERY_ID VARCHAR,
USER_NAME VARCHAR,
FUNCTION_NAME VARCHAR,
MODEL_NAME VARCHAR,
CREDITS NUMBER,
START_TIME TIMESTAMP_LTZ,
ACTION VARCHAR
)
LANGUAGE SQL
AS
$$
DECLARE
result RESULTSET;
BEGIN
-- Find queries from the last 48 hours that exceed the threshold and are still running
result := (
SELECT
h.QUERY_ID,
u.NAME AS USER_NAME,
h.FUNCTION_NAME,
h.MODEL_NAME,
h.CREDITS,
h.START_TIME,
h.ROLE_NAMES,
h.QUERY_TAG,
h.WAREHOUSE_ID,
'CANCELLED' AS ACTION
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY h
LEFT JOIN SNOWFLAKE.ACCOUNT_USAGE.USERS u
ON h.USER_ID = u.USER_ID
WHERE h.START_TIME >= DATEADD('hour', -48, CURRENT_TIMESTAMP())
AND h.CREDITS > :P_CREDIT_THRESHOLD
AND h.IS_COMPLETED = FALSE
);
-- Cancel each runaway query and send alert
FOR rec IN result DO
-- Attempt to cancel the query
BEGIN
EXECUTE IMMEDIATE 'SELECT SYSTEM$CANCEL_QUERY(''' || rec.QUERY_ID || ''')';
EXCEPTION
WHEN OTHER THEN
NULL; -- Query may have already completed
END;
-- Send alert with query details
CALL SYSTEM$SEND_EMAIL(
'ai_cost_alerts',
'admin@company.com',
'Runaway AI Query Cancelled - ' || rec.QUERY_ID,
'A runaway AI Function query has been cancelled due to excessive cost.\n\n' ||
'Query Details:\n' ||
'- Query ID: ' || rec.QUERY_ID || '\n' ||
'- User: ' || COALESCE(rec.USER_NAME, 'Unknown') || '\n' ||
'- Function: ' || rec.FUNCTION_NAME || '\n' ||
'- Model: ' || rec.MODEL_NAME || '\n' ||
'- Credits Used: ' || rec.CREDITS::VARCHAR || '\n' ||
'- Threshold: ' || :P_CREDIT_THRESHOLD::VARCHAR || '\n' ||
'- Start Time: ' || rec.START_TIME::VARCHAR || '\n' ||
'- Roles: ' || COALESCE(rec.ROLE_NAMES::VARCHAR, 'N/A') || '\n' ||
'- Query Tag: ' || COALESCE(rec.QUERY_TAG, 'N/A') || '\n' ||
'- Warehouse ID: ' || COALESCE(rec.WAREHOUSE_ID::VARCHAR, 'N/A') || '\n\n' ||
'Please investigate this query and take appropriate action.'
);
END FOR;
RETURN TABLE(result);
END;
$$;
-- Create a task to monitor and cancel runaway queries every hour
CREATE OR REPLACE TASK MONITOR_RUNAWAY_AI_QUERIES
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 * * * * UTC' -- Every hour
AS
CALL MONITOR_AND_CANCEL_RUNAWAY_QUERIES(50); -- adjust the limit accordingly
-- Enable the task
ALTER TASK MONITOR_RUNAWAY_AI_QUERIES RESUME;
-- Verify task status
SHOW TASKS LIKE 'MONITOR_RUNAWAY_AI_QUERIES';
-- Check task execution history
SELECT *
FROM TABLE(INFORMATION_SCHEMA.TASK_HISTORY(
SCHEDULED_TIME_RANGE_START => DATEADD('day', -1, CURRENT_TIMESTAMP()),
TASK_NAME => 'MONITOR_RUNAWAY_AI_QUERIES'
))
ORDER BY SCHEDULED_TIME DESC;
Tipp
Möglicherweise wissen Sie bereits, dass einige Ihrer Abfragen sehr lange dauern werden. Sie können eine spezielle Rolle für diese Abfragen definieren und diese Rolle von der Abbruchlogik in der Prozedur ausschließen. So erstellen Sie beispielsweise die Rolle:
CREATE ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE;
GRANT ROLE AI_FUNCTIONS_USER_ROLE TO ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE;
GRANT ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE TO USER LONG_RUNNING_USER;
Fügen Sie die folgende Bedingung zur WHERE-Klausel der Prozedur hinzu, um auszuschließen, dass Abfragen, die von Benutzenden mit dieser Rolle ausgeführt werden, abgebrochen werden.
,, code-block:: sqlexample
AND NOT ARRAY_CONTAINS(h.ROLE_NAMES, ‚AI_FUNCTIONS_USER_LONG_RUNNING_ROLE‘)
Nun kann der Benutzende die Rolle übernehmen, um eine zeitintensive Abfrage auszuführen, ohne dass sie abgebrochen wird:
USE ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE;
-- then start the long-running query
Best Practices¶
Beachten Sie bei der Entwicklung einer Kostenmanagementstrategie für die Verwendung von AI-Funktionen die folgenden Best Practices:
Mit der Überwachung beginnen: Bevor Sie automatisierte Kontrollen implementieren, legen Sie anhand der Abfragen in Überwachung der grundlegenden Nutzung grundlegende Nutzungsmuster fest.
Konservative Anfangslimits festlegen: Beginnen Sie mit niedrigeren Schwellenwerten, und passen Sie sie basierend auf den tatsächlichen Nutzungsmustern nach oben an.
Abfrage-Tags verwenden: Ermutigen Sie Teams, QUERY_TAG-Sitzungsparameter zu verwenden, um die Zuordnung der Kosten nach Projekt oder Team zu ermöglichen.
Regelmäßig überprüfen: Überprüfen Sie die Zugriffssteuerungstabelle regelmäßig, und passen Sie die Limits pro Benutzendem auf der Grundlage berechtigter Anforderungen an.
Test-Alerts: Überprüfen Sie, ob E-Mail-Benachrichtigungen korrekt funktionieren, bevor Sie sich bei kritischen Alerts darauf verlassen.
Latenz berücksichtigen: Die ACCOUNT_USAGE-Ansicht hat eine Latenzzeit von bis zu 60 Minuten. Berücksichtigen Sie dies in Ihrer Überwachungsstrategie.