이수(一水), 아페이쓰(凹非寺) 발
양자위(量子位) | 공식계정 QbitAI
창위페이의 연례 글로벌 1024 개발자 페스티벌을 둘러보고 느낀 것은 단 하나:
성황리이다, 정말 성황리이다。
사진을 보면 알겠지만, 인파 속에서 두 걸음 앞으로 나아가는 게 얼마나 어려운지—
부스 앞에는 사람들이 끊이지 않고, 어떤 이는 직접 체험하고, 어떤 이들은 둘러앉아 기술을 이야기하고 세부 사항을 묻고 있으며, 현장에서 선보이는 AI 성과와 몰입형 인터랙션이 하나가 끝나기 무섭게 다음 것이 이어졌고, 하드코어 기술 함량이 한껏 가득했다.
하지만 성황함보다 더 볼 가치가 있는 것은, 이 AI 제품들이 과연 무엇을 할 수 있는가이다.
교육, 의료, 금융, 번역…… 창위페이는 이번에 일련의 산업 AI 제품을 부스에 가져왔으며, 국산 대형 모델이 구체적인 시나리오에 어떻게 진입하고, 다양한 산업에 어떻게 적응하며, 실제로 어떻게 사용되는지를 이곳에서 구체적으로 볼 수 있었다.
그중 올해 9월에 발표된 Spark-X2.5 시리즈 오픈소스 모델은 전 채널 누적 다운로드 수가 256만을 돌파했고(전 세계 엣지 모델 다운로드 4위 진입), 4B 버전은 Hugging Face 최근 7일 Trending 랭킹 1위에 오르기도 했다.
「256만 다운로드, 랭킹 1위」, 성과가 확실히 눈부시지만, 이번에 내가 진짜 주목한 것은 또 다른 일이다:
창위페이가 걷고 있는 길은 대다수 플레이어들과는 사뭇 다른 길이라는 것.
풀스택 자주 통제.
모델 훈련부터 추론, 그리고 엣지 배포까지, 창위페이는 줄곧 국산 연산으로 대형 모델 체계 전체를 떠받치고 있다.
이 길이 얼마나 어려운지는 아는 사람은 다 안다。。。
그래서 문제가 생긴다:
엔비디아 GPU에 의존하지 않고, 이 전국산 체계는 대체 중국 모델을 어느 단계까지 이끌었는가?
마침 창위페이가 최근 Spark-X2.6도 내놓았다.
그럼 뭘 더 기다리랴, 바로 강도 높은 테스트 들어간다!(흐흐흐.jpg)
전국산, 모델을 훈련하는 것만이 아니다
본격 실측에 앞서, 먼저 분명히 해둘 일이 있다:
모두 「국산 대형 모델」이라고 말하지만, 그 안의 국산 연산 노선은 사실 조금씩 다르다.
몇 가지 개념이 자주 혼동되는데, 이번에 나는 아예 정리해 보았다:
△이미지는 AI가 생성
분명히 창위페이는 마지막 그 더 어려운 길을 선택했다:
모델 훈련, 강화 학습, 지속적 반복 개선부터 추론 배포까지, 전체 체인이 국산 연산 플랫폼 위에 놓여 있다.
핵심 체인의 엔비디아 함량은 0, 어떻게 말해야 할까? 듣기만 해도 확실히 짜릿하다.
하지만 진짜 파고들어 보면, 이 일이 얼마나 어려운지 알게 된다.
지난 몇 년간 업계에서 전국산 대형 모델을 논할 때, 가장 먼저 따져 물었던 것은 보통 이것이었다:
국산 카드로, 대체 모델을 훈련해낼 수 있는가?
이것이야말로 가장 직관적인 단계이지만, 실제로 대규모 훈련에 들어가면 진짜 어려움이 나타나기 시작합니다.
엔비디아의 우위는 GPU에만 있는 것이 아니라, CUDA를 중심으로 수년간 축적해온 소프트웨어 생태계에도 있다. 국산 칩으로 바꾸면 연산자, 프레임워크부터 다카드 통신까지 모두 새로 적응시켜야 한다.
규모가 천 카드, 만 카드 규모에 이르면 훈련 효율과 클러스터 안정성이 또 새로운 시험대에 오르게 된다.
많은 작업이 모델 뒤에 숨겨져 있어 일반 사용자의 눈에는 보이지 않지만, 가장 많은 시간과 연발 자원을 소모하는 부분이다.
△이미지는 AI로 생성됨
나는 이어서 지난 몇 년간의 iFlytek 타임라인을 살펴보았는데, 이 회사의 완전 국산화에 대한 이해가 분명히 「국산 카드로 모델을 훈련한다」는 수준보다 몇 걸음 더 나아가 있음을 발견했다.
이는 iFlytek이 오랫동안 산업 현장에 깊이 뿌리내리고 있던 것과 관련이 있을 수 있다.
모델이 병원, 학교, 기업 시스템의 다양한 하드웨어 장비에 들어가면 연산력 공급, 데이터 보안, 배포 비용이 피할 수 없는 문제가 되며, 이것이 iFlytek을 더 일찍 전체 체인 국산화 노선으로 이끌었다.
2023년, iFlytek은 화웨이와 함께 「훙싱이호(飞星一号)」를 출시하여 대규모 국산 연산력 기반을 먼저 구축했다.
이후 국산 연산력 기반의 천억 파라미터 모델 Spark-V3.5, 심층 추론 모델 Spark-X1이 잇달아 나왔다.
올해 들어 Spark-X2.5는 4B와 1.7B 엔드사이드 모델을 오픈소스로 공개하며 더 많은 단말 기기로 뻗어나가기 시작했다.
Spark-X2.6까지 파고들면서 문제는 훈련에서 배포로 넘어갔다:
모델은 대체로 어디에서 실행되어야 하는가?
마침 최근에 Every의 《How Codex Happened》라는 글을 보았는데, OpenAI 역시 이 문제에서 학비를 치른 적이 있었다.
OpenAI는 처음에 Codex를 전부 클라우드에 두었지만, 환경 설정이 번거롭고 작업에 즉시 개입하기 어렵다는 이유로 벽에 부딪혔고, 이후 로컬로 방향을 바꾸며 점차 양쪽을 연결해 나갔다.
결국 왜 양쪽 모두 필요했을까? 아래 표를 보면 이해할 수 있다:
△이미지는 AI로 생성됨
클라우드는 능력에서, 엔드사이드는 오프라인 응답, 비용, 프라이버시에서 강점을 가지므로, 실제 비즈니스에 적용할 때 한쪽에만 베팅하기는 어렵다.
더 현실적인 방안은 선택권을 기업에 넘겨주는 것이다:
어떤 작업을 로컬에 두고, 어떤 작업을 클라우드에 맡기며, 어떤 데이터를 업로드할 수 있고, 한 번의 호출에 얼마나 많은 Token을 지출할지 정하는 것이다.
Spark-X2.6이 하는 일은 바로 엔드사이드와 클라우드가 필요에 따라 역할을 분담하도록 하는 것이다:
작업은 먼저 엔드사이드 모델이 판단한 후, 적합한 실행 경로를 선택하여 세 가지 협업 모드를 형성한다.。
간단한 작업은 로컬에서 바로 완료되며, 이것이「순수 엔드사이드 실행」이다.。
클라우드 능력이 필요한 작업은 먼저 엔드사이드에서 비식별화 처리를 거친 후 클라우드로 넘겨 처리하며, 이것이「순수 클라우드 실행」이다.。
양쪽의 협력이 필요한 작업은 엔드사이드에서 비식별화 처리 후「클라우드+엔드 실행」에 들어간다.—클라우드가 지도를 제공하고 엔드사이드가 작업을 수행할 수도 있고, 엔드사이드와 클라우드가 역할을 분담하여 협력함으로써 함께 작업을 완수할 수도 있다.
발상은 꽤 말이 되는데, 정말로 Token을 절약하고 프라이버시를 지켜낼 수 있을지 궁금하다?
그럼, 바로 테스트해보자.
Spark-X2.6 실측
Spark-X2.6이 현재 출시되었다쉰페이 스타잉(Xingchen) MaaS 플랫폼MoE 아키텍처를 채택했으며, 총 파라미터 수는 293B이고 추론 시마다 약 30B를 활성화하며, 1M 컨텍스트를 지원합니다.
현재 API 가격은 40% 할인된 가격으로, 백만 입력 tokens당 0.9위안, 백만 출력 tokens당 3.6위안입니다(대페이위구 가격보다 약 10% 저렴함).
9월에 출시된 X2.5에 비해, 이번 세대는 주로 세 가지 측면에서 앞으로 나아갔습니다:
작업 수행 능력이 더 강력: X2.6의 코드 및 에이전트 능력이 전체적으로 각각 약 8포인트 향상되었으며, 모델의 전반적인 실력은 업계 최상위권에 위치합니다;
국산 연산력에서 더 원활하게 구동: 학습 및 추론 아키텍처 최적화를 통해 모델이 국산 학습 플랫폼에서의 효율이 4배 향상되었고, 4계층 KV Cache의 적중률이 95%에 달합니다;
사용하기 더 경제적입니다：고빈도 애플리케이션 시나리오에서 약 60%의 작업이 Token 소비 감소를 달성했습니다.
요약하자면, 이러한 업그레이드는 여전히 그 익숙한 주제를 가리키고 있습니다:
일해라.
일하는 능력을 측정하는 것이면서 채팅창에서 몇 문제만 묻는 것으로는 명백히 충분하지 않다.
그래서 이번에는 Spark-X2.6의 API를 DeepSeek Harness에 연결하여 파일을 직접 읽고 쓰고, 코드를 실행하며, 실행 결과를 바탕으로 오류를排查하도록 했습니다.
다른 것은 잠시 두고, 먼저 이것이 현재 최고 수준의 모델들과 얼마나 큰 차이가 있는지 살펴보자.
최근 실리콘밸리 주요 모델 발표 시각화 코딩은 거의 고정 프로그램이 되었고, 자전거를 타는 펠리컨, 3D 인터랙티브 장면 등이 반복적으로 시연되었습니다.
이런 종류의 작업이 Benchmark를 대체할 수는 없지만, 결과가 충분히 직관적이라는 장점이 있기에, 첫 번째 관문에서 저도 Spark-X2.6에게 「톱스타 동일款」을 배정했습니다.
「최고 인기 스타同款」— 이 모델 자체가 얼마나 강한지 테스트해 보세요
먼저 자전거를 타는 펠리컨 한 마리부터.
프롬프트는 실리콘밸리 테스트에서 흔히 쓰이는 극미니멀 방식으로 작성되었으며, 화풍, 구도, 구현 방식을 규정하지 않고 모델에게 한 문장만 주었다:
Create an SVG of a pelican riding a bicycle. Save it as pelican.svg in the current directory and preview the result. Do not use external image assets.(자전거를 타는 펠리컨의 SVG를 만들어 현재 디렉터리에 pelican.svg 파일로 저장하고, 결과를 미리 보세요. 외부 이미지 리소스는 사용하지 마세요.)
요구 사항이 적을수록 모델 자신의 코딩 기본기와 미적 감각이 오히려 드러나기 마련이다.
아래 그림은모델이 한 번에 직접 생성의 결과, 첫눈에 보기에 완성도가确实 낮지 않다:
자전거 구조가 완전하고, 근경과 원경도 모두 채워 넣었다.
손이 잘 풀리는 김에 문제를 하나 더 추가했다:3×3 큐브 시뮬레이터。
이번에는 단순히 큐브를 순수 CSS 3D로 그리는 것에 그치지 않고, 여섯 면이 실제로 회전할 수 있도록 하고, 섞기와 리셋 기능까지 모두 구현합니다.
최종적으로 만들어진 버전도 꽤 편리한데, 의존성을 설치할 필요 없이 파일 하나만 열면 바로 실행되며, 마우스를 드래그해 시점을 바꿀 수 있고 원하는 대로 마음껏 돌릴 수 있습니다.
이제 큐브도 맞출 수 있으니, 거대한 BOSS급 궁극의 시험이라도 있어야 하지 않겠는가:
코드로 자유롭게 탐험할 수 있는 3D 자금성 만들기。
저는 AI가 생성한 프롬프트를 하나 던져 넣은 뒤, Spark-X2.6이 백그라운드에서 돌아가는 동안 밥을 먹으러 갔습니다.
돌아왔을 때 그것이 이미 index.html, style.css, main.js로 구성된 완전한 웹페이지를 납품한 것은 뜻밖이었다.
로컬 서비스를 열면 붉은 담과 금색 기와가 중심축을 따라 펼쳐지고, 마우스로 시점을 자유롭게 회전, 확대·축소 및 이동할 수 있습니다.
솔직히 말하면, 내가 예상했던 것보다 꽤 완성도가 높다.
소규모로 시험해 본 결과, Spark-X2.6은 모든 세부 사항을 한 번에 맞히지는 못했지만 피드백에 대한 반응은 매우 빠르다.
이 점은 사실 Coding Agent에게 꽤 중요합니다.
Vibe Coding을 해본 분들이라면 공감하겠지만, 「OA」 양사의 플래그십 모델을 사용하더라도 한 번의 생성으로 완전히 기대에 부합하는 결과를 얻기는 현실적으로 어렵습니다.
따라서 저에게 진정으로 경험에 영향을 주는 것은, 모델이 사람의 말을 알아들을 수 있는지, 그리고 빠르고 정확하게 수정하는지입니다.
물론 그림 그리기와 웹페이지 만들기는 아직 준비운에 불과하다. 이제부터는 진짜 일을 좀 시켜볼 차례다.
4B 모델을 컴퓨터에 넣고, 먼저 독립적으로 일하게 하기
이번의 주인공은방금 오픈 소스로 공개된 Spark-X2.6-4B。
파라미터 수는 4B에 불과하지만 최대 1M 컨텍스트와 200개 이상의 언어를 지원하며, Ollama, LM Studio 등에도 대응합니다.로컬 실행 도구, 그리고 llama.cpp, vLLM 등주류 추론 프레임워크。
4B 모델의 성능을 최대한 끌어내기 위해 아이플라이훙은 후학습 단계에능력 인지 메커니즘, 모델이 자신의 취약 항목을 판단하게 한 뒤, 서로 다른 교사 모델에게 맞춤형으로 학습한다.
훈페이(讯飞) 내부 평가에 따르면, 동일 크기의 온디바이스 모델이 독립적으로 수행할 수 있는 Agent 작업 비율은 약12.8%，而 Spark-X2.6-4B는 이 숫자를 다음으로 끌어올렸습니다41.9%。
더는 망설이지 않겠다. 노새든 말이든 끌어내 걸어봐야 안다.
제 컴퓨터에는 AMD 내장 그래픽만 있고 독립 그래픽 카드가 없어서 모델이 전 과정 동안 CPU 추론에 의존했기 때문에, 저는 Ollama를 통해 Spark-X2.6-4B의 Q4 양자화 버전을 배포하고 터미널에서 로컬 API를 호출했습니다.
모델이 성공적으로 실행된 후, 나는 곧바로 네트워크 연결을 끊어 자료 읽기, 분석 및 결과 출력이 모두 이 컴퓨터 안에 머물도록 했다.
내가 이 모델에 부여한 과제는 가상의 로봇 회사를 대신해 주간 경영 복기를 완성하는 것이었다。
판매 주간 보고서, 고객 이메일, 생산 일정 및 공급망 기록이 서로 다른 파일에 흩어져 있고 일부 정보는 서로 모순됩니다. AI는 여러 파일에 걸쳐 데이터를 대조하여 매출 변화, 고객 충돌 및 납품 위험을 찾아내고, 마지막으로 경영진의 결정을 기다리는 사항들을 목록으로 정리합니다.
결국,모델은 6.8분 만에 완전한 경영 복기 보고서를 제출했다。
이 보고서는 2550만 위안의 판매 기준 매출과 2370만 위안의 회계상 인식 수익을 구분해 정리했으며, 두 건의 주요 사업 기회와 세 가지 공급망 공백을 찾아냈고, 주요 결론에는 모두 정보 출처를 명시했다.
숫자 정확성, 파일 간 연관성, 위험 식별, 출처 추적, 보고서 완성도의 다섯 가지 차원을 종합하면, 이번 과제의 완수도는 대략 90% 정도이다.
굳이 흠을 찾자면, 보유 중인 수주 한 건을 잠재적 기회로 분류해 분류가 아직 엄밀하지 않다는 점이 있지만, 관련 사실과 금액은 모두 정확하여 간단한 수동 검토를 거친 후 이미 경영진 논의의 참고 자료로 활용할 수 있다.
완전 오프라인으로 CPU만으로 구동되는 4B 모델 치고는 이 정도 결과면 충분히 볼만하다.
민감 정보가 관련된 복잡한 작업은 클라우드가 이어서 처리하게 한다
다만 온디바이스 모델의 능력에는 결국 한계가 있어, 더 복잡한 작업을 만나면 여전히 클라우드가 나서야 한다.
그렇다면 어떤 작업은 로컬에 두고, 어떤 작업이 클라우드에 올릴 가치가 있을까?
이를 위해 아이플라이토크는 한 세트를 도입했다평语 모델 기반 단말-클라우드 라우팅 협동 학습 메커니즘。
간단히 말해, 동일한 작업을 엣지 측과 클라우드에서 각각 여러 번 실행하고, 평가 모델이 결과를 비교하여 피드백을 제공하며, 교대 훈련을 통해 라우팅 판단을 지속적으로 최적화함으로써 시스템이 한 작업을 엣지 측에 맡길지, 클라우드에 맡길지, 아니면 양쪽이 함께 수행할지 더 명확하게 파악하도록 하는 것입니다.
讯飞 내부 평가에 따르면, 이 메커니즘은 엔드-클라우드 작업 라우팅 정확도를81.2%다음과 같이 끌어올렸다96.1%。
이미 96.1%에 달했기 때문에, 이번 실측에서는 더 민감하고 연관 관계도 더 복잡한 자료를 주기로 했습니다:
산업용 시각 검사 장비 구매 계약서를 검토하다.
계약서는 여전히 가공의 것이지만, 회사명, 담당자, 전화번호, 은행 계좌, 계약 금액은 하나도 빠지지 않으며, 지급, 검수, 데이터 업로드, 지식재산권 및 위약 책임 사이에는 여러 곳에 연관 리스크가 숨어 있습니다.
먼저 로컬 4B 모델이 비식별화를 담당하도록 했다.
소요 시간 4.3분 만에 계약서 속 26개의 민감 정보가 모두 플레이스홀더로 대체되었으며, 검사 결과 원본 정보 잔존이 없는 것으로 나타났습니다.
깨끗이 처리된 것을 확인한 후에야 네트워크에 다시 연결하여, 비식별화된 계약서를 클라우드 X2.6에 넘겼다.
70.8초 후, 7368개의 토큰을 소비하여 18가지 위험과 8건의 조항 충돌을 찾아낸 완전한 검토 보고서를 제출했습니다.
마치 검수 기준이 서로 앞뒤로 충돌하거나, 데이터를 클라우드에 직접 업로드하도록 허용하면서도 공급업체에 무한 책임을 지우는 것처럼 서로 다른 조항 속에 숨어 있는 문제들도 이 시스템이 실마리를 쫓아가며 하나하나 찾아냈다.
이후 다시 네트워크를 차단하고, 로컬에서 계약서 정보를 복원한 뒤 항목별 수정 제안이 첨부된 Word 파일을 생성했다.
자기가 자기 채점을 하는 일을 피하기 위해, 전체 자료를 Codex에 넘겨 한 번 더 검토하게 했다.
그 결과 클라우드로 전송된 계약서에는 원본 민감 정보가 없었고, 로컬에서 복원한 후에도 어떤 자리표시자(placeholder)도 남아 있지 않았으며, 계약서 본문과 표 역시 그대로 온전히 보존되어 있었다.
여기에 이르러서야 전체 흐름이 비로소 완전히 작동했다:
민감 정보는 로컬에 남기고, 복잡한 분석은 클라우드에 맡긴 뒤, 처리가 끝나면 다시 로컬로 돌아와 복원한다.
말해둘 것은, 이번에는 최소한의 실현 가능성 검증만 진행했다는 점이다.
각 단계의 데이터 흐름을 자세히 보기 위해 저는 수동 할당 단계를 남겨두었는데,완전한 솔루션은 자동 라우팅을 지원합니다。
실제로 기업 환경에 들어가면 시스템이 작업 난이도와 보안 요구 사항에 따라 단말-클라우드 작업을 자동으로 할당하여, 이 기술 솔루션이 지속적으로 운영될 수 있는 비즈니스 프로세스가 되도록 합니다.
학습이 끝난 후, 진짜 시련이 시작됩니다
여러 차례 테스트해 본 결과, Spark-X2.6에게 가장 깊은 인상을 받은 점은 기업에게 선택의 여지를 남겨두었다는 것입니다.
대형 모델이 처음 인기를 끌던 시절, 기업의 AI 활용은 기본적으로 클라우드 API 하나 연결하는 정도로 간단하고 직관적이었습니다.
그러나 AI가 실제 업무에 들어가자 상황은 금방 복잡해졌습니다.
계약서와 고객 자료는 업로드하기 꺼려지고, 잦은 호출은 Token 비용을 계속 발생시키며, 전부 단말 측에 두면 복잡한 작업의 성능이 뒤처질 수 있습니다.
단말-클라우드 협업의 가치는 기업이 자신의 비즈니스에 맞춰 배포 방식을 자유롭게 조정할 수 있게 하는 데 있습니다.
Stanford《2026 AI Index》에 따르면 전 세계 이미 88%의 응답 기업이 AI를 사용하고 있지만, Agent의 거의 모든 비즈니스 직능에서의 확산 배포율은 여전히 한 자릿수에 그치고 있습니다.
이는 AI가 이미 기업에 들어왔지만, 핵심 업무는 아직 진정으로 Agent에게 맡겨지지 않았음을 보여줍니다.
Agent가 핵심 업무로 더 나아가게 하려면 모델 능력뿐 아니라 배포 방식도 시나리오의 변화에 맞춰야 합니다.
병원, 학교, 사무실이 직면한 제약은 각각 다르므로, 단말 측과 클라우드를 어떻게 나눌지에 대한 답도 당연히 하나만 있을 수 없습니다.
iFlytek가 흥미로운 점은, 이 문제를 이미 몇 년 동안 고민해 왔다는 것입니다.
처음부터 iFlytek는 국산 컴퓨팅 인프라를 갈고닦는 데 많은 시간을 쏟았습니다.
생각해 보면, 모델이 국산 컴퓨팅 파워에서 「구동되게」 만들고 일련의 추론 적합 문제들을 해결하는 것만으로도 정신이 아픈 일입니다.
그런데 더 강력한 것은, iFlytek가 단순히 구동을 넘어 이 인프라 위에서 대형 모델의 완전한 훈련 과정을 완주하며, 국제 일류에 필적하는 실력의 대형 모델을 직접 학습시켰다는 점입니다.
「구동」에서 「학습」까지, 들어는 몇 글자 차이지만 그 뒤의 엔지니어링 난이도는 완전히 다른 차원입니다.
둘러보면 이 전체 체인을 위해 장기적으로 구멍을 메울 의향이 있는 회사는 정말 많지 않습니다.
그리고 iFlytek가 이 몇 년간 겪은 시행착오와 축적한 경험은 이제 단말 측 모델과 단말-클라우드 협업을 위한 가장 단단한 밑천이 되었습니다.
물론 일찍 시작한 것은 시작일 뿐, 이 노선이 얼마나 멀리 갈 수 있는지를 결정하는 것은 결국 규모화된 실제 적용의 성과입니다.
이런 유형의 장기적 시련은 중국 과학기술 산업에서 드물지 않습니다.
북두(Beidou)는 1994년 프로젝트 시작부터 2020년 글로벌 네트워크 구축 완료까지 26년이 걸렸습니다.
C919는 2007년 프로젝트 시작부터 2023년 상업 첫 비행까지 16년이 걸렸습니다.
기술적 돌파부터 실제 사용까지, 그 사이에는 아직 먼 길이 남아 있습니다.
중국 모델의 국산화 길 역시 이 관문을 피할 수 없습니다.
새 모델과 벤치마크 성적은 쉽게 주목받지만, 시스템 적합, 프로젝트 인도, 장기 운영 같은 일들은 평소에는 거의 논의되지 않습니다.
모델 능력은 반복적인 개선으로 따라잡을 수 있지만, 이런 잘 드러나지 않는 축적은 하루아침에 메울 수 없습니다.
iFlytek가 몇 년 먼저 걸어온 강점이 이제 드러나기 시작했습니다.
P.S. 지금 星辰MaaS 플랫폼에서 Spark-X2.6 10억 Tokens 한도를 무료로 받을 수 있습니다~
바로가기 링크:
https://maas.xfyun.cn/modelService
https://huggingface.co/collections/XHToken/spark-x26
https://github.com/XHToken/Spark-X2.6
https://www.modelscope.cn/collections/XHToken/Spark-X26