LightSeek website authoring guide

Scope

These instructions apply to the entire repository. Use them when writing or editing research posts, producing figures, exporting assets, and checking the rendered site.

The reference standard is the presentation used by:

• blog/docs/kimi-k3-optimization-gb300-part-i.md
• blog/docs/kimi-k3-draft-collection.md
• Their matching assets in blog/public/images/202609/
• The figure language in HiSparse: Scaling Sparse-Attention Decoding with Hierarchical KV Cache Management

Aim for the clarity of a research paper and the restraint of a high-quality research blog. The design should help a reader understand the result; it should not compete with the result.

Editorial style

• Write in direct, technical prose. State the question, experimental contract, result, and limitation explicitly.
• Preserve the boundary of every claim. Distinguish end-to-end results, local ablations, interpolated values, estimates, and theoretical capacity.
• Give every measurement a unit and enough context to interpret it. Define uncommon abbreviations on first use.
• Use sentence case for headings, figure titles, legends, and labels.
• Keep paragraphs focused. Prefer a compact table when readers need to compare several exact configurations or measurements.
• Use bold text sparingly for genuine emphasis, never for an entire figure caption.
• Use typographic symbols in prose where appropriate, such as 2.5×, μs, and GiB. Preserve literal command-line flags and code identifiers in backticks.

Placing a figure

Introduce the question answered by a figure before the image, then interpret the important observation after it. Do not leave the reader to infer why the figure is present.

Use descriptive alt text and an italic caption in this exact form:

![Routed-down projection benchmark comparing replicated and sharded paths](/images/202609/kimi-k3-gb300-routed-down-benchmark.png)

*Figure 3. Routed-down projection latency for replicated and sharded paths.*

Caption rules:

• Use Figure N. with a period, not Figure N: with a colon.
• Italicize the whole caption with single asterisks. Do not bold it.
• Use sentence case and end with a period.
• Keep the caption factual and concise. Put interpretation in the body text.
• Keep one blank line between the image and caption and one after the caption.
• Number figures in the order they appear and update later references when the order changes.
• Do not bake the caption or figure number into the image itself.

Alt text should identify the content or comparison, not repeat Figure N or the filename. If the figure conveys a conclusion that is not explained in the surrounding prose, improve the prose as well as the alt text.

Figure visual system

Research-paper reference

Use the HiSparse paper as a visual reference, especially Figures 1–4. Its figures establish several useful patterns:

• Compact small multiples use the same visual grammar and place (a), (b), and (c) labels where readers can scan them quickly.
• Blue and orange distinguish the primary comparison while light-gray grids and axes stay subordinate to the data.
• Architecture diagrams use pale grouped regions to communicate ownership and memory or compute boundaries without heavy decoration.
• Numbered steps, short verb-led labels, and directional arrows make execution order explicit.
• Legends and color keys sit close to the data, and captions carry the detailed experimental context instead of crowding the artwork.

Match that clarity and information structure, not the physical size of a two-column paper figure. Paper typography is too small for a web image viewed at roughly 800 CSS pixels wide, so enlarge labels, add whitespace, and simplify annotations while preserving the paper's data and meaning. Never paste a paper screenshot into the site when an editable, web-legible redraw is expected.

Overall direction

• Use a white canvas, near-black primary text, neutral-gray supporting text, light-gray rules, and a small, consistent set of accent colors.
• Favor generous whitespace, a clear reading order, and simple geometry.
• Avoid gradients, drop shadows, decorative illustrations, glossy effects, heavy borders, and unnecessary color.
• Use color to encode meaning consistently. Do not rely on color alone; combine it with labels, marker shapes, line styles, or position when series must be distinguishable.
• Keep all text horizontal unless an axis label genuinely benefits from being vertical.

The existing Figma components and published figures are the color source of truth. When a new component is needed, start from this palette:

• Primary text: #202124
• Secondary text: #70757A
• Grid and separators: #E5E7EB
• Borders: #D1D5DB
• Subtle panel fill: #F8FAFC
• Blue: #1F77B4
• Orange: #FF7F0E
• Green: #1B9E77
• Magenta: #BC3D68

Use no more accent colors than the data requires. Prefer blue for the primary or optimized path and gray for a neutral baseline; use orange for a contrasting control or transition. Do not imply good/bad semantics unless the content does.

Canvas, spacing, and type

• Design the master frame at 1600 px wide with an opaque white background.
• Export at 2×, producing a 3200 px-wide PNG. Height follows the content; do not stretch a figure to a preset aspect ratio.
• Use 72–96 px outer margins at the 1600 px design size. Align titles, plots, panels, and notes to a shared grid.
• Use an 8 px spacing system. Typical major gaps are 24, 32, 48, and 64 px.
• Reuse the Figma file's text styles. If a new file must be created, use Inter for prose and IBM Plex Mono for code, tensor shapes, ranks, and numeric schematics.
• At the 1600 px design size, use approximately 36–40 px for the title, 18–20 px for the subtitle, 16–18 px for panel headings and axis labels, and 14–16 px for ticks and annotations. Do not use text below 13 px.
• Prefer Regular and Medium weights. Use Semibold only for titles, panel labels, or a deliberately emphasized result; avoid large blocks of bold text.

