BartConfig wrong decoder_start_token_id?
# 🐛 Bug

## Information

Model I am using (Bert, XLNet ...): Bart

Language I am using the model on (English, Chinese ...): English

## To reproduce

Steps to reproduce the behavior:

```
from transformers import BartConfig, BartTokenizer
config = BartConfig.from_pretrained('facebook/bart-large')
tokenizer = BartTokenizer.from_pretrained('facebook/bart-large')
config.decoder_start_token_id
>>> 2
tokenizer.bos_token_id
>>> 0 # != config.decoder_start_token_id
tokenizer.eos_token_id
>>> 2
```

It is misleading in the documentation of the function ```generate````

*decoder_start_token_id=None – (optional) int If an encoder-decoder model starts decoding with a different token than BOS. Defaults to None and is changed to BOS later.*


## Expected behavior

I expect that decoder_start_token_id = tokenizer.bos_token_id, but maybe the model is designed to start decoding with EOS token.


Thanks for this issue we should update the documentation here!<|||||>@patrickvonplaten Thanks for the answer! Therefore what is expected from the model? EOS I guess?<|||||>Bart normally has the decoder_input_token_id defined in its config so there shoud be no problem<|||||>Hi, I also wondered about this.
`facebook/bart-base` and `facebook/bart-large-mnli` do not have `decoder_start_token_id` defined in their config file so it defaults to 0 (`bos_token_id`), while all the other BART models have it as 2 (`eos_token_id`). 
Is there any reason for it?
In fairseq's implementation looks like it is always `bos`:
https://github.com/pytorch/fairseq/blob/5d7ed6ab4f92d20ad10f8f792b8703e260a938ac/fairseq/models/bart/hub_interface.py#L123<|||||>`prefix_tokens` in fairseq is not the same as `config.decoder_start_token_id` It is more like `config.force_bos_token_to_be_generated`, if I remember correctly.

For the finetuned summarization versions,
I have checked very aggressively and they work much better when `decoder_start_token_id=2`.

@FomalhautB Do you have any empirical evidence that bart-base/bart-large are different?<|||||>> `prefix_tokens` in fairseq is not the same as `config.decoder_start_token_id` It is more like `config.force_bos_token_to_be_generated`, if I remember correctly.
> 
> For the finetuned summarization versions,
> I have checked very aggressively and they work much better when `decoder_start_token_id=2`.
> 
> @FomalhautB Do you have any empirical evidence that bart-base/bart-large are different?

I was training an autoregressive model based on Bart. It works fine until the day the config changed. After training my model for a few iterations, it only generates `<s></s>` and never changed for the iterations after that. I fixed this by forcing `decoder_start_token_id` to be 0. I didn't write anything about the `decoder_start_token_id` before and I didn't change the way that Bart generates text. I am not sure if this is also the case for the original Bart model.<|||||>That's super interesting, thanks for reporting this!

Would you mind seeing if leaving `decoder_start_token_id=2`,  but adding `force_bos_token_to_be_generated=True` changes anything?

I'd also be interested in seeing what a batch of your data looks like during training/what finetuning code you are using if you are willing to share.

<|||||>Any updates on this issue? I'm also confused<|||||>Hey @sshleifer, could you take a second look at this issue?<|||||>@patrickvonplaten @sshleifer 
Hello, any updates?
if `labels`'s prefix of `bos` is added automatically by `BartTokenizer`, using `eos` as the first token to start generate seems unreasonable, right? 

But it seems that it is deliberately designed rather than a bug, why is that?
![image](https://user-images.githubusercontent.com/38466901/126856297-2a305148-ffde-4f79-ba19-2a1159e2f499.png)
