많은 팀이 단일 비스트리밍 (non-streaming) 요청으로 공유된 OpenAI 호환 API 게이트웨이를 검증한 뒤, 나중에 한 클라이언트는 스트리밍 (streaming)을 사용하고, 다른 클라이언트는 사용하지 않으며, 세 번째 클라이언트는 원시 응답 (raw response)을 숨기고 있다는 사실을 발견하곤 합니다. 그 결과, Base URL, API Key, 모델 이름이 대부분 정확함에도 불구하고 마치 제공업체(provider)의 장애처럼 보일 수 있습니다.

이 DEV 튜토리얼은 Vector Engine을 공유 LLM API 제공 계층 (provider layer)으로 사용하며, Dify, Cursor, 그리고 Node.js 애플리케이션에 연결하기 전에 두 모드 모두에서 동일한 경로를 테스트하는 방법을 보여줍니다.

알려진 하나의 경로로 시작하기

모든 곳에서 동일한 세 가지 값을 사용하세요:

Base URL: https://api.vectorengine.cn/v1
API Key: VECTOR_ENGINE_API_KEY에 저장됨
model name: gpt-4o-mini

스트리밍과 라우팅 (routing)을 동시에 테스트하지 마세요. 모델 이름이 틀리면 model_not_found 오류가 스트리밍 문제를 가려버릴 것입니다. 일반 요청으로 모델 경로를 먼저 확인한 다음, 스트리밍을 테스트하세요.

일반 Node.js 요청

plain-check.mjs를 생성합니다:

const baseUrl = "https://api.vectorengine.cn/v1";
const model = "gpt-4o-mini";

...

실행:

node plain-check.mjs

만약 이 단계에서 실패한다면, 잠시 멈추세요. Dify나 Cursor를 열기 전에 Base URL, API Key, 모델 이름을 확인하십시오.

스트리밍 Node.js 요청

stream-check.mjs를 생성합니다:

const baseUrl = "https://api.vectorengine.cn/v1";
const model = "gpt-4o-mini";

...

실행:

node stream-check.mjs

여기서 여러분은 답변의 품질을 확인하는 것이 아닙니다. 경로가 Vector Engine을 통해 스트리밍 청크 (streamed chunks)를 반환할 수 있는지 확인하는 것입니다.

비교를 위한 Dify 설정

Dify에서 제공자 (provider) 설정을 Node.js 스크립트와 비교하십시오:

만약 Dify가 스트리밍이 활성화되었을 때만 실패한다면, model_not_found와는 별개로 그 차이점을 포착하십시오. 라우팅 오류와 스트림 파싱 (stream parsing) 문제는 서로 다른 해결책을 가리킵니다.

비교를 위한 Cursor 설정

Cursor의 경우, 팀 설정 가이드 옆에 작은 메모를 남겨두세요:

Provider: Vector Engine
Base URL: https://api.vectorengine.cn/v1
model name: gpt-4o-mini
...

Cursor는 전송 (transport)의 일부를 추상화할 수 있습니다. Node.js 스크립트는 팀이 문제가 공유 게이트웨이 경로 (gateway route) 때문인지 아니면 클라이언트 동작 때문인지 판단할 수 있도록 가공되지 않은 (raw) 참조를 제공합니다.

문제 해결 (Troubleshooting) 테이블

유용한 습관은 라우팅 (routing), 인증 (authentication), 그리고 스트리밍 (streaming)을 각각 별도의 체크 항목으로 분리하는 것입니다. 가공되지 않은 (raw) Node.js 체크를 통과하고 나면, Dify와 Cursor의 문제 해결 범위는 훨씬 좁아집니다.

많은 팀이 먼저 비스트리밍 (non-streaming) 요청을 사용하여 공유된 OpenAI 호환 (OpenAI-compatible) API 게이트웨이 (gateway)를 검증한 뒤에야, 한 클라이언트는 스트리밍 (streaming)을 사용하고 다른 클라이언트는 사용하지 않으며, 또 다른 클라이언트는 원본 응답을 숨기고 있다는 사실을 발견하곤 합니다. 그 결과는 마치 제공자 (provider)의 장애처럼 보이지만, Base URL, API Key, 모델 이름 (model name)은 대체로 문제가 없는 상태일 수 있습니다.

여기서는 Vector Engine API 중계소를 공유 엔트리 (entry)로 간주합니다. 즉, 팀에서 흔히 말하는 Vector Engine 중계소입니다. 이는 API 중계소로서 라우팅 (routing), 인증 (authentication), 그리고 응답 전달 (response forwarding)의 책임을 집니다.

이 DEV 튜토리얼은 Vector Engine을 공유된 LLM API 제공자 계층 (provider layer)으로 보고, Dify, Cursor, 그리고 Node.js 애플리케이션에 연결하기 전에 동일한 경로의 비스트리밍 (non-streaming) 모드와 스트리밍 (streaming) 모드를 동시에 검증하는 방법을 보여줍니다.

하나의 알려진 경로에서 시작하기

모든 곳에서 동일한 세 가지 구성 항목을 사용합니다:

Base URL: https://api.vectorengine.cn/v1
API Key: VECTOR_ENGINE_API_KEY에 저장됨
model name: gpt-4o-mini

스트리밍 (streaming) 문제와 라우팅 (routing) 문제를 섞어서 테스트하지 마세요. 모델 이름이 틀리면 model_not_found 오류가 스트리밍 문제를 가려버릴 수 있습니다. 먼저 일반 요청을 통해 모델 경로를 확인한 다음, 스트리밍 (streaming)을 테스트하세요.

일반 Node.js 요청

plain-check.mjs를 생성합니다:

const baseUrl = "https://api.vectorengine.cn/v1";
const model = "gpt-4o-mini";

...

실행:

node plain-check.mjs

여기서 실패한다면, Dify나 Cursor를 열기 전에 먼저 Base URL, API Key, 그리고 모델 이름 (model name)을 확인하세요.

스트리밍 Node.js 요청

stream-check.mjs를 생성합니다:

const baseUrl = "https://api.vectorengine.cn/v1";
const model = "gpt-4o-mini";

...

실행:

node stream-check.mjs

이 단계는 답변의 품질을 평가하는 것이 아니라, 이 경로가 Vector Engine을 통해 스트리밍 조각 (streaming chunks)을 반환할 수 있는지 확인하는 것입니다.

Dify 설정과 대조하기

Dify에서 제공자 (provider) 설정을 Node.js 스크립트와 일치시킵니다:

Cursor 설정과 대조하기

Cursor의 경우, 팀 설정 안내(team configuration instructions)에 다음과 같은 짧은 내용을 남겨둘 수 있습니다.

Provider: Vector Engine
Base URL: https://api.vectorengine.cn/v1
model name: gpt-4o-mini
...

Cursor는 전송(transmission) 세부 사항의 일부를 추상화(abstraction)할 수 있습니다. Node.js 스크립트는 원시 참조(raw reference)를 제공하여, 문제가 공유 게이트웨이 라우팅(shared gateway routing)에서 발생하는지 아니면 클라이언트 동작(client behavior)에서 발생하는지 팀이 판단하는 데 도움을 줍니다.

점검표 (Troubleshooting Checklist)

등록 주소: https://api.vectorengine.cn/register?aff=Igym

라우팅(routing), 인증(authentication), 스트리밍(streaming)을 독립적으로 분리하여 점검하는 습관을 갖는 것이 가치 있습니다. 원시 Node.js 점검을 통과하고 나면, Dify와 Cursor의 점검 범위는 훨씬 좁아질 것입니다.