Review the figure at the size it will occupy in the article, roughly 800 CSS pixels wide on desktop. If labels are not comfortably readable there, simplify the figure or increase the text size.

Charts

• Give each chart one clear title and, when useful, a short gray subtitle that states hardware, workload, or configuration.
• Label axes with both metric and unit. Use consistent number formatting and honest axis domains; disclose truncation or a log scale.
• Use thin, light-gray grid lines and quiet axes. Keep data lines and markers visually stronger than the grid.
• Use 2–3 px data strokes and 8–12 px markers at the 1600 px design size.
• Put legends above the plot when practical. Keep series order consistent across related charts.
• Direct-label only the points that help the reader understand the result. Prevent labels from colliding with markers, axes, or one another.
• For small multiples, share plot dimensions, domains, typography, and spacing.
• Verify every plotted value and label against the source data. A visual cleanup must never silently change the experiment.

Architecture and process diagrams

• Build diagrams from editable vectors, text, and components rather than a flattened screenshot.
• Use a left-to-right or top-to-bottom reading order. Make the baseline and new design visually parallel so the difference is immediately visible.
• Use subtle fills, 1–1.5 px borders, 12–16 px corner radii, and consistent arrowheads. Reserve saturated color for the active path or changed component.
• Keep labels short. Move detailed explanation into the article instead of shrinking text to make it fit.
• Use monospaced text only for code, formulas, dimensions, ranks, or literal values. Use the sans-serif style for explanation.

Screenshots and profiler traces may be used when the pixels themselves are the evidence. Crop them tightly, remove unrelated interface chrome, and add only the minimum callouts needed to direct attention. Do not redraw a trace in a way that could imply measurements that were not captured.

Figma workflow

Use the shared LightSeek figure file as the editable source of truth:

• File: https://www.figma.com/design/9GkumhKbBmAaGt15dHOUUV
• Create one page per article and name it after the article title or slug.
• The Kimi K3 Draft Collection page is a reference for chart, mask, sequence, and profiler layouts.

For each figure:

1. Duplicate the closest existing figure or component set. Do not start with a visually unrelated template.
2. Create a named 1600 px-wide frame, such as Figure 03 — Routed-down benchmark. Keep the figure number in the Figma layer name only, not in the visible artwork.
3. Place the old image or paper figure in a locked Reference layer when matching an existing visual. Rebuild the content beside it with editable Figma layers; do not ship the reference raster as the new design.
4. Reuse local color, text, grid, marker, panel, and arrow styles. Use components and Auto Layout for repeated structures so spacing remains consistent.
5. Preserve the source data, labels, units, topology, and direction of every arrow. Resolve ambiguity from the article or source data rather than guessing.
6. Check the frame at 100% and at approximately 50%, which approximates its desktop article size. Also check that annotations remain understandable on a narrow viewport.
7. Hide or remove reference layers and export the frame itself as PNG at 2×. Confirm that the white frame background is included and that no object is clipped.

Keep source layers sensibly named and grouped. A future editor should be able to change a label, data point, or color without reconstructing the figure.

Asset integration

• Store blog figures under blog/public/images/YYYYMM/.
• Use lowercase, descriptive, kebab-case filenames beginning with the article or subject prefix, for example kimi-k3-draft-throughput.png.
• Reference assets from Markdown with the public path /images/YYYYMM/name.png.
• Export finished research figures as high-resolution PNGs. Keep Figma as the editable source; do not commit ad hoc working files or local screenshots.
• Optimize file size without reducing dimensions or introducing visible text, line, or transparency artifacts.
• If replacing an image that is already live and the update must appear immediately, prefer a new descriptive filename and update the Markdown path. Reusing the same URL can leave the old image in browser or CDN caches for several hours.

Verification

Before committing a figure or article change:

1. Run npm run build from the repository root.
2. Confirm the exported PNG is 3200 px wide and has the intended aspect ratio.
3. Inspect the rendered article, not only the Markdown preview. Check desktop and narrow layouts for legibility, overflow, spacing, and caption styling.
4. Confirm captions render as italic text (<em>), not bold text (<strong>).
5. Check figure order, in-text references, alt text, filenames, units, legends, and plotted values.
6. Review the diff to ensure no unrelated prose or assets changed.

Treat a successful build as necessary but not sufficient: the final check is whether the published page communicates the result clearly at normal reading size.