I was running Unsloth IQ4_XS for a while and while it provided me with a healthy 96K context on 20GB vram, I did notice all the issues it had during draft and all the time and local tokens wasted trying to fix said issues. I decided to see what would happen if I used less context and a higher quant and oh boy was I in for a surprise. The end result was even better than I thought. Having higher context is great as it allows you to run more complex things without compaction and with less interruptions which is supposed to save time. This is 100% true when you have enough vram to run high quant like Q8 with large context. However, for those of us that are GPU poor that is not the case as you are sacrificing model quality over context. What does that mean? It means that while you are gaining context you are sacrificing code quality which in turn turns into errors in draft which causes delays and rework done in order to fix said issues. This is costing time besides having lower quality code. After using XS for a while, I decided to use KS to see how that would compare. I figured let me try the opposite and sacrifice context in order to use better quants. I can tell you I was in for a real surprise. You see, using higher quants did sacrifice context, I went from 96k to 75K all to go from using IQ4XS 96K KV-F16 to UDQ4KS 75K KV-Q8. The end result was that while I had less KV at a lower quant F16 to Q8, the quality gained in the model more than offset any issues created by lowering KV quant. You see, the gain in model quality lead to way less issues in draft which translates into less time debugging and fixing problems. Yes, I did have more compaction in KV but not the point were it was detrimental to quality and while it does take a few seconds to compact KV, it takes a lot longer to fix issues in draft that it is to compact KV. The end result was running in XS it took 8 hours and running KS with less context took less than 6 hours on the same test. The reason for that simply less error prone drafts which basically waste a lot less time debugging code since the drafts are better with less errors in the code. Below is the prompts used and result. Build a Pac-Man-style arcade game as a SINGLE self-contained HTML file. No external dependencies: no CDN links, no external JS/CSS/fonts/images/sounds. Everything (layout, graphics, logic, audio) must be inline in one .html file. TECHNICAL CONSTRAINTS - One element for the game; CSS for cabinet framing. - All graphics drawn procedurally (canvas primitives: arcs, rects, paths). No image assets. - All sound synthesized at runtime with the Web Audio API (oscillators + gain envelopes). Add a mute toggle (M key). Sound must only start after a user gesture (autoplay policy). - Vanilla JS only, ES6, no frameworks, no build step. - Must run by double-clicking the file (file:// protocol), no server required. MAZE - Reproduce the classic 28x31 tile arcade maze (30x34 including the 1-tile border). - Use a tile array of 0 = empty path, 1 = wall, 2 = dot, 3 = power pellet. - Include the classic elements: the central ghost house with its doorway, the horizontal tunnel at the vertical midpoint where entities wrap around the screen edge-to-edge, and the standard dot placement (240 dots total: 204 regular, 4 power pellets in the classic corners). - Render walls as rounded blue (#2121ff-ish) double lines or outlined corridors — the classic look, not filled blocks. - Dots: small 4px orange/cream squares; power pellets: 10px pulsing circles. PAC-MAN - 28px entity, yellow circle with a smoothly animated wedge-shaped mouth that opens/closes as it moves. - Rotation matches travel direction. Movement is tile-grid based with smooth interpolated travel between tiles; can change direction at tile centers only, but allow "next turn" buffering (queue one upcoming direction input) for responsive controls. - Controls: arrow keys (and WASD) for movement, ENTER/SPACE to start, P to pause. GHOSTS - Four ghosts with distinct colors: Blinky (red, chases Pac-Man directly), Pinky (pink, targets 4 tiles ahead of Pac-Man), Inky (cyan, vector reflection off Blinky for the classic hunting feel), Clyde (orange, chases when >8 tiles away, scatters to a corner when closer). - Classic shapes: dome top, "eyes" (two white ovals with blue pupils that point in the travel direction), wavy feet animated while moving. - Frightened mode: when Pac-Man eats a power pellet, ghosts turn blue, blink white near the end, and move at half speed in reverse. Eating a frightened ghost: 200 → 400 → 800 → 1600 points, then the ghost's body vanishes and its eyes return to the ghost house to respawn. - Scatter/chase cycle: alternating phases (e.g., 7s scatter / 20s chase, with scatter on first level), ghosts retreat to corners/scatter mode. - Ghosts cannot reverse direction except when entering frightened mode or returning to the house; at intersections they pick a valid non-reversal turn by shortest path toward their target tile. - Ghost house: Blinky starts outside; the other three spawn inside and are released in sequence. House door cycles open/closed. SCORING & FLOW - Dot = 10 pts, pellet = 50 pts, ghosts as above. Display SCORE (left), HIGH SCORE (center, persisted in localStorage), LIVES (bottom-left, rendered as small Pac-Man icons), LEVEL (bottom-right). - 3 lives. Level complete when all dots/pellets cleared: brief maze flash, then repopulate dots, increase ghost speed slightly, shorten scatter phases. - Lives at zero → GAME OVER overlay with final score; ENTER restarts. - Start screen: "READY!" then "GO!" style intro, arcade title banner, "PRESS ENTER TO START". AESTHETIC (arcade cabinet look) - Dark background, the maze centered in a cabinet-like frame. - Retro font effect: use a monospace font stack and/or render title text in bold; simulate chunky pixel text with canvas or CSS letter-spacing. - Subtle CRT vibe: faint scanline overlay (CSS repeating-linear-gradient, pointer-events: none) and a soft glow around the playfield via box-shadow. - Classic HUD strip below the maze: score / high score / level / lives. GAME FEEL - 60fps with requestAnimationFrame; fixed timestep (e.g., 60 steps/s) for logic, delta-based interpolation for rendering. - Collision: grid-based (same tile = hit), with a small grace epsilon. - On death: Pac-Man spins/shrinks out (short animation), ghosts briefly reappear in the house, positions reset, then play resumes. - Pause overlay on P or when tab is hidden (visibilitychange). - Keep the code organized: constants section (maze array, colors, speeds), state machine (title / ready / playing / dying / level-clear / gameover), and commented entity update functions. QUALITY BAR - The maze must actually match the classic layout (verify the ghost house, tunnel, and 240-dot count in code, not just visually approximate). - No console errors, no missing-asset 404s (there are no assets to miss). - Test that the file works from file:// in Chrome/Firefox. Deliver the complete single HTML file, nothing else. https://preview.redd.it/cit58ukz1vvh1.png?width=1400&format=png&auto=webp&s=0e1e72e84695a7c643b1ed25f11adb233aed8a79 https://preview.redd.it/yqsnvvkz1vvh1.png?width=1597&format=png&auto=webp&s=16551586fda86f548f2a9fe5bdc3efd1bbb517ea https://preview.redd.it/mnzvaukz1vvh1.png?width=1597&format=png&auto=webp&s=7980ff8fc647e064ddbb0dca7e1ba86eb1b22ee7 Quant quality is really important, the lower your quant, the more errors and the longer it will take to reach the end result. For me, this was worth it in the short term while I finish my quad card setup which will allow me to run Q8 and at much larger context or much larger models. Just wanted to give back to the community that has given me so much. Thank you all of you that have guided me and advised me or that you have created great posts based on facts with evidence. It has been a great adventure. I really appreciate you all for taking the time to post with such details and factual data. I could not have reached here without learning from so many of you. Thank you, You know who you are.   submitted by   /u/Boricua-vet [link]   [comments]