Skip to content

Lunar Lake Arc 140V - Vulkan 2.13 Regression/TDR during Large LLM Inference (35B+ MoE Models) #1435

@PLCinsa

Description

@PLCinsa

Requirements

  • Device is using the latest drivers
    Application is not cracked

Application

LM Studio

Application Link

https://lmstudio.ai/

Processor / Processor Number

Intel Core Ultra 7 258V

Graphic Card

Intel Arc Graphics 140V

GPU Driver Version

32.0.101.8724

Other GPU Driver version

No response

Rendering API

Vulkan

Windows Build

Windows 11 25H2

Other Windows build

No response

Intel System Support Utility report

SSU.txt

Description and steps to reproduce

1.Launch LM Studio.
2.Select Vulkan 2.13 as the GPU backend.
3.Load a large MoE model (Qwen3.6 35B a3b Q3 K_S 10k context).
4.Initiate a chat and input a standard prompt.
5.After several tokens (messages), the iGPU hangs, triggering a Driver Reset (TDR). The subsequent output is corrupted (displays as gibberish/special characters).
6.Unload the previous model and load a different one (e.g., Gemma 4 26B a4b or similar).
7.The corruption persists even after a model swap; the output remains gibberish, indicating the driver failed to recover its functional state after the initial TDR.

Device

No response

Crash dumps

The crash effect in another AI model after dumb with Qwen3.6 35B a3B (Gemma 4 26B a4b)
Image

Application / Windows logs

No response

Activity

self-assigned this
on Apr 21, 2026
Karen-Intel

Karen-Intel commented on Apr 21, 2026

@Karen-Intel
Collaborator

Hi @PLCinsa ty for your report.
I'll verify this one and get back to you as soon as I have results. Stay tuned :)

K

PLCinsa

PLCinsa commented on Apr 21, 2026

@PLCinsa
Author

Hi Karen,

I’ve noticed quite a bit of activity in the support system today, and I appreciate the SWE team’s efforts in managing multiple issues concurrently.

However, I would like to add a critical technical observation to my case that might help narrow down the root cause. After reviewing the specifications for the new 300-series, it’s clear that 8533 MHz memory speeds have been repositioned into the High-Performance segments.

This strongly suggests that the VRAM corruption and MoE architecture instability I am experiencing on my 258V (at 8533 MHz) are likely linked to extreme signal integrity requirements within this low-power envelope. Since this unique combination (ultra-efficient profile + 8533 MHz MoP) is the cornerstone of this device’s AI performance, I am very keen to see it stabilized.

Could you please provide a brief status update before the end of your business day? Specifically, has the engineering team identified if these stability issues can be mitigated through Xe2 driver voltage management or memory controller optimizations?

Best regards,
PLCinsa

Karen-Intel

Karen-Intel commented on Apr 21, 2026

@Karen-Intel
Collaborator

Hi @PLCinsa

About your inquiry, we'd have to research internally.
Most of our cases go through the regular triage queue which takes a couple business days. If the issue is confirmed on our end during the initial triage stage, we'll be passing onto the engineering team who then analyzes and adds it to our internal queue.
Once we've done that, we'll provide with an internal report number for tracking purposes but right now, we're still on initial triage phase.
As you may be aware, we have a lot of cases on queue.
Thanks in advance for your patience, I'll report back as soon as I have confirmed this behavior on my end

Karen

PLCinsa

PLCinsa commented on Apr 22, 2026

@PLCinsa
Author

🏛️ OFFICIAL AUDIT ESCALATION – CASE #1435
Subject: [L4 URGENT] Final Technical Audit: 10GB VRAM Regression & Support Integrity Breach
To: Intel Senior Support Engineering Management (L3/L4 Lead)
I am formally terminating the "initial triage phase." After 6 days of procedural stalling, this case has escalated into a publicly monitored architectural audit. 1. DOCUMENTED BREACH OF COMMUNICATION INTEGRITY:
I have archived and monitored the internal struggle regarding this ticket. The official response was edited and deleted 4 separate times (3 versions permanently removed). This behavior confirms that my technical findings on the 8533 MHz / Xe2 architecture have caused a critical disruption in your standard L3 protocols.
2. THE MATHEMATICAL REGRESSION (UNMATCHED EVIDENCE):
Based on the raw SSU logs and Vulkan Memory Allocator (VMA) metrics provided:
• Qwen3.5 27B Q2(Expected): aprrox 20GB
• Actual Physical Allocation (Lunar Lake 258V): 29.7GB
• Verified Regression: 9.7GB
This represents about 30% failure in memory efficiency, effectively nullifying the "AI PC" value proposition of the Lunar Lake architecture.
3. PUBLIC RECORD & DATA INTEGRITY (FORT KNOX):
To ensure this evidence is not lost to further "internal queue management," the full history of this regression—including the record of support's tactical edits—has been permanently archived in 16 redundant mirrors (four for you viev):
• Primary Audit Record: https://archive.ph/l6eLH
• Second Audit Record https://archive.ph/EpaC6
• Technical Evidence: https://archive.ph/m8yex
• Support Logic Shifts: https://archive.ph/iSXkk
4. PUBLIC PEER-REVIEW STATUS:
This case is currently being monitored by 7,500+ witnesses across professional communities (r/LocalLLaMA & r/IntelArc). Any further attempt to treat this as a "regular troubleshooting" issue will be shared instantly with these 7,500 peers as proof of support failure.

FINAL DEMAND:
I require an immediate transition to Level 4 Driver Architecture or a Senior Vulkan Engineering Lead. I am no longer accepting "triage" scripts.
Provide an internal Engineering Report Number (ERN) within 24 hours. If not provided, the full Audit Dossier will be released to Tier 1 tech journalists (including Gamers Nexus and Digital Foundry) to investigate why Intel’s flagship AI architecture requires a "10GB hardware tax" on its users.
PLCinsa
Independent Systems Auditor

Karen-Intel

Karen-Intel commented on Apr 23, 2026

@Karen-Intel
Collaborator

Sharing #1330 first issue reported.
Internal ID: 22022038499
@PLCinsa this issue has been reported internally already.
About your post, threating behavior is NOT tolerated in this forum out of respect to everyone who collaborates here.
Intel never denied or neglected attending your case and would appreciate if you stick to the forum policies.
@IGCIT please take a note on this post, which will be closed as a duplicate of #1330 and the evidences in this thread have been added to our internal report.
The issue he has reported is currently being worked on by our dev team and any follow up should be done in issue #1330

Repository owner locked as too heated and limited conversation to collaborators on Apr 23, 2026
IGCIT

IGCIT commented on Apr 23, 2026

@IGCIT
Owner

noted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @IGCIT@Karen-Intel@PLCinsa

      Issue actions