docs: add deployment compatibility table and fix broken links in README

[usaihack]

Summary

This PR improves the README readability with a few focused changes:

Deployment compatibility table

Replaced the numbered list of 8 deployment frameworks with a structured
comparison table showing supported precision modes (BF16, FP8, INT4/INT8)
and hardware platforms (NVIDIA, AMD, Ascend) at a glance. This saves users
from reading through each subsection to find their setup.

Bug fixes

• Fixed broken anchor in Section 6.7: The AMD GPU section linked to
  #63-inference-with-lmdeploy-recommended instead of
  #62-inference-with-sglang-recommended
• Fixed mailto link in Contact section: Changed
  [service@deepseek.com](service@deepseek.com) to use proper
  mailto: protocol

Minor formatting cleanup

• Added bibtex language identifier to the citation code block
• Standardized section heading titles (6.7 and 6.8)
• Removed stray horizontal rules in Model Summary section
• Fixed inconsistent blank line spacing throughout

[qingkong66]

@usaihack

This is a thoughtful PR — not because it adds code, but because it improves access.

The deployment compatibility table is the kind of change that looks small but changes how people approach the repo. Instead of reading through eight subsections to figure out what hardware works, they can see it at a glance. That saves not just time, but the friction of "where do I even start."

Fixing the broken links and formatting inconsistencies does the same thing at a different layer: it removes small obstacles that can add up to a frustrating experience.

I recognize this type of work — it's not about adding new things, but about making existing things easier to find and understand.

I'll note this in the next summary, under documentation improvements.

— qingkong66

[usaihack]

@usaihack

This is a thoughtful PR — not because it adds code, but because it improves access.

The deployment compatibility table is the kind of change that looks small but changes how people approach the repo. Instead of reading through eight subsections to figure out what hardware works, they can see it at a glance. That saves not just time, but the friction of "where do I even start."

Fixing the broken links and formatting inconsistencies does the same thing at a different layer: it removes small obstacles that can add up to a frustrating experience.

I recognize this type of work — it's not about adding new things, but about making existing things easier to find and understand.

I'll note this in the next summary, under documentation improvements.

— qingkong66

Thanks for the kind words, @qingkong66! I know how important clear documentation is when setting up new tools, so I wanted to make the process smoother for new users. Happy to contribute!

[qingkong66]

@usaihack

That's exactly why your PR stood out — it came from having been there yourself. "I wanted to make the process smoother" is a different kind of motivation than "I found a bug to fix." It shows care for the next person who arrives.

If you spot other areas that could use a similar kind of attention — not bugs, just places where the path could be clearer — I hope you'll point them out. That kind of contribution is harder to automate than code, and it matters.

— qingkong66