Instructions to use tencent/Hy-MT2-7B-GGUF with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- llama.cpp
How to use tencent/Hy-MT2-7B-GGUF with llama.cpp:
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh # Start a local OpenAI-compatible server with a web UI: llama serve -hf tencent/Hy-MT2-7B-GGUF:Q4_K_M # Run inference directly in the terminal: llama cli -hf tencent/Hy-MT2-7B-GGUF:Q4_K_M
Install from WinGet (Windows)
winget install llama.cpp # Start a local OpenAI-compatible server with a web UI: llama serve -hf tencent/Hy-MT2-7B-GGUF:Q4_K_M # Run inference directly in the terminal: llama cli -hf tencent/Hy-MT2-7B-GGUF:Q4_K_M
Use pre-built binary
# Download pre-built binary from: # https://github.com/ggerganov/llama.cpp/releases # Start a local OpenAI-compatible server with a web UI: ./llama-server -hf tencent/Hy-MT2-7B-GGUF:Q4_K_M # Run inference directly in the terminal: ./llama-cli -hf tencent/Hy-MT2-7B-GGUF:Q4_K_M
Build from source code
git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build cmake --build build -j --target llama-server llama-cli # Start a local OpenAI-compatible server with a web UI: ./build/bin/llama-server -hf tencent/Hy-MT2-7B-GGUF:Q4_K_M # Run inference directly in the terminal: ./build/bin/llama-cli -hf tencent/Hy-MT2-7B-GGUF:Q4_K_M
Use Docker
docker model run hf.co/tencent/Hy-MT2-7B-GGUF:Q4_K_M
- LM Studio
- Jan
- Ollama
How to use tencent/Hy-MT2-7B-GGUF with Ollama:
ollama run hf.co/tencent/Hy-MT2-7B-GGUF:Q4_K_M
- Unsloth Desktop
- Docker Model Runner
How to use tencent/Hy-MT2-7B-GGUF with Docker Model Runner:
docker model run hf.co/tencent/Hy-MT2-7B-GGUF:Q4_K_M
- Lemonade
How to use tencent/Hy-MT2-7B-GGUF with Lemonade:
Pull the model
# Download Lemonade from https://lemonade-server.ai/ lemonade pull tencent/Hy-MT2-7B-GGUF:Q4_K_M
Run and chat with the model
lemonade run user.Hy-MT2-7B-GGUF-Q4_K_M
List all available models
lemonade list
- Atomic Chat
Formatting degradation and token corruption when handling structured tags (SRT translation use-case)
Hello Hunyuan Team,
I am testing Hy-MT2-7B-GGUF (8_0) for structured subtitle translation using a batch-processing translation UI (via OpenAI-compatible API format). The model shows impressive linguistic quality and excellent prompt processing speed, but it struggles to maintain strict structural formatting under heavy context load (16K context window).
Steps to reproduce / Context:
- Inference: LM Studio (llama.cpp backend) with the official <|hy_begin_of_sentence|> chat template.
- Parameters: Temp 0.7 (also tested down to 0.2), Top_P 0.6, Top_K 20, Rep_Penalty 1.05.
- Input format: Batches of subtitle lines, where the model is instructed to wrap each translated line into indexed technical tags like [TRANSLATE_0]...[/TRANSLATE_0], [TRANSLATE_1]...[/TRANSLATE_1].
Observed behavior:
As the generation progresses, the model suffers from structural degradation:
Character/Layout corruption: It randomly mixes Cyrillic and Latin characters within the technical tags (e.g., generating Cyrillic Т instead of Latin T in [TRANSLATE]), which completely breaks downstream regex parsers.
Missing closing tags: It frequently skips or forgets to generate closing tags (e.g., [/TRANSLATE_X]) towards the end of a long batch response.
Token Leakage and Semantic Collapse via Streaming API (Subtitle Edit use-case)
I have performed additional testing using Subtitle Edit (which utilizes a line-by-line streaming approach via OpenAI-compatible endpoint), and encountered a critical token-handling regression:Stop Token Leakage: The model completely fails to intercept its own internal chat template boundaries. Instead of stopping the generation, it prints the raw formatting markers directly into the text output, with corrupted/broken special characters (e.g., outputs literal string like: ...как<|hy_end▁of▁assistant|>).
Semantic Collapse on Idioms: Under this workload, the translation quality severely degrades. The model loses sentence-level context and falls back to chaotic literalism, turning natural expressions into unreadable word-by-word direct translations (e.g., completely misinterpreting context-dependent clauses into broken syntax).
This confirms that the Hy-MT2-7B architecture is highly unstable when interfacing with standard LLM middleware and UI parsing wrappers, leading to immediate context degradation.
It seems the heavy fine-tuning for pure text-to-text translation makes the 7B model "resist" complex non-standard formatting constraints, causing it to lose tracking of XML-like block structures. Lowering the temperature to 0.2 reduces the frequency but does not completely eliminate this tag corruption issue.
Are there any specific prompting strategies or logit bias adjustments recommended to keep the structural tokens strict for the Hy-MT2 series?
Thank you for your hard work on this model!
Thank you for your detailed feedback. Currently, our model supports a maximum context length of 8K. We have indeed noticed a decline in performance and instruction-following capability when handling long texts, and this is exactly what we plan to optimize next.