환불 여부와 긴급도를 판단하려고 같은 고객 기록을 두 번 읽히고 있다면, 모델 크기보다 요청 구조를 먼저 볼 이유가 있습니다. Flide는 하나의 상태에 붙은 여러 판단 질문을 처리하는 엔진입니다. 빠른 답이 원래의 답과 같은지 확인하는 일이 도입의 출발점입니다.
공식 README는 최대 9.5배를 내세우지만, 이 숫자는 모든 모델의 공통 성능이 아닙니다. 11월 9일 확인한 README에는 그보다 큰 개별 셀도 있습니다. 제목의 최대값과 계속 갱신되는 모델 표를 하나의 고정된 벤치마크로 취급하면 안 됩니다. 이 글은 원문과 공개 인터페이스 검토이며 GPU 실행 결과가 아닙니다.
질문을 합치는 것과 상태를 공유하는 것은 다르다
일반적인 구현은 같은 기록에 질문을 하나씩 붙여 독립 실행합니다. 공통 입력을 반복 처리하는 비용이 발생합니다. 반대로 질문을 모두 하나의 프롬프트에 넣으면 다른 질문의 문구가 답에 영향을 줄 수 있습니다.
Flide가 설명하는 Exact State Forking의 계약은 공통 상태의 계산을 공유하되 각 질문의 답은 단독 질문의 답과 일치시키는 것입니다. 독립성은 제품 요구사항입니다. 고객 기록이 같아도 환불 정책 버전이나 이미지 전처리가 다르면 같은 상태로 취급할 수 있는지 따로 확인해야 합니다.
고객 기록 → 공통 상태 계산 ┬→ 환불 질문 → 선택 결과
└→ 긴급도 질문 → 판단 결과
공식 구조를 설명하기 위한 자체 개념 도식입니다. 메모리 할당이나 실제 커널 실행 순서를 표현하지 않습니다. 기존의 RAG 설명과 연결하면, 검색한 근거를 상태로 고정한 뒤 여러 결정을 내리는 경계를 생각할 수 있습니다. 검색 근거의 정확성은 엔진이 보장하지 않습니다.
Flide 논문 §3의 ForkAttention은 요청을 공통 trunk와 독립 branch의 트리로 표현합니다. 토큰 간 정보를 섞는 층에서는 공통 trunk에 접근하되 형제 branch를 격리해야 합니다. 표준 attention뿐 아니라 과거를 하나의 행렬 상태로 접는 Gated DeltaNet 같은 순환 층에도 이 경계를 적용해야 한다는 것이 단순 prefix cache와의 중요한 차이입니다. 논문이 제시하는 일치성 보장은 정확한 산술에서의 성질이며, 실제 부동소수점 실행의 배치별 비트 일치는 별도 문제입니다.
비교표의 분모부터 읽는다
| README의 조건 | 해석에 필요한 구분 |
|---|---|
| H200 한 장, 워크로드별 요청 지연시간 중앙값 | 동시 사용자 부하의 p95나 처리량이 아님 |
| 채팅 모델은 vLLM·SGLang 중 빠른 엔진 | 모든 모델이 같은 비교 대상을 쓰지 않음 |
| OneJev는 기존 qev 엔진 | vLLM 대비 수치로 옮기면 오류 |
| KnowLine 35B는 FP8 설정 | 정밀도 조건을 함께 유지해야 함 |
| ~ 표시는 시험한 크기들의 평균 | 단일 모델 크기의 값과 구분 |
수치는 개발팀 측정이며 독립 재현은 수행하지 않았습니다. 버전·질문 수·입력 길이·워밍업·동시성까지 고정해야 서비스에 의미 있는 비교가 됩니다. 중앙값이 개선돼도 캐시 메모리나 꼬리 지연시간이 나빠질 수 있습니다.
실행 전에 정해야 할 검증 계약
Quick start의 /v1/systemone은 state와 이름별 questions를 받습니다. 다음은 구조 설명용 JSON이며 서버에 전송하지 않았습니다. choice와 noul은 공식 예제에 있는 유형입니다.
{
"state": "Order arrived with a cracked screen.",
"questions": {
"action": {
"type": "choice",
"instructions": "What should support do next?",
"criteria": {"replace": "send a replacement", "escalate": "ask a human"}
},
"urgent": {"type": "noul", "instructions": "Does this need a reply within the hour?"}
}
}
설치와 모델 다운로드에는 CUDA 환경과 해당 모델의 라이선스 검토가 선행돼야 합니다. 여기서는 설치·다운로드를 하지 않았습니다. 실제 평가에서는 같은 상태와 질문을 독립 실행한 기준 결과를 보관하고, 질문 순서·배치 구성·반복 실행을 바꿔 비교하세요. README의 flide verify는 자체 요청 검증의 출발점입니다. --batch-invariant는 배치와 무관한 비트 일치를 위한 별도 선택이며 속도 비용이 있다고 명시돼 있습니다. Exact라는 이름만 보고 기본 설정에서 모든 부동소수점 비트까지 같다고 가정하지 마세요.
11월 9일 업데이트가 넓힌 것과 남긴 것
News는 0.1.9의 여러 요청 본문 지원과 0.1.10의 Ainvest·Darwin·KnowLine 모델 추가, KnowLine 이미지 입력을 기록합니다. 이는 엔진의 최초 공개일이 아닙니다. 저장소는 10월 24일 첫 릴리스를 기록합니다. 이미지 지원도 모든 모델의 공통 기능으로 확대 해석할 수 없습니다.
공통 상태가 길고 질문이 여러 개인 서비스는 우선 평가할 가치가 있습니다. 단일 질문, 매번 완전히 바뀌는 상태, 지원하지 않는 모델이라면 재사용 이득이 줄거나 적용 자체가 어렵습니다. 판단 모델의 오류나 편향은 상태 재사용으로 사라지지 않습니다. 먼저 결과 일치성에 통과 기준을 두고, 그다음 실제 부하의 지연시간·메모리·비용을 비교하는 것이 이 엔진을 평가하는 순서입니다